Matthieu,
I confirmed that there is a problem with the Netmon parser when displaying
ReferralEntryFlag. The ReferralEntryFlags should be in little endian. In the
packet, it should be parsed as 0x0004 that has TargetSetBoundary bit set for
the first entry. So this is not the problem. I will file a Netmon parser bug
for that.
After looking further at the traces (XP to Samba and XP to Windows server
2008R2), I think that the DFS referral v4 returned by Samba doesn't seem to
have any problem. The only differences between two responses are if the
DFSPath and DFSAlternativePath are shared between ReferralEntries. This
should not be the problem if the correct offsets are used. The details are
shown as below:
Response from Samba:
DfsPath: Index:1 \w2k8r2.home.matws.net\sysvol
DfsAlternatePath: Index:1 \w2k8r2.home.matws.net\sysvol
TargetPath: Index:1 \s2-w2k8r2.w2k8r2.home.matws.net\sysvol
DfsPath: Index:2 \w2k8r2.home.matws.net\sysvol
DfsAlternatePath: Index:2 \w2k8r2.home.matws.net\sysvol
TargetPath: Index:2 \ares.w2k8r2.home.matws.net\sysvol
Response from Windows:
DfsPath: \w2k8r2.home.matws.net\sysvol
DfsAlternatePath: \w2k8r2.home.matws.net\sysvol
TargetPath: Index:1 \s2-w2k8r2.w2k8r2.home.matws.net\sysvol
TargetPath: Index:2 \ares.w2k8r2.home.matws.net\sysvol
It seems that XP client did process the DFS Referral Response v4 from
Samba server correctly. The following is the analysis of the events.
Packet 339 XP ARES DFSC DFSC:Get DFS Referral Request,
FileName: \w2k8r2.home.matws.net\sysvol, MaxReferralLevel: 4
Packet 340 ARES XP DFSC DFSC:Get DFS Referral Response,
NumberOfReferrals: 2 VersionNumber: 4
Two TargetPaths returned :
\s2-w2k8r2.w2k8r2.home.matws.net\sysvol, \ares.w2k8r2.home.matws.net\sysvol
Packet 345 XP ARES DNS DNS:QueryId = 0xB8C8, QUERY (Standard
query), Query for s2-w2k8r2.w2k8r2.home.matws.net
Packet 346 ARES XP DNS DNS:QueryId = 0xB8C8, QUERY (Standard
query), Response - Success, 172.16.100.27
Packet 442 ARES XP ICMP ICMP:Destination Unreachable Message,
Host Unreachable, 172.16.100.27
The client goes to the first target
(s2-w2k8r2.w2k8r2.home.matws.net), but it is not reachable. Why was
s2-w2k8r2.w2k8r2.home.matws.net not accessible ? Was this intended because you
were testing the DFS target failover ?
Packet 634 XP ARES ICMP ICMP:Echo Request Message, From
172.16.101.16 To 172.16.101.1
Packet 657 XP ARES KerberosV5 KerberosV5:TGS Request Realm:
W2K8R2.HOME.MATWS.NET Sname: cifs/ares.w2k8r2.home.matws.net
Packet 659 ARES XP KerberosV5 KerberosV5:TGS Response Cname:
Administrator
Packet 668 XP ARES SMB SMB:C; Tree Connect Andx, Path =
\\ARES.W2K8R2.HOME.MATWS.NET\SYSVOL, Service = ?????
The client fails over to the second target
(ares.w2k8r2.home.matws.net) and use the Kerberos to do session setup.
It seems to me that when it fell back to NTLM, it was trying to access IPC$
for srvsrc service, not to access SYSVOL or NETLOGON. I don't see this in the
trace between Windows. I am not sure if it is related to the DFS Referral
Response v4.
Please let me know what you think.
Thanks!
Hongwei
-----Original Message-----
From: Matthieu Patou [mailto:[email protected]]
Sent: Tuesday, May 31, 2011 4:44 PM
To: Hongwei Sun
Cc: [email protected]; [email protected]; MSSolve Case Email
Subject: Re: [REG:111051779565831] RE: [cifs-protocol] dfs referral for sysvol
and windows XP
On 27/05/2011 03:35, Hongwei Sun wrote:
> Matthieu,
>
> I used your complete trace (dfs2.pcap) to see the entire scenario. The
> reason it falls back to NTLM from Kerberos is because it cannot get the TGS
> ticket for SPN (cifs/w2k8r2.home.matws.net). The error is
> KDC_ERR_S_PRINCIPAL_UNKNOWN. Have you checked if the SPN has been registered
> properly ?
Yeah I know why it falls back to NTLM actually, it's because if fails to accept
correctly the DFS referral answer we've sent.
Because the SPN cifs/domainname do not exists as client should instead use DFS
to find the closest DC for SYSVOL/Netlogon (and other domain DFS).
> 339 3:34:02 PM 5/17/2011 24.0070710 XP ARES DFSC
> DFSC:Get DFS Referral Request, FileName: \w2k8r2.home.matws.net\sysvol,
> MaxReferralLevel: 4
> 340 3:34:02 PM 5/17/2011 24.0145370 ARES XP DFSC
> DFSC:Get DFS Referral Response, NumberOfReferrals: 2 VersionNumber: 4
>
> 488 3:34:22 PM 5/17/2011 43.8453860 XP ARES
> KerberosV5 KerberosV5:TGS Request Realm: W2K8R2.HOME.MATWS.NET Sname:
> cifs/w2k8r2.home.matws.net
> 489 3:34:22 PM 5/17/2011 43.8507430 ARES XP
> KerberosV5 KerberosV5:KRB_ERROR - KDC_ERR_S_PRINCIPAL_UNKNOWN (7)
>
> As far as the DFS Referral version 4, I can see one thing that doesn't
> meet the requirement to be a version 4 of DFS referral. The
> TargetSetBoundary bit in ReferralEntryFlags of the first referral response
> entry MUST be set to 1, as per section 2.2.4.4 of MS-DFSC. In the both
> response entries returned from Samba , this bit is always 0.
>
> - ReferralEntryFlags: 1024 (0x400)
> unused1: (0000010000000...) - Unused
> TargetSetBoundary: (.............0..) - The target corresponding to
> this referral entry is not the first target of a target set.
> NameListReferral: (..............0.) - This is not a trusted
> domain or DC list referral
> unused2: (...............0) - Unused
That's intresting because the way wireshark display this is not the same.
It sees this two bytes in the little endian order while you see them in the big
endian.
Samba4 is also doing this way:
v4: struct dfs_referral_v3
size : 0x0022 (34)
server_type :
DFS_SERVER_NON_ROOT (0)
entry_flags :
DFS_FLAG_REFERRAL_FIRST_TARGET_SET (4)
ttl : 0x00000384 (900)
referrals : union
dfs_referral(case 0)
r1: struct dfs_normal_referral
DFS_path : *
DFS_path :
'\w2k8r2.home.matws.net\sysvol'
DFS_alt_path : *
DFS_alt_path :
'\w2k8r2.home.matws.net\sysvol'
netw_address : *
netw_address :
'\s2-w2k8r2.w2k8r2.home.matws.net\sysvol'
I'm thinking that's correct still as when I take DFS request for DC resolution
(the one when the client send \domain.tld or \NetbiosDomain) from Windows 2003
I have:
v3: struct dfs_referral_v3
size : 0x0022 (34)
server_type :
DFS_SERVER_NON_ROOT (0)
entry_flags :
DFS_FLAG_REFERRAL_DOMAIN_RESP (2)
ttl : 0x00000258 (600)
referrals : union
dfs_referral(case 2)
r2: struct dfs_domain_referral
special_name : *
special_name :
'\msw2k3.tst'
nb_expanded_names : 0x0001 (1)
expanded_names : *
expanded_names: ARRAY(1)
[0] :
'\w2k3advz01.msw2k3.tst'
service_site_guid : union
dfs_padding(case 16)
And for the packet 337
v3: struct dfs_referral_v3
size : 0x0022 (34)
server_type :
DFS_SERVER_NON_ROOT (0)
entry_flags :
DFS_FLAG_REFERRAL_DOMAIN_RESP (2)
ttl : 0x00000258 (600)
referrals : union
dfs_referral(case 2)
r2: struct dfs_domain_referral
special_name : *
special_name :
'\w2k8r2.home.matws.net'
nb_expanded_names : 0x0002 (2)
expanded_names : *
expanded_names: ARRAY(2)
[0] :
'\s2-w2k8r2.w2k8r2.home.matws.net'
[1] :
'\ares.w2k8r2.home.matws.net'
So in both case our pidl generated parser reads the same way ReferralEntryFlags
(entry_flags) should the request come from a Windows Server or from a Samba
server.
I put here: http://www.matws.net/mat/misc/dfs3_from_w2k8r2.pcap.gz
another capture made from w2k8r2 with XP. For me the packets looks very similar
(both are DC on the same domain btw !).
Matthieu.
> Please let me know what you think.
>
> Thanks!
>
> Hongwei
>
>
> -----Original Message-----
> From: Matthieu Patou [mailto:[email protected]]
> Sent: Sunday, May 22, 2011 3:52 PM
> To: Hongwei Sun
> Cc:[email protected];[email protected]; MSSolve Case Email
> Subject: Re: [REG:111051779565831] RE: [cifs-protocol] dfs referral
> for sysvol and windows XP
>
> Hello Hongwei,
>
> So the attached pcap show dfs referral traffic between a S4 and XP hosts.
>
> Where we can see that XP is requesting a level 4 referral and that S4 answers
> to it with an answer following the specification.
>
> After this XP is blocked or fallback to NTLM auth (not shown in this capture
> but in this one:http://www.matws.net/mat/misc/dfs2.pcap.gz).
>
> So I'm wondering if it's normal, maybe XP didn't appreciate the level 4
> answers.
>
> Matthieu.
>
> On 19/05/2011 20:23, Hongwei Sun wrote:
>> Hi, Matthieu,
>>
>> I need some clarification about your question. I have a problem to
>> match the packets to what you have described. The trace has only 6
>> packets. The following are all the packets in the trace:
>>
>> 1 3:28:33 PM 5/17/2011 0.0000000 172.16.101.16 172.16.101.1
>> DFSC DFSC:Get DFS Referral Request, FileName:<empty>, MaxReferralLevel: 3
>> 2 3:28:33 PM 5/17/2011 0.0001600 172.16.101.1 172.16.101.16
>> DFSC DFSC:Get DFS Referral Response, NumberOfReferrals: 2 VersionNumber: 3
>> 3 3:28:33 PM 5/17/2011 0.1360020 172.16.101.16 172.16.101.1
>> DFSC DFSC:Get DFS Referral Request, FileName: \w2k8r2.home.matws.net,
>> MaxReferralLevel: 3
>> 4 3:28:33 PM 5/17/2011 0.1434180 172.16.101.1 172.16.101.16
>> DFSC DFSC:Get DFS Referral Response, NumberOfReferrals: 1 VersionNumber: 3
>> 5 3:28:33 PM 5/17/2011 0.1440790 172.16.101.16 172.16.101.1
>> DFSC DFSC:Get DFS Referral Request, FileName:
>> \w2k8r2.home.matws.net\sysvol, MaxReferralLevel: 4
>> 6 3:28:33 PM 5/17/2011 0.1514540 172.16.101.1 172.16.101.16
>> DFSC DFSC:Get DFS Referral Response, NumberOfReferrals: 2 VersionNumber: 4
>>
>> Could you explain more about the configuration of your testing ,
>> scenario as well as the behavior in question? It will be better if you
>> can point out the packets in question.
>>
>> Thanks!
>>
>> Hongwei
>>
>>
>> -----Original Message-----
>> From:[email protected]
>> [mailto:[email protected]] On Behalf Of Matthieu Patou
>> Sent: Tuesday, May 17, 2011 4:09 PM
>> To: Interoperability Documentation Help;[email protected];
>> [email protected]
>> Subject: [cifs-protocol] dfs referral for sysvol and windows XP
>>
>> Hello doc help,
>>
>> While revisiting the DFS implementation for samba I remade some tests with
>> XP and It seems that when doing the last step in order to resolve
>> \\domain.tld\sysvol.
>> Even if we tend to send the same frame, XP comes to samba 4 when asking for
>> a DC holding \\domain.tld\sysvol. So as we support this level we return
>> entry for this level.
>>
>> But then it fails to connect to \\dc.domain.tld\sysvol and keep doing ntlm
>> connection to \\domain.tld\sysvol.
>>
>> Is this "normal" ?
>>
>> I put another capture here:http://www.matws.net/mat/misc/dfs2.pcap.gz
>> where we can clearly see that the client starts to do NTLM auth to connect
>> to \\domain.tld.
>>
>> Thanks for your answers.
>>
>> Matthieu.
>>
>> --
>> Matthieu Patou
>> Samba Teamhttp://samba.org
>> Private repohttp://git.samba.org/?p=mat/samba.git;a=summary
>>
>>
> --
> Matthieu Patou
> Samba Teamhttp://samba.org
> Private repohttp://git.samba.org/?p=mat/samba.git;a=summary
>
>
>
--
Matthieu Patou
Samba Teamhttp://samba.org
Private repohttp://git.samba.org/?p=mat/samba.git;a=summary
_______________________________________________
cifs-protocol mailing list
[email protected]
https://lists.samba.org/mailman/listinfo/cifs-protocol
