Good morning Andrew. I have created case SRX090727600015 ([MS_NRPC] 2.2.1.3.5 WorkstationFlags) to track your request for clarification of the NETLOGON_WORKSTATION_INFO WorkstationFlags B bit with respect to SPN update rules.
I expect to begin work on this later this morning, and will advise you of my research results as soon as possible. > > We do need some further assistance. Matthias has discovered that we need to > implement the small note on WorkstationFlags: > B: Client handles the update of the service principal name (SPN). > > That is, we must handle the update of the servicePrincipalName if that bit is > not set. > > What concerns me is what are the rules for updating the dsnHostName and > servicePrincipalName attributes from the information the client supplies here? > > Information such as 'the DC must ensure the client selects a name that does > not already exist' and what forms of servicePrincipalName are manipulated > with this call would be most useful. > > I'm concerned that for the natural first implementation, the client could > specify any name, and therefore create a collision in the KDC (which service > to issue the ticket for), or worse still 'spoof' another server. > > (There is simply no detail on this that I can see in this section) > > Thanks, > -- > Andrew Bartlett > http://samba.org/~abartlet/ > Authentication Developer, Samba Team http://samba.org > Samba Developer, Cisco Inc. > Regards, Bill Wesse MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM 8055 Microsoft Way Charlotte, NC 28273 TEL: +1(980) 776-8200 CELL: +1(704) 661-5438 FAX: +1(704) 665-9606 -----Original Message----- From: Andrew Bartlett [mailto:[email protected]] Sent: Monday, July 27, 2009 7:26 AM To: Bill Wesse Cc: Interoperability Documentation Help; [email protected]; [email protected]; Matthias Dieter Wallnöfer; Hongwei Sun Subject: RE: Please clarify LSA and OsVersion behaviour in MS-NRPC On Fri, 2009-07-10 at 02:48 -0700, Bill Wesse wrote: > Good day Andrew! Hongwei and I have divided your request in two parts - one > each for OsVersion and the LsaPolicy buffer. > > I have just filed a Technical Document Issue (TDI) concerning the OsVersion > field (of [MS-NRPC] 2.2.1.3.6 NETLOGON_WORKSTATION_INFO). Hongwei will be > your contact for the LsaPolicy buffer information you asked after. > > The OsVersion member is an OSVERSIONINFOEX structure (284 bytes); this is > cross-referenced in [MS-REF], and documented on MSDN (links included below, > along with the actual typedef). This structure is subject to normal RPC > marshaling; . > > As you noted, the OsVersion description states 'the version information is > unchanged and uninterpreted' for (placement in) the operatingSystemVersion > attribute. This certainly does not match the example given in <23>, which > shows "5.2 (3790)". > > I pointed out these discrepancies in the TDI, as well as noting that the > operatingSystemVersion attribute is mentioned once only in [MS-ADTS] at > 3.1.1.2.3.5 'Flag fRODCFilteredAttribute in Attribute searchFlags' (where > there is a link to [MS-ADA3]: Active Directory Schema Attributes N-Z / 2.55 > Attribute operatingSystemVersion). > > I have included a manual deconstruction of the OSVERSIONINFOEX structure from > netlogon-29.0.in. > > Please let me know your thoughts concerning any further elaboration or > reference information that would assist in your efforts! We do need some further assistance. Matthias has discovered that we need to implement the small note on WorkstationFlags: B: Client handles the update of the service principal name (SPN). That is, we must handle the update of the servicePrincipalName if that bit is not set. What concerns me is what are the rules for updating the dsnHostName and servicePrincipalName attributes from the information the client supplies here? Information such as 'the DC must ensure the client selects a name that does not already exist' and what forms of servicePrincipalName are manipulated with this call would be most useful. I'm concerned that for the natural first implementation, the client could specify any name, and therefore create a collision in the KDC (which service to issue the ticket for), or worse still 'spoof' another server. (There is simply no detail on this that I can see in this section) Thanks, -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco Inc. _______________________________________________ cifs-protocol mailing list [email protected] https://lists.samba.org/mailman/listinfo/cifs-protocol
