openldap-technical

openldap-technical@openldap.org

11 participants
9690 discussions

CN must be indexed?
by Andrew Bartlett 06 Jan '08

06 Jan '08

Working on the OpenLDAP backend for Samba4, I'm wondering if this is expected: Is 'cn' a special attribute in the OpenLDAP code? It seems that the builtin schema definition (or something else) requires that the 'cn' attribute be indexed with index cn eq Otherwise, searches for cn=foo fail, where cn=foo* succeeds... I'm using current CVS, and trying to have Samba4 automatically generate configuration files for OpenLDAP, possibly based on the (AD) schema-data we will load into the directory. As such, knowing any (particularly other, similar) OpenLDAP-imposed constraints will be very useful, so that I can ensure these are met by the provision-backend script in Samba4. Thanks, Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. http://redhat.com

2 5

Packaging libldap and libldap_r
by Russ Allbery 05 Jan '08

05 Jan '08

I'm one of the people who works on packaging OpenLDAP for Debian, and I'm trying to figure out what the right way to deal with libldap and libldap_r would be. Here's the problem that Debian has (which I expect is shared by other distributors): As I understand it, libldap_r is the thread-safe library and libldap is not thread-safe, so threaded applications have to link with libldap_r. However, libldap and libldap_r both contain the same symbols and don't use symbol versioning. So if both are loaded into the same process space at the same time, it's undefined which library is called, which can cause all sorts of problems. Therefore, for modules like nss-ldap that are loaded into the process space of almost every system process, there is no good option for which library to link against in the presence of both libraries: Linking with libldap because nss-ldap isn't threaded means that threaded applications that link with libldap_r may resolve symbols to the wrong library. Threaded applications may also get undefined results if they call NSS functions. But linking nss-ldap with with libldap_r to be safe for threaded applications will cause problems for any application linked with libldap. Note that nss-ldap is just an example, useful because it's fairly obvious. The same problem applies to any situation where multiple libraries may be mingled in a process space: PAM-using servers with pam-ldap, Apache with mod_ldap and mod_python or mod_perl loading LDAP modules, etc. What's the recommended way of dealing with this problem? I'd like whatever solution we use to be something that you're comfortable with. It's worth noting, btw, that glibc provides stubs for pthread functions, allowing libraries that need to be thread-safe in threaded programs but not in unthreaded programs to gain back the speed lost to locking when running without threads. In order to use this, the library should *not* be linked directly with the pthread library. glibc will provide stubs that do nothing if libpthread isn't loaded, and if it is, they will be transparently replaced by the correct threading code. This would eliminate the need to have two separate libraries. However, glibc only provides these stubs for a limited number of functions, and libldap_r currently references pthread functions outside of that set. I believe the other symbols may only be used in the code that supports slapd, although I could be wrong. Attached is the list of functions for which stubs are provided. pthread_attr_destroy pthread_attr_getdetachstate pthread_attr_getinheritsched pthread_attr_getschedparam pthread_attr_getschedpolicy pthread_attr_getscope pthread_attr_init pthread_attr_setdetachstate pthread_attr_setinheritsched pthread_attr_setschedparam pthread_attr_setschedpolicy pthread_attr_setscope pthread_cond_broadcast pthread_cond_destroy pthread_cond_init pthread_cond_signal pthread_cond_timedwait pthread_cond_wait pthread_condattr_destroy pthread_condattr_init pthread_equal pthread_exit pthread_getschedparam pthread_mutex_destroy pthread_mutex_init pthread_mutex_lock pthread_mutex_unlock pthread_self pthread_setcancelstate pthread_setcanceltype pthread_setschedparam -- Russ Allbery (rra(a)stanford.edu) <http://www.eyrie.org/~eagle/>

1 0

openldap adressbook
by digitom 04 Jan '08

04 Jan '08

Hello, I've want to set up an email server with dovecot, postfix openldap etc. Now my problem is to set up an openldap adressbook for Evolution. I've could add a new contact to the database via Evolution, and can see the contact via phpldapadmin and with Evolution. But if I restart Evolution, all contacts are lost (in Evolution, in phpldapadmin I still could see the conatcts.) Where is the problem? I've activated all possible log statements, but there's no needful information. (for me:) I've using debian etch with slapd 2.3.30-5 and Evolution 2.12.1. Now my slapd.conf: include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema include /etc/ldap/schema/evolutionperson.schema pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args loglevel conns filter config trace args BER ACL stats stats2 shell parse index modulepath /usr/lib/ldap moduleload back_bdb sizelimit 500 tool-threads 1 backend bdb checkpoint 512 30 database bdb suffix "dc=testdomain" rootdn "cn=admin,dc=testdomain" rootpw {SSHA} ... and my ldif: dn:dc=testdomain objectClass: dcObject objectClass: organization o: my-example dc:testdomain dn:cn=admin,dc=testdomain objectClass: organizationalRole cn:admin dn:ou=contacts,dc=testdomain ou: contacts objectClass: organizationalUnit Do you need any further information to help me??? Thanks in advance. Thomas

3 2

[Unofficial] OpenLDAP Weekly News Issue 7
by Gavin Henry 04 Jan '08

04 Jan '08

Dear All, The seventh issue is out: http://blog.suretecsystems.com/categories/1-OpenLDAP Summary: - OpenLDAP 2.4.7 Released - OpenLDAP 2.3.40 Released - New Mailing List - Update on Build Farm - Contributions - OpenLDAP Documentation updates - OpenLDAP Development - Community Binaries - Blog LDAP Schema Update - "If there was an OpenLDAP Cookbook, what recipes would you like to see?" - Selected user issues and solutions discussed - LDAP Roundup Thanks, Gavin. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/

1 0

Cannot replicate userPassword?
by Thomas Kirchtag 02 Jan '08

02 Jan '08

My setup is rather basic. ldaps://ldap.ipodion.at is master/sync provider. "consumer" is slave/consumer. Everything seems to be working fine, all attributes are replicated with the notable exception of the userPassword attribute. ldapsearch on the consumer shows the missing attributes, so it can't be a permissions problem: consumer # ldapsearch -x -LL -D "cn=admin,dc=ipodion,dc=at" -W -H ldaps://ldap.ipodion.at -b "dc=int,dc=ipodion,dc=at" "(objectClass=person)" uidNumber userpassword Enter LDAP Password: version: 1 dn: cn=NextFreeUnixId,dc=int,dc=ipodion,dc=at uidNumber: 10007 dn: uid=tkircht,ou=people,dc=int,dc=ipodion,dc=at uidNumber: 500 userPassword:: e1NNRDV9dXZ1UkxMY1VDaThMSktablRSazJWMElCU2l dn: uid=Administrator,ou=People,dc=int,dc=ipodion,dc=at uidNumber: 0 userPassword:: e1NNRDV9c2swZEtCMzUyb2JQTkRucTcxcDczc0VScXpB [...] I added the acl for uidNumber just to make sure I didn't mistype any credential information, but the uidNumber attribute is replicated the user Password isn't.. I cannot find anything on this in the archives or the documentation - what am I doing wrong here?! Any help would be appreciated thanks, Thomas Config files: --------------------------------------------------------- provider: --------------------------------------------------------- ldap:~# grep -v '^#' /etc/ldap/slapd.conf | grep -v '^$' allow bind_v2 include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema include /etc/ldap/schema/samba.schema include /etc/ldap/schema/extension.schema schemacheck on pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args TLSCertificateFile /etc/ssl/certs/ldap.ipodion.cert.pem TLSCertificateKeyFile /etc/ssl/private/ldap.ipodion.key.pem TLSCACertificateFile /usr/share/ca-certificates/cacert.org/root.crt loglevel -1 modulepath /usr/lib/ldap moduleload back_bdb moduleload back_meta moduleload syncprov backend bdb database bdb suffix "dc=ipodion,dc=at" directory "/var/lib/ldap" overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 index objectClass eq index uidNumber,gidNumber,loginShell eq,pres index uid,memberUid eq,pres,sub lastmod on rootdn "cn=admin,dc=ipodion,dc=at" rootpw <secret> access to attrs=userPassword by dn="cn=admin,dc=ipodion,dc=at" write by anonymous auth by self write by * none access to attrs=uidNumber by dn="cn=admin,dc=ipodion,dc=at" write by anonymous auth by self write by * none access to dn.subtree="ou=addressbook,dc=ipodion,dc=at" by self write by dn="cn=admin,ou=addressbook,dc=ipodion,dc=at" write by * read access to dn.base="" by * read access to * by dn="cn=admin,dc=ipodion,dc=at" write by * read --------------------------------------------------------- consumer: --------------------------------------------------------- consumer:~# grep -v '^#' /etc/ldap/slapd.conf | grep -v '^$' allow bind_v2 include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema include /etc/ldap/schema/samba.schema schemacheck on pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args TLSCACertificateFile /etc/ssl/CA/cacert.pem loglevel 256 modulepath /usr/lib/ldap moduleload back_bdb backend bdb database bdb suffix "dc=int,dc=ipodion,dc=at" directory "/var/lib/ldap" index objectClass eq index uidNumber,gidNumber,loginShell eq,pres index uid,memberUid eq,pres,sub lastmod on rootdn "cn=admin,dc=int,dc=ipodion,dc=at" rootpw {SSHA}<secret2> syncrepl rid=667 provider=ldaps://ldap.ipodion.at type=refreshOnly interval=01:00:00:00 searchbase="dc=int,dc=ipodion,dc=at" scope=sub schemachecking=on bindmethod=simple binddn="cn=admin,dc=ipodion,dc=at" credentials=<secret> access to attrs=userPassword by dn="cn=admin,dc=int,dc=ipodion,dc=at" write by anonymous auth by self write by * none access to dn.base="" by * read access to * by dn="cn=admin,dc=int,dc=ipodion,dc=at" write by * read -- ========================================================= iPodion GmbH Rotensterngasse 20/3 A-1020 Wien, Austria Mobil: +43-660-216 32 98 Tel.:+43-1-216 32 98-0 mailto:office@iPodion.at Fax: +43-1-216 32 98-28 http://www.iPodion.at ========================================================= Achtung: Bitte beachten Sie meine neue Telefonnummer: 0660/2163298

4 7

ldap_set_option/ldap_bind_s segfaults
by Johan Ström 31 Dec '07

31 Dec '07

Hi list Im trying to run pure-ftpd 1.0.21 on a FreeBSD 7.0-amd64 (still beta yes) host, with LDAP (openldap-2.3.39) as auth backend. However the authing doesnt seem to work at all, as soon as password is sent the client gets disconnected. I've posted this similar message (altough more debugging info now) to their list without a single response. Tracing the problem got me to the following code (pureftpd's log_ldap.c, with a lot of logfile statements inserted by me): 110 static LDAP *pw_ldap_connect(void) 111 { 112 LDAP *ld; 113 # ifdef LDAP_OPT_PROTOCOL_VERSION 114 int version = ldap_version; 115 # endif 116 117 if (ldap_host == NULL || port < 0) { 118 logfile(LOG_DEBUG, "bad host"); 119 return NULL; 120 } 121 logfile(LOG_DEBUG, "initing to host %s port %d", ldap_host, port); 122 if ((ld = ldap_init(ldap_host, port)) == NULL) { 123 logfile(LOG_DEBUG, "init failed"); 124 return NULL; 125 } 126 logfile(LOG_DEBUG, "init ok ld is %p", ld); 127 # ifdef LDAP_OPT_PROTOCOL_VERSION 128 logfile(LOG_DEBUG, "setting version %d", version); 129 if (ldap_set_option(ld, LDAP_OPT_PROTOCOL_VERSION, &version) != 130 LDAP_SUCCESS) { 131 logfile(LOG_DEBUG, "failed versionset"); 132 return NULL; 133 } 134 logfile(LOG_DEBUG, "versionset ok"); 135 # endif 136 logfile(LOG_DEBUG, "binding"); 137 if (ldap_bind_s(ld, root, pwd, LDAP_AUTH_SIMPLE) != LDAP_SUCCESS) { 138 logfile(LOG_DEBUG, "bind failed"); 139 return NULL; 140 } 141 logfile(LOG_DEBUG, "bound ok"); 142 143 return ld; 144 } When running, I get this debug output Dec 29 09:31:10 back-1 pure-ftpd: (?(a)172.28.1.11) [DEBUG] ldap entered Dec 29 09:31:10 back-1 pure-ftpd: (?(a)172.28.1.11) [DEBUG] connecting Dec 29 09:31:10 back-1 pure-ftpd: (?(a)172.28.1.11) [DEBUG] initing to host localhost port 389 Dec 29 09:31:10 back-1 pure-ftpd: (?(a)172.28.1.11) [DEBUG] init ok ld is 0x1297180 Dec 29 09:31:10 back-1 pure-ftpd: (?(a)172.28.1.11) [DEBUG] setting version 3 Dec 29 09:31:10 back-1 kernel: pid 97603 (pure-ftpd), uid 0: exited on signal 11 After that, nothing.. And the forked process dies. As its a forked one, I havent been able to run gdb on it, so I've done the above log entrys instead.. But it seems pretty clear that it crashes when doign ldap_set_option. If i skip the set option and do bind directly, that crashes too. slapd doesnt even see the connection so I guess its something in the client part pure-ftpd: libssl.so.5 => /usr/lib/libssl.so.5 (0x800650000) libcrypto.so.5 => /lib/libcrypto.so.5 (0x80079a000) libldap-2.3.so.2 => /usr/local/lib/libldap-2.3.so.2 (0x800a2a000) liblber-2.3.so.2 => /usr/local/lib/liblber-2.3.so.2 (0x800b64000) libcrypt.so.4 => /lib/libcrypt.so.4 (0x800c72000) libpam.so.4 => /usr/lib/libpam.so.4 (0x800d8b000) libc.so.7 => /lib/libc.so.7 (0x800e93000) libsasl2.so.2 => /usr/local/lib/libsasl2.so.2 (0x8010b0000) Only have one version of the client lib installed so shouldnt be any problems there.. openldap-sasl-client-2.3.39 Open source LDAP client implementation with SASL2 support openldap-server-2.3.39 Open source LDAP server implementation I do have the same setup but with openldap-2.3.38 running fine on a FreeBSD 6.2-i386 box. Haven't seen any problems with the regular ldap* tools on this box, but havent tested any other software yet. Soo.. Anyone got any ideas? Hope this is the correct list, if not, sorry. Thanks! -- Johan Ström Stromnet johan(a)stromnet.se http://www.stromnet.se/

2 5

OpenLDAP and optional kerberos ?
by Nicolas GRENECHE 29 Dec '07

29 Dec '07

Hi all, I need tu replace an old NIS with a topnotch OpenLDAP server. I would like to add SSO support on my brand new architecture. 2 scenarii may occur : 1) Using pam_kerberos to authentaicate against KDC and retreiving information from LDAP server with SASL. The backward is that anyone (or anything) that need to authenticate MUST be kerberos aware. 2) Having LDAP and Kerberos passwords synced. Asset : You can authenticate through LDAP or kerberos (pam_ldap required an pam_kerberos optional) ie you must authenticate against LDAP and if Kerberos autentication success you get a TGT ! Backward : Two password databases to protect / lot of work on client side / passwords must be synced (Do you now materials to do it ?). I add that security is not a major concern for us and we got many OS on client side that's why the 1st solution may not fit our needs. Has someone ever experienced the second solution ? Have you some hints and feedbacks ? Thx, Nico

2 1

slapcat Segmentation fault
by John Sherling 29 Dec '07

29 Dec '07

Running OpenLDAP 2.2.19 on Darwin kernel v. 8.11.1, and when I issue: /usr/sbin/slapcat -d 5 -v -l /Users/localadmin/Desktop/bkup.ldif I get the following output: <snip>... # id=00000070 entry_decode: "cn=raidgroup,cn=groups,dc=fileserver,dc=mydomain,dc=private" <= entry_decode(cn=raidgroup,cn=groups,dc=fileserver,dc=mydomain,dc=private) # id=00000071 slapcat shutdown: initiated Segmentation fault ...</snip> Anyone know how I can track down what's causing this segmentation fault?

2 1

archive test
by Kurt Zeilenga 28 Dec '07

28 Dec '07

Test the archives....

1 0

test message
by Kurt Zeilenga 28 Dec '07

28 Dec '07

test

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical