On Mon, 2011-11-07 at 14:34 +0100, Jakub Hrozek wrote:
On Sun, Sep 25, 2011 at 04:44:55PM +0200, Jakub Hrozek wrote:
> On Tue, Sep 06, 2011 at 01:48:00PM -0400, Stephen Gallagher wrote:
> > On Thu, 2011-08-18 at 18:02 +0200, Jakub Hrozek wrote:
> > > On Thu, Aug 18, 2011 at 05:38:11PM +0200, Sumit Bose wrote:
> > > > On Thu, Aug 18, 2011 at 04:48:32PM +0200, Jan Zelený wrote:
> > > > > The patches look fine, but I didn't manage to set up
environment to test the
> > > > > new behavior. Nothing seems to be broken though
> > > >
> > > > If you have a running IPA server you can remove the krbPrincipalKey
> > > > attribute from a user but keep userPassword. This should trigger sssd
to
> > > > run the migration code if you try to log in as this user.
> > > >
> > > > HTH
> > > >
> > > > bye,
> > > > Sumit
> > > >
> > >
> > > If that doesn't work for you, feel free to ping me off list and use
my
> > > test environment.
> >
> > I was trying to test this, but instead of quietly creating the kerberos
> > password, it's prompting me to change the password. I wonder if this is
> > related to LDAP password policy? I cannot ack this until we figure out
> > why this is happening.
>
> Interesting, I haven't hit this issue. I have tested the migration with
> IPA server nightlies, today it's freeipa-server-2.99.0GITf323d81-0. My
> testing involved creating a bunch of users in 389-ds, migrating them to
> IPA with the migrate-ds script and then logging in with the LDAP
> password.
>
> The login went OK and "klist" shows a ticket was granted, also "ipa
> user-show --all --raw" tells the Kerberos attributes were generated,
> including krblastsuccessfulauth.
>
> I suggest we discuss the patches on #sssd.
I've retested the patches again with SSSD git head + the patches on review and
freeipa-server-2.1.3-2 I've performed about 20 migrations (scripted) and
they went OK.
Attached are patches that are rebased on current master. Because the
migration patch touches most of the ipa-auth.c file I've also fixed the
debug levels there.
Nack.
Looks good for the most part, but I'm not a huge fan of the "three-way
boolean" you're using for force_tls. I'd much prefer it if you just used
an enum instead of a reference to a boolean.