openldap-technical April 2014

openldap-technical@openldap.org

61 participants
55 discussions

2.4.39 error when starting openldap with mdb backend
by ping-shin ching 09 Apr '14

09 Apr '14

Using openldap 2.4.39 on solaris 10 sparc box. Bdb runs without any issue. Mdb fails on startup ( described below) Snip from the slapd.conf------------------------------------- database mdbsuffix "o=vtec,c=au"rootdn "cn=manager,o=vtec,c=au"# Cleartext passwords, especially for the rootdn, should# be avoid. See slappasswd(8) and slapd.conf(5) for details.# Use of strong authentication encouraged.rootpw secret# The database directory MUST exist prior to running slapd AND# should only be accessible by the slapd and slap tools.# Mode 700 recommended.directory /data/irene/var/openldap-data-mdbmaxsize 1073741824 Get this error on startup-------------------------------------- 34628c3 1.2.36.79672281.1.13.3 (rdnMatch): 534628c3 2.5.13.1 (distinguishedNameMatch): 534628c3 matchingRuleUse: ( 2.5.13.1 NAME 'distinguishedNameMatch' APPLIES ( creatorsName $ modifiersName $ subschemaSubentry $ entryDN $ namingContexts $ aliasedObjectName $ dynamicSubtrees $ distinguishedName $ seeAlso $ olcDefaultSearchBase $ olcRootDN $ olcSchemaDN $ olcSuffix $ olcUpdateDN $ olcRelay $ member $ owner $ roleOccupant ) )534628c3 2.5.13.0 (objectIdentifierMatch): 534628c3 matchingRuleUse: ( 2.5.13.0 NAME 'objectIdentifierMatch' APPLIES ( supportedControl $ supportedExtension $ supportedFeatures $ supportedApplicationContext ) )534628c3 slapd startup: initiated.534628c3 backend_startup_one: starting "cn=config"534628c3 config_back_db_openBackend ACL: access to * by * none 534628c3 config_back_db_open: line 0: warning: cannot assess the validity of the ACL scope within backend naming context534628c3 config_back_db_open: No explicit ACL for back-config configured. Using hardcoded default534628c3 config_build_entry: "cn=config"534628c3 config_build_entry: "cn=schema"534628c3 >>> dnNormalize: <cn={0}core>534628c3 <<< dnNormalize: <cn={0}core>534628c3 config_build_entry: "cn={0}core"534628c3 config_build_entry: "olcDatabase={-1}frontend"534628c3 config_build_entry: "olcDatabase={0}config"534628c3 config_build_entry: "olcDatabase={1}mdb"534628c3 backend_startup_one: starting "o=vtec,c=au"534628c3 mdb_db_open: "o=vtec,c=au"534628c3 mdb_db_open: database "o=vtec,c=au": dbenv_open(/data/irene/var/openldap-data-mdb).534628c3 mdb_db_open: database "o=vtec,c=au": mdb_dbi_open(/data/irene/var/openldap-data-mdb/id2e) failed: MDB_BAD_TXN: Transaction cannot recover - it must be aborted (-30782).534628c3 backend_startup_one (type=mdb, suffix="o=vtec,c=au"): bi_db_open failed! (-30782)534628c3 slapd shutdown: initiated534628c3 slapd destroy: freeing system resources.534628c3 slapd stopped.

1 0

syncrepl question
by John Timon 09 Apr '14

09 Apr '14

Hey, I hope that this is a good forum for this question, if not please feel free to tell me where to go ;) I have recently inherited an existing openldap infrastructure. The LDAP tree also stores Kerberos tickets and principals. the environment is configured with a 'master' ldap server and a bunch of 'consumer' nodes all pointing to it for syncrepl. The syncrepl looks like that olcSyncrepl: {0}rid=312 provider="ldaps://<ldap master>:636/" type=refreshAndPersist interval="00:00:01:00" retry="60 30 300 +" searchbase="<base dn>" bi ndmethod=sasl saslmech=gssapi keepalive=3540:10:3 This master server needs to be decommissioned. So I have chosen one of the consumers in the environment to be the new master. And pointed all of the other consumers to use its IP in the provider field. Syncreplication appears to be working as expected. However the new master still has the original in its provider field. Is the process of promoting this new node to 'master' as simple as stopping slapd, removing the olcSyncRepl line from the hdb.ldif file and restarting slapd? Or is this more to it, I am assuming more to it, but I can't seem to verify that suspicion. Thanks -- JT Experience is what you get when you didn't get what you wanted.

1 0

回复： mirror mode question
by Eileen(=^ω^=) 09 Apr '14

09 Apr '14

Hi Michael and Dieter, Thanks for your kindly replies. In my case, I didn't use any SASL or TLS but "simple" method with operation mode of user/password authenticated. However, I need the rootpw hashed (not cleartext) and the 2 servers (master & slave) synchronized. Could you pls advise how i should modify the syncrepl part? or could you pls provide a sample of the slapd.conf file configuration? Best regards, Eileen ------------------ 原始邮件 ------------------ 发件人: "Michael Ströder";<michael(a)stroeder.com>; 发送时间: 2014年3月5日(星期三) 下午4:09 收件人: "Dieter Klünter"<dieter(a)dkluenter.de>; "openldap-technical"<openldap-technical(a)openldap.org>; 主题: Re: mirror mode & sasl question Dieter Klünter wrote: > Am Wed, 5 Mar 2014 14:38:04 +0800 > schrieb "Eileen(=^ω^=)" <123784635(a)qq.com>: >> This is Eileen from China SINAP. I am a beginner for openldap soft. I >> encountered a problem in my study on two LDAP services replication. >> I have 2 LDAP services, one name LDPA1, the other is LDAP2 . I want >> to make them synchronously in mirror mode. But when I set LDAP >> services rootpw both in hash, the 2 LDAP serivces can’t be >> synchronous. My question is >> 1. if I set my rootpw in hash, my bindmethod must be SASL? If I >> must use sasl method, can I put the sasl service in the same ldap >> service? If bindmethod=sasl then what is the saslmech should be? >> 2. If I change to sasl method, do I need change my database >> record? > > In order to use sasl, passwords must be cleartext and you should > configure an apropriate authz-regexp, see man slapd.conf(5) > You may use any sasl mechanism that you sasl framework provides. > [...] To be more precise: In order to use password-based SASL mechs the passwords have to be stored in clear-text. Well, if working with SASL and TLS (LDAPS, StartTLS) one should consider using client certs and SASL/EXTERNAL for replication. Ciao, Michael.

4 7

help with cn=config and rwm
by Alex Samad - Yieldbroker 08 Apr '14

08 Apr '14

Hi Wondering what an example rwm overlay module would look like in cn=config Trying to apply to a msad ldap backend I would like to change group to groupOfUniqueNames and attributr member to uniqueMember Thanks

1 0

dnNormalize with subsequent dnMatch on do_syncrep
by Daniel Jung 07 Apr '14

07 Apr '14

Hi, Running 2.4.37 with mdb backend. Recently I ran one of our test LDAP instance a olcLogLevel with strace and noticed the following in the log: pr 7 00:10:16 servername.com slapd[15271]: connection_get(12) Apr 7 00:10:16 servername.com slapd[15271]: connection_get(12): got connid=0 Apr 7 00:10:16 servername.com slapd[15271]: =>do_syncrepl rid=405 Apr 7 00:10:16 servername.com slapd[15271]: =>do_syncrep2 rid=405 all the entries are being normalized, 75911 Apr 7 00:05:16 servername.com slapd[15271]: >>> dnNormalize: <uid=someone,ou=People,dc=example,dc=com> 75912 Apr 7 00:05:16 servername.com slapd[15271]: <<< dnNormalize: <uid=someone2,ou=people,dc=example,dc=com> 75913 Apr 7 00:05:16 servername.com slapd[15271]: dnMatch 6 75914 Apr 7 00:05:16 servername.com slapd[15271]: dnMatch -6 75915 Apr 7 00:05:16 servername.com slapd[15271]: dnMatch -1 for each of db_syncrep2 action, could this be related to the ITS#7741? Thanks

1 0

unicodePwd
by Jean-Marc Choulet 03 Apr '14

03 Apr '14

Hello, I want to convert my client (ADSI and C++) for use OpenLDAP. I know I must encode the unicodePwd. With ADSI, Miscrosoft give me some functions to do that. How can I do same things from OpenLDAP ? Thanks, Jean-Michel

3 3

Converting from slapd.d back to slapd.conf
by Sven Jourgensen 03 Apr '14

03 Apr '14

Is there a tool to perform the reverse operation, and convert the newer cn=config configuration back into a slapd.conf? Thanks. s.

9 17

LDAPS: ldapsearch working, back-ldap failing?
by Mitchell Im 03 Apr '14

03 Apr '14

Hi there, After several hours of beating on this (including multiple searches over the general internet and the mailing list), I've hit a dead end. So, I've decided to ask the experts, since it may require poking idassert-bind, which is pretty opaque to me (I can only partially understand the man page). Here's the problem: I'm setting up OpenLDAP as a proxy to another LDAP server (Active Directory, if it matters). I'm able to perform an ldapsearch against the backend LDAP server via ldaps://. The OpenLDAP proxy works if it connects to the backend LDAP server via ldap://. The OpenLDAP proxy does *not* work if it connects to the backend LDAP server via ldaps://, though. What am I missing? This is on CentOS 6.5, packages openldap-servers-2.4.23-34.el6_5.1.x86_64, nss-3.15.3-6.el6_5.x86_64 (Red Hat's decision). ======================================== * Backend LDAP server, ldaps:// $ ldapsearch -x -W -D 'cn=bindbot,cn=users,dc=domain,dc=local' -H ldaps://ad.domain.local -b 'dc=domain,dc=local' 'uid=bindbot' Enter LDAP Password: # extended LDIF # # LDAPv3 # base <dc=domain,dc=local> with scope subtree # filter: uid=bindbot # requesting: ALL # # BindBot, Users, domain.local dn: CN=BindBot,CN=Users,DC=domain,DC=local ... .. . ======================================== * OpenLDAP server, connecting to the backend via ldap:// $ ldapsearch -x -W -D 'cn= bindbot,cn=users,dc=domain,dc=local' -H ldaps://openldap.domain.local -b 'dc=domain,dc=local' 'uid=bindbot' Enter LDAP Password: # extended LDIF # # LDAPv3 # base <dc=domain,dc=local> with scope subtree # filter: uid=bindbot # requesting: ALL # # BindBot, Users, domain.local dn: cn=BindBot,cn=Users,dc=domain,dc=local ... .. . ======================================== * OpenLDAP server, connecting to the backend via ldaps:// (adding only the s to olcDbURI's ldap:// connection) $ ldapsearch -x -W -D 'cn= bindbot,cn=users,dc=domain,dc=local' -H ldaps://openldap.domain.local -b 'dc=domain,dc=local' 'uid=bindbot' Enter LDAP Password: ldap_bind: Server is unavailable (52) additional info: Proxy operation retry failed ======================================== * LDIF specifying the backend: dn: olcDatabase={2}ldap objectClass: olcDatabaseConfig objectClass: olcLDAPConfig olcDatabase: {2}ldap olcSuffix: cn=users,dc=domain,dc=local olcSubordinate: TRUE olcAccess: {0}to dn.subtree="dc=domain,dc=local" by * read olcDbURI: "ldap://ad.domain.local" olcDbIDAssertBind: bindmethod=simple binddn="cn=bindbot,cn=users,dc=domain,dc= local" credentials="********" tls_cacert=/etc/openldap/certs/ad.crt olcDbIDAssertAuthzFrom: * olcDbRebindAsUser: TRUE ======================================== * Snippet of /var/log/ldaplog (olcLogLevel 65535): Mar 30 21:21:37 openldap slapd[14645]: daemon: activity on 1 descriptor Mar 30 21:21:37 openldap slapd[14645]: daemon: activity on: Mar 30 21:21:37 openldap slapd[14645]: Mar 30 21:21:37 openldap slapd[14645]: slap_listener_activate(9): Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=7 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=8 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=9 busy Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=10 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=11 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: >>> slap_listener(ldaps:///) Mar 30 21:21:37 openldap slapd[14645]: daemon: listen=9, new connection on 15 Mar 30 21:21:37 openldap slapd[14645]: daemon: activity on 1 descriptor Mar 30 21:21:37 openldap slapd[14645]: daemon: activity on: Mar 30 21:21:37 openldap slapd[14645]: Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=7 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=8 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=9 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=10 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=11 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: daemon: added 15r (active) listener=(nil) Mar 30 21:21:37 openldap slapd[14645]: daemon: activity on 1 descriptor Mar 30 21:21:37 openldap slapd[14645]: daemon: activity on: Mar 30 21:21:37 openldap slapd[14645]: conn=1000 fd=15 ACCEPT from IP=10.0.0.202:40342 (IP=0.0.0.0:636) Mar 30 21:21:37 openldap slapd[14645]: Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=7 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=8 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=9 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=10 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=11 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: daemon: activity on 1 descriptor Mar 30 21:21:37 openldap slapd[14645]: daemon: activity on: Mar 30 21:21:37 openldap slapd[14645]: 15r Mar 30 21:21:37 openldap slapd[14645]: Mar 30 21:21:37 openldap slapd[14645]: daemon: read active on 15 Mar 30 21:21:37 openldap slapd[14645]: connection_get(15) Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=7 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=8 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: connection_get(15): got connid=1000 Mar 30 21:21:37 openldap slapd[14645]: connection_read(15): checking for input on id=1000 Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=9 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=10 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=11 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: daemon: activity on 1 descriptor Mar 30 21:21:37 openldap slapd[14645]: daemon: activity on: Mar 30 21:21:37 openldap slapd[14645]: Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=7 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=8 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=9 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=10 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=11 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: daemon: activity on 1 descriptor Mar 30 21:21:37 openldap slapd[14645]: daemon: activity on: Mar 30 21:21:37 openldap slapd[14645]: 15r Mar 30 21:21:37 openldap slapd[14645]: Mar 30 21:21:37 openldap slapd[14645]: daemon: read active on 15 Mar 30 21:21:37 openldap slapd[14645]: connection_get(15) Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=7 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=8 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=9 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=10 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=11 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: connection_get(15): got connid=1000 Mar 30 21:21:37 openldap slapd[14645]: connection_read(15): checking for input on id=1000 Mar 30 21:21:37 openldap slapd[14645]: connection_read(15): unable to get TLS client DN, error=49 id=1000 Mar 30 21:21:37 openldap slapd[14645]: conn=1000 fd=15 TLS established tls_ssf=256 ssf=256 Mar 30 21:21:37 openldap slapd[14645]: daemon: activity on 1 descriptor Mar 30 21:21:37 openldap slapd[14645]: daemon: activity on: Mar 30 21:21:37 openldap slapd[14645]: Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=7 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=8 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=9 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=10 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=11 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: daemon: activity on 1 descriptor Mar 30 21:21:37 openldap slapd[14645]: daemon: activity on: Mar 30 21:21:37 openldap slapd[14645]: 15r Mar 30 21:21:37 openldap slapd[14645]: Mar 30 21:21:37 openldap slapd[14645]: daemon: read active on 15 Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=7 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=8 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=9 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=10 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=11 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: connection_get(15) Mar 30 21:21:37 openldap slapd[14645]: connection_get(15): got connid=1000 Mar 30 21:21:37 openldap slapd[14645]: connection_read(15): checking for input on id=1000 Mar 30 21:21:37 openldap slapd[14645]: op tag 0x60, time 1396239697 Mar 30 21:21:37 openldap slapd[14645]: daemon: activity on 1 descriptor Mar 30 21:21:37 openldap slapd[14645]: daemon: activity on: Mar 30 21:21:37 openldap slapd[14645]: Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=7 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=8 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=9 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=10 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=11 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: conn=1000 op=0 do_bind Mar 30 21:21:37 openldap slapd[14645]: >>> dnPrettyNormal: <cn=bindbot,cn=users,dc=domain,dc=local> Mar 30 21:21:37 openldap slapd[14645]: <<< dnPrettyNormal: <cn=bindbot,cn=users,dc=domain,dc=local>, <cn=bindbot,cn=users,dc=domain,dc=local> Mar 30 21:21:37 openldap slapd[14645]: conn=1000 op=0 BIND dn="cn=bindbot,cn=users,dc=domain,dc=local" method=128 Mar 30 21:21:37 openldap slapd[14645]: do_bind: version=3 dn="cn=bindbot,cn=users,dc=domain,dc=local" method=128 Mar 30 21:21:37 openldap slapd[14645]: [rw] bindDN: "cn=bindbot,cn=users,dc=domain,dc=local" -> "cn=bindbot,cn=users,dc=domain,dc=local" Mar 30 21:21:37 openldap slapd[14645]: send_ldap_result: conn=1000 op=0 p=3 Mar 30 21:21:37 openldap slapd[14645]: send_ldap_result: err=52 matched="" text="Proxy operation retry failed" Mar 30 21:21:37 openldap slapd[14645]: send_ldap_response: msgid=1 tag=97 err=52 Mar 30 21:21:37 openldap slapd[14645]: conn=1000 op=0 RESULT tag=97 err=52 text=Proxy operation retry failed Mar 30 21:21:37 openldap slapd[14645]: daemon: activity on 1 descriptor Mar 30 21:21:37 openldap slapd[14645]: daemon: activity on: Mar 30 21:21:37 openldap slapd[14645]: 15r Mar 30 21:21:37 openldap slapd[14645]: Mar 30 21:21:37 openldap slapd[14645]: daemon: read active on 15 Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=7 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=8 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=9 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=10 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=11 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: connection_get(15) Mar 30 21:21:37 openldap slapd[14645]: connection_get(15): got connid=1000 Mar 30 21:21:37 openldap slapd[14645]: connection_read(15): checking for input on id=1000 Mar 30 21:21:37 openldap slapd[14645]: ber_get_next on fd 15 failed errno=0 (Success) Mar 30 21:21:37 openldap slapd[14645]: connection_read(15): input error=-2 id=1000, closing. Mar 30 21:21:37 openldap slapd[14645]: connection_closing: readying conn=1000 sd=15 for close Mar 30 21:21:37 openldap slapd[14645]: daemon: activity on 1 descriptor Mar 30 21:21:37 openldap slapd[14645]: daemon: activity on: Mar 30 21:21:37 openldap slapd[14645]: Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=7 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=8 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=9 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=10 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: daemon: epoll: listen=11 active_threads=0 tvp=zero Mar 30 21:21:37 openldap slapd[14645]: connection_close: conn=1000 sd=15 Mar 30 21:21:37 openldap slapd[14645]: =>ldap_back_conn_destroy: fetching conn 1000 Mar 30 21:21:37 openldap slapd[14645]: daemon: removing 15 Mar 30 21:21:37 openldap slapd[14645]: conn=1000 fd=15 closed (connection lost) ======================================== * Other miscellaneous information: - /etc/openldap/ldap.conf also sets TLS_CACERT, /etc/openldap/certs/ad.crt, the CA public PEM. - The "unable to get TLS client DN, error=49 id=1000" error happens whether OpenLDAP attempts to connect to the backend LDAP server via ldap:// or ldaps://. - Adding tls_reqcert=allow to olcDbIDAssertBind doesn't help. - Explicitly specifying :636 doesn't help.

2 2

Hashed Entries
by Monica Warnock 03 Apr '14

03 Apr '14

Hi Can I please ask the relevance of the results of my ldapsearch command: ldapsearch -x -LLL -b dc=/name///=/name / dn: dc=/name/__,dc=/name/// objectClass: dcObject objectClass: organization dc:: ZGxpYi1tb25pZHAg o:: ZGxpYi1tb25pZHAg dn: ou=Users,dc=/name///,dc=/name/ objectClass: organizationalUnit ou: Users dn: cn=Bob Jones,ou=Users,dc=/name///,dc=/name/ cn: Bob Jones sn: Jones objectClass: inetOrgPerson objectClass: eduPerson eduPersonAffiliation: staff userPassword:: cGFzc3dvcmQg uid: bjones When I log in as bjones using the correct password the 'username or password is not valid'. What is the relevance of the entries such as the userPassword:: which now appear with two colons? I have added more test users and on their entry the uid entry also has the double colons with a hashed entry following. Thanks in advance. Monica -- *Monica Warnock* UK Access Management Federation for Education and Research EDINA Causewayside House, 160 Causewayside, Edinburgh EH9 1PR *t:* 0131 651 7721 *f:* 0131 650 3308 *e:* monica.warnock(a)ed.ac.uk The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

5 6

dhcp.schema attribute dhcpStatements value in filter
by Zeus Panchenko 02 Apr '14

02 Apr '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 hi, I configured my isc-dhcpd servers to work with openldap, all works now when I want to find dn for some definite MAC or IP, I am unable to do that please, help to understand how can I ldapsearch by attribute dhcpStatements values? in dhcp.schema it is written: - ---[ quotation start ]------------------------------------------- ... attributetype ( 2.16.840.1.113719.1.203.4.3 NAME 'dhcpStatements' EQUALITY caseIgnoreIA5Match DESC 'Flexible storage for specific data depending on what object this exists in. Like conditional statements, server parameters, etc. This allows the standard to evolve without needing to adjust the schema.' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) ... - ---[ quotation end ]------------------------------------------- so, when I use filter "(&(objectClass=dhcpHost)(dhcpStatements=*))" I successfully receive all objects but lets say I need to find this object: - ---[ quotation start ]------------------------------------------- dn: cn=ap01,cn=10.0.0.0,cn=officeXXX DHCP Config,ou=officeXXX,ou=DHCP, dc=allstuff cn: ap01 objectClass: top objectClass: dhcpHost dhcpHWAddress: ethernet 20:cf:30:88:5d:18 dhcpStatements: fixed-address 10.0.0.222 - ---[ quotation end ]------------------------------------------- I use filter: "(&(objectClass=dhcpHost)(dhcpStatements=fixed-address 10.0.0.222))" and receive empty result ... it is the same picture for anything except dhcpStatements=* ... so, how is it correct to write the filter to get all objects with IP like 10.0.0.2* ? - -- Zeus V. Panchenko jid:zeus@im.ibs.dn.ua IT Dpt., I.B.S. LLC GMT+2 (EET) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlM6y1sACgkQr3jpPg/3oyqPvQCgq6w8K53fw+6zrsSLbI72sbMR 5k8AoOh0wWlYmeQyyNKfngyMQrP3TXrt =KYZt -----END PGP SIGNATURE-----

3 9

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical April 2014