Hardening Samba as an AD DC: Difference between revisions

From SambaWiki
No edit summary
Line 3: Line 3:
==ldap server require strong auth==
==ldap server require strong auth==


This smb.conf option was introduced due to the attacks on LDAP known as NTLM forwarding or 'pass the hash' attacks. If ```ldap server require storong auth``` it set to ```no``` or ```allow_sasl_over_tls``` then the authentication to an SMB server by a privileged user or computer can be redirected to our LDAP server, allowing impersonation.
This smb.conf option was introduced due to the attacks on LDAP known as NTLM forwarding or 'pass the hash' attacks. If <code>ldap server require storong auth</code> it set to <code>no</code> or <code>allow_sasl_over_tls</code> then the authentication to an SMB server by a privileged user or computer can be redirected to our LDAP server, allowing impersonation.


See also [[Updating_Samba#New_Default_for_LDAP_Connections_Requires_Strong_Authentication|notes on this change]].
See also [[Updating_Samba#New_Default_for_LDAP_Connections_Requires_Strong_Authentication|notes on this change]].
Line 11: Line 11:
===Future possible hardening===
===Future possible hardening===


Microsoft has chosen a different path to addressing this issue, and instead would like AD clients to include a session-specific value in the NTLMv2 response, known a channel binding. Samba doesn't set this as a client nor does it check this as a server, at this time. A future Samba may add a new option here allowing NTLM and Kerberos connections over TLS, when this is sent and checked.
Microsoft has chosen a different path to addressing this issue, and instead would like AD clients to include a session-specific value in the NTLMv2 response, known a channel binding. Samba doesn't set this as a client nor does it check this as a server, at this time. A future Samba may add a new option here allowing NTLM and Kerberos connections over TLS, when this is sent and checked.


==ntlm auth==
==ntlm auth==

Revision as of 23:30, 31 May 2023

Samba smb.conf options to set/not set

ldap server require strong auth

This smb.conf option was introduced due to the attacks on LDAP known as NTLM forwarding or 'pass the hash' attacks. If ldap server require storong auth it set to no or allow_sasl_over_tls then the authentication to an SMB server by a privileged user or computer can be redirected to our LDAP server, allowing impersonation.

See also notes on this change.

It is more secure to use Kerberos with Kerberos encryption directly.

Future possible hardening

Microsoft has chosen a different path to addressing this issue, and instead would like AD clients to include a session-specific value in the NTLMv2 response, known a channel binding. Samba doesn't set this as a client nor does it check this as a server, at this time. A future Samba may add a new option here allowing NTLM and Kerberos connections over TLS, when this is sent and checked.

ntlm auth

NTLM authentication is 56-bit encryption at best and compromised badly for well-known word lists.

For a passive attacker, the options ```no``` and ```allow-mschapv2``` are at their core equally insecure, as they boil down to the same cryptography, but the latter option is permitted because MSCHAPv2 is harder to eliminate, is not presented on administrative interfaces and may be protected by a TLS tunnel.

Protected Users

[Samba_4.17_Features_added/changed#Protected_Users_security_group|Protected users], implemented in Samba 4.17 and later, are not permitted to use NTLM, are restricted from Kerberos delegations (were one server can act as the user to another) and have shorter ticket lifetimes. Windows clients also detect protected users and implement local protections for these accounts.