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.
Regards, 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:[EMAIL PROTECTED] Sent: Thursday, July 31, 2008 4:20 AM To: Interoperability Documentation Help Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: trustAuthIncoming format On Thu, 2008-07-31 at 16:20 +1000, Andrew Bartlett wrote: > In MS-ADTS 7.1.6.8.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 > 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 http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc.
_______________________________________________ cifs-protocol mailing list [email protected] https://lists.samba.org/mailman/listinfo/cifs-protocol
