<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 03/31/2015 04:08 AM, Prasun Gera
wrote:<br>
</div>
<blockquote
cite="mid:CAFLz+B=723OgrbqOmoqenCUFJr37t_BWDHqNH7tggjF6C9o=9g@mail.gmail.com"
type="cite">
<div dir="ltr"><br>
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">The idea is that you
tel lall the users to either login via migration page or
via SSSD.<br>
If your server is in a migration mode the migration page
should be available and SSSD should detect that server
is in migration mode.<br>
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.<br>
You suggested that this is not the case but I am not
sure that the test was 100 correct.<br>
<br>
Please try:<br>
- check that migration mode is on<br>
- check that user does not have kerberos password only
LDAP hash from NIS migration<br>
- ssh into a box that runs SSSD with such user,
authenticate<br>
As a result you should see Kerberos hash created for
this user and I suspect the LDAP hash is converted at
the same time. <br>
<span class=""> <br>
</span></div>
</blockquote>
<div><br>
</div>
<div>I verified all the steps, and I can confirm that SSSD
does not migrate users automatically. </div>
<div>I see the following in /var/log/secure, which confirms
that sssd is indeed authenticating the user</div>
<div><br>
</div>
<div>
<div>Mar 31 03:50:47 ipaserver sshd[23531]: Accepted
password for testuser2 from ip port 43622 ssh2</div>
<div>Mar 31 03:50:47 ipaserver sshd[23531]:
pam_unix(sshd:session): session opened for user
testuser2 by (uid=0)</div>
</div>
</div>
</div>
</div>
</blockquote>
<br>
Hm... this does not mean SSSD was used during the authentication. It
means that you used files that were delivered by NIS.<br>
<br>
<blockquote
cite="mid:CAFLz+B=723OgrbqOmoqenCUFJr37t_BWDHqNH7tggjF6C9o=9g@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<div>ipa user-show testuser2 still shows Kerberos keys
available: False<br>
</div>
<div><br>
</div>
<div>sssd's logs also show successful authentication. <br>
</div>
</div>
</div>
</div>
</blockquote>
<br>
? SSSD does not seem to be involved as user is found in the
/etc/passwd and this SSSD should not do anything.<br>
<br>
<blockquote
cite="mid:CAFLz+B=723OgrbqOmoqenCUFJr37t_BWDHqNH7tggjF6C9o=9g@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<div>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. </div>
<div><br>
</div>
<div>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. <br>
</div>
</div>
</div>
</div>
</blockquote>
<br>
<br>
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.<br>
<br>
<blockquote
cite="mid:CAFLz+B=723OgrbqOmoqenCUFJr37t_BWDHqNH7tggjF6C9o=9g@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<div>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 ?</div>
</div>
</div>
</div>
</blockquote>
<br>
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.<br>
<br>
<blockquote
cite="mid:CAFLz+B=723OgrbqOmoqenCUFJr37t_BWDHqNH7tggjF6C9o=9g@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<div> </div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div> </div>
</div>
</div>
</div>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
Thank you,
Dmitri Pal
Sr. Engineering Manager IdM portfolio
Red Hat, Inc.</pre>
</body>
</html>