[Freeipa-users] Pure Kerberos login on Windows stopped working

[Simo Sorce]

On Tue, 2013-11-12 at 21:50 +0100, Nicklas Björk wrote:
> On 2013-11-12 21:39, Simo Sorce wrote:
> > On Tue, 2013-11-12 at 21:11 +0100, Nicklas Björk wrote:
> >> In our evironment we have very limited amount of shared virtual Windows
> >> 7 machines. We haven't really seen any value in setting up an AD domain
> >> for them, but have been relying on pure Kerberos authentication using
> >> the ksetup procedure
> >> (http://www.freeipa.org/page/Windows_authentication_against_FreeIPA).
> >>
> >> Recently the LDAP in our FreeIPA 3.0 was updated with the task to add
> >> SIDs to all old user accounts (the newer ones would already have a SID),
> >> but that made the Kerberos logon stop working for remote desktop
> >> connections. Logging on to the console using the same Kerberos
> >> credentials would still work... This seems to be directly related to the
> >> addition of SIDs in LDAP, as removing the object class ipantuserattrs
> >> and the SID would get it back in order again.
> >>
> >> Are there any known tricks that could be applied to the Windows machines
> >> (or to FreeIPA for that matter) that would make this work again?
> > 
> > It's odd that adding the SIDs make it not work, I remember reports of
> > people being happy to see it work better.
> > 
> > We do have a way to disable setting the MS-PAC on tickets, but I fear it
> > is only for TGS requests and not for the TGT.
> > 
> > Have you added SIDs because you are using a trust relationship with an
> > AD domain, and you just wish not to use them for these few Windows
> > machines ?
> > 
> > Simo.
> > 
> 
> Rather than the SIDs, it was the NT-hash I was looking for, to be used
> in a Radius implementation. The task in LDAP to make the update also
> added SIDs to all user accounts.
> 
> The mentioned few Windows machines are the only ones here and there is
> also no AD available. At an earlier stage I may have tried making a
> trust using the ipa-adtrust-install against a test-AD that was available
> for some time, but it's long gone and there are currently no configured
> trusts.

I see, but the SID is required by the objectclass that allows you to set
the NThash. One way to resolve that would be to use a different
objectclass so you do not have to set the SID, but I ma not sure NThash
would be automatically refreshed at password change  then.

Can you tell me exactly what error do your Win7 machines return ?

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York