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