openldap-technical February 2014

openldap-technical@openldap.org

85 participants
90 discussions

ldap/pwd complexity and PAM?
by Doug OLeary 15 Feb '14

15 Feb '14

Hi; In my free time, I've been studying openldap and the ppolicy overlay. I started working on password complexity today. While searching for information on implementing complexity, I ran across the link immediately following which seems to indicate that openldap honors the settings in /etc/pam.d/password-auth. http://ubuntuforums.org/showthread.php?t=2172393 I tried configuring that on a test kvm and can't even get it working with local accounts so obviously I borked something in the password-auth file - like maybe not even the right pam.d file; however, before I spend a whole lot of time troubleshooting this, is my understanding accurate? Will openldap honor the settings in pam.d? It seems that'd be a whole lot cleaner and more supportable than compiling a specialized password checking module. Any info greatly appreciated. Thanks for your time. Doug O'Leary ------------ Senior UNIX/Security Admin CISSP, CISA, RHCSA, CEH O'Leary Computers Inc dkoleary(a)olearycomputers.com (w) 630-904-6098 (c) 630-248-2749 linkedin: http://www.linkedin.com/in/dkoleary resume: http://www.olearycomputers.com/resume.html

3 3

MIT Kerberos and LDAP Backend Passwords synchronization
by Abdelkader Chelouah 13 Feb '14

13 Feb '14

Hello all, I configured a KDC (MIT Kerberos 1.12.1) with an OpenLDAP (2.4.32) Backend. Everything is working fine. We want to migrate smoothly from LDAP password to KDC password. For that purpose, we plan to force user to change their password using ldappasswd command, intercept the password modification with smbkrb5pwd overlay and then change the userPassword attribute for SASL passthrough. I setup up the overlay smbkrb5pwd (last git version) to synchronized LDAP and Kerberos passwords as decribed on https://github.com/opinsys/smbkrb5pwd The module is loaded correctly. However, the "ldappasswd" command hangs now. This is apparently due to a locking issue. Is anyone succeeded to configure the overlay ? Is there any other way to synchronize LDAP et KDC passwords when OpenLDAP is used as a Backend ?

3 4

LDAP proxy and memberOf overlay
by Ingo Mailinglists 13 Feb '14

13 Feb '14

Hi List, I am currently stuck with setting up OpenLDAP servers to fully address my use case. I hope someone here can point me in the right direction. I think it comes down to the point at where I do not know how to use the memberOf overlay with an LDAP proxy (back_ldap). First the use case: * I have a corporate OpenLDAP server that holds entries for our employees * There are also multiple http-based services which are allowed to be used after successful user authentication and given that group membership requirements are met. * The http-based services need to be accessed by both internal employees (those for which entries are stored in the corporate OpenLDAP server) and external people (for which there are no user entries yet). The task is to come up with an approach that supports the following: * allow the http-based services to authenticate both internal and external users against an OpenLDAP server * allow authorization based on group memberships * entries that represent external people are not allowed to be stored in the existing corporate OpenLDAP server * entries that represent group memberships are not allowed to be stored in the existing corporate OpenLDAP server * in general, no changes to the corporate OpenLDAP server are allowed at all Here is my approach so far: * I have set up a new OpenLDAP server with two databases. * The first is a local hdb database. The suffix is set to a subordinate of the corporate OpenLDAP server. * The second is a ldap database, which points to and has the same suffix as the corporate OpenLDAP server. The purpose of the local hdb database is twofold * it should store entries for external people * it should store the group memberships for both external people and employees from my own company I did some tests with Apache 2.2.22, mod_ldap and mod_authnz_ldap. I can authenticate both types of users (external from hdb and internal from ldap). I can even authorize them based on their group membership (using groupOfNames stored in the local hdb database). The group membership check also works for user entries that are proxied via the ldap database backend. However, the approach fails for services that need the memberOf overlay for making authorization decisions based on group membership (ownCloud is such an example). I have enabled the memberOf overlay for the local hdb database. So external users are not the problem. However, I cannot enable it for the ldap database, as I am not allowed to make any changes to the user entries of the corporate OpenLDAP server. That is, I am not allowed to add the memberOf attribute to the respective entries - even if ACLs would allow me to do so. Now this is the point where I am stuck. Basically, I am looking for a way to add the memberOf attribute to proxied user entries locally on my new OpenLDAP server, without affecting the entries in the corporate OpenLDAP server. Any help that might point me in the right direction is highly appreciated. Thanks, Ingo

3 2

k5start
by Brendan Kearney 13 Feb '14

13 Feb '14

i am looking to move away from credentials in my configs, and want to use k5start to maintain the kerberos ticket for replication. i am wondering if any folks here are using k5start to do this, in addition to using k5start on the same machine to maintain tickets for other processes? nslcd is one example that would use k5start to maintain the kerberos ticket. is anyone using k5start to maintain tickets for more than one process, on one machine?

1 0

Proper way to configure custom schemas
by Nerijus Kislauskas 13 Feb '14

13 Feb '14

Hi, What is a proper set of actions to add attribute via cn=config to custom schema, also add attribute to custom objectclass? My way: 1. Add attribute 2. Delete old objectlass definition 3. Add new objectClass with new attribute included What if I have 100 objectClasses, and want replace only 1? I am in trouble to do this on Debian wheezy, slapd 2.4.31. My test.ldif: ------------------------------------------ dn: cn={8}ktuEduPerson,cn=schema,cn=config changetype: modify add: olcAttributeTypes olcAttributeTypes: ( ktuAttributeType:36 NAME 'macaroni' DESC 'LDAP attribute for macaroni' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSub stringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) Let's add the attribute: $ ldapmodify ... -f test.ldif Enter LDAP Password: modifying entry "cn={8}ktuEduPerson,cn=schema,cn=config" ldap_modify: No such object (32) $ Ooops, something went wrong, but cn=config sees this attribute: $ ldapsearch ... "cn={8}ktuEduPerson,cn=schema,cn=config" | grep macaroni Enter LDAP Password: olcAttributeTypes: {41}( ktuAttributeType:36 NAME 'macaroni' DESC 'LDAP ... $ But in case of VM/slapd restart, my macaroni attribute will be gone: $ sudo grep -iR macaroni /etc/ldap/slapd.d/ $ Access rights of process and config files are ok. Changing lets say olcLogLevel works fine, config is synced. Am I the only one in the world facing this problem? Or I should fill 69th bug on slapd in Debian? Is slapd package usable in Debian for something bigger than kindergarden? And yes, I know about "Why is using the OpenLDAP server from a Linux distribution not recommended?". -- Sincerely, Nerijus Kislauskas KTU ITD, Litnet valdymo centras Studentu g. 48a - 101, Kaunas tel.: (8~37) 30 06 45 mob. tel.: 8-614-93889 e-mail.: nerijus.kislauskas(a)ktu.lt

4 6

slapo-accesslog
by Michael 13 Feb '14

13 Feb '14

I'm trying to configure a means to be able to get the lastlogin time for users in my environment. However, since I'm stuck using the RHEL version of OpenLDAP I can't take advantage of the "lastbind overlay" Here's my config. overlay accesslog logdb cn=accesslog logops bind logsuccess TRUE # scan the accesslog DB every day, and purge entries older than 90 days logpurge 90+00:00 01+00:00 The accesslog DB is populated and I can query for BIND operations, however the only BIND operations that get recorded are BINDS to the LDAP server itself. BINDS to clients do not get recorded in the accesslog. Is this the advertised behavior of the accesslog? -Mike

4 5

Syncrepl and mmr
by Borresen, John - 0442 - MITLL 12 Feb '14

12 Feb '14

All, Hope I am not persona non grata (that is supposed to be funny) based on the responses I received from my last post earlier today. Tomorrow I am starting from scratch...I have one week to get this working -- afraid to find out what will happen after that. Anyway, I've increased the syslog verbosity on both servers. mm-server1: 52fbefc2 <= send_search_entry: conn 1013 exit. 52fbefc2 => test_filter 52fbefc2 PRESENT 52fbefc2 => access_allowed: search access to "reqStart=20140211203819.000000Z,cn=accesslog" "objectClass" requested 52fbefc2 => acl_get: [1] attr objectClass 52fbefc2 => acl_mask: access to entry "reqStart=20140211203819.000000Z,cn=accesslog", attr "objectClass" requested 52fbefc2 => acl_mask: to all values by "cn=ldapadmin,dc=group42,dc=ldap", (=0) 52fbefc2 <= check a_dn_pat: uid=replicator,ou=admins,dc=group42,dc=ldap 52fbefc2 <= check a_dn_pat: cn=ldapadmin,dc=group42,dc=ldap 52fbefc2 <= acl_mask: [2] applying write(=wrscxd) (stop) 52fbefc2 <= acl_mask: [2] mask: write(=wrscxd) 52fbefc2 => slap_access_allowed: search access granted by write(=wrscxd) 52fbefc2 => access_allowed: search access granted by write(=wrscxd) 52fbefc2 <= test_filter 6 52fbefc2 => send_search_entry: conn 1013 dn="reqStart=20140211203819.000000Z,cn=accesslog" 52fbefc2 => access_allowed: read access to "reqStart=20140211203819.000000Z,cn=accesslog" "entry" requested 52fbefc2 => acl_get: [1] attr entry 52fbefc2 => acl_mask: access to entry "reqStart=20140211203819.000000Z,cn=accesslog", attr "entry" requested 52fbefc2 => acl_mask: to all values by "cn=ldapadmin,dc=group42,dc=ldap", (=0) 52fbefc2 <= check a_dn_pat: uid=replicator,ou=admins,dc=group42,dc=ldap 52fbefc2 <= check a_dn_pat: cn=ldapadmin,dc=group42,dc=ldap 52fbefc2 <= acl_mask: [2] applying write(=wrscxd) (stop) 52fbefc2 <= acl_mask: [2] mask: write(=wrscxd) 52fbefc2 => slap_access_allowed: read access granted by write(=wrscxd) 52fbefc2 => access_allowed: read access granted by write(=wrscxd) 52fbefc2 => access_allowed: result not in cache (reqType) 52fbefc2 => access_allowed: read access to "reqStart=20140211203819.000000Z,cn=accesslog" "reqType" requested 52fbefc2 => acl_get: [1] attr reqType 52fbefc2 => acl_mask: access to entry "reqStart=20140211203819.000000Z,cn=accesslog", attr "reqType" requested 52fbefc2 => acl_mask: to value by "cn=ldapadmin,dc=group42,dc=ldap", (=0) 52fbefc2 <= check a_dn_pat: uid=replicator,ou=admins,dc=group42,dc=ldap 52fbefc2 <= check a_dn_pat: cn=ldapadmin,dc=group42,dc=ldap 52fbefc2 <= acl_mask: [2] applying write(=wrscxd) (stop) 52fbefc2 <= acl_mask: [2] mask: write(=wrscxd) 52fbefc2 => slap_access_allowed: read access granted by write(=wrscxd) 52fbefc2 => access_allowed: read access granted by write(=wrscxd) 52fbefc2 => access_allowed: result not in cache (reqDN) 52fbefc2 => access_allowed: read access to "reqStart=20140211203819.000000Z,cn=accesslog" "reqDN" requested 52fbefc2 => acl_get: [1] attr reqDN 52fbefc2 => acl_mask: access to entry "reqStart=20140211203819.000000Z,cn=accesslog", attr "reqDN" requested 52fbefc2 => acl_mask: to value by "cn=ldapadmin,dc=group42,dc=ldap", (=0) 52fbefc2 <= check a_dn_pat: uid=replicator,ou=admins,dc=group42,dc=ldap 52fbefc2 <= check a_dn_pat: cn=ldapadmin,dc=group42,dc=ldap 52fbefc2 <= acl_mask: [2] applying write(=wrscxd) (stop) 52fbefc2 <= acl_mask: [2] mask: write(=wrscxd) 52fbefc2 => slap_access_allowed: read access granted by write(=wrscxd) 52fbefc2 => access_allowed: read access granted by write(=wrscxd) 52fbefc2 => access_allowed: result not in cache (reqMod) 52fbefc2 => access_allowed: read access to "reqStart=20140211203819.000000Z,cn=accesslog" "reqMod" requested 52fbefc2 => acl_get: [1] attr reqMod 52fbefc2 => acl_mask: access to entry "reqStart=20140211203819.000000Z,cn=accesslog", attr "reqMod" requested 52fbefc2 => acl_mask: to value by "cn=ldapadmin,dc=group42,dc=ldap", (=0) 52fbefc2 <= check a_dn_pat: uid=replicator,ou=admins,dc=group42,dc=ldap 52fbefc2 <= check a_dn_pat: cn=ldapadmin,dc=group42,dc=ldap 52fbefc2 <= acl_mask: [2] applying write(=wrscxd) (stop) 52fbefc2 <= acl_mask: [2] mask: write(=wrscxd) 52fbefc2 => slap_access_allowed: read access granted by write(=wrscxd) 52fbefc2 => access_allowed: read access granted by write(=wrscxd) 52fbefc2 => access_allowed: result was in cache (reqMod) 52fbefc2 => access_allowed: result was in cache (reqMod) 52fbefc2 => access_allowed: result was in cache (reqMod) 52fbefc2 => access_allowed: result not in cache (entryCSN) 52fbefc2 => access_allowed: read access to "reqStart=20140211203819.000000Z,cn=accesslog" "entryCSN" requested 52fbefc2 => acl_get: [1] attr entryCSN 52fbefc2 => acl_mask: access to entry "reqStart=20140211203819.000000Z,cn=accesslog", attr "entryCSN" requested 52fbefc2 => acl_mask: to value by "cn=ldapadmin,dc=group42,dc=ldap", (=0) 52fbefc2 <= check a_dn_pat: uid=replicator,ou=admins,dc=group42,dc=ldap 52fbefc2 <= check a_dn_pat: cn=ldapadmin,dc=group42,dc=ldap 52fbefc2 <= acl_mask: [2] applying write(=wrscxd) (stop) 52fbefc2 <= acl_mask: [2] mask: write(=wrscxd) 52fbefc2 => slap_access_allowed: read access granted by write(=wrscxd) 52fbefc2 => access_allowed: read access granted by write(=wrscxd) 52fbefc2 conn=1013 op=1 ENTRY dn="reqStart=20140211203819Z,cn=accesslog" 52fbefc2 daemon: activity on 1 descriptor 52fbefc2 daemon: activity on:52fbefc2 18r52fbefc2 52fbefc2 daemon: read active on 18 52fbefc2 daemon: epoll: listen=7 active_threads=0 tvp=zero 52fbefc2 daemon: activity on 1 descriptor 52fbefc2 daemon: activity on:52fbefc2 52fbefc2 daemon: epoll: listen=7 active_threads=0 tvp=zero 52fbefc2 daemon: activity on 1 descriptor 52fbefc2 daemon: activity on:52fbefc2 52fbefc2 daemon: epoll: listen=7 active_threads=0 tvp=zero 52fbefc2 connection_get(18) 52fbefc2 connection_get(18): got connid=1013 52fbefc2 connection_read(18): checking for input on id=1013 ber_get_next ldap_read: want=8, got=7 0000: 30 05 02 01 03 42 00 0....B. ber_get_next: tag 0x30 len 5 contents: ber_dump: buf=0x76a43d0 ptr=0x76a43d0 end=0x76a43d5 len=5 0000: 02 01 03 42 00 ...B. 52fbefc2 op tag 0x42, time 1392242626 ber_get_next ldap_read: want=8, got=0 mm-server2: 52fbf12a =>do_syncrep2 rid=001 ldap_result ld 0x9715890 msgid 2 wait4msg ld 0x9715890 msgid 2 (infinite timeout) wait4msg continue ld 0x9715890 msgid 2 all 0 ** ld 0x9715890 Connections: * host: mm-server1.example.ldap port: 389 (default) refcnt: 2 status: Connected last used: Wed Feb 12 17:09:46 2014 ** ld 0x9715890 Outstanding Requests: * msgid 2, origid 2, status InProgress outstanding referrals 0, parent count 0 ld 0x9715890 request count 1 (abandoned 0) ** ld 0x9715890 Response Queue: Empty ld 0x9715890 response count 0 ldap_chkResponseList ld 0x9715890 msgid 2 all 0 ldap_chkResponseList returns ld 0x9715890 NULL ldap_int_select read1msg: ld 0x9715890 msgid 2 all 0 ber_get_next ldap_read: want=8, got=8 0000: 30 81 b2 02 01 02 64 48 0.....dH ldap_read: want=173, got=173 0000: 04 0c 63 6e 3d 61 63 63 65 73 73 6c 6f 67 30 38 ..cn=accesslog08 0010: 30 36 04 08 65 6e 74 72 79 43 53 4e 31 2a 04 28 06..entryCSN1*.( 0020: 32 30 31 34 30 32 30 33 31 38 33 38 33 31 2e 37 20140203183831.7 0030: 35 31 38 33 38 5a 23 30 30 30 30 30 30 23 30 30 51838Z#000000#00 0040: 31 23 30 30 30 30 30 30 a0 63 30 61 04 18 31 2e 1#000000.c0a..1. 0050: 33 2e 36 2e 31 2e 34 2e 31 2e 34 32 30 33 2e 31 3.6.1.4.1.4203.1 0060: 2e 39 2e 31 2e 32 04 45 30 43 0a 01 01 04 00 04 .9.1.2.E0C...... 0070: 3c 72 69 64 3d 30 30 31 2c 73 69 64 3d 30 30 31 <rid=001,sid=001 0080: 2c 63 73 6e 3d 32 30 31 34 30 32 30 33 31 38 33 ,csn=20140203183 0090: 38 33 31 2e 37 35 31 38 33 38 5a 23 30 30 30 30 831.751838Z#0000 00a0: 30 30 23 30 30 31 23 30 30 30 30 30 30 00#001#000000 ber_get_next: tag 0x30 len 178 contents: ber_dump: buf=0x9762840 ptr=0x9762840 end=0x97628f2 len=178 0000: 02 01 02 64 48 04 0c 63 6e 3d 61 63 63 65 73 73 ...dH..cn=access 0010: 6c 6f 67 30 38 30 36 04 08 65 6e 74 72 79 43 53 log0806..entryCS 0020: 4e 31 2a 04 28 32 30 31 34 30 32 30 33 31 38 33 N1*.(20140203183 0030: 38 33 31 2e 37 35 31 38 33 38 5a 23 30 30 30 30 831.751838Z#0000 0040: 30 30 23 30 30 31 23 30 30 30 30 30 30 a0 63 30 00#001#000000.c0 0050: 61 04 18 31 2e 33 2e 36 2e 31 2e 34 2e 31 2e 34 a..1.3.6.1.4.1.4 0060: 32 30 33 2e 31 2e 39 2e 31 2e 32 04 45 30 43 0a 203.1.9.1.2.E0C. 0070: 01 01 04 00 04 3c 72 69 64 3d 30 30 31 2c 73 69 .....<rid=001,si 0080: 64 3d 30 30 31 2c 63 73 6e 3d 32 30 31 34 30 32 d=001,csn=201402 0090: 30 33 31 38 33 38 33 31 2e 37 35 31 38 33 38 5a 03183831.751838Z 00a0: 23 30 30 30 30 30 30 23 30 30 31 23 30 30 30 30 #000000#001#0000 00b0: 30 30 00 read1msg: ld 0x9715890 msgid 2 message type search-entry ber_scanf fmt ({xx) ber: ber_dump: buf=0x9762840 ptr=0x9762843 end=0x97628f2 len=175 0000: 64 48 04 0c 63 6e 3d 61 63 63 65 73 73 6c 6f 67 dH..cn=accesslog 0010: 30 38 30 36 04 08 65 6e 74 72 79 43 53 4e 31 2a 0806..entryCSN1* 0020: 04 28 32 30 31 34 30 32 30 33 31 38 33 38 33 31 .(20140203183831 0030: 2e 37 35 31 38 33 38 5a 23 30 30 30 30 30 30 23 .751838Z#000000# 0040: 30 30 31 23 30 30 30 30 30 30 a0 63 30 61 04 18 001#000000.c0a.. 0050: 31 2e 33 2e 36 2e 31 2e 34 2e 31 2e 34 32 30 33 1.3.6.1.4.1.4203 0060: 2e 31 2e 39 2e 31 2e 32 04 45 30 43 0a 01 01 04 .1.9.1.2.E0C.... 0070: 00 04 3c 72 69 64 3d 30 30 31 2c 73 69 64 3d 30 ..<rid=001,sid=0 0080: 30 31 2c 63 73 6e 3d 32 30 31 34 30 32 30 33 31 01,csn=201402031 0090: 38 33 38 33 31 2e 37 35 31 38 33 38 5a 23 30 30 83831.751838Z#00 00a0: 30 30 30 30 23 30 30 31 23 30 30 30 30 30 30 0000#001#000000 ber_scanf fmt ({a) ber: ber_dump: buf=0x9762840 ptr=0x976288f end=0x97628f2 len=99 0000: 30 61 04 18 31 2e 33 2e 36 2e 31 2e 34 2e 31 2e 0a..1.3.6.1.4.1. 0010: 34 32 30 33 2e 31 2e 39 2e 31 2e 32 04 45 30 43 4203.1.9.1.2.E0C 0020: 0a 01 01 04 00 04 3c 72 69 64 3d 30 30 31 2c 73 ......<rid=001,s 0030: 69 64 3d 30 30 31 2c 63 73 6e 3d 32 30 31 34 30 id=001,csn=20140 0040: 32 30 33 31 38 33 38 33 31 2e 37 35 31 38 33 38 203183831.751838 0050: 5a 23 30 30 30 30 30 30 23 30 30 31 23 30 30 30 Z#000000#001#000 0060: 30 30 30 000 ber_scanf fmt (o) ber: ber_dump: buf=0x9762840 ptr=0x97628ab end=0x97628f2 len=71 0000: 04 45 30 43 0a 01 01 04 00 04 3c 72 69 64 3d 30 .E0C......<rid=0 0010: 30 31 2c 73 69 64 3d 30 30 31 2c 63 73 6e 3d 32 01,sid=001,csn=2 0020: 30 31 34 30 32 30 33 31 38 33 38 33 31 2e 37 35 0140203183831.75 0030: 31 38 33 38 5a 23 30 30 30 30 30 30 23 30 30 31 1838Z#000000#001 0040: 23 30 30 30 30 30 30 #000000 ldap_get_dn_ber ber_scanf fmt ({ml{) ber: ber_dump: buf=0x9762840 ptr=0x9762843 end=0x97628f2 len=175 0000: 64 48 04 0c 63 6e 3d 61 63 63 65 73 73 6c 6f 67 dH..cn=accesslog 0010: 30 38 30 36 04 08 65 6e 74 72 79 43 53 4e 31 2a 0806..entryCSN1* 0020: 04 28 32 30 31 34 30 32 30 33 31 38 33 38 33 31 .(20140203183831 0030: 2e 37 35 31 38 33 38 5a 23 30 30 30 30 30 30 23 .751838Z#000000# 0040: 30 30 31 23 30 30 30 30 30 30 a0 63 30 61 04 18 001#000000.c0a.. 0050: 31 2e 33 2e 36 2e 31 2e 34 2e 31 2e 34 32 30 33 1.3.6.1.4.1.4203 0060: 2e 31 2e 39 2e 31 2e 32 04 45 30 43 0a 01 01 04 .1.9.1.2.E0C.... 0070: 00 04 3c 72 69 64 3d 30 30 31 2c 73 69 64 3d 30 ..<rid=001,sid=0 0080: 30 31 2c 63 73 6e 3d 32 30 31 34 30 32 30 33 31 01,csn=201402031 0090: 38 33 38 33 31 2e 37 35 31 38 33 38 5a 23 30 30 83831.751838Z#00 00a0: 30 30 30 30 23 30 30 31 23 30 30 30 30 30 30 0000#001#000000 ber_scanf fmt ({em) ber: ber_dump: buf=0x9762970 ptr=0x9762970 end=0x97629b5 len=69 0000: 30 43 0a 01 01 04 00 04 3c 72 69 64 3d 30 30 31 0C......<rid=001 0010: 2c 73 69 64 3d 30 30 31 2c 63 73 6e 3d 32 30 31 ,sid=001,csn=201 0020: 34 30 32 30 33 31 38 33 38 33 31 2e 37 35 31 38 40203183831.7518 0030: 33 38 5a 23 30 30 30 30 30 30 23 30 30 31 23 30 38Z#000000#001#0 0040: 30 30 30 30 30 00000 52fbf12a do_syncrep2: rid=001 got empty syncUUID with LDAP_SYNC_ADD (cn=accesslog) ldap_msgfree ldap_free_request (origid 2, msgid 2) ldap_free_connection 1 1 ldap_send_unbind ber_flush2: 7 bytes to sd 17 0000: 30 05 02 01 03 42 00 0....B. ldap_write: want=7, written=7 0000: 30 05 02 01 03 42 00 0....B. ldap_free_connection: actually freed 52fbf12a do_syncrepl: rid=001 rc -1 retrying 52fbf12a daemon: activity on 1 descriptor 52fbf12a daemon: activity on:52fbf12a 52fbf12a daemon: epoll: listen=7 active_threads=0 tvp=zero 52fbf166 daemon: epoll: listen=7 active_threads=0 tvp=zero 52fbf166 =>do_syncrepl rid=001 ldap_create ldap_url_parse_ext(ldap://mm-server1.example.ldap) ldap_sasl_bind_s ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP mm-server1.example.ldap:389 ldap_new_socket: 17 ldap_prepare_socket: 17 ldap_connect_to_host: Trying <mm-server1_IP>:389 ldap_pvt_connect: fd: 17 tm: -1 async: 0 attempting to connect: connect success ldap_open_defconn: successful ldap_send_server_request ber_scanf fmt ({it) ber: ber_dump: buf=0x9761740 ptr=0x9761740 end=0x9761778 len=56 0000: 30 36 02 01 01 60 31 02 01 03 04 1f 63 6e 3d 6c 06...`1.....cn=l 0010: 64 61 70 61 64 6d 69 6e 2c 64 63 3d 67 72 6f 75 dapadmin,dc=exam 0020: 70 34 32 2c 64 63 3d 6c 64 61 70 80 0b 47 72 70 ple,dc=ldap..<pas 0030: 34 32 2d 41 64 6d 21 6e sword> ber_scanf fmt ({i) ber: ber_dump: buf=0x9761740 ptr=0x9761745 end=0x9761778 len=51 0000: 60 31 02 01 03 04 1f 63 6e 3d 6c 64 61 70 61 64 `1.....cn=ldapad 0010: 6d 69 6e 2c 64 63 3d 67 72 6f 75 70 34 32 2c 64 min,dc=example,d 0020: 63 3d 6c 64 61 70 80 0b 47 72 70 34 32 2d 41 64 c=ldap..<passwo 0030: 6d 21 6e rd> ber_flush2: 56 bytes to sd 17 0000: 30 36 02 01 01 60 31 02 01 03 04 1f 63 6e 3d 6c 06...`1.....cn=l 0010: 64 61 70 61 64 6d 69 6e 2c 64 63 3d 67 72 6f 75 dapadmin,dc=grou 0020: 70 34 32 2c 64 63 3d 6c 64 61 70 80 0b 47 72 70 p42,dc=ldap..<pass 0030: 34 32 2d 41 64 6d 21 6e word> ldap_write: want=56, written=56 0000: 30 36 02 01 01 60 31 02 01 03 04 1f 63 6e 3d 6c 06...`1.....cn=l 0010: 64 61 70 61 64 6d 69 6e 2c 64 63 3d 67 72 6f 75 dapadmin,dc=grou 0020: 70 34 32 2c 64 63 3d 6c 64 61 70 80 0b 47 72 70 p42,dc=ldap..<pas 0030: 34 32 2d 41 64 6d 21 6e sword> ldap_result ld 0x950ac90 msgid 1 Thanks in advance... John D. Borresen (Dave) Linux/Unix Systems Administrator MIT Lincoln Laboratory Surveillance Systems Group 244 Wood St Lexington, MA 02420 Email: john.borresen(a)ll.mit.edu<mailto:john.borresen@ll.mit.edu>

2 1

rwm overlay causes slapd segfault
by Jarbas Peixoto Júnior 12 Feb '14

12 Feb '14

Needed to enable authentication on ldap server via the mail attribute. I used the overlay rwm as documentation: * Http://www.openldap.org/doc/admin24/overlays.html # Rewrite / Remap * http://www.openldap.org/lists/openldap-software/200707/msg00487.html * http://www.openldap.org/software/man.cgi?query=slapo-rwm&sektion=5&apropos=… I run the current version of OpenLDAP : dpkg -l | grep openldap ii openldap-ltb 2.4.39-1 amd64 OpenLDAP server with addons from the LDAP Tool Box project ii openldap-ltb-check-password 2.4.39-1 amd64 check_password module for password policy ii openldap-ltb-contrib-overlays 2.4.39-1 amd64 Overlays contributed to OpenLDAP My configuration snippet is shown below : ... backend hdb moduleload rwm overlay rwm rwm-rewriteEngine on rwm-rewriteMap ldap attr2dn "ldaps:///dc=gov,dc=br?dn?sub?" rwm-rewriteContext bindDN rwm-rewriteRule "^mail=[^,]+@[^,]+$" "${attr2dn($0)}" ":@I" database hdb ... Everything worked fine , but sometimes occurred a ' slapd segfault " there was no apparent cause . A log analysis allowed us to identify the query that caused the "crash " was the folder containing " ** " as follows : "(mail=*name**surname*)(mailAlternateAddress=*name**surname*)" Redid several searches and this is really "crash " in some situations : Normal ======= ldapsearch -xLLL -H ldaps://www-linuxprev -b dc=gov,dc=br "(uid=jarbas*peixoto)" mail dn: uid=jarbas.peixoto,ou=URMS,ou=SUAT,ou=DRD,ou=DATAPREV,dc=gov,dc=br mail: jarbas.peixoto(a)dataprev.gov.br Normal ======= ldapsearch -xLLL -H ldaps://www-linuxprev -b dc=gov,dc=br "(uid=jarbas**peixoto)" mail ldap_search_ext: Bad search filter (-7) Normal ======= ldapsearch -xLLL -H ldaps://www-linuxprev -b dc=gov,dc=br "(mail=jarbas*peixoto(a)dataprev.gov.br)" mail dn: uid=jarbas.peixoto,ou=URMS,ou=SUAT,ou=DRD,ou=DATAPREV,dc=gov,dc=br mail: jarbas.peixoto(a)dataprev.gov.br Normal ======= ldapsearch -xLLL -H ldaps://www-linuxprev -b dc=gov,dc=br "(mail=jarbas**peixoto(a)dataprev.gov.br)" mail ldap_search_ext: Bad search filter (-7) Segfault - Note that there is a space between the two asterisks ( "* *" ) ================================================================ ldapsearch -xLLL -H ldaps://www-linuxprev -b dc=gov,dc=br "(mail=jarbas* *peixoto(a)dataprev.gov.br)" mail Additional information: massaged filter parse error The excerpts from server logs are: Feb 12 09:49:18 linuxprev slapd[27108]: conn=1004 fd=19 ACCEPT from IP=10.82.0.22:46996 (IP=0.0.0.0:636) Feb 12 09:49:18 linuxprev slapd[27108]: conn=1004 fd=19 TLS established tls_ssf=128 ssf=128 Feb 12 09:49:18 linuxprev slapd[27108]: conn=1004 op=0 BIND dn="" method=128 Feb 12 09:49:18 linuxprev slapd[27108]: conn=1004 op=0 RESULT tag=97 err=0 text= Feb 12 09:49:18 linuxprev slapd[27108]: conn=1004 op=1 SRCH base="dc=gov,dc=br" scope=2 deref=0 filter="(mail=jarbas**peixoto(a)dataprev.gov.br)" Feb 12 09:49:18 linuxprev slapd[27108]: conn=1004 op=1 SRCH attr=mail Feb 12 09:49:18 linuxprev slapd[27108]: conn=1004 op=1 SEARCH RESULT tag=101 err=0 nentries=0 text=massaged filter parse error Feb 12 09:49:18 linuxprev kernel: [19683068.279488] slapd[27112] general protection ip:7f9c3520cac9 sp:7f9bc9eb2960 error:0 in libc-2.13.so[7f9c35191000+182000] To work around this error I added the lines: # Remove os '**" da pesquisa 'mail=**' evitando o segfault rwm-rewriteContext searchFilter rwm-rewriteRule "(.*)(\\* ?\\*)(.*)" "$1*$3" "@I" This problem also occurs in other versions of slapd native Debian and Ubuntu. Without the overlay rwm not occur this BUG . Can anyone confirm if it is really a bug in the " rwm overlay" ? Regards, Jarbas

3 4

subtree-exclude (was Re: slapd-meta exclude syntax; larger problem with rwm, collective attributes.)
by Dan Pritts 12 Feb '14

12 Feb '14

Hi - Anyone have any thoughts about my question about "subtree-exclude" with slapd-meta? > Dan Pritts <mailto:danno@umich.edu> > February 7, 2014 at 10:51 AM > Hi folks - > > first, a simple, direct question. I'm trying to use the meta backend, > and exclude part of the > back-end directory (which is AD, if that matters). > > I tried the following config: > > -------------------------- > include /usr/local/pkg/openldap-2.4.39/etc/openldap/schema/core.schema > include > /usr/local/pkg/openldap-2.4.39/etc/openldap/schema/cosine.schema > include > /usr/local/pkg/openldap-2.4.39/etc/openldap/schema/inetorgperson.schema > include /usr/local/pkg/openldap-2.4.39/etc/openldap/schema/nis.schema > > pidfile /var/run/openldap/slapd-filter.pid > argsfile /var/run/openldap/slapd-filter.args > > loglevel any > > access to * > by * read > > database meta > suffix "dc=adsroot,dc=itd,dc=umich,dc=edu" > uri > "ldap://adsroot.itd.umich.edu/dc=adsroot,dc=itd,dc=umich,dc=edu" > rootdn "cn=Manager,dc=adsroot,dc=itd,dc=umich,dc=edu" > > #subtree-exclude > "ou=ICPSR,ou=Organizations,ou=UMICH,dc=adsroot,dc=itd,dc=umich,dc=edu" > #subtree-exclude > "ou=ICPSR,ou=Accounts,ou=UMICH,dc=adsroot,dc=itd,dc=umich,dc=edu" > subtree-exclude > "dn.subtree:ou=ICPSR,ou=Organizations,ou=UMICH,dc=adsroot,dc=itd,dc=umich,dc=edu" > subtree-exclude > "dn.subtree:ou=ICPSR,ou=Accounts,ou=UMICH,dc=adsroot,dc=itd,dc=umich,dc=edu" > -------------------------- > > As you can see i tried two syntaxes for subtree-exclude. with either > one, a search for "cn=danno" returns > dn: > cn=danno,ou=ICPSR,ou=Accounts,ou=UMICH,dc=adsroot,dc=itd,dc=umich,dc=edu > > What am I doing wrong? Or do I misunderstand what subtree-exclude is > supposed to be doing? > > openldap 2.4.39 on centos 6, x64. > -- Dan Pritts ICPSR Computing & Network Services University of Michigan +1 (734)615-7362

1 0

Simple way to check that MMR is in sync?
by Philip Colmer 12 Feb '14

12 Feb '14

Hi I've got a 2-node setup for master-master replication. Other than creating or modifying a record on one node and then checking/waiting for that change to appear on the other node, is there a recommended way to check that the nodes are in sync and not encountering any problems? Thanks. Philip

12 28

← Newer
1
2
3
4
5
6
7
8
9
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical February 2014