Re: migrating from (old) /etc/shadow to LDAP

[Gerardo Herzig <gherzig@fmed.uba.ar>]

El jue, 22-09-2011 a las 10:10 -0400, Christopher Wood escribiÃ:
> On Thu, Sep 22, 2011 at 07:50:50AM -0300, Gerardo Herzig wrote:
> > El miÃ, 21-09-2011 a las 10:16 -0400, Christopher Wood escribiÃ:
> > > On Wed, Sep 21, 2011 at 07:51:34AM -0300, Gerardo Herzig wrote:
> > > > El mar, 20-09-2011 a las 19:18 -0400, Christopher Wood escribiÃ:
> > > > > On Tue, Sep 20, 2011 at 05:57:29PM -0300, Gerardo Herzig wrote:
> > > > > > Hi all. Im migrating the /etc/shadow accounts to an LDAP enviroment.
> > > > > > 
> > > > > > As the /etc/shadow containing server has suffered several upgrades,
> > > > > > there is more than one crypto mechanism applied.
> > > > > > 
> > > > > > Some entries are in the form $2a$10$..... this is an {CRYPT} entry, and
> > > > > > have no problems with that.
> > > > > > 
> > > > > > Others (the oldest ones) doesn't seem to have a prefix at all. There are
> > > > > > "short" strings like 
> > > > > > bHwTgdCTnfpco
> > > > > > lJvWLr8sfW.Hg
> > > > > > and so on...
> > > > > > 
> > > > > > I tried with {MD5}, {SHA} + encrypted password with no luck.
> > > > > > 
> > > > > > Any one knows which crypto mechanism is applied here? I think they are
> > > > > > from an old Suse 9.1 (not the Enterprise Server Edition, the realy old
> > > > > > SuSE 9.1)
> > > > > 
> > > > > They look like plain crypts, of the original {CRYPT} kind.
> > > > >  
> > > > Thanks Chris for your answer. I dont know what to say...{CRYPT} is
> > > > working for the $2a$10$... kind of entries, but not for the other
> > > > kind...Obviously it is a hash, because i can do a ssh with the user and
> > > > it is working ok....I am missing something here, but cant figure out
> > > > what is...
> > > 
> > > I realize I should have expanded my answer. Please take what I say with a grain of salt, given that I haven't had much experience with your issue.
> > > 
> > > First, make sure that when you ssh, ssh is authenticating via ldap and not through /etc/shadow, or through ssh keys. Best to test your ldap authentications on a naked test machine (where the only userid is something definitely not in ldap).
> > > 
> > > There is a difference (in OpenLDAP treatment as far as I know, both use the crypt of "password") between this:
> > > 
> > > userPassword: {CRYPT}qrYJvxP/8txGA
> > > 
> > > And this:
> > > 
> > > userPassword: qrYJvxP/8txGA
> > > 
> > > In the first case, if you've compiled OpenLDAP with crypt support (--enable-crypt when compiling), you can bind against the DN with that password.
> > > 
> > > In the second case, you cannot bind against the DN. (I've seen the second case in the wild, used by an application that does an ldapsearch to retrieve a user's credentials, then compares the crypt of the password the user entered with the literal value of userPassword.)
> > > 
> > > In your migration script you can check the length of the password field in /etc/shadow, and if it's the right length prepend a '{CRYPT}' string to it. Of course this assumes that user authentication will be checked with a directory bind, not a directory search/compare.
> > >  
> > 
> > Thanks again Chris. The ssh session is authenticated in the "usual" way
> > (via PAM i guess), *not* via LDAP. If my understanding of the situation
> > is good, the thing is that ldap is linked to the standard crypt library
> > (for compatibility reasons), and it seems like PAM authentication method
> > contains more than one method to check the password against.
> > 
> > So, now im focus in 
> > 1) Understanding how pam internally works, and
> > 2) finding a tool to 'normalize' all the passwords to the last version
> > of the crypt library.
> > 
> > And failing misserably at both!! :$
> 
> Depending on your platform you may need extra packages and config. (This is what worked for me, perhaps something in here could be superfluous.)
> 
> RedHat/CentOS 5: install nscd and nss_ldap, configure /etc/ldap.conf, and ensure you have "files ldap" as lookups listed in /etc/nsswitch.conf for passwd, group, shadow.
> 
> Debian/Ubuntu: install nslcd, libnss-ldapd, libpam-ldapd, configure your /etc/nslcd.conf, and ensure you have "compat ldap" as lookups listed in /etc/nsswitch.conf for passwd, group, shadow. (I figure on the whole nss-pam-ldapd arrangement for CentOS6 too, but I haven't gotten that far yet.)

After all this noise, i just recompile ldap with --with-crypt option,
and now it looks like it is using the native C crypt() instead of the
openssl crypt() function.

Damn precompiled binaries!!

Thanks again Chris for all your help, and very sory about the noise.

Cheers.
Gerardo