Last bit of info. This article, http://support.microsoft.com/kb/258503, indicates that Windows should indeed be setting up its own default SPNs (host and machine name).
http://support.microsoft.com/kb/320187 states that the pre-Windows 2000 checkbox is ADUC assigns the machine password based on the machine name. I haven't found any information indicating that it does anything more than this. I'll try to confirm the behavior against a Win2008 DC this week, but right now I'm leaning towards the CIFS SPN being dependent upon a HOST SPN being present. On Tue, Jul 30, 2013 at 8:58 PM, Ryan Bair <ryandb...@gmail.com> wrote: > I've noticed that Win2k+ clients have filled in their servicePrincipalName > attribute in AD. I know that the cifs SPN is implicit, but are you certain > the host SPN is also implicit? If cifs was only meant to be implicit off of > the host (and the host not implicit itself), that could be a way to > determine if the request should be fulfilled. > > I have not tried against a Windows DC. I may set up a test DC to see what > the behavior is. > > Connecting by IP address does work. I'll try using an alternative name, > that sounds promising as well. > > In ADUC, there is a checkbox for pre-Windows 2000 when creating a new > machine account. I wonder what this does and if we could use it somehow. I > know it's not stored anywhere directly, but I'd suspect its there for a > reason. > > > On Tue, Jul 30, 2013 at 6:02 PM, Andrew Bartlett <abart...@samba.org>wrote: > >> On Tue, 2013-07-30 at 05:33 -0400, Ryan Bair wrote: >> > Hi Andrew, >> > >> > >> > To clarify, it is the Win7 client sending the TGS request to the DC >> > and the DC responds positively. I now have a more complete >> > understanding of what's going on: >> > >> > >> > 1. Win7 initiates a session with NT4. Nothing interesting. >> > >> > 2. Win7 sends the negotiate protocol response. Of note, we state that >> > we support extended security. >> > >> > 3. NT4 responds that it does not support extended security. More >> > precisely, when NT4 dinosaurs roamed the earth, that bit was likely >> > still reserved. >> > >> > 4. Win7 issues a TGS request to the _DC_ to see if the host with that >> > name really doesn't support extended security, or if the NT4 machine >> > is trying to subject it to some sort of elaborate ruse. (i) >> > >> > 5. DC responds positively to the TGS req. (!!!) >> > >> > 6. Win7 closes the connection, and displays the error to the user. >> > >> > >> > i. The notes on http://msdn.microsoft.com/en-us/library/cc246806.aspx >> > state: >> > <94> Section 3.2.5.2: When the server completes negotiation and >> > returns the CAP_EXTENDED_SECURITY flag as not set, Windows-based SMB >> > clients query the Key Distribution Center (KDC) to verify whether a >> > service ticket is registered for the given security principal name >> > (SPN). If the query indicates that the SPN is registered with the KDC, >> > then the SMB client terminates the connection and returns an >> > implementation-specific security downgrade error to the caller. >> > >> > >> > Since the Samba DC replies that the SPN is available (by fulfilling >> > the request), I'm assuming we're triggering this documented behavior >> > in the Win7 client. >> >> Indeed. >> >> > Also of note, `klist` on the client has an entry for cifs/nt4test >> > which `setspn -Q cifs/nt4test` confirms does not exist. I can't >> > confirm the behavior in #5 is a bug, but it certainly seems suspect. >> >> The cifs/nt4test SPN is implicit, from the implicit host/nt4test SPN >> that comes from nt4test being the machine's name. >> >> The issue for us as a KDC is that there is no flag that I know of that >> can be set to say that this domain member should not be issued a ticket, >> and the downgrade protection is an important part of the security of the >> network. (that protection isn't useful if the member server can still >> negotiate for only NTLM without protection, but waiting for that is for >> another day). >> >> Have you tested and shows windows behaves any differently? >> >> Finally, as a workaround try connecting to the machine by IP or by a >> name the KDC doesn't know. >> >> Andrew Bartlett >> >> >> -- >> Andrew Bartlett >> http://samba.org/~abartlet/ >> Authentication Developer, Samba Team http://samba.org >> Samba Developer, Catalyst IT http://catalyst.net.nz >> >> >> > -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba