[cifs-protocol] [REG:111051779565831] RE: dfs referral for sysvol and windows XP

Matthieu Patou mat at samba.org
Tue May 31 15:44:16 MDT 2011


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:mat at samba.org]
> Sent: Sunday, May 22, 2011 3:52 PM
> To: Hongwei Sun
> Cc:pfif at tridgell.net;cifs-protocol at samba.org; 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:cifs-protocol-bounces at cifs.org
>> [mailto:cifs-protocol-bounces at cifs.org] On Behalf Of Matthieu Patou
>> Sent: Tuesday, May 17, 2011 4:09 PM
>> To: Interoperability Documentation Help;pfif at tridgell.net;
>> cifs-protocol at samba.org
>> 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: dfs_flags_dc_referrals.png
Type: image/png
Size: 20498 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/cifs-protocol/attachments/20110601/1092ff3b/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dfs_flags_sysvol.png
Type: image/png
Size: 21169 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/cifs-protocol/attachments/20110601/1092ff3b/attachment-0003.png>


More information about the cifs-protocol mailing list