openldap-technical

openldap-technical@openldap.org

5 participants
9991 discussions

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

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

TLS vs. MirrorMode replication
by Maros Timko 19 Apr '09

19 Apr '09

Hi all, we use OpenLDAP 2.4.11 on CentOS 5 for OS user PAM authentication in Xen-based HA cluster of 2 nodes. We are using MirrorMode replication so that databases are synchronised if change occurs on any node and there is no issue if one node goes down - each node maintains its own database. We use non-TLS local LDAP access (127.0.0.1) on Dom0 and TLS from virtual machines to LDAP. As soon as LDAP replication is set up in non-TLS way, everything works fine. But we are trying to set up TLS also for replication to bring more security into the system. However, it seems like there is a principial issue here - one cannot specify client access config for local access and for remote replication at the same time. Or can we? If we define client config to use TLS for the peer, then each local request goes to peer node. If the peer is down, the request will fail and user cannot log in into the OS. It looks like syncrepl requires client configuration to the peer. We tried to use "start_tls" option in syncrepl section but we still fail to connect to peer node. From the replies on the list I assume, TLS options in syncrepl section are just supposed to overwrite default settings, not to specify explicit option for it. Questions: - Is it possible to use local LDAP database locally together with TLS-enabled replication in a cluster? - Is anybody running such or similar setup successfully? - What would you suggest, if it is not possible? Thanks

2 1

Integration
by A Gilmore 18 Apr '09

18 Apr '09

Hello, I have a technical hurdle to overcome and I'm hoping openldap is the answer. I have contacts in a sql db, I'm wanting to make them available in outlook, blackberries, and other clients such as thunderbird. What I'm currently thinking is to setup an openldap server and import the data into that. I'm not expecting much trouble getting the data into LDAP. But how much effort/time is normally involved in the actual implementation of hooking these devices/applications to an openldap directory so non-technical users can use it? If anyone else has done this, how did it go? Has it been 'quirky'? I've read over the FAQ and what google offers, it seems mostly dealing with overcoming specific technical issues, I haven't found much on how well it works overall. Thank you for your time, - Adrien

2 2

Compile module for pwdCheckQuality
by Dat Duong 18 Apr '09

18 Apr '09

Does anyone have good luck on compiling a module like check_password.so for pwdCheckQuality? Also, what are the configuration for check_password.conf ? I'm having a harding time compiling the cracklib using check_password Makefile. Anyone have for the Makefile? What is the -lcrack ? # Comment out this line if you do NOT want to use the cracklib. # You may have to add an -Ldirectory if the libcrak is not in a standard # location # CRACKLIB_LIB=-lcrack

1 0

Context CSN not updated on OpenLDAP 2.3.11
by Adrien Futschik 17 Apr '09

17 Apr '09

Hy everyone ! I am facing a major issued for the second time with OpenLDAP 2.3.11. I am aware it is a pretty old version of OpenLDAP, but, it has been working in production for almost a year now without any problem. Here is the setup : Master -> Slave For some strange reason, the contextCSN stops updating and therefore the Slave is not updated anymore. The strange thing is that the Master continues to successfully update/add data ! We are using a OpenLDAP 2.3.11, Berkeley DB 4.4.16 & OpenSSL 0.9.8a all running on Solaris 10. Restarting the master solved the problem once, but now that it as failed again, I am very woried, because, restarting isn't a solution, considering that the application is in production. Please see in attachement the configuration files for Master & Slave. I have no log on the master, and only "syncrepl logging" on the slave. We consider restarting the master with "enable all logging" to see if wee can grab some informations.... Is this a bug of OpenLDAP, BerkleyDB or something else ? Thanks in advance, Adrien Futschik

4 11

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical