View source for Hardening Samba as an AD DC

=Other Guides=

The Samba Team values the effort put by others into documenting Samba, and so rather than duplicate that work, please do first see:
* [https://samba.tranquil.it/doc/en/samba_advanced_methods/samba_advanced_methods.html Tranquil IT's Advanced features of Samba Active Directory]

=Samba smb.conf options to set/not set=

While this is not a comprehensive list, the below options some of which are defaults often disabled, and others are stronger options off by default should be carefully checked to confirm that Samba's behaviour is as strict as is possible in your organisation.

==Audit Logging==

[[Setting_up_Audit_Logging|Samba's AD DC Audit logging]] is configured via the <code>log level</code> parameter, and should be configured and processed by a log analysis stem on a hardened installation.

==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 <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.

A hardened installation will retain the default value of <code>yes</code>

See also [[Updating_Samba#New_Default_for_LDAP_Connections_Requires_Strong_Authentication|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 <code>no</code> and <code>allow-mschapv2</code> 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.

A fully hardened installation should set this to <code>disabled</code>, to require Kerberos or simple-bind authentication only, as even NTLMv2 is quite poor security in 2023.

==lanman auth==

Samba 4.17 removed LanMan authentication, if you are running Samba 4.16 and earlier, ensure that <code>lanman auth</code> has the default setting of <code>no</code>

==allow store nt hash==

Related to the above, Samba 4.17 has an the <code>allow store nt hash</code> option, allowing Samba to avoid storing the NT hash.  Well known for being <strong>unsalted</strong> the NT hash is required for <code>NTLM</code>, <code>NTLMv2</code>, and <code>MSCHAPv2</code> authentication, as well as for <code>arcfour-hmac-md5</code> Kerberos authentication.  However in 2023 all of these authentication mechanisms are considered as weak, and should not be used on hardened networks. 

The purpose of this option is to allow Samba to not store the NT hash that will not be used, as it presents a vulnerability if the DB is exposed.  

A hardened installation will set the value <code>never</code>, which avoids this storage.

==server min protocol, client min protocol, client ipc min protocol==

Modern Samba versions default to SMB2 and above.  A hardened Samba installation should not set <code>server min protocol</code> <code>client min protocol</code> or <code>client ipc min protocol</code> to values such as <code>NT1</code>, which enable the old SMB1 support.

Avoiding SMB1 avoids support for NTLMv2 without NTLMSSP, which is not as secure as NTLMv2 as used within NTLMSSP - eg as used in SMB2, as well as a significant body of older C code in Samba.  The SMB message signing (integrity protection) protocols are also much better in SMB2.

==smb1 unix extensions, unix extensions==

This is only relevant if SMB1 is enabled.

The SMB1 unix extensions allow the creation of a server-side symlink to a user-chosen location, and significant work had to be done to avoid Samba following such a link.  While this work is now complete, it is still better to never allow the creation of such symbolic links. 

A hardened installation will retain the default of <code>no</code>.

==NETLOGON Secure channel options==

The default values of these options should not be changed:
<code>allow nt4 crypto = no</code>,
<code>reject md5 clients = yes</code>,
<code>server schannel require seal = yes</code>,
<code>server schannel = yes</code>

If specific client hosts need to use outdated NETLOGON cryptography, then see the smb.conf documentation for the per-host overrides that are permitted.

==GnuTLS TLS option configuration==

Samba can feed the GnuTLS cryptography provider an option string to describe the TLS protocols that should be supported and not supported.  See [https://gnutls.org/manual/html_node/Priority-Strings.html|The GnuTLS manual] for valid strings.  The <code>tls priority</code> option is is useful to disable a newly-vulnerable TLS protocol.  The default in Samba (and in modern GnuTLS) is set to ensure that SSLv3 is disabled. 

==Enforce stronger password quality (not upper/lower/special chars)==

A hardened installation of Samba will set <code>check password script</code> to a secure script or binary that checks the most common cracked passwords as well as dictionary words.  Samba provides an example <code>crackcheck</code> binary, but cracklib which it uses has been superseded [https://github.com/sfonteneau/haveibeenpwnd_for_check_password_script_samba by tools checking large breach databases].

==Insecure DNS updates==

Samba can be configured to allow un-authenticated clients to update Dynamic DNS records.  The default value for <code>allow dns updates</code> is <code>secure only</code> and this should be kept.

=Samba Host hardening=
These are things to do, on the Samba host, to improve security of Samba and your AD Domain. 

The Samba Team does not maintain these hardening methods, but does recommend using (eg) packages with them prepared and tested.

==Apparmor==
Samba as packaged for some distributions (SuSE has been observed) has an extensive AppArmor rule set to restrict Samba only to the parts of the filesystem that it requires access to.  This should not be disabled.

==SELinux==
Samba as packaged on Fedora and RHEL has SELinux rules set to likewise restrict Samba only to the parts of the filesystem that it requires access to.  This should not be disabled.

==TLS Configuration (LDAP over TLS, ldaps://, StartTLS)==

Samba will autogenerate a TLS certificate for the LDAP service.  This should be replaced with a properly signed certificate trusted and verified by the clients in your organisation.  

The options <code>tls cafile</code>,<code>tls certfile</code>,<code>tls crlfile</code>,<code>tls dh params file</code>,<code>tls keyfile</code> control the location of these files. 

Currently Samba will need to be restarted when these files are updated.

=Encryption at rest for the Samba AD DC=
Samba's AD DC supports encryption at rest of passwords and other secret values (for a fixed list of attributes).

To use this feature to the full advantage, two hardening steps and then key management are required.

==Never set <code>--plaintext-secrets</code> in <code>samba-tool domain provision</code> or <code>samba-tool domain join</code>==

By default encryption at rest is enabled.  Even without key management (below) this avoids a number of in-memory attacks on our database by separating the key from the encrypted data. 

==Ensure Samba's AD DC sam.ldb was created after Samba 4.8==

A Samba AD DC database that was continuously updated in-place from an earlier Samba version will not gain the encrypted secret feature, it will continue to read and write plaintext secrets into the sam.ldb file.

A new AD DC running a modern Samba version should be joined to the domain, and the DC that was historically pre-Samba 4.8 DC should be demoted. 

==Arrange offline storage of the <code>encrypted_secrets.key</code>==
Samba does not attempt key management of the <code>private/encrypted_secrets.key</code> file.

A hardened AD DC could arrange to have this file be supplied to Samba - say on a ramdisk after obtaining the key from a key vault - at startup. 

Note that this would still be a partial solution, there are other secret files in <code>private/</code> that could be managed, but no specific engineering has been done for <code>secrets.keytab</code> and host passwords in <code>secrets.tdb</code> and <code>secrets.ldb</code>

=Samba compilation hardening=
Samba's build system and that of many Samba packages harden Samba against some attacks on the C codebase.

See [[Samba_Security_Documentation#Hardening_practices|Samba compiler hardening]] for details.

=AD DC configuration options to consider=

==LDAP Max Query Duration==

Samba honours the [https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/3f0137a1-63df-400c-bf97-e1040f055a99 lDAPAdminLimits MaxQueryDuration] however the default is 120 seconds.  This is a very high value and the worker processing this query will not process other requests in this time.  Consider lowering the value.  Queries over 25% the maximum time will be logged at log level <code>3</code>.

==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.

==Password Policies==

Samba supports domain-wide and Fine-Grained Password Policies / Password Setting Objects (PSOs).  

The domain-wide policies can be set via GPO if <code>apply group policies = yes</code> is set, but the direct method is to update the values in LDAP or via <code>samba-tool domain passwordsettings</code>.

To configure fine-grained password policies, use <code>samba-tool domain passwordsettings pso</code> per [https://samba.tranquil.it/doc/en/samba_advanced_methods/samba_password_policies.html Tranquil IT's Applying a password strategy with Samba-AD guide]

The default values in Samba are
<pre>Password complexity: on
Store plaintext passwords: off
Password history length: 24
Minimum password length: 7
Minimum password age (days): 1
Maximum password age (days): 42
Account lockout duration (mins): 30
Account lockout threshold (attempts): 0
Reset account lockout after (mins): 30
</pre>

These values match Windows, but should be strengthened in a hardened domain.  A hardened domain should have a password lockout set (by changing the threashold from 0) and should have a much longer minimum password length.