To do that, I suspect we would have to update our current LDAP pre-BIND callback and try to bind against some external Directory server that would be specified in the FreeIPA Config object.

There is a place where authentication is happening that would have to be changed to try the LDAP BIND:

https://git.fedorahosted.org/cgit/freeipa.git/tree/daemons/ipa-slapi-plugins/ipa-pwd-extop/prepost.c#n1461

I am not sure how doable it is though, Ludwig or Rob, do you know?

I'm not sure if this is the right place, but I am not familiar with the workflow of password migration. I think the place to change would be where now the pw hash is retrieved and compared.

generally we already have this mechanism in PTA and PAM plugins, where actual password verification is transferred to a remote server, so it can be done.

IMO this is not migration then and should not be done this way at all. It is then more of a self registration portal when user authenticates against something else using some other mean and then allowed to set his password in the system. I see two paths how it can be done: using user self-registration portal which does not exist yet and another using external authentication into the UI. The latter is considered for the 4.4 release but I do not think it is filed as a formal ticket yet. It might be time to do it.
The solution would be then:
a. Copy accounts over using migrate-ds or other scripts
b. Setup Ipsilon or Keycloak or similar IdP
c. Enable login into the UI using external authentication
d. Instruct users to log in and set their passwords, SSH keys and OTPs
e. Disconnect external authentication when the migration is over

However for now until this feature is available the administrator can set a password for the users in the system and let user know the password. This can be automated. User would log in in the IPA UI using this registration password and will be forced to change the password (this is how system works now). At that time he can change his password to that he is using in the old system. This scenario is though not that automated as the one above is still very much doable and the nice part that it is doable now.

This may work too, although it seems to be targeting a much more general case that what was asked for.

In this case, it is migration other compliant LDAP with LDAP BIND working, so I am thinking if there could be some easy changes to support that scenario.

I am wondering if what lkrispen said is achievable:

generally we already have this mechanism in PTA and PAM plugins, where actual password verification is transferred to a remote server, so it can be done.

It sounds appealing to me, as it is pretty generic and SSSD can be configured to route the authentication to the target LDAP or it's subtree, it can even filter the allowed users, etc.

However, the LDAP callback would have need to be configured to do something like that:

• There is LDAP BIND which failed
  • Is migration mode enabled?
    • If not, just return the error
    • If yes, check if userPassword exists.
      • If yes, just return the error
      • If not, do PAM Pass Through to the external LDAP service, as configured on the FreeIPA server. If it succeeds, generate the hashes *

Looking at
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/pam-pta.html
I wonder if we can selectively route some authentication requests (only for non-migrated users) to PAM or not.

In private discussion with the requester a different approach was proposed.

A custom migration page will be implemented which will do all required operations. Which are:

• check if the current password valid in original store
• update ipa and original store(for migration period) with updated password

This keeps password in sync in migration period. From implementation perspective it is a simple solution and therefore complex general solution can be avoided. Therefore closing as won't fix.