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
Ok… Trick is to run yast mailserver config first… then export old ldiff and import… to new system…
Did I miss something???
Cheers…
M.
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
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… 
Anybody having a clue where to look at? Or am I on the wrong track??
Regards,
Mike
[QUOTE=jmozdzen;10335]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[/QUOTE]
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
Hi Jens!
grep password /etc/ldap.conf
#pam_password clear
pam_password crypt
#pam_password nds
#pam_password ad
#pam_password exop
#pam_password_prohibit_message Please visit http://internal to change your password.
#pam_password ad
grep password /etc/ldap.conf
#pam_password clear
pam_password crypt
#pam_password nds
#pam_password ad
#pam_password exop
#pam_password_prohibit_message Please visit http://internal to change your password.
#pam_password ad
#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?
[QUOTE=jmozdzen;10386]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[/QUOTE]
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
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
[QUOTE=jmozdzen;10414]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[/QUOTE]
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