>
> Keys can be generated in migration in two ways: by the migration web UI
> or by sssd. I'm guessing you were unaware of this second method and that
> is how the keys are being created.
>
>
That's what I suspected too. But it doesn't look like SSSD is generating
keys. At least not right away. I SSHed to one of the clients with
ipa-client installed as well as to the ipa-server, and that didn't change
anything right away. That's what I was trying to figure out. i.e Which
event triggers key generation ?



> I'd suggest using nss_ldap over NIS. You can also manually configure
> Kerberos and have basic functionality as long as nscld doesn't drive you
> crazy.
>

Thanks. I'll look into it.


>
> It's not the encryption type, it is how it is encoded in 389-ds. When
> you migrated the passwords they were stored as {crypt}hash. When the
> password is changed in 389-ds it becomes {SSHA}hash. The NIS
> configuration for slapi-nis only provides those passwords prefixed with
> {crypt} (because NIS can only grok that format).


> rob
>

Yeah that sounds like a possible fix, although a less than ideal one. Is it
possible to change it back to {SSHA} after all the clients have been
migrated suitably ? How would one force all the existing users' passwords
to be converted to {SSHA} once slapi-nis is no longer needed ?
-- 
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

Reply via email to