Re: (ITS#7678) Operational Error propagated from back-meta
by hyc＠symas.com
matth(a)netsight.co.uk wrote:
> Full_Name: Matt Hamilton
> Version: 2.4.36
> OS: Linux
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (213.133.64.253)
>
>
> I am using the meta backend to query multiple LDAP (AD) backends. This is to
> consolidate several directories in different departments into one. We attempt
> both simple binds with username/password and also anon binds to look up user
> information.
That doesn't make much sense, since AD disallows anonymous Binds.
> At the moment, trying to do an authenticated simple bind to slapd caused an
> Operational Error to be propagated to the client regardless of the setting of
> 'onerr'. Even when a result is successfully found. This is due to one server in
> the backend succeeding and the other returning an operational error due to an
> invalid bind (as would be expected as the credentials supplied from the client
> will only work with one of the backends).
>
> Looking at servers/slapd/back-meta/search.c at around line 1903 it appears that
> the code is not checking for 'Operational Error' as a specific case above and so
> uses the default case (line 1665). Hence sres is set to 'Operational Error' too
> at line 1934.
back-meta/search.c has nothing to do with Binds. Not sure what you're trying
to demonstrate there.
>
> The server should be changing this to LDAP_SUCCESS somewhere in that logic
> unless META_BACK_ONERR_REPORT.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
10 years
(ITS#7679) Problem with overlay dynlist
by a.rossini＠cineca.it
Full_Name: Angelo Rossini
Version: slapd 2.4.23 (Dec 16 2012 11:48:44)
OS: Debian GNU/Linux 6.0 2.6.32-5-amd64 x86_64
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (130.186.20.62)
I've tried to use the overlay dynlist to manage dynamic group; i've added these
rows to slapd.conf:
# required schema for dynamic groups
include /etc/ldap/schema/dyngroup.schema
# permanent load of the dynlist overlay
moduleload dynlist
overlay dynlist
dynlist-attrset groupOfURLs memberURL seeAlso
And created a group using this LDIF:
dn: cn=GROUP_DYN,ou=gruppi,o=unixx,dc=unixx,dc=it
objectClass: groupOfURLs
cn: GROUP_DYN
memberURL: ldap:///ou=users,o=unixx,dc=unixx,dc=it??sub?(schacPersonalPosition=STUDENTE)
When i try ldap searches like ldapsearch --baseDN
cn=GROUP_DYN,ou=gruppi,o=unixx,dc=unixx,dc=it '(objectClass=*)' or like
ldapsearch --baseDN cn=GROUP_DYN,ou=gruppi,o=unixx,dc=unixx,dc=it
'isMemberOf=cn=GROUP_DYN,ou=gruppi,o=unixx,dc=unixx,dc=it' is not possible to
retrieve the list of distinguished names of the results but only a list of some
other attributes of the result.
The configuration is exactly the one described in the
http://www.openldap.org/doc/admin24/overlays.html#Dynamic Lists page.
What is wrong?
Regards,
Angelo Rossini.
10 years
(ITS#7678) Operational Error propagated from back-meta
by matth＠netsight.co.uk
Full_Name: Matt Hamilton
Version: 2.4.36
OS: Linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (213.133.64.253)
I am using the meta backend to query multiple LDAP (AD) backends. This is to
consolidate several directories in different departments into one. We attempt
both simple binds with username/password and also anon binds to look up user
information.
database meta
suffix "DC=hscic,DC=nhs,DC=uk"
rootdn "DC=hscic,DC=nhs,DC=uk"
chase-referrals no
norefs yes
uri "ldap://dc1lv.npfit.nhs.uk/DC=hscic,DC=nhs,DC=uk"
"ldap://dc2lv.npfit.nhs.uk" "ldap://dc1dr.npfit.nhs.uk"
suffixmassage "DC=hscic,DC=nhs,DC=uk" "OU=Accounts - Active Users, OU=routine
objects, DC=npfit, DC=nhs, DC=uk"
idassert-bind bindmethod=simple
binddn="CN=webuser,OU=Surnames Q to Z,OU=Accounts - Active
Users,OU=Routine Objects,DC=npfit,DC=nhs,DC=uk"
credentials="secret1"
mode=self
idassert-authzFrom "dn:*"
uri "ldap://ts-l-dci-350.ic.green.net/DC=hscic,DC=nhs,DC=uk"
"ldap://ts-l-dci-344.ic.green.net" "ldap://hg-l-dci-332.ic.green.net"
suffixmassage "DC=hscic,DC=nhs,DC=uk" "OU=HSCIC,DC=ic,DC=Green,DC=Net"
idassert-bind bindmethod=simple
binddn="CN=z-CFHimport,OU=Service
Accounts,OU=Administration,DC=ic,DC=Green,DC=Net"
credentials="secret2"
mode=self
idassert-authzFrom "dn:*"
At the moment, trying to do an authenticated simple bind to slapd caused an
Operational Error to be propagated to the client regardless of the setting of
'onerr'. Even when a result is successfully found. This is due to one server in
the backend succeeding and the other returning an operational error due to an
invalid bind (as would be expected as the credentials supplied from the client
will only work with one of the backends).
Looking at servers/slapd/back-meta/search.c at around line 1903 it appears that
the code is not checking for 'Operational Error' as a specific case above and so
uses the default case (line 1665). Hence sres is set to 'Operational Error' too
at line 1934.
The server should be changing this to LDAP_SUCCESS somewhere in that logic
unless META_BACK_ONERR_REPORT.
10 years
Re: (ITS#7673) rwm and bad ACL evaluation
by michael＠stroeder.com
This is a cryptographically signed message in MIME format.
--------------ms030200060406090105050307
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Russell.Mosemann(a)cune.edu wrote:
> Further testing confirms that the filter for the ACL is not being appli=
ed
> correctly when rwm is used. Turning the rewriteEngine off has no effect=
=2E
> All lines referring to rwm must be commented.
>=20
> Interestingly, performing the query without specifying any attribute
> succeeds. All allowed attributes are returned.
Hmm, maybe it's related to this:
http://www.openldap.org/its/index.cgi?findid=3D7495
Ciao, Michael.
--------------ms030200060406090105050307
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFfzCC
BXswggNjoAMCAQICAwxOfTANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w
HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu
ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMjEw
MDIyMDE3MDlaFw0xNDEwMDIyMDE3MDlaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj
MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd
NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV
hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/
0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ
NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH
AgMBAAGjggFEMIIBQDAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdUbyBnZXQgeW91
ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6Ly93d3cuQ0Fj
ZXJ0Lm9yZzAOBgNVHQ8BAf8EBAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMC
BgorBgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIG
CCsGAQUFBzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMDEGA1UdHwQqMCgwJqAkoCKGIGh0
dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9yZXZva2UuY3JsMB8GA1UdEQQYMBaBFG1pY2hhZWxAc3Ry
b2VkZXIuY29tMA0GCSqGSIb3DQEBBQUAA4ICAQC9ouXq3p/bDWMM4tBKgD3tl4HY5H0eECl8
q9/nqk0UL6YeWkrCiQdrDtNPW7DcGqNYtzdgtzmyTr1GhiAX+igrOjdk/ge5NRcQOpONK/4b
zrmpQEcIUyxSSDKLWh211/kcFfxxLEiJ5teF4GL8Fc1qbrLP4+DCvJXWfYaaR5NLjZMqm2VP
yKTv3qpXWnGohiRkGTwS/11QM2XCfIGdRsQT9a8mO4m2fn2tGPp2TEIoCLrDDrbGVeDWaOWB
OIeTrp4wa3Q4OI6yCptJhEqKvjhV96IBRYgM76nTBqsqnDzwxExAyhhWiUS5DunRHOr/+NyF
pUpD4883RBLO0g9kUEGOhtZNF1u+8zEL0YgMGvifAom9JEklLOXZuqj0MThypKs/3d/OyOQb
4gURnu6oZwcKZ7LskytWnlRKUxF6o0A8grtmyKkqe14TS7cQbg0NTaIYXPkHR+dfFmb3uEqn
BBjvpJXFcEtWI2lQXC/ET+au991pK797ExBOmpQwjIn3SjiW80vw/UoL6DMvqY/6JhVhyNTP
MJ2W5AX5kc27DIbVtVGZs8J4AYhuNALJUq9N9Ka7rPRj3RcYDrfehDLOkM5iMnarpmtuOpLK
d1SvZhqj/0N/JWGIDpPSTkTFOPP6ZN9I9Rqyf+9NGqb2sjo4DkIiZcHxt735/GJLwus5KLBl
2DGCA6EwggOdAgEBMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93
d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8G
CSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wCQYFKw4DAhoFAKCCAfUwGAYJ
KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwOTAyMTMzNzMyWjAj
BgkqhkiG9w0BCQQxFgQUSUWFlNi+P3gVhEYcXVvCWpgF+p0wbAYJKoZIhvcNAQkPMV8wXTAL
BglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN
BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGD
MIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9y
ZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYS
c3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNV
BAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZ
Q0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNl
cnQub3JnAgMMTn0wDQYJKoZIhvcNAQEBBQAEggEAHz5RR3K9GzJnvCkk+VEaz3FbSTprmvi/
Ey1b74sXSMNwTx85VZ12vvZZquUFwFxXckqtNoqlHQfggDf224UjQB0Fx8NTzdwKuMDJAjBI
+/VGV0EP7EXkhHXoPjYAhiWU2QnX4/bWLMwIaXYhT2ANJL9dV03WU6Y2UoC6Sh+xdKEQOCA4
kjQ54Zi5e09/KuWl+3eIQivGzIi+5zbukV6VHvumpQd5IL4s1F8VTHpHgmMQiDLPK2xv5+Uc
DuwnggSmLjskrUwg7uQtJARk3Cx6k9+SM0dB0c5Edrv8kDoDpFEanS5zvtRVP13/415dJJcP
MH5Bv8s+9RzDAKF6D4vcAAAAAAAAAA==
--------------ms030200060406090105050307--
10 years