openldap-technical

openldap-technical@openldap.org

9868 discussions

RE: ppolicy master/slave issue (currently "forward ppolicy updates" OR "authenticate")
by Siddhartha Jain 26 May '10

26 May '10

One more observation: 1. When changing password on the client, with client pointing at slave (with chaining enabled), the password change only goes through when the right password is supplied. 2. But, entering a wrong password won't give you a password fail message. Look at this transaction, where I enter a wrong password for password change: $ passwd Changing password for user joe. Enter login(LDAP) password: New UNIX password: Retype new UNIX password: LDAP password information update failed: Strong(er) authentication required only authenticated users may change passwords passwd: Permission denied From: Siddhartha Jain Sent: Tuesday, May 25, 2010 5:16 PM To: openldap-technical(a)openldap.org Subject: RE: ppolicy master/slave issue (currently "forward ppolicy updates" OR "authenticate") I replicated the setup and issues with slapd.d configuration. Running OpenLDAP 2.4.21 on CentOS x64. 1. Master and slave setup with ppolicy overlay. 2. When client points to master, pwdFailures are duly recorded and respected. Password auth works as expected. 3. When clients points to slave with chaining disabled, password auth and changes work fine but obviously pwdFailures are not recorded anywhere - neither on slave or master. 4. When client points to slave with chaining enabled, password auth breaks meaning user can type any string and still get a successful auth. Interestingly, in this case, pwdFailures get recorded on slave and master. Why or how a bind succeeds with a wrong password is weird. With slapd.d type config, the chain directives go under "frontendconfig" so I suspect the solution must lie there. As a sidenote, I am thinking of doing without slaves and just creating more primaries in multi-mode replication. Seems less complicated in terms of configuration and maintenance. Thanks, - Siddhartha > -----Original Message----- > From: openldap-technical-bounces+sjain=silverspringnet.com(a)openldap.org > [mailto:openldap-technical- > bounces+sjain=silverspringnet.com(a)openldap.org] On Behalf Of Chris > Jacobs > Sent: Tuesday, May 25, 2010 9:16 AM > To: openldap-technical(a)openldap.org > Subject: RE: ppolicy master/slave issue (currently "forward ppolicy > updates" OR "authenticate") > > Haven't heard anything on this yet... > > If someone could point me to some documentation, or better, graphic > illustration, of how OpenLDAP 'works', perhaps I can figure this out on > my own. > > Thanks, > - chris > > -----Original Message----- > From: openldap-technical- > bounces+chris.jacobs=apollogrp.edu(a)OpenLDAP.org [mailto:openldap- > technical-bounces+chris.jacobs=apollogrp.edu(a)OpenLDAP.org] On Behalf Of > Chris Jacobs > Sent: Thursday, May 06, 2010 11:45 AM > To: openldap-technical(a)openldap.org > Subject: RE: ppolicy master/slave issue (currently "forward ppolicy > updates" OR "authenticate") > > Anyone? > > I can't be the only person trying to implement ppolicy_forward_updates > and have user's actually authenticate... > > I've been poring over the documentation: > > http://www.openldap.org/doc/admin24/overlays.html#Password%20Policies > http://www.symas.com/blog/?page_id=66 > http://www.openldap.org/software/man.cgi?query=slapo- > ppolicy&sektion=5&apropos=0&manpath=OpenLDAP+2.4-Release > Which indicates: "This setting is only useful on a replication > consumer, and also requires the updateref setting and chain overlay to > be appropriately configured." > > I tried "chain-rebind-as-user" and that didn't seem to help (you can > see it in the configs below) - at least, how I tried it. Perhaps I > misunderstand something (I'm hoping at least) > > I'm totally at a loss here... > > - chris > > -----Original Message----- > From: openldap-technical- > bounces+chris.jacobs=apollogrp.edu(a)OpenLDAP.org [mailto:openldap- > technical-bounces+chris.jacobs=apollogrp.edu(a)OpenLDAP.org] On Behalf Of > Chris Jacobs > Sent: Monday, May 03, 2010 9:07 AM > To: openldap-technical(a)openldap.org > Subject: RE: ppolicy master/slave issue > > Really, I think this comes down to how to: > * ppolicy_forward_updates requiring priviledges > * authentication NOT requiring priviledges > > How do I split the two? Let ppolicy forward updates, which requires > priviledges, and NOT specify any authentication while user's are > authenticating? > > Thanks, > - chris > > -----Original Message----- > From: openldap-technical- > bounces+chris.jacobs=apollogrp.edu(a)OpenLDAP.org [mailto:openldap- > technical-bounces+chris.jacobs=apollogrp.edu(a)OpenLDAP.org] On Behalf Of > Chris Jacobs > Sent: Thursday, April 29, 2010 2:55 PM > To: openldap-technical(a)openldap.org > Subject: ppolicy master/slave issue > > Hello again, > > I'm having an odd issue with ppolicy and my master/slave config. > > First, my goals > General use: > Slave handles all reads locally. > Writes get forwarded to the master by the slave. > > Password policy: > When password failures happen on clients using slave ldap servers, > the failures, etc, get passed to the master to get replicated to the > slaves. > I understand this would be done using the ppolicy option: > ppolicy_forward_updates > > Authentication: > Actually authenticate (more later). > > To the problem: > --------------- > When I leave the section in the chain bit of SLAVE slapd.conf below > marked by lines intact (which bind as root): > * ppolicy_forward_updates seems to work great - the master shows > matching "pwdFailureTime" attributes. > * Regardless of password entered, you get a shell. User/bad password = > get a shell! This being a problem should be obvious. > I suspect that's due to the chain overlay section... > > If I comment out the lines in the SLAVE slapd.conf: > * authentication actually requires authentication (bad password = no > authentication) > * ppolicy_forward_updates don't work (no updates to master) > > It's possible that from my description some may already know my issue - > however, just to be sure, I've pasted below 'bare' versions of the: > * a master slapd.conf (sans schema includes) > * a slave slapd.conf (sans schema includes) > * /etc/ldap.conf (using slave) > * /etc/openldap/ldap.conf (same on all ldap servers) (thanks Howard - > they are NOT the same) > * /etc/pam.d/system-auth-ac (CentOS 5.4; ssh refers to system-auth-ac > for all types). > > Thanks for any help (and, likely, pointing out any 'stupids' below), > - chris > > PS: Feel free to critique - you won't hurt my feelings. > > MASTER slapd.conf: (one of a pair, mirrored, active/passive fail over) > ---------------------------------------------------------------------- > serverID 1 > loglevel 0 > pidfile /usr/local/var/openldap-data/run/slapd.pid > argsfile /usr/local/var/openldap-data/run/slapd.args > TLSCipherSuite HIGH:MEDIUM:+SSLv2 > TLSCACertificateFile /etc/openldap/cacerts/cacert.pem > TLSCertificateFile /etc/openldap/cacerts/servercrt.pem > TLSCertificateKeyFile /etc/openldap/cacerts/serverkey.pem > TLSVerifyClient never > password-hash {MD5} > sizelimit size.soft=500 size.hard=unlimited > timelimit time.soft=3600 time.soft=unlimited > database bdb > suffix "dc=example,dc=net" > rootdn "cn=root,dc=example,dc=net" > rootpw "secret" > directory "/usr/local/var/openldap-data" > include /etc/openldap/slapd.access.conf > index uid,cn,gidNumber,uidNumber,memberUid eq > index objectClass pres,eq > index operatingSystem pres,eq > index host pres,eq > index rack eq > index entryUUID eq > index uniqueMember eq > index entryCSN eq > index site eq > overlay ppolicy > ppolicy_hash_cleartext > ppolicy_use_lockout > overlay syncprov > syncprov-checkpoint 100 10 > syncprov-sessionlog 10 > syncrepl rid=2 > provider=ldaps://ldapmaster2.corp.example.net > type=refreshAndPersist > interval=00:00:10:00 > searchbase="dc=example,dc=net" > bindmethod=simple > binddn="cn=root,dc=example,dc=net" > credentials="secret" > retry="15 20 60 +" > mirrormode on > database monitor > > SLAVE slapd.conf: > ----------------- > serverID 13 > loglevel 0 > pidfile /usr/local/var/openldap-data/run/slapd.pid > argsfile /usr/local/var/openldap-data/run/slapd.args > TLSCipherSuite HIGH:MEDIUM:+SSLv2 > TLSCACertificateFile /etc/openldap/cacerts/cacert.pem > TLSCertificateFile /etc/openldap/cacerts/servercrt.pem > TLSCertificateKeyFile /etc/openldap/cacerts/serverkey.pem > TLSVerifyClient never > password-hash {MD5} > sizelimit size.soft=500 size.hard=unlimited > timelimit time.soft=3600 time.soft=unlimited > overlay chain > chain-uri ldaps://ldap-vip.corp.example.net/ > chain-rebind-as-user TRUE > vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv > vvvvvv > chain-idassert-bind bindmethod="simple" > binddn="cn=root,dc=example,dc=net" > credentials="secret" > mode="self" > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > ^^^^^^ > chain-tls ldaps > chain-return-error TRUE > database bdb > suffix "dc=example,dc=net" > rootdn "cn=root,dc=example,dc=net" > rootpw "secret" > directory "/usr/local/var/openldap-data" > include /etc/openldap/slapd.access.conf > index uid,cn,gidNumber,uidNumber,memberUid eq > index objectClass pres,eq > index operatingSystem pres,eq > index host pres,eq > index rack eq > index entryUUID eq > index uniqueMember eq > index entryCSN eq > index site eq > overlay ppolicy > ppolicy_hash_cleartext > ppolicy_use_lockout > ppolicy_forward_updates > syncrepl rid=1 > provider=ldaps://ldap-vip.corp.example.net > type=refreshAndPersist > interval=00:00:10:00 > searchbase="dc=example,dc=net" > bindmethod=simple > binddn="cn=root,dc=example,dc=net" > credentials="secret" > retry="15 20 60 +" > updateref "ldaps://ldap-vip.corp.example.net" > database monitor > > /etc/openldap/ldap.conf: (same on all LDAP servers) > --------------------------------------------------- > uri ldaps://localhost > base dc=example,dc=net > network_timeout 0 > sizelimit 0 > timelimit 0 > tls_cacert /etc/openldap/cacerts/cacert.pem > tls_reqcert demand > > /etc/ldap.conf: (on client using slave) > --------------------------------------- > uri ldaps://ldap-vip.dc1.example.net > timelimit 10 > bind_timelimit 10 > bind_policy soft > base dc=example,dc=net > scope sub > ssl on > tls_checkpeer no > tls_cacertfile /etc/openldap/cacert.pem (contents same as > /etc/openldap/cacerts/cacert.pem) > pam_login_attribute uid > pam_lookup_policy yes > pam_password exop > > /etc/pam.d/system-auth-ac: > -------------------------- > auth required pam_env.so > auth sufficient pam_unix.so nullok try_first_pass > auth requisite pam_succeed_if.so uid >= 500 quiet > auth sufficient pam_ldap.so use_first_pass > auth required pam_deny.so > > account required pam_unix.so broken_shadow > account sufficient pam_localuser.so > account sufficient pam_succeed_if.so uid < 500 quiet > account [default=bad success=ok user_unknown=ignore] pam_ldap.so > account required pam_permit.so > > password requisite pam_cracklib.so try_first_pass retry=3 > password sufficient pam_unix.so sha256 shadow nullok > try_first_pass use_authtok > password sufficient pam_ldap.so use_authtok > password required pam_deny.so > > session optional pam_keyinit.so revoke > session required pam_limits.so > session optional pam_mkhomedir.so > session [success=1 default=ignore] pam_succeed_if.so service in > crond quiet use_uid > session required pam_unix.so > session optional pam_ldap.so > > > > > This message is private and confidential. If you have received it in > error, please notify the sender and remove it from your system. > > > > > This message is private and confidential. If you have received it in > error, please notify the sender and remove it from your system. > > > > > This message is private and confidential. If you have received it in > error, please notify the sender and remove it from your system. >

1 0

ppolicy master/slave issue
by Chris Jacobs 26 May '10

26 May '10

Hello again, I'm having an odd issue with ppolicy and my master/slave config. First, my goals General use: Slave handles all reads locally. Writes get forwarded to the master by the slave. Password policy: When password failures happen on clients using slave ldap servers, the failures, etc, get passed to the master to get replicated to the slaves. I understand this would be done using the ppolicy option: ppolicy_forward_updates Authentication: Actually authenticate (more later). To the problem: --------------- When I leave the section in the chain bit of SLAVE slapd.conf below marked by lines intact (which bind as root): * ppolicy_forward_updates seems to work great - the master shows matching "pwdFailureTime" attributes. * Regardless of password entered, you get a shell. User/bad password = get a shell! This being a problem should be obvious. I suspect that's due to the chain overlay section... If I comment out the lines in the SLAVE slapd.conf: * authentication actually requires authentication (bad password = no authentication) * ppolicy_forward_updates don't work (no updates to master) It's possible that from my description some may already know my issue - however, just to be sure, I've pasted below 'bare' versions of the: * a master slapd.conf (sans schema includes) * a slave slapd.conf (sans schema includes) * /etc/ldap.conf (using slave) * /etc/openldap/ldap.conf (same on all ldap servers) (thanks Howard - they are NOT the same) * /etc/pam.d/system-auth-ac (CentOS 5.4; ssh refers to system-auth-ac for all types). Thanks for any help (and, likely, pointing out any 'stupids' below), - chris PS: Feel free to critique - you won't hurt my feelings. MASTER slapd.conf: (one of a pair, mirrored, active/passive fail over) ---------------------------------------------------------------------- serverID 1 loglevel 0 pidfile /usr/local/var/openldap-data/run/slapd.pid argsfile /usr/local/var/openldap-data/run/slapd.args TLSCipherSuite HIGH:MEDIUM:+SSLv2 TLSCACertificateFile /etc/openldap/cacerts/cacert.pem TLSCertificateFile /etc/openldap/cacerts/servercrt.pem TLSCertificateKeyFile /etc/openldap/cacerts/serverkey.pem TLSVerifyClient never password-hash {MD5} sizelimit size.soft=500 size.hard=unlimited timelimit time.soft=3600 time.soft=unlimited database bdb suffix "dc=unix,dc=aptimus,dc=net" rootdn "uid=root,ou=people,dc=unix,dc=aptimus,dc=net" rootpw "secret" directory "/usr/local/var/openldap-data/aptimus" include /etc/openldap/slapd.access.conf index uid,cn,gidNumber,uidNumber,memberUid eq index objectClass pres,eq index operatingSystem pres,eq index host pres,eq index rack eq index entryUUID eq index uniqueMember eq index entryCSN eq index site eq overlay ppolicy ppolicy_hash_cleartext ppolicy_use_lockout overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 10 syncrepl rid=2 provider=ldaps://ldapmaster2.corp.aptimus.net type=refreshAndPersist interval=00:00:10:00 searchbase="dc=unix,dc=aptimus,dc=net" bindmethod=simple binddn="uid=root,ou=people,dc=unix,dc=aptimus,dc=net" credentials="secret" retry="15 20 60 +" mirrormode on database monitor SLAVE slapd.conf: ----------------- serverID 13 loglevel 0 pidfile /usr/local/var/openldap-data/run/slapd.pid argsfile /usr/local/var/openldap-data/run/slapd.args TLSCipherSuite HIGH:MEDIUM:+SSLv2 TLSCACertificateFile /etc/openldap/cacerts/cacert.pem TLSCertificateFile /etc/openldap/cacerts/servercrt.pem TLSCertificateKeyFile /etc/openldap/cacerts/serverkey.pem TLSVerifyClient never password-hash {MD5} sizelimit size.soft=500 size.hard=unlimited timelimit time.soft=3600 time.soft=unlimited overlay chain chain-uri ldaps://ldap-vip.corp.aptimus.net/ chain-rebind-as-user TRUE vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv chain-idassert-bind bindmethod="simple" binddn="uid=root,ou=people,dc=unix,dc=aptimus,dc=net" credentials="Ten%20two" mode="self" ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ chain-tls ldaps chain-return-error TRUE database bdb suffix "dc=unix,dc=aptimus,dc=net" rootdn "uid=root,ou=people,dc=unix,dc=aptimus,dc=net" rootpw "secret" directory "/usr/local/var/openldap-data/aptimus" include /etc/openldap/slapd.access.conf index uid,cn,gidNumber,uidNumber,memberUid eq index objectClass pres,eq index operatingSystem pres,eq index host pres,eq index rack eq index entryUUID eq index uniqueMember eq index entryCSN eq index site eq overlay ppolicy ppolicy_hash_cleartext ppolicy_use_lockout ppolicy_forward_updates syncrepl rid=1 provider=ldaps://ldap-vip.corp.aptimus.net type=refreshAndPersist interval=00:00:10:00 searchbase="dc=unix,dc=aptimus,dc=net" bindmethod=simple binddn="uid=root,ou=people,dc=unix,dc=aptimus,dc=net" credentials="secret" retry="15 20 60 +" updateref "ldaps://ldap-vip.corp.aptimus.net" database monitor /etc/openldap/ldap.conf: (same on all LDAP servers) --------------------------------------------------- uri ldaps://localhost base dc=unix,dc=aptimus,dc=net network_timeout 0 sizelimit 0 timelimit 0 tls_cacert /etc/openldap/cacerts/cacert.pem tls_reqcert demand /etc/ldap.conf: (on client using slave) --------------------------------------- uri ldaps://ldap-vip.dc1.aptimus.net timelimit 10 bind_timelimit 10 bind_policy soft base dc=unix,dc=aptimus,dc=net scope sub ssl on tls_checkpeer no tls_cacertfile /etc/openldap/cacert.pem (contents same as /etc/openldap/cacerts/cacert.pem) pam_login_attribute uid pam_lookup_policy yes pam_password exop /etc/pam.d/system-auth-ac: -------------------------- auth required pam_env.so auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 500 quiet auth sufficient pam_ldap.so use_first_pass auth required pam_deny.so account required pam_unix.so broken_shadow account sufficient pam_localuser.so account sufficient pam_succeed_if.so uid < 500 quiet account [default=bad success=ok user_unknown=ignore] pam_ldap.so account required pam_permit.so password requisite pam_cracklib.so try_first_pass retry=3 password sufficient pam_unix.so sha256 shadow nullok try_first_pass use_authtok password sufficient pam_ldap.so use_authtok password required pam_deny.so session optional pam_keyinit.so revoke session required pam_limits.so session optional pam_mkhomedir.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so session optional pam_ldap.so This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system.

2 5

How to obtain a 'version number' of an attributes
by Andrew Bartlett 25 May '10

25 May '10

I've got a little challenge... there is an attribute in AD call msDS-KeyVersionNumber. In AD this operational attribute increments each time the unicodePwd attribute is updated. It is typically a small integer, being the number of times that the password has ever been changed. In Samba4, we maintain this by looking into our replication metadata (replPropertyMetaData), and returning a counter that is maintained there. I could maintain this manually from Samba's side (this is what we did in the past), but I wanted to first check if there was something already stored that I could convert. Thanks, Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco Inc.

5 8

cURL, libcurl, and LDAP
by Howard Chu 25 May '10

25 May '10

For those of you who use libcurl in your own applications, you may be interested to know that I've written a new LDAP implementation for libcurl. http://article.gmane.org/gmane.comp.web.curl.cvs/13393 The old code had a number of problems, mainly due to exclusively using the synchronous LDAPv2 APIs, which prevented it from playing nicely in the otherwise fully-asynchronous libcurl framework. It also has a bug such that it always opens two connections to the LDAP server for every curl request. The old code is still there, for deployments stuck with older LDAP libraries (OpenLDAP 2.3, or non-OpenLDAP code). The new code is fully asynchronous and non-blocking, written for OpenLDAP 2.4. It's also (surprise, surprise) far more efficient in parsing results. To cut down on duplication of config code, this module uses libcurl's existing socket and SSL infrastructure, instead of OpenLDAP's built in SSL/TLS support. Thus it automatically supports all of the libraries and features libcurl already supports, without needing any ongoing maintenance for when new libcurl features are added. If you've got other tools already built around curl, you'll get improved LDAP support without making any other changes. If you're looking for ways to tightly integrate libldap support directly into your own applications, the libcurl OpenLDAP code can show you how. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Proxy authorization fail with cyrus-sasl and postfix
by Julien Vehent 24 May '10

24 May '10

Hello list, I am trying to authenticate my mail users against my ldap directory (slapd 2.4.17, debian squeeze). I have setup proxy authorization for user postfix as follow: in slapd.conf ---- # SASL proxy authorization rewrite rule authz-regexp "^uid=([^,]+).*,cn=[^,]*,cn=auth$" "ldap:///dc=linuxwall,dc=info??sub?(uid=$1)" authz-policy to ---- ldif of user postfix ---- dn: cn=Postfix Administrator,ou=infrastructure,dc=linuxwall,dc=info authzto: ldap:///dc=linuxwall,dc=info??sub?(objectClass=inetOrgPerson) cn: Postfix Administrator [...] ---- I have a similar user with cyrus for cyrus-imapd. My user postfix seem to have the authorization to act on behalf of other user. ---- # ldapwhoami -Y DIGEST-MD5 -U postfix -H ldap://localhost -R linuxwall.info -X u:julien SASL/DIGEST-MD5 authentication started Please enter your password: SASL username: u:julien SASL SSF: 128 SASL data security layer installed. dn:cn=julien vehent,ou=people,dc=linuxwall,dc=info ---- Thus, I set up the ldapdb driver from the sasl library in the chroot of postfix. I see connections from postfix to slapd, postfix user is properly authenticated, but then I have the following message (see trace below): ---- May 23 12:57:04 samchiel slapd[1431]: conn=109 fd=17 ACCEPT from IP=127.0.0.1:58349 (IP=127.0.0.1:389) May 23 12:57:04 samchiel slapd[1431]: conn=109 op=0 BIND dn="" method=163 May 23 12:57:04 samchiel slapd[1431]: conn=109 op=0 RESULT tag=97 err=14 text=SASL(0): successful result: May 23 12:57:04 samchiel slapd[1431]: conn=109 op=1 BIND dn="" method=163 May 23 12:57:04 samchiel slapd[1431]: conn=109 op=1 BIND authcid="postfix" authzid="postfix" May 23 12:57:04 samchiel slapd[1431]: conn=109 op=1 BIND dn="cn=postfix administrator,ou=infrastructure,dc=linuxwall,dc=info" mech=DIGEST-MD5 sasl_ssf=128 ssf=128 May 23 12:57:04 samchiel slapd[1431]: conn=109 op=1 RESULT tag=97 err=0 text= May 23 12:57:04 samchiel slapd[1431]: conn=109 op=2 RESULT tag=120 err=123 text=not authorized to assume identity May 23 12:57:04 samchiel slapd[1431]: conn=109 op=2 do_extended: get_ctrls failed May 23 12:57:04 samchiel slapd[1431]: conn=109 op=3 UNBIND May 23 12:57:04 samchiel slapd[1431]: conn=109 fd=17 closed May 23 12:57:04 samchiel slapd[1431]: connection_read(17): no connection! ---- I don't understand this error 'not authorized to assume identity'... Since proxy authorization works fine when I test it with ldapwhoami. Also, on the same machine, I have a cyrus-imapd server that authenticates on the same slapd using the same ldapdriver. Thus, I don't think either slapd or cyrus-sasl are the problem, but since I don't understand the error..... Can you guys give me a hand here ? Thanks, Julien

3 6

dynlist and group membership (libnss-ldap, posixGroup, samba)
by Felipe Augusto van de Wiel 23 May '10

23 May '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, I'm afraid I'm missing something very simple here and it is likely that the issue is on libnss-ldap and not on OpenLDAP dynlist overlay, I just want to make sure everything is fine regarding OpenLDAP configuration. I'm using Debian 5.0 (Lenny) and OpenLDAP 2.4.11 (Debian packaged version). I'm also using rfc2307bis and I would like to have a dynamic group with all non-disabled Samba users. Not sure if it is recommended to send the full slapd.conf, so I'm just sending the parts I added in order to have the dynlist/"dynamic group". /etc/ldap/slapd.conf: include /etc/ldap/schema/dyngroup.schema ... overlay dynlist dynlist-attrset posixGroup labeledURI member $ ldapsearch -x cn=active-samba-users dn: cn=active-samba-users,ou=Groups,dc=ahpi,dc=org objectClass: top objectClass: groupOfNames objectClass: posixGroup objectClass: sambaGroupMapping objectClass: labeledURIObject cn: active-samba-users gidNumber: 999 sambaSID: S-1-5-21-1234567899-1234567899-123456789-2999 sambaGroupType: 2 displayName: active samba users labeledURI: ldap:///ou=People,?uid?sub?(&(objectClass=posixAccount)(objectClass=sambaSAMAccount)(!(sambaAcctFlags=*D*))) When I run the search above I do get the expected results, several 'member' fields are added to the response: member: uid=userA,ou=People,dc=ahpi,dc=org member: uid=userB,ou=People,dc=ahpi,dc=org The problem, is that I would expect and 'id userA' to include group 'active-samba-users' but it doesn't. But 'getent group active-samba-users' includes all the users: active-samba-users:*:999:userA,userB Am I doing something wrong or missing something obvious? Below are the complete version of libnss-ldap.conf and pam_ldap.conf /etc/libnss-ldap.conf: ldap_version 3 base dc=ahpi,dc=org host 127.0.0.1 uri ldap://localhost rootbinddn cn=manager,dc=ahpi,dc=org scope sub pam_password ssha nss_schema rfc2307bis nss_map_attribute uniqueMember member /etc/pam_ldap.conf ldap_version 3 base dc=ahpi,dc=org uri ldap://localhost rootbinddn cn=manager,dc=ahpi,dc=org pam_password ssha nss_schema rfc2307bis nss_map_attribute uniqueMember member I also tried to use a different attrset: dynlist-attrset posixGroup labeledURI memberUid:uid From some maillist archives I had the impression that the approach above could solve it, I then removed the nss_schema and nss_map_attribute from libnss-ldap and pam_ldap but it didn't seem to work (the query was OK). It seems to me that something is wrong with my libnss/pam configuration, but it would be great if somebody else could confirm it. Thanks in advance. :-) Kind regards, - -- Felipe Augusto van de Wiel <felipe.wiel(a)hpp.org.br> Tecnologia da Informação (TI) - Complexo Pequeno Príncipe http://www.pequenoprincipe.org.br/ T: +55 41 3310 1747 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCgAGBQJL9JYHAAoJECCPPxLgxLxPv3gP/ip9seR1fhhLvrTwQ9OlfdjL iRk3nU9iPj5JtzwDHiOl872CTdZuI7Hbh4bCAe61Ix7Ai8Sz0nZsaBJRu2L+4K9W 4qY2lLAChn1k/R//9pnWxSi3zRInL6aMIXWWPqxLI5cmN9zht6Z0YQp/Uf5tkoez q16nXSklJTJFJEAaEbhR5oxVo0vAGAl8zMdU8aZ1OicsdaVG4e0gzTtaCet6Yyvf lCt7M1S3TNW4emebysKML+lbC6MdCAdUiRn0TzN3RL7v/42YZQX7k/nL2ZWKhIEn jTkB5AzH4G1SjMTjq2yl3x7JGjFEmgPIDVTHcXfZj8mho6VaHmfR2QLGY6Mmt6/E 7ATQsYe57qNhTW5XhrUadd/5M+jCHkFe6mfKALbYhmj4Yjj1cXUxLTh4g4AYtWbL qKd+haYf8cFDoDDBvf/bQQBe8tlM0ZRLkbqliy6I0+VZGoWkGButwM0TVjSPnin5 h7by/m3cgRFuRf2qZEafCoCzsVExN8wLKkzo9VHDx9ZxvA0KJ6QEQl52s5w+DkmF CxyjTkRWPYi6mpzj9+nK0l8wbTeq+GLV2qvldPt+QIPyWDVOrnzJofkJK36Huhzs 7siOd8SI2uSSZwrRESaNWl/Wjyf0DAUhXOHUYqpGBIg9yiWHCKWr/A0EhOVOEWwb CyPGFEw88YJq8dD89pdb =Icjy -----END PGP SIGNATURE-----

2 3

Q: status of component matching?
by Nardmann, Heiko 23 May '10

23 May '10

Hi all, we are trying to set up an openldap 2.4.21 slapd server that is able to handle component-filter search requests. The problem we get is that the slapd fails to load the compmatch module. With full debug output the error message is: "lt_dlopenext failed: (compmatch.la) file not found" Does anybody already have entered this problem? What we did/tried is now described in detail: We use Suse 11.1 as the Linux distribution. Compiler info: openldap@ocsp-openldap24:~/openldap-2.4.21/tests> gcc -v Using built-in specs. Target: i586-suse-linux Configured with: ../configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib --libexecdir=/usr/lib --enable-languages=c,c++,objc,fortran,obj-c++,java,ada --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.3 --enable-ssp --disable-libssp --with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux' --disable-libgcj --disable-libmudflap --with-slibdir=/lib --with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-version-specific-runtime-libs --program-suffix=-4.3 --enable-linux-futex --without-system-libunwind --with-cpu=generic --build=i586-suse-linux Thread model: posix gcc version 4.3.2 [gcc-4_3-branch revision 141291] (SUSE Linux) The openldap software is configured with the following command: ./configure LDFLAGS="-L/usr/local/BerkeleyDB.5.0/lib -ldb" --prefix /home/openldap/openldap-2.4.21-install --enable-modules --enable-sssvlv --enable-syncprov --enable-valsort --enable-bdb=mod To supply the ASN.1 object parsing we downloaded http://www.openldap.org/software/download/OpenLDAP/openldap-release/openlda… to create the asn.1 library libcasn1.a. While running make for the component match module itself we encounter problems when calling the libtool for linking: ../../../libtool --mode=link gcc -g -O2 -DLDAP_COMPONENT -DLDAP_COMP_MATCH \ /home/openldap/openldap-snacc-2.3.6/c-lib/libcasn1.a -L/usr/lib -lcrypto -version-info 0:0:0 \ -rpath /home/openldap/openldap-2.4.21-install/libexec/openldap -module -o compmatch.la componentlib.lo \ init.lo certificate.lo asn_to_syn_mr.lo authorityKeyIdentifier.lo crl.lo \ /home/openldap/openldap-snacc-2.3.6/c-lib/libcasn1.a -L/usr/lib -lcrypto *** Warning: Linking the shared library compmatch.la against the *** static library /home/openldap/openldap-snacc-2.3.6/c-lib/libcasn1.a is not portable! In the resulting compmatch.a library the asn.1 lib is included four times: openldap@ocsp-openldap24:~/openldap-2.4.21/contrib/slapd-modules/comp_match> ar tv .libs/compmatch.a rw-r--r-- 1000/1000 152162 May 18 14:37 2010 libcasn1.a rw-r--r-- 1000/1000 152162 May 18 14:37 2010 lt1-libcasn1.a rw-r--r-- 1000/1000 131488 May 19 14:04 2010 componentlib.o rw-r--r-- 1000/1000 70900 May 19 14:04 2010 init.o rw-r--r-- 1000/1000 144908 May 19 14:04 2010 certificate.o rw-r--r-- 1000/1000 55372 May 19 14:04 2010 asn_to_syn_mr.o rw-r--r-- 1000/1000 110584 May 19 14:04 2010 authorityKeyIdentifier.o rw-r--r-- 1000/1000 84920 May 19 14:04 2010 crl.o rw-r--r-- 1000/1000 152162 May 18 14:37 2010 libcasn1.a rw-r--r-- 1000/1000 152162 May 18 14:37 2010 libcasn1.a The component filter test fails: >>>>> Starting test031-component-filter for bdb... running defines.sh Running slapadd to build slapd database... slapadd: bad configuration file! slapadd failed (1)! Be sure to have a certificate module in tests/data/comp_libs The module is in openldap/contrib/slapd-modules/comp_match Test skipped. >>>>> ./scripts/test031-component-filter completed OK for bdb. Now we try to load the module via slapd. In the slapd.conf we specify the following: # Load dynamic backend modules: modulepath /home/openldap/openldap-2.4.21-install/libexec/openldap moduleload back_bdb.la moduleload compmatch.la Check that all module files do exist: openldap@ocsp-openldap24:~/openldap-2.4.21/contrib/slapd-modules/comp_match> ls -al /home/openldap/openldap-2.4.21-install/libexec/openldap total 736 drwxr-xr-x 2 openldap openldap 4096 2010-05-19 14:10 . drwxr-xr-x 3 openldap openldap 4096 2010-05-19 09:32 .. lrwxrwxrwx 1 openldap openldap 21 2010-05-19 09:31 back_bdb-2.4.so.2 -> back_bdb-2.4.so.2.5.4 -rwxr-xr-x 1 openldap openldap 221074 2010-05-19 09:31 back_bdb-2.4.so.2.5.4 -rwxr-xr-x 1 openldap openldap 889 2010-05-19 09:31 back_bdb.la lrwxrwxrwx 1 openldap openldap 21 2010-05-19 09:31 back_bdb.so -> back_bdb-2.4.so.2.5.4 -rwxr-xr-x 1 openldap openldap 889 2010-05-19 10:02 compmatch.la lrwxrwxrwx 1 openldap openldap 18 2010-05-19 09:56 compmatch.so -> compmatch.so.0.0.0 -rwxr-xr-x 1 openldap openldap 507076 2010-05-19 09:55 compmatch.so.0.0.0 Starting slapd by openldap@ocsp-openldap24:~/openldap-2.4.21/contrib/slapd-modules/comp_match> strace -vall -s1024 -oasi /home/openldap/openldap-2.4.21-install/libexec/slapd -h ldap://localhost:9389/ -d -1 results in the following: line 15 (pidfile /home/openldap/openldap-2.4.21-install/var/run/slapd.pid) line 16 (argsfile /home/openldap/openldap-2.4.21-install/var/run/slapd.args) line 19 (modulepath /home/openldap/openldap-2.4.21-install/libexec/openldap) line 21 (moduleload back_bdb.la) loaded module back_bdb.la bdb_back_initialize: initialize BDB backend bdb_back_initialize: Berkeley DB 5.0.21: (March 30, 2010) module back_bdb.la: null module registered line 26 (moduleload compmatch.la) lt_dlopenext failed: (compmatch.la) file not found /home/openldap/openldap-2.4.21-install/etc/openldap/slapd.conf: line 26: <moduleload> handler exited with 1! slapd destroy: freeing system resources. slapd stopped. connections_destroy: nothing to destroy. The content of compmatch.la: openldap@ocsp-openldap24:~/openldap-2.4.21/contrib/slapd-modules/comp_match> cat /home/openldap/openldap-2.4.21-install/libexec/openldap/compmatch.la # back_bdb.la - a libtool library file # Generated by ltmain.sh - GNU libtool 1.5.22-OpenLDAP (1.1220.2.365 2005/12/18 22:14:06) # # Please DO NOT delete this file! # It is necessary for linking the library. # The name that we can dlopen(3). dlname='compmatch.so.0.0.0' # Names of this library. library_names='compmatch.so.0.0.0 compmatch.so' # The name of the static archive. old_library='' # Libraries that this one depends upon. dependency_libs='' # Version information for back_bdb. current=0 age=0 revision=0 # Is this an already installed library? installed=yes # Should we warn about portability when linking against -modules? shouldnotlink=yes # Files to dlopen/dlpreopen dlopen='' dlpreopen='' # Directory that this library needs to be installed in: libdir='/home/openldap/openldap-2.4.21-install/libexec/openldap' An excerpt from the strace file shows that the module itself can be accessed: open("/home/openldap/openldap-2.4.21-install/libexec/openldap/compmatch.so.0.0.0", O_RDONLY) = 10 read(10, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\20\241\0\0004\0\0\0\224V\7\0\0\0\0\0004\0 \0\6\0(\0'\0$\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\20\267\2\0\20\267\2\0\5\0\0\0\0\20\0\0\1\0\0\0\364\273\2\0\364\313\2\0\364\313\2\0\4(\0\0<>\0\0\6\0\0\0\0\20\0\0\2\0\0\0`\274\2\0`\314\2\0`\314\2\0\330\0\0\0\330\0\0\0\6\0\0\0\4\0\0\0\4\0\0\0\364\0\0\0\364\0\0\0\364\0\0\0$\0\0\0$\0\0\0\4\0\0\0\4\0\0\0Q\345td\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\6\0\0\0\4\0\0\0R\345td\364\273\2\0\364\313\2\0\364\313\2\0\f\4\0\0\f\4\0\0\4\0\0\0\1\0\0\0\4\0\0\0\24\0\0\0\3\0\0\0GNU\0\"\261\223\260l\363\226\251\276\214p&\265\373\240\242l\3254\310\t\2\0\0006\2\0\0\230\0\0\0\n\1\0\0;\0\0\0\0\0\0\0\235\0\0\0\0\0\0\0\0\0\0\0\350\1\0\0(\2\0\0\0\0\0\0\0\1\0\0\0\0\0\0\7\2\0\0\0\0\0\0\205\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\245\0\0\0\0\0\0\0\16\1\0\0\322\1\0\0\0\0\0\0\224\1\0\0#\0\0\0\275\0\0\0\0\0\0\0\263\0\0\0\0\0\0\0D\0\0\0$\1\0\0\314\0\0\0\312\1\0\0c\1\0\0\0\0\0\0\0\0\0\0~\0\0\0\0\0\0\0\0\0\0\0\274\1\0\0\375\0\0\0\362\1\0\0\237\1\0\0\0\0\0\0\0\0\0\0\210\1\0\0\0\0\0\0\0\0\0\0\225\0\0\0\0\0\0\0t\1\0\0\21\2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 512) = 512 fstat64(10, {st_dev=makedev(8, 2), st_ino=357002, st_mode=S_IFREG|0755, st_nlink=1, st_uid=1000, st_gid=1000, st_blksize=4096, st_blocks=1000, st_size=507076, st_atime=2010/05/19-14:13:32, st_mtime=2010/05/19-09:55:40, st_ctime=2010/05/19-09:55:40}) = 0 mmap2(NULL, 199216, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 10, 0) = 0xb7c42000 fadvise64(10, 0, 199216, POSIX_FADV_WILLNEED) = 0 mmap2(0xb7c6e000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 10, 0x2b) = 0xb7c6e000 mmap2(0xb7c72000, 2608, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7c72000 close(10) = 0 open("/usr/local/BerkeleyDB.5.0/lib/libcrypto.so.0.9.8", O_RDONLY) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 10 fstat64(10, {st_dev=makedev(8, 2), st_ino=567539, st_mode=S_IFREG|0644, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=64, st_size=31447, st_atime=2010/05/19-14:13:32, st_mtime=2010/05/18-10:45:00, st_ctime=2010/05/18-10:45:00}) = 0 mmap2(NULL, 31447, PROT_READ, MAP_PRIVATE, 10, 0) = 0xb7c3a000 close(10) = 0 open("/usr/lib/libcrypto.so.0.9.8", O_RDONLY) = 10 read(10, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\300\320\3\0004\0\0\0\2641\26\0\0\0\0\0004\0 \0\7\0(\0\35\0\34\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\220\333\24\0\220\333\24\0\5\0\0\0\0\20\0\0\1\0\0\0\300\351\24\0\300\351\24\0\300\351\24\0\304F\1\0Xz\1\0\6\0\0\0\0\20\0\0\2\0\0\0\310Z\25\0\310Z\25\0\310Z\25\0\360\0\0\0\360\0\0\0\6\0\0\0\4\0\0\0\4\0\0\0\24\1\0\0\24\1\0\0\24\1\0\0$\0\0\0$\0\0\0\4\0\0\0\4\0\0\0P\345td\310\242\22\0\310\242\22\0\310\242\22\0\34u\0\0\34u\0\0\4\0\0\0\4\0\0\0Q\345td\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\7\0\0\0\4\0\0\0R\345td\300\351\24\0\300\351\24\0\300\351\24\0@v\0\0@v\0\0\4\0\0\0\1\0\0\0\4\0\0\0\24\0\0\0\3\0\0\0GNU\0\265\352E\24\365\314\1771\372m\0\247U\306\336\241\222C->\5\10\0\0r\r\0\0\0\0\0\0-\6\0\0\0\0\0\0\336\n\0\0\0\0\0\0\0\0\0\0f\7\0\0\363\3\0\0\0\0\0\0\0\0\0\0\215\f\0\0l\v\0\0\214\v\0\0/\v\0\0\311\4\0\0\257\7\0\0\32\f\0\0u\3\0\0\203\3\0\0\30\6\0\0\327\n\0\0\260\4\0\0\303\2\0\0H\6\0\0&\r\0\0\342\v\0\0m\t\0\0\202\3\0\0O\6\0\0\267\v\0\0\373\n\0\0\0\0\0\0\331\0\0\0\233\7\0\0-\0\0\0/\10\0\0\0\0\0\0\t\6\0\0\0\0\0\0E\1\0\0.\0\0\0U\4\0\0\21\0\0\0\0\0\0\0\345\t\0\0!\2\0\0\0\0\0\0\0\0\0\0", 512) = 512 fstat64(10, {st_dev=makedev(8, 2), st_ino=523294, st_mode=S_IFREG|0555, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=2856, st_size=1455676, st_atime=2010/05/19-14:13:32, st_mtime=2008/12/03-07:36:55, st_ctime=2009/07/27-12:44:06}) = 0 mmap2(NULL, 1467416, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 10, 0) = 0xb7ad3000 fadvise64(10, 0, 1467416, POSIX_FADV_WILLNEED) = 0 mmap2(0xb7c21000, 90112, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 10, 0x14e) = 0xb7c21000 mmap2(0xb7c37000, 9240, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7c37000 close(10) = 0 open("/usr/local/BerkeleyDB.5.0/lib/libz.so.1", O_RDONLY) = 10 read(10, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0p\31\0\0004\0\0\0(2\1\0\0\0\0\0004\0 \0\7\0(\0\35\0\34\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\254)\1\0\254)\1\0\5\0\0\0\0\20\0\0\1\0\0\0(.\1\0(>\1\0(>\1\0\344\2\0\0\354\2\0\0\6\0\0\0\0\20\0\0\2\0\0\0\350.\1\0\350>\1\0\350>\1\0\320\0\0\0\320\0\0\0\6\0\0\0\4\0\0\0\4\0\0\0\24\1\0\0\24\1\0\0\24\1\0\0$\0\0\0$\0\0\0\4\0\0\0\4\0\0\0P\345td\0\34\1\0\0\34\1\0\0\34\1\0\304\2\0\0\304\2\0\0\4\0\0\0\4\0\0\0Q\345td\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\6\0\0\0\4\0\0\0R\345td(.\1\0(>\1\0(>\1\0\330\1\0\0\330\1\0\0\4\0\0\0\1\0\0\0\4\0\0\0\24\0\0\0\3\0\0\0GNU\0\17\363*\0274\316\273\2402`\300d\237a\241\201\356h\327Sa\0\0\0i\0\0\0;\0\0\0\0\0\0\0\f\0\0\0\32\0\0\0,\0\0\0\35\0\0\0\0\0\0\0b\0\0\0\0\0\0\0\0\0\0\0g\0\0\0\0\0\0\0P\0\0\0\0\0\0\0\\\0\0\0\0\0\0\0003\0\0\0_\0\0\0A\0\0\0\37\0\0\0W\0\0\0000\0\0\0[\0\0\0'\0\0\0%\0\0\0\0\0\0\0F\0\0\0]\0\0\0\23\0\0\0006\0\0\0\0\0\0\0a\0\0\0h\0\0\0\6\0\0\0-\0\0\0H\0\0\0\34\0\0\0008\0\0\0\27\0\0\0\0\0\0\0\20\0\0\0`\0\0\0005\0\0\0K\0\0\0\0\0\0\0)\0\0\0J\0\0\0\26\0\0\0", 512) = 512 fstat64(10, {st_dev=makedev(8, 2), st_ino=579040, st_mode=S_IFREG|0755, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=168, st_size=79536, st_atime=2010/05/19-14:13:32, st_mtime=2010/05/19-08:48:55, st_ctime=2010/05/19-08:48:55}) = 0 mmap2(NULL, 82196, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 10, 0) = 0xb7abe000 fadvise64(10, 0, 82196, POSIX_FADV_WILLNEED) = 0 mmap2(0xb7ad1000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 10, 0x12) = 0xb7ad1000 close(10) = 0 mprotect(0xb7ad1000, 4096, PROT_READ) = 0 mprotect(0xb7c21000, 32768, PROT_READ) = 0 munmap(0xb7c3a000, 31447) = 0 munmap(0xb7c42000, 199216) = 0 munmap(0xb7ad3000, 1467416) = 0 munmap(0xb7abe000, 82196) = 0 write(2, "lt_dlopenext failed: (compmatch.la) file not found\n", 51) = 51 time(NULL) = 1274271212 send(3, "<167>May 19 14:13:32 slapd[24620]: lt_dlopenext failed: (compmatch.la) file not found\n", 86, MSG_NOSIGNAL) = 86 write(2, "/home/openldap/openldap-2.4.21-install/etc/openldap/slapd.conf: line 26: <moduleload> handler exited with 1!\n", 109) = 109 close(9) = 0 munmap(0xb7e62000, 4096) = 0 write(2, "slapd destroy: freeing system resources.\n", 41) = 41 munmap(0xb7c73000, 252728) = 0 write(2, "slapd stopped.\n", 15) = 15 So does anybody have an idea? Regards, Heiko -- Dipl.-Ing. Heiko Nardmann Berater Business Security secunet Security Networks AG Weidenauer Str. 223-225 D-57076 Siegen Telefon +49 201 5454-2017 Telefax +49 201 5454-1329 Heiko.Nardmann(a)secunet.com www.secunet.com secunet Security Networks AG Kronprinzenstr. 30 45128 Essen Amtsgericht Essen HRB 13615 Vorstand: Dr. Rainer Baumgart Thomas Koelzer Thomas Pleines Aufsichtsratsvorsitzender: Dr. Karsten Ottenberg Diese E-mail kann vertrauliche Informationen enthalten. Falls Sie diese E-Mail irrtÃ¼mlich erhalten haben, informieren Sie bitte unverzÃ¼glich den Absender und lÃ¶schen Sie diese E-Mail von jedem Rechner, auch von den Mailservern. Jede Verbreitung des Inhalts, auch die teilweise Verbreitung, ist in diesem Fall untersagt. AuÃŸer bei Vorsatz oder grober FahrlÃ¤ssigkeit schlieÃŸen wir jegliche Haftung fÃ¼r Verluste oder SchÃ¤den aus, die durch Viren befallene Software oder E-Mails verursacht werden. This e-mail may contain confidential information. If you received this e-mail in error, please contact the sender and delete this e-mail from your computer, including your mailservers. Any dissemination, even partly, is prohibited. Except in case of gross negligence or wilful misconduct we accept no liability for any loss or damage caused by software or e-mail viruses.

2 1

setup for OpenLDAP for windows platform
by mani chandel 22 May '10

22 May '10

Hello, Can anyone please provide me the latest setup of OpenLDAP for windows platform. Thanks in advance. Regards, Mani

1 0

use of server-side sorting and virtual list view controls blocks slapd
by Lehnert, Hartmut 22 May '10

22 May '10

Hi all, We encounter a problem using server-side sort and virtual list view controls in our search requests. After sending one search requests the slapd remains busy until it is restarted: Executing the command /home/openldap/openldap-2.4.21-install/bin/ldapsearch -h localhost -p 9389 -D cn=openldapadmin -w welcome -b o=CustomerCA,c=de -s children -E!sss=sncertnr -E!vlv="0/0/1/0" "objectclass=*" Generates the following output: # extended LDIF # # LDAPv3 # base <o=CustomerCA,c=de> with scope children # filter: objectclass=* # requesting: sncertnr # with server side sorting critical control # with virtual list view critical control: 0/0/1/0 # # R\C3\BCger OttoSER:9000, testsuite, CustomerCA, de dn:: Y249UsO8Z2VyIE90dG9TRVI6OTAwMCxvdT10ZXN0c3VpdGUsbz1DdXN0b21lckNBLGM9ZGU= SNcertNr: 9000 # search result search: 2 result: 0 Success control: 1.2.840.113556.1.4.474 false MAMKAQA= sortResult: (0) Success control: 2.16.840.1.113730.3.4.10 false MA8CAQECAQsCAQAEBJB4LAg= vlvResult: pos=1 count=11 context=kHgsCA== (0) Success # numResponses: 2 # numEntries: 1 Press [before/after(/offset/count|:value)] Enter for the next window. # extended LDIF # # LDAPv3 # base <o=CustomerCA,c=de> with scope children # filter: objectclass=* # requesting: sncertnr # with server side sorting critical control # with virtual list view critical control: 0/0/1/11 # # search result search: 3 result: 4 Size limit exceeded # numResponses: 1 Why is the size limit exceeded here? Executing the same command once more produces the following output: # extended LDIF # # LDAPv3 # base <o=CustomerCA,c=de> with scope children # filter: objectclass=* # requesting: sncertnr # with server side sorting critical control # with virtual list view critical control: 0/0/1/0 # # search result search: 2 result: 51 Server is busy text: Other sort requests already in progress # numResponses: 1 Now slapd doesn't accept sssvlv requests anymore, it has to be restarted. Here is the content of slapd.conf: # # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # include /home/openldap/openldap-2.4.21-install/etc/openldap/schema/core.schema include /home/openldap/openldap-2.4.21-install/etc/openldap/schema/isis_mtt_exte nsions.schema include /home/openldap/openldap-2.4.21-install/etc/openldap/schema/secunet_isis_ mtt_extensions.schema # Define global ACLs to disable default read access. # Do not enable referrals until AFTER you have a working directory # service AND an understanding of referrals. #referral ldap://root.openldap.org pidfile /home/openldap/openldap-2.4.21-install/var/run/slapd.pid argsfile /home/openldap/openldap-2.4.21-install/var/run/slapd.args # Load dynamic backend modules: modulepath /home/openldap/openldap-2.4.21-install/libexec/openldap # modulepath /usr/local/libexec/openldap moduleload back_bdb.la # moduleload back_hdb.la # moduleload back_ldap.la # moduleload /home/openldap/openldap-2.4.21-install/libexec/openldap/compmatch # moduleload /home/openldap/openldap-2.4.21-install/libexec/openldap/compmatch.la # moduleload compmatch.la # overlay server-side-sorting + virtual list view: overlay sssvlv # Sets the maximum number of concurrent sort requests allowed # across all connections; the default is one half of the number of # server threads: sssvlv-max 8 # Sets the maximum number of keys allowed in a sort request; the # default is 5: sssvlv-maxkeys 5 # Sample security restrictions # Require integrity protection (prevent hijacking) # Require 112-bit (3DES or better) encryption for updates # Require 63-bit encryption for simple bind # security ssf=1 update_ssf=112 simple_bind=64 # Sample access control policy: # Root DSE: allow anyone to read it # Subschema (sub)entry DSE: allow anyone to read it # Other DSEs: # Allow self write access # Allow authenticated users read access # Allow anonymous users to authenticate # Directives needed to implement policy: # access to dn.base="" by * read # access to dn.base="cn=Subschema" by * read # access to * # by self write # by users read # by anonymous auth # # if no access controls are present, the default policy # allows anyone and everyone to read anything but restricts # updates to rootdn. (e.g., "access to * by * read") # # rootdn can always read and write EVERYTHING! ####################################################################### # BDB database definitions ####################################################################### database bdb suffix "" rootdn "cn=openldapadmin" # Cleartext passwords, especially for the rootdn, should # be avoid. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. rootpw welcome # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory /home/openldap/openldap-2.4.21-install/var/openldap-data # Indices to maintain index objectClass eq index c eq index o eq index ou eq index sncertnr eq index sncerthash eq index snissuerkeyhash eq index snissuernamehash eq Does anybody have an idea? Executing this command against a Sun DS 6 server doesn't generate this problem. Regards, Hartmut

2 1

shadowLastChange not updating
by Allgood, John 21 May '10

21 May '10

Hey All I am troubleshooting openldap on a Centos box and having an issue. When the users set their passwords using the passwd program shadowLastChange is not getting updated in ldap. Using openldap 2.3.43.12.el5. Here is a listing of my ACL's. Any ideas? access to attrs=userPassword,shadowLastChange by dn.base="cn=Manager,dc=turbocorp,dc=com" write by anonymous auth by self write by * none access to attrs=SambaLMPassword,SambaNTPassword by dn.base="cn=Manager,dc=turbocorp,dc=com" write by anonymous auth by self write by * none access to * by dn.base="cn=Manager,dc=turbocorp,dc=com" write by self write by * read John Allgood Senior Systems Administrator OHL Transportation Services 2251 Jesse Jewell Pky. NE Gainesville, GA 30507 tel: (678) 989-3051 fax: (770) 531-7878 jallgood(a)ohl.com<mailto:jallgood@ohl.com> www.ohl.com<http://www.ohl.com> ______________________________________________________ This e-mail transmission may contain information that is proprietary, privileged and/or confidential and is intended exclusively for the person(s) to whom it is addressed. Any use, copying, retention or disclosure by any person other than the intended recipient or the intended recipient's designees is strictly prohibited. If you are not the intended recipient or their designee, please notify the sender immediately by return e-mail and delete all copies.

2 3

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical