RE: Please clarify LSA and OsVersion behaviour in MS-NRPC

[John Dunning-5]

Hello Andrew,
   Thank you for your question regarding  the [MS-NRPC] document. I will have one of my colleagues get back to you so that we can start working on this.

Thanks
John Dunning
Senior Escalation Engineer Microsoft Corporation US-CSS DSC PROTOCOL TEAM
Email: johndun@...

-----Original Message-----
From: Andrew Bartlett [mailto:abartlet@...]
Sent: Tuesday, July 07, 2009 10:45 PM
To: Interoperability Documentation Help
Cc: pfif@...; cifs-protocol@...; Matthias Dieter Wallnöfer
Subject: Please clarify LSA and OsVersion behaviour in MS-NRPC

In MS-NRPC 2.2.1.3.6 NETLOGON_WORKSTATION_INFO it has:

>
> typedef struct _NETLOGON_WORKSTATION_INFO {
>   NETLOGON_LSA_POLICY_INFO LsaPolicy;
>
This is defined in 2.2.1.3.5, but not very helpfully:

> The NETLOGON_LSA_POLICY_INFO structure defines Local Security
> Authority (LSA) policy information as an unsigned character buffer. For details, see [LSAPOLICY] and [MS-LSAD].

My question is:  Is this buffer ever filled in (it is null in the attached example from a WinXP join), and if so, what does it mean?  The links to [LSAPOLICY] and [MS-LSAD] are non-specific and not very useful in understanding the possible inputs here.

Further down, it claims:

> OsVersion: A null-terminated Unicode string that contains the version number of the operating
>   system installed on the client machine.<23> The DC that receives this data structure updates
>   the operatingSystemVersion attribute of the client's machine account object in Active
>   Directory with this value, unchanged and uninterpreted, as specified in [MS-ADTS].
> OsName: A null-terminated Unicode string that contains the name of the operating system
>   installed on the client machine.<24> The DC that receives this data structure updates the
>   operatingSystem attribute of the client's machine account object in Active Directory, as
>   specified in [MS-ADTS].

Firstly, which part of MS-ADTS does this refer?  It is a large document, and I can't find the reference.

However, the main problem I have is that the text for OsName is plausable, given the input.  The examples in <24> even match up with the wire data (attached).  However, OsVersion is a very different thing.
What is in this 284 byte buffer?  For certain it is not a unicode string
- and certainly not the one indicated in <23>:

> <23> Section 2.2.1.3.6: The version and build number of the client
> operating system are used. For example, for Windows Server 2003 SP1,
> the string "5.2 (3790)" is used, which indicates version 5.2 and build number 3790.
>

Please clarify these inputs, so that Matthias may implement this important part of NETLOGON correctly (see
https://bugzilla.samba.org/show_bug.cgi?id=4888 for his attempts so far).


Thanks,

Andrew Bartlett


--
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.

_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

[Bill Wesse]

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!



OSVERSIONINFOEX Structure
http://msdn.microsoft.com/en-us/library/ms724833(VS.85).aspx

[MS-REF]: Windows Protocols Master Reference
[MSDN-OSVERSIONINFOEX] Microsoft Corporation, "OSVERSIONINFOEX" Structure, http://msdn2.microsoft.com/en-us/library/ms724833.aspx

typedef struct _OSVERSIONINFOEX {
   DWORD dwOSVersionInfoSize;
   DWORD dwMajorVersion;
   DWORD dwMinorVersion;
   DWORD dwBuildNumber;
   DWORD dwPlatformId;
   TCHAR szCSDVersion[128];
   WORD  wServicePackMajor;
   WORD  wServicePackMinor;
   WORD  wSuiteMask;
   BYTE  wProductType;
   BYTE  wReserved;
} OSVERSIONINFOEX, *POSVERSIONINFOEX, *LPOSVERSIONINFOEX;


netlogon-29.0.in


OsVersion
---------

 blob2: struct lsa_BinaryString
     length                   : 0x011c (284)
     size                     : 0x011c (284)
     array                    : *


0140  DWORD dwOSVersionInfoSize  0x0000011C  (284)
0144  DWORD dwMajorVersion       0x00000005    (5) 5.1 Windows XP
0148  DWORD dwMinorVersion       0x00000001    (1)
014C  DWORD dwBuildNumber        0x00000A28 (2600)
0150  DWORD dwPlatformId         0x00000002    (2) VER_PLATFORM_WIN32_NT
0154  TCHAR szCSDVersion[128]    "Service Pack 2\0"
0170  TCHAR szCSDVersion[...]    (ignore; recycled memory)
0254  WORD wServicePackMajor         0x0002    (2) 2.0
0256  WORD wServicePackMinor         0x0000    (0)
0257  WORD wSuiteMask                0x0100  (256) VER_SUITE_SINGLEUSERTS
0257  BYTE wProductType                0x01    (1) VER_NT_WORKSTATION
0258  BYTE wReserved                   0x00    (0)

0140  1C 01 00 00                                      ....             DWORD dwOSVersionInfoSize  0x0000011C  (284)
0144              05 00 00 00                              ....         DWORD dwMajorVersion       0x00000005    (5) 5.1 Windows XP
0148                          01 00 00 00                      ....     DWORD dwMinorVersion       0x00000001    (1)
014C                                      28 0A 00 00              (... DWORD dwBuildNumber        0x00000A28 (2600)
0150  02 00 00 00                                      ....             DWORD dwPlatformId         0x00000002    (2) VER_PLATFORM_WIN32_NT
0154              53 00 65 00 72 00 76 00 69 00 63 00      S.e.r.v.i.c. TCHAR szCSDVersion[128]    Service Pack 2
0160  65 00 20 00 50 00 61 00 63 00 6B 00 20 00 32 00  e. .P.a.c.k. .2.
0170  00 00                                            ..              
0170        E6 00 02 00 00 00 00 00 00 00 20 C0 0B 00    .......... ... ignore; recycled memory: TCHAR szCSDVersion[128] ...
0180  40 5A 86 5B 00 00 00 00 00 00 00 00 00 00 00 00  @Z.[............
0190  30 00 09 00 02 00 00 00 00 00 00 00 00 00 00 00  0...............
01A0  B0 E4 E6 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
01B0  00 00 00 00 C4 F5 E6 00 0E 00 00 00 00 00 00 00  ................
01C0  D0 E4 E6 00 20 F6 E6 00 00 00 00 00 00 00 00 00  .... ...........
01D0  00 00 00 00 0D 00 00 00 58 61 17 00 4F 00 00 00  ........Xa..O...
01E0  00 00 00 00 00 00 09 00 1A 00 00 00 00 00 00 00  ................
01F0  00 00 00 00 00 00 00 00 20 C0 0B 00 00 00 00 00  ........ .......
0200  04 5D 88 8A 48 00 00 00 CC 27 87 5B BC 27 87 5B  .]..H....'.[.'.[
0210  09 00 00 00 DA 27 87 5B D0 F8 E6 00 00 00 00 00  .....'.[........
0220  00 00 00 00 C6 27 87 5B DA 5A 86 5B 00 00 00 00  .....'.[.Z.[....
0230  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0240  24 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  $...............
0250  00 00 00 00                                      ....            
0254              02 00                                    ..           WORD wServicePackMajor     0x0002   (2) 2.0
0256                    00 00                                ..         WORD wServicePackMinor     0x0000   (0)
0257                          00 01                            ..       WORD wSuiteMask            0x0100 (256) VER_SUITE_SINGLEUSERTS
0257                                01                           .      BYTE wProductType            0x01   (1) VER_NT_WORKSTATION
0258                                   00                          .    BYTE wReserved               0x00   (0)



NTSTATUS NetrLogonGetDomainInfo(
   [in, string] LOGONSRV_HANDLE ServerName,
   [in, string, unique] wchar_t* ComputerName,
   [in] PNETLOGON_AUTHENTICATOR Authenticator,
   [in, out] PNETLOGON_AUTHENTICATOR ReturnAuthenticator,
   [in] DWORD Level,
   [in, switch_is(Level)] PNETLOGON_WORKSTATION_INFORMATION WkstaBuffer,
   [out, switch_is(Level)] PNETLOGON_DOMAIN_INFORMATION DomBuffer
);

0000  1E 00 00 00 00 00 00 00 1E 00 00 00 5C 00 5C 00  ............\.\.
0010  6E 00 61 00 6F 00 6D 00 69 00 2E 00 53 00 34 00  n.a.o.m.i...S.4.
0020  2E 00 4E 00 41 00 4F 00 4D 00 49 00 2E 00 41 00  ..N.A.O.M.I...A.
0030  42 00 41 00 52 00 54 00 4C 00 45 00 54 00 2E 00  B.A.R.T.L.E.T...
0040  4E 00 45 00 54 00 00 00 08 5E 17 00 08 00 00 00  N.E.T....^......
0050  00 00 00 00 08 00 00 00 57 00 49 00 4E 00 58 00  ........W.I.N.X.
0060  50 00 2D 00 35 00 00 00 4D 20 E4 59 70 FC A2 CE  P.-.5...M .Yp...
0070  D5 0D 54 4A 00 00 00 00 00 00 00 00 00 00 00 00  ..TJ............
0080  01 00 00 00 01 00 00 00 D0 F4 E6 00 00 00 00 00  ................
0090  00 00 00 00 58 CF 15 00 94 F8 E6 00 00 00 00 00  ....X...........
00A0  00 00 00 00 00 00 00 00 00 00 00 00 1C 01 1C 01  ................
00B0  60 F5 E6 00 2E 00 30 00 80 27 50 74 00 00 00 00  `.....0..'Pt....
00C0  00 00 00 00 00 00 00 00 00 00 00 00 03 00 00 00  ................
00D0  00 00 00 00 00 00 00 00 00 00 00 00 08 00 00 00  ................
00E0  00 00 00 00 08 00 00 00 77 00 69 00 6E 00 78 00  ........w.i.n.x.
00F0  70 00 2D 00 35 00 00 00 18 00 00 00 00 00 00 00  p.-.5...........
0100  18 00 00 00 44 00 65 00 66 00 61 00 75 00 6C 00  ....D.e.f.a.u.l.
0110  74 00 2D 00 46 00 69 00 72 00 73 00 74 00 2D 00  t.-.F.i.r.s.t.-.
0120  53 00 69 00 74 00 65 00 2D 00 4E 00 61 00 6D 00  S.i.t.e.-.N.a.m.
0130  65 00 00 00 8E 00 00 00 00 00 00 00 8E 00 00 00  e...............
0140  1C 01 00 00 05 00 00 00 01 00 00 00 28 0A 00 00  ............(...
0150  02 00 00 00 53 00 65 00 72 00 76 00 69 00 63 00  ....S.e.r.v.i.c.
0160  65 00 20 00 50 00 61 00 63 00 6B 00 20 00 32 00  e. .P.a.c.k. .2.
0170  00 00 E6 00 02 00 00 00 00 00 00 00 20 C0 0B 00  ............ ...
0180  40 5A 86 5B 00 00 00 00 00 00 00 00 00 00 00 00  @Z.[............
0190  30 00 09 00 02 00 00 00 00 00 00 00 00 00 00 00  0...............
01A0  B0 E4 E6 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
01B0  00 00 00 00 C4 F5 E6 00 0E 00 00 00 00 00 00 00  ................
01C0  D0 E4 E6 00 20 F6 E6 00 00 00 00 00 00 00 00 00  .... ...........
01D0  00 00 00 00 0D 00 00 00 58 61 17 00 4F 00 00 00  ........Xa..O...
01E0  00 00 00 00 00 00 09 00 1A 00 00 00 00 00 00 00  ................
01F0  00 00 00 00 00 00 00 00 20 C0 0B 00 00 00 00 00  ........ .......
0200  04 5D 88 8A 48 00 00 00 CC 27 87 5B BC 27 87 5B  .]..H....'.[.'.[
0210  09 00 00 00 DA 27 87 5B D0 F8 E6 00 00 00 00 00  .....'.[........
0220  00 00 00 00 C6 27 87 5B DA 5A 86 5B 00 00 00 00  .....'.[.Z.[....
0230  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0240  24 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  $...............
0250  00 00 00 00 02 00 00 00 00 01 01 00 18 00 00 00  ................
0260  00 00 00 00 17 00 00 00 57 00 69 00 6E 00 64 00  ........W.i.n.d.
0270  6F 00 77 00 73 00 20 00 58 00 50 00 20 00 50 00  o.w.s. .X.P. .P.
0280  72 00 6F 00 66 00 65 00 73 00 73 00 69 00 6F 00  r.o.f.e.s.s.i.o.
0290  6E 00 61 00 6C 00 00 00 8A E3 13 71 02 F4 36 71  n.a.l......q..6q
02A0  01 40 04 00 01 00 00 00-                         .@......*

Regards,
Bill Wesse
MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM
8055 Microsoft Way
Charlotte, NC 28273
TEL:  [phone]
CELL: [phone]
FAX:  [phone]

-----Original Message-----
From: Andrew Bartlett [mailto:abartlet@...]
Sent: Tuesday, July 07, 2009 11:45 PM
To: Interoperability Documentation Help
Cc: pfif@...; cifs-protocol@...; Matthias Dieter Wallnöfer
Subject: Please clarify LSA and OsVersion behaviour in MS-NRPC

In MS-NRPC 2.2.1.3.6 NETLOGON_WORKSTATION_INFO it has:

>
> typedef struct _NETLOGON_WORKSTATION_INFO {
>   NETLOGON_LSA_POLICY_INFO LsaPolicy;
>
This is defined in 2.2.1.3.5, but not very helpfully:

> The NETLOGON_LSA_POLICY_INFO structure defines Local Security
> Authority (LSA) policy information as an unsigned character buffer. For details, see [LSAPOLICY] and [MS-LSAD].

My question is:  Is this buffer ever filled in (it is null in the attached example from a WinXP join), and if so, what does it mean?  The links to [LSAPOLICY] and [MS-LSAD] are non-specific and not very useful in understanding the possible inputs here.

Further down, it claims:

> OsVersion: A null-terminated Unicode string that contains the version number of the operating
>   system installed on the client machine.<23> The DC that receives this data structure updates
>   the operatingSystemVersion attribute of the client's machine account object in Active
>   Directory with this value, unchanged and uninterpreted, as specified in [MS-ADTS].
> OsName: A null-terminated Unicode string that contains the name of the operating system
>   installed on the client machine.<24> The DC that receives this data structure updates the
>   operatingSystem attribute of the client's machine account object in Active Directory, as
>   specified in [MS-ADTS].

Firstly, which part of MS-ADTS does this refer?  It is a large document, and I can't find the reference.

However, the main problem I have is that the text for OsName is plausable, given the input.  The examples in <24> even match up with the wire data (attached).  However, OsVersion is a very different thing.
What is in this 284 byte buffer?  For certain it is not a unicode string
- and certainly not the one indicated in <23>:

> <23> Section 2.2.1.3.6: The version and build number of the client
> operating system are used. For example, for Windows Server 2003 SP1,
> the string "5.2 (3790)" is used, which indicates version 5.2 and build number 3790.
>

Please clarify these inputs, so that Matthias may implement this important part of NETLOGON correctly (see
https://bugzilla.samba.org/show_bug.cgi?id=4888 for his attempts so far).


Thanks,

Andrew Bartlett


--
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.

_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

[Hongwei Sun]

Andrew,

  After review, we confirmed that the LsaPolicy in _NETLOGON_WORKSTATION_INFO is not used in any release of Windows.  The LsaPolicySize field is set to zero, and the LsaPolicy field is set to NULL.   I filed a request for documentation update to include this information.

  Bill already responded to you in a separate e-mail regarding the behaviour of OsVersion.
 
  Please let us know if you have any further questions.

Thanks!

--------------------------------------------------------------------
Hongwei  Sun - Sr. Support Escalation Engineer
DSC Protocol  Team, Microsoft
hongweis@...
Tel:  [phone] x 57027
---------------------------------------------------------------------


-----Original Message-----
From: Andrew Bartlett [mailto:abartlet@...]
Sent: Tuesday, July 07, 2009 10:45 PM
To: Interoperability Documentation Help
Cc: pfif@...; cifs-protocol@...; Matthias Dieter Wallnöfer
Subject: Please clarify LSA and OsVersion behaviour in MS-NRPC

In MS-NRPC 2.2.1.3.6 NETLOGON_WORKSTATION_INFO it has:

>
> typedef struct _NETLOGON_WORKSTATION_INFO {
>   NETLOGON_LSA_POLICY_INFO LsaPolicy;
>
This is defined in 2.2.1.3.5, but not very helpfully:

> The NETLOGON_LSA_POLICY_INFO structure defines Local Security
> Authority (LSA) policy information as an unsigned character buffer. For details, see [LSAPOLICY] and [MS-LSAD].

My question is:  Is this buffer ever filled in (it is null in the attached example from a WinXP join), and if so, what does it mean?  The links to [LSAPOLICY] and [MS-LSAD] are non-specific and not very useful in understanding the possible inputs here.

Further down, it claims:

> OsVersion: A null-terminated Unicode string that contains the version number of the operating
>   system installed on the client machine.<23> The DC that receives this data structure updates
>   the operatingSystemVersion attribute of the client's machine account object in Active
>   Directory with this value, unchanged and uninterpreted, as specified in [MS-ADTS].
> OsName: A null-terminated Unicode string that contains the name of the operating system
>   installed on the client machine.<24> The DC that receives this data structure updates the
>   operatingSystem attribute of the client's machine account object in Active Directory, as
>   specified in [MS-ADTS].

Firstly, which part of MS-ADTS does this refer?  It is a large document, and I can't find the reference.

However, the main problem I have is that the text for OsName is plausable, given the input.  The examples in <24> even match up with the wire data (attached).  However, OsVersion is a very different thing.
What is in this 284 byte buffer?  For certain it is not a unicode string
- and certainly not the one indicated in <23>:

> <23> Section 2.2.1.3.6: The version and build number of the client
> operating system are used. For example, for Windows Server 2003 SP1,
> the string "5.2 (3790)" is used, which indicates version 5.2 and build number 3790.
>

Please clarify these inputs, so that Matthias may implement this important part of NETLOGON correctly (see
https://bugzilla.samba.org/show_bug.cgi?id=4888 for his attempts so far).


Thanks,

Andrew Bartlett


--
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.
_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

[Andrew Bartlett]

On Tue, 2009-07-14 at 10:11 -0700, Hongwei Sun wrote:

> Andrew,
>
>   After review, we confirmed that the LsaPolicy in
> _NETLOGON_WORKSTATION_INFO is not used in any release of Windows.  The
> LsaPolicySize field is set to zero, and the LsaPolicy field is set to
> NULL.   I filed a request for documentation update to include this
> information.
>
>   Bill already responded to you in a separate e-mail regarding the behaviour of OsVersion.
>  
>   Please let us know if you have any further questions.

Thanks.  It's good to have this clarified.

Andrew Bartlett
--
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Cisco Inc.


_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

[Bill Wesse]

Good morning Andrew. I have attached the original response email for your convenience. I notice that I previously neglected to provide the case number, which is SRX090713600128.

The document changes are not yet available; I have placed some relevant notes below concerning where I have reported the [MS-NRPC] document to be deficient, and will advise you as soon as we have the change information.


[MS-NRPC]: Netlogon Remote Protocol Specification

==========
2.2.1.3.6 NETLOGON_WORKSTATION_INFO

Notes:
The OsVersion member is an OSVERSIONINFOEX structure (284 bytes). <23> shows "5.2 (3790)" as an example, and there is no reference to OsVersion as an OSVERSIONINFOEX structure [MS-REF]

==========
<23> Section 2.2.1.3.6: The version and build number of the client operating system are used. For example, for Windows Server 2003 with SP1, the string "5.2 (3790)" is used, which indicates version 5.2 and build number 3790.

Notes:
There is no clear format specification for the operatingSystemVersion string example. Additional clarification concerning where that is meaningfully defined ([MS-ADA3] 2.55; the only appearance of operatingSystemVersion in [MS-ADTS] is at 3.1.1.2.3.5 Flag fRODCFilteredAttribute in Attribute searchFlags.

Regards,
Bill Wesse
MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM
8055 Microsoft Way
Charlotte, NC 28273
TEL:  [phone]
CELL: [phone]
FAX:  [phone]


-----Original Message-----
From: Andrew Bartlett [mailto:abartlet@...]
Sent: Tuesday, July 14, 2009 10:25 PM
To: Hongwei Sun
Cc: pfif@...; cifs-protocol@...; Matthias Dieter Wallnöfer; Bill Wesse
Subject: Re: [cifs-protocol] Please clarify LSA and OsVersion behaviour in MS-NRPC

On Tue, 2009-07-14 at 10:11 -0700, Hongwei Sun wrote:

> Andrew,
>
>   After review, we confirmed that the LsaPolicy in
> _NETLOGON_WORKSTATION_INFO is not used in any release of Windows.  The
> LsaPolicySize field is set to zero, and the LsaPolicy field is set to
> NULL.   I filed a request for documentation update to include this
> information.
>
>   Bill already responded to you in a separate e-mail regarding the behaviour of OsVersion.
>  
>   Please let us know if you have any further questions.

Thanks.  It's good to have this clarified.

Andrew Bartlett
--
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Cisco Inc.

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!



OSVERSIONINFOEX Structure
http://msdn.microsoft.com/en-us/library/ms724833(VS.85).aspx

[MS-REF]: Windows Protocols Master Reference
[MSDN-OSVERSIONINFOEX] Microsoft Corporation, "OSVERSIONINFOEX" Structure, http://msdn2.microsoft.com/en-us/library/ms724833.aspx

typedef struct _OSVERSIONINFOEX {
   DWORD dwOSVersionInfoSize;
   DWORD dwMajorVersion;
   DWORD dwMinorVersion;
   DWORD dwBuildNumber;
   DWORD dwPlatformId;
   TCHAR szCSDVersion[128];
   WORD  wServicePackMajor;
   WORD  wServicePackMinor;
   WORD  wSuiteMask;
   BYTE  wProductType;
   BYTE  wReserved;
} OSVERSIONINFOEX, *POSVERSIONINFOEX, *LPOSVERSIONINFOEX;


netlogon-29.0.in


OsVersion
---------

 blob2: struct lsa_BinaryString
     length                   : 0x011c (284)
     size                     : 0x011c (284)
     array                    : *


0140  DWORD dwOSVersionInfoSize  0x0000011C  (284)
0144  DWORD dwMajorVersion       0x00000005    (5) 5.1 Windows XP
0148  DWORD dwMinorVersion       0x00000001    (1)
014C  DWORD dwBuildNumber        0x00000A28 (2600)
0150  DWORD dwPlatformId         0x00000002    (2) VER_PLATFORM_WIN32_NT
0154  TCHAR szCSDVersion[128]    "Service Pack 2\0"
0170  TCHAR szCSDVersion[...]    (ignore; recycled memory)
0254  WORD wServicePackMajor         0x0002    (2) 2.0
0256  WORD wServicePackMinor         0x0000    (0)
0257  WORD wSuiteMask                0x0100  (256) VER_SUITE_SINGLEUSERTS
0257  BYTE wProductType                0x01    (1) VER_NT_WORKSTATION
0258  BYTE wReserved                   0x00    (0)

0140  1C 01 00 00                                      ....             DWORD dwOSVersionInfoSize  0x0000011C  (284)
0144              05 00 00 00                              ....         DWORD dwMajorVersion       0x00000005    (5) 5.1 Windows XP
0148                          01 00 00 00                      ....     DWORD dwMinorVersion       0x00000001    (1)
014C                                      28 0A 00 00              (... DWORD dwBuildNumber        0x00000A28 (2600)
0150  02 00 00 00                                      ....             DWORD dwPlatformId         0x00000002    (2) VER_PLATFORM_WIN32_NT
0154              53 00 65 00 72 00 76 00 69 00 63 00      S.e.r.v.i.c. TCHAR szCSDVersion[128]    Service Pack 2
0160  65 00 20 00 50 00 61 00 63 00 6B 00 20 00 32 00  e. .P.a.c.k. .2.
0170  00 00                                            ..
0170        E6 00 02 00 00 00 00 00 00 00 20 C0 0B 00    .......... ... ignore; recycled memory: TCHAR szCSDVersion[128] ...
0180  40 5A 86 5B 00 00 00 00 00 00 00 00 00 00 00 00  @Z.[............
0190  30 00 09 00 02 00 00 00 00 00 00 00 00 00 00 00  0...............
01A0  B0 E4 E6 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
01B0  00 00 00 00 C4 F5 E6 00 0E 00 00 00 00 00 00 00  ................
01C0  D0 E4 E6 00 20 F6 E6 00 00 00 00 00 00 00 00 00  .... ...........
01D0  00 00 00 00 0D 00 00 00 58 61 17 00 4F 00 00 00  ........Xa..O...
01E0  00 00 00 00 00 00 09 00 1A 00 00 00 00 00 00 00  ................
01F0  00 00 00 00 00 00 00 00 20 C0 0B 00 00 00 00 00  ........ .......
0200  04 5D 88 8A 48 00 00 00 CC 27 87 5B BC 27 87 5B  .]..H....'.[.'.[
0210  09 00 00 00 DA 27 87 5B D0 F8 E6 00 00 00 00 00  .....'.[........
0220  00 00 00 00 C6 27 87 5B DA 5A 86 5B 00 00 00 00  .....'.[.Z.[....
0230  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0240  24 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  $...............
0250  00 00 00 00                                      ....
0254              02 00                                    ..           WORD wServicePackMajor     0x0002   (2) 2.0
0256                    00 00                                ..         WORD wServicePackMinor     0x0000   (0)
0257                          00 01                            ..       WORD wSuiteMask            0x0100 (256) VER_SUITE_SINGLEUSERTS
0257                                01                           .      BYTE wProductType            0x01   (1) VER_NT_WORKSTATION
0258                                   00                          .    BYTE wReserved               0x00   (0)



NTSTATUS NetrLogonGetDomainInfo(
   [in, string] LOGONSRV_HANDLE ServerName,
   [in, string, unique] wchar_t* ComputerName,
   [in] PNETLOGON_AUTHENTICATOR Authenticator,
   [in, out] PNETLOGON_AUTHENTICATOR ReturnAuthenticator,
   [in] DWORD Level,
   [in, switch_is(Level)] PNETLOGON_WORKSTATION_INFORMATION WkstaBuffer,
   [out, switch_is(Level)] PNETLOGON_DOMAIN_INFORMATION DomBuffer
);

0000  1E 00 00 00 00 00 00 00 1E 00 00 00 5C 00 5C 00  ............\.\.
0010  6E 00 61 00 6F 00 6D 00 69 00 2E 00 53 00 34 00  n.a.o.m.i...S.4.
0020  2E 00 4E 00 41 00 4F 00 4D 00 49 00 2E 00 41 00  ..N.A.O.M.I...A.
0030  42 00 41 00 52 00 54 00 4C 00 45 00 54 00 2E 00  B.A.R.T.L.E.T...
0040  4E 00 45 00 54 00 00 00 08 5E 17 00 08 00 00 00  N.E.T....^......
0050  00 00 00 00 08 00 00 00 57 00 49 00 4E 00 58 00  ........W.I.N.X.
0060  50 00 2D 00 35 00 00 00 4D 20 E4 59 70 FC A2 CE  P.-.5...M .Yp...
0070  D5 0D 54 4A 00 00 00 00 00 00 00 00 00 00 00 00  ..TJ............
0080  01 00 00 00 01 00 00 00 D0 F4 E6 00 00 00 00 00  ................
0090  00 00 00 00 58 CF 15 00 94 F8 E6 00 00 00 00 00  ....X...........
00A0  00 00 00 00 00 00 00 00 00 00 00 00 1C 01 1C 01  ................
00B0  60 F5 E6 00 2E 00 30 00 80 27 50 74 00 00 00 00  `.....0..'Pt....
00C0  00 00 00 00 00 00 00 00 00 00 00 00 03 00 00 00  ................
00D0  00 00 00 00 00 00 00 00 00 00 00 00 08 00 00 00  ................
00E0  00 00 00 00 08 00 00 00 77 00 69 00 6E 00 78 00  ........w.i.n.x.
00F0  70 00 2D 00 35 00 00 00 18 00 00 00 00 00 00 00  p.-.5...........
0100  18 00 00 00 44 00 65 00 66 00 61 00 75 00 6C 00  ....D.e.f.a.u.l.
0110  74 00 2D 00 46 00 69 00 72 00 73 00 74 00 2D 00  t.-.F.i.r.s.t.-.
0120  53 00 69 00 74 00 65 00 2D 00 4E 00 61 00 6D 00  S.i.t.e.-.N.a.m.
0130  65 00 00 00 8E 00 00 00 00 00 00 00 8E 00 00 00  e...............
0140  1C 01 00 00 05 00 00 00 01 00 00 00 28 0A 00 00  ............(...
0150  02 00 00 00 53 00 65 00 72 00 76 00 69 00 63 00  ....S.e.r.v.i.c.
0160  65 00 20 00 50 00 61 00 63 00 6B 00 20 00 32 00  e. .P.a.c.k. .2.
0170  00 00 E6 00 02 00 00 00 00 00 00 00 20 C0 0B 00  ............ ...
0180  40 5A 86 5B 00 00 00 00 00 00 00 00 00 00 00 00  @Z.[............
0190  30 00 09 00 02 00 00 00 00 00 00 00 00 00 00 00  0...............
01A0  B0 E4 E6 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
01B0  00 00 00 00 C4 F5 E6 00 0E 00 00 00 00 00 00 00  ................
01C0  D0 E4 E6 00 20 F6 E6 00 00 00 00 00 00 00 00 00  .... ...........
01D0  00 00 00 00 0D 00 00 00 58 61 17 00 4F 00 00 00  ........Xa..O...
01E0  00 00 00 00 00 00 09 00 1A 00 00 00 00 00 00 00  ................
01F0  00 00 00 00 00 00 00 00 20 C0 0B 00 00 00 00 00  ........ .......
0200  04 5D 88 8A 48 00 00 00 CC 27 87 5B BC 27 87 5B  .]..H....'.[.'.[
0210  09 00 00 00 DA 27 87 5B D0 F8 E6 00 00 00 00 00  .....'.[........
0220  00 00 00 00 C6 27 87 5B DA 5A 86 5B 00 00 00 00  .....'.[.Z.[....
0230  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0240  24 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  $...............
0250  00 00 00 00 02 00 00 00 00 01 01 00 18 00 00 00  ................
0260  00 00 00 00 17 00 00 00 57 00 69 00 6E 00 64 00  ........W.i.n.d.
0270  6F 00 77 00 73 00 20 00 58 00 50 00 20 00 50 00  o.w.s. .X.P. .P.
0280  72 00 6F 00 66 00 65 00 73 00 73 00 69 00 6F 00  r.o.f.e.s.s.i.o.
0290  6E 00 61 00 6C 00 00 00 8A E3 13 71 02 F4 36 71  n.a.l......q..6q
02A0  01 40 04 00 01 00 00 00-                         .@......*

Regards,
Bill Wesse
MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM
8055 Microsoft Way
Charlotte, NC 28273
TEL:  [phone]
CELL: [phone]
FAX:  [phone]

-----Original Message-----
From: Andrew Bartlett [mailto:abartlet@...]
Sent: Tuesday, July 07, 2009 11:45 PM
To: Interoperability Documentation Help
Cc: pfif@...; cifs-protocol@...; Matthias Dieter Wallnöfer
Subject: Please clarify LSA and OsVersion behaviour in MS-NRPC

In MS-NRPC 2.2.1.3.6 NETLOGON_WORKSTATION_INFO it has:

>
> typedef struct _NETLOGON_WORKSTATION_INFO {
>   NETLOGON_LSA_POLICY_INFO LsaPolicy;
>
This is defined in 2.2.1.3.5, but not very helpfully:

> The NETLOGON_LSA_POLICY_INFO structure defines Local Security
> Authority (LSA) policy information as an unsigned character buffer. For details, see [LSAPOLICY] and [MS-LSAD].

My question is:  Is this buffer ever filled in (it is null in the attached example from a WinXP join), and if so, what does it mean?  The links to [LSAPOLICY] and [MS-LSAD] are non-specific and not very useful in understanding the possible inputs here.

Further down, it claims:

> OsVersion: A null-terminated Unicode string that contains the version number of the operating
>   system installed on the client machine.<23> The DC that receives this data structure updates
>   the operatingSystemVersion attribute of the client's machine account object in Active
>   Directory with this value, unchanged and uninterpreted, as specified in [MS-ADTS].
> OsName: A null-terminated Unicode string that contains the name of the operating system
>   installed on the client machine.<24> The DC that receives this data structure updates the
>   operatingSystem attribute of the client's machine account object in Active Directory, as
>   specified in [MS-ADTS].

Firstly, which part of MS-ADTS does this refer?  It is a large document, and I can't find the reference.

However, the main problem I have is that the text for OsName is plausable, given the input.  The examples in <24> even match up with the wire data (attached).  However, OsVersion is a very different thing.
What is in this 284 byte buffer?  For certain it is not a unicode string
- and certainly not the one indicated in <23>:

> <23> Section 2.2.1.3.6: The version and build number of the client
> operating system are used. For example, for Windows Server 2003 SP1,
> the string "5.2 (3790)" is used, which indicates version 5.2 and build number 3790.
>

Please clarify these inputs, so that Matthias may implement this important part of NETLOGON correctly (see
https://bugzilla.samba.org/show_bug.cgi?id=4888 for his attempts so far).


Thanks,

Andrew Bartlett


--
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.

_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

[Andrew Bartlett]

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
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

[Bill Wesse]

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:  [phone]
CELL: [phone]
FAX:  [phone]


-----Original Message-----
From: Andrew Bartlett [mailto:abartlet@...]
Sent: Monday, July 27, 2009 7:26 AM
To: Bill Wesse
Cc: Interoperability Documentation Help; pfif@...; cifs-protocol@...; 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
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

[Bill Wesse]

Good morning Andrew. I have filed a TDI against your request for guidance concerning SPN updates via the NetrLogonGetDomainInfo NETLOGON_WORKSTATION_INFO.WorkstationFlags.B flag.

Please consider the following text to not be normative in any way; it is not much more than a rundown of applicable account object attributes relevant to the call parameters. I expect your work has led you to similar conclusions.

I will keep you advised of progress on the TDI, and will stand by in case you have further questions or comments!

==============================================================================

[MS_NRPC] 2.2.1.3.5 NETLOGON_WORKSTATION_INFO WorkstationFlags : B

If B is clear (Client does not handle the update of the service principal name (SPN)):

When NetrLogonGetDomainInfo is invoked, a basic validity check for the supplied NETLOGON_WORKSTATION_INFO.DnsHostName string would be to verify the first label matches the NetrLogonGetDomainInfo ComputerName parameter.

Before updating the servicePrincipalName attribute ("HOST/dNSHostName") for the account under the established secure channel, the following checks would be prudent:

   Reference:
   [MS-ADA3]: Active Directory Schema Attributes N-Z
   2.252 Attribute servicePrincipalName

1. NETLOGON_WORKSTATION_INFO.DnsHostName must match the client (machine) account sAMAccountName attribute (minus the trailing '$' character) for the account under the established secure channel.

   Reference:
   [MS-ADA3]: Active Directory Schema Attributes N-Z
   2.221 Attribute sAMAccountName

2. NETLOGON_WORKSTATION_INFO.DnsHostName must match the client (machine) account dNSHostName attribute for the account under the established secure channel.

   Reference:
   [MS-ADA1]: Active Directory Schema Attributes A-L
   2.185 Attribute dNSHostName

3. NETLOGON_WORKSTATION_INFO.DnsHostName must have an allowed DNS suffix (e.g., the domain DNS name).

   Reference:
   [MS-ADA2]: Active Directory Schema Attributes M
   2.181 Attribute msDS-AllowedDNSSuffixes


Regards,
Bill Wesse
MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM
8055 Microsoft Way
Charlotte, NC 28273
TEL:  [phone]
CELL: [phone]
FAX:  [phone]


-----Original Message-----
From: Bill Wesse
Sent: Monday, July 27, 2009 8:02 AM
To: Andrew Bartlett
Cc: Interoperability Documentation Help; pfif@...; cifs-protocol@...; Matthias Dieter Wallnöfer; Hongwei Sun
Subject: RE: Please clarify LSA and OsVersion behaviour in MS-NRPC (SRX090727600015)

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:  [phone]
CELL: [phone]
FAX:  [phone]


-----Original Message-----
From: Andrew Bartlett [mailto:abartlet@...]
Sent: Monday, July 27, 2009 7:26 AM
To: Bill Wesse
Cc: Interoperability Documentation Help; pfif@...; cifs-protocol@...; 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
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

[Matthias Dieter Wallnöfer]

I tried to reproduce your suggested checks with a testsuite against my
Windows Server 2003 R2 but couldn't see them applied. I was able to set
the workstation info DNS name to an arbitrary value, deactivated the
update through client flag (you call it "B") in the
LogonGetDomainInformations call and the server didn't hesitate to set
the "dNSHostname" and also the "servicePrincipalName" to the nonsense value.

So the checks are good, but also Windows Server should implement them.

Regards,
Matthias Dieter Wallnöfer

Bill Wesse schrieb:

> Good morning Andrew. I have filed a TDI against your request for guidance concerning SPN updates via the NetrLogonGetDomainInfo NETLOGON_WORKSTATION_INFO.WorkstationFlags.B flag.
>
> Please consider the following text to not be normative in any way; it is not much more than a rundown of applicable account object attributes relevant to the call parameters. I expect your work has led you to similar conclusions.
>
> I will keep you advised of progress on the TDI, and will stand by in case you have further questions or comments!
>
> ==============================================================================
>
> [MS_NRPC] 2.2.1.3.5 NETLOGON_WORKSTATION_INFO WorkstationFlags : B
>
> If B is clear (Client does not handle the update of the service principal name (SPN)):
>
> When NetrLogonGetDomainInfo is invoked, a basic validity check for the supplied NETLOGON_WORKSTATION_INFO.DnsHostName string would be to verify the first label matches the NetrLogonGetDomainInfo ComputerName parameter.
>
> Before updating the servicePrincipalName attribute ("HOST/dNSHostName") for the account under the established secure channel, the following checks would be prudent:
>
>    Reference:
>    [MS-ADA3]: Active Directory Schema Attributes N-Z
>    2.252 Attribute servicePrincipalName
>
> 1. NETLOGON_WORKSTATION_INFO.DnsHostName must match the client (machine) account sAMAccountName attribute (minus the trailing '$' character) for the account under the established secure channel.
>
>    Reference:
>    [MS-ADA3]: Active Directory Schema Attributes N-Z
>    2.221 Attribute sAMAccountName
>
> 2. NETLOGON_WORKSTATION_INFO.DnsHostName must match the client (machine) account dNSHostName attribute for the account under the established secure channel.
>
>    Reference:
>    [MS-ADA1]: Active Directory Schema Attributes A-L
>    2.185 Attribute dNSHostName
>
> 3. NETLOGON_WORKSTATION_INFO.DnsHostName must have an allowed DNS suffix (e.g., the domain DNS name).
>
>    Reference:
>    [MS-ADA2]: Active Directory Schema Attributes M
>    2.181 Attribute msDS-AllowedDNSSuffixes
>
>
> Regards,
> Bill Wesse
> MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM
> 8055 Microsoft Way
> Charlotte, NC 28273
> TEL:  [phone]
> CELL: [phone]
> FAX:  [phone]
>
>
> -----Original Message-----
> From: Bill Wesse
> Sent: Monday, July 27, 2009 8:02 AM
> To: Andrew Bartlett
> Cc: Interoperability Documentation Help; pfif@...; cifs-protocol@...; Matthias Dieter Wallnöfer; Hongwei Sun
> Subject: RE: Please clarify LSA and OsVersion behaviour in MS-NRPC (SRX090727600015)
>
> 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:  [phone]
> CELL: [phone]
> FAX:  [phone]
>
>
> -----Original Message-----
> From: Andrew Bartlett [mailto:abartlet@...]
> Sent: Monday, July 27, 2009 7:26 AM
> To: Bill Wesse
> Cc: Interoperability Documentation Help; pfif@...; cifs-protocol@...; 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
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

[Bill Wesse]

Thank you for the information on how R2 handles this. I will dig into that starting later today.

Regards,
Bill Wesse
MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM
8055 Microsoft Way
Charlotte, NC 28273
TEL:  [phone]
CELL: [phone]
FAX:  [phone]


-----Original Message-----
From: Matthias Dieter Wallnöfer [mailto:mwallnoefer@...]
Sent: Thursday, July 30, 2009 5:00 PM
To: Bill Wesse
Cc: Andrew Bartlett; pfif@...; cifs-protocol@...
Subject: Re: Please clarify LSA and OsVersion behaviour in MS-NRPC (SRX090727600015)

I tried to reproduce your suggested checks with a testsuite against my
Windows Server 2003 R2 but couldn't see them applied. I was able to set
the workstation info DNS name to an arbitrary value, deactivated the
update through client flag (you call it "B") in the
LogonGetDomainInformations call and the server didn't hesitate to set
the "dNSHostname" and also the "servicePrincipalName" to the nonsense value.

So the checks are good, but also Windows Server should implement them.

Regards,
Matthias Dieter Wallnöfer

Bill Wesse schrieb:

> Good morning Andrew. I have filed a TDI against your request for guidance concerning SPN updates via the NetrLogonGetDomainInfo NETLOGON_WORKSTATION_INFO.WorkstationFlags.B flag.
>
> Please consider the following text to not be normative in any way; it is not much more than a rundown of applicable account object attributes relevant to the call parameters. I expect your work has led you to similar conclusions.
>
> I will keep you advised of progress on the TDI, and will stand by in case you have further questions or comments!
>
> ==============================================================================
>
> [MS_NRPC] 2.2.1.3.5 NETLOGON_WORKSTATION_INFO WorkstationFlags : B
>
> If B is clear (Client does not handle the update of the service principal name (SPN)):
>
> When NetrLogonGetDomainInfo is invoked, a basic validity check for the supplied NETLOGON_WORKSTATION_INFO.DnsHostName string would be to verify the first label matches the NetrLogonGetDomainInfo ComputerName parameter.
>
> Before updating the servicePrincipalName attribute ("HOST/dNSHostName") for the account under the established secure channel, the following checks would be prudent:
>
>    Reference:
>    [MS-ADA3]: Active Directory Schema Attributes N-Z
>    2.252 Attribute servicePrincipalName
>
> 1. NETLOGON_WORKSTATION_INFO.DnsHostName must match the client (machine) account sAMAccountName attribute (minus the trailing '$' character) for the account under the established secure channel.
>
>    Reference:
>    [MS-ADA3]: Active Directory Schema Attributes N-Z
>    2.221 Attribute sAMAccountName
>
> 2. NETLOGON_WORKSTATION_INFO.DnsHostName must match the client (machine) account dNSHostName attribute for the account under the established secure channel.
>
>    Reference:
>    [MS-ADA1]: Active Directory Schema Attributes A-L
>    2.185 Attribute dNSHostName
>
> 3. NETLOGON_WORKSTATION_INFO.DnsHostName must have an allowed DNS suffix (e.g., the domain DNS name).
>
>    Reference:
>    [MS-ADA2]: Active Directory Schema Attributes M
>    2.181 Attribute msDS-AllowedDNSSuffixes
>
>
> Regards,
> Bill Wesse
> MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM
> 8055 Microsoft Way
> Charlotte, NC 28273
> TEL:  [phone]
> CELL: [phone]
> FAX:  [phone]
>
>
> -----Original Message-----
> From: Bill Wesse
> Sent: Monday, July 27, 2009 8:02 AM
> To: Andrew Bartlett
> Cc: Interoperability Documentation Help; pfif@...; cifs-protocol@...; Matthias Dieter Wallnöfer; Hongwei Sun
> Subject: RE: Please clarify LSA and OsVersion behaviour in MS-NRPC (SRX090727600015)
>
> 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:  [phone]
> CELL: [phone]
> FAX:  [phone]
>
>
> -----Original Message-----
> From: Andrew Bartlett [mailto:abartlet@...]
> Sent: Monday, July 27, 2009 7:26 AM
> To: Bill Wesse
> Cc: Interoperability Documentation Help; pfif@...; cifs-protocol@...; 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
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

[Andrew Bartlett]

On Fri, 2009-07-31 at 07:31 -0700, Bill Wesse wrote:
> Thank you for the information on how R2 handles this. I will dig into that starting later today.

Has there been any progress clarifying the actual windows behaviour in
the past 10 days?

We would like to move on with a solution that both matches the
documentation and the demonstrated behaviour soon.

Thanks,

--
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Cisco Inc.


_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

[Andrew Bartlett]

On Mon, 2009-08-10 at 17:42 +1000, Andrew Bartlett wrote:
> On Fri, 2009-07-31 at 07:31 -0700, Bill Wesse wrote:
> > Thank you for the information on how R2 handles this. I will dig into that starting later today.
>
> Has there been any progress clarifying the actual windows behaviour in
> the past 10 days?
>
> We would like to move on with a solution that both matches the
> documentation and the demonstrated behaviour soon.

I would really like to get this clarified for the next Samba4 alpha.
I'm not too happy with the client being able to set any value, but this
appears to be the windows behaviour.  Will there be any clarification
forthcoming?

Thanks,

--
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Cisco Inc.


_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

[Bill Wesse]

Andrew - I think I might have missed a previous email of yours. If so, I offer my apologies.

The actual Windows behavior is - as Matthias noted previously - that NetrLogonGetDomainInfo bypasses the servicePrincipalName constraints (which are documented in [MS-ADTS] 3.1.1.5.3.1.1.4).

We are currently working on which document this should be addressed in ([MS-ADTS] or [MS-NRPC]). I expect that [MS-NRPC] is not the correct place, since SPN validation is carried out by Active Directory, outside the scope of the NetLogon protocol. I do not yet have any information concerning whether or not any product bugs will be filed, but I have alerted the appropriate folks here at Microsoft. That may impact any forthcoming Windows Behavior notes.

[MS-ADTS]:
Active Directory Technical Specification
3.1.1.5.3.1.1.4   servicePrincipalName
        The object has class computer (or a subclass of computer).
        In AD DS, the servicePrincipalName value satisfies the following constraints:
o The SPN is a syntactically correct two-part SPN (see section 5.1.1.4, "Mutual Authentication").
o The instance name matches one of the following: the full DNS name of the machine, the sAMAccountName of the machine (without the terminating "$"), one of the msDS-AdditionalDnsHostName, or one of the msDS-AdditionalSamAccountName (without the terminating "$").

The guidance I provided earlier addresses these constraints; I regret omitting the reference to [MS-ADTS] 3.1.1.5.3.1.1.4 servicePrincipalName.

> Before updating the servicePrincipalName attribute ("HOST/dNSHostName") for the account under the established secure channel, the following checks would be prudent:
>
>    Reference:
>    [MS-ADA3]: Active Directory Schema Attributes N-Z
>    2.252 Attribute servicePrincipalName
>
> 1. NETLOGON_WORKSTATION_INFO.DnsHostName must match the client (machine) account sAMAccountName attribute (minus the trailing '$' character) for the account under the established secure channel.
>
>    Reference:
>    [MS-ADA3]: Active Directory Schema Attributes N-Z
>    2.221 Attribute sAMAccountName
>
> 2. NETLOGON_WORKSTATION_INFO.DnsHostName must match the client (machine) account dNSHostName attribute for the account under the established secure channel.
>
>    Reference:
>    [MS-ADA1]: Active Directory Schema Attributes A-L
>    2.185 Attribute dNSHostName
>
> 3. NETLOGON_WORKSTATION_INFO.DnsHostName must have an allowed DNS suffix (e.g., the domain DNS name).
>
>    Reference:
>    [MS-ADA2]: Active Directory Schema Attributes M
>    2.181 Attribute msDS-AllowedDNSSuffixes

Regards,
Bill Wesse
MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM
8055 Microsoft Way
Charlotte, NC 28273
TEL:  [phone]
CELL: [phone]
FAX:  [phone]


-----Original Message-----
From: Andrew Bartlett [mailto:abartlet@...]
Sent: Monday, August 24, 2009 7:59 AM
To: Bill Wesse
Cc: cifs-protocol@...; pfif@...; Matthias Dieter Wallnöfer
Subject: Re: [cifs-protocol] Please clarify LSA and OsVersion behaviour in MS-NRPC (SRX090727600015)

On Mon, 2009-08-10 at 17:42 +1000, Andrew Bartlett wrote:
> On Fri, 2009-07-31 at 07:31 -0700, Bill Wesse wrote:
> > Thank you for the information on how R2 handles this. I will dig into that starting later today.
>
> Has there been any progress clarifying the actual windows behaviour in
> the past 10 days?
>
> We would like to move on with a solution that both matches the
> documentation and the demonstrated behaviour soon.

I would really like to get this clarified for the next Samba4 alpha.
I'm not too happy with the client being able to set any value, but this appears to be the windows behaviour.  Will there be any clarification forthcoming?

Thanks,

--
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Cisco Inc.
_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

[Bill Wesse]

Good morning Andrew - I have attached a pdf showing the changes that will be in the next update to [MS-NRPC] concerning section 2.2.1.3.6 NETLOGON_WORKSTATION_INFO OsVersion field description.

These changes will reference [MS-RPRN], which has a full definition for the OSVERSIONINFOEX structure; I have provided a link for this:

[MS-RPRN]: Print System Remote Protocol Specification
2.2.3.10.2 OSVERSIONINFOEX
http://msdn.microsoft.com/en-us/library/cc669279.aspx

Please let me know if this answers your question satisfactorily; if so, I will consider the case resolved. Thanks for helping us improve our documentation!

Regards,
Bill Wesse
MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM
8055 Microsoft Way
Charlotte, NC 28273
TEL:  [phone]
CELL: [phone]
FAX:  [phone]


-----Original Message-----
From: Andrew Bartlett [mailto:abartlet@...]
Sent: Monday, July 27, 2009 7:26 AM
To: Bill Wesse
Cc: Interoperability Documentation Help; pfif@...; cifs-protocol@...; 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
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

[Andrew Bartlett]

On Mon, 2009-08-24 at 07:41 -0700, Bill Wesse wrote:
> Good morning Andrew - I have attached a pdf showing the changes that will be in the next update to [MS-NRPC] concerning section 2.2.1.3.6 NETLOGON_WORKSTATION_INFO OsVersion field description.
>
> These changes will reference [MS-RPRN], which has a full definition for the OSVERSIONINFOEX structure; I have provided a link for this:
>
> [MS-RPRN]: Print System Remote Protocol Specification
> 2.2.3.10.2 OSVERSIONINFOEX
> http://msdn.microsoft.com/en-us/library/cc669279.aspx
>
> Please let me know if this answers your question satisfactorily; if so, I will consider the case resolved. Thanks for helping us improve our documentation!

While the proposed changes remove the outright incorrect information, I
don't see how they help us populate the operatingSystemVersion
attribute.  The references to the update, and the rules by which it is
processed need to be corrected rather than just removed.

Andrew Bartlett

--
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Cisco Inc.


_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

[Andrew Bartlett]

On Mon, 2009-08-24 at 07:35 -0700, Bill Wesse wrote:
> Andrew - I think I might have missed a previous email of yours. If so, I offer my apologies.
>
> The actual Windows behavior is - as Matthias noted previously - that
> NetrLogonGetDomainInfo bypasses the servicePrincipalName constraints
> (which are documented in [MS-ADTS] 3.1.1.5.3.1.1.4).

OK, When will this security bug be addressed?  I thought I saw a
difference in this behaviour for Windows 2008 - honestly I was expecting
'Windows 2008 fixed this' as your reply.

> We are currently working on which document this should be addressed in
> ([MS-ADTS] or [MS-NRPC]). I expect that [MS-NRPC] is not the correct
> place, since SPN validation is carried out by Active Directory,
> outside the scope of the NetLogon protocol. I do not yet have any
> information concerning whether or not any product bugs will be filed,
> but I have alerted the appropriate folks here at Microsoft. That may
> impact any forthcoming Windows Behavior notes.

OK.  I would appreciate an update on what the expected long-term
behaviour of Microsoft products will be, so we know what we must
emulate.  (Oh the joys of bug-for-bug compatibility)

> [MS-ADTS]:
> Active Directory Technical Specification
> 3.1.1.5.3.1.1.4   servicePrincipalName
> The object has class computer (or a subclass of computer).
> In AD DS, the servicePrincipalName value satisfies the following constraints:
> o The SPN is a syntactically correct two-part SPN (see section 5.1.1.4, "Mutual Authentication").
> o The instance name matches one of the following: the full DNS name of the machine, the sAMAccountName of the machine (without the terminating "$"), one of the msDS-AdditionalDnsHostName, or one of the msDS-AdditionalSamAccountName (without the terminating "$").
>
> The guidance I provided earlier addresses these constraints; I regret omitting the reference to [MS-ADTS] 3.1.1.5.3.1.1.4 servicePrincipalName.
>
> > Before updating the servicePrincipalName attribute ("HOST/dNSHostName") for the account under the established secure channel, the following checks would be prudent:
> >
> >    Reference:
> >    [MS-ADA3]: Active Directory Schema Attributes N-Z
> >    2.252 Attribute servicePrincipalName
> >
> > 1. NETLOGON_WORKSTATION_INFO.DnsHostName must match the client (machine) account sAMAccountName attribute (minus the trailing '$' character) for the account under the established secure channel.
> >
> >    Reference:
> >    [MS-ADA3]: Active Directory Schema Attributes N-Z
> >    2.221 Attribute sAMAccountName
> >
> > 2. NETLOGON_WORKSTATION_INFO.DnsHostName must match the client (machine) account dNSHostName attribute for the account under the established secure channel.
> >
> >    Reference:
> >    [MS-ADA1]: Active Directory Schema Attributes A-L
> >    2.185 Attribute dNSHostName
> >
> > 3. NETLOGON_WORKSTATION_INFO.DnsHostName must have an allowed DNS suffix (e.g., the domain DNS name).
> >
> >    Reference:
> >    [MS-ADA2]: Active Directory Schema Attributes M
> >    2.181 Attribute msDS-AllowedDNSSuffixes

Thanks for the detail.  I look forward to being able to use it some
day :-)

Andrew Bartlett

--
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Cisco Inc.


_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

[Bill Wesse]

Good morning Andrew. Thanks for your feedback. I have interpolated available information below.

>> Andrew - I think I might have missed a previous email of yours. If so, I offer my apologies.
>>
>> The actual Windows behavior is - as Matthias noted previously - that
>> NetrLogonGetDomainInfo bypasses the servicePrincipalName constraints
>> (which are documented in [MS-ADTS] 3.1.1.5.3.1.1.4).
>
>OK, When will this security bug be addressed?  I thought I saw a difference in this behaviour for Windows 2008 - >honestly I was expecting 'Windows 2008 fixed this' as your reply.

This is currently 'work-in-progress', and I will update you as soon as I have information. My understanding is that this is not an issue with releases after Windows 2003 (which matches with your comments concerning Windows 2008).

>> We are currently working on which document this should be addressed in
>> ([MS-ADTS] or [MS-NRPC]). I expect that [MS-NRPC] is not the correct
>> place, since SPN validation is carried out by Active Directory,
>> outside the scope of the NetLogon protocol. I do not yet have any
>> information concerning whether or not any product bugs will be filed,
>> but I have alerted the appropriate folks here at Microsoft. That may
>> impact any forthcoming Windows Behavior notes.

>OK.  I would appreciate an update on what the expected long-term behaviour of Microsoft products will be, so we >know what we must emulate.  (Oh the joys of bug-for-bug compatibility)

Some of this will depend on Windows 2003 and earlier bug/fix details. I will keep you advised!

>Thanks for the detail.  I look forward to being able to use it some day :-)

My pleasure!

Regards,
Bill Wesse
MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM
8055 Microsoft Way
Charlotte, NC 28273
TEL:  [phone]
CELL: [phone]
FAX:  [phone]

-----Original Message-----
From: Andrew Bartlett [mailto:abartlet@...]
Sent: Monday, August 24, 2009 7:30 PM
To: Bill Wesse
Cc: cifs-protocol@...; pfif@...; Matthias Dieter Wallnöfer
Subject: RE: [cifs-protocol] Please clarify LSA and OsVersion behaviour in MS-NRPC (SRX090727600015)

On Mon, 2009-08-24 at 07:35 -0700, Bill Wesse wrote:
> Andrew - I think I might have missed a previous email of yours. If so, I offer my apologies.
>
> The actual Windows behavior is - as Matthias noted previously - that
> NetrLogonGetDomainInfo bypasses the servicePrincipalName constraints
> (which are documented in [MS-ADTS] 3.1.1.5.3.1.1.4).

OK, When will this security bug be addressed?  I thought I saw a difference in this behaviour for Windows 2008 - honestly I was expecting 'Windows 2008 fixed this' as your reply.

> We are currently working on which document this should be addressed in
> ([MS-ADTS] or [MS-NRPC]). I expect that [MS-NRPC] is not the correct
> place, since SPN validation is carried out by Active Directory,
> outside the scope of the NetLogon protocol. I do not yet have any
> information concerning whether or not any product bugs will be filed,
> but I have alerted the appropriate folks here at Microsoft. That may
> impact any forthcoming Windows Behavior notes.

OK.  I would appreciate an update on what the expected long-term behaviour of Microsoft products will be, so we know what we must emulate.  (Oh the joys of bug-for-bug compatibility)

> [MS-ADTS]:
> Active Directory Technical Specification
> 3.1.1.5.3.1.1.4   servicePrincipalName
> The object has class computer (or a subclass of computer).
> In AD DS, the servicePrincipalName value satisfies the following constraints:
> o The SPN is a syntactically correct two-part SPN (see section 5.1.1.4, "Mutual Authentication").
> o The instance name matches one of the following: the full DNS name of the machine, the sAMAccountName of the machine (without the terminating "$"), one of the msDS-AdditionalDnsHostName, or one of the msDS-AdditionalSamAccountName (without the terminating "$").
>
> The guidance I provided earlier addresses these constraints; I regret omitting the reference to [MS-ADTS] 3.1.1.5.3.1.1.4 servicePrincipalName.
>
> > Before updating the servicePrincipalName attribute ("HOST/dNSHostName") for the account under the established secure channel, the following checks would be prudent:
> >
> >    Reference:
> >    [MS-ADA3]: Active Directory Schema Attributes N-Z
> >    2.252 Attribute servicePrincipalName
> >
> > 1. NETLOGON_WORKSTATION_INFO.DnsHostName must match the client (machine) account sAMAccountName attribute (minus the trailing '$' character) for the account under the established secure channel.
> >
> >    Reference:
> >    [MS-ADA3]: Active Directory Schema Attributes N-Z
> >    2.221 Attribute sAMAccountName
> >
> > 2. NETLOGON_WORKSTATION_INFO.DnsHostName must match the client (machine) account dNSHostName attribute for the account under the established secure channel.
> >
> >    Reference:
> >    [MS-ADA1]: Active Directory Schema Attributes A-L
> >    2.185 Attribute dNSHostName
> >
> > 3. NETLOGON_WORKSTATION_INFO.DnsHostName must have an allowed DNS suffix (e.g., the domain DNS name).
> >
> >    Reference:
> >    [MS-ADA2]: Active Directory Schema Attributes M
> >    2.181 Attribute msDS-AllowedDNSSuffixes

Thanks for the detail.  I look forward to being able to use it some day :-)

Andrew Bartlett

--
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Cisco Inc.
_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

[Bill Wesse]

Thanks again for your input; my response interpolated below...

>> Good morning Andrew - I have attached a pdf showing the changes that will be in the next update to [MS-NRPC] concerning section 2.2.1.3.6 NETLOGON_WORKSTATION_INFO OsVersion field description.
>>
>> These changes will reference [MS-RPRN], which has a full definition for the OSVERSIONINFOEX structure; I have provided a link for this:
>>
>> [MS-RPRN]: Print System Remote Protocol Specification
>> 2.2.3.10.2 OSVERSIONINFOEX
>> http://msdn.microsoft.com/en-us/library/cc669279.aspx
>>
>> Please let me know if this answers your question satisfactorily; if so, I will consider the case resolved. Thanks for helping us improve our documentation!

>While the proposed changes remove the outright incorrect information, I don't see how they help us populate the >operatingSystemVersion attribute.  The references to the update, and the rules by which it is processed need to be >corrected rather than just removed.

I'm not sure I understand what is not specified in '[MS-RPRN] 2.2.3.10.2 OSVERSIONINFOEX'. After running down the links in that topic, I see they contain essentially the same information as the MSDN 'OSVERSIONINFOEX Structure' (link shown below, not included in the doc, since we cannot cite MSDN content as normative).

OSVERSIONINFOEX Structure
http://msdn.microsoft.com/en-us/library/ms724833.aspx

Could you elaborate on what sort of processing you are referring to (beyond the implicit matching between the OsName text and OsVersion structured data)?

Regards,
Bill Wesse
MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM
8055 Microsoft Way
Charlotte, NC 28273
TEL:  [phone]
CELL: [phone]
FAX:  [phone]


-----Original Message-----
From: Andrew Bartlett [mailto:abartlet@...]
Sent: Monday, August 24, 2009 7:02 PM
To: Bill Wesse
Cc: pfif@...; cifs-protocol@...; Matthias Dieter Wallnöfer
Subject: Re: Status: Please clarify LSA and OsVersion behaviour in MS-NRPC (SRX090713600128)

On Mon, 2009-08-24 at 07:41 -0700, Bill Wesse wrote:
> Good morning Andrew - I have attached a pdf showing the changes that will be in the next update to [MS-NRPC] concerning section 2.2.1.3.6 NETLOGON_WORKSTATION_INFO OsVersion field description.
>
> These changes will reference [MS-RPRN], which has a full definition for the OSVERSIONINFOEX structure; I have provided a link for this:
>
> [MS-RPRN]: Print System Remote Protocol Specification
> 2.2.3.10.2 OSVERSIONINFOEX
> http://msdn.microsoft.com/en-us/library/cc669279.aspx
>
> Please let me know if this answers your question satisfactorily; if so, I will consider the case resolved. Thanks for helping us improve our documentation!

While the proposed changes remove the outright incorrect information, I don't see how they help us populate the operatingSystemVersion attribute.  The references to the update, and the rules by which it is processed need to be corrected rather than just removed.

Andrew Bartlett

--
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Cisco Inc.
_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

[Andrew Bartlett]

On Tue, 2009-08-25 at 07:04 -0700, Bill Wesse wrote:

> Good morning Andrew. Thanks for your feedback. I have interpolated available information below.
>
> >> Andrew - I think I might have missed a previous email of yours. If so, I offer my apologies.
> >>
> >> The actual Windows behavior is - as Matthias noted previously - that
> >> NetrLogonGetDomainInfo bypasses the servicePrincipalName constraints
> >> (which are documented in [MS-ADTS] 3.1.1.5.3.1.1.4).
> >
> >OK, When will this security bug be addressed?  I thought I saw a difference in this behaviour for Windows 2008 - >honestly I was expecting 'Windows 2008 fixed this' as your reply.
>
> This is currently 'work-in-progress', and I will update you as soon as I have information. My understanding is that this is not an issue with releases after Windows 2003 (which matches with your comments concerning Windows 2008).

Great.  Can you give me the exact rules as they apply to Windows 2008
then?  I can work from them to fix this up to match Windows 2008
behaviour (which was my original goal, but wasn't what Matthias wrote
the code to match).

> >> We are currently working on which document this should be addressed in
> >> ([MS-ADTS] or [MS-NRPC]). I expect that [MS-NRPC] is not the correct
> >> place, since SPN validation is carried out by Active Directory,
> >> outside the scope of the NetLogon protocol. I do not yet have any
> >> information concerning whether or not any product bugs will be filed,
> >> but I have alerted the appropriate folks here at Microsoft. That may
> >> impact any forthcoming Windows Behavior notes.
>
> >OK.  I would appreciate an update on what the expected long-term behaviour of Microsoft products will be, so we >know what we must emulate.  (Oh the joys of bug-for-bug compatibility)
>
> Some of this will depend on Windows 2003 and earlier bug/fix details. I will keep you advised!
>
> >Thanks for the detail.  I look forward to being able to use it some day :-)
>
> My pleasure!

Thanks,

Andrew Bartlett

--
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Cisco Inc.


_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

[Andrew Bartlett]

On Tue, 2009-08-25 at 07:17 -0700, Bill Wesse wrote:

> Thanks again for your input; my response interpolated below...
>
> >> Good morning Andrew - I have attached a pdf showing the changes that will be in the next update to [MS-NRPC] concerning section 2.2.1.3.6 NETLOGON_WORKSTATION_INFO OsVersion field description.
> >>
> >> These changes will reference [MS-RPRN], which has a full definition for the OSVERSIONINFOEX structure; I have provided a link for this:
> >>
> >> [MS-RPRN]: Print System Remote Protocol Specification
> >> 2.2.3.10.2 OSVERSIONINFOEX
> >> http://msdn.microsoft.com/en-us/library/cc669279.aspx
> >>
> >> Please let me know if this answers your question satisfactorily; if so, I will consider the case resolved. Thanks for helping us improve our documentation!
>
> >While the proposed changes remove the outright incorrect information, I don't see how they help us populate the >operatingSystemVersion attribute.  The references to the update, and the rules by which it is processed need to be >corrected rather than just removed.
>
> I'm not sure I understand what is not specified in '[MS-RPRN] 2.2.3.10.2 OSVERSIONINFOEX'. After running down the links in that topic, I see they contain essentially the same information as the MSDN 'OSVERSIONINFOEX Structure' (link shown below, not included in the doc, since we cannot cite MSDN content as normative).
>
> OSVERSIONINFOEX Structure
> http://msdn.microsoft.com/en-us/library/ms724833.aspx
>
> Could you elaborate on what sort of processing you are referring to (beyond the implicit matching between the OsName text and OsVersion structured data)?

No, it is the removal of the explanation of how the OS version specified
here is translated into the operatingSystemVersion attribute, and
how/when that is done that seems to have been removed.

Andrew Bartlett

--
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Cisco Inc.


_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol