[cifs-protocol] dfs referral for sysvol and windows XP

[Hongwei Sun]

Matthieu,

   For Windows XP DFS client, it will set MaxReferralLevel in REQ_GET_DFS_REFERRAL to 3 for Domain Referral and DC Referral and set it to 4 for SYSVOL and other DFS referrals.     This behavior cannot be changed.    As per 3.3.5.2 & 3.3.5.3 MS-DFSC, the server will always return referral version 3  for domain and DC referral even if the client requests version4.    As per 3.2.5.5 MS-DFSC, for SYSVOL and other referral,  the VersionNumber in returned referral entry MUST be set to the minimum of the highest DFS referral version supported by the server and the value specified in the MaxReferralLevel field of REQ_GET_DFS_REFERRAL.   

  Have you tried to make the s2-w2k8r2.w2k8r2.home.matws.net available to see how fast the version 4 referral response is processed?   

Thanks!

Hongwei

 
-----Original Message-----
From: Matthieu Patou [mailto:mat at matws.net] 
Sent: Friday, June 17, 2011 1:50 PM
To: cifs-protocol at cifs.org; Hongwei Sun; pfif at tridgell.net; MSSolve Case Email
Subject: Re: [cifs-protocol] [REG:111051779565831] RE: dfs referral for sysvol and windows XP

Hello Hongwei,
Any news on this ?

Matthieu.
On 08/06/2011 11:22, Matthieu Patou wrote:
> On 08/06/2011 02:01, Hongwei Sun wrote:
>> 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.
> Ok good !
>>
>>    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
> Yeah I noticed this before, it's a limitation in our IDL compiler at 
> the moment and it's uneasy to fix, but as far as I understand it's 
> should be so much of a problem as the structure of the packet is 
> correct (offset are correctly pointing to paths).
>
>>     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 ?
> Well I tried to check that XP is a happy with samba4 as well as I 
> expect him to be ok with Windows 2008R2.
>>     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.
> The thing is that XP is very slow with DFS referral response v4, and 
> not only the first call (as you might expect with the first call as it 
> is testing first the s2-w2k8r2 server). With a DFS referral response
> v3 it's very quick and responsive.
>
> Also I noticed that most of the time XP comes to Windows server with 
> level 3 request and not a level 4, is there anything in Windows server 
> that trigger this behavior ?.
>
> Matthieu.
>
>