[Freeipa-users] Password migrating into IPA with SSSD failed

[Dmitri Pal]

On 04/30/2012 04:49 PM, David Copperfield wrote:
> >
> >>
> >> The existing document states all the steps as listed below.
> >>
> >>        A user tries to log into a machine with SSSD.
> >>        SSSD attempts to perform Kerberos authentication against the
> >>        IPA server.
> >>        Even though the user exists in the system, the authentication
> >>        will fail with the error key type is not supported because the
> >>        Kerberos hashes do not yet exist.
> >>        SSSD the performs a plaintext LDAP bind over a secure
> >>        connection.
> >>        IPA intercepts this bind request. If the user has a Kerberos
> >>        principal but no Kerberos hashes, then the IPA identity
> >>        provider generates the hashes and stores them in the user
> >>        entry.
> >>        If authentication is successful, SSSD disconnects from IPA and
> >>        tries Kerberos authentication again. This time, the request
> >>        succeeds because the hash exists in the entry.
> >> The steps 4-6 are a little difficult to understand: Are these steps
> >> SSSD/IPA's internal information exchange mechanism? or do I have to
> >> setup something at IPA client/server side to fullfill? like setup
> >> pam_ldap or nslcd/nss_ldap?
> >>
> >>>Steps 4-6 are handled automatically by SSSD as long as it is configured
> >with 'id_provider = ipa' and 'auth_provider = ipa' (which is how
> >ipa-client-install configures it) and migration mode is enabled on the
> >server.
> >
>
> IPA server's migration mode was already setup, and sssd have the
> providers setup
> to IPA already for both id and auth.
>
> >>
> >> I've mirgated all my users and groups from openLDAP into IPA without
> >> user password/hash ( another bug here: needs
> >> --group-objectclas='posixGroup' option, and optionally
> >> --schema='RFC2307'), the passwords were not migrated, and so I tried
> >> the above method to setup new passwords seamlessly for users,
> >> unfortunately all tries failed.
> >>
> >>
> >
> >This is the problem. In order for seamless password migration to work,
> >you need to migrate the hashes. If we cannot bind with the old password,
> >we can't set that up for Kerberos.
> >
>
> This is the popint. If I understand correctly -- please feel free to
> correct --, the document claims a way to initialize password hash for
> IPA users, when the accounts are migrated and without a password hash,
> and they use the user's password input to initialize the password hash.
>

I think the confusion is not "without any hash" but "without a kerberos
hash". You need old password hashes copied over for the LDAP
authentication to be successful to make sure that the password is the
same as the old one.
Deon we should make it more clear.

> The ssh session fails may be related to the 'REQUIRE-PREAUTH'
> attribute for IPA accounts but I am not sure.
>
> >What it sounds like you probably want to do (since you aren't keeping
> >the hashes) is just reset the passwords for all of your users, which
> >will require them to change it on first login. There's an admin command
> >'ipa passwd <username>' that can reset a user password. There may also
> >be tools to do this in bulk, but someone else will need to chime in
> >here.
> >
>
> I know this way password-resetting (to 'abcd1234' :) ) should work,
> but it is not the document claims. for bulk setup, I've use the
> following IPA command to find all users without password hash:
> ipa user-find | perl -00 -ni -e '/Keytab: False/ && print $_;' | grep
> -i 'User login:' | cut -d: -f2
> and then run a loop to apply command 'ipa passwd <userID>'.
>
> There maybe a better and simpler ldapsearch command to find a list of
> users against 389 directory server directly, but I am still in the
> learning curve.
>
> --David
> >
> >
> >
> >


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20120430/c452bb42/attachment.htm>