[Date Prev][Date Next] [Chronological] [Thread] [Top]

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

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.
> I will keep digging, thanks again Chris!
> Gerardo