[cifs-protocol] cifs/ SPN not accepted in certain scenarios
edgaro at microsoft.com
Fri Aug 28 16:19:18 MDT 2009
I will be investigating this case and will update you as soon as I have news.
Edgar A. Olougouna
Sr. SEE, Microsoft DSC Protocol Team
From: Zachary Loafman [mailto:zachary.loafman at isilon.com]
Sent: Friday, August 28, 2009 11:18 AM
To: Interoperability Documentation Help
Cc: pfif at tridgell.net; cifs-protocol at samba.org
Subject: cifs/ SPN not accepted in certain scenarios
We stumbled across a rather odd behavior related to non-forest-root tree-root domains. Can you help explain/document this behavior?
I've attached a short pcap showing the start of an XP machine joining a
2k8 tree-root. Here's the setup:
*) I have a Win2k8 DC at 10.54.139.240 for the zl.test domain, which is the forest root for this forest. This domain is only once contacted during the capture, but if you're setting up a similar environment, you'll need it.
*) I have another Win2k8 DC at 10.54.139.241 for the zl-alt.test domain (ZL-ALTROOT-TEST.zl-alt.test). This domain was configured as an alternate root within the same forest using the "advanced" settings in the dcpromo wizard (but is otherwise the standard configuration from that wizard).
*) I have an XP client whose DNS is set to 10.54.139.241 prior to the join.
For whatever reason, the alternate root DC will not accept a TGS-REQ for cifs/ZL-ALTROOT-TEST.zl-alt.test. In this pcap, the XP join then falls back to NTLM. This is fine, but kind of dumb - there should be no need to fall back to NTLM.
The zl-alt.test DC *will* accept a TGS-REQ for HOST/ZL-ALTROOT-TEST.zl-alt.test. That's the curious part.
In case it helps, here's a setspn -L on the altroot:
C:\Users\Administrator>setspn -L ZL-ALTROOT-TEST Registered ServicePrincipalNames for CN=ZL-ALTROOT-TEST,OU=Domain
More information about the cifs-protocol