Resending as I have not heard back from Ronnie on this. Richard Guthrie Open Protocols Support Team Support Escalation Engineer, US-CSS DSC PROTOCOL TEAM Tel: +1 (469) 775-7794 E-mail: [EMAIL PROTECTED] 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: Richard Guthrie Sent: Monday, August 25, 2008 9:30 AM To: 'ronnie sahlberg' Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: Request for fix to MS-PAC Ronnie, can you send over a network trace (Wireshark or Netmon 3 format preferred) that shows the behavior you describe for items 1 and 4? I will continue to investigate your list of questions and get back to you shortly. Richard Guthrie Open Protocols Support Team Support Escalation Engineer, US-CSS DSC PROTOCOL TEAM Tel: +1 (469) 775-7794 E-mail: [EMAIL PROTECTED] 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:[EMAIL PROTECTED] Sent: Sunday, August 24, 2008 8:54 PM To: Richard Guthrie Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Request for fix to MS-PAC Hi, Thanks for the reply. However, 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. Please, 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? regards ronnie sahlberg On Fri, Aug 22, 2008 at 8:02 AM, Richard Guthrie <[EMAIL PROTECTED]> wrote: > Ronnie, > > 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: [EMAIL PROTECTED] > 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:[EMAIL PROTECTED] > Sent: Thursday, August 14, 2008 3:11 AM > To: Interoperability Documentation Help > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Request for fix to MS-PAC > > Hi, > > 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. > > > regards > ronnie sahlberg > > _______________________________________________ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
