s3 member server to s4 kerberos trouble

Matthieu Patou mat at samba.org
Sun Jun 13 01:24:16 MDT 2010


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

>    
>> , 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 ;-)

-- 
Matthieu Patou
Samba Team        http://samba.org



More information about the samba-technical mailing list