openldap-technical

openldap-technical@openldap.org

5 participants
9899 discussions

odd multi-master inconsistency
by Brian Gold 25 Apr '13

25 Apr '13

Hi all. Kind of an odd issue that I was hoping to get your advice with. I'm currently running a pair of rhel6 servers (hostnames: ldap1 & ldap2) w/ openldap-2.4.23 in multi-master. I also have a pair of rhel6 servers running keepalived & haproxy to act as loadbalancers (floating ip resolves to hostname: ldap) to direct ldap queries from some of our less documented/older services from the days before we had 2 ldap servers or from services that can't natively handle failover ldap providers. This setup has been working without issue (from what I could tell) for over 2 years. I noticed today that we have an issue with 2x of our users ldap entries. They went from being students to being staff, which necessitated a uid change (username09 for student to username for staff). We have a script that was written years ago for handling these uid changes. Apparently, when this script was run on these two users, the uid change happened only on one of the ldap servers. The other still contains the old uid information. Here is a sanitized version of the script: http://pastebin.com/UiDJgWKA Would love some advice on why this might not have replicated and what I might be able to do to prevent this in the future.

3 2

retrieve local operational attributes with translucent overlay?
by Steve Eckmann 25 Apr '13

25 Apr '13

Is it possible to retrieve operational attributes associated with local entries in the context of translucent overlay queries? For example, to retrieve the local entryUUID, I try something like this: ldapsearch -x -H ldaps://localhost -LLL -b ou=people,dc=issinc,dc=com \ -D "cn=admin,ou=people,dc=issinc,dc=com" -W \ '(mail=steve.eckmann(a)issinc.com)' dn entryUUID where the 'mail' attribute is remote. I get back the DN but not an entryUUID. If I specify + instead of entryUUID I get back three operational attributes: entryDN, subschemaSubentry, and hasSubordinates. If I query a purely local backend with + I get several operational attributes, including the three I want: entryUUID, createTimestamp, and modifyTimestamp. Is there something I can put in my slapd.conf or in the search to get specific local operational attributes? Thanks. Steve

1 0

slapd terminates with error "read_config: no serverID / URL match found. Check slapd -h arguments"
by Joe Phan 24 Apr '13

24 Apr '13

Hi, When I configure N-Way Multi-Master configuration with cn=config, slapd terminates with the error: "module syncprov.la: null module registered" and "read_config: no serverID / URL match found. Check slapd -h arguments". olcServerID IDs are already added and configured properly, but when slapd starts with -h option, it always fails. Please help if someone has gone through a similar issue. Thanks, Joe Reference, Step 3-4: http://niranjanmr.wordpress.com/2012/03/29/n-waymmr/ Is there an equivalent /etc/sysconfig/ldap file in Solaris 10? Platform: Sun Solaris10 OpenLDAP: openldap-2.4.32 Configuring for N-Way Multi-Master: adding olcServerID, olcOverlay: syncprov, and olcSyncRepl: apggd04dev# more config_repl.ldif #Specify ServerID for both the masters dn: cn=config changetype: modify add: olcServerID olcServerID: 101 ldap://apggd06dev.pg.dtveng.net olcServerID: 201 ldap://apggd04dev.pg.dtveng.net #Enable Syncprov Overlay for config database dn: olcOverlay=syncprov,olcDatabase={0}config,cn=config changetype: add objectclass: olcOverlayConfig objectclass: olcSyncProvConfig olcOverlay: syncprov #Configure SyncRepl for config database dn: olcDatabase={0}config,cn=config changetype: modify add: olcSyncRepl olcSyncRepl: rid=001 provider=ldap://apggd06dev.pg.dtveng.net binddn="cn=config" bindmethod=simple credentials=secret searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5" timeout=1 olcSyncRepl: rid=002 provider=ldap://apggd04dev.pg.dtveng.net binddn="cn=config" bindmethod=simple credentials=secret searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5" timeout=1 - add: olcMirrorMode olcMirrorMode: TRUE apggd04dev# ldapmodify -x -D "cn=config" -w secret -f config_repl.ldif -h apggd04dev.pg.dtveng.net <== olcServerID IDs are already added successfully to dn: cn=config. modifying entry "cn=config" adding new entry "olcOverlay=syncprov,olcDatabase={0}config,cn=config" modifying entry "olcDatabase={0}config,cn=config" Restart slapd with -h option: ==================== apggd04dev# /usr/local/libexec/slapd -d -1 -h ldap://apggd04dev.pg.dtveng.net:389 entryUUID: 05897b3c-3bd8-1032-8598-57af23b0cca0 creatorsName: cn=config createTimestamp: 20130417182610Z olcServerID: 101 ldap://apggd06dev.pg.dtveng.net <=== olcServerID IDs are successfully loaded olcServerID: 201 ldap://apggd04dev.pg.dtveng.net <=== olcServerID IDs are successfully loaded entryCSN: 20130418183118.510871Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20130418183118Z contextCSN: 20130418183118.573577Z#000000#000#000000 ... olcModuleLoad: {0}syncprov.la 51705faf loaded module syncprov.la 51705faf module syncprov.la: null module registered <=== ERROR for syncprov.la module ... olcSyncrepl: {0}rid=001 provider=ldap://apggd06dev.pg.dtveng.net binddn="cn=co <=== olcSyncrepl is successfully loaded nfig" bindmethod=simple credentials=secret searchbase="cn=config" type=refres hAndPersist retry="5 5 300 5" timeout=1 olcSyncrepl: {1}rid=002 provider=ldap://apggd04dev.pg.dtveng.net binddn="cn=co nfig" bindmethod=simple credentials=secret searchbase="cn=config" type=refres hAndPersist retry="5 5 300 5" timeout=1 olcMirrorMode: TRUE ... 5170847e index objectClass 0x0004 5170847e index entryUUID 0x0006 5170847e index entryCSN 0x0006 5170847e send_ldap_result: conn=-1 op=0 p=0 5170847e send_ldap_result: err=0 matched="" text="" 5170655f read_config: no serverID / URL match found. Check slapd -h arguments. <=== ERROR for serverID 5170655f slapd destroy: freeing system resources. 5170655f syncinfo_free: rid=001 5170655f slapd stopped. <=== slapd terminates 5170655f connections_destroy: nothing to destroy.

3 4

Documentation for memberof overlay
by Philip Colmer 24 Apr '13

24 Apr '13

I'm trying to find documentation for the various values that can be specified for the MemberOf overlay, particularly olcMemberOfMemberAD and olcMemberOfMemberOfAD. There are other values where I'm curious as to why they have their particular value (e.g. olcMemberOfDangling: ignore). Where is this stuff documented, please? I've tried searching openldap.orgweb site but cannot find anything definitive. Thanks. Philip

2 1

pbkdf2_sha256
by Alessandro Dentella 24 Apr '13

24 Apr '13

Hi, is it possible to use password stored as pbkdf2_sha256 in slapd? A first trial on ubuntu 12.04 seems to fail... My trial was: userPassword: {PBKDF2-SHA256}12000$1Pqf0/pfyxmDsPaeEwIghA$ory6WKYGfDASDNwhsWoOiVHwqmBnHginfu.FD2YuXIs Thnaks in advance sandro *:-) -- Sandro Dentella *:-) http://www.reteisi.org Soluzioni libere per le scuole http://sqlkit.argolinux.org SQLkit home page - PyGTK/python/sqlalchemy

2 2

RE: slapd-meta as a proxy for a monolithic namespace
by Hummel, Wolfgang 24 Apr '13

24 Apr '13

Hello, thanks a lot for your support on this topic. Both inputs from Howard and Pierangelo were really helpful. With the additional config tweak it works properly. So far I tested search and delete operations successfully. Other tests to follow ... Regards Wolfgang Hummel -----Original Message----- From: Hummel, Wolfgang Sent: Dienstag, 23. April 2013 18:10 To: 'openldap-technical(a)openldap.org' Subject: slapd-meta as a proxy for a monolithic namespace Hello OpenLDAP community, we are currently planning for a largescale directory with > 1 Bio. entries in a single namespace. The idea is to divide the DB in 10 equal sized DBs and let them access by slapd-meta proxies. Example: dn: ou=rsp1,c=de,o=mno entries with uid=79101234567890, 79101234567891 etc. 791 is always fix In our scenario each server would have 100 Mio. entries using the last digit of uid as a naturally even balanced distribution mechanism. Here are the questions: - is slapd-meta a feasible approach for this scenario ? - how could the slapd.conf for the proxy look like ? Here is a (non working) example with 2 backend servers. What is wrong about it ? ... moduleload back_meta moduleload back_ldap ... ####################################################################### # Meta database ####################################################################### database meta suffix " ou=rsp1,c=de,o=mno" dncache-ttl forever lastmod off rootdn "cn=admin,ou=rsp1,c=de,o=mno" rootpw secret network-timeout 1 uri "ldap://10.11.12.170/ ou=rsp1,c=de,o=mno" rewriteEngine on #rewriteContext searchFilterAttrDN rewriteContext searchFilter rewriteRule '^uid=[0-9]{11}1,.*' 'ldap://10.11.12.170/%0' ':@' uri "ldap://10.11.12.180/ ou=rsp1,c=de,o=mno" rewriteEngine on #rewriteContext searchFilterAttrDN rewriteContext searchFilter rewriteRule '^uid=[0-9]{11}2,.*' 'ldap://10.11.12.180/%0' ':@' ...

1 0

slapd-meta as a proxy for a monolithic namespace
by Hummel, Wolfgang 24 Apr '13

24 Apr '13

Hello OpenLDAP community, we are currently planning for a largescale directory with > 1 Bio. entries in a single namespace. The idea is to divide the DB in 10 equal sized DBs and let them access by slapd-meta proxies. Example: dn: ou=rsp1,c=de,o=mno entries with uid=79101234567890, 79101234567891 etc. 791 is always fix In our scenario each server would have 100 Mio. entries using the last digit of uid as a naturally even balanced distribution mechanism. Here are the questions: - is slapd-meta a feasible approach for this scenario ? - how could the slapd.conf for the proxy look like ? Here is a (non working) example with 2 backend servers. What is wrong about it ? ... moduleload back_meta moduleload back_ldap ... ####################################################################### # Meta database ####################################################################### database meta suffix " ou=rsp1,c=de,o=mno" dncache-ttl forever lastmod off rootdn "cn=admin,ou=rsp1,c=de,o=mno" rootpw secret network-timeout 1 uri "ldap://10.11.12.170/ ou=rsp1,c=de,o=mno" rewriteEngine on #rewriteContext searchFilterAttrDN rewriteContext searchFilter rewriteRule '^uid=[0-9]{11}1,.*' 'ldap://10.11.12.170/%0' ':@' uri "ldap://10.11.12.180/ ou=rsp1,c=de,o=mno" rewriteEngine on #rewriteContext searchFilterAttrDN rewriteContext searchFilter rewriteRule '^uid=[0-9]{11}2,.*' 'ldap://10.11.12.180/%0' ':@' ... logfile snippet for # ldapsearch -LLL -xD uid=admin,ou=rsp1,c=de,o=mno -w secret -b ou=rsp1,c=de,o=mno uid=791720001981 ldap_bind: Invalid credentials (49) Apr 23 08:44:13 slapd[26200]: >>> dnPrettyNormal: <uid=admin,ou=rsp1,c=de,o=mno> Apr 23 08:44:13 slapd[26200]: <<< dnPrettyNormal: <uid=admin,ou=rsp1,c=de,o=mno>, <uid=admin,ou=rsp1,c=de,o=mno> Apr 23 08:44:13 slapd[26200]: conn=1015 op=0 BIND dn="uid=admin,ou=rsp1,c=de,o=mno" method=128 Apr 23 08:44:13 slapd[26200]: do_bind: version=3 dn="uid=admin,ou=rsp1,c=de,o=mno" method=128 Apr 23 08:44:13 slapd[26200]: conn=1015 op=0 meta_back_bind: dn="uid=admin,ou=rsp1,c=de,o=mno". Apr 23 08:44:13 slapd[26200]: conn=1015 op=0: meta_back_getconn[0] Apr 23 08:44:13 slapd[26200]: conn=1015 op=0: meta_back_getconn[1] Apr 23 08:44:13 slapd[26200]: conn=1015 op=0 meta_back_getconn: candidates=2 conn=ANON fetched Apr 23 08:44:13 slapd[26200]: conn=1015 op=0 >>> meta_back_search_start[0] Apr 23 08:44:13 slapd[26200]: conn=1015 op=0 >>> meta_search_dobind_init[0] Apr 23 08:44:13 slapd[26200]: conn=1015 op=0 <<< meta_search_dobind_init[0]=1 Apr 23 08:44:13 slapd[26200]: ==> rewrite_context_apply [depth=1] string='uid=admin,ou=rsp1,c=de,o=mno' Apr 23 08:44:13 slapd[26200]: ==> rewrite_context_apply [depth=1] res={0,'NULL'} Apr 23 08:44:13 slapd[26200]: [rw] searchBase: "uid=admin,ou=rsp1,c=de,o=mno" -> "uid=admin,ou=rsp1,c=de,o=mno" Apr 23 08:44:13 slapd[26200]: ==> rewrite_context_apply [depth=1] string='(objectClass=*)' Apr 23 08:44:13 slapd[26200]: ==> rewrite_rule_apply rule=''^uid=[0-9]{11}1,.*'' string='(objectClass=*)' [1 pass(es)] Apr 23 08:44:13 slapd[26200]: ==> rewrite_context_apply [depth=1] res={0,'(objectClass=*)'} Apr 23 08:44:13 slapd[26200]: [rw] searchFilter: "(objectClass=*)" -> "(objectClass=*)" Apr 23 08:44:13 slapd[26200]: conn=1015 op=0 <<< meta_back_search_start[0]=1 Apr 23 08:44:13 slapd[26200]: conn=1015 op=0 >>> meta_back_search_start[1] Apr 23 08:44:13 slapd[26200]: conn=1015 op=0 >>> meta_search_dobind_init[1] Apr 23 08:44:13 slapd[26200]: conn=1015 op=0 <<< meta_search_dobind_init[1]=1 Apr 23 08:44:13 slapd[26200]: ==> rewrite_context_apply [depth=1] string='uid=admin,ou=rsp1,c=de,o=mno' Apr 23 08:44:13 slapd[26200]: ==> rewrite_context_apply [depth=1] res={0,'NULL'} Apr 23 08:44:13 slapd[26200]: [rw] searchBase: "uid=admin,ou=rsp1,c=de,o=mno" -> "uid=admin,ou=rsp1,c=de,o=mno" Apr 23 08:44:13 slapd[26200]: ==> rewrite_context_apply [depth=1] string='(objectClass=*)' Apr 23 08:44:13 slapd[26200]: ==> rewrite_rule_apply rule=''^uid=[0-9]{11}2,.*'' string='(objectClass=*)' [1 pass(es)] Apr 23 08:44:13 slapd[26200]: ==> rewrite_context_apply [depth=1] res={0,'(objectClass=*)'} Apr 23 08:44:13 slapd[26200]: [rw] searchFilter: "(objectClass=*)" -> "(objectClass=*)" Apr 23 08:44:13 slapd[26200]: conn=1015 op=0 <<< meta_back_search_start[1]=1 Apr 23 08:44:13 slapd[26200]: conn=1015 op=0 meta_back_search: ncandidates=2 cnd="**" Apr 23 08:44:13 slapd[26200]: daemon: activity on 1 descriptor Apr 23 08:44:13 slapd[26200]: daemon: activity on: Apr 23 08:44:13 slapd[26200]: Apr 23 08:44:13 slapd[26200]: daemon: epoll: listen=8 active_threads=0 tvp=zero Apr 23 08:44:13 slapd[26200]: daemon: epoll: listen=9 active_threads=0 tvp=zero Apr 23 08:44:13 slapd[26200]: conn=1015 op=0 meta_back_search[0] match="" err=32 (No such object). Apr 23 08:44:13 slapd[26200]: conn=1015 op=0 meta_back_search[1] match="" err=32 (No such object). Apr 23 08:44:13 slapd[26200]: send_ldap_result: conn=1015 op=0 p=3 Apr 23 08:44:13 slapd[26200]: send_ldap_result: err=32 matched="ou=rsp1,c=de,o=mno" text="" Apr 23 08:44:13 slapd[26200]: conn=1015 op=0 meta_back_bind: no target for dn "uid=admin,ou=rsp1,c=de,o=mno" (32).

3 2

ldap with TLS
by Rodney Simioni 24 Apr '13

24 Apr '13

Hi, I'm getting a weird behavior in LDAP with TLS. Using: openldap Linux Red Hat Sssd Nslcd When I issue a ' ldapsearch -x ZZ', it works flawlessly but when issue a `getent passwd`, I get back the system users in /etc/passwd file but I don't see the ldap users. The openldap.log indicates the following when I issue the 'getent passwd' command connection_read(14): TLS accept failure error=-1 id=1037 But it does not give any errors when doing the ldapsearch -x ZZ. So, if I have TLS not correctly configured, shouldn't it not work completely? Here's my sssd.conf: [domain/local] debug_level = 9 ldap_id_use_start_tls = True cache_credentials = True ldap_search_base = dc=wh,dc=local id_provider = ldap auth_provider = ldap chpass_provider = ldap ldap_uri = ldap://127.0.0.1/ ldap_tls_cacert = /certs/cacert.pem [sssd] services = nss, pam config_file_version = 2 domains = local [nss] [pam] [sudo] [autofs] [ssh] Here's my nslcd.conf: uri ldap://127.0.0.1/ base dc=wh,dc=local ssl start_tls tls_cacertfile /certs/cacert.pem tls_reqcert hard Here's my /etc/openldap/ldap.conf: TLS_CACERT /certs/cacert.pem TLS_REQCERT hard URI ldap://127.0.0.1/ BASE dc=wh,dc=local This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, distribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Verio Inc. makes no warranty that this email is error or virus free. Thank you.

3 2

hdb and mdb have different search results/behaviour
by Juergen.Sprenger＠swisscom.com 23 Apr '13

23 Apr '13

Hi, I have running OpenDLAP 2.4.35 on Gentoo Linux and wanted to make some tests with mdb. Slapd was running fine with hdb, no problems so far. Then I exported contents via slapcat and switched config to mdb. When slapd started using mdb no users from directory were shown by 'getent passwd': ### hdb part #### # using hdb parameters database hdb dirtyread cachesize 150000 cachefree 100 idlcachesize 450000 dncachesize 100000 # slapadd from backup and run slapd with hdb backend /etc/init.d/unscd stop /etc/init.d/slapd stop rm /var/lib/openldap-data/* rm -rf /etc/openldap/slapd.d/* cp -p /etc/openldap/DB_CONFIG /var/lib/openldap-data/ cp -p /etc/openldap/slapd.conf.hdb /etc/openldap/slapd.conf su ldap -c '/usr/sbin/slapadd -f /etc/openldap/slapd.conf -l odsldap-dev.ldif' /etc/init.d/slapd start /etc/init.d/unscd start slapcat -f /etc/openldap/slapd.conf -b dc=scom | md5sum # 73850f9a3f7ff9d3d1ddb7663cd046a6 - getent passwd # all users shown, everything ok ### mdb part #### # using mdb paramters database mdb dbnosync maxsize 2094967296 searchstack 64 # slapadd from backup and run slapd with mdb backend /etc/init.d/unscd stop /etc/init.d/slapd stop rm /var/lib/openldap-data/* rm -rf /etc/openldap/slapd.d/* cp -p /etc/openldap/slapd.conf.mdb /etc/openldap/slapd.conf su ldap -c '/usr/sbin/slapadd -f /etc/openldap/slapd.conf -l odsldap-dev.ldif' /etc/init.d/slapd start /etc/init.d/unscd start slapcat -f /etc/openldap/slapd.conf -b dc=scom | md5sum # 73850f9a3f7ff9d3d1ddb7663cd046a6 - getent passwd # no users from ldap shown Am I missing something when setting up and using mdb? Both backends have exactly the same content, and so the results for searches should also be identical. Regards Jürgen Sprenger

2 1

Re: OpenLDAP 2.4.35 available
by Clément OUDOT 23 Apr '13

23 Apr '13

2013/4/1 OpenLDAP Project <project(a)openldap.org> > OpenLDAP 2.4.35 is now available for download as detailed on our download > page: > > http://www.openldap.org/software/download/ > > and should soon be available on all official mirrors: > > ftp://ftp.openldap.org/pub/OpenLDAP/MIRRORS > > This is a maintenance release and is made available for general use. > Users of OpenLDAP Software are encouraged to upgrade. > > Hi, as usual, you can find some RPMs here: http://ltb-project.org/wiki/download#openldap Clément.

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