On 03/27/2015 01:20 PM, Prasun Gera wrote:



    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 ?



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.


--
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

Reply via email to