Re: [Samba] NT4 clients
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 ryandb...@gmail.com 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 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.orgwrote: 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,
Re: [Samba] NT4 clients
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: http://msdn.microsoft.com/en-us/library/d367854f-5eee-45e8-a588-eed596a1a521#endNote94When the server completes negotiation and returns the CAP_EXTENDED_SECURITY flag as not set, Windows-based SMB clients query the Key Distribution Center (KDC)http://msdn.microsoft.com/en-us/library/0aa17e1f-b3c1-478a-9bf0-2d826888d081#key_distribution_center_KDCto verify whether a service ticket is registered for the given security principal name (SPN)http://msdn.microsoft.com/en-us/library/54af12e1-fcc1-4d62-bd47-c80514ac2615#spn. If the query indicates that the SPNhttp://msdn.microsoft.com/en-us/library/54af12e1-fcc1-4d62-bd47-c80514ac2615#spnis registered with the KDChttp://msdn.microsoft.com/en-us/library/0aa17e1f-b3c1-478a-9bf0-2d826888d081#key_distribution_center_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. 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. On Jul 30, 2013 1:07 AM, Andrew Bartlett abart...@samba.org wrote: On Mon, 2013-07-29 at 19:29 -0400, Ryan Bair wrote: Yes, AD has explicit support for pre-2000 clients. WINS is alive and well and name resolution is working. I really think the bogus TGS reply is messing things up, but I'd like to have someone more knowledgeable confirm the behavior is incorrect. NT4 doesn't know about Kerberos, I think any TGS traffic is highly likely a red herring. Are you really sure the client is issuing it, and you have not additional software installed on the NT4 machine? 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
Re: [Samba] NT4 clients
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
Re: [Samba] NT4 clients
For what it is worth - it looks like NT4 does NOT use kerberos even with the Active Directory client installed. http://www.petri.co.il/dsclient_for_win98_nt.htm# Windows 2003 Active Directory had some compatibility with NT4 domain controllers. I don't think Samba 4 does.Your best bet may be to try putting the NT4 machine in a separate NT4/Samba 3 domain and establishing trusts. Or more realistically take it OUT of the domain and just create local user accounts with same passwords as the network accounts. The only legit reason I could see to be running NT4 is if it is managing a specialized piece of equipment (e.g. on a manufacturing floor.)In that case the machine(s) should be airgapped from any regular network with internet access. If you follow security news you can imagine why it is important to keep unpatched systems physically isolated from the internet or other networks. On 07/30/13 05:33, 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: http://msdn.microsoft.com/en-us/library/d367854f-5eee-45e8-a588-eed596a1a521#endNote94When the server completes negotiation and returns the CAP_EXTENDED_SECURITY flag as not set, Windows-based SMB clients query the Key Distribution Center (KDC) http://msdn.microsoft.com/en-us/library/0aa17e1f-b3c1-478a-9bf0-2d826888d081#key_distribution_center_KDC to verify whether a service ticket is registered for the given security principal name (SPN) http://msdn.microsoft.com/en-us/library/54af12e1-fcc1-4d62-bd47-c80514ac2615#spn. If the query indicates that the SPN http://msdn.microsoft.com/en-us/library/54af12e1-fcc1-4d62-bd47-c80514ac2615#spn is registered with the KDC http://msdn.microsoft.com/en-us/library/0aa17e1f-b3c1-478a-9bf0-2d826888d081#key_distribution_center_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. 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. On Jul 30, 2013 1:07 AM, Andrew Bartlett abart...@samba.org mailto:abart...@samba.org wrote: On Mon, 2013-07-29 at 19:29 -0400, Ryan Bair wrote: Yes, AD has explicit support for pre-2000 clients. WINS is alive and well and name resolution is working. I really think the bogus TGS reply is messing things up, but I'd like to have someone more knowledgeable confirm the behavior is incorrect. NT4 doesn't know about Kerberos, I think any TGS traffic is highly likely a red herring. Are you really sure the client is issuing it, and you have not additional software installed on the NT4 machine? Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ http://samba.org/%7Eabartlet/ 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
Re: [Samba] NT4 clients
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
Re: [Samba] NT4 clients
Understood. The machine I'm trying to connect is just a member, not a DC. This is something which was well supported in earlier versions of Windows with AD (NT4 didn't die overnight), and reportedly still works in 2012. I'm not expecting any Kerberos to come out of NT4, nor do I see any. The issue is that the Samba DC is fulfilling a TGS request when it really should not. I spelled this out in a bit more detail a few messages back. Thank you for pointing out the security issues. I'm well aware of the issues with having an OS so old hanging around. The machine is involved in ultimately driving a piece of equipment, but the set up requires several other clients to have access via named pipe and SMB share. It's presently isolated as best it can be given all the constraints. It's far from ideal on several fronts, but the solution has been extremely reliable for a long time and we realistically have at least 12 months until replacing the solution is feasible. On Tue, Jul 30, 2013 at 6:12 PM, Gaiseric Vandal gaiseric.van...@gmail.comwrote: For what it is worth - it looks like NT4 does NOT use kerberos even with the Active Directory client installed. http://www.petri.co.il/dsclient_for_win98_nt.htm# Windows 2003 Active Directory had some compatibility with NT4 domain controllers. I don't think Samba 4 does.Your best bet may be to try putting the NT4 machine in a separate NT4/Samba 3 domain and establishing trusts. Or more realistically take it OUT of the domain and just create local user accounts with same passwords as the network accounts. The only legit reason I could see to be running NT4 is if it is managing a specialized piece of equipment (e.g. on a manufacturing floor.)In that case the machine(s) should be airgapped from any regular network with internet access. If you follow security news you can imagine why it is important to keep unpatched systems physically isolated from the internet or other networks. On 07/30/13 05:33, 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.aspxstate: 94 Section 3.2.5.2: http://msdn.microsoft.com/en-us/library/d367854f-5eee-45e8-a588-eed596a1a521#endNote94When the server completes negotiation and returns the CAP_EXTENDED_SECURITY flag as not set, Windows-based SMB clients query the Key Distribution Center (KDC)http://msdn.microsoft.com/en-us/library/0aa17e1f-b3c1-478a-9bf0-2d826888d081#key_distribution_center_KDCto verify whether a service ticket is registered for the given security principal name (SPN)http://msdn.microsoft.com/en-us/library/54af12e1-fcc1-4d62-bd47-c80514ac2615#spn. If the query indicates that the SPNhttp://msdn.microsoft.com/en-us/library/54af12e1-fcc1-4d62-bd47-c80514ac2615#spnis registered with the KDChttp://msdn.microsoft.com/en-us/library/0aa17e1f-b3c1-478a-9bf0-2d826888d081#key_distribution_center_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. 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. On Jul 30, 2013 1:07 AM, Andrew Bartlett abart...@samba.org wrote: On Mon, 2013-07-29 at 19:29 -0400, Ryan Bair wrote: Yes, AD has explicit support for pre-2000 clients. WINS is alive and well and name resolution is working. I really think the bogus TGS reply is messing things up, but I'd like to have someone more knowledgeable confirm the behavior is incorrect. NT4 doesn't know about Kerberos, I think any TGS traffic is highly likely a red herring. Are you really sure the client is issuing it, and you have not additional software installed on the NT4 machine? Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Catalyst IT
Re: [Samba] NT4 clients
On Tue, 2013-07-30 at 21:25 -0400, Ryan Bair wrote: Understood. The machine I'm trying to connect is just a member, not a DC. This is something which was well supported in earlier versions of Windows with AD (NT4 didn't die overnight), and reportedly still works in 2012. I'm not expecting any Kerberos to come out of NT4, nor do I see any. The issue is that the Samba DC is fulfilling a TGS request when it really should not. I spelled this out in a bit more detail a few messages back. What I need you to do is show how this is different with Windows 2008, rather than Samba 4.0 as an AD DC. Then I might be able to assist, otherwise, the only 'buggy' part of this would seem to be the new security behavior of Windows 7, which you may be able to disable. 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
Re: [Samba] NT4 clients
Sorry Andrew, that message was intended towards Gaiseric's comment. I will try to get you a trace against Windows 2008, but it may take me a while to get a test environment set up for that. I've also noticed that this happens as far back as Windows 2000 clients, so not isolated to Win7. On Tue, Jul 30, 2013 at 9:31 PM, Andrew Bartlett abart...@samba.org wrote: On Tue, 2013-07-30 at 21:25 -0400, Ryan Bair wrote: Understood. The machine I'm trying to connect is just a member, not a DC. This is something which was well supported in earlier versions of Windows with AD (NT4 didn't die overnight), and reportedly still works in 2012. I'm not expecting any Kerberos to come out of NT4, nor do I see any. The issue is that the Samba DC is fulfilling a TGS request when it really should not. I spelled this out in a bit more detail a few messages back. What I need you to do is show how this is different with Windows 2008, rather than Samba 4.0 as an AD DC. Then I might be able to assist, otherwise, the only 'buggy' part of this would seem to be the new security behavior of Windows 7, which you may be able to disable. 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
Re: [Samba] NT4 clients
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.orgwrote: 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
[Samba] NT4 clients
I'm attempting to get an old NT4 client participating in a Samba4 domain. Users can logon to the machine locally and access network shares on other machines in the network. However, no one can access shares on the NT4 machine using the machine name. Attempting this results in an error The account is not authorized to log in from this station. Using the IP address does work however. The clients are configured to allow no smb signing and NTLMv1, I think I have all the security settings covered. I noticed while looking at wireshark though that the client is doing TGS-REQ for cifs/nt4test and Samba is returning a full TGS-REP. This feels very odd to me since there is no such SPN cifs/nt4test on the network. 'setspn -Q cifs/nt4test' confirms this. I've also noticed that the MS docs state: 94 Section 3.2.5.2: http://msdn.microsoft.com/en-us/library/d367854f-5eee-45e8-a588-eed596a1a521#endNote94When the server completes negotiation and returns the CAP_EXTENDED_SECURITY flag as not set, Windows-based SMB clients query the Key Distribution Center (KDC)http://msdn.microsoft.com/en-us/library/0aa17e1f-b3c1-478a-9bf0-2d826888d081#key_distribution_center_KDCto verify whether a service ticket is registered for the given security principal name (SPN)http://msdn.microsoft.com/en-us/library/54af12e1-fcc1-4d62-bd47-c80514ac2615#spn. If the query indicates that the SPNhttp://msdn.microsoft.com/en-us/library/54af12e1-fcc1-4d62-bd47-c80514ac2615#spnis registered with the KDChttp://msdn.microsoft.com/en-us/library/0aa17e1f-b3c1-478a-9bf0-2d826888d081#key_distribution_center_KDC, then the SMB client terminates the connection and returns an implementation-specific security downgrade error to the caller. The client does have CAP_EXTENDED_SECURITY set and I'm guessing the TGS-REQ is how Windows is testing the presence of the SPN. Since the test is succeeding and the server doesn't advertise the extended security capability, Windows disconnects. Can someone confirm my hypothesis? -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] NT4 clients
Oh, forgot to mention. Samba 4.0.7-4 Sernet packages running on CentOS 6.4. On Mon, Jul 29, 2013 at 5:00 PM, Ryan Bair ryandb...@gmail.com wrote: I'm attempting to get an old NT4 client participating in a Samba4 domain. Users can logon to the machine locally and access network shares on other machines in the network. However, no one can access shares on the NT4 machine using the machine name. Attempting this results in an error The account is not authorized to log in from this station. Using the IP address does work however. The clients are configured to allow no smb signing and NTLMv1, I think I have all the security settings covered. I noticed while looking at wireshark though that the client is doing TGS-REQ for cifs/nt4test and Samba is returning a full TGS-REP. This feels very odd to me since there is no such SPN cifs/nt4test on the network. 'setspn -Q cifs/nt4test' confirms this. I've also noticed that the MS docs state: 94 Section 3.2.5.2: http://msdn.microsoft.com/en-us/library/d367854f-5eee-45e8-a588-eed596a1a521#endNote94When the server completes negotiation and returns the CAP_EXTENDED_SECURITY flag as not set, Windows-based SMB clients query the Key Distribution Center (KDC)http://msdn.microsoft.com/en-us/library/0aa17e1f-b3c1-478a-9bf0-2d826888d081#key_distribution_center_KDCto verify whether a service ticket is registered for the given security principal name (SPN)http://msdn.microsoft.com/en-us/library/54af12e1-fcc1-4d62-bd47-c80514ac2615#spn. If the query indicates that the SPNhttp://msdn.microsoft.com/en-us/library/54af12e1-fcc1-4d62-bd47-c80514ac2615#spnis registered with the KDChttp://msdn.microsoft.com/en-us/library/0aa17e1f-b3c1-478a-9bf0-2d826888d081#key_distribution_center_KDC, then the SMB client terminates the connection and returns an implementation-specific security downgrade error to the caller. The client does have CAP_EXTENDED_SECURITY set and I'm guessing the TGS-REQ is how Windows is testing the presence of the SPN. Since the test is succeeding and the server doesn't advertise the extended security capability, Windows disconnects. Can someone confirm my hypothesis? -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] NT4 clients
I wouldn't have even guessed that NT4 would join a modern AD domain. It looks like MS did provide client software to join a Windows 2000 AD domain.Or does the NT4 machine think it is in an NT4 / Samba3 type domain? Presumably you can see the domain users in the local user manager program on the NT4 machine? And verify the security options. http://www.windowsnetworking.com/articles-tutorials/windows-nt/nt4user.html Do you have a a WINS server running? With XP/Windows 7 when you join an AD domain, the machine name usually gets set to a fully qualified domain name. e.g. mypc.mydomain.com. Does the host name of the NT4 machine match the expected AD fully qualified domain name (does nslookup ip_address on the NT4 machine return the expected hostname? ) Are all machines in DNS? I think a hostname or dns mismatch could cause problems validating AD kerberos tickets. I am running Samba 3, not 4, but found that using a WINS server and making sure key systems were in DNS helped solve some issues. On 07/29/13 17:05, Ryan Bair wrote: Oh, forgot to mention. Samba 4.0.7-4 Sernet packages running on CentOS 6.4. On Mon, Jul 29, 2013 at 5:00 PM, Ryan Bair ryandb...@gmail.com wrote: I'm attempting to get an old NT4 client participating in a Samba4 domain. Users can logon to the machine locally and access network shares on other machines in the network. However, no one can access shares on the NT4 machine using the machine name. Attempting this results in an error The account is not authorized to log in from this station. Using the IP address does work however. The clients are configured to allow no smb signing and NTLMv1, I think I have all the security settings covered. I noticed while looking at wireshark though that the client is doing TGS-REQ for cifs/nt4test and Samba is returning a full TGS-REP. This feels very odd to me since there is no such SPN cifs/nt4test on the network. 'setspn -Q cifs/nt4test' confirms this. I've also noticed that the MS docs state: 94 Section 3.2.5.2: http://msdn.microsoft.com/en-us/library/d367854f-5eee-45e8-a588-eed596a1a521#endNote94When the server completes negotiation and returns the CAP_EXTENDED_SECURITY flag as not set, Windows-based SMB clients query the Key Distribution Center (KDC)http://msdn.microsoft.com/en-us/library/0aa17e1f-b3c1-478a-9bf0-2d826888d081#key_distribution_center_KDCto verify whether a service ticket is registered for the given security principal name (SPN)http://msdn.microsoft.com/en-us/library/54af12e1-fcc1-4d62-bd47-c80514ac2615#spn. If the query indicates that the SPNhttp://msdn.microsoft.com/en-us/library/54af12e1-fcc1-4d62-bd47-c80514ac2615#spnis registered with the KDChttp://msdn.microsoft.com/en-us/library/0aa17e1f-b3c1-478a-9bf0-2d826888d081#key_distribution_center_KDC, then the SMB client terminates the connection and returns an implementation-specific security downgrade error to the caller. The client does have CAP_EXTENDED_SECURITY set and I'm guessing the TGS-REQ is how Windows is testing the presence of the SPN. Since the test is succeeding and the server doesn't advertise the extended security capability, Windows disconnects. Can someone confirm my hypothesis? -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] NT4 clients
Yes, AD has explicit support for pre-2000 clients. WINS is alive and well and name resolution is working. I really think the bogus TGS reply is messing things up, but I'd like to have someone more knowledgeable confirm the behavior is incorrect. On Mon, Jul 29, 2013 at 5:23 PM, Gaiseric Vandal gaiseric.van...@gmail.comwrote: I wouldn't have even guessed that NT4 would join a modern AD domain. It looks like MS did provide client software to join a Windows 2000 AD domain. Or does the NT4 machine think it is in an NT4 / Samba3 type domain? Presumably you can see the domain users in the local user manager program on the NT4 machine? And verify the security options. http://www.windowsnetworking.**com/articles-tutorials/** windows-nt/nt4user.htmlhttp://www.windowsnetworking.com/articles-tutorials/windows-nt/nt4user.html Do you have a a WINS server running? With XP/Windows 7 when you join an AD domain, the machine name usually gets set to a fully qualified domain name. e.g. mypc.mydomain.com. Does the host name of the NT4 machine match the expected AD fully qualified domain name (does nslookup ip_address on the NT4 machine return the expected hostname? ) Are all machines in DNS? I think a hostname or dns mismatch could cause problems validating AD kerberos tickets. I am running Samba 3, not 4, but found that using a WINS server and making sure key systems were in DNS helped solve some issues. On 07/29/13 17:05, Ryan Bair wrote: Oh, forgot to mention. Samba 4.0.7-4 Sernet packages running on CentOS 6.4. On Mon, Jul 29, 2013 at 5:00 PM, Ryan Bair ryandb...@gmail.com wrote: I'm attempting to get an old NT4 client participating in a Samba4 domain. Users can logon to the machine locally and access network shares on other machines in the network. However, no one can access shares on the NT4 machine using the machine name. Attempting this results in an error The account is not authorized to log in from this station. Using the IP address does work however. The clients are configured to allow no smb signing and NTLMv1, I think I have all the security settings covered. I noticed while looking at wireshark though that the client is doing TGS-REQ for cifs/nt4test and Samba is returning a full TGS-REP. This feels very odd to me since there is no such SPN cifs/nt4test on the network. 'setspn -Q cifs/nt4test' confirms this. I've also noticed that the MS docs state: 94 Section 3.2.5.2: http://msdn.microsoft.com/en-**us/library/d367854f-5eee-45e8-** a588-eed596a1a521#endNote94http://msdn.microsoft.com/en-us/library/d367854f-5eee-45e8-a588-eed596a1a521#endNote94 **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)http://msdn.microsoft.**com/en-us/library/0aa17e1f-** b3c1-478a-9bf0-2d826888d081#**key_distribution_center_KDChttp://msdn.microsoft.com/en-us/library/0aa17e1f-b3c1-478a-9bf0-2d826888d081#key_distribution_center_KDCto verify whether a service ticket is registered for the given security principal name (SPN)http://msdn.microsoft.**com/en-us/library/54af12e1- **fcc1-4d62-bd47-c80514ac2615#**spnhttp://msdn.microsoft.com/en-us/library/54af12e1-fcc1-4d62-bd47-c80514ac2615#spn . If the query indicates that the SPNhttp://msdn.microsoft.com/** en-us/library/54af12e1-fcc1-**4d62-bd47-c80514ac2615#spnhttp://msdn.microsoft.com/en-us/library/54af12e1-fcc1-4d62-bd47-c80514ac2615#spnis registered with the KDChttp://msdn.microsoft.com/**en-us/library/0aa17e1f-b3c1-** 478a-9bf0-2d826888d081#key_**distribution_center_KDChttp://msdn.microsoft.com/en-us/library/0aa17e1f-b3c1-478a-9bf0-2d826888d081#key_distribution_center_KDC , then the SMB client terminates the connection and returns an implementation-specific security downgrade error to the caller. The client does have CAP_EXTENDED_SECURITY set and I'm guessing the TGS-REQ is how Windows is testing the presence of the SPN. Since the test is succeeding and the server doesn't advertise the extended security capability, Windows disconnects. Can someone confirm my hypothesis? -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/**mailman/options/sambahttps://lists.samba.org/mailman/options/samba -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] NT4 clients
On Mon, 2013-07-29 at 19:29 -0400, Ryan Bair wrote: Yes, AD has explicit support for pre-2000 clients. WINS is alive and well and name resolution is working. I really think the bogus TGS reply is messing things up, but I'd like to have someone more knowledgeable confirm the behavior is incorrect. NT4 doesn't know about Kerberos, I think any TGS traffic is highly likely a red herring. Are you really sure the client is issuing it, and you have not additional software installed on the NT4 machine? 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
