[cifs-protocol] RE: trustAuthIncoming format

Bill Wesse billwe at microsoft.com
Thu Jul 31 08:58:12 GMT 2008

Good morning Andrew!

I have created a new case (SRX080731600025) for your questions; one of our team will take ownership of this shortly, and will contact you concerning same.

Bill Wesse
MCSE / Escalation Engineer, US-CSS DSC PROTOCOL TEAM
8055 Microsoft Way
Charlotte, NC 28273
TEL:  980-776-8200
CELL: 704-661-5438
FAX:  704-665-9606
We're Hiring http://members.microsoft.com/careers/search/details.aspx?JobID=A976CE32-B0B9-41E3-AF57-05A82B88383E&start=1&interval=10&SortCol=DatePosted

-----Original Message-----
From: Andrew Bartlett [mailto:abartlet at samba.org]
Sent: Thursday, July 31, 2008 4:20 AM
To: Interoperability Documentation Help
Cc: pfif at tridgell.net; cifs-protocol at samba.org
Subject: Re: trustAuthIncoming format

On Thu, 2008-07-31 at 16:20 +1000, Andrew Bartlett wrote:
> In MS-ADTS, it states:
> AuthType: This ULONG value dictates the type of AuthInfo which is being stored. There are four
>   values that are recognized by Windows
>     Possible Values              Meaning
>     TRUST_AUTH_TYPE_NONE         AuthInfo byte field is invalid / not relevant
>     0
> However, in the attached decrypted and decoded blob, it instead
> appears that the 0 value for AUTH_TYPE is used like a trailing NULL in
> an array, at the end of an array of LSAPR_AUTH_INFORMATION.
> As such, I'm wondering if windows servers require that the list of
> trust secrets (and previous secrets) be terminated in this way.

With more work on the IDL, this no longer appears to be the case.

> Also, I would like you to confirm (ie, against the code) that the
> 'count' in the top level structure refers to the presence of both the
> current and previous authentication tokens or the length of those
> tokens (given the apparent NONE trailer)
> BTW, the IDL I'm using the decode this is attached.

See new blobs and decodes attached, as well as our IDL.  I think, but would love to have confirmed, that I am decoding this correctly.

Clearly I should not try and use IDL for this (if you read the IDL you will see what I mean), but I think a worked example would make it much easier to construct a parser.

Andrew Bartlett

Andrew Bartlett
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.

More information about the cifs-protocol mailing list