Re: migrating from (old) /etc/shadow to LDAP
Hi Gerardo,
the 'short strings' You mentioned are 13-character DES password hashes.
For security reasons they should not be used anymore if possible.
Putting {crypt} in front of them should be sufficient for conversion.
Normalizing the passwords might become difficult if only their DES hashes are
available.
Especially in a heterogenous environment using simple authentication together
with
ssl/tls will prevent some trouble.
In that case OpenLDAP will take care of the crypto algorithm, creation of
password hashes and so on while clients just send plaintext passwords
over an encrypted ssl/tls connection to the LDAP server.
This will also prevent trouble if there is no common algorithm supported by
all OS flavors and releases in Your environment which use LDAP for
authentication.
Regards
Juergen
Re: migrating from (old) /etc/shadow to LDAP
juergen.spren...@swisscom.com wrote:
Hi Gerardo,
the 'short strings' You mentioned are 13-character DES password hashes.
For security reasons they should not be used anymore if possible.
It's always interesting to see how things have progressed. ~15 years ago a
desktop processor could perform 130,000 crypts/second, and could crack a
typical 8 character password in ~251 days.
http://personal.stevens.edu/~khockenb/crypt3.html
Skip ahead to 2010 and a single-core desktop processor can do 10 million
crypts/second - so your crack time is now down to ~2.5 days for a single
password, even less for multi-core. Of course, you can crack an entire
password file all in parallel, since you only need to perform a simple
comparison of the crypt result with each password.
http://openwall.info/wiki/john/benchmarks
So if all else fails, you can most likely generate the original plaintext for
the majority of these old passwords in not much time. Of course, having done
that, you probably won't want any of your users to continue using them...
Putting {crypt} in front of them should be sufficient for conversion.
Normalizing the passwords might become difficult if only their DES hashes are
available.
Especially in a heterogenous environment using simple authentication together
with
ssl/tls will prevent some trouble.
In that case OpenLDAP will take care of the crypto algorithm, creation of
password hashes and so on while clients just send plaintext passwords
over an encrypted ssl/tls connection to the LDAP server.
This will also prevent trouble if there is no common algorithm supported by
all OS flavors and releases in Your environment which use LDAP for
authentication.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: migrating from (old) /etc/shadow to LDAP
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 Truelite Srl picca...@truelite.it (email/jabber) Via Monferrato, 6 Tel. +39-347-103243350142 Firenze http://www.truelite.it Tel. +39-055-7879597Fax. +39-055-736
Re: migrating from (old) /etc/shadow to LDAP
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 -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: migrating from (old) /etc/shadow to LDAP
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 -- Simone Piccardi Truelite Srl picca...@truelite.it (email/jabber) Via Monferrato, 6 Tel. +39-347-103243350142 Firenze http://www.truelite.it Tel. +39-055-7879597Fax. +39-055-736
Re: migrating from (old) /etc/shadow to LDAP
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 picca...@truelite.it (email/jabber) Via Monferrato, 6 Tel. +39-347-103243350142 Firenze http://www.truelite.it Tel. +39-055-7879597Fax. +39-055-736
Re: migrating from (old) /etc/shadow to LDAP
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 -- Simone Piccardi Truelite Srl picca...@truelite.it (email/jabber) Via Monferrato, 6 Tel. +39-347-103243350142 Firenze http://www.truelite.it Tel. +39-055-7879597Fax. +39-055-736
Re: migrating from (old) /etc/shadow to LDAP
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 okI 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
Re: migrating from (old) /etc/shadow to LDAP
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 okI 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.)
Thanks again Chris for your time.
Cheers
Gerardo
Re: migrating from (old) /etc/shadow to LDAP
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 okI 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.)
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.
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 okI 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
migrating from (old) /etc/shadow to LDAP
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
Re: migrating from (old) /etc/shadow to LDAP
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
