Gérer et stocker des hashes de mot de passe

Samba-AD se conforme au fonctionnement de Microsoft-AD pour le stockage des hashes de mots de passe standard. Depuis la version 4.6 puis la 4.7, l’équipe Samba a commencé à ajouter d’autres types de hashes dans la base de données Active Directory pour améliorer l’intégration avec les environnements extérieurs, notamment avec OpenLDAP. Il est important de noter que ces extensions restent compatibles avec le fonctionnement normal de la réplication d’un Microsoft-AD, même si celui ci ne pourra pas en bénéficier de ces hashes supplémentaires.

Les hashes standard Active Directory

Un Active Directory stocke les hashes Kerberos et ainsi que les hashesNT. Avant la version MS-AD-2k8r2, l’AD stockait aussi les hashes LM pour la rétrocompatibilité. Désormais les Hash LM ne sont plus générés ou stocké dans l’AD, que ce soit Samba-AD ou Microsoft AD.

Note

Il ne faut pas confondre HashNT qui est un type de hash, et le protocole NTLM qui est un protocole d’authentification.

Le HashNT

Le HashNT est stocké dans le champ unicodePwd sous forme binaire. Il suffit de convertir la valeur en hexadécimal pour obtenir le format de hash auquel on est habitué.

L’attribut unicodePwd n’est pas lisible en protocole LDAP. Pour l’afficher il est nécessaire de lancer la commande ldbsearch directement sur un contrôleur de domaine en accédant directement aux bases de stockage LDB.

L’attribut unicodePwd n’est pas non plus modifiable directement. Pour le changement de mot de passe, on peut écrire une nouvelle valeur dans ce champ (pourvu que l’on ait les droits). Toutefois l’écriture n’est pas une écriture directe, mais elle appelle un processus de changement de mot de passe qui va à la fois changer le HashNT et les hashes Kerberos.

Par exemple:

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')))"

On peut vérifier la valeur hexadécimal avec la ligne de commande suivante (le hash NT est la deuxième valeur après les deux points) :

pdbedit -Lw testuser
D37AB9ABF1800E092FFDBCD3B19A0167

Le HashLM

Comme mentionné dans l’introduction ci-dessus, le HashLM n’est désormais plus utilisé. Il était historiquement stocké dans l’attribut dbcsPwd. Ce champ est vide dans l’AD. On peut aussi constater cette valeur vide en lançant la commande ci-après, la valeur du HashLM est remplacé par une suite de XXXXX.

pdbedit -Lw testuser

Les hashes Kerberos

Les hashes Kerberos sont stocké dans l’attribut supplementalCredentials. Cet attribut n’est pas lisible en protocole LDAP et ne peut pas être modifié directement. Il est modifié lors du changement de mot de passe. C’est un champ multi-valués auquel on peut rajouter de nouveaux types de hashes. On retrouve dans ce champ les différents hashes Kerberos, ainsi que le hash WDigest (voir ci-dessous) et une copie du hash NT.

Les types de hashes Kerberos qui sont générés dans l’AD sont paramétrables en fonction du niveau de sécurité. Sous Samba il faut pour cela modifier le paramètre smb.conf password hash userPassword schemes.

Pour afficher le contenu de l’attribut supplementalCredential, il suffit de lancer la commande :

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

Les types de hash acceptés par une machine ou un utilisateur est renseigné sur son entrée LDAP sous l’attribut msDS-SupportedEncryptionTypes. Par défaut, au minimum les contrôleurs de domaine ont cette valeur configurée.

La valeur par défaut est msDS-SupportedEncryptionTypes: 0x1F (31) = ( DES_CBC_CRC | DES_CBC_MD5 | RC4_HMAC_MD5 | AES128_CTS_HMAC_SHA1_96 | AES256_CTS_HMAC_SHA1_96 ).

Les postes Windows 2000 / XP / 2003 ne supportent que les types de ciphers kerberos 3DES et RC4 (des3-cbc-md5, des3-cbc-sha1, des3-cbc-sha1-kd, rc4-hmac).

Il y a d’autres subtilités dans la définition des ciphers à utiliser. Pour plus d’information, voir cet article de Microsoft sur les types de chiffrement supportés.

Cas particulier du hash Kerberos dérivé du hash NT

Si l’on a réinjecté un hash NT (soit lors d’une migration Samba3-OpenLDAP vers Samba-AD, soit par l’utilisation de la commande pdbedit --set-nt-hash, il n’est pas possible de générer l’ensemble des hashes Kerberos habituellement générés par l’Active Directory car le mot de passe en clair n’est pas disponible. Dans ce cas de figure, le seul hash Kerberos disponible est un hash dérivé du HashNT (RC4-HMAC, défini dans cette la RFC4757).

Le hash Kerberos RC4-HMAC est considéré trop faible pour les systèmes actuels et sa suppression est proposé dans ce draft IETF.

Les hashes WDigest

Le hash WDigest sert à effectuer l’authentification en mode Digest (voir cet article Wikipedia) sur les applications Web et proxy authentifiant. Le hash est dérivé de l’identifiant de l’utilisateur, du domaine et du mot de passe.

Propager un changement de mot de passe de Samba-AD à un OpenLDAP

Nouveau dans la version 4.7.

Il est maintenant possible d’avoir de nouveaux types de hashes générés lorsqu’un utilisateur change son mot de passe, comme le crypt-ssha256 ou crypt-ssha512. Ces hashes sont utilisés habituellement pour l’authentification sur des bases OpenLDAP. Il est alors possible de réinjecter ces hashes depuis les serveurs Samba-AD vers les serveurs OpenLDAP pour propager un changement de mot de passe d’un utilisateur.