OK. I got all excited and ran the test against a 2008 DC this morning. After allowing NT4 crypto through group policy, it worked seamlessly.
Here's what I saw through wireshark: 1. same old failed extended security negotiation .. 2. Win7 sends DC TGS-REQ for cifs/nt4test 3. DC replies KRB-ERROR: KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN Just for grins, I then added HOST entries for the NT4 box in AD and tested again. The result was exactly the same as with the Samba DC, Windows issued a ticket and Win7 rejected the connection to the NT4 box. In summary, the evidence strongly points to CIFS being a mapped alias to the HOST SPN. If HOST exists, we can map it to CIFS, if it does not, we should tell the client that the principal does not exist. I will open a bug for this. On Tue, Jul 30, 2013 at 9:44 PM, Ryan Bair <[email protected]> wrote: > 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 <[email protected]> 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 <[email protected]>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
