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: +1(980) 776-8200
CELL: +1(704) 661-5438
FAX: +1(704) 665-9606
-----Original Message-----
From: Bill Wesse
Sent: Monday, July 27, 2009 8:02 AM
To: Andrew Bartlett
Cc: Interoperability Documentation Help; p...@tridgell.net;
cifs-proto...@samba.org; 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: +1(980) 776-8200
CELL: +1(704) 661-5438
FAX: +1(704) 665-9606
-----Original Message-----
From: Andrew Bartlett [mailto:abart...@samba.org]
Sent: Monday, July 27, 2009 7:26 AM
To: Bill Wesse
Cc: Interoperability Documentation Help; p...@tridgell.net;
cifs-proto...@samba.org; 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@cifs.org
https://lists.samba.org/mailman/listinfo/cifs-protocol
