Samba deprecates rc4-hmac cipher for Kerberos session keys

Security advice

Following Microsofts November updates the Samba team deprecated the “rc4-hmac” cipher for Kerberos session keys and released entirely new versions of Samba. Univention will release the new Samba version 4.16.8 as an errata update for UCS 5.0-2. Since backporting the required code changes to UCS 4.4 is prohibitively complex, we communicate the security advice from the Samba team and translated it into the specific context of UCS systems.

The official upstream advisories are here for reference:

In AD-Member configuration, the UCS server will use the Micosoft AD KDC instead, for which Microsoft has issued updates addressing the issues. This means most of the steps below are not relevant for UCS domains that run in AD-member configuration, joined to a native Microsoft AD domain. Please consider the recommendation for CVE-2022-38023 below though.

Clarification

The topic here is the “Session Key” and not the “Ticket Key”. For each TGS-REQ, the Session Key is chosen by the KDC and the KDC decides based on several factors, amongst them if the account of the target service has the attribute msDS-SupportedEncryptionTypes set and what that specifies. If that is not set, or set to “0”, then a default of the Samba software applies. Before the update it war “rc4-hmac” and after the update to version 4.16.8 (published as errata update for UCS 5.0-2) the default becomes “rc4-hmac, aes256-cts-hmac-sha1-96-sk”. The value aes256-cts-hmac-sha1-96-sk instructs the server to choose one of the AES ciphers for use as Session Key, even when aes256-cts-hmac-sha1-96 or aes128-cts-hmac-sha1-96 is not set for the respective service account, i.e. also in cases where the Ticket Key (i.e. the Kerberos password hash) has been of lower strength.

Workaround and long-term fixes

Check domain function level

This first point is just a general recommendation: Domains that still have Active Directory Domain Function Level prior to 2008R2 should perform the steps required to raise the function level, as described in How-to: Raise Domain Functional Level . While this step doesn’t seem to be strictly required from what the upstream advisories say, it is highly recommended to do this in order to not run into trouble when the next raise of minimum acceptable security standard will happen in Samba/AD. This step is a prerequisite to make Samba/AD to calculate AES keys the next time when users (or machines) change their password. This will only happen gradually one account password change at a time.

The function level can be checked by running the command samba-tool domain level show on a system with the UCS app “samba4” installed. To check where “samba4” (aka Samba/AD) is installed see output of univention-app info or run univention-ldapsearch -LLL univentionService="Samba 4" 1.1.

Check for service accounts that have been configured to explicitly prohibit the use of AES for Session Keys

This second point directly addresses the issue of the Kerberos Session Keys. Following this is recommended for all UCS Samba/AD domains:

For each account in Samba/AD with a servicePrincipalName attribute, the supported encryption types should be checked for cases, where AES ciphers are are explicitly disabled. These accounts can be found by running this command on a UCS Samba/AD DC:

univention-s4search '(&(servicePrincipalName=*)(&(msDS-SupportedEncryptionTypes=*)(!(msDS-SupportedEncryptionTypes=0))(!(msDS-SupportedEncryptionTypes:1.2.840.113556.1.4.804:=0x18))))' 1.1

In UCS@school setups this should preferably be run on the UCS@school Primary Directory Node. In case there is not samba4 installed on the UCS Primary Directory Node, this command should be run on all UCS@school site servers.

Without any adjustment all of the Kerberos based services (CIFS etc.) that use these accounts will not be reachable by clients any longer after the update to Samba 4.16.8. At least one additional bit needs to be set in this attribute for these accounts.

For the accounts identified with the above command you can adjust the msDS-SupportedEncryptionTypes one by one, to allow the usage of AES ciphers for the Session Key when communicating with them. This can be done by adjusting the attribute in a way that has at least the 6th bit set (corresponding to a value of 32 in base 10 notation and 0x20 in hex) as well as the 3rd bit (corresponding to a value of 4). This combination of bits corresponds to the new Samba default “rc4-hmac, aes256-cts-hmac-sha1-96-sk”. This is a bit confusing (and required so clarification by Microsoft too), but for technical (code flow) reasons the “rc4-hmac” bit needs to be enabled here still.

This change of the attribute msDS-SupportedEncryptionTypes can also be done using Microsofts native “Active Directory Users and Computers” GUI application.

Check for service accounts that could use AES for Ticket Keys, but are prohibited to

This third point is more of a general recommendation for all UCS Samba/AD domains to avoid lower security standards than technically possible:

In UCS Samba/AD Kerberos service principals are usually connected to the machine accounts of each Samba/AD DC and additionally there are the service accounts named “dns-" and "http-proxy-” (for each DC, where univention-bind9 and/or univention-squid-kerberos are installed). All of these Kerberos service accounts have Keytab files stored in the file system. They should be checked for the presence of AES keys too:

for keytab in /etc/krb5.keytab /var/lib/samba/private/dns.keytab /var/lib/samba/private/http-proxy.keytab;
do
ktutil -k "$keytab" list | grep aes
done

If the keytab files you inspected contained AES Keys, then it should be ok to go one step further and also check that the corresponding AES ciphers are enabled for usage as Ticket Keys too. This can be done by additionally setting the 5th bit (corresponding to a value of 16 in base 10 notation and 0x10 in hex, meaning AES256) and the 4th bit (corresponding to a value of 8 in base 10 notation, meaning AES128). If you are already running Samba 4.16.8 then you should consider simply going back to let the default getting used by Samba by either unsetting the attribute entirely (or setting it to a value of “0”). This adjustment in the Samba/AD LDAP will avoid using “rc4-hmac” for Session Keys, but still allow it as fallback for Ticket Keys. The latter is still recommended by Microsoft as last fallback option for interoperability. This change of the attribute msDS-SupportedEncryptionTypes can also be done using Microsofts native “Active Directory Users and Computers” GUI application.

The upstream Samba team recommends just enabling the AES256 keys, and probably that’s good advice. Additionally supporting AES128 is probably redundant and may also be obsoleted at some point in the future.

In case cross domain trusts to external Active Directory domain are configured

For trusted domains you should explicitly configure the use of aes256-cts-hmac-sha1-96 support, either via the Windows GUI or the newly added samba-tool domain trust modify --use-aes-keys.

For legacy trusts against Windows 2000/2003 domains you need to force rc4-hmac using samba-tool domain trust modify --no-aes-keys. Against remote DCs (including Windows) you can use the --local-dc-ipaddress= and other --local-dc-* options to specify that the remote DC shall be configured. The terminology of the options is a bit awkward at this point, but it works. See samba-tool domain trust modify --help for further details.

Note that already cached rc4-hmac cross-realm tickets may no longer work after switching to AES, which may cause temporary problems.

Setting a 1 hour ticket lifetime may reduce the problems. In UCS this can be done by running the follwing command on all UCS Samba/AD DCs

ucr set samba/global/options/kdc:user_ticket_lifetime=1 \
        samba/global/options/kdc:service_ticket_lifetime=1
/etc/init.d/samba restart

Changes for CVE-2022-38023

The vulnerability CVE-2022-38023 also affects fileservers and as described in that advisory, the Samba patch just changes the default for two configuration options. This can also be done manually by running

ucr set samba/global/options/"reject md5 servers"=yes \
        samba/global/options/"reject md5 clients"=yes
/etc/init.d/samba restart

on all UCS 4.4 servers running Samba

1 Like

is this correct?

for keytab in /etc/krb5.keytab /var/lib/samba/private/dns.keytab /var/lib/samba/private/http-proxy.keytab;
do
ktutil -k "$keytab" list | grep aes
done

because surely “/var/lib/samba/private/http-proxy.keytab;” relies on SQUID initialization, so if SQUID has never been installed on the univention this might not exist.

If this is the case, there should perhaps be a not to prevent readers being confused., by any errors thrown.

Mastodon