Yes, that is right. I added the users with ipa user-add [username]
--setattr userpassword={crypt}yourencryptedpassActually, 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 slapi-nis 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. A user can be explicitly migrated to IPA if (s)he generates the kerberos keys, at which point the 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 "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). 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. On Thu, Mar 26, 2015 at 5:59 PM, Dmitri Pal <d...@redhat.com> wrote: > On 03/26/2015 02:29 PM, Prasun Gera wrote: > > Hello, > I followed > https://www.freeipa.org/page/NIS_accounts_migration_preserving_Passwords > 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. > > Regards, > Prasun > > > > Based on what you describe I assume that you: > - Migrated users to IPA > - Enabled slapi-nis plugin > - 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. > > Right? > > 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. > 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. > > -- > 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 >
-- 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
