[cifs-protocol] Re: Request for fix to MS-PAC
ronniesahlberg at gmail.com
Mon Aug 25 01:54:26 GMT 2008
Thanks for the reply.
In my traces there is a difference compared yo your description :
Between DnsOffset and the start of the UPN field there are 8 bytes.
Not 4 bytes as your description suggests.
Additionally it is stated that the 4 flag bytes must be 0, which they
are not in my trace.
1, investigate whether there will be 4 or 8 bytes between the
DnsOffset and the UPN field.
2, since this is not NDR encoded, please explain what the alignment
rules are for the UPN and DNS fields.
3, Are UPN and DNS fields null terminated or not?
4, Please explain the flag bits. My traces show flags with the
values 0x01 0x00 0x00 0x00
5, Also please describe the sequence how a client will request that a
KDC to create a ticket containing this new
pac blob. I.e. what exactly need an initiator do to request that the
KDC will add this to the pac?
On Fri, Aug 22, 2008 at 8:02 AM, Richard Guthrie <rguthrie at microsoft.com> wrote:
> Thank you for your question. We have completed our review and agree this was missing from the documentation. It will be corrected in a future version of the documentation but I wanted to provide you with the missing information. The updates that will be added to the documentation are listed below.
> The ulType field will have a flag added for 0x0000000C and its meaning will be as follows:
> UPN and DNS information (section 2.10). PAC structures SHOULD contain zero or one buffer of this type. Additional UPN and DNS information buffers MUST be ignored.
> A section will be added to section 2 Structures entitled UPN_DNS_INFO. Here is the added text:
> 2.10 UPN_DNS_INFO
> The UPN_DNS_INFO structure contains the client's UPN and DNS name. It is used to provide the UPN and DNS name that corresponds to the client of the ticket. The UPN_DNS_INFO structure is placed directly after the Buffers array of the topmost PACTYPE structure, at the offset specified in the Offset field of the corresponding PAC_INFO_BUFFER structure in the Buffers array. The ulType field of the corresponding PAC_INFO_BUFFER is set to 0x0000000C.
> UpnLength (2 bytes): An unsigned 16-bit integer in little-endian format that specifies the length, in bytes, of the UPN field.
> UpnOffset (2 bytes): An unsigned 16-bit integer in little-endian format that contains the offset to the beginning of the buffer, in bytes, from the beginning of the UPN_DNS_INFO structure.
> DnsDomainNameLength (2 bytes): An unsigned 16-bit integer in little-endian format that specifies the length, in bytes, of the DnsDomainName field.
> DnsOffset (2 bytes): An unsigned 16-bit integer in little-endian format that contains the offset to the beginning of the buffer, in bytes, from the beginning of the UPN_DNS_INFO structure.
> Flags (4 bytes): An unsigned 32-bit integer in little-endian format that MUST be 0.
> Please let us know if you have any further questions.
> Richard Guthrie
> Open Protocols Support Team
> Support Escalation Engineer, US-CSS DSC PROTOCOL TEAM
> Tel: +1 (469) 775-7794
> E-mail: rguthrie at microsoft.com
> 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: ronnie sahlberg [mailto:ronniesahlberg at gmail.com]
> Sent: Thursday, August 14, 2008 3:11 AM
> To: Interoperability Documentation Help
> Cc: pfif at tridgell.net; cifs-protocol at samba.org
> Subject: Request for fix to MS-PAC
> I am a pfif subcontractor.
> Using Vista workstation joined to a W2008 domain we have observed a
> new undocumented PAC_INFO_BUFFER type : type 12.
> The MS-PAC document only documents types 1,2,6,7,10 and 11.
> Please provide documentation of PAC_INFO_BUFFER type 12.
> ronnie sahlberg
More information about the cifs-protocol