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
