"GSSException Fehlerhaftes Token erkannt" - wenn versucht wird, sich mit Windows unter Verwendung von Kerberos bei Tomcat zu authentifizieren

8

Ich habe Schwierigkeiten, mich mit einem Java-Webcontainer zu authentifizieren (ich habe sowohl Tomcat als auch Jetty ausprobiert), wenn ich mit Windows 2012 arbeite.

Jedes Mal, wenn ich das Negotiate Auth-Schema versuche, erhalte ich einen Fehler: org.ietf.jgss.GSSException: Defective token detected (Mechanism level: GSSHeader did not find the right tag)

Schritte zum Reproduzieren

Beginnen Sie mit der Einrichtung einer Windows Server 2012- oder Windows-Instanz und installieren Sie Active Directory-Domänendienste.

In meinem Beispiel habe ich erstellt:

  • NETBIOS-Domäne: NICKIS

  • DNS-Domain: nickis.life

Erstellen Sie den Kerberos-Benutzer in Active Directory

WICHTIG: VERGEWISSERN SIE SICH, DASS DER VORNAME, DER LETZTE NAME UND DER VOLLE NAME SIND!

Der neue Benutzer in meinem Fall ist:

DN = CN=kerberos500,CN=Users,DC=nickis,DC=life

Anmeldung + Domain = [email protected]

NETBIOS \ samAccountName = NICKIS\kerberos500

Führen Sie den Befehl setspn von Windows Active Directory Server

aus %Vor%

Beispielausgabe:

%Vor%

Führen Sie den Befehl ktpass von Windows Active Directory Server

aus %Vor%

Beispielausgabe:

%Vor%

An dieser Stelle haben Sie jetzt eine Keytab-Datei:

%Vor%

Und ein Benutzerprinzipal:

%Vor%

Dies sind die zwei Eingaben, die benötigt werden, um dem GSSApi die einmalige Anmeldung mit Kerberos zu ermöglichen.

Also habe ich diese Eingaben im Sicherheitsbereich von Kerberos im Webcontainer im Hadoop-Sicherheitsmodul bereitgestellt.

Curl-Test Ich habe erfolglos versucht, Curl zu verwenden, um es zu testen:

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

Internet Explorer-Test Ich habe auch versucht, den Internet Explorer zu verwenden. Ich habe nickis.life domain zu den vertrauenswürdigen Rollen in Internet Explorer hinzugefügt. Dann starte ich die Seite im Internet Explorer: Ссылка

Wie auch immer, ich bekomme den Fehler unten:

%Vor%

Ich bin ratlos. HINWEIS: Ich habe hier und da mehrere Links gefunden, aber keines von ihnen war in den Schritten, die ich hier beschrieben habe, all-inclusive, und keine der Lösungen, die darin enthalten waren, funktionierte für mich.

  • Ich versuche eine Kerberos-Anmeldung von einem anderen Computer in der Domäne, als der Server auf
  • ausgeführt wird
  • Ich habe alle möglichen Kombinationen von Keytab-Varianten getestet, die bisher noch nicht funktionieren.
  • Es gibt keinen doppelten SPN.
  • Ich habe versucht, den DNS auf dem Domänenserver als A record einzurichten.
  • Ich frage mich vielleicht, ob es einige Kerberos Windows Server Setup-Schritte und Microsoft-Mitarbeiter verifiziert, dass dies hier nicht der Fall sein sollte: Ссылка

Kann jemand nachvollziehen, was ich hier vermassele?

UPDATE:

  • Ich habe den AD-Server mit der Domain fusionis.life und den AD-Server mit WIN-OVV6VHBGIB8.fusionis.life
  • Ich habe den Tomcat-Server auf einen anderen Windows-Rechner in der Domäne verschoben. %Code%
  • Ich habe DESKTOP-VTPBE99.fusionis.life geöffnet und eine "Forward-Lookup-Zone" mit "kerberos500.nickis.life" hinzugefügt, wobei ein HOST auf die IP-Adresse der dnsmgmt.msc -Box gesetzt wurde.
  • Ich habe den AD-Account gelöscht, neu erstellt und den Keytab erneut generiert, wie in einer der Antworten auf dem Ticket vorgeschlagen.

DESKTOP-VTPBE99.fusionis.life

  • Ich habe die Keytab-Datei auf dem Server gespeichert und dann den Service Principal in 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)

  • aktualisiert
  • Ich habe mich als Domänenbenutzer bei tomcat machine angemeldet, Ссылка zu den vertrauenswürdigen Sites hinzugefügt und dann zu Ссылка

  • Ich habe alle Kombinationen der Verschlüsselungs-Kontrollkästchen in der Registerkarte "account" des kerberos500 AD überprüft.

Jetzt bekomme ich einen neuen Fehler ...

HTTP/[email protected]

UPDATE:

Endlich gelöst. Ich habe diesen letzten Fehler bekommen, weil ich GSSException: No valid credentials provided (Mechanism level: Failed to find any Kerberos credentails) benötigt habe, um auf demselben Host zu sein wie fusionis.life

    
Nicholas DiPiazza 10.11.2017, 16:31
quelle

2 Antworten

7

Der Fehler " Fehlerhaftes Token erkannt " bedeutet wahrscheinlich, dass ein Token wurde erkannt. Dies ist, was der Negotiate-Mechanismus in populären Webbrowsern verwendet, wenn schlägt fehlschlägt - wenn nicht andernfalls vom Webserver angewiesen. Auf Betriebssysteme, der IE-Webbrowser drauf (und Firefox, wenn richtig konfiguriert) sagt grundsätzlich, wenn Sie Kerberos nicht tun, werde ich Ihnen ein NTLM-Token senden. Und der Server antwortet "auf keinen Fall" Ich weiß nicht einmal NTLM, also rufe ich an, was Sie mir schadhaft gesendet haben. Da Sie dies anscheinend zum ersten Mal einrichten, haben Sie wahrscheinlich keinen Fallback-Mechanismus (z. B. NTLM) für den Fall konfiguriert, dass Kerberos fehlschlägt, daher diese Fehlermeldung. Wir lösen dies, indem wir verstehen, warum Kerberos versagt. Ich denke, ich sehe den Grund für den Fehler in Ihrer Frage an zwei Stellen, die sich auf SPNs und vertrauenswürdige Sites beziehen. Selbst wenn Sie diese beiden Elemente auflösen, gibt es einen dritten Grund und einen vierten Grund, warum es im Zusammenhang mit der Verschlüsselung weiterhin fehlschlagen könnte.

  1. Die für den HTTP-Dienst stimmen nicht mit der URL überein, die von eingegeben wurde der Browser. Diese müssen übereinstimmen, andernfalls wird Kerberos fehlschlagen. Um zu arbeiten, sollte der Browser verwenden: Ссылка , nicht Ссылка . Ich sage das basierend auf dem, was ich in Ihrer Erstellungssyntax gesehen habe. Darin haben Sie den SPN als solchen codiert: HTTP/[email protected]. Deshalb müssen Sie Ссылка verwenden. Der Browser weiß nicht, wie er zu Ihrem Webdienst gelangt, wenn Sie ihm mitteilen, dass er Ссылка aufrufen soll. Mit dieser Top-URL geht der Browser davon aus, dass er nach einem Webdienst suchen muss, der in >>>>>>>>>>>>> ausgeführt wird domaincontroller (es wird angenommen, dass alles mit nur nickis.life auf dem Domain Controller läuft). Domänencontroller sollten aus Sicherheitsgründen niemals Webserver ausführen.
  2. Sie müssen Ссылка unter IE-Einstellungen als vertrauenswürdige Site hinzufügen. Alternativ könnte * .nickis.life auch funktionieren. (Sie haben es als vertrauenswürdige Rollen bezeichnet, wenn es sich tatsächlich um vertrauenswürdige Sites handelt).
  3. Sie beschränken den Kerberos-Verschlüsselungstyp auf DES-CBC-MD5. Ab Windows Server 2008 Active Directory R2 ist DES standardmäßig deaktiviert. DES ist heutzutage ein veralteter und im Allgemeinen unsicherer Verschlüsselungstyp. Viel besser, AES128 oder noch besser AES256 zu verwenden. Sie können das beheben, indem Sie den Keytab für mein Beispiel unten neu generieren.
  4. Gehen Sie im AD-Benutzerkonto kerberos500 zur Registerkarte Konto, scrollen Sie nach unten und markieren Sie alle Kästchen für DES, AES 128 und AES 256 und OK, Sie befinden sich weit außerhalb der Dialogfelder. Sie müssen diese Kästchen auch dann aktivieren, wenn Sie oben alles richtig gemacht haben oder die Kerberos-Authentifizierung weiterhin fehlschlägt.

So erstellen Sie die Schlüsseltabelle ordnungsgemäß neu: Sie sollten den Befehl setspn -a nicht ausführen, um einem AD-Benutzer einen SPN hinzuzufügen, wenn Sie planen, eine Schlüsseltabelle für dieses Benutzerkonto zu erstellen. Der Grund dafür ist, dass der Keytab-Erstellungsbefehl den SPN als Teil des Befehls zum Benutzerkonto hinzufügt. Wenn Ihr Szenario nicht funktioniert, nachdem Sie meinen obigen Ratschlag befolgt haben, müssen Sie den SPN wie folgt mit setspn -D entfernen:

%Vor%

Und die Keytab neu generieren danach, meine einzige Änderung ist, dass ich ihm gesagt, alle Verschlüsselungsarten zu verwenden. Der Client und der Server stimmen während des Authentifizierungsvorgangs mit dem stärksten gemeinsamen überein.

%Vor%


Ersetzen Sie dann die alte Keytab durch die neue. Weitere ausführliche Informationen zu Keytabs finden Sie in meinem technischen Artikel zum Erstellen von Kerberos-Keytabs: Kerberos Keytabs - erklärt . Ich gehe häufig zurück und bearbeite es basierend auf Fragen, die ich hier in diesem Forum sehe.

Übrigens ist HTTP / kerberos500.nickis.life ein Dienstprinzipal und kein Benutzerprinzipal, wie Sie in Ihrer Frage geschrieben haben. Ich verwende nur Webbrowser, um Kerberos in HTTP-Szenarios wie diesem zu testen, ich benutze cURL nicht.

Ich bin positiv, wenn Sie alle vier Punkte sorgfältig durchgehen, die ich oben hervorgehoben habe, werden Sie dieses Problem lösen.

EDIT1: Bei dieser Antwort wird davon ausgegangen, dass auf einem Host mit dem vollqualifizierten Domänennamen kerberos500.nickis.life ein HTTP-Dienst ausgeführt wird. Wenn Sie keinen solchen Host mit diesem Namen haben, wird sich meine Antwort leicht ändern. Bitte lassen Sie mich wissen, falls vorhanden.

EDIT2: Um das Ziel der Authentifizierung mithilfe der URL von Ссылка zu erreichen, können Sie weiterhin verwenden das gleiche Keytab, das Sie bereits erstellt haben.

Gehen Sie auf dem AD-Konto NICKIS \ kerberos500 auf die Registerkarte Konto, scrollen Sie nach unten und aktivieren Sie das Kontrollkästchen "Kerberos DES-Verschlüsselungstypen für dieses Konto verwenden".

Aktivieren Sie dann die DES-Verschlüsselung selbst auf der AD-Domänenebene über Gruppenrichtlinien. Führen Sie dazu Folgendes aus:

  1. Öffnen Sie die Gruppenrichtlinien-Verwaltungskonsole (GPMC).
  2. Standardrichtlinienobjekt für Domänenrichtlinien bearbeiten. (Es ist sicherer, stattdessen ein neues Gruppenrichtlinienobjekt auf Domänenebene zu erstellen und zu bearbeiten, aber das bleibt Ihnen überlassen.)
  3. Navigieren Sie zu Computerkonfiguration & gt; Richtlinien & gt; Windows-Einstellungen & gt; Sicherheitseinstellungen & gt; Lokale Richtlinien & gt; Sicherheitsoptionen & gt; "Netzwerksicherheit: Konfigurieren Sie die für Kerberos zulässigen Verschlüsselungsarten" und aktivieren Sie die beiden Kontrollkästchen für DES_CBC_MD5 und DES_CBC_MD5. WICHTIG: Stellen Sie in derselben Gruppenrichtlinie sicher, dass die Kontrollkästchen für RC4, AES128 und AES256 ebenfalls aktiviert sind. Diese Verschlüsselungstypen werden nicht für Tickets auf Ihrer Website verwendet, sie werden jedoch für alles andere in der Domäne verwendet. und OK, Sie sind weit von den Dialogfeldern entfernt und schließen die GPMC.
  4. Führen Sie den Befehl 'gpupdate / force' sowohl auf dem DC-Server als auch auf dem Client aus.
  5. Führen Sie 'klist purge' auf dem Client aus, um alle Kerberos-Tickets zu löschen.
  6. Löschen Sie im Webbrowser den Cache und löschen Sie alle Cookies.
  7. Stellen Sie sicher, dass der DC-Server den eingehenden Port 8080 TCP zulässt.
  8. Probieren Sie es erneut.

Referenz: Windows-Konfigurationen für Kerberos Unterstützter Verschlüsselungstyp

EDIT 3: Vermeiden Sie Kerberos KDC (der DC), Client und Server auf dem gleiche Maschine. Das ist ein klassisches Rezept, um den "Token Fehler Fehler" zu bekommen, auch wenn Sie alles andere richtig gemacht haben.

EDIT 4: (Endgültige Aktualisierung, die vom OP verifiziert wurde): Guckte auf die neue ktpass Keytab Creation Ausgabe, und ich sah dies: Targeting Domain Controller: WIN-OVV6VHBGIB8.fusionis.life. Jetzt ist der definierte SPN in der Keytab HTTP / kerberos500.nickis.life. Der AD-Domänenname unterscheidet sich von dem von Ihnen definierten SPN. Dies funktioniert nicht, es sei denn, Sie haben eine Art von Trust-Setup zwischen diesen Domänen eingerichtet. Wenn Sie keine Vertrauensstellung haben, müssen Sie stattdessen einen SPN von HTTP / kerberos500.fusionis.life verwenden.

    
T-Heron 15.11.2017, 01:01
quelle
-1

Versuchen Sie Folgendes:

Lösung 1

Führen Sie dies unter Windows cmd:

aus

ksetup / addkdc ksetup / addhosttorealmmap

und legen Sie die SPNEGO-Einstellungen im Browser fest

Lösung 2

Probieren Sie es mit Firefox aus, tun Sie das vorher:

1) Öffnen Sie diese URL in Firefox

über: config

2) Legen Sie Folgendes fest: network.negotiate-auth.trusted-uris

Legen Sie für jede Cluster-DNS-Domäne fest, für die eine ausgehandelte Authentifizierung erforderlich ist (z. B. die HTTP-Authentifizierung für Cluster mit Kerberos-Aktivierung).

Beispiel:

network.negotiate-auth.trusted-uris = .lily.cloudera.com, .solr.cloudera.com

2) Legen Sie Folgendes fest: network.auth.use-sspi = false 3) Starten Sie Firefox neu 4) Sie müssen den Windows isntaller von hier herunterladen:

Ссылка

5) Kopieren Sie die Kerberos-Client-Konfiguration nach hier

C: \ Programme \ MIT \ Kerberos5 \ krb5.ini

6) Erstellen Sie ein Ticket mit dem MIT kerberos GUI-Client

7) Versuchen Sie es erneut mit Firefox

Ich hoffe, es kann helfen.

    
DeadSpock 14.11.2017 23:10
quelle