I noticed that when I migrated my users with the migrate_passwd.pl tool from PADL it didn't migrate the actual passwords (just the rest of the posixAccount info). I think I need to set the EXTENDED_SCHEMA variable and then try running the tool again. does anyone know what this should be?
I actually thought there might be a migrate_shadow.pl tool that could accomplish this, but there doesn't appear to be anything like that among the PADL migration tools.
So in short the user info is there in LDAP but no one can log in because all the password fields look like this: userPassword: {crypt}*
Here is a more complete user entry that is currently in the system:
73 uid=bluethundr,ou=summitnjops,ou=staff,dc=summitnjhome,dc=com uid: bluethundr cn: Timothy P. givenName: Timothy P. sn: Dunphy objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: posixAccount loginShell: /usr/local/bin/bash uidNumber: 1001 gidNumber: 1002 homeDirectory: /home/bluethundr gecos: Timothy P. userPassword: {crypt}*
thanks in advance for any tips you can share that will get this working!
On Fri, 2010-10-29 at 09:00 -0400, Tim Dunphy wrote:
I noticed that when I migrated my users with the migrate_passwd.pl tool from PADL it didn't migrate the actual passwords (just the rest of the posixAccount info). I think I need to set the EXTENDED_SCHEMA variable and then try running the tool again. does anyone know what this should be? I actually thought there might be a migrate_shadow.pl tool that could accomplish this, but there doesn't appear to be anything like that among the PADL migration tools.
I'd *strongly* recommend *not* using the PADL migration scripts. Morphing your system data into LDAP is pretty simple if you are familiar with any scripting language. You should carefully think through what you want in the DSA and how you want it represented, then make the LDIF files accordingly.
See http://mosg.googlegroups.com/web/LDAP102.pdf?gda=OkhSRj0AAABGYSQZGnP1p0-ZaG58b_-Dpp2Ky__YopapPAxAcIb5YKjfyxwalkQMu975yVukqHflNv--OykrTYJH3lVGu2Z5 for some simple example (slides 27 - 29)
So in short the user info is there in LDAP but no one can log in because all the password fields look like this: userPassword: {crypt}* Here is a more complete user entry that is currently in the system:
On Fri, Oct 29, 2010 at 10:15:32AM -0400, Adam Tauno Williams wrote:
On Fri, 2010-10-29 at 09:00 -0400, Tim Dunphy wrote:
I noticed that when I migrated my users with the migrate_passwd.pl tool from PADL it didn't migrate the actual passwords (just the rest of the posixAccount info). I think I need to set the EXTENDED_SCHEMA variable and then try running the tool again. does anyone know what this should be? I actually thought there might be a migrate_shadow.pl tool that could accomplish this, but there doesn't appear to be anything like that among the PADL migration tools.
I wonder if you did it as root. If not, it doesn't include the passwords. (That is, the script will run as regular user, but will not include passwords.)
I'd *strongly* recommend *not* using the PADL migration scripts. Morphing your system data into LDAP is pretty simple if you are familiar with any scripting language. You should carefully think through what you want in the DSA and how you want it represented, then make the LDIF files accordingly.
I would have argued that two years ago, but I've come to the conclusion that this is true. I might use it to create a sample ldif when I forget some syntax, but I find myself using the padl scripts less and less. This is not to say that (IMNSKO, not so knowledgeable--the rest I'm sure you folks know), they're bad per se, just that as one gets more experienced, there are better ways of doing it.
See http://mosg.googlegroups.com/web/LDAP102.pdf?gda=OkhSRj0AAABGYSQZGnP1p0-ZaG58b_-Dpp2Ky__YopapPAxAcIb5YKjfyxwalkQMu975yVukqHflNv--OykrTYJH3lVGu2Z5 for some simple example (slides 27 - 29)
Excellent link, thank you, even though I'm not the OP.
I noticed that when I migrated my users with the migrate_passwd.pl tool from PADL it didn't migrate the actual passwords (just the rest of the posixAccount info). I think I need to set the EXTENDED_SCHEMA variable and then try running the tool again. does anyone know what this should be?
$EXTENDED_SCHEMA = 1;
I actually thought there might be a migrate_shadow.pl tool that could accomplish this, but there doesn't appear to be anything like that among the PADL migration tools.
Correct, just the migrate_passwd.pl script.
So in short the user info is there in LDAP but no one can log in because all the password fields look like this: userPassword: {crypt}*
That's a result when there is no password set for the user to be migrated (see man 5 shadow).
Here is a more complete user entry that is currently in the system:
73 uid=bluethundr,ou=summitnjops,ou=staff,dc=summitnjhome,dc=com uid: bluethundr cn: Timothy P. givenName: Timothy P. sn: Dunphy objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: posixAccount loginShell: /usr/local/bin/bash uidNumber: 1001 gidNumber: 1002 homeDirectory: /home/bluethundr gecos: Timothy P. userPassword: {crypt}*
The PADL script blindly uses {crypt}, although the password encryption mechanism may be very different.
thanks in advance for any tips you can share that will get this working!
Alexander
On Fri, 29 Oct 2010 16:42:41 +0200 (CEST) "Alexander Dalloz" ad+lists@uni-x.org wrote
<SNIP>
The PADL script blindly uses {crypt}, although the password encryption mechanism may be very different.
thanks in advance for any tips you can share that will get this working!
Alexander
I think Alexander is onto something here. I just checked my default CentOS 5 installation and /etc/sysconfig/authconfig specifies that the passwords are hashed using MD5, so there's a good chance yours is too. We ran into a problem with this when we migrated users to the Sun directory server (not my choice!). The {?} part of the userPassword field value specifies the hash method used, so if OpenLDAP supports MD5 you may be able to just do a global search-and-replace of '{crypt}' with '{MD5}'.
OTOH, if the "*" you showed in the message was literal, you'll probably have to do some additional work to retrieve the user's password from /etc/shadow and plug that in instead. You could just cobble up a script to generate a simple LDIF file just to change the passwords if you don't want to alter the output of the PDL scripts. The format is pretty simple, just look at the ldapmodify man page for hints. Just scan through /etc/shadow and look for something with a pasword <> "!!" and generate the LDIF to change that user's password.
Just my $.02! -- Jay Leafey - Memphis, TN jay.leafey@mindless.com
hey guys, nice suggestions.. it looks like PADL did not cover shadow entries for some reason.. this will likely have to be a custom script i will have to write...
in the meantime I made sure I was root and then ran the scripts:
Hey guys,
The script definitely ran as root:
LBSD2# whoami root
LBSD2# ./migrate_passwd.pl /etc/passwd /tmp/passwd.ldif
This is an ldif entry that resulted:
dn: uid=bluethundr,ou=People,dc=summitnjhome,dc=com uid: bluethundr cn: Timothy P. givenName: Timothy P. sn: mail: bluethundr@padl.com mailRoutingAddress: bluethundr@mail.padl.com mailHost: mail.padl.com objectClass: inetLocalMailRecipient objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: posixAccount objectClass: top objectClass: kerberosSecurityObject userPassword: {crypt}* krbName: bluethundr@PADL.COM loginShell: /usr/local/bin/bash uidNumber: 1001 gidNumber: 1002 homeDirectory: /home/bluethundr gecos: Timothy P.
so no mater if you are root passwords are not transferred...
On Fri, Oct 29, 2010 at 11:24 AM, jleafey jay.leafey@mindless.com wrote:
On Fri, 29 Oct 2010 16:42:41 +0200 (CEST) "Alexander Dalloz" ad+lists@uni-x.org wrote
<SNIP>
The PADL script blindly uses {crypt}, although the password encryption mechanism may be very different.
thanks in advance for any tips you can share that will get this working!
Alexander
I think Alexander is onto something here. I just checked my default CentOS 5 installation and /etc/sysconfig/authconfig specifies that the passwords are hashed using MD5, so there's a good chance yours is too. We ran into a problem with this when we migrated users to the Sun directory server (not my choice!). The {?} part of the userPassword field value specifies the hash method used, so if OpenLDAP supports MD5 you may be able to just do a global search-and-replace of '{crypt}' with '{MD5}'.
OTOH, if the "*" you showed in the message was literal, you'll probably have to do some additional work to retrieve the user's password from /etc/shadow and plug that in instead. You could just cobble up a script to generate a simple LDIF file just to change the passwords if you don't want to alter the output of the PDL scripts. The format is pretty simple, just look at the ldapmodify man page for hints. Just scan through /etc/shadow and look for something with a pasword <> "!!" and generate the LDIF to change that user's password.
Just my $.02!
Jay Leafey - Memphis, TN jay.leafey@mindless.com
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On 10/29/2010 04:00 PM, Tim Dunphy wrote:
hey guys, nice suggestions.. it looks like PADL did not cover shadow entries for some reason.. this will likely have to be a custom script i will have to write...
I'm sure there are plenty floating around. Try mine: http://phantom.dragonsdawn.net/~gordon/importAccounts/importAccounts
-
Adam Tauno Williams -
Alexander Dalloz -
Gordon Messmer -
jleafey -
Scott Robbins -
Tim Dunphy