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)
Thanks!
Gerardo
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!
Gerardo
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 will keep digging, thanks again Chris!
Gerardo
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
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
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.)
Thanks again Chris for your time.
Cheers Gerardo
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
On 11-09-22 10:10 AM, Christopher Wood wrote:
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.)
The authconfig-tui command is very handy and does a few magic for you. If you are connecting via TLS/SSL make sure you put the CA certificate in directory /etc/openldap/cacerts first and run the command afterwards.
On 22/09/2011 16:10, Christopher Wood wrote:
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.)
This, at least for Debian Stable and Ubuntu LTS has an important shortcoming, it does not update shadowLastChange on password change. So if you set a password expiration they will stay expired forever.
It can be made working with a patched smbk5pwd overlay in the openldap server, but that's not present in Debian or Ubuntu.
Simone
Simone Piccardi wrote:
On 22/09/2011 16:10, Christopher Wood wrote:
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.)
This, at least for Debian Stable and Ubuntu LTS has an important shortcoming, it does not update shadowLastChange on password change. So if you set a password expiration they will stay expired forever.
Not a major shortcoming. If you're actually using LDAP then you should set expiration using ppolicy and not using shadow attributes at all.
It can be made working with a patched smbk5pwd overlay in the openldap server, but that's not present in Debian or Ubuntu.
Simone
On 23/09/2011 13:20, Howard Chu wrote:
Not a major shortcoming. If you're actually using LDAP then you should set expiration using ppolicy and not using shadow attributes at all.
Did this solve problems with current nslcd, libnss-ldapd, libpam-ldapd packages on Debian Stable and Ubuntu LTS? I was not aware of this.
Anyway I have more than 80 server in schools, with hundred of students registered in each one. When they where created 6 years ago ppolicy was not an option.
I prefer to install a patched slapd-smbk5passwd package on each server and have a consistent managament of the actual information than reworking the data in each database and make changes in about 2500 client configurations.
Ppolicy could be the future, but I have to deal with the present and the past.
Simone
On Fri, Sep 23, 2011 at 12:19:17PM +0200, Simone Piccardi wrote:
On 22/09/2011 16:10, Christopher Wood wrote:
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.)
This, at least for Debian Stable and Ubuntu LTS has an important shortcoming, it does not update shadowLastChange on password change. So if you set a password expiration they will stay expired forever.
This depends where passwords are maintained. Certainly in your case it sounds like the authoritative password copy is maintained in the directory.
It can be made working with a patched smbk5pwd overlay in the openldap server, but that's not present in Debian or Ubuntu.
Simone
Simone Piccardi Truelite Srl piccardi@truelite.it (email/jabber) Via Monferrato, 6 Tel. +39-347-1032433 50142 Firenze http://www.truelite.it Tel. +39-055-7879597 Fax. +39-055-7333336
On 23/09/2011 14:42, Christopher Wood wrote:
On Fri, Sep 23, 2011 at 12:19:17PM +0200, Simone Piccardi wrote:
On 22/09/2011 16:10, Christopher Wood wrote:
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.)
This, at least for Debian Stable and Ubuntu LTS has an important shortcoming, it does not update shadowLastChange on password change. So if you set a password expiration they will stay expired forever.
This depends where passwords are maintained. Certainly in your case it sounds like the authoritative password copy is maintained in the directory.
The problem I'm talking is not about password, they are just in userPassword.
Problem arise form the lack of managament of shadowLastChange in the current version of nslcd, libnss-ldapd, libpam-ldapd, for both Squeeze and Lucid.
It should work if you use the old libpam-ldap.
Simone
openldap-technical@openldap.org
-
Christopher Wood -
Daniel Qian -
Gerardo Herzig -
Howard Chu -
Simone Piccardi