Le KDC Kerberos ne prend pas en charge le type de chiffrement lors de l'obtention des identifiants

Windows Server & IT Pro Active Directory & Entra ID
1

Je configure une authentification apache/SSO avec un AD via Kerberos.
Mon serveur http est un Debian Wheezy et l’AD est un Windows Server 2012.

J’ai généré des fichiers keytab sur WS2012 avec la commande kpass pour chaque type de chiffrement disponible sur WS2012.

Lorsque j’essaie d’ouvrir une session avec un utilisateur [email protected] via kinit, cela fonctionne.

Lorsque j’essaie d’ouvrir une session avec mon HTTP/[email protected], j’obtiens le message :

kvno HTTP/[email protected]
kvno: KDC has no support for encryption type while getting credentials for HTTP/[email protected]

De plus, lorsque je vérifie le chiffrement utilisé pour [email protected], j’ai :

root@SERVER:~# klist -e
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: [email protected]

Valid starting       Expires              Service principal
03/04/2015 12:48:21  03/04/2015 22:48:17  krbtgt/[email protected]
        renew until 04/04/2015 12:48:21, Etype (skey, tkt): arcfour-hmac, arcfour-hmac

J’ai essayé de personnaliser mon /etc/krb5.conf avec :

  default_tgs_enctypes = arcfour-hmac-md5 des-cbc-crc des-cbc-md5
  default_tkt_enctypes = arcfour-hmac-md5 des-cbc-crc des-cbc-md5

Et en utilisant le fichier keytab chiffré avec arcfour-hmac sans succès.

Je ne comprends pas comment changer le type de chiffrement utilisé pour communiquer, pourquoi il veut toujours arcfour-hmac et pourquoi quand je lui fournis le chiffrement arcfour-hmac, rien ne change…

Comment être sûr que les modifications de /etc/krb5.conf sont effectives et comment faire fonctionner la génération de tickets Kerberos également ?

2

Les types de chiffrement pris en charge par un contrôleur de domaine Active Directory sont listés dans l’attribut msDS-SupportedEncryptionTypes de l’objet ordinateur du contrôleur de domaine. Dans une installation par défaut, ils sont généralement quelque chose comme :

RC4_HMAC_MD5
AES128_CTS_HMAC_SHA1_96
AES256_CTS_HMAC_SHA1_96

C’est un masque de bits qui donne la valeur décimale 28, donc quelque chose comme 00011100.

Donc quand vous demandez pourquoi le contrôleur de domaine « veut toujours uniquement ARC4-HMAC », c’est parce que votre client n’a aucun des deux autres types de chiffrement en commun avec le contrôleur de domaine, ils sont donc éliminés pendant le processus de négociation.

(Remarque : RC4_HMAC_MD5 est vraiment le pire et le plus faible de tous les types de chiffrement possibles ici, mais il est aussi parfois nécessaire pour prendre en charge les scénarios hérités et l’interopérabilité avec les produits non-Microsoft.)

J’ai consulté de la documentation et trouvé un exemple de fichier de configuration d’une autre personne qui pourrait être utile :

http://wiki.squid-cache.org/ConfigExamples/Authenticate/Kerberos

; for Windows 2008 with AES
   default_tgs_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5
   default_tkt_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5
   permitted_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5

Remarquez que, en plus de prendre en charge de meilleurs types de chiffrement, ils spécifient également rc4-hmac dans leur configuration, ce qui est différent de ce que vous avez, arcfour-hmac-md5. (N’oubliez pas non plus la ligne permitted_enctypes, que je n’ai pas vue dans votre message.)

Je ne suis pas sûr à 100% que cela résoudra votre problème, car je ne suis pas en mesure de le tester maintenant, mais j’espère que cela vous aidera.