[cifs-protocol] RE: trustAuthIncoming format
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.
MCSE / Escalation Engineer, US-CSS DSC PROTOCOL TEAM
8055 Microsoft Way
Charlotte, NC 28273
We're Hiring http://members.microsoft.com/careers/search/details.aspx?JobID=A976CE32-B0B9-41E3-AF57-05A82B88383E&start=1&interval=10&SortCol=DatePosted
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 188.8.131.52.1.1, 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
> 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.
Authentication Developer, Samba Team http://samba.org
Samba Developer, Red Hat Inc.
More information about the cifs-protocol