PDA

View Full Version : Migrating SLES LDAP (and CYRUS) from SLES 10 to SLES 11



endc01
25-Nov-2012, 21:11
I am running a full operational SLES 10 LDAP system with Cyrus/Postfix...
Now trying to configure a already up and running SLES 11 system to provide exactly the same functionality...

There is no change in LDAP architecture needed... in terms of changing the DC...

Is there a "how to" for migrating manually SLES 10 LDAP to SLES 11??


Advice is highly appreciated...

Mike

endc01
25-Nov-2012, 22:05
Ok... Trick is to run yast mailserver config first... then export old ldiff and import... to new system...

Did I miss something???

Cheers...

M.

jmozdzen
27-Nov-2012, 16:40
Hi M.,

> Did I miss something???

if you set up non-default schema files in the SLES10 LDAP, you'll need to provide these in SLES11 as well. Did you go for the new LDIF-based configuration of OpenLDAP or keep the old config file stuff?

While I don't see any practical difficulties (we're running an SLES10 to SLES11 upgraded LDAP to serve SLES10, SLES11 and other servers), there may have been changes in the information structure - I wouldn't export all and any information of the old LDAP tree, but just the account data (user and probably group) and see how it goes.

Concerning the IMAP migration: Once you've set up all required accounts/mboxes, you might consider using an IMAP-based migration tool to transfer the old mailboxes' contents to the new server.

It's been a long time since I had to do this myself, so my memory may be a bit vague... but at least you have the fortunate situation of migrating to a new server. You can always zap the new server's data and start from scratch. Better than having to update your current machine ;)

Regards,
Jens

endc01
28-Nov-2012, 11:51
Hey!

Thank you for your reply!!!!

The new ldiff config was done by SLES yast ldap server tool...
It did the conversion from slapd.conf to ldiff style... (just requires the slapd.d directory...)

But here comes the "funny side" effect...

After configuring mailserver with yast all necessary schemes are created by yast itself...
Likewise it was done in SLES10...

So a import of all the data runs via slapadd without any errors at all...

Even the userPasswords are imported... 1 by 1...
So everything should work... Should so to speak... but does not...

For what so ever reason the ldap saved passwords donŽt work...
Once you reset these passwords via yast you end up with a different hash... 13character hash style...
and these then work propper...

How does yast do these password changes? Are they done issuing shell commands? Any hints were to look at?

WHAT THE HECK IS going on? Can this be related to some changes in PAM???

On the other hand doing a slappasswd -c {CRYPT} leeds on SLES10 and SLES11 to the identical values... IDENTICAL!!!

BUT the LDAP values, also 13 character hash style, wonŽt work... :confused:

Anybody having a clue where to look at? Or am I on the wrong track??

Regards,

Mike





Hi M.,

> Did I miss something???

if you set up non-default schema files in the SLES10 LDAP, you'll need to provide these in SLES11 as well. Did you go for the new LDIF-based configuration of OpenLDAP or keep the old config file stuff?

While I don't see any practical difficulties (we're running an SLES10 to SLES11 upgraded LDAP to serve SLES10, SLES11 and other servers), there may have been changes in the information structure - I wouldn't export all and any information of the old LDAP tree, but just the account data (user and probably group) and see how it goes.

Concerning the IMAP migration: Once you've set up all required accounts/mboxes, you might consider using an IMAP-based migration tool to transfer the old mailboxes' contents to the new server.

It's been a long time since I had to do this myself, so my memory may be a bit vague... but at least you have the fortunate situation of migrating to a new server. You can always zap the new server's data and start from scratch. Better than having to update your current machine ;)

Regards,
Jens

jmozdzen
28-Nov-2012, 18:40
Hi Mike,

how's your client set up, password-wise, in /etc/ldap.conf? And when you look at the data in the LDAP store (i.e. with "gq"), what hashing algo is selected for the old passwords versus those that work?

Regards,
Jens

endc01
29-Nov-2012, 10:47
Hi Jens!

SLES 11
yast - LDAP Client Configuration - Advanced Configuration... -Administration Settings
susePasswordHash CRYPT
------------------------------------
grep password /etc/ldap.conf
# Search the root DSE for the password policy (works
# Do not hash the password at all; presume
#pam_password clear
# Hash password locally; required for University of
pam_password crypt
# Remove old password first, then update in
#pam_password nds
# Update Active Directory password, by
# creating Unicode password and updating
#pam_password ad
# Use the OpenLDAP password change
# extended operation to update the password.
#pam_password exop
# Redirect users to a URL or somesuch on password
#pam_password_prohibit_message Please visit http://internal to change your password.
#pam_password ad
# configure --enable-authpassword is no longer supported
#pam_password nds
#nss_map_attribute userPassword passwordChar
#pam_password clear
---------------------------------------------------------------------------------------
SLES 10
yast - LDAP Client Configuration - Advanced Configuration... -Administration Settings
susepasswordhash │CRYPT
------------------------------------
grep password /etc/ldap.conf
# Search the root DSE for the password policy (works
# Do not hash the password at all; presume
#pam_password clear
# Hash password locally; required for University of
pam_password crypt
# Remove old password first, then update in
#pam_password nds
# Update Active Directory password, by
# creating Unicode password and updating
#pam_password ad
# Use the OpenLDAP password change
# extended operation to update the password.
#pam_password exop
# Redirect users to a URL or somesuch on password
#pam_password_prohibit_message Please visit http://internal to change your password.
#pam_password ad
# configure --enable-authpassword is no longer supported
#pam_password nds
#nss_map_attribute userPassword passwordChar
#pam_password clear

As far as I could see both are the same... crypt

the userPassword is working or not always this style: {crypt}EWc7aviiqcgac

Suppose therefore settings are the same... :-/

Thanks,

Mike

BTW: I heard that this can be also a PAM related problem... what do you think?



Hi Mike,

how's your client set up, password-wise, in /etc/ldap.conf? And when you look at the data in the LDAP store (i.e. with "gq"), what hashing algo is selected for the old passwords versus those that work?

Regards,
Jens

jmozdzen
29-Nov-2012, 11:37
Hi Mike,

{crypt} results are rather implementation specific, see http://www.openldap.org/faq/data/cache/344.html and the man page for slappasswd, section "limitations".

Generally, I'd recommend to use "pam_password exop" in ldap.conf to let OpenLDAP (or better - its admin) decide on the rules. But that will not help you with your current situation, either. (But you might want to consider this if you run into a situation where you have multiple "architectures" accessing the same LDAP store: Changing the password via local crypt on one machine may make the stored password hash unusable for other systems.)

I'm currently out of ideas - we've never been running local crypt password operations nor do I have a suitable SLES10 system at hand to easily test, so I cannot acknowledge that you're really hitting a cross-system compatibility problem. If you have a support contract with Novell/SuSE you might want to open a ticket, or somebody else from this forum can help with practical experience on this subject?

Regards,
Jens

endc01
29-Nov-2012, 13:56
Hey Jens!

Jep true spoken!!! :-)
I saw that url, too...
http://www.openldap.org/faq/data/cache/344.html

I think you got the point of of running the crypt locally from command line wrong...
that was ment to be a test to prove SLES 10 & 11 leading to the same results...
indicating for me there was no change of crypt functions in the system transition from
10 to 11...

Because of running out of time, I opened a ticket at novel...
they are now checking if there had been any changes in PAM...
IŽll let you know...


All the best an thank you for your kind attention!!!

Mike








Hi Mike,

{crypt} results are rather implementation specific, see http://www.openldap.org/faq/data/cache/344.html and the man page for slappasswd, section "limitations".

Generally, I'd recommend to use "pam_password exop" in ldap.conf to let OpenLDAP (or better - its admin) decide on the rules. But that will not help you with your current situation, either. (But you might want to consider this if you run into a situation where you have multiple "architectures" accessing the same LDAP store: Changing the password via local crypt on one machine may make the stored password hash unusable for other systems.)

I'm currently out of ideas - we've never been running local crypt password operations nor do I have a suitable SLES10 system at hand to easily test, so I cannot acknowledge that you're really hitting a cross-system compatibility problem. If you have a support contract with Novell/SuSE you might want to open a ticket, or somebody else from this forum can help with practical experience on this subject?

Regards,
Jens

jmozdzen
29-Nov-2012, 14:30
Hi Mike,

> I think you got the point of of running the crypt locally from command line wrong...
> that was ment to be a test to prove SLES 10 & 11 leading to the same results...

Yes, you're right: As far as I believe to understand the mechanisms, this will run the crypt algorithm on the LDAP server. So, as your call on SLES10 was against the SLES10 LDAP server and the call on SLES11 was against the SLES11 server and the resulting crypts are identical, then my theory of different crypt algos is proven wrong. I had that "single central LDAP server" in mind :o

Regards,
Jens