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
- Understanding how pam internally works, and
- 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