openldap-technical

openldap-technical@openldap.org

14 participants
9796 discussions

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

Group based ACLS
by Indexer 20 May '10

20 May '10

I have been reading http://www.openldap.org/doc/admin24/access-control.html and am evry interested in how sets can be applied to controlling ACLs. In the examples shown, all the relationships are tied to the user having an attribute such as a manager etc, but i would like to do this in reverse so that an account, lets say Admin, can only modify users that have an entry in a group such as cn=Group,dc=example memberUid: testuser uid=testuser,dc=example uid=someuser,dc=example In this case Admin would be able to modify testuser, but not someuser. Is this possible, or do i need to enforce membership on the user as well such that uid=testuser,dc=example memberOf: group William

1 0

olcAccess
by Indexer 20 May '10

20 May '10

Im having a look at using the new olcAccess system rather than using slapd.conf for ACLs, and while the documentation of olcAccess is fantastic, how to implement it is not so easily found. Any help and pointers on how to get started with olcAccess would be greatly appreciated, as i just want to add a set of ACLs to my LDAP with this. William

3 4

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical