web-dev-qa-db-fra.com

"Jeton défectueux GSSException détecté" - lors de la tentative d'authentification auprès de Tomcat exécuté sur Windows à l'aide de Kerberos

J'ai du mal à m'authentifier auprès d'un Java (j'ai essayé à la fois Tomcat et Jetty) lors de l'exécution sur Windows 2012.

Chaque fois que j'essaie le schéma d'authentification Negotiate, j'obtiens une erreur: org.ietf.jgss.GSSException: Defective token detected (Mechanism level: GSSHeader did not find the right tag)

Étapes à reproduire

Commencez par configurer une instance de Windows Server 2012 ou 2016 et installez les services de domaine Active Directory.

Dans mon exemple, j'ai créé:

  • Domaine NETBIOS: NICKIS

  • Domaine DNS: nickis.life

Créer l'utilisateur du sujet Kerberos sur Active Directory

IMPORTANT: ASSUREZ-VOUS QUE LE PREMIER NOM, LE DERNIER NOM ET LE NOM COMPLET SONT LES MÊMES!

Le nouvel utilisateur dans mon cas est:

[~ # ~] dn [~ # ~] = CN=kerberos500,CN=Users,DC=nickis,DC=life

connexion + domaine = [email protected]

NETBIOS\samAccountName = NICKIS\kerberos500

Exécutez la commande setspn à partir du serveur Windows Active Directory

setspn -A HTTP/[email protected] kerberos500

Exemple de sortie:

C:\Users\Administrator>setspn -A HTTP/nickis.life kerberos500
Checking domain DC=nickis,DC=life 
Registering ServicePrincipalNames for CN=kerberos500,CN=Users,DC=nickis,DC=life
        HTTP/kerberos500.nickis.life
Updated object

Exécutez la commande ktpass à partir du serveur Windows Active Directory

ktpass -out c:\Users\Administrator\kerberos500.keytab -princ HTTP/[email protected] -mapUser kerberos500 -mapOp set -pass XXXXpasswordforkerberos500userXXXX -crypto DES-CBC-MD5 -pType KRB5_NT_PRINCIPAL +DesOnly

Exemple de sortie:

C:\Users\Administrator>ktpass -out c:\Users\Administrator\kerberos500.keytab -princ HTTP/[email protected] -mapUser kerberos500 -mapOp set -pass xxxxxxxx -crypto DES-CBC-MD5 -pType KRB5_NT_PRINCIPAL +DesOnly
Targeting domain controller: WIN-OVV6VHBGIB8.nickis.life
Using legacy password setting method
Successfully mapped HTTP/kerberos500.nickis.life to kerberos500.
Key created.
Output keytab to c:\Users\Administrator\kerberos500.keytab:
Keytab version: 0x502
keysize 71 HTTP/[email protected] ptype 1 (KRB5_NT_PRINCIPAL) vno 3 etype 0x3 (DES-CBC-MD5) keylength 8 (0xcd07200bea625d20)
Account kerberos500 has been set for DES-only encryption.

À ce stade, vous aurez maintenant un fichier keytab:

c:\Users\Administrator\kerberos500.keytab

Et un utilisateur principal:

HTTP/[email protected]

Ce sont les 2 entrées qui doivent être fournies au GSSApi pour obtenir une connexion unique avec Kerberos.

J'ai donc déployé ces entrées dans le domaine de sécurité Kerberos de mon conteneur Web dans le module de sécurité Hadoop.

Test de curl J'ai essayé en vain d'utiliser curl pour le tester:

curl --negotiate -u : http://nickis.life:8080/my/webapp

Test Internet Explorer J'ai également essayé d'utiliser Internet Explorer. J'ai ajouté le domaine nickis.life Aux rôles approuvés dans Internet Explorer. Ensuite, je lance le site dans Internet Explorer: http://nickis.life:808

Quoi qu'il en soit, j'obtiens l'erreur ci-dessous:

org.Apache.hadoop.security.authentication.client.AuthenticationException: GSSException: Defective token detected (Mechanism level: GSSHeader did not find the right tag)
    at org.Apache.hadoop.security.authentication.server.KerberosAuthenticationHandler.authenticate(KerberosAuthenticationHandler.Java:398) ~[hadoop-auth-2.7.1.jar:?]

...

Caused by: org.ietf.jgss.GSSException: Defective token detected (Mechanism level: GSSHeader did not find the right tag)
    at Sun.security.jgss.GSSHeader.<init>(Unknown Source) ~[?:1.8.0_131]
    at Sun.security.jgss.GSSContextImpl.acceptSecContext(Unknown Source) ~[?:1.8.0_131]
    at Sun.security.jgss.GSSContextImpl.acceptSecContext(Unknown Source) ~[?:1.8.0_131]
    at org.Apache.hadoop.security.authentication.server.KerberosAuthenticationHandler$2.run(KerberosAuthenticationHandler.Java:365) ~[hadoop-auth-2.7.1.jar:?]
    at org.Apache.hadoop.security.authentication.server.KerberosAuthenticationHandler$2.run(KerberosAuthenticationHandler.Java:347) ~[hadoop-auth-2.7.1.jar:?]
    at Java.security.AccessController.doPrivileged(Native Method) ~[?:1.8.0_131]
    at javax.security.auth.Subject.doAs(Unknown Source) ~[?:1.8.0_131]
    at org.Apache.hadoop.security.authentication.server.KerberosAuthenticationHandler.authenticate(KerberosAuthenticationHandler.Java:347) ~[hadoop-auth-2.7.1.jar:?]

Je suis perplexe. REMARQUE: J'ai trouvé plusieurs liens ici et là, mais aucun d'entre eux n'était exhaustif sur les étapes qui ont été suivies comme je l'ai résumé ici, et aucune des solutions fournies dans le cadre n'a fonctionné pour moi.

Quelqu'un peut-il retracer ce que je fous ici?

MISE À JOUR:

  • J'ai un serveur AD avec un domaine défini sur fusionis.life Et le serveur AD est WIN-OVV6VHBGIB8.fusionis.life
  • J'ai déplacé le serveur Tomcat vers une autre machine Windows du domaine. DESKTOP-VTPBE99.fusionis.life
  • J'ai ouvert dnsmgmt.msc Et ajouté une "zone de recherche directe" avec "kerberos500.nickis.life" avec un hôte défini sur l'IP de la boîte DESKTOP-VTPBE99.fusionis.life.
  • J'ai supprimé le compte AD, je l'ai recréé, puis j'ai à nouveau généré le keytab comme suggéré dans l'une des réponses du ticket.

C:\Users\Administrator>ktpass -out c:\Users\Administrator\kerberos500.keytab -princ HTTP/[email protected] -mapUser kerberos500 -mapOp set -pass xxxxxxxxx -crypto ALL -pType KRB5_NT_PRINCIPAL Targeting domain controller: WIN-OVV6VHBGIB8.fusionis.life Using legacy password setting method Successfully mapped HTTP/kerberos500.nickis.life to kerberos500. Key created. Key created. Key created. Key created. Key created. Output keytab to c:\Users\Administrator\kerberos500.keytab: Keytab version: 0x502 keysize 67 HTTP/[email protected] ptype 1 (KRB5_NT_PRINCIPAL) vno 4 etype 0x1 (DES-CBC-CRC) keylength 8 (0x04e30b9183ba8389) keysize 67 HTTP/[email protected] ptype 1 (KRB5_NT_PRINCIPAL) vno 4 etype 0x3 (DES-CBC-MD5) keylength 8 (0x04e30b9183ba8389) keysize 75 HTTP/[email protected] ptype 1 (KRB5_NT_PRINCIPAL) vno 4 etype 0x17 (RC4-HMAC) keylength 16 (0xe39a141de38abd8750bf9c0bf49fd1c5) keysize 91 HTTP/[email protected] ptype 1 (KRB5_NT_PRINCIPAL) vno 4 etype 0x12 (AES256-SHA1) keylength 32 (0xe368a1b060cfe4816f522c1c5f62ca07fe201ed96c6d018054dfbd5b86251892) keysize 75 HTTP/[email protected] ptype 1 (KRB5_NT_PRINCIPAL) vno 4 etype 0x11 (AES128-SHA1) keylength 16 (0x1b1a548fa2893a78c6f4c7f9c482b614)

  • J'ai enregistré le fichier de mise à jour du fichier de clés sur le serveur, puis mis à jour le principal du service en HTTP/[email protected]

  • Je me suis connecté à la machine Tomcat en tant qu'utilisateur de domaine, j'ai ajouté http://kerberos500.nickis.life aux sites de confiance, puis j'ai accédé à http://kerberos500.nickis.life:8764

  • J'ai vérifié toutes les combinaisons des cases à cocher de cryptage dans l'onglet "compte" de kerberos500 AD.

Maintenant, je reçois une nouvelle erreur ...

GSSException: No valid credentials provided (Mechanism level: Failed to find any Kerberos credentails)

MISE À JOUR:

Résolu enfin. J'ai eu cette dernière erreur car j'avais besoin que fusionis.life Soit sur le même hôte que nickis.life

javawindowsactive-directorykerberosgssapi
10
Nicholas DiPiazza

L'erreur " Jeton défectueux détecté" signifie probablement qu'un jeton ntlm a été détecté. C’est ce que le mécanisme de négociation utilise dans les navigateurs Web populaires si kerberos échoue - s’il n’y est pas invité par le serveur Web autrement. Sur windows systèmes d'exploitation, le IE navigateur Web sur celui-ci (et Firefox, s'il est configuré correctement) dit essentiellement, si vous ne faites pas Kerberos, je vais pour vous envoyer un jeton NTLM. Et le serveur répond "pas du tout" Je ne connais même pas NTLM donc j'appelle ce que vous m'avez envoyé défectueux. Puisque vous semblez configurer cela pour la première fois, vous ne configurer n'importe quel mécanisme de secours (tel que NTLM) pour quand Kerberos échoue, par conséquent, ce message d'erreur. Nous résolvons cela en comprenant pourquoi Kerberos échoue. Je pense que je vois la raison de l'échec dans votre question, à deux endroits, liés aux SPN et les sites de confiance. Même si vous résolvez ces deux éléments, il existe une troisième et quatrième raison pour laquelle il pourrait continuer à échouer, liée au chiffrement.

  1. spn pour le service HTTP ne correspond pas à l'URL entrée par le navigateur. Ceux-ci doivent correspondre, sinon Kerberos échouera. Pour fonctionner, le navigateur doit utiliser: http://kerberos500.nickis.life:808 , pas http://nickis.life:808 . Je dis cela en fonction de ce que j'ai vu dans votre keytab syntaxe de création. En ce sens, vous avez codé le SPN comme tel: HTTP/[email protected]. C'est pourquoi vous devez utiliser http://kerberos500.nickis.life:808 . Le navigateur ne saura pas comment accéder à votre service Web lorsque vous lui direz d'aller à http://nickis.life:808 . Avec cette URL supérieure, le navigateur suppose qu'il doit trouver un service Web en cours d'exécution sur votre Active Directory domaincontroller (tout ce qui ne contient que nickis.life est supposé s'exécuter sur le contrôleur de domaine). Les contrôleurs de domaine ne doivent jamais exécuter de serveurs Web pour des raisons de sécurité.
  2. Vous devrez ajouter http://kerberos500.nickis.life en tant que site de confiance sous IE settings. Alternativement, * .nickis.life fonctionnerait également (Vous l'avez appelé Trusted Roles, alors qu'il s'appelait en fait Trusted Sites).
  3. Vous limitez le type de chiffrement Kerberos à DES-CBC-MD5. À partir de Windows Server 2008 Active Directory R2, DES est désactivé par défaut. DES est un type de cryptage obsolète et généralement non sécurisé de nos jours. Il est préférable d'utiliser AES128 ou encore mieux, AES256. Vous pouvez résoudre ce problème en régénérant le fichier de clés conformément à mon exemple ci-dessous.
  4. Dans le compte d'utilisateur AD kerberos500, accédez à l'onglet Compte, faites défiler vers le bas et cochez toutes les cases pour DES, AES 128 et AES 256, et OK, vous êtes bien sorti des boîtes de dialogue. Vous devez cocher ces cases même si vous avez tout fait juste au-dessus, sinon l'authentification Kerberos échouera toujours.

Comment régénérer correctement le fichier de clés: vous ne devez pas exécuter la commande setspn -a pour ajouter un SPN à un utilisateur AD chaque fois que vous prévoyez de créer un fichier de clés associé à ce compte d'utilisateur. La raison en est que la commande de création de keytab ajoute le SPN au compte d'utilisateur dans le cadre de la commande. Si votre scénario ne fonctionne pas après avoir suivi mes conseils ci-dessus, vous devrez supprimer le SPN via setspn -D comme ci-dessous:

setspn -D HTTP/[email protected] kerberos500

Et la régénération du keytab par la suite, mon seul changement est que je lui ai dit d'utiliser tous les types de cryptage. Le client et le serveur s'accorderont sur le plus commun lors du processus d'authentification.

ktpass -out c:\Users\Administrator\kerberos500.keytab -princ HTTP/[email protected] -mapUser kerberos500 -mapOp set -pass XXXXpasswordforkerberos500userXXXX -crypto ALL -pType KRB5_NT_PRINCIPAL


Remplacez ensuite l'ancien keytab par le nouveau. Pour plus d'informations détaillées sur les keytabs, vous pouvez lire plus de mon article technique sur la façon de créer des keytabs Kerberos ici: Kerberos Keytabs - Explained . Je reviens fréquemment et le modifie en fonction des questions que je vois ici dans ce forum.

Au fait, HTTP/kerberos500.nickis.life est un principal de service, pas un principal d'utilisateur comme vous l'avez écrit dans votre question. J'utilise uniquement des navigateurs Web pour tester Kerberos dans des scénarios HTTP comme celui-ci, je n'utilise pas cURL.

Je suis positif si vous passez avec diligence à travers les quatre points que j'ai mis en évidence ci-dessus, vous résoudrez ce problème.

EDIT1: Cette réponse suppose que vous disposez d'un service HTTP exécuté sur un hôte avec le nom de domaine complet kerberos500.nickis.life. Si vous n'avez pas un tel hôte avec ce nom, ma réponse changera légèrement. Veuillez me le faire savoir, le cas échéant.

EDIT2: Pour atteindre l'objectif d'authentification en utilisant l'URL de http://nickis.life:808 , alors vous pouvez continuez à utiliser le même keytab que vous avez déjà créé.

Sur le compte AD NICKIS\kerberos500, accédez à l'onglet Compte, faites défiler vers le bas et cochez la case "Utiliser Kerberos DES types de cryptage pour ce compte".

Activez ensuite le chiffrement DES lui-même au niveau du domaine AD via la stratégie de groupe. Pour ce faire, procédez comme suit:

  1. Ouvrez la console de gestion des stratégies de groupe (GPMC).
  2. Modifier l'objet de stratégie de domaine par défaut GPO. (Il est plus sûr de créer un nouveau niveau de domaine GPO à la place et de le modifier, mais cela dépend de vous).
  3. Accédez à Configuration ordinateur> Stratégies> Paramètres Windows> Paramètres de sécurité> Stratégies locales> Options de sécurité> "Sécurité réseau: configurer les types de cryptage autorisés pour Kerberos" et cochez les deux cases pour DES_CBC_MD5 et DES_CBC_MD5. IMPORTANT: dans cette même stratégie de groupe, assurez-vous également que les cases à cocher pour RC4, AES128 et AES256 sont également cochées. Ces types de cryptage ne seront pas utilisés pour les tickets de votre site Web, mais ils le seront pour tout le reste du domaine. et OK, vous êtes loin des boîtes de dialogue et fermez la GPMC.
  4. Exécutez la commande 'gpupdate/force' sur le serveur DC et le client.
  5. Exécutez "klist purge" sur le client pour purger tous les tickets Kerberos.
  6. Dans le navigateur Web, videz le cache et supprimez tous les cookies.
  7. Assurez-vous que le serveur DC autorise le port 8080 TCP entrant).
  8. Essayez à nouveau.

Référence: Configurations Windows pour le type de chiffrement pris en charge par Kerberos

EDIT 3: Évitez d'exécuter Kerberos KDC (le contrôleur de domaine), client et serveur sur la machine même . C'est une recette classique pour obtenir l '"erreur de jeton défectueux" même si vous avez tout fait correctement.

EDIT 4: (Mise à jour finale qui a été vérifiée par l'OP): J'ai regardé la nouvelle sortie de création du fichier de clés ktpass, et j'ai vu ceci: Contrôleur de domaine de ciblage: WIN-OVV6VHBGIB8.fusionis.life. Maintenant, le SPN défini dans le keytab est HTTP/kerberos500.nickis.life. Le nom de domaine AD est différent du SPN que vous avez défini, donc cela ne fonctionnera pas sauf si vous avez une sorte de configuration de confiance entre ces domaines. Si vous n'avez pas d'approbation, vous devez utiliser à la place un SPN HTTP/kerberos500.fusionis.life.

12
T-Heron