[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: migrating from (old) /etc/shadow to LDAP
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.)
> Thanks again Chris for your time.
>
> Cheers
> Gerardo
>
>