Hi Zachary, I have investigated this case and configured a similar environment as you described. In my testing environment the Windows XP client can successfully join the new Windows Server 2008 domain (new tree root domain in an existing forest) by using Kerberos authentication.
I suspect the Kerberos error KRB_ERROR - KDC_ERR_S_PRINCIPAL_UNKNOWN (7) that you experienced on the TGS request is due your environment. Since the Kerberos mechanism failed to obtain the ticket for the CIFS service, the fallback to NTLM mechanism is the correct processing with respect to SPNEGO as documented in [MS-SPNG] and [RFC4178]. In case this helps, I am providing this reference on Kerberos troubleshooting. Troubleshooting Kerberos Errors http://www.microsoft.com/downloads/details.aspx?familyid=7DFEB015-6043-47DB-8238-DC7AF89C93F1&displaylang=en The KDC_ERR_S_PRINCIPAL_UNKNOWN error could be associated with these Windows internal errors: STATUS_NO_TRUST_SAM_ACCOUNT STATUS_OBJECT_NAME_NOT_FOUND STATUS_KDC_UNABLE_TO_REFER If you need more in-depth support in troubleshooting and debugging this issue, we can work with you to establish a Windows support case to pursue this in more depth. As always, please let us know if you have any specific documentation issue and we will be happy to assist. Best regards, Edgar -----Original Message----- From: Zachary Loafman [mailto:[email protected]] Sent: Friday, August 28, 2009 11:18 AM To: Interoperability Documentation Help Cc: [email protected]; [email protected] 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 Controllers,DC=zl-alt,DC=test: ldap/ZL-ALTROOT-TEST.zl-alt.test/ForestDnsZones.zl.test Dfsr-12F9A27C-BF97-4787-9364-D31B6C55EB04/ZL-ALTROOT-TEST.zl-alt.test DNS/ZL-ALTROOT-TEST.zl-alt.test GC/ZL-ALTROOT-TEST.zl-alt.test/zl.test HOST/ZL-ALTROOT-TEST.zl-alt.test/ZLALTTEST HOST/ZL-ALTROOT-TEST HOST/ZL-ALTROOT-TEST.zl-alt.test HOST/ZL-ALTROOT-TEST.zl-alt.test/zl-alt.test E3514235-4B06-11D1-AB04-00C04FC2DCD2/57379a03-4669-4b74-811b-97e3fdced92 2/zl-alt.test ldap/57379a03-4669-4b74-811b-97e3fdced922._msdcs.zl.test ldap/ZL-ALTROOT-TEST.zl-alt.test/ZLALTTEST ldap/ZL-ALTROOT-TEST ldap/ZL-ALTROOT-TEST.zl-alt.test ldap/ZL-ALTROOT-TEST.zl-alt.test/zl-alt.test pcap attached. ...Zach
_______________________________________________ cifs-protocol mailing list [email protected] https://lists.samba.org/mailman/listinfo/cifs-protocol
