Sommario

Introduzione

Terminologia

Conoscenze e requisiti

Flusso di rete Kerberos

Flusso di autenticazione Kerberos in WSA

Qual è lo scopo di SPN?

Configurazione server Active Directory

Risoluzione dei problemi relativi a Kerberos con comandi SPN

Esempi di comandi e output SPN

Scenario 1: SPN non trovato

Scenario 2: SPN trovato

Risoluzione dei problemi di Kerberos su WSA

Ulteriori informazioni e riferimenti

Introduzione

Questo documento descrive il protocollo Kerberos utilizzando i ticket per verificare in modo sicuro le identità nei siti Web e nei sistemi Single Sign-On.

Terminologia

WSA

Web Security Appliance

CLI

Interfaccia della riga di comando

ANNUNCIO

Active Directory

SPN

Nome dell'entità servizio

KDC

Centro distribuzione chiavi Kerberos

TGT

Ticket di autenticazione

TGS

Servizio di concessione ticket

HA

Alta disponibilità

VRRP

Protocollo di ridondanza router virtuale

CARPA

Protocollo Common Address Redundancy

Conoscenze e requisiti

- Active Directory e autenticazione.

- Autenticazione e realm su WSA

Flusso di rete Kerberos

Di seguito sono riportati i passaggi di base per l'autenticazione in un ambiente kerberizzato:

1. Il client richiede un ticket di concessione ticket (TGT) dal centro distribuzione chiavi (KDC).

2. Il KDC verifica le credenziali utente del computer client e restituisce un TGT e una chiave di sessione crittografati.

3. Il TGT è crittografato con la chiave segreta TGS (Ticket Granting Service).

4. Il client memorizza il TGT e ne richiede automaticamente uno nuovo alla scadenza.

Per accedere a un servizio o a una risorsa:

1. Il client invia il TGT al TGS insieme al nome dell'entità servizio (SPN) della risorsa desiderata.

2. Il KDC verifica il TGT e controlla i diritti di accesso al computer client dell'utente.

3. Il TGS invia al client una chiave di sessione specifica del servizio.

4. Il client fornisce la chiave di sessione al servizio per provare l'accesso e il servizio concede l'accesso.

Flusso di autenticazione Kerberos in WSA

1. Il client richiede l'accesso a www.google.com tramite WSA.

2. WSA risponde con uno stato HTTP 407, richiedendo l'autenticazione.

3. Il client richiede un ticket di servizio dal server AD per il servizio HTTP/wsa.domain.com utilizzando il TGT ottenuto durante l'aggiunta al dominio.

4. Il server AD convalida il client ed emette un ticket di servizio, se viene eseguito correttamente e viene trovato il nome SPN (Service Principal Name) di WSA, procede al passaggio successivo.

5. Il client invia questo ticket al server di distribuzione Windows.

6. WSA decrittografa il ticket e verifica l'autenticazione.

7. Se l'autenticazione ha esito positivo, il server di sicurezza di Windows verifica i criteri.

8. Il WSA invia una risposta HTTP 200 OK al client se la transazione è consentita.

Qual è lo scopo di SPN?

Un nome SPN (Service Principal Name) identifica in modo univoco un'istanza del servizio nell'autenticazione Kerberos. Collega un'istanza del servizio a un account del servizio, consentendo ai client di richiedere l'autenticazione per il servizio senza che sia necessario il nome dell'account. Ogni account nell'implementazione di un centro distribuzione chiavi (KDC), ad esempio AD o Open LDAP, dispone di un SPN. Sebbene l'SPN identifichi in modo rigoroso un servizio, talvolta viene utilizzato erroneamente per fare riferimento al nome del client (UPN) in scenari in cui il servizio funge anche da client.

In Kerberos un nome SPN identifica in modo univoco un'istanza del servizio all'interno di una rete. Consente ai client di richiedere l'autenticazione per un servizio specifico. L'SPN collega l'istanza del servizio al relativo account, consentendo a Kerberos di autenticare e autorizzare correttamente le richieste di accesso a tale servizio.

Configurazione server Active Directory

- Creare un nuovo account utente o scegliere un account utente esistente da utilizzare

- Registrare l'SPN da utilizzare con l'account utente scelto

- Verificare che non siano registrati SPN duplicati

Suggerimento: Quali sono le differenze tra Kerberos e il servizio di bilanciamento del carico di WSA o tra Traffic Manager e Traffic Shaper? Anziché associare l'SPN per il nome host virtuale HA a un account utente, associare l'SPN per il dispositivo di reindirizzamento del traffico HTTP (ad esempio: LoadBalancer o Traffic Manager) a un account utente in Active Directory.

Risoluzione dei problemi relativi a Kerberos con comandi SPN

Di seguito è riportato un elenco di utili comandi `setspn` per la gestione dei nomi SPN (Service Principal Names) in un ambiente Kerberos. Questi comandi vengono in genere eseguiti da un'interfaccia della riga di comando con privilegi amministrativi in un ambiente Windows.

Elenca SPN per un account specifico:

setspn -L <NomeAccountUtente/Computer>

Elenca tutti gli SPN registrati per l'account specificato.

Aggiungere un SPN a un account:

setspn -A <SPN> <NomeAccountUtente/Computer>

Aggiunge l'SPN specificato all'account specificato.

Eliminare un SPN da un account:

setspn -D <SPN> <NomeAccountUtente/Computer>

Rimuove l'SPN specificato dall'account specificato.

Verificare se un SPN è già registrato:

setspn -Q <SPN>

Controlla se l'SPN specificato è già registrato nel dominio.

Elenca tutti gli SPN nel dominio

setspn -L <Account utente/computer>

Elenca tutti gli SPN nel dominio.

Impostare un SPN per un account computer:

setspn -S <SPN> <NomeAccountUtente/Computer>

Aggiunge un SPN a un account computer, verificando che non vi siano voci duplicate.

Reimposta SPN per un account specifico:

setspn -R <NomeAccountUtente/Computer>

Reimposta gli SPN per l'account specificato, contribuendo a risolvere i problemi SPN duplicati.

Esempi di comandi e output SPN

Gli esempi forniti dimostrano l'utilizzo:

Account utente/computer: vrpserviceuser

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

- Verificare se l'SPN è già associato a un account utente:

setspn -q <SPN>

setspn -q http/proxyha.localdomain

Scenario 1: SPN non trovato

Scenario 2: SPN trovato

- Associare un SPN a un account utente/computer valido:

Sintassi: setspn -s <SPN> <Account utente/computer>

Ad esempio: setspn -s http/proxyha.localdomain utenterprrpserviceutente

- Eliminare/rimuovere un SPN già associato a un

account utente/computer:

Sintassi: setspn -d <SPN> <Account utente/computer>

Ad esempio: setspn -d http/proxyha.localdomain pod1234-wsa0

Verificare che non vi siano SPN duplicati per il nome host virtuale HA, in quanto gli errori possono verificarsi in seguito:

Comando da utilizzare: setspn -x

Di conseguenza, il ticket del servizio Kerberos non viene fornito al client e l'autenticazione Kerberos non riesce.

Attenzione: Se vengono trovati duplicati, rimuoverli utilizzando il comando setspn -d

- Elenca tutti gli SPN associati a un account:

Sintassi: setspn -l <Account utente/computer>

Ad esempio: setspn -l utenterprpserviceuser

Risoluzione dei problemi di Kerberos su WSA

Informazioni che TAC deve ottenere per la risoluzione dei problemi di autenticazione Kerberos

- Dettagli configurazione corrente

- Log di autenticazione (preferibilmente in modalità debug o trace)

- Acquisizioni di pacchetti effettuate (con filtri appropriati):

a) Dispositivo client

b) WSA

- Registri di accesso con l'identificatore di formato personalizzato %m abilitato. Deve essere indicato il meccanismo di autenticazione utilizzato per una transazione specifica.

Suggerimento: Per ulteriori informazioni sull'autenticazione dettagliata, aggiungere questi campi personalizzati ai log degli accessi sui proxy attivi/non attivi

Su GUI WSA Passare a > Amministrazione di sistema > Sottoscrizione log > Log degli accessi > Campi personalizzati > Aggiungere questa stringa per i problemi di autenticazione

indirizzo IP server = %k, indirizzo IP client= %a, Auth-Mech = %m, Auth_Type= %m, Auth_group= %g, Authenticated_Username= %A, Date= %L, Transaction_ID= %I Risposta autenticazione = %1:<a, Auth total = %1:>a;

Snapshot del log degli accessi WSA per i dettagli di autenticazione utente

- Un caso di errore comune è rappresentato da richieste Web con errore "Server non trovato nel database Kerberos":

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

* Connessione in corso () alla porta proxy proxyha.localdomain 3128 (#0)

* Connesso alla porta proxyha.localdomain (10.8.96.30) 3128 (#0)

< HTTP/1.1 407 Autenticazione proxy richiesta

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

< Content-Type: testo/html

gss_init_sec_context() non riuscito: : Server non trovato nel database Kerberos

< Autenticazione proxy: Negoziazione

< Connessione: chiudi

* Il set di connessioni proxy HTTP/1.1 è chiuso.

In questo caso, l'errore indica che il nome dell'entità servizio corrispondente al valore dell'indirizzo proxy proxyha.localdomain non è registrato nel server Active Directory. Per risolvere il problema, è necessario verificare che SPN http/proxyha.localdomain sia registrato nel controller di dominio Active Directory e aggiunto a un account di servizio appropriato.

- Le procedure ottimali per l'implementazione di kerberos sono documentate in questo collegamento ipertestuale:

Procedure ottimali per Secure Web Appliance

Ulteriori informazioni e riferimenti