Managing and storing password hashes

Samba-AD complies with Microsoft-AD’s operation for storing hashs of standard passwords. Since version 4.6 and then 4.7, the Samba team started adding other types of hashs in the Active Directory database to improve integration with external environments, notably with OpenLDAP. It is important to note that these extensions remain compatible with the normal operation of Microsoft-AD replication, even if the latter will not be able to benefit from these additional hashs.

Standards hashs in Active Directory

An Active Directory stores Kerberos hashes and also hashsNT. Prior to MS-AD-2k8r2, the AD also stored the hashes LM for backward compatibility. Now the Hash LMs are no longer generated or stored in the AD, either Samba-AD or Microsoft AD.

Note

Do not confuse HashNT which is a type of hash, and the NTLM protocol which is an authentication protocol.

The HashNT

The HashNT is stored in the unicodePwd field in binary form. Simply convert the value to hexadecimal to get the hash format you are used to.

The attribute unicodePwd is not readable in LDAP protocol. To display it it is necessary to run the command ldbsearch directly on a domain controller by accessing directly the LDB storage bases.

The attribute unicodePwd is also not directly modifiable. To change the password, you can write a new value in this field (provided you have the rights). However the writing is not a direct write, but calls a password change process which will change both the HashNT and the Kerberos hashes.

For example:

ldbsearch -H /var/lib/samba/private/sam.ldb '(cn=testuser)' unicodepwd
dn: cn=testuser,ou=test,dc=test,dc=lan
unicodePwd:: 03q5q/GADgkv/bzTsZoBZw==

python -c "import codecs ; import binascii; print (binascii.hexlify(codecs.decode( '03q5q/GADgkv/bzTsZoBZw==' , 'base64')))"

The hexadecimal value can be checked with the following command line (the hash NT is the second value after the colon):

pdbedit -Lw testuser
D37AB9ABF1800E092FFDBCD3B19A0167

The HashLM

As mentioned in the introduction above, HashLM is no longer used. It was historically stored in the dbcsPwd attribute. This field is empty in AD. This empty value can also be seen by running the following command, the value of the HashLM is replaced by a sequence of XXXXX.

pdbedit -Lw testuser

Kerberos hashes

The Kerberos hashes are stored in the supplementalCredentials attribute. This attribute is not readable in LDAP protocol and cannot be directly modified. It is modified when the password is changed. It is a multi-valued field to which new types of hashes can be added. We find in this field the different Kerberos hashes, as well as the hash WDigest (see below) and a copy of the NT hash.

The types of Kerberos hashes that are generated in the AD are configurable according to the security level. Under Samba you have to change the parameter smb.conf password hash userPassword schemes.

To display the contents of the attribute supplementalCredential, simply run the command:

ldbsearch --show-binary -H    /var/lib/samba/private/sam.ldb '(cn=testuser)' supplementalcredentials

The hash types accepted by a machine or a user is given on their LDAP entry under the mDS-SupportedEncryptionTypes attribute. By default, domain controllers have at least this value configured.

The default value is msDS-SupportedEncryptionTypes: 0x1F (31) = (DES_CBC_CRC | DES_CBC_MD5 | RC4_HMAC_MD5 | AES128_CTS_HMAC_SHA1_96 | AES256_CTS_HMAC_SHA1_96 ).

Windows 2000 / XP / 2003 workstations only support the kerberos cipher types 3DES and RC4 (des3-cbc-md5, des3-cbc-sha1, des3-cbc-sha1-kd, rc4-hmac).

There are other subtleties in the definition of the ciphers to be used. For more information, see this Article from Microsoft on supported cipher types.

Special case of Kerberos hash derived from NT hash

If you have reinjected an hash NT (either during a Samba3-OpenLDAP to Samba-AD migration, or by having used the pdbedit –set-nt-hash command), it is not possible to generate all the Kerberos hashes usually generated by the Active Directory because the plain text password is not available. In this case, the only Kerberos hash available is a hash derived from HashNT (RC4-HMAC, defined in RFC4757).

The RC4-HMAC Kerberos hash is considered too weak for current systems and its removal is proposed in this IETF draft.

The WDigest hashes

The hash WDigest is used to perform Digest authentication (see this Wikipedia article) on authenticating web and proxy applications. The hash is derived from the user ID, domain and password.

Propagating a password change from Samba-AD to an OpenLDAP

New in version 4.7.

It is now possible to have new types of hashes generated when a user changes their password, such as crypt-ssha256 or crypt-ssha512. These hashes are usually used for authentication on OpenLDAP databases. It is then possible to re-inject these hashes from the Samba-AD servers to the OpenLDAP servers to propagate a change of a user’s password.