openldap-technical January 2008

openldap-technical@openldap.org

48 participants
57 discussions

Decoding error when splitting a DN with ldap_str2dn()
by Michael Ströder 07 Jan '08

07 Jan '08

HI! I have a problem splitting a DN with ldap_str2dn(). Actually I'm using it from python-ldap but judging from the debug output there does not seem to be an issue with passing the DN to the OpenLDAP API (see Python console output below). Any clue what's wrong with this DN? OID.0.2.262.1.10.7.20=1 + CN=DIR DATEV D12 1:PN, O=DATEV eG, C=DE BTW: Removing the spaces around , and + does not help either. Ciao, Michael. -------------------------------- snip -------------------------------- Python console: >>> ldap.set_option(ldap.OPT_DEBUG_LEVEL,65535) >>> dn 'OID.0.2.262.1.10.7.20=1 + CN=DIR DATEV D12 1:PN, O=DATEV eG, C=DE' >>> ldap.dn.str2dn(dn) => ldap_bv2dn(OID.0.2.262.1.10.7.20=1 + CN=DIR DATEV D12 1:PN, O=DATEV eG, C=DE,0) ldap_err2string <= ldap_bv2dn(OID.0.2.262.1.10.7.20=1 + CN=DIR DATEV D12 1:PN, O=DATEV eG, C=DE)=-4 Decoding error Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/usr/lib/python2.5/site-packages/ldap/dn.py", line 50, in str2dn return ldap.functions._ldap_function_call(_ldap.str2dn,dn,flags) File "/usr/lib/python2.5/site-packages/ldap/functions.py", line 59, in _ldap_function_call result = func(*args,**kwargs) ldap.DECODING_ERROR >>>

3 4

Relative Distinguished Name searches
by Andrew Bartlett 06 Jan '08

06 Jan '08

In Samba4, I currently have a module that creates and maintains the 'name' attribute for our AD look-alike. Unlike in other systems, where this is related to 'cn', in AD this is always the relative distinguished name. I wondered if it might be possible (by some extended matching of some kind) to transform a search of 'name=foo' into something that does not require the manual maintenance of a samba4RDN attribute? (such a matching might then avoid problems if, in future, we allow clients direct access to the backend). Any thoughts? Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc.

2 1

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical January 2008