[Freeipa-users] LDAP to Free IPA Migration SSSD migration : example configuration of sssd.conf file?

Matt Koch matt.koch at sendgrid.com
Thu Jul 23 00:45:17 UTC 2015


Hello,
I’m looking for an example sssd.conf migrationconfiguration that will allow for the user to seamlessly authenticate to LDAP or freeIPA prior to installation of the freeipa client. 

This would be during migration to generate kerberos hashes for each user while still providing legacy LDAP support until migration can be completed. Hopefully with minimal changes to our existing sssd.conf file. 


Hinted at here: 
(20.1.3.4. Migration Sequence - 
http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/Migrating_from_a_Directory_Server_to_IPA.html#migration-considerations 

and here: 

The redhat documentation describes  
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/Migrating_from_a_Directory_Server_to_IPA.html
27.1.2.3. Method 3: Using SSSD (Recommended)

SSSD can work with IdM to mitigate the user impact on migrating by generating the required user keys. For deployments with a lot of users or where users shouldn't be burdened with password changes, this is the best scenario.
	• A user tries to log into a machine with SSSD.
	• SSSD attempts to perform Kerberos authentication against the IdM server.
	• Even though the user exists in the system, the authentication will fail with the error key type is not supported because the Kerberos hashes do not yet exist.
	• SSSD then performs a plain text LDAP bind over a secure connection.
	• IdM intercepts this bind request. If the user has a Kerberos principal but no Kerberos hashes, then the IdM identity provider generates the hashes and stores them in the user entry.
	• If authentication is successful, SSSD disconnects from IdM and tries Kerberos authentication again. This time, the request succeeds because the hash exists in the entry.
That entire process is entirely transparent to the user; as far as users known, they simply log into a client service and it works as normal.


From:
https://www.redhat.com/archives/freeipa-users/2011-September/msg00138.html
Specifically, the way SSSD behaves is as follows: 
1) Try to authenticate with Kerberos. If Kerberos responds that there's no hash for this user, 
2) Ask FreeIPA if migration mode is enabled, if it is, 
3) Try to bind to FreeIPA LDAP using the same password. If this succeeds, we know that the password is valid 
4) Initiate a kerberos password-change to set the kerberos password equal to the LDAP password.

Thanks for your help!
-Matt








More information about the Freeipa-users mailing list