s3 member server to s4 kerberos trouble

Lukasz Zalewski lukas at dcs.qmul.ac.uk
Sat Jun 12 11:19:31 MDT 2010

On 11/06/2010 21:02, Matthieu Patou wrote:
Hi Matthieu,
> 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 ?
I have provisioned using --function-level=2008
> 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 :
> ipv4: for
> Kerberos: No preauth found, returning PREAUTH-REQUIRED --
> ipv4: for
> 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 is
> its ip.
That is correct for both
> 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, 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. 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.
The workaround that i found (for now) is to limit kerberos encription 
types to those suppoted by s3 (removing AES ones). Downside is that all 
tickets issued are Arcfour ones from then on - but the shares can be mounted
> Lukasz, a full trace from login and restart of s3 would be very useful
> to see what's happenning.
> If you can provide me the keytab of the domain it would be super (but it
> means that I have somehow enough information to pretend to be you, your
> dc or your server, so you'd better use a generic password for admin and
> be ready to reprovision the domain).
i can create a test domain that is thrashable ;) (As this one is too). I 
wont be able to do this over this weekend though.
> Matthieu.
> On 11/06/2010 13:17, Lukasz Zalewski wrote:
>> Hi!
>> The Samba 3 i have used is 3.3.8 running on centos 5.5 (i have tried
>> samba 3.4.7 on Fedora 12 whiche exhibited same behaviour)
>> I can join S3 machine to the s4 domain without any problems (well
>> there is a DNS update failed). I can also mount any share from
>> non-domain machines (it being XP or 7) without any issies. The
>> problems start when i log in to the s4 domain - my homeDrive is
>> specified as \\s3memberserver\username.
>> Also whne i try to manually map the drive the authentication box pops up.
>> Attached are s4 d10 log and memberserver client's d10 logs. Please let
>> me know if you need anything else
>> Regards
>> Luk

More information about the samba-technical mailing list