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 <alvic266@gmail.com
> <mailto:alvic266@gmail.com>> 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 <rcritten@redhat.com
> <mailto:rcritten@redhat.com>> 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 -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
> 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/freeipa-users@lists.fedorahosted.org
>