s3 member server to s4 kerberos trouble

[Andrew Bartlett]

On Sun, 2010-06-13 at 11:24 +0400, Matthieu Patou wrote:
> On 13/06/2010 07:21, Andrew Bartlett wrote:
> > On Sat, 2010-06-12 at 00:02 +0400, Matthieu Patou wrote:
> >    
> >> Hello Lukaz,
> >>
> >> To my mind according to your log the pb is that w7 present an AES
> >> encrypted ticket, and s3, didn't support for this version, AES.
> >>
> >> In order for s4 to provide AES ticket, you should have raised to level
> >> 2008 your domain, because by default we do provision with a 2003
> >> functional level.
> >> Is it the case ?
> >>
> >> Even win this case we should be able to sort out differences in capacity.
> >> If I trust your log it _seems_ that your s3 pretend to support encoding
> >> that it in fact didn't support :
> >>
> >> Kerberos: AS-REQ ORINOCO$@STUDENT.EECS.QMUL.AC.UK from
> >> ipv4:138.37.37.245:58349 for
> >> krbtgt/STUDENT.EECS.QMUL.AC.UK at STUDENT.EECS.QMUL.AC.UK
> >> Kerberos: No preauth found, returning PREAUTH-REQUIRED --
> >> ORINOCO$@STUDENT.EECS.QMUL.AC.UK
> >> Kerberos: AS-REQ ORINOCO$@STUDENT.EECS.QMUL.AC.UK from
> >> ipv4:138.37.37.245:47940 for
> >> krbtgt/STUDENT.EECS.QMUL.AC.UK at STUDENT.EECS.QMUL.AC.UK
> >> Kerberos: Client sent patypes: encrypted-timestamp
> >> Kerberos: Looking for PKINIT pa-data -- ORINOCO$@STUDENT.EECS.QMUL.AC.UK
> >> Kerberos: Looking for ENC-TS pa-data -- ORINOCO$@STUDENT.EECS.QMUL.AC.UK
> >> Kerberos: ENC-TS Pre-authentication succeeded --
> >> ORINOCO$@STUDENT.EECS.QMUL.AC.UK using aes256-cts-hmac-sha1-96
> >> Kerberos: AS-REQ authtime: 2010-06-11T09:59:30 starttime: unset endtime:
> >> 2010-06-12T09:59:33 renew till: unset
> >> Kerberos: Client supported enctypes: aes256-cts-hmac-sha1-96,
> >> arcfour-hmac-md5, des3-cbc-sha1, des-cbc-crc, des-cbc-md5, using
> >> aes256-cts-hmac-sha1-96/aes256-cts-hmac-sha1-96
> >>
> >> Can you confirm that ORINOCO is your s3 server and that 138.37.37.245 is
> >> its ip.
> >>
> >> Andrew: if it is so I have the impression that something wrong: either
> >> from s4 side because it thinks that the client support that it is not
> >> announcing as supported, either it's s3 which announce encoding that it
> >> fact it didn't support.
> >>
> >> In any case even in  if s3 announce wrong encoding when requesting
> >> ticket
> >>      
> > Samba3 isn't able to influence this (nor should it, for security and man
> > in the middle attack reasons).  It just finds out at the end that it
> > can't decrypt.
> >    
> well according to the capture and message it seems that we concider that 
> s3 is supporting AES, it is what the message is saying no ?
> (here it's the s3 server requesting a ticket for itself in order to 
> verify the ticket of the client I suppose).

Yes, while the client could control this (a little), as in Windows the
KDC does the control, the Samba3 code probably doesn't do the deep
kerberos magic to also attempt to control it.  We need to fix this on
the DC side.

> >    
> >> , we should use msDS-SupportedEncryptionTypes when requested for a
> >> ticket for a given principal (ie. cifs/server at REALM) to decide in which
> >> encoding we return the ticket to the requester so that it can be
> >> understood by requester and and requested principal.
> >>      
> > Yes.  The requester is handled by the KDC already, but the requested
> > principal is what needs work.
> >
> >    
> >> Looking at the code
> >> I didn't saw much lookup to this attribute so I wonder how do we decide
> >> which encoding the requested principal support.
> >>      
> > Correct, we need to use msDS-SupportedEncryptionTypes in kdc/db-glue.c
> > near where we look at UF_USE_DES_KEY_ONLY.
> >
> > The trickier part is that we need to have Samba4's domain join call the
> > netlogon 'GetDomainInfo' call to set it's use of the full set of
> > encryption types (and the DNS name).
> >
> > Attached is my proposed solution
> 
> I'll try to give a try ;-)
> 

Did it help?

Andrew Bartlett