.. Reminder for header structure:
Parts (H1) : #################### with overline
Chapters (H2) : ******************** with overline
Sections (H3) : ====================
Subsections (H4) : --------------------
Subsubsections (H5) : ^^^^^^^^^^^^^^^^^^^^
Paragraphs (H6) : """""""""""""""""""""
.. |date| date::
.. meta::
:description: Managing and storing password hashes
:keywords: LDAP, Samba-AD, Active Directory, Kerberos, NT, LM, NTLM, hash
.. _about_password_hash:
####################################
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* :abbr:`LM (LanManager)` 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 :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:
.. code-block:: bash
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):
.. code-block:: bash
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.
.. code-block:: bash
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:
.. code-block:: bash
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
==========================================================
.. versionadded:: 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.