Inhalt

Einleitung

Terminologie

Kenntnisse und Anforderungen

Kerberos - Netzwerkablauf

Kerberos-Authentifizierungsablauf in WSA

Wozu dient SPN?

Konfiguration des Active Directory-Servers

Fehlerbehebung bei Kerberos mit SPN-Befehlen

Beispiele für SPN-Befehle und -Ausgaben

Szenario 1: SPN nicht gefunden

Szenario 2: SPN gefunden

Fehlerbehebung bei Kerberos auf der WSA

Weitere Informationen und Referenzen

Einleitung

In diesem Dokument wird das Kerberos-Protokoll mithilfe von Tickets zur sicheren Verifizierung von Identitäten auf Websites und in Single-Sign-On-Systemen beschrieben.

Terminologie

WSA

Websicherheits-Appliance

CLI

Kommandozeilenschnittstelle

ANZEIGE

Active Directory

SPN

Name des Dienstprinzipals

KDC

Kerberos-Schlüsselverteilungscenter

TGT

Authentifizierungs-Ticket

TTGS

Dienst für die Ticketgewährung

HA

Hohe Verfügbarkeit

VRRP

Virtual Router Redundancy Protocol

KARBE

Common Address Redundancy Protocol

Kenntnisse und Anforderungen

- Active Directory und Authentifizierung.

- Authentifizierung und Realms auf WSA

Kerberos - Netzwerkablauf

Im Folgenden werden die grundlegenden Schritte für die Authentifizierung in einer Kerberized-Umgebung beschrieben:

1. Der Kunde fordert ein Ticket Granting Ticket (TGT) vom Key Distribution Center (KDC) an.

2. Der KDC überprüft die Anmeldeinformationen des Client-Computerbenutzers und sendet ein verschlüsseltes TGT und einen Sitzungsschlüssel zurück.

3. Der TGT wird mit dem geheimen Schlüssel des Ticket Granting Service (TGS) verschlüsselt.

4. Der Client speichert das TGT und fordert automatisch ein neues an, wenn es abläuft.

Zugriff auf einen Dienst oder eine Ressource:

1. Der Client sendet das TGT zusammen mit dem Service Principal Name (SPN) der gewünschten Ressource an das TGS.

2. Der KDC überprüft das TGT und die Zugriffsrechte des Client-Systems des Benutzers.

3. Das TGS sendet einen dienstspezifischen Sitzungsschlüssel an den Client.

4. Der Client stellt den Sitzungsschlüssel für den Dienst bereit, um den Zugriff zu prüfen, und der Dienst gewährt den Zugriff.

Kerberos-Authentifizierungsablauf in WSA

1. Der Client fordert über die WSA Zugriff auf www.google.com an.

2. Die WSA antwortet mit einem HTTP-407-Status und fordert eine Authentifizierung an.

3. Der Client fordert vom AD-Server ein Dienstticket für den Dienst HTTP/wsa.domain.com mit dem TGT an, das er während des Domänenbeitritts erhält.

4. Der AD-Server validiert den Client und stellt ein Service-Ticket aus. Wenn dies erfolgreich ist und der SPN (Service Principal Name) der WSA gefunden wird, wird mit dem nächsten Schritt fortgefahren.

5. Der Client sendet dieses Ticket an die WSA.

6. Die WSA entschlüsselt das Ticket und überprüft die Authentifizierung.

7. Wenn die Authentifizierung erfolgreich ist, überprüft die WSA die Richtlinien.

8. Die WSA sendet eine HTTP 200 OK-Antwort an den Client, wenn eine Transaktion zulässig ist.

Wozu dient SPN?

Ein Dienstprinzipalname (SPN) identifiziert eine Dienstinstanz in der Kerberos-Authentifizierung eindeutig. Sie verknüpft eine Dienstinstanz mit einem Dienstkonto, sodass Clients die Authentifizierung für den Dienst anfordern können, ohne den Kontonamen zu benötigen. Jedes Konto in einer Implementierung eines Key Distribution Centers (KDC), z. B. AD oder Open LDAP, verfügt über einen SPN. Während der SPN einen Service streng identifiziert, wird er manchmal fälschlicherweise verwendet, um in Szenarien, in denen der Service auch als Client agiert, auf den Client-Namen (UPN) zu verweisen.

In Kerberos identifiziert ein Service Principal Name (SPN) eine Serviceinstanz innerhalb eines Netzwerks eindeutig. Es ermöglicht Clients, die Authentifizierung für einen bestimmten Dienst anzufordern. Der SPN verknüpft die Dienstinstanz mit ihrem Konto, sodass Kerberos Zugriffsanforderungen für diesen Dienst ordnungsgemäß authentifizieren und autorisieren kann.

Konfiguration des Active Directory-Servers

- Erstellen Sie ein neues Benutzerkonto, oder wählen Sie ein vorhandenes Benutzerkonto aus.

- Registrieren Sie den SPN für das ausgewählte Benutzerkonto.

- Stellen Sie sicher, dass keine doppelten SPNs registriert werden.

Tipp: Worin unterscheiden sich Kerberos und WSAs für den Load Balancer oder Traffic Manager/Traffic Shaper? Anstatt den SPN für den virtuellen HA-Hostnamen mit einem Benutzerkonto zu verknüpfen, ordnen Sie den SPN für das HTTP-Datenverkehrsumleitungsgerät (z. B. LoadBalancer oder Traffic Manager) einem Benutzerkonto im AD zu.

Fehlerbehebung bei Kerberos mit SPN-Befehlen

Hier finden Sie eine Liste nützlicher `setspn`-Befehle zur Verwaltung von SPNs (Service Principal Names) in einer Kerberos-Umgebung. Diese Befehle werden in der Regel von einer Befehlszeilenschnittstelle mit Administratorrechten in einer Windows-Umgebung ausgeführt.

Listen Sie SPNs für ein bestimmtes Konto auf:

setspn -L <Benutzer-/Computerkontoname>

Führt alle SPNs auf, die für das angegebene Konto registriert wurden.

Hinzufügen einer SPN zu einem Konto:

setspn -A <SPN> <Benutzer-/Computerkontoname>

Fügt die angegebene SPN dem angegebenen Konto hinzu.

SPN aus einem Konto löschen:

setspn -D <SPN> <Benutzer-/ComputerAccountName>

Entfernt die angegebene SPN aus dem angegebenen Konto.

Überprüfen Sie, ob bereits ein SPN registriert wurde:

setspn -Q <SPN>

Überprüft, ob der angegebene SPN bereits in der Domäne registriert ist.

Alle SPNs in der Domäne auflisten

setspn -L <Benutzer-/Computerkonto>

Führt alle SPNs in der Domäne auf.

Legen Sie einen SPN für ein Computerkonto fest:

setspn -S <SPN> <Benutzer-/Computerkontoname>

Fügt einem Computerkonto einen SPN hinzu, um sicherzustellen, dass keine doppelten Einträge vorhanden sind.

SPNs für ein bestimmtes Konto zurücksetzen:

setspn -R <Benutzer-/Computerkontoname>

Setzt die SPNs für das angegebene Konto zurück und hilft, doppelte SPN-Probleme zu beheben.

Beispiele für SPN-Befehle und -Ausgaben

Die angegebenen Beispiele zeigen die Verwendung:

Benutzer-/Computerkonto: vrrpserviceuser

SPN: http/WsaHostname.com oder http/proxyha.localdomain

- Überprüfen Sie, ob SPN bereits einem Benutzerkonto zugeordnet ist:

setspn -q <SPN>

setspn -q http/proxyha.localdomain

Szenario 1: SPN nicht gefunden

Szenario 2: SPN gefunden

- Ordnen Sie einen SPN einem gültigen Benutzer-/Computerkonto zu:

Syntax: setspn -s <SPN> <Benutzer-/Computerkonto>

Beispiele: setspn -s http/proxyha.localdomain vrrpserviceuser

- Löschen/entfernen Sie einen SPN, der bereits mit einem

Benutzer-/Computerkonto:

Syntax: setspn -d <SPN> <Benutzer-/Computerkonto>

Beispiele: setspn -d http/proxyha.localdomain pod1234-wsa0

Stellen Sie sicher, dass keine doppelten SPNs für den virtuellen HA-Hostnamen vorhanden sind, da Fehler später auftreten können:

Zu verwendender Befehl: setspn -x

Daher wird das Kerberos Service-Ticket dem Client nicht bereitgestellt, und die Kerberos-Authentifizierung schlägt fehl.

Vorsicht: Wenn Duplikate gefunden werden, entfernen Sie Duplikate mit dem Befehl setspn -d

- Listen Sie alle SPNs auf, die einem Konto zugeordnet sind:

Syntax: setspn -l <Benutzer-/Computerkonto>

Beispiele: setspn -l vrpserviceuser

Fehlerbehebung bei Kerberos auf der WSA

Informationen, die das TAC zur Fehlerbehebung bei Kerberos-Authentifizierungsproblemen benötigt

- Aktuelle Konfigurationsdetails

- Authentifizierungsprotokolle (vorzugsweise im Debug- oder Trace-Modus)

- Übernommene Paketerfassungen (mit geeigneten Filtern):

a) Client-Gerät

b) WSA

- Zugriffsprotokolle mit aktivierter benutzerdefinierter Formatangabe %m. Dabei muss der Authentifizierungsmechanismus angezeigt werden, der für eine bestimmte Transaktion verwendet wurde.

Tipp: Um detaillierte Authentifizierungsdetails zu erhalten, fügen Sie diese benutzerdefinierten Felder den Zugriffsprotokollen funktionierender/nicht funktionierender Proxys hinzu.

Auf der WSA-GUI Navigieren Sie zu > Systemverwaltung > Protokoll-Subscription > Zugriffsprotokolle > Benutzerdefinierte Felder > Diese Zeichenfolge für Authentifizierungsprobleme hinzufügen.

Server-IP-Adresse = %k, Client-IP-Adresse= %a, Auth-Mech = %m, Auth_Type= %m, Auth_group= %g, Authenticated_Username= %A, Date= %L, Transaction_ID= %I Auth-Antwort = %:<a, Auth gesamt = %:>a;

WSA-Zugriffsprotokoll-Snapshot für Benutzerauthentifizierungsdetails

- Ein häufiger Fehlerfall sind Web-Anfragen, die mit "Server nicht in der Kerberos-Datenbank gefunden" fehlschlagen:

curl -vx proxyha.localdomain:3128 —proxy-negotiate -u: http://www.google.com/

* Ich möchte eine Verbindung () zum Proxy proxyha.localdomain-Port 3128 (#0) herstellen.

* Verbunden mit proxyha.localdomain (10.8.96.30) Port 3128 (#0)

< HTTP/1.1 407 Proxy-Authentifizierung erforderlich

< Über: 1,1 pod1234-wsa02.localdomain:80 (Cisco-WSA/10.1.2-003)

< Inhaltstyp: Text/HTML

gss_init_sec_context() fehlgeschlagen: : Server nicht in Kerberos-Datenbank gefunden

< Proxy-Authentifizieren: Verhandeln

< Verbindung: schließen

* HTTP/1.1-Proxy-Verbindungssatz geschlossen!

In diesem Fall zeigt der Fehler an, dass der Dienstprinzipalname, der dem Proxyadressenwert proxyha.localdomain entspricht, nicht auf dem Active Directory-Server registriert ist. Um das Problem zu beheben, müssen Sie sicherstellen, dass SPN http/proxyha.localdomain im AD DC registriert und einem entsprechenden Dienstkonto hinzugefügt ist.

- Best Practices für die Implementierung von Kerberos sind in diesem Hyperlink dokumentiert:

Best Practices für sichere Web-Appliances

Weitere Informationen und Referenzen