openldap-technical

openldap-technical@openldap.org

1 participants
9989 discussions

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

Keep alive functionality when the remote closes the conenction due idle
by alin vasile 13 Sep '10

13 Sep '10

Hi guys, I have a question related to the open ldap client keep alive functionality. Our OS is SLES 11. In our client code we are reusing the ldap connections between requests uning a connection pool. For each conenction we are setting the keep-alive options (LDAP_OPT_X_KEEPALIVE_IDLE, LDAP_OPT_X_KEEPALIVE_PROBES and LDAP_OPT_X_KEEPALIVE_INTERVAL) and this works fine. My question is how the openl ldap library (libldap and libldap_r) handles the situation when the number of kee-alive probes for a connection is exceeded and the connection is closed at the server side. Did you dealt with this situation? Thanks, Alin

4 5

syncrepl incomplete database problem
by Islam Amer 13 Sep '10

13 Sep '10

Hello everyone, I have a problem with a simple master/slave syncrepl replication setup. Everytime I restart the slave it goes back to an empty state and then syncs about only 200 entries from thousands in the master. >From then on it gets the update events from the master fine. I have tried some of the things suggested in this mailing list but none have worked so far. For example I tried initializing the slave with a full slapcat of the master after deleting all files from /var/lib/ldap/ , but when I start the slave it deletes ALL entries and starts over. The master is debian etch with 2.3.30-5+etch2 ( critical, not easy to update ) The slave is 2.3.43 RHEL The slave config is : syncrepl rid=100 provider=ldaps://xxxxxxxxxxxxxx:636 type=refreshOnly tls_cert=/var/lib/ldap/ssl/clientcert.pem tls_key=/var/lib/ldap/ssl/clientkey.pem tls_cacert=/var/lib/ldap/ssl/cacert.pem interval=00:00:01:00 retry="5 60" searchbase="dc=xxxx" filter="(objectClass=*)" scope=sub schemachecking=off bindmethod=simple binddn="cn=xxxxx,dc=xxxx" credentials=xxxxxx slapd is started with options "-c rid=100,csn=0" ( the real values are obscured for security, sorry ) I switched to refreshOnly because the connection passes through a strict firewall, and I read that the persistent connection of refreshAndPersist has problems with that. Any help is appreciated. Thanks.

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical