cURL, libcurl, and LDAP
by Howard Chu
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/
13 years, 3 months
Proxy authorization fail with cyrus-sasl and postfix
by Julien Vehent
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
13 years, 3 months
dynlist and group membership (libnss-ldap, posixGroup, samba)
by Felipe Augusto van de Wiel
-----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-----
13 years, 4 months
Q: status of component matching?
by Nardmann, Heiko
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/openl...
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.
13 years, 4 months
use of server-side sorting and virtual list view controls blocks slapd
by Lehnert, Hartmut
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
13 years, 4 months
shadowLastChange not updating
by Allgood, John
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.
13 years, 4 months
Group based ACLS
by Indexer
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
13 years, 4 months
olcAccess
by Indexer
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
13 years, 4 months
RE: Segmentation Fault appearing while doing the sync.-OpenLDAP 2.4.22
by masarati＠aero.polimi.it
> Thanks for the suggestion.
>
> No I didn't run the core with gdb.
Please see <http://www.openldap.org/faq/data/cache/56.html>.
In any case, you don't need sync_use_subentry, unless your database's
suffix is "".
> The owner of the files is root and I am running the slapd process with
> root only.
>
> Have rearranged the directives in the config. Please check the attached.
> But it is still throwing the same error.
>
> Can you please suggest on this?
>
> Rahul Manchanda
>
> GS Selfcare
> Platform Build Team
>
> Tel: +91 02066018100 Extn: 6178
> SMTP: rahul.manchanda(a)bt.com
>
> Office: Sharda Center ,6th Floor Annex
> Off Karve Road, Erandwana ,Pune-04
>
> -----Original Message-----
> From: Dieter Kluenter [mailto:dieter@dkluenter.de]
> Sent: Wednesday, May 19, 2010 10:09 AM
> To: Manchanda,RK,Rahul,DKE C
> Cc: openldap-technical(a)openldap.org
> Subject: Re: Segmentation Fault appearing while doing the sync.-OpenLDAP
> 2.4.22
>
> <rahul.manchanda(a)bt.com> writes:
>
>> Hi ,
>>
>> I have added sync_use_subentry in the ldap configuration and it started
>> throwing the core dump while performing the sync from other running
>> server and
>> stops the LDAP process.
>
> Did you run the core within gdb?
>>
>> Here is the error seen the in the debug logs.
>>
>> <= index_entry_add( 114, "ou=New NetIQ StAlbans /
>> Glasgow,ou=ChartReports,ou=
>> services,o=BT" ) success
>>
>> => entry_encode(0x00000072): ou=New NetIQ StAlbans / Glasgow,ou=
>> ChartReports,ou=services,o=BT
>>
>> <= entry_encode(0x00000072): ou=New NetIQ StAlbans / Glasgow,ou=
>> ChartReports,ou=services,o=BT
>>
>> bdb_add: added id=00000072 dn="ou=New NetIQ StAlbans / Glasgow,ou=
>> ChartReports,ou=services,o=BT"
>>
>> send_ldap_result: conn=-1 op=0 p=0
>>
>> send_ldap_result: err=0 matched="" text=""
>>
>> bdb_modify: cn=ldapsync,o=bt
>>
>> bdb_dn2entry("cn=ldapsync,o=bt")
>>
>> => bdb_dn2id("cn=ldapsync,o=bt")
>>
>> <= bdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found
>> (-30988)
>>
>> bdb_modify: dn2entry failed (-30988)
>
> who is running slapd and who is the owner of dn2id.bdb and dn2entry.bdb?
>
>> send_ldap_result: conn=-1 op=0 p=0
>>
>> send_ldap_result: err=10 matched="o=BT" text=""
>
> error 10 indicates that the referral is not available.
Error 10 is there because the internal modification can't find the entry
it's looking for, thus tries to send a referral according to updateref.
p.
>> ./start_ldap.sh: line 3: 14900 Segmentation Fault (core dumped)
>> /software
>> /openldap2.4.22/libexec/slapd -f /software/openldap2.4.22/etc/openldap/
>> slapd.conf -h ldap://tardis02.nat.bt.com:489/ -d -1
>>
>> Have attached the slapd.conf file.
>>
>> Could you please suggest?
>
> Your slapd.conf is completely bogus, don't mix global configuration
> parameters with database specific parameters, and vice versa. Overlay
> declarations have to follow all database configuration parameters.
>
>
>>
>> overlay syncprov
>> syncprov-checkpoint 100 5
>> syncprov-sessionlog 100
>>
>> sync_use_subentry TRUE
> ^^^^^^^^^^^^^^^^^^^^^^^^
>
> this is a database specific parameter
>
>
>> # Index Definition
> [...]
>
> Indices are database specific
>
>> #############################
>> ###### ACL definitions ######
>> #############################
>
> ACL's are partly global and database specific
>
> -Dieter
>
> --
> Dieter KlÃŒnter | Systemberatung
> sip: +49.40.20932173
> http://www.dpunkt.de/buecher/2104.html
> GPG Key ID:8EF7B6C6
>
13 years, 4 months
