openldap-technical September 2010

openldap-technical@openldap.org

111 participants
113 discussions

invalid syntax on pwdPolicy object add
by Julien Vehent 16 Sep '10

16 Sep '10

Hello all, I'm trying to add a default password policy to my directory. I have set the following parameters in slapd.conf: ---- include /etc/ldap/schema/ppolicy.schema [...] moduleload ppolicy [...] backend hdb database hdb suffix "dc=example,dc=net" [...] # Password policy overlay ppolicy ppolicy_default "cn=defaultpwpolicy,ou=policies,dc=example,dc=net" ---- I have created the OU 'policies' just fine, but when I try to add a pwdPolicy object, i get the following error: ---- # ldapadd -x -D cn=admin,dc=example,dc=net -W << EOF dn: cn=defaultpwpolicy,ou=policies,dc=example,dc=net objectClass: pwdPolicy objectClass: top pwdAttribute: userPassword pwdAllowUserChange: TRUE pwdInHistory: 2 pwdMaxFailure: 10 pwdLockout: TRUE pwdLockoutDuration: 1800 pwdMinLength: 6 EOF Enter LDAP Password: adding new entry "cn=defaultpwpolicy,ou=policies,dc=example,dc=net" ldap_add: Invalid syntax (21) additional info: objectClass: value #0 invalid per syntax ---- The Schema is properly loaded, the ppolicy.so module is in the path (ie, /usr/lib/ldap on debian). So, I'm out of ideas. Anything I've missed here ? Thanks for your help, Julien

5 9

Re: Authenticate to ldap using Kerberos
by Dan White 16 Sep '10

16 Sep '10

On 09/09/10 10:21 +0800, Wouter van Marle wrote: >> That requires pass-through authentication. > >I see. >Well with the above instructions nothing seems to have changed. >I have restarted saslauthd and slapd after making the changes, and when >now accessing the ldap addressbook using Evolution, I still have to use >the ldap stored password, not the krb password. > >Wouter. To be a little more explicit, to enable pass-through authentication, you will need to replace the password (userPassword attribute) with: userPassword: {SASL}username@realm for instance: dn: uid=jsmith,dc=example,dc=com ... userPassword: {SASL}jsmith In this case, the user will have no valid password defined in LDAP (or at least not in the userPassword attribute). When attempting to perform a non-sasl bind, slapd will use saslauthd to authenticate, by taking the username (from the userPassword field), and the password that was submitted. -- Dan White

8 33

How to bootstrap in mirror mode with cn=config
by Torsten Schlabach (Tascel eG) 16 Sep '10

16 Sep '10

Dear list! I am currently chasing some replication problems and I am trying to get my mind around a couple of questions. Let's assume this: We have two LDAP servers, server 1 and server 2, which are supposed to be mirrors of each other. The both have their cn=config database and a database with actual data, let's assume it's the dc=example,dc=com database. I want to run not only dc=example,dc=com but also cn=config in mirror mode to make sure that I keep the config in sync and that any changes to the config (e.g. ACls) can be done on one of the servers and will replicate to the other one. Let's assume this was all working well. Not server 2 fails and needs a complete reinstall. So I sit there with a slapd binary and no configuration at all. My idea would be (please tell me if I am on the right path) : 1. I could give server 2 a minimal config which does not contain anything else but "replicate your cn=config from server1". Let's call this a bootstrap config. 2. Once server 2 starts with that bootstrap config, it will fetch cn=config from server1. 3. It will learn from the replicated config that it has to have an dc=example,dc=com database, create it and replicate its content from server1 as well. 4. I would be back in business. Unfortunately, when I tried, what happened was: The contextCSN of the bootstrap config on server 2 is newer / higher than the one on server 1 which has not been touched for a while. So server 2 did not fetch the config from server 1 but vice versa, which was not exactly the result I intended. Though it's very consequent and logical behaviour. My question: Am I on the complete wrtong track? Would I have to do the slapcat -> slapadd thing between server 1 and server 2 first (with server 2 offline) and start server 2 only after that? When I do the slapcat / slapadd thing from server 1 to server 2, do I have to remove any contextCSN / entryCSN entries (as some postings such as http://www.mail-archive.com/openldap-technical@openldap.org/msg00109.html) suggest or would that be just wrong? Regards, Torsten

1 0

Can't get TLS working.
by c0re 16 Sep '10

16 Sep '10

Hello everyone! Wrote to openldap-software, but got "Technical details of permanent failure: Google tried to deliver your message, but it was rejected by the recipient domain. We recommend contacting the other email provider for further information about the cause of this error. The error that the other server returned was: 550 550 5.1.1 <openldap-software(a)openldap.org>... User unknown (state 14)." So I'm here. I'm trying to make openldap+TLS on freebsd 7.3. I configured openldap, nss_ldap, ldap.conf, nsswitch.conf, can ldapsearch it, can make "id user" and etc. So when I do "id test" I get uid=5555(test) gid=5555 groups=5555 All ok. And now I want to add TLS to it. So I add to slapd.conf TLSCertificateFile /usr/local/etc/openldap/ssl/ldap.server.ru.crt.pem TLSCertificateKeyFile /usr/local/etc/openldap/ssl/ldap.server.ru.key.pem TLSCACertificateFile /usr/local/etc/openldap/ssl/rootcrt.pem In nss_ldap and ldap.conf I add folowing: ssl start_tls tls_cacertfile /usr/local/etc/openldap/ssl-client/rootcrt.pem I start slapd with debugging: /usr/local/libexec/slapd -u ldap -d 1 and making "id test" I get "id: test: no such user" And slapd debug: slap_listener_activate(7): >>> slap_listener(ldap:///) connection_get(11): got connid=1000 connection_read(11): checking for input on id=1000 ber_get_next ber_get_next: tag 0x30 len 29 contents: op tag 0x77, time 1284477158 ber_get_next conn=1000 op=0 do_extended ber_scanf fmt ({m) ber: send_ldap_extended: err=0 oid= len=0 send_ldap_response: msgid=1 tag=120 err=0 ber_flush2: 14 bytes to sd 11 connection_get(11): got connid=1000 connection_read(11): checking for input on id=1000 TLS trace: SSL_accept:before/accept initialization TLS trace: SSL_accept:SSLv3 read client hello A TLS trace: SSL_accept:SSLv3 write server hello A TLS trace: SSL_accept:SSLv3 write certificate A TLS trace: SSL_accept:SSLv3 write server done A TLS trace: SSL_accept:SSLv3 flush data TLS trace: SSL_accept:error in SSLv3 read client certificate A TLS trace: SSL_accept:error in SSLv3 read client certificate A connection_get(11): got connid=1000 connection_read(11): checking for input on id=1000 TLS trace: SSL_accept:SSLv3 read client key exchange A TLS trace: SSL_accept:SSLv3 read finished A TLS trace: SSL_accept:SSLv3 write change cipher spec A TLS trace: SSL_accept:SSLv3 write finished A TLS trace: SSL_accept:SSLv3 flush data connection_read(11): unable to get TLS client DN, error=49 id=1000 connection_get(11): got connid=1000 connection_read(11): checking for input on id=1000 ber_get_next ber_get_next: tag 0x30 len 5 contents: op tag 0x42, time 1284477158 ber_get_next TLS trace: SSL3 alert read:warning:close notify ber_get_next on fd 11 failed errno=0 (Undefined error: 0) conn=1000 op=1 do_unbind connection_close: conn=1000 sd=11 TLS trace: SSL3 alert write:warning:close notify That's all. What's wrong? Where should I look at? What other information should I post here? I do not like this string: "ber_get_next on fd 11 failed errno=0 (Undefined error: 0)" But I do not know what that mean.

4 16

Re: Troubleshoot ACLs
by Torsten Schlabach (Tascel eG) 15 Sep '10

15 Sep '10

Hi again! In the concrete case you explain, maybe the group thing doesn't work as expected. Here is our (anonymized) entry for that: {3}to dn.regex="o=([^,]+),o=planet" by self write by group.expand="cn=admins2,o=$1,o=planet" write by dn.base="cn=admin,o=planet" write by dn.base="uid=someoneelse,ou=user,o=anyorg,o=planet" write by * search What that does is: In each o=something,o=planet subtree we have a group called cn=admins2,o=something,o=planet. Each member of that group has write access to o=something,o=planet. The lines by dn.base="cn=admin,o=planet" write by dn.base="uid=someoneelse,ou=user,o=anyorg,o=planet" write are needed to make sure that our two superusers cn=admin,o=planet and uid=someoneelse,ou=user,o=anyorg,o=planet also keep having access. One nasty thing about how ACLs work is: As soon as the "to" portion machtes, no further entries are scanned. So if we would say {4}to * by dn.base="cn=admin,o=planet" write by dn.base="uid=someoneelse,ou=user,o=anyorg,o=planet" write later, the entry {3} would still result in cn=admin and uid=someoneelse not having *any* access to o=...,o=planet if they would not be explicitely mentioned in entry {3}. This is what many people stumble on. Regards, Torsten On Wed, 15 Sep 2010 14:58:43 +0200, Marcel van Dorp <marcel(a)van-dorp.nl> wrote: > Torsten Schlabach (Tascel eG) wrote: >> Hi Marcel! >> >> Your setup is exactly what we also do. >> >> My question: >> >> What works and what doesn't? > > It is quite a lot now, and I did not document properly what did and did > not work; sorry! I am working with a copy of a real configuration > (thanks to virtualization!), so basically I can start from scratch with > the ACLs. > >> >> How do you test it? Manually? >> > > With PHPldapadmin (PLA). I have a linux workplace, with 2 screens > (X-windows). On each screen I have a browser open. In the left browser I > log on as cn=admin,cn=config, and there I do the tweaking. On the right > browser I login as a user. This way the session cookies remain separate, > and do not conflict with each other (which happens if you use 2 tabs > within the same browser). I did some (obvious) abbreviation in my > original post. As a normal user I use something like: > > cn=testuser,ou=cust1,ou=customers,ou=people,dc=example,dc=com > > In this example I would like to have read rights to anything from: > > ou=cust1,ou=customers,ou=people,dc=example,dc=com > > this DN included, and all children (my own entry is there as well). > > If I am also a member of the group > > cn=cust1,ou=groups,dc=example,dc=com > > then I would like to have write rights as well in beformentioned parts > of the directory. > > I tried a zillion combinations, but all I get, is access to my own entry > (in many cases, I can login, but cannot read the directory, not even my > own entry). > > > When I log in in PLA, I get the two toplevel DNs: > cn=config > dc=example,dc=com > > Which I cannot expand. Just above this my own DN is displayed, and when > I click on the left-most field, I get my entry, and I then can expand > the tree (number of children between parenthesis): > > dc=example,dc=com (1) > ou=people (1) > ou=customers (1) > ou=cust1 (1) > cn=testuser > > When I open the parent (ou=cust1), I do not see any content (there is an > objectclass definition, the ou attribute (obviously) and an extra > 'description' attribute (for testing only). In my own entry > (cn=testuser), I can see all attributes. > > The debug output says a few things about matching and masking, but it is > not very clear which ACL-line is processed, and if this is about the > 'to' or the 'by' part. > > Hope this clearifies things a bit. Any suggestions? > > Marcel > >> Regards, >> Torsten >> >> On Wed, 15 Sep 2010 09:36:38 +0200, Marcel van Dorp <marcel(a)van-dorp.nl> >> wrote: >>> Hi, >>> >>> I try to implement certain ACLs, but apparently something goes wrong. I >>> read a lot about ACLs, and I do not understand what I do wrong. Maybe >>> someone on this list can help. >>> >>> I use the Debian (lenny) version of openLDAP (version 2.4.11-1), with >>> phpldapadmin as frontend. I use cn=config >>> >>> I try to achieve the following: >>> >>> *) No anonymous access >>> *) Users can change their own attributes/children >>> *) LDAP managers are listed in a groupOfNames >>> *) Customers should have READ access to their parent entry, and all >>> children of their parent (siblings) >>> *) Specific users below a customer should have WRITE access to their >>> parent, and all siblings (users are member of a specific groupOfNames) >>> >>> I have the following ACLs in olcAccess (sanitized, on multiple lines for >>> readability, with group/groupOfNames/member abbt. to g/gON/m below): >>> >>> {0}to attrs=userPassword,shadowLastChange >>> by dn.base="cn=admin,ou=roles,dc=exm,dc=com" write >>> by g/gON/m.exact="cn=ldapadm,ou=groups,dc=exm,dc=com" write >>> by g/gON/m.exact="cn=repl,ou=roles,dc=exm,dc=com" read >>> by anonymous auth >>> by self write >>> by * none >>> >>> {1}to dn.base="" by * read >>> >>> {2}to dn.regex="ou=([^,]+),ou=cust,ou=people,dc=exm,dc=com" >>> by dn.exact,expand="cn=[^,]+,ou=$1,ou=cust,ou=people,dc=exm,dc=com" >> read >>> by g/gON/m.exact,expand="cn=$1,ou=cust,ou=people,dc=exm,dc=com" write >>> by * none >>> >>> {3}to attrs=mail,entry >>> by dn.exact="cn=admin,ou=roles,dc=exm,dc=com" write >>> by g/gON/m.exact="cn=ldapadm,ou=groups,dc=exm,dc=com" write >>> by self write >>> by * read >>> >>> {4}to * >>> by dn.exact="cn=admin,ou=roles,dc=exm,dc=com" write >>> by g/gON/m.exact="cn=ldapadm,ou=groups,dc=exm,dc=com" write >>> by anonymous search >>> by self write >>> by * none >>> >>> >>> Explanation: >>> >>> {0} superuser, admins and self can change passwords. Replicators can >>> read, anonymous can authenticate, and others have no access. >>> >>> {1} Is added to get some result, gives read access to the top level of >>> the directory. It shows 'cn=config', and 'dc=exm,dc=com' >>> >>> {2} Is the ACL which I expected to work. >>> The 'to' clause matches any customer in that branch >>> The first 'by' matches any member in a group with the same name >>> The second 'by' matches any entry below this customer >>> The last 'by' denies other access >>> >>> {3} Is there, because the email address is used for login (matching dn >>> is looked up, and then used to bind. See documentation of phpldapadmin). >>> >>> {4} Is there, so I can actually do something (My dn is in the mentioned >>> group) >>> >>> I played with a different order and the like, but I do not get what I >>> want. When I enable logging (olcLogLevel = ACL), I get some info, but it >>> is hard to determine where it goes wrong. >>> >>> Regarding {2}: >>> *) I also prepended the 'to' with '.+,' to match everything below, but >>> to no avail. >>> *) I also tried the 'by' clauses with 'dn=regex' instead of 'dn.exact' >>> >>> Questions: >>> >>> 1) What is it I do wrong? >>> 2) How can I troubleshoot these issues (ACL validator available?) >>> >>> >>> If more info is needed, please let me know. >>> >>> Marcel

2 1

Changing serverID considered harmful
by Andrew Findlay 15 Sep '10

15 Sep '10

This one caused some head-scratching recently so just in case anyone else comes across it... I was updating the OpenLDAP installation for a customer, and part of the work involved converting from a single server to a mirrormode pair with some read-only slaves. The sequence of events was: 1) Dump old server to LDIF 2) Update software from 2.3.x to 2.4.23 3) Clear out and reload database from LDIF 4) Many entries added, deleted, modified 5) Second server introduced, mirrormode configured This involved adding 'serverID 1' to the original server config and restarting it. 6) Read-only slave configured, pre-loaded from the same LDIF 7) Slave started The new servers updated using refreshAndPersist mode: they got all the adds and changes but did not process any of the deletes. The problem was introduced at stage 5: by changing from serverID 000 to serverID 001 I had broken an assumption in the code. I am still not clear on exactly what went wrong, as I would expect the server to simply regard all its current entries to have come from some other master server. The effect was reproducable though: no deletes were processed by the consuming server. The correct thing would be to set the serverID before loading the initial data, but if that gets missed it seems to be OK to take a new LDIF dump after changing the ID, and to use that to pre-load replica servers. Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | -----------------------------------------------------------------------

2 2

Re: Troubleshoot ACLs
by Torsten Schlabach (Tascel eG) 15 Sep '10

15 Sep '10

On Wed, 15 Sep 2010 14:58:43 +0200, Marcel van Dorp <marcel(a)van-dorp.nl> wrote: > When I log in in PLA, I get the two toplevel DNs: > cn=config > dc=example,dc=com > > Which I cannot expand. Might you make your life harder than necessary by using PLA? Could you properly expand dc=example,dc=com when you had the default ACL, i.e. before you did any changes? > Hope this clearifies things a bit. Any suggestions? Take a look at http://linux.die.net/man/8/slapacl It may be a bit of a learning curve initially, but this will enable you to write yourself some scripts which will iterate over a set of entries and check you permissions. So you can easily make changes and see if they do what you think you want to do. Regards, Torsten P.S.: Double-check to reply to the list. ;-)

1 0

syncrepl: contextCSN less than entryCSN
by Ioan Indreias 15 Sep '10

15 Sep '10

Hello, We are running openldap 2.4.21 configured as a consumer, using a refreshAndPersist replication: syncrepl rid=202 provider=ldaps://ldap.hashed.net type=refreshAndPersist interval=00:00:05:00 retry="10 3 60 +" searchbase="ou=emailservice,o=hashed" filter="(objectClass=*)" scope=sub attrs="*" schemachecking=off bindmethod=simple binddn="cn=ldap-hashed-service,o=hashed" credentials=xx-xx-xx tls_reqcert=never In order to check if the replication works OK we compare (periodically) the provider's contextCSN versus the consumer's contextCSN Most of the time both are in sync but from time to time we see that these parameters are different (provider contextCSN > consumer contextCSN) and we thought that the consumer was not "in sync" with the provider. Continuing our investigations we found that in the consumer there are objects with entryCSN greater than the consumer contextCSN. Is this a normal situation or a bug? Bellow you could find an extract from the ldapsearch we ran on the consumer side. Best regards, Ioan Indreias ### Provider SID: 001 Local SID: 015 test199.entryCSN (20100910085049.959625) less than 001.contextCSN (20100910085055.650259) less than johndoe.entryCSN (20100910092955.693053) --- CONSUMER --- # extended LDIF # # LDAPv3 # base <o=hashed> with scope subtree # filter: (objectclass=*) # requesting: + # # hashed dn: o=hashed structuralObjectClass: organization entryUUID: 541ccdcb-8d82-4160-9fc7-1892765cbdac creatorsName: cn=superuser,o=hashed createTimestamp: 20100714124242Z entryCSN: 20100714124242.721169Z#000000#015#000000 modifiersName: cn=superuser,o=hashed modifyTimestamp: 20100714124242Z contextCSN: 20100909124709.457916Z#000000#015#000000 contextCSN: 20100910085055.650259Z#000000#001#000000 entryDN: o=hashed subschemaSubentry: cn=Subschema auditContext: cn=auditlog # emailservice, hashed dn: ou=emailservice,o=hashed structuralObjectClass: organizationalUnit entryUUID: b8950978-248b-4b77-bcf9-6455f9c273c0 creatorsName: cn=superuser,o=hashed createTimestamp: 20100714124242Z modifiersName: cn=superuser,o=hashed modifyTimestamp: 20100714124242Z entryCSN: 20100730103008.669976Z#000000#001#000000 entryDN: ou=emailservice,o=hashed subschemaSubentry: cn=Subschema hasSubordinates: TRUE # org, emailservice, hashed dn: dc=org,ou=emailservice,o=hashed structuralObjectClass: domain entryUUID: 32e805e8-669c-471e-b9d3-1d22938bdce3 creatorsName: cn=superuser,o=hashed createTimestamp: 20100714124242Z modifiersName: cn=superuser,o=hashed modifyTimestamp: 20100714124242Z entryCSN: 20100730103013.472630Z#000000#001#000000 entryDN: dc=org,ou=emailservice,o=hashed subschemaSubentry: cn=Subschema hasSubordinates: TRUE # hashed, org, emailservice, hashed dn: dc=hashed,dc=org,ou=emailservice,o=hashed structuralObjectClass: domain entryUUID: 3bd366ba-5213-4bf2-8935-3ddbb26bf220 creatorsName: cn=superuser,o=hashed createTimestamp: 20100714124242Z modifiersName: cn=superuser,o=hashed modifyTimestamp: 20100714124242Z entryCSN: 20100730103018.690150Z#000000#001#000000 entryDN: dc=hashed,dc=org,ou=emailservice,o=hashed subschemaSubentry: cn=Subschema hasSubordinates: TRUE # users, hashed, org, emailservice, hashed dn: ou=users,dc=hashed,dc=org,ou=emailservice,o=hashed structuralObjectClass: organizationalUnit entryUUID: 87390f34-5698-4653-a700-5045843813db creatorsName: cn=superuser,o=hashed createTimestamp: 20100714124242Z modifiersName: cn=superuser,o=hashed modifyTimestamp: 20100714124242Z entryCSN: 20100802144805.677791Z#000000#001#000000 entryDN: ou=users,dc=hashed,dc=org,ou=emailservice,o=hashed subschemaSubentry: cn=Subschema hasSubordinates: TRUE ... # test199, users, hashed, org, emailservice, hashed dn: uid=test199,ou=users,dc=hashed,dc=org,ou=emailservice,o=hashed structuralObjectClass: inetOrgPerson entryCSN: 20100910085049.959625Z#000000#001#000000 entryUUID: 416a2a78-5104-102f-8592-6d824ed7581a creatorsName: cn=superuser,o=hashed createTimestamp: 20100910085049Z modifiersName: cn=superuser,o=hashed modifyTimestamp: 20100910085049Z entryDN: uid=test199,ou=users,dc=hashed,dc=org,ou=emailservice,o=hashed subschemaSubentry: cn=Subschema hasSubordinates: FALSE # johndoe, users, hashed, org, emailservice, hashed dn: uid=johndoe,ou=users,dc=hashed,dc=org,ou=emailservice,o=hashed structuralObjectClass: inetOrgPerson entryCSN: 20100910092955.693053Z#000000#001#000000 entryUUID: b794ae8a-5109-102f-8593-6d824ed7581a creatorsName: cn=superuser,o=hashed createTimestamp: 20100910092955Z modifiersName: cn=superuser,o=hashed modifyTimestamp: 20100910092955Z entryDN: uid=johndoe,ou=users,dc=hashed,dc=org,ou=emailservice,o=hashed subschemaSubentry: cn=Subschema hasSubordinates: FALSE # search result search: 2 result: 0 Success # numResponses: 197 # numEntries: 196 ###

3 5

Troubleshoot ACLs
by Marcel van Dorp 15 Sep '10

15 Sep '10

Hi, I try to implement certain ACLs, but apparently something goes wrong. I read a lot about ACLs, and I do not understand what I do wrong. Maybe someone on this list can help. I use the Debian (lenny) version of openLDAP (version 2.4.11-1), with phpldapadmin as frontend. I use cn=config I try to achieve the following: *) No anonymous access *) Users can change their own attributes/children *) LDAP managers are listed in a groupOfNames *) Customers should have READ access to their parent entry, and all children of their parent (siblings) *) Specific users below a customer should have WRITE access to their parent, and all siblings (users are member of a specific groupOfNames) I have the following ACLs in olcAccess (sanitized, on multiple lines for readability, with group/groupOfNames/member abbt. to g/gON/m below): {0}to attrs=userPassword,shadowLastChange by dn.base="cn=admin,ou=roles,dc=exm,dc=com" write by g/gON/m.exact="cn=ldapadm,ou=groups,dc=exm,dc=com" write by g/gON/m.exact="cn=repl,ou=roles,dc=exm,dc=com" read by anonymous auth by self write by * none {1}to dn.base="" by * read {2}to dn.regex="ou=([^,]+),ou=cust,ou=people,dc=exm,dc=com" by dn.exact,expand="cn=[^,]+,ou=$1,ou=cust,ou=people,dc=exm,dc=com" read by g/gON/m.exact,expand="cn=$1,ou=cust,ou=people,dc=exm,dc=com" write by * none {3}to attrs=mail,entry by dn.exact="cn=admin,ou=roles,dc=exm,dc=com" write by g/gON/m.exact="cn=ldapadm,ou=groups,dc=exm,dc=com" write by self write by * read {4}to * by dn.exact="cn=admin,ou=roles,dc=exm,dc=com" write by g/gON/m.exact="cn=ldapadm,ou=groups,dc=exm,dc=com" write by anonymous search by self write by * none Explanation: {0} superuser, admins and self can change passwords. Replicators can read, anonymous can authenticate, and others have no access. {1} Is added to get some result, gives read access to the top level of the directory. It shows 'cn=config', and 'dc=exm,dc=com' {2} Is the ACL which I expected to work. The 'to' clause matches any customer in that branch The first 'by' matches any member in a group with the same name The second 'by' matches any entry below this customer The last 'by' denies other access {3} Is there, because the email address is used for login (matching dn is looked up, and then used to bind. See documentation of phpldapadmin). {4} Is there, so I can actually do something (My dn is in the mentioned group) I played with a different order and the like, but I do not get what I want. When I enable logging (olcLogLevel = ACL), I get some info, but it is hard to determine where it goes wrong. Regarding {2}: *) I also prepended the 'to' with '.+,' to match everything below, but to no avail. *) I also tried the 'by' clauses with 'dn=regex' instead of 'dn.exact' Questions: 1) What is it I do wrong? 2) How can I troubleshoot these issues (ACL validator available?) If more info is needed, please let me know. Marcel

1 0

ldapcompare on rootDSE attribute types
by Dieter Kluenter 14 Sep '10

14 Sep '10

Hello, what would be the correct DN for a compare on rootDSE? Although the examples of the manual page seem to be quite specific, none of the following seem to be correct: :~> ldapcompare -x -Z -H ldap://localhost:9004 "" supportedControl:1.3.6.1.4.1.42.2.27.8.5.1 Compare Result: Inappropriate matching (18) Additional info: inappropriate matching request UNDEFINED :~> ldapcompare -x -Z -H ldap://localhost:9004 dn: supportedControl:1.3.6.1.4.1.42.2.27.8.5.1 Compare Result: Invalid DN syntax (34) Additional info: invalid DN UNDEFINED -Dieter -- Dieter Klünter | Systemberatung sip: 7770535(a)sipgate.de http://www.dpunkt.de/buecher/2104.html GPG Key ID:8EF7B6C6

2 1

← Newer
1
...
4
5
6
7
8
9
10
11
12
Older →

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical September 2010