[Freeipa-users] Understanding the migration mode

Prasun Gera prasun.gera at gmail.com
Tue Mar 31 08:08:55 UTC 2015


> The idea is that you tel lall the users to either login via migration page
> or via SSSD.
> If your server is in a migration mode the migration page should be
> available and SSSD should detect that server is in migration mode.
> In this case any authentication via SSSD will end up creating proper
> hashes for Kerberos. I suspect this is when the conversion of the LDAP
> hashes happens too.
> You suggested that this is not the case but I am not sure that the test
> was 100 correct.
>
> Please try:
> - check that migration mode is on
> - check that user does not have kerberos password only LDAP hash from NIS
> migration
> - ssh into a box that runs SSSD with such user, authenticate
> As a result you should see Kerberos hash created for this user and I
> suspect the LDAP hash is converted at the same time.
>
>
I verified all the steps, and I can confirm that SSSD does not migrate
users automatically.
I see the following in /var/log/secure, which confirms that sssd is indeed
authenticating the user

Mar 31 03:50:47 ipaserver sshd[23531]: Accepted password for testuser2 from
ip port 43622 ssh2
Mar 31 03:50:47 ipaserver sshd[23531]: pam_unix(sshd:session): session
opened for user testuser2 by (uid=0)

ipa user-show testuser2 still shows Kerberos keys available: False

sssd's logs also show successful authentication.

I think this sounds reasonable (and possibly intentional?) since the
alternative would make staged migration impossible. As soon as one client
is migrated, all other clients would lose the ability to authenticate with
NIS. The way it is behaving right now is actually preferable. i.e. No
automatic migration until done explicitly by user/admin.

Coming back to the original issue, I deleted those accidentally migrated
users and added them again, and I haven't seen any anomalous behaviour
since. i.e Their cypt hashes are visible to NIS clients. I can only guess
that whatever triggered it in the first place was a one-off event. Could
yum update be responsible ? All the free ipa packages were updated last
week to the latest point release. In any case, I think it is behaving well
for now, and hope it stays that way.

Minor question: Our NIS maps had separate shadow maps originally, which
provided some mild security since they can't be accessed by unprivileged
users/ports. Is it possible to do that with the NIS plugin in IPA ?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20150331/fc48e943/attachment.htm>


More information about the Freeipa-users mailing list