(besides add the passSyncManagersDNs attribute of course!) Andy
On Thu, Feb 4, 2021 at 1:13 PM Alfred Victor <[email protected]> wrote: > > From: > 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 > > *"Users cannot authenticate to the IdM domain or access IdM resources > until they have Kerberos hashes."* > > To be sure I understand, without the kerberos keys SSH auth to an IPA > system requiring for instance SSH key+password in sshd_config will fail, > and 39.1.2.3 as described at link above won't generate the keys > transparently? Just trying to be sure I understand the scope and what > actions we need to take to make sure that logins will work, and that the > necessary keys will get created for a user to not notice whether they are > on an IPA or an LDAP system, or if this will require further action from us. > > Also it sounds like we'll need to use ldapmodify to connect to the IPA > system to write the password hash. It sounds like I can use the same user > for this bind that does the migrate-ds currently. This user is currently > set up with least privilege, has only a special group we have created. Is > there anything I need to give it specially to be able to write hashes of an > existing user, or I guess it already can do this if it can do a migrate-ds > and create users (and their hash values)? > > Andy > > On Thu, Feb 4, 2021 at 12:38 PM Rob Crittenden <[email protected]> > wrote: > >> Alfred Victor via FreeIPA-users wrote: >> > Hi Rob and IPA list - >> > >> > The alternative is if it is possible to use the sssd method similar to >> > as described in 39.1.2.3 at the below link to update credentials at IPA >> > as well when a user resets their password, but I expect that if this is >> > possible to do with both systems in parallel (OpenLDAP remaining source >> > of truth until IPA is given the reins), the configuration will be >> > complex. Hence why I feel we are better off writing this value directly, >> > or else our IPA systems are going to have a stale credential problem >> > because migrate-ds will copy the user, or make sure any new user ends up >> > in IPA, but eventually the user changes password and migrate-ds will >> > only be concerned that the user already exists and will not update the >> > credential. Can you please let us know what we'll need to change or do >> > to write to the password hash directly? I do not plan to store any >> > credential hashes during this process - nor do I plan to have them >> > accessible by any means. They will be processed into IPA and that's it. >> > We already sync public key, group changes to IPA. >> > >> > SSSD method: >> > >> 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 >> > >> > Another option is of course to drop all users and remigrate them, but >> > this is incompatible with our use case, as we won't have this >> > opportunity easily. >> >> The problem with using a pre-hashed password is that IPA cannot generate >> new keys so the user would always have to migrate their password using >> either SSSD or an LDAP bind. How often that would be depends on how >> often passwords are changing. >> >> Syncing in a password change will also trigger an expired password. So >> if you can grab the unhashed password and sync that then see >> >> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/identity_management_guide/pass-sync >> section 15.6.3 (ignore everything else, literally). >> >> This will allow an unhashed password to be written without marking it as >> expired.For DN you use the user that binds from your existing password >> source to do the write. >> >> rob >> >> > Andy >> > >> > On Wed, Feb 3, 2021 at 3:10 PM Alfred Victor <[email protected] >> > <mailto:[email protected]>> wrote: >> > >> > Hi Rob, >> > >> > We have our system in migration mode. Due to the number and >> > diversity of systems we have, we've found we really need to test >> > everything extensively before we can cut over and make our IPA >> > cluster our source of truth. Keeping a subset of systems on IPA >> > during this time allows us to be comfortable switching at some >> > future date, given that we know we've had no issues with each subset >> > x of all systems y with t duration of production utilization. >> > >> > Andy >> > >> > On Wed, Feb 3, 2021 at 2:08 PM Rob Crittenden <[email protected] >> > <mailto:[email protected]>> wrote: >> > >> > Alfred Victor via FreeIPA-users wrote: >> > > Hi all, >> > > >> > > We have a need to set the password hash value directly, is >> this >> > > possible? It does not appear that ipa user-mod will support >> > this, and >> > > using the API or other methods looks like it will be fraught >> > with access >> > > control complications. >> > >> > Why do you need to set the hash directly? >> > >> > It is possible to do when adding a new user for migration >> > purposes, but >> > after that it is generally not allowed. >> > >> > rob >> > >> > >> > _______________________________________________ >> > FreeIPA-users mailing list -- [email protected] >> > To unsubscribe send an email to >> [email protected] >> > Fedora Code of Conduct: >> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >> > List Archives: >> https://lists.fedorahosted.org/archives/list/[email protected] >> > >> >>
_______________________________________________ FreeIPA-users mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/[email protected]
