.. 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 <https://blogs.msdn.microsoft.com/openspecification/2009/09/12/msds-supportedencryptiontypes-episode-1-computer-accounts/>`_.

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 <https://tools.ietf.org/id/draft-ietf-curdle-des-des-des-die-die-die-03.html>`_.

The WDigest hashes
++++++++++++++++++

The *hash* ``WDigest`` is used to perform Digest authentication (`see this Wikipedia article <https://en.wikipedia.org/wiki/Digest_access_authentication>`_) 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.
