On 03/31/2015 04:08 AM, Prasun Gera wrote:
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)
Hm... this does not mean SSSD was used during the authentication. It
means that you used files that were delivered by NIS.
ipa user-show testuser2 still shows Kerberos keys available: False
sssd's logs also show successful authentication.
? SSSD does not seem to be involved as user is found in the /etc/passwd
and this SSSD should not do anything.
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.
No yum has nothing to do with it. But may be there is a client where the
pam stack is configured without pam_unix being first or there was some
latency and SSSD managed to find user before NIS replicated the map or
NIS is not configured on that client. In this case the user would be
migrated because it would hit SSSD.
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 ?
No AFAIK. It is not recommended to use NIS for authentication anyways so
making marginally secure is relly a design not goal. The intent is to
help you migrate off NIS as soon as possible.
--
Thank you,
Dmitri Pal
Sr. Engineering Manager IdM portfolio
Red Hat, Inc.
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
