openldap-technical

openldap-technical@openldap.org

5 participants
9899 discussions

Re: slapd ACLs
by Mik J 30 Sep '12

30 Sep '12

Thank you for your answer Olivier, I tried to do this but it didn't work. The logs look like this conn=1001 op=0 BIND dn="user2,ou=people,dc=mydomain,dc=org" method=128 conn=1001 op=0 BIND dn="user2,ou=people,dc=mydomain,dc=org" mech=SIMPLE ssf=0 conn=1001 op=0 RESULT tag=97 err=0 text= conn=1001 op=1 SRCH base="user1,ou=people,dc=mydomain,dc=org" scope=2 deref=0 filter="(objectClass=*)" conn=1001 op=1 SEARCH RESULT tag=101 err=32 nentries=0 text= conn=1001 op=2 UNBIND I triple checked, and when it works, with the dn.subtree permission in the begining of slapd.conf I have conn=1000 op=0 BIND dn="user2,ou=people,dc=mydomain,dc=org" method=128 conn=1000 op=0 BIND dn="user2,ou=people,dc=mydomain,dc=org" mech=SIMPLE ssf=0 conn=1000 op=0 RESULT tag=97 err=0 text= conn=1000 op=1 SRCH base="user1,ou=people,dc=mydomain,dc=org" scope=2 deref=0 filter="(objectClass=*)" conn=1000 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= conn=1000 op=2 UNBIND ----- Mail original ----- > De : Olivier <ldap(a)guillard.nom.fr> > À : Mik J <mikydevel(a)yahoo.fr> > Cc : > Envoyé le : Dimanche 30 septembre 2012 20h29 > Objet : Re: slapd ACLs > >T ry to put this rule : > >> access to dn.subtree="" >> by * read > > after the two others. > > (ionce a rule matches, then the scan stops : order counts) > > -- > Olivier > > 2012/9/30 Mik J <mikydevel(a)yahoo.fr>: >> Hello, >> >> I'm a bit confused with the ACLs in my slapd.conf considering I have > this >> >> access to dn.subtree="" >> by * read >> >> access to > attrs=userPassword,shadowMax,shadowExpire,sambaLMPassword,sambaNTPassword >> by dn.regex="uid=[^/]+/admin\+(realm=MYDOMAIN.ORG)?" > write >> by dn="uid=admin,ou=people,dc=mydomain,dc=org" write >> by self write >> by anonymous auth >> by * none >> >> access to * >> by dn.regex="uid=[^/]+/admin\+(realm=MYDOMAIN.ORG)?" > =wrscx >> by self write >> by users read >> by anonymous auth >> by * none >> >> >> When I do a ldapsearch without authentication, I can see the user's > details including the unencrypted password >> >> ldapsearch -x -b "uid=user1,ou=people,dc=mydomain,dc=org" >> I think that it's because the rule access to dn.subtree="" by > * read >> With an authenticated user is works as well >> >> ldapsearch -x -D uid=user2,ou=people,dc=mydomain,dc=org -b > "uid=user1,ou=people,dc=mydomain,dc=org" -W >> >> But if I comment these two lines >> #access to dn.subtree="" >> # by * read >> The search doesn't give me any result >> >> ldapsearch -x -D uid=user2,ou=people,dc=mydomain,dc=org -b > "uid=user1,ou=people,dc=mydomain,dc=org" -W >> # search result >> search: 2 >> result: 32 No such object >> # numResponses: 1 >> >> I would have expected that this command matched >> access to * >> by users read >> >> My goal is that only authenticated user would be able to access the ldap > directory and users can change their passwords >> >> Does anyone has an idea on how to explain this behavior. ? >> >> Thank you >> >

1 0

slapd ACLs
by Mik J 30 Sep '12

30 Sep '12

Hello, I'm a bit confused with the ACLs in my slapd.conf considering I have this access to dn.subtree="" by * read access to attrs=userPassword,shadowMax,shadowExpire,sambaLMPassword,sambaNTPassword by dn.regex="uid=[^/]+/admin\+(realm=MYDOMAIN.ORG)?" write by dn="uid=admin,ou=people,dc=mydomain,dc=org" write by self write by anonymous auth by * none access to * by dn.regex="uid=[^/]+/admin\+(realm=MYDOMAIN.ORG)?" =wrscx by self write by users read by anonymous auth by * none When I do a ldapsearch without authentication, I can see the user's details including the unencrypted password ldapsearch -x -b "uid=user1,ou=people,dc=mydomain,dc=org" I think that it's because the rule access to dn.subtree="" by * read With an authenticated user is works as well ldapsearch -x -D uid=user2,ou=people,dc=mydomain,dc=org -b "uid=user1,ou=people,dc=mydomain,dc=org" -W But if I comment these two lines #access to dn.subtree="" # by * read The search doesn't give me any result ldapsearch -x -D uid=user2,ou=people,dc=mydomain,dc=org -b "uid=user1,ou=people,dc=mydomain,dc=org" -W # search result search: 2 result: 32 No such object # numResponses: 1 I would have expected that this command matched access to * by users read My goal is that only authenticated user would be able to access the ldap directory and users can change their passwords Does anyone has an idea on how to explain this behavior. ? Thank you

1 0

LDAP search filter on superior/parent attribute
by Roman Rybalko 30 Sep '12

30 Sep '12

Have a schema: olcAttributeTypes: ( 2.999.777.1.1.1.3 NAME 'orderingInteger' DESC 'Integer with ordering' EQUALITY integerMatch ORDERING integerOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 ) olcAttributeTypes: ( 2.999.777.1.1.2.16 NAME 'timeInteger' DESC 'Integer time representation' SUP orderingInteger ) olcAttributeTypes: ( 2.999.777.1.1.2.17 NAME 'Mailbox' DESC 'Mailbox name' SUP info ) olcAttributeTypes: ( 2.999.777.1.1.2.16.1 NAME 'timeIntegerYear' DESC 'Integer year representation' SUP timeInteger ) olcAttributeTypes: ( 2.999.777.1.1.2.16.2 NAME 'timeIntegerMonth' DESC 'Integer month representation' SUP timeInteger ) olcAttributeTypes: ( 2.999.777.1.1.2.16.3 NAME 'timeIntegerDay' DESC 'Integer day of the month representation' SUP timeInteger ) olcAttributeTypes: ( 2.999.777.1.1.2.16.4 NAME 'timeIntegerHour' DESC 'Integer hour representation' SUP timeInteger ) olcAttributeTypes: ( 2.999.777.1.1.2.16.5 NAME 'timeIntegerMinute' DESC 'Integer minute representation' SUP timeInteger ) olcObjectClasses: ( 2.999.777.1.2.3 NAME 'entry' SUP top STRUCTURAL MAY ( timeInteger $ timeIntegerYear $ timeIntegerMonth $ timeIntegerDay $ timeIntegerHour $ timeIntegerMinute ) ) Have a search: (&(timeInteger>=1348900000)(timeInteger<=1349000000)) This search may return entries like: timeInteger: 1347014897 timeIntegerYear: 2012 timeIntegerMonth: 9 ... The entry with timeInteger=1347014897 is obviously not in [1348900000,1349000000] range, but it is matched because there are another attributes in the entry with "SUP timeInteger", so timeIntegerYear=2012 is matched the (timeInteger<=1349000000) filter part. I'm looking for RFC that describes such behavior. -- WBR, Roman Rybalko

3 2

Appropriate index for <= >= filter on generalizedTime (Re: reqStart<= slow)
by Roman Rybalko 30 Sep '12

30 Sep '12

Hi, I'm trying to use >= <= filter on eq-indexed generalizedTime attribute. Seems eq-index does not work for <= filter. olcAttributeTypes: ( 2.999.777.1.1.1.5 NAME 'logTime' DESC 'Time' EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 ) olcDbIndex: logTime eq (&(logTime>=201209201440+0400)(logTime<=201209201450+0400)) - 57sec (|(logTime=20120920144001+0400)(logTime=20120920144008+0400)) - 0.03sec ~ 1000000 records in db, target = 100000000 records What should I do to make >= filters work efficiently? I may consider using another data type that work with <=/=> filters for sure. Strings? Integers? Anything that can mimic TIME semantics. Any advice? 14.04.2012 19:44, Michael Ströder пишет: > can I influence the order of index usage by order in the filter or slapd index configuration? The same question from me. Is it possible to select indexes using some sort of filter syntax? -- WBR, Roman Rybalko

2 11

mdb_idl_fetch_key: cursor failed: Invalid argument (22)
by Roman Rybalko 30 Sep '12

30 Sep '12

I have such error in logs: null_callback : error code 0x50 syncrepl_entry: rid=001 be_add logID=502,logID=402,logHost=mail.xxx.xxx.xx,logName=main,cn=test failed (80) do_syncrepl: rid=001 rc 80 retrying (2 retries left) and then every 2-3 minutes: => mdb_idl_fetch_key: cursor failed: Invalid argument (22) MDB is running on replication consumer. I shutted down the replication provider for reindexing. The consumer was not fully synced at that time. Than I changed olcDbMaxSize on the replication consumer. Than I started the provider again. Seems the error happened first time right after olcDbMaxSize was increased from 5G to 8G. I've never changed it before. Sep 30 16:07:01 lintest slapd[518]: conn=1089 op=1 MOD dn="olcDatabase={1}mdb,cn=config" Sep 30 16:07:01 lintest slapd[518]: conn=1089 op=1 MOD attr=olcDbMaxSize Sep 30 16:07:03 lintest slapd[518]: conn=1089 op=1 RESULT tag=103 err=0 text= Sep 30 16:07:03 lintest slapd[518]: conn=1089 op=2 UNBIND Sep 30 16:07:03 lintest slapd[518]: conn=1089 fd=12 closed Sep 30 16:07:03 lintest slapd[518]: => mdb_idl_fetch_key: cursor failed: Invalid argument (22) slapd version git a1c2dc6 db size 3.7Gb What this error is about? Is it serious? Should I recreate the DB on the consumer? Seems replication is stalled. -- WBR, Roman Rybalko

1 0

LDAP and MD5 authentication issues.
by S K 30 Sep '12

30 Sep '12

Hi, I am newbie to LDAP and I am having a issue. I have to work with MD5 authentication as the application we are going to use has to bind to a LDAP server with password generated using MD5. I am not able to authenticate with password generate using the perl script or using the md5 executable. But if I generate the passwords using slappassword and MD5 I am fine. Can somebody please explain what I am doing wrong and how I can authenticate using perl or md5 exe generated password. Any help is greatly appreciated. Passwords generated using this perl script. for example. MD5 for hello perl -e 'use Digest::MD5 qw(md5_hex);print uc(md5_hex("hello"))."\n";' 5D41402ABC4B2A76B9719D911017C592 Using slappasswd ./slappasswd -h \{MD5\} -s hello {MD5}XUFAKrxLKna5cZ2REBfFkg== My LDIF file user MD5A assigned perl or md5 exe generated MD5 password and user MD5B assigned slappasswd generated MD5 password. dn: cn=MD5A, ou=hr, o=test objectClass: top objectClass: person objectClass: organizationalPerson cn: MD5A sn: MD5A userpassword: {MD5}5D41402ABC4B2A76B9719D911017C592 title: admin dn: cn=MD5B, ou=hr, o=test objectClass: top objectClass: person objectClass: organizationalPerson cn: MD5B sn: MD5B userpassword: {MD5}XUFAKrxLKna5cZ2REBfFkg== title: admin Import LDIF: # /usr/local/bin/ldapadd -x -W -D "cn=admin" -f users.ldif Enter LDAP Password: adding new entry "o=test" adding new entry "ou=hr,o=test" adding new entry "cn=MD5A, ou=hr, o=test" adding new entry "cn=MD5B, ou=hr, o=test" ldapsearch fails for MD5A with error 49 and for MD5B it works fine. # /usr/local/bin/ldapsearch -x -w hello -D "cn=MD5A, ou=hr, o=test" ldap_bind: Invalid credentials (49) # /usr/local/bin/ldapsearch -x -w hello -D "cn=MD5B, ou=hr, o=test" # extended LDIF # # LDAPv3 # base <> (default) with scope subtree # filter: (objectclass=*) # requesting: ALL # # test dn: o=test objectClass: top objectClass: organization o: test # hr, test dn: ou=hr,o=test objectClass: top objectClass: organizationalUnit ou: asqmatrix ou: hr # MD5A, hr, test dn: cn=MD5A,ou=hr,o=test objectClass: top objectClass: person objectClass: organizationalPerson cn: MD5A sn: MD5A userPassword:: e01ENX01RDQxNDAyQUJDNEIyQTc2Qjk3MTlEOTExMDE3QzU5Mg== title: admin # MD5B, hr, test dn: cn=MD5B,ou=hr,o=test objectClass: top objectClass: person objectClass: organizationalPerson cn: MD5B sn: MD5B userPassword:: e01ENX1YVUZBS3J4TEtuYTVjWjJSRUJmRmtnPT0= title: admin # search result search: 2 result: 0 Success # numResponses: 5 # numEntries: 4 Thanks, SK

2 1

Re: ldapsearch stalling when performing searches with a large number of results
by Mark Cairney 28 Sep '12

28 Sep '12

My olcDB values are listed below (minus the olcDbConfig entries). I'm not sure if you need the indexes but I've left them in anyway: olcDbDirectory: /usr/local/authz/var/openldap-data/authorise olcAddContentAcl: FALSE olcDbCacheFree: 1 olcDbCacheSize: 400000 olcDbCheckpoint: 10240 10 olcDbDirtyRead: FALSE olcDbDNcacheSize: 0 olcDbIDLcacheSize: 1200000 olcDbIndex: autoMountKey eq olcDbIndex: cn pres,eq,sub olcDbIndex: eduniCategory eq olcDbIndex: eduniCollegeCode eq olcDbIndex: eduniIdmsId pres,eq olcDbIndex: eduniIDStatus eq olcDbIndex: eduniLibraryBarcode pres,eq olcDbIndex: eduniOrganisation pres,eq,sub olcDbIndex: eduniOrgCode eq olcDbIndex: eduniSchoolCode eq olcDbIndex: eduniServiceCode pres,eq olcDbIndex: eduniType eq olcDbIndex: eduniUnitCode eq olcDbIndex: eduPersonAffiliation pres,eq olcDbIndex: eduPersonEntitlement pres,eq olcDbIndex: eduPersonPrimaryAffiliation eq olcDbIndex: eduPersonPrincipalName eq olcDbIndex: eduPersonScopedAffiliation pres,eq olcDbIndex: eduPersonTargetedID eq olcDbIndex: entryCSN eq olcDbIndex: entryUUID eq olcDbIndex: gecos pres,eq,sub olcDbIndex: gidNumber pres,eq olcDbIndex: krbName pres,eq olcDbIndex: mail pres,eq,sub olcDbIndex: memberOf pres,eq olcDbIndex: memberUid eq olcDbIndex: objectClass eq olcDbIndex: sn pres,eq,sub olcDbIndex: uid pres,eq,sub olcDbIndex: uidNumber pres,eq olcDbIndex: uniqueMember pres,eq olcDbIndex: userPassword eq olcDbLinearIndex: FALSE olcDbMode: 0600 olcDbNoSync: FALSE olcDbSearchStack: 16 olcDbShmKey: 0 and my DB_CONFIG file contains: set_cachesize 4 0 1 set_flags DB_LOG_AUTOREMOVE set_lk_max_objects 5000 set_lk_max_lockers 5000 set_lg_regionmax 41943040 set_lg_dir /usr/local/authz/slapd/trans-logs set_lk_max_locks 10000 set_lg_bsize 20971520 set_lg_max 83886080 I'm not using an SHM key (should I be?). The search that I spotted this behaviour probably means nothing outside our environment as it's against a value in our local schema but for completeness it was: (&(eduniCategory=201)(objectclass=inetorgperson)) I've seen the same behaviour with similar searches which we would expect to return a large number of results e.g. (&(eduPersonAffiliation=student)(objectclass=inetorgperson)) or indeed against groups with a lot of members. > > You may wish to read over <https://wiki.zimbra.com/wiki/OpenLDAP_Performance_Tuning>. You can easily map the information there to a non-zimbra installation. Thanks- your documentation on the DB tuning and SHM key is excellent. I can see a couple of things which I might change based on it but I'll wait to hear back before I jump in and start playing around with parameters. > > --Quanah > > -- > > Quanah Gibson-Mount > Sr. Member of Technical Staff > Zimbra, Inc > A Division of VMware, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration > /**************************** Mark R Cairney ITI UNIX Section Information Services Tel: 0131 650 6565 Email: Mark.Cairney(a)ed.ac.uk ****************************/ -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

3 7

range search on Generalized Time attribute
by Marco Schirrmeister 28 Sep '12

28 Sep '12

Hi, OpenLDAP 2.4.32 and also tried with latest RE24 BDB 4.8.30 My DB_CONFIG looks like this. set_lk_detect DB_LOCK_DEFAULT set_flags DB_TXN_NOSYNC set_flags DB_LOG_AUTOREMOVE set_lg_max 10485760 set_cachesize 0 1073741824 1 set_lk_max_locks 4000 set_lk_max_lockers 4000 set_lk_max_objects 4000 set_lg_regionmax 262144 set_lg_bsize 20971520 set_lg_dir /var/lib/ldap2.4/ogilvy.com/bdb/ In our stage directory I noticed a range search is not returning anything on a specific attribute with generalizedTime syntax. On production it works fine. Here is an example command. $ ldapsearch -x -H ldaps://ds71 -D cn=manager,dc=ogilvy,dc=com -w 'secret' -b ou=people,dc=ogilvy,dc=com -LLL '(&(lastchangeDate<=20111107235959Z)(lastchangeDate>=20111107151200Z))' dn lastchangedate $ I know my entry falls in that range. $ ldapsearch -x -H ldaps://ds71 -D cn=manager,dc=ogilvy,dc=com -w 'secret' -b ou=people,dc=ogilvy,dc=com -LLL '(uid=marco.schirrm*)' lastchangedate dn: uid=marco.schirrmeister(a)ogilvy.com,ou=people,dc=ogilvy,dc=com lastchangeDate: 20111107151301Z $ The attribute is indexed. index lastchangeDate eq Schema has this. SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch I tried recreating the index, but all that did not help. Same problem exists if I use bach-hdb. I tried that same dataset with back-mdb and the search returned what I expected. So I thought it's maybe Berkeley DB bug. I then tried bdb 5.3.15 some time ago and also the latest 5.3.21. I see the same issue with this versions. I first thought it's the amount of entries that cause that issue. It's not really much, but stage has less the prod. So tried to create different test datasets to see if I can reproduce it. I was not able to reproduce it with the test datasets. The ldapsearch always returned what I wanted. I'm now a little bit lost if my DB_CONFIG settings are maybe bad. Or if it is something in Berkeley DB or OpenLDAP. Any ideas? I'm going to switch to mdb soon. But was wondering if that is something serious or not. Here is the slapd.conf. I omitted all the schema includes and index lines. include /etc/openldap2.4/slapd.access.ogilvy.conf pidfile /var/run/ldap2.4/slapd.pid argsfile /var/run/ldap2.4/slapd.args modulepath /usr/lib64/oldap24/openldap2.4 moduleload back_monitor.la moduleload accesslog.la moduleload syncprov.la moduleload auditlog.la TLSCertificateFile /etc/pki/tls/certs/ogilvy.com.crt TLSCertificateKeyFile /etc/pki/tls/private/ogilvy.com.rsa TLSCACertificateFile /etc/pki/tls/certs/ca-bundle.crt loglevel stats sasl-secprops noplain,noanonymous,noactive serverID 40 ldaps://ds71.ogilvy.com database bdb suffix "dc=ogilvy,dc=com" rootdn "cn=manager,dc=ogilvy,dc=com" rootpw FooBarBaz directory /var/lib/ldap2.4/ogilvy.com limits dn.exact="cn=manager,dc=ogilvy,dc=com" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited limits dn.exact="uid=replicator,ou=admin,dc=ogilvy,dc=com" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited limits group/ogilvyGroup/uniqueMember="cn=svcgrp-unlimitedsearch,ou=groups,dc=ogilvy,dc=com" size.soft=unlimited size.hard=unlimited cachesize 150000 dirtyread sizelimit 90000 checkpoint 256 5 conn_max_pending_auth 2000 idlcachesize 450000 dncachesize 150000 monitoring on overlay syncprov syncprov-checkpoint 256 5 syncprov-sessionlog 5000 database config rootdn "cn=admin,cn=config" rootpw FooBarBaz include /etc/openldap2.4/slapd.access.config.conf database monitor rootdn cn=monitor rootpw FooBarBaz -- Marco

1 0

Suggestion about slapd.conf
by Net Warrior 28 Sep '12

28 Sep '12

Hi there I't been long time since I did not administer LDAP, now I have the need to do it again cuz a new proyect , reading the docs I found that lots of interesting things were included and some will be deprecated as for example slapd.conf, I need to apply some ACL, I'm familliar with the old slapd.conf style, but the documentation says slapd.conf will be deprecated sooner latter. My doubt is that it will be deprecated for the core LDAP configuration or if something will be still possible to do through it, reading the documentation ( 2.4 ) I see examples regarding the old style and do not know if that's for compatibility or not. Still I do not get familiar with the oclAccess and the new cn=something structure. Thanks for your time and support Best Regards

1 0

syncrepl failure
by manu＠netbsd.org 28 Sep '12

28 Sep '12

Hi I had a master/replicas setup that has been working for years. Recently, I discovered that a replica sometime failed to return existing entries: no error, it just returned nentries=0, for a few queries, then went back to normal. I suspected some database corruption: I killed slapd, removed the databases, restarted slapd so that it resync from master. It pulled a few hundreds of records and then got its up to date contextCSN while a lot of entries are still missing. Restarting slapd exhibit a stright failure in syncrepl: Sep 28 06:34:29 motul slapd[2901]: do_syncrepl: rid=217 rc -2 retrying How do I debug that? I had the problem with OpenLDAP-2.4.21/ db-4.7.25.3. I tried upgrading the replica to OpenLDAP-2.4.32 / db-4.8.30 but it did not change anything. Is there a chance that upgrading the master (runs 2.4.21 too) will help? During the short time syncrepl runs, logs are filled with stuff like this, I wonder if it is a related problem or not: Sep 28 03:30:16 motul slapd[269]: conn=-1 op=0 => bdb_dn2id_add dn="uid=user,ou=foo,dc=example,dc=net" ID=0x7c: put failed: DB_LOCK_DEADLOCK: Locker killed to r esolve a deadlock -30994 -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu(a)netbsd.org

2 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