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