openldap-technical April 2009

openldap-technical@openldap.org

71 participants
79 discussions

Adding OU with PSQL backend
by Marcel Berteler 23 Apr '09

23 Apr '09

For a project that requires a large user authentication database, we are currently using OpenLDAP with a BDB backend. We have about 150K users in the tree and all works well. Authentication and new user creation is fast and we are happy. But, when we try and get statistical data from the tree, we run into the limitations of LDAP: trying to find all user that have registered last month, using a filter with 2 dates, is just too slow. It takes minutes to come back with a result. To get around this limitation, we want to experiment with a PSQL backend so we can do some comparative testing. (If any of you have a way of allowing us to interrogate our BDB backend with SQL like queries that are relatively fast, than please let me know.) Our test environment: openldap 2.4.16 with Postgres backend I have loaded CORE in slapd.conf as well as our custom schema for our users The only ACL in the conf is ACCESS TO * BY * WRITE Our tree looks like this and I have loaded the data tables and meta-data tables: dc=example,dc=come ou=people,dc=example,dc=com cn=user1,dc=example,dc=com The setup is working about 60%. with openLdapAdmin, I can see the tree and I can add users. What I can not do, is add an OU. It gives me: LDAP said: Server is unwilling to perform Error number: 0x35 (LDAP_UNWILLING_TO_PERFORM) Description: The LDAP server refused to perform the operation. If I get this on our custom schema, I can explain this by not having the right meta-data and procedures loaded. But as this is part of the CORE schema, am I right in only adding the meta-data for OU in ldap_attr_mappings without add or delete procedures? I have looked at the log files and outputs but I can not figure out what is going wrong and why it is not accepting any new OU Any help is appreciated. -- Regards, Marcel Berteler *Chief Information Officer */"May the source be with you"/ Website: http://www.bdsolutions.co.za Email Legal Notice: http://www.bdsolutions.co.za/legal/

7 16

just curious
by Piotr Wadas 22 Apr '09

22 Apr '09

Hello, I've been trying past weeks upgrading my production openldap software. I started from 2.4.11 when it was available, through all available versions, up to 2.4.16. I tried package builds, and my own builds. Each version except 2.4.10 was likely to hang, as it's production, and load is quite high, I haven't too much patience to debug and researching what's actually going on, but I tried disabling syncrepl (no effect), some different settings for bdb backend and slapd thread, concurrency etc ( starting from settings which caused no problems with 2.4.10 ), and finally, got back to 2.4.10 which works fine. Between version change I noticed that 2.4.11+ is build with newer libdb versions (package depends), starting from libdb4.2 (2.4.10), up to libdb4.7 (newer openldap version). I didn't try to build 2.4.15+ with some old (4.2) libdb. Is it some major significant jump between 2.4.10 and all later versions? some general rewrite of some feature ? It's not syncrepl related, as daemon hang no matter whether configured as slave or standalone. The symptoms was, it was (in general) producing BIGGER server load than 2.4.10, and, although daemon process did not segfaults, server stopped responding for requests (?). With higher load I wasn't able to try logging and use of debug symbols. I expected it will work without any slapd.conf, anyway nor leaving it untouched, nor some minor reasonable changes had no effect. So, what's going on? :) Is it possibly related to libdb ? or what? What else could it be ? Except libdb ( 5 different versions available in my system with one default, usually newest ), there was no other software change, just upgrading openldap/libldap. Any clues you may have? I'm sorry I cannot provide more information, anyway config is rather standard and simple, some custom schemas added with indexing, that's all. 2.4.10 has no problems at all, and significantly lower general machine load. ( if 2.4.10 = 100%, 2.4.11+ makes 300-400% ) Actually I'm not expecting some miracle explanation, anyway it's interesting what could it be.. I have about 25 000 entries total in my directory tree, it's used as NSS source, and other information for various applications. regards :) P.

3 4

Porting mozldap to openldap
by Nguyen, Quang 22 Apr '09

22 Apr '09

Hi everybody, I have spend sometime to understand mozldap and openldap. I have searched the archives using these keyword "mozldap to openldap" or just "mozldap" but found nothing. I have to port an application currently using mozldap to openldap. Has anyone done this before, I would like to ask some questions such as: 1. I see that the application called ldapssl_advclientauth_init(), ldapssl_init() if using certificate and call prldap_init() if using simple authentication. The function ldapssl_advclientauth_init() is very big after I traced it down. Is there an equivalent call in openldap? 2. Is there any example posted somewhere that my search on google missed (I could not find any). 3. Is there anything I should be watching for? 4. What is the best approach to do this? I thank you very much for any help, suggestion I can get. Best regards

2 2

Setting up LDAP server
by Santosh Balan 22 Apr '09

22 Apr '09

Hi Friends, Can anyone help me on implementing and configuring LDAP server to authenticate users with system policies and auto mount a user's partition provided to him. Also, I want it to authenticate qmail users using LDAP. Your assistance is highly appreciable. Thanking you in advance. Thanks and Regards Santosh Balan 9819419509 -- It's News. It's Reviews. It's Interviews. It's Free. What Are You Waiting For? www.movieline.com

2 1

ldap SQL backend and syncrepl
by Frederic Bouy 22 Apr '09

22 Apr '09

Hello, For performance issues (millions or records) I have two ldap servers: - one master with an sql backend (postgres) to allow easy data manipulation - one slave to anwer ldap queries and provide good response time When lauching the slave ("./slapd -f /usr/local/openldap/etc/openldap/slapd-front.conf -h "ldap://localhost:3890" -d 1") I got a first non blocking error I don't really understand: " => bdb_dn2id("dc=lnp") <= bdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found (-30988)" According to the fact that the following command is successfull: "ldapwhoami -H "ldap://localhost:389" -D "cn=manager,dc=lnp" -w secret" and then the synchronization fails with this error: "read1msg: ld 0x9ca73e8 msgid 2 message type search-entry ber_scanf fmt ({xx) ber: ber_scanf fmt ({a) ber: ber_scanf fmt (o) ber: ber_scanf fmt ({em) ber: do_syncrep2: rid=001 got empty syncUUID with LDAP_SYNC_ADD ldap_msgfree connection_get(11): got connid=0 ldap_free_request (origid 2, msgid 2) ldap_free_connection 1 1 ldap_send_unbind ber_flush2: 7 bytes to sd 11 ldap_free_connection: actually freed do_syncrepl: rid=001 quitting" Do you know whether suncrepl is support for ldap with sql backend? Do you know where can I find some documentation on this? Do you have any clue on how I could solve my issues? Thanks in advance. Please find below the .conf of those two ldap servers: # === MASTER ===== include /usr/local/openldap/etc/openldap/schema/core.schema include /usr/local/openldap/etc/openldap/schema/cosine.schema include /usr/local/openldap/etc/openldap/schema/nis.schema include /usr/local/openldap/etc/openldap/schema/inetorgperson.schema include /usr/local/openldap/etc/openldap/schema/lnp.schema pidfile /usr/local/openldap/var/slapd-lnp.pid argsfile /usr/local/openldap/var/slapd-lnp.args backend sql ####################################################################### # sql database definitions ####################################################################### database sql suffix "dc=lnp" rootdn "cn=Manager,dc=lnp" rootpw secret dbname lnp dbuser lnp dbpasswd lnp strcast_func "text" #subtree_cond "ldap.entries.dn like '%'||?" concat_pattern "?||?" has_ldapinfo_dn_ru no overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 lastmod on # === MASTER ===== include /usr/local/openldap/etc/openldap/schema/core.schema include /usr/local/openldap/etc/openldap/schema/cosine.schema include /usr/local/openldap/etc/openldap/schema/nis.schema include /usr/local/openldap/etc/openldap/schema/inetorgperson.schema include /usr/local/openldap/etc/openldap/schema/lnp.schema pidfile /usr/local/openldap/var/run/slapd-front.pid argsfile /usr/local/openldap/var/run/slapd-front.args ####################################################################### # BDB database definitions ####################################################################### database bdb suffix "dc=lnp" rootdn "cn=Manager,dc=lnp" rootpw secret directory /usr/local/openldap/var/openldap-data # index entryCSN,entryUUID eq index entryUUID eq # filter="(objectClass=*)" syncrepl rid=001 provider=ldap://localhost:389 bindmethod=simple type=refreshAndPersist searchbase="ou=31,dc=lnp" schemachecking=off binddn="cn=manager,dc=lnp" credentials=secret filter="(objectClass=*)" mirrormode on serverID 1

4 7

Re: Directory migration
by Michael Ströder 22 Apr '09

22 Apr '09

Ian wrote: > On Tue, 21 Apr 2009 23:07:11 Michael Ströder wrote: >> Hmm, which password scheme is used? Are the userPassword values prefixed >> with {MD5} or with {CRYPT}? In the latter case libcrypt on both systems >> could be incompatible. So this could be another issue. The general >> advice is not to use {CRYPT}. Recommended is to use salted SHA-1 >> (password scheme {SSHA}). > > Well FreeBSD is using MD5 for it's encryption and so is the linux workstation. This does not say much since there are also MD5-based password hashes in Unix crypt. > Is the LDAP server encrypting the hashes as well? No, the clear-text password is hashed depending on the password scheme together with a random salt. > They don't look like the > hashes in master.password What is master.password? > at all, so I guess it is? And that's one reason why > you need to use the PADL scripts when you import /etc/passwd into your LDAP > directory? If you import /etc/shadow or whereever your salted Unix password hashes are stored you would use the platform-specific password scheme {CRYPT}. > The password entry looks like this: > userPassword:: e21kNX01NDdxRWpMNXlRbmZJcDdhREFYZDh3PT0= ^^ The double-colon indicates that the value is base64-encoded in the LDIF representation. $ python -c "print 'e21kNX01NDdxRWpMNXlRbmZJcDdhREFYZDh3PT0='.decode('base64')" {md5}547qEjL5yQnfIp7aDAXd8w== So this is a plain MD5-hashed password. This password scheme is *not* platform-specific. Is this from your original data? Do all entries have password values like this? Check that. If yes, then you should not have a problem to migrate this data. > So I don't know what encoding it's using - is there a setting that controls > this? (nothing in slapd.conf that I can see). There are various relevant settings. But I wonder which component is used for setting the password and which mechanism it uses. You should also consult the fine articles in the FAQ-O-MATIC: http://www.openldap.org/faq/data/cache/419.html Ciao, Michael.

2 1

Re: Directory migration
by Michael Ströder 22 Apr '09

22 Apr '09

Ian wrote: > On Wed, 22 Apr 2009 00:04:47 Andrew Findlay wrote: >> On Tue, Apr 21, 2009 at 03:37:11PM +0200, Michael Ströder wrote: >>> Hmm, which password scheme is used? Are the userPassword values prefixed >>> with {MD5} or with {CRYPT}? In the latter case libcrypt on both systems >>> could be incompatible. So this could be another issue. The general >>> advice is not to use {CRYPT}. Recommended is to use salted SHA-1 >>> (password scheme {SSHA}). >> You also need to make sure that the new server was built with support >> for your chosen hash scheme. If using crypt passwords, this means >> adding the --enable-crypt flag to the initial 'configure' command. > > Maybe that's where the problem lies. From what Michael said in his reply, the > passwords are plain MD5 hashes. Perhaps I've build the new one with crypt > support and it's trying to use that instead of straight MD5? The password scheme {MD5} does not need --enable-crypt! >> As Michael says, it would make sense to use 2.4.16 for your >> new installation. > > And I shall, but maybe now it's best to get 2.3.x working first, then go to > the new version. You might have to migrate your database. So there's really no reason to not directly use 2.4.16. Ciao, Michael.

1 0

Re: Directory migration
by Ian Moore 21 Apr '09

21 Apr '09

On Wed, 22 Apr 2009 00:13:51 Michael Ströder wrote: > Ian wrote: > > On Tue, 21 Apr 2009 23:07:11 Michael Ströder wrote: > >> Hmm, which password scheme is used? Are the userPassword values prefixed > >> with {MD5} or with {CRYPT}? In the latter case libcrypt on both systems > >> could be incompatible. So this could be another issue. The general > >> advice is not to use {CRYPT}. Recommended is to use salted SHA-1 > >> (password scheme {SSHA}). > > > > Well FreeBSD is using MD5 for it's encryption and so is the linux > > workstation. > > This does not say much since there are also MD5-based password hashes in > Unix crypt. > > > Is the LDAP server encrypting the hashes as well? > > No, the clear-text password is hashed depending on the password scheme > together with a random salt. > > > They don't look like the > > hashes in master.password > > What is master.password? :-) FBSD equivalent of /etc/shadow > > at all, so I guess it is? And that's one reason why > > you need to use the PADL scripts when you import /etc/passwd into your > > LDAP directory? > > If you import /etc/shadow or whereever your salted Unix password hashes > are stored you would use the platform-specific password scheme {CRYPT}. > > > The password entry looks like this: > > userPassword:: e21kNX01NDdxRWpMNXlRbmZJcDdhREFYZDh3PT0= > > ^^ > The double-colon indicates that the value is base64-encoded in the LDIF > representation. > > $ python -c "print > 'e21kNX01NDdxRWpMNXlRbmZJcDdhREFYZDh3PT0='.decode('base64')" > {md5}547qEjL5yQnfIp7aDAXd8w== > > So this is a plain MD5-hashed password. This password scheme is *not* > platform-specific. So I guess that's why it works logging in from a linux workstation, even though the passwords originally were imported from the FBSD master.passwd file and also works with squid running on the FBSD server. > Is this from your original data? Yes, taken from the original server's LDAP database. > Do all entries have password values like this? Check that. Yes, they do! > If yes, then you should not have a problem to migrate this data. Yet sadly I do have a problem :-/ I have used ldapsearch to confirm that the password hashes are the same on the old & new servers when I use ldapsearch or slapcat to view them. Yet I can't login on the new server. And since the hashes are salted, I can't tell if the actual password is really different. > > > So I don't know what encoding it's using - is there a setting that > > controls this? (nothing in slapd.conf that I can see). > > There are various relevant settings. But I wonder which component is > used for setting the password and which mechanism it uses. > > You should also consult the fine articles in the FAQ-O-MATIC: > > http://www.openldap.org/faq/data/cache/419.html I'll give that a read tonight and do some more testing. Cheers, -- Ian gpg key: http://home.swiftdsl.com.au/~imoore/no-spam.asc

1 0

Re: Master server error
by Gavin Henry 21 Apr '09

21 Apr '09

----- "Ivan Ordonez" <iordonez(a)nature.berkeley.edu> wrote: > Hi, > > Just wondering why the master server is trying to contact the slave > when > I use any of the smbldap tools? I would get the message below. > > erreur LDAP: Can't contact slave ldap server (IO::Socket::INET: > connect: > timeout) > =>trying to contact the master server > > It would then contact the master server and give me the result. > Instead > of pulling the information faster, it will take a few minutes. It is > > not a big deal, as things are working fine but I just want to know if > > there's a way to get rid of the error. Please advise. > This is actually to do with the smbldap tools, not OpenLDAP. Check the config file for the master/slave settings and the Perl code too. The master isn't trying to contact the slave at ;-) Thanks. -- 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/ Suretec Systems is a limited company registered in Scotland. Registered number: SC258005. Registered office: 13 Whiteley Well Place, Inverurie, Aberdeenshire, AB51 4FP. Subject to disclaimer at http://www.suretecgroup.com/disclaimer.html

2 1

Master server error
by Ivan Ordonez 21 Apr '09

21 Apr '09

Hi, Just wondering why the master server is trying to contact the slave when I use any of the smbldap tools? I would get the message below. erreur LDAP: Can't contact slave ldap server (IO::Socket::INET: connect: timeout) =>trying to contact the master server It would then contact the master server and give me the result. Instead of pulling the information faster, it will take a few minutes. It is not a big deal, as things are working fine but I just want to know if there's a way to get rid of the error. Please advise. Thanks, -Ivan

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical April 2009