openldap-technical

openldap-technical@openldap.org

14 participants
9795 discussions

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 22 Apr '09

22 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

Directory migration
by Ian Moore 21 Apr '09

21 Apr '09

Hi, I'm trying to migrate my directory from one server to another (I'm building a replacement server and want to test everything before changing over). The old server is FreeBSD 5 with openldap-server-2.3.39 The new one is FreeBSD 7.1 with openldap-server-2.3.43 I thought I would be able to use ldapsearch to dump the contents of the old server to an ldif file and then import it into the new one using ldapadd. That seemed to work, but when I tried to login on a workstation which is configured to use ldap authentication (and works fine when attached to the old server), my login fails. If I change my password to what it's supposed to be and then try to login, it works. So it appears that the passwords for user objects are not being transferred correctly from the old system to the new (all the other information seems correct). I'm using md5 passwords on both systems (the freebsd default) and I've checked that the new server & the workstation are set to use md5. I also tried using slapcat to create the ldif file, but that made no difference. If I look at the encrypted password before and after resetting it, the password hashes are different, even though they are supposedly the same password. I've tried this several times and can't get it to work. Do I need to do something else to transfer passwords correctly from one server to another? -- Ian gpg key: http://home.swiftdsl.com.au/~imoore/no-spam.asc

3 2

Need help on pwdCheckQuality
by Dat Duong 20 Apr '09

20 Apr '09

Hi, I need to enforce the password quality check. I've set all the the requirement on the slapd.conf created default policies profile. Unfortunately, the pwdMinLength and pwdCheckQuality are not working. I also try to compile the cracklib with check_password.c and the Makefile. The instruction was not very clear. Does anyone have a procedure to install the check_password.so module? Please help me with this. See my below setting. I omitted all the other parts from slapd.conf.. slapd.conf file: ..... ..... include /usr/local/etc/openldap/schema/ppolicy.schema ..... overlay ppolicy ppolicy_default "cn=default,ou=policies,dc=example,dc=com" ppolicy_hash_cleartext ppolicy_use_lockout ..... # default, policies, arc.nasa.gov dn: cn=default,ou=policies,dc=example,dc=com cn: default objectClass: pwdPolicy objectClass: person objectClass: top objectClass: pwdPolicyChecker pwdAllowUserChange: TRUE pwdAttribute: userPassword pwdExpireWarning: 180 pwdFailureCountInterval: 30 pwdGraceAuthNLimit: 5 pwdInHistory: 24 pwdLockout: TRUE pwdLockoutDuration: 1800 pwdMaxAge: 15768000 pwdMaxFailure: 5 pwdMinAge: 0 pwdMinLength: 12 pwdMustChange: TRUE pwdSafeModify: FALSE sn: default policy pwdCheckModule: check_password.so pwdCheckQuality: 2 THANKS!!!

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical