[cifs-protocol] [REG:114082011718524] 114082011718524 NTLM username / password routing on member servers and on an AD DC
obaidf at microsoft.com
Wed Sep 10 23:23:48 MDT 2014
Please see the answer to your questions in Q&A fashion as follows:
Q. How does the DC work out what Domain to send it to, when it is one of many domains in a complex trusted domain tree?
A. If the server is a DC, the processing steps are described in section " 184.108.40.206.1 NetrLogonSamLogonEx (Opnum 39)". Specifically, the discussion about trusted domains that starts as follows:
If the request is not for the domain of which the server is a member and the server is a DC, then
the server MUST perform external behavior consistent with locally invoking
LsarQueryTrustedDomainInfoByName (MS-LSAD section 220.127.116.11.5), using the following
Please consult MS-NRPC for a full discussion.
Q. This happens, apparently, when logging on to a domain that doesn't actually exist (eg, an unrelated random name as the domain or workgroup).
A. There is a discussion of authoritative flag in MS-NRPC section "18.104.22.168.1 NetrLogonSamLogonEx (Opnum 39)" as follows:
This Boolean value indicates whether the validation information is final. This field is necessary
because the request might be forwarded through multiple servers. The value TRUE indicates
that the validation information is an authoritative response and MUST remain unchanged. The
value FALSE SHOULD indicate that the validation information is not an authoritative response
and that the client can resend the request to another server.
I my testing, when an unknow domain is specified, I always got Authoritative response.
Q. does user have this SPN?
A. Can you please elaborate more on this question?
Escalation Engineer | Microsoft
Exceeding your expectations is my highest priority. If you would like to provide feedback on your case you may contact my manager at nkang at Microsoft dot com
From: Andrew Bartlett [mailto:abartlet at samba.org]
Sent: Monday, September 8, 2014 7:30 PM
To: Obaid Farooqi
Cc: cifs-protocol at samba.org; MSSolve Case Email
Subject: Re: [REG:114082011718524] 114082011718524 NTLM username / password routing on member servers and on an AD DC
On Mon, 2014-09-08 at 16:33 +0000, Obaid Farooqi wrote:
> Hi Andrew:
> The answers to your questions is in MS-NRPC, specifically in sections "1.3.1 Pass-Through Authentication" and "1.3.2 Pass-Through Authentication and Domain Trusts".
> I cannot advise you on how to implement this in your environment but I can tell you how Windows does it.
> As far as how windows does it, here is what happens in windows:
> 1. first it is determined if the server (machine receiving the ntlm
> authenticate message) is a member of a domain or not. If the server is
> not a member of a domain, then SAM is tried right away.
> 2. If the server is a member of the domain, netlogon is the default
> method. But before shipping the logon request to DC, the server tries
> the SAM first and in case of a failure, sends the request to DC.
> I did not see any difference in processing when the server is just a member server or DC (non GC).
How does the DC work out what Domain to send it to, when it is one of many domains in a complex trusted domain tree?
> I was not able to reproduce the situation in which a DC returns a
> non-authoritative response. I tried it in the situation where there is
> one root DC with two child DCs and a member server that is joined to
> one child domains. If you can please let me know a scenario where DC
> returns non-authoritative and I'll see what windows does.
This happens, apparently, when logging on to a domain that doesn't actually exist (eg, an unrelated random name as the domain or workgroup).
> I'll update you on the following question as I continue my investigation on rootDC:
> 1. does user have this SPN?
Authentication Developer, Samba Team http://samba.org
Samba Developer, Catalyst IT http://catalyst.net.nz/services/samba
More information about the cifs-protocol