<div dir="ltr">Yes, that is right. I added the users with <span style="color:rgb(51,51,51);font-family:Monaco,Menlo,Consolas,'Courier New',monospace;font-size:13px;line-height:20px;white-space:pre-wrap;background-color:rgb(245,245,245)">ipa user-add [username] --setattr userpassword={crypt}yourencryptedpass</span><div><br></div><div>Actually, the authentication does work for the users added this way. i.e. Without making any changes to NIS clients. I just repurposed the NIS server to be the IPA server, turned off the ypserv & yppasswd service, and enabled the <span style="font-size:12.8000001907349px">slapi-nis</span> plugin. So far so good, and the NIS clients continue to function normally. i.e. The NIS plugin on the IPA server DOES distribute the cryptpasses. I also didn't expect the old NIS clients to authenticate any new users added to IPA directly, and that is all right. I just want the clients to function for the existing users until they are migrated. The only thing that is slightly puzzling is that a couple of users have been migrated unintentionally, so to speak. </div><div><br></div><div>A user can be explicitly migrated to IPA if (s)he generates the kerberos keys, at which point the <span style="font-size:12.8000001907349px">slapi-nis stops distributing the crypt pass for that user. This is what I have observed so far, and it sounds reasonable. (This can also be confirmed with ipa user-show, which in case of these old users shows </span>"Kerberos keys available: False", which turns to True once properly migrated. It can also be confirmed from the webui. The old password won't work in the webui until migrated, and once migrated, NIS cryptpasses will stop working<span style="font-size:12.8000001907349px">). </span></div><div><br></div><div>However, what I'm seeing is that in a couple of cases, the users have been migrated to IPA automatically. Their status shows Kerberos keys available: True, and their cryptpasses have changed to * in ypcat passwd's output. </div><div><br></div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 26, 2015 at 5:59 PM, Dmitri Pal <span dir="ltr"><<a href="mailto:dpal@redhat.com" target="_blank">dpal@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><div><div class="h5">
<div>On 03/26/2015 02:29 PM, Prasun Gera
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Hello,
<div>I followed <a href="https://www.freeipa.org/page/NIS_accounts_migration_preserving_Passwords" target="_blank">https://www.freeipa.org/page/NIS_accounts_migration_preserving_Passwords</a>
in order to migrate our NIS installation, and for the most
part it worked. The server responds to ypcat from the NIS
clients, and users can log in. However, I'm seeing a couple of
weird issues. Normally, ypcat returns
"username:cryptpass:uid:gid:gecos:homedir:shell" for users
and authentication works fine. For new users that were added
directly to IPA, instead of the cryptpass, I see an
asterisk(*), which is also understandable. However, for a
couple of migrated users, I'm seeing that their cyrptpasses
have also been replaced with *s (in ypcat's output) over the
course of time. This creates problems for authentication on
clients that haven't been migrated, and they can't log in with
their passwords. These users didn't explicitly call kinit or
go to the webui for migration. Is it normal for the crypt
passes to be replaced by *? I migrated a couple of clients,
and these users would have sshed to the migrated clients or
possibly to the server. That didn't seem to affect ypcat's
behaviour directly, and yet that is the only thing I can think
of that has any connection to this. </div>
<div><br>
</div>
<div>Regards,</div>
<div>Prasun </div>
</div>
<br>
<fieldset></fieldset>
<br>
</blockquote>
<br></div></div>
Based on what you describe I assume that you:<br>
- Migrated users to IPA<br>
- Enabled slapi-nis plugin<br>
- Use old clients with slapi-nis as a NIS server and expect to be
able to authenticate with new and old users against IPA NIS map.<br>
<br>
Right?<br>
<br>
So the authentication does not work and this is by design since
passwords in files are insecure and distributing them centrally as
NIS did is security problem.<br>
The suggestion is to change the authentication method on old clients
to LDAP or Kerberos first, whatever they support (they usually do
even if they are quite old), and leave NIS for identity information
only since some old clients do not support LDAP for that part and
only support NIS.<span class="HOEnZb"><font color="#888888"><br>
<br>
<pre cols="72">--
Thank you,
Dmitri Pal
Sr. Engineering Manager IdM portfolio
Red Hat, Inc.</pre>
</font></span></div>
<br>--<br>
Manage your subscription for the Freeipa-users mailing list:<br>
<a href="https://www.redhat.com/mailman/listinfo/freeipa-users" target="_blank">https://www.redhat.com/mailman/listinfo/freeipa-users</a><br>
Go to <a href="http://freeipa.org" target="_blank">http://freeipa.org</a> for more info on the project<br></blockquote></div><br></div>