openldap-technical

openldap-technical@openldap.org

20 participants
9801 discussions

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

I can't login in my system using OpenLDAP
by Eric KOM 14 Sep '10

14 Sep '10

Hi Dear! Since 3 days I try to setting a LDAP Server with OpenLDAP on Debian Lenny. I'm using Mandriva Management Console (mmc) like web based admin. I already create some users with mmc, but I can't login? Please, everybody can help me or provide me a good tuto? -- Yours truly, Eric KOM 110 LAWN STREET ROSETTENVILLE 2190 JOHANNESBURG SOUTH AFRICA Phone: +27 (0) 788 791 334 Fax: +27 (0) 865 563 009 E-mail: erickom(a)namekom.co.za Websites: www.erickom.co.za | www.namekom.co.za/erickom | www.namekom.co.za

5 9

troubles with back-ldap based replication
by DT Piotr Wadas 14 Sep '10

14 Sep '10

Hello. I have some troubles setting syncrepl + back-ldap push based replication, as described on http://www.openldap.org/doc/admin24/replication.html#LDAP Sync Replication I'm using current stable openldap - the problem is, when I set up daemons (using the same slapcat output file) and modify e.g. "description" attribute on master side, back-ldap pushes out system attributes like entryCSN, creatorsName, etc, which causes modify operation to fail on final consumer side. conn=1000 op=33 MOD attr=creatorsName createTimestamp description entryCSN conn=1000 op=33 RESULT tag=103 err=19 text=creatorsName: no user modification allowed Is it some ACL-related matter, should I create some ACL, which denies to read of system attributes on master-side, to avoid replicating it with syncrepl to local back-ldap ? In such push-based scenario ( in opposite to classic provider-consumer syncrepl), final consumer does not know actually that it is a replica, it's just receiving modify operation, how do I prevent read-only system attributes from being pushed from back-ldap to final replica? Regards, DT

2 2

Re: invalid syntax on pwdPolicy object add
by Julien Vehent 14 Sep '10

14 Sep '10

On Tue, 14 Sep 2010 10:51:01 +0200, Emmanuel Lecharny <elecharny(a)gmail.com> wrote: > On 9/14/10 8:40 AM, mailing lists wrote: >> Hello, >> >> I think that the pwdAttribute needs an OID value (specified by the syntax) >> so you would must use the OID of the userPassword attribute which is >> 2.5.4.35 >> >> >> >> >> > I thought that would be a possibility for the failure Kiran and Julien are facing, (please guys, can you give it a try ?), but IMO, there is no reason why we would not be allowed to use 'userPassword' in this context. > > Using the OID instead of the alias name does not carry any extra information, as soon as the alias is valid accordingly to the schema (whatever it represents, be it an AT, OC, MR, or any of the other kind of schema objects). The syntax should just check that the alias is syntaxically correct. It's up to the ppolicy overlay to check that the value is a valid AT. > > Plus the error message is really misleading if this is the cause for the error. I tried with the OID... same thing. How can I check that the module is properly loaded and functional ? Julien

2 1

objectClass index from slapd.conf is not working
by tim stone 14 Sep '10

14 Sep '10

Hello, I've a strange behavior while using index objectClass for searching. In my slapd.conf I have defined the index in the database section: index objectClass eq Other indexes follows in the config. All of them working fine. If I search via ldapsearch like: ldapsearch -x -h localhost -w password -D"cn=admin,ou=root" -b"ou=root" "(objectclass=Guest)" I can find following Message in the syslog (loglevel -1): Sep 1 14:02:52 LDAP01 slapd[17856]: EQUALITY Sep 1 14:02:52 LDAP01 slapd[17856]: => bdb_equality_candidates (objectClass) Sep 1 14:02:52 LDAP01 slapd[17856]: => key_read Sep 1 14:02:52 LDAP01 slapd[17856]: <= bdb_index_read: failed (-30989) Sep 1 14:02:52 LDAP01 slapd[17856]: <= bdb_equality_candidates: id=0, first=0, last=0 Sep 1 14:02:52 LDAP01 slapd[17856]: <= bdb_filter_candidates: id=0 first=0 last=0 Sep 1 14:02:52 LDAP01 slapd[17856]: => bdb_filter_candidates Sep 1 14:02:52 LDAP01 slapd[17856]: EQUALITY Sep 1 14:02:52 LDAP01 slapd[17856]: => bdb_equality_candidates (objectClass) Sep 1 14:02:52 LDAP01 slapd[17856]: => key_read Sep 1 14:02:52 LDAP01 slapd[17856]: <= bdb_index_read 355545 candidates Sep 1 14:02:52 LDAP01 slapd[17856]: <= bdb_equality_candidates: id=-1, first=228, last=355772 Sep 1 14:02:52 LDAP01 slapd[17856]: <= bdb_filter_candidates: id=-1 first=228 last=355772 Sep 1 14:02:52 LDAP01 slapd[17856]: <= bdb_list_candidates: id=-1 first=228 last=355772 Sep 1 14:02:52 LDAP01 slapd[17856]: <= bdb_filter_candidates: id=-1 first=228 last=355772 Sep 1 14:02:52 LDAP01 slapd[17856]: <= bdb_list_candidates: id=-1 first=112277 last=355755 Sep 1 14:02:52 LDAP01 slapd[17856]: <= bdb_filter_candidates: id=-1 first=112277 last=355755 Sep 1 14:02:52 LDAP01 slapd[17856]: bdb_search_candidates: id=-1 first=112277 last=355755 Sep 1 14:02:52 LDAP01 slapd[17856]: => test_filter Sep 1 14:02:52 LDAP01 slapd[17856]: EQUALITY Sep 1 14:02:52 LDAP01 slapd[17856]: <= test_filter 5 Sep 1 14:02:52 LDAP01 slapd[17856]: bdb_search: 112277 does not match filter Sep 1 14:02:52 LDAP01 slapd[17856]: entry_decode: "cn=Aaa,cn=Bbb,... Sep 1 14:02:52 LDAP01 slapd[17856]: <= entry_decode(cn=Aaa,cn=Bbb,... Sep 1 14:02:52 LDAP01 slapd[17856]: => bdb_dn2id("cn=aaa,cn=bbb,... Sep 1 14:02:52 LDAP01 slapd[17856]: <= bdb_dn2id: got id=0x1b696 Sep 1 14:02:52 LDAP01 slapd[17856]: => test_filter Sep 1 14:02:52 LDAP01 slapd[17856]: EQUALITY Sep 1 14:02:52 LDAP01 slapd[17856] ... all other entires following... As result, the entires are found, but not in the index and the search takes a very long time. After this, I have rebuild the complete database via slapcat/slapadd, rebuild the index via slapindex for objetClass, but nothing helped. In tried the test above on: * OpenSuSE 11.1 and openLDAP 2.4.21 and 2.4.23 (linked against libdb-4.5) * OpenSuSE 11.0 and openLDAP 2.4.9 (linked against libdb-4.5) * Debian Lenny and openLDAP 2.4.11 (linked against libdb-4.2) with different databases and a search against a objectClass. If I try another index (not objectClass) from the slapd.conf the index works, example: ldapsearch -x -h localhost -w password -D"cn=admin,ou=root" -b"ou=root" "(mypk=1234-234)" Sep 1 14:03:44 LDAP01 slapd[17856]: => bdb_equality_candidates (mypk) Sep 1 14:03:44 LDAP01 slapd[17856]: => key_read Sep 1 14:03:44 LDAP01 slapd[17856]: <= bdb_index_read 1 candidates Sep 1 14:03:44 LDAP01 slapd[17856]: <= bdb_equality_candidates: id=1, first=112838, last=112838 Sep 1 14:03:44 LDAP01 slapd[17856]: <= bdb_filter_candidates: id=1 first=112838 last=112838 Sep 1 14:03:44 LDAP01 slapd[17856]: <= bdb_list_candidates: id=1 first=112838 last=112838 Sep 1 14:03:44 LDAP01 slapd[17856]: <= bdb_filter_candidates: id=1 first=112838 last=112838 Sep 1 14:03:44 LDAP01 slapd[17856]: <= bdb_list_candidates: id=1 first=112838 last=112838 Sep 1 14:03:44 LDAP01 slapd[17856]: <= bdb_filter_candidates: id=1 first=112838 last=112838 Sep 1 14:03:44 LDAP01 slapd[17856]: bdb_search_candidates: id=1 first=112838 last=112838 Sep 1 14:03:44 LDAP01 slapd[17856]: => test_filter Sep 1 14:03:44 LDAP01 slapd[17856]: EQUALITY Sep 1 14:03:44 LDAP01 slapd[17856]: <= test_filter 6 Sep 1 14:03:44 LDAP01 slapd[17856]: => send_search_entry: conn 1002 dn="cn=Fff,cn=Eee,... Sep 1 14:03:44 LDAP01 slapd[17856]: <= send_search_entry: conn 1002 exit. Sep 1 14:03:44 LDAP01 slapd[17856]: send_ldap_result: conn=1002 op=1 p=3 Sep 1 14:03:44 LDAP01 slapd[17856]: send_ldap_response: msgid=2 tag=101 err=0 Sep 1 14:03:44 LDAP01 slapd[17856]: connection_get(12): got connid=1002 Sep 1 14:03:44 LDAP01 slapd[17856]: connection_read(12): checking for input on id=1002 Sep 1 14:03:44 LDAP01 slapd[17856]: op tag 0x42, time 1283342624 Sep 1 14:03:44 LDAP01 slapd[17856]: conn=1002 op=2 do_unbind Sep 1 14:03:44 LDAP01 slapd[17856]: connection_close: conn=1002 sd=12 Why does only the objectClass index not work? The only difference I can see, is that all other indexes are based on "normal" attributes. I don't know, if it is necessary, but for objectClass I can't find a attribute definition in the schema. In the core.schema is the attribute definition for objectClass deactivated (aka #)... Here is the Config from the LDAP-Server: # Schema and objectClass definitions include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/yast.schema include /etc/openldap/schema/rfc2307bis.schema include /etc/openldap/schema/my_ldap_attribute.schema include /etc/openldap/schema/my_ldap.schema pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args modulepath /usr/lib/ldap moduleload back_bdb sizelimit -1 timelimit 300 disallow bind_anon gentlehup on tool-threads 1 ####################################################################### # bdb database definitions ####################################################################### database bdb suffix "ou=root" rootdn "cn=root,ou=root" checkpoint 4096 15 rootpw password directory /var/lib/ldap dbnosync # Indices to maintain index objectClass,entryUUID,entryCSN eq index mypk,myusername pres,eq index myproperty,mylanguage eq index cn eq,sub Kindly regards Tim Stone

3 7

Re: invalid syntax on pwdPolicy object add
by mailing lists 14 Sep '10

14 Sep '10

Hello, I think that the pwdAttribute needs an OID value (specified by the syntax) so you would must use the OID of the userPassword attribute which is 2.5.4.35

3 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical