Re: [cifs-protocol] [REG:111051779565831] RE: dfs referral for sysvol and windows XP
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 ARESDFSCDFSC:Get DFS Referral Request, FileName: \w2k8r2.home.matws.net\sysvol, MaxReferralLevel: 4 Packet 340 ARESXP DFSCDFSC: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 345XP ARESDNS DNS:QueryId = 0xB8C8, QUERY (Standard query), Query for s2-w2k8r2.w2k8r2.home.matws.net Packet 346ARESXP DNS DNS:QueryId = 0xB8C8, QUERY (Standard query), Response - Success, 172.16.100.27 Packet 442ARESXP ICMPICMP: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 ARESICMPICMP:Echo Request Message, From 172.16.101.16 To 172.16.101.1 Packet 657 XP ARESKerberosV5 KerberosV5:TGS Request Realm: W2K8R2.HOME.MATWS.NET Sname: cifs/ares.w2k8r2.home.matws.net Packet 659 ARESXP KerberosV5 KerberosV5:TGS Response Cname: Administrator Packet 668 XP ARESSMB 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. -- Matthieu Patou Samba Teamhttp://samba.org Private repo http://git.samba.org/?p=mat/samba.git;a=summary ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] [REG:111051779565831] RE: dfs referral for sysvol and windows XP
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 339XP ARESDFSCDFSC:Get DFS Referral Request, FileName: \w2k8r2.home.matws.net\sysvol, MaxReferralLevel: 4 Packet 340 ARESXP DFSCDFSC: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 ARESDNS DNS:QueryId = 0xB8C8, QUERY (Standard query), Query for s2-w2k8r2.w2k8r2.home.matws.net Packet 346 ARESXP DNS DNS:QueryId = 0xB8C8, QUERY (Standard query), Response - Success, 172.16.100.27 Packet 442 ARESXP ICMPICMP: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 ARESICMPICMP:Echo Request Message, From 172.16.101.16 To 172.16.101.1 Packet 657 XP ARESKerberosV5 KerberosV5:TGS Request Realm: W2K8R2.HOME.MATWS.NET Sname: cifs/ares.w2k8r2.home.matws.net Packet 659 ARESXP KerberosV5 KerberosV5:TGS Response Cname: Administrator Packet 668 XP ARESSMB 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:m...@samba.org] Sent: Tuesday, May 31, 2011 4:44 PM To: Hongwei Sun Cc: p...@tridgell.net; cifs-proto...@samba.org; 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/201124.0070710 XP ARESDFSC DFSC:Get DFS Referral Request, FileName: \w2k8r2.home.matws.net\sysvol, MaxReferralLevel: 4 340 3:34:02 PM 5/17/201124.0145370 ARESXP DFSC DFSC:Get DFS Referral Response, NumberOfReferrals: 2 VersionNumber: 4 488 3:34:22 PM 5/17/201143.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/201143.8507430 ARESXP KerberosV5 KerberosV5
Re: [cifs-protocol] [REG:111051779565831] RE: 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/20110.000 172.16.101.16 172.16.101.1DFSC DFSC:Get DFS Referral Request, FileName:empty, MaxReferralLevel: 3 2 3:28:33 PM 5/17/20110.0001600 172.16.101.1172.16.101.16 DFSCDFSC:Get DFS Referral Response, NumberOfReferrals: 2 VersionNumber: 3 3 3:28:33 PM 5/17/20110.1360020 172.16.101.16 172.16.101.1 DFSCDFSC:Get DFS Referral Request, FileName: \w2k8r2.home.matws.net, MaxReferralLevel: 3 4 3:28:33 PM 5/17/20110.1434180 172.16.101.1172.16.101.16 DFSCDFSC:Get DFS Referral Response, NumberOfReferrals: 1 VersionNumber: 3 5 3:28:33 PM 5/17/20110.1440790 172.16.101.16 172.16.101.1 DFSCDFSC:Get DFS Referral Request, FileName: \w2k8r2.home.matws.net\sysvol, MaxReferralLevel: 4 6 3:28:33 PM 5/17/20110.1514540 172.16.101.1172.16.101.16 DFSCDFSC: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-boun...@cifs.org [mailto:cifs-protocol-boun...@cifs.org] On Behalf Of Matthieu Patou Sent: Tuesday, May 17, 2011 4:09 PM To: Interoperability Documentation Help; p...@tridgell.net; cifs-proto...@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 repo http://git.samba.org/?p=mat/samba.git;a=summary -- Matthieu Patou Samba Teamhttp://samba.org Private repo http://git.samba.org/?p=mat/samba.git;a=summary ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
