Inhoud

Inleiding

Terminologie

Kennis en vereisten

Kerberos-netwerkstroom

Kerberos-verificatiestroom in WSA

Wat is het doel van SPN?

Configuratie van Active Directory-server

Problemen oplossen bij Kerberos met SPN-opdrachten

Voorbeelden van SPN-opdrachten en -uitvoer

Scenario 1: SPN niet gevonden

Scenario 2: SPN gevonden

Probleemoplossing voor Kerberos op WSA

Aanvullende informatie en referenties

Inleiding

Dit document beschrijft Kerberos Protocol met behulp van tickets om identiteit veilig te verifiëren in websites en Single Sign-On systemen.

Terminologie

WSA

Web security applicatie

CLI

Opdrachtlijninterface

AD

Active Directory

CENTRIFUGE

Naam van serviceresources

KDC

Kerberos-sleuteldistributiecentrum

TGT

Verificatiekaart

TGS

Tickettoekenningsservice

HA

Hoge beschikbaarheid

VRRP

Virtueel routerredundantieprotocol

KARPER

Gemeenschappelijk Protocol voor adresredundantie

Kennis en vereisten

- Active Directory en verificatie.

- Verificatie en domeinen op WSA

Kerberos-netwerkstroom

Hier zijn de basisstappen voor verificatie in een Kerberos-omgeving:

1. De klant vraagt een Ticket Granting Ticket (TGT) aan bij het Key Distribution Center (KDC).

2. De KDC verifieert de gebruikersreferenties van de client-machine en stuurt een versleutelde TGT- en sessiesleutel terug.

3. De TGT is versleuteld met de sleutel Ticket Granting Service (TGS).

4. De client slaat de TGT op en vraagt automatisch een nieuwe aan wanneer deze vervalt.

Voor toegang tot een service of bron:

1. De klant stuurt de TGT naar de TGS samen met de Service Principal Name (SPN) van de gewenste bron.

2. De KDC verifieert de TGT en controleert de toegangsrechten van de gebruikersclient.

3. De TGS stuurt een servicespecifieke sessiesleutel naar de client.

4. De klant biedt de sessiesleutel aan de dienst om toegang te bewijzen en de dienst verleent toegang.

Kerberos-verificatiestroom in WSA

1. De klant vraagt via de WSA toegang tot www.google.com.

2. De WSA reageert met een HTTP 407-status en vraagt om verificatie.

3. De klant vraagt een servicekaartje aan bij de AD-server voor HTTP/wsa.domain.com-service met behulp van de TGT die het krijgt tijdens domeindeelname.

4. De AD-server valideert de client en geeft een servicekaartje af, indien geslaagd en de SPN (Service Principal Name) van WSA wordt gevonden, gaat het verder naar de volgende stap.

5. De Klant stuurt dit ticket naar de WSA.

6. De WSA decrypteert het ticket en controleert de authenticatie.

7. Als de authentificatie succesvol is, verifieert WSA beleid.

8. De WSA stuurt een HTTP 200 OK-antwoord naar de client als transactie is toegestaan.

Wat is het doel van SPN?

Een Service Principal Name (SPN) identificeert een unieke service instantie in Kerberos-verificatie. Het koppelt een service-instantie aan een service-account, zodat klanten om authenticatie voor de service kunnen vragen zonder de naam van de account te hoeven gebruiken. Elke account in een Key Distribution Center (KDC)-implementatie, zoals AD of Open LDAP, heeft een SPN. Terwijl de SPN strikt een dienst identificeert, wordt het soms ten onrechte gebruikt om naar de cliëntnaam (UPN) te verwijzen in scenario's waar de dienst ook als een cliënt handelt.

In Kerberos identificeert een Service Principal Name (SPN) een unieke service-instantie binnen een netwerk. Hiermee kunnen clients verificatie aanvragen voor een specifieke service. De SPN koppelt de service-instantie naar zijn account, waardoor Kerberos toegangsaanvragen voor die service op de juiste manier kan authenticeren en autoriseren.

Configuratie van Active Directory-server

- Een nieuwe gebruikersaccount maken of een bestaande gebruikersaccount kiezen voor gebruik

- Registreer de te gebruiken SPN tegen de gekozen gebruikersaccount

- Zorg ervoor dat er geen dubbele SPN’s zijn geregistreerd

Tip: Hoe is Kerberos met WSA's achter lastverdeler of een Traffic Manager/Traffic Shaper anders? In plaats van de SPN voor HA Virtual hostname te koppelen aan een gebruikersaccount, koppelt u de SPN voor het HTTP-verkeersomleidingsapparaat (bijvoorbeeld:LoadBalancer of Traffic Manager) aan een gebruikersaccount op de AD.

Problemen oplossen bij Kerberos met SPN-opdrachten

Hier is een lijst van nuttige 'setspan'-opdrachten voor het beheer van Service Principal Names (SPN's) in een Kerberos-omgeving. Deze opdrachten worden doorgaans uitgevoerd vanuit een opdrachtregelinterface met beheerrechten in een Windows-omgeving.

SPN's voor een specifieke account weergeven:

setspan -L <User/ComputerAccountName>

Toont een lijst met alle SPN's die voor de opgegeven account zijn geregistreerd.

Voeg een SPN toe aan een account:

setspan -A <SPN> <User/ComputerAccountName>

Voegt de gespecificeerde SPN aan de bepaalde rekening toe.

Een SPN van een account verwijderen:

setspan -D <SPN> <User/ComputerAccountName>

Verwijdert de gespecificeerde SPN uit de gegeven account.

Controleer of een SPN al is geregistreerd:

setspan -Q <SPN>

Controleert of het opgegeven SPN al is geregistreerd in het domein.

Maak een lijst van alle SPN's in het domein

setspan -L <User/Computer-account>

Een lijst van alle SPNs in het domein.

Stel een SPN in voor een computeraccount:

setspan -S <SPN> <User/ComputerAccountName>

Voegt een SPN toe aan een computeraccount zonder dubbele vermeldingen.

Reset SPN's voor een specifieke account:

setspan -R <User/ComputerAccountName>

Hiermee worden de SPN's voor de opgegeven account hersteld, zodat dubbele SPN-problemen kunnen worden opgelost.

Voorbeelden van SPN-opdrachten en -uitvoer

De verstrekte voorbeelden tonen het gebruik aan:

Gebruikersaccount/computeraccount: vrpreservice-gebruiker

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

- Controleer of SPN al is gekoppeld aan een gebruikersaccount:

setspan -q <SPN>

setspan -q http/proxyha.localdomain

Scenario 1: SPN niet gevonden

Scenario 2: SPN gevonden

- Koppel een SPN aan een geldig gebruikers-/computeraccount:

Syntaxis: setspan -s <SPN> <User/computer account>

Voorbeeld: setspan -s http/proxyha.localdomain

- Een SPN verwijderen/verwijderen dat al aan een spn is gekoppeld

gebruikersaccount/computeraccount:

Syntaxis: setspan -d <SPN> <User/computer account>

Voorbeeld: setspan -d http/proxyha.localdomain pod1234-wsa0

Zorg ervoor dat er geen dubbele SPN's zijn voor de HA virtuele hostname, aangezien fouten later kunnen optreden:

Opdracht voor gebruik: setspan -x

Hierdoor wordt het Kerberos Service-ticket niet aan de client geleverd en mislukt de Kerberos-verificatie.

Voorzichtig: Als er duplicaten worden gevonden, verwijdert u deze met de opdracht setspan -d

- Maak een lijst van alle SPN's die aan een account zijn gekoppeld:

Syntaxis: setspan -l <User/Computer-account>

Voorbeeld: setspan -l vrpserviceuser

Probleemoplossing voor Kerberos op WSA

Informatie TAC moet krijgen bij problemen met kerberos-verificatie

- Huidige configuratiedetails

- Verificatielogboeken (bij voorkeur in debug- of traceermodus)

- Opgenomen pakketopnamen (met geschikte filters):

a) Clientapparaat

b) WSA

- Toegangslogboeken met ingeschakeld %m custom format specifier. Dit moet het authenticatiemechanisme tonen dat voor een specifieke transactie is gebruikt.

Tip: Voor gedetailleerde verificatiedetails kunt u deze aangepaste velden toevoegen aan de toegangslogboeken van werkende/niet-werkende proxy’s voor meer informatie

Op WSA GUI Navigeer naar > Systeembeheer > Log-abonnement > Access logs > Aangepaste velden > Voeg deze string toe voor verificatieproblemen

server-IP-adres = %k, client-IP-adres= %a, auth-mech = %m, auth_type= %m, auth_group= %g, Authenticated_user= %a, date= %L, Transaction_ID= %i audiorespons = %:<a, auditief totaal = %:>a;

Snapshot van WSA-toegangslogboek voor details van gebruikersverificatie

- Een veel voorkomende fout case zijn webverzoeken die falen met "Server niet gevonden in Kerberos database":

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

* Verbinden() met proxy proxyha.localdomain poort 3128 (#0)

* Verbonden met proxyha.localdomain (10.8.96.30) poort 3128 (#0)

< HTTP/1.1.407 proxy-verificatie vereist

< Via: 1.1 pod1234-wsa02.localdomain:80 (Cisco-WSA/10.1.2-003)

< Type inhoud: tekst/html

gss_init_sec_context() is mislukt: : Server niet gevonden in Kerberos database

< Proxy-authenticeren: onderhandelen

< Verbinding: sluiten

* HTTP/1.1 proxy-verbinding gesloten!

In dit geval geeft de fout aan dat de Service Principal Name die correspondeert met de proxy adreswaarde proxyha.localdomain niet is geregistreerd op de Active Directory-server. Om het probleem op te lossen, moet worden bevestigd dat SPN http/proxyha.localdomain is geregistreerd op AD DC en wordt toegevoegd aan een juiste serviceaccount.

- De beste praktijken voor het implementeren van kerberos worden in deze hyperlink gedocumenteerd:

Best practices voor Secure Web applicatie

Aanvullende informatie en referenties