Inhalt

Einführung

Voraussetzungen

Anforderungen

Verwendete Komponenten

Hintergrundinformationen

Kerberos-Interaktion mit der ASA

Konfigurieren

Topologie

Domänencontroller und Anwendungskonfiguration

Domäneneinstellungen

Festlegen des Dienstprinzipalnamens (SPN)

Konfiguration auf der ASA

Überprüfen

Die ASA tritt der Domäne bei

Serviceanfrage

Fehlerbehebung

Cisco Bug-IDs

Zugehörige Informationen

Einführung

In diesem Dokument wird beschrieben, wie WebVPN Single Sign On (SSO) für Anwendungen konfiguriert und Fehler bei diesen behoben werden, die durch Kerberos geschützt sind.

Voraussetzungen

Anforderungen

Cisco empfiehlt, über grundlegende Kenntnisse in folgenden Bereichen zu verfügen:

- CLI-Konfiguration der Cisco Adaptive Security Appliance (ASA) und SSL-VPN-Konfiguration (Secure Socket Layer)

- Kerberos-Services

Verwendete Komponenten

Die Informationen in diesem Dokument basieren auf den folgenden Softwareversionen:

- Cisco ASA Software, Version 9.0 und höher

- Microsoft Windows 7-Client

- Microsoft Windows 2003 Server und höher

Die Informationen in diesem Dokument wurden von den Geräten in einer bestimmten Laborumgebung erstellt. Alle in diesem Dokument verwendeten Geräte haben mit einer leeren (Standard-)Konfiguration begonnen. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die potenziellen Auswirkungen eines Befehls verstehen.

Hintergrundinformationen

Kerberos ist ein Netzwerkauthentifizierungsprotokoll, das es Netzwerkentitäten ermöglicht, sich sicher zu authentifizieren. Dabei wird ein vertrauenswürdiger Drittanbieter, das Key Distribution Center (KDC), verwendet, der den Netzwerkentitäten Tickets gewährt. Diese Tickets werden von den Entitäten verwendet, um den Zugriff auf den angeforderten Service zu überprüfen und zu bestätigen.

Es ist möglich, WebVPN SSO für Anwendungen zu konfigurieren, die durch Kerberos mit der Cisco ASA-Funktion, der Kerberos Constrained Delegation (KCD), geschützt sind. Mit dieser Funktion kann die ASA Kerberos-Tickets im Namen des WebVPN-Portalbenutzers anfordern, während sie auf durch Kerberos geschützte Anwendungen zugreift.

Wenn Sie über das WebVPN-Portal auf solche Anwendungen zugreifen, müssen Sie keine Anmeldeinformationen mehr angeben. Stattdessen wird das Konto verwendet, das für die Anmeldung beim WebVPN-Portal verwendet wurde.

Weitere Informationen finden Sie im Abschnitt Funktionsweise von KCD im ASA-Konfigurationsleitfaden.

Kerberos-Interaktion mit der ASA

Für WebVPN muss die ASA Tickets im Namen des Benutzers anfordern (da der Benutzer des WebVPN-Portals nur Zugriff auf das Portal hat, nicht auf den Kerberos-Service). Dazu verwendet die ASA Kerberos-Erweiterungen für eingeschränkte Delegation. Hier ist der Ablauf:

1. Die ASA tritt der Domäne bei und erhält ein Ticket (Ticket1) für ein Computerkonto mit auf ASA konfigurierten Anmeldeinformationen (kcd-server-Befehl). Dieses Ticket wird in den nächsten Schritten für den Zugang zu Kerberos-Services verwendet.

2. Der Benutzer klickt auf den WebVPN-Portallink für die Anwendung mit Kerberos-Schutz.

3. Die ASA fordert (TGS-REQ) ein Ticket für das Computerkonto mit dem Hostnamen als Principal an. Diese Anforderung umfasst das Feld PA-TGS-REQ mit PA-FOR-USER mit dem Principal als Benutzernamen für das WebVPN-Portal, der in diesem Szenario cisco ist. Das Ticket für den Kerberos-Service aus Schritt 1 dient der Authentifizierung (korrekte Delegation).

4. Als Antwort erhält die ASA ein Identitätsticket (Ticket2) für den WebVPN-Benutzer (TGS_REP) für das Computerkonto. Dieses Ticket wird zum Anfordern von Anwendungstickets für diesen WebVPN-Benutzer verwendet.

5. Die ASA initiiert eine weitere Anfrage (TGS_REQ), um das Ticket für die Anwendung zu erhalten (HTTP/test.kra-sec.cisco.com). Diese Anforderung verwendet erneut das Feld PA-TGS-REQ, dieses Mal ohne das Feld PA-FOR-USER, aber mit dem in Schritt 4 erhaltenen imitierten Ticket.

6. Die Antwort (TGS_REQ) mit dem imitierten Ticket (Ticket3) für die Anwendung wird zurückgegeben.

7. Dieses Ticket wird von der ASA transparent für den Zugriff auf den geschützten Dienst verwendet, und der WebVPN-Benutzer muss keine Anmeldeinformationen eingeben. Für die HTTP-Anwendung wird der SPNEGO-Mechanismus (Simple and Protected GSS-API Negotiation) verwendet, um die Authentifizierungsmethode auszuhandeln, und das richtige Ticket wird von der ASA übergeben.

Konfigurieren

Topologie

Domäne: kra-sec.cisco.com (10.211.0.221 oder 10.211.0.216)

Anwendung Internetinformationsdienste (IIS) 7: test.kra-sec.cisco.com (10.211.0.223)

Domänencontroller (RZ): dc.kra-sec.cisco.com (10.211.0.221 oder 10.211.0.216) - Windows2008

ASA: 10.211.0.162

WebVPN-Benutzername/Kennwort: Cisco/Cisco

Angehängte Datei: asa-join.pcap (erfolgreicher Beitritt zur Domäne)

Angehängte Datei: asa-kerberos-bad.pcap (Service-Anfrage)

Domänencontroller und Anwendungskonfiguration

Domäneneinstellungen

Es wird davon ausgegangen, dass es bereits eine funktionale IIS7-Anwendung gibt, die durch Kerberos geschützt ist (falls nicht, lesen Sie den Abschnitt Erforderliche Komponenten). Sie müssen die Einstellungen für die Benutzerdelegationen überprüfen:

Stellen Sie sicher, dass die funktionale Domänenebene auf Windows Server 2003 (mindestens) erhöht wird. Der Standardwert ist "Windows Server 2000:

Festlegen des Dienstprinzipalnamens (SPN)

Sie müssen jedes Konto im AD mit der richtigen Delegation konfigurieren. Ein Administratorkonto wird verwendet. Wenn die ASA dieses Konto verwendet, kann sie ein Ticket für einen anderen Benutzer (Constrained Delegation) für den jeweiligen Dienst (HTTP-Anwendung) anfordern. Damit dies geschieht, muss die richtige Delegation für die Anwendung/den Dienst erstellt werden.

Um diese Delegierung über die CLI mit der setspn.exe durchzuführen, die Teil der Support-Tools  für Windows Server 2003 Service Pack 1  ist, geben Sie den folgenden Befehl ein:

setspn.exe -A HTTP/test.kra-sec.cisco.com kra-sec.cisco.com\Administrator

Dies weist darauf hin, dass der Administrator-Benutzername das vertrauenswürdige Konto für die Delegation des HTTP-Dienstes unter test.kra-sec.cisco.com ist.

Der SPN-Befehl ist ebenfalls erforderlich, um die Delegation-Registerkarte für diesen Benutzer zu aktivieren. Sobald Sie den Befehl eingegeben haben, wird die Registerkarte Delegation für den Administrator angezeigt. Es ist wichtig, "Use any authentication protocol" zu aktivieren, da "Use Kerberos only" die Erweiterung Constrained Delegation nicht unterstützt.

Auf der Registerkarte Allgemein ist es auch möglich, die Kerberos-Vorauthentifizierung zu deaktivieren. Dies wird jedoch nicht empfohlen, da diese Funktion verwendet wird, um das Rechenzentrum vor Wiederholungsangriffen zu schützen. Die ASA kann mit der Vorabauthentifizierung ordnungsgemäß arbeiten.

Dieses Verfahren gilt auch für die Übertragung des Computerkontos (die ASA wird als Computer in die Domäne integriert, um eine "Vertrauensbeziehung" herzustellen):

Konfiguration auf der ASA

interface Vlan211

nameif inside

security-level 100

ip address 10.211.0.162 255.255.255.0

hostname KRA-S-ASA-05

domain-name kra-sec.cisco.com

dns domain-lookup inside

dns server-group DNS-GROUP

name-server 10.211.0.221

domain-name kra-sec.cisco.com

aaa-server KerberosGroup protocol kerberos

aaa-server KerberosGroup (inside) host 10.211.0.221

kerberos-realm KRA-SEC.CISCO.COM

webvpn

enable outside

enable inside

kcd-server KerberosGroup username Administrator password *****

group-policy G1 internal

group-policy G1 attributes

WebVPN

url-list value KerberosProtected

username cisco password 3USUcOPFUiMCO4Jk encrypted

tunnel-group WEB type remote-access

tunnel-group WEB general-attributes

default-group-policy G1

tunnel-group WEB webvpn-attributes

group-alias WEB enable

dns-group DNS-GROUP

Überprüfen

Die ASA tritt der Domäne bei

Nachdem der Befehl kcd-server verwendet wurde, versucht die ASA, der Domäne beizutreten:

********** START: KERBEROS PACKET DECODE ************

Kerberos: Message type KRB_AS_REQ

Kerberos: Option forwardable

Kerberos: Client Name KRA-S-ASA-05$

Kerberos: Client Realm KRA-SEC.CISCO.COM

Kerberos: Server Name krbtgt

Kerberos: Start time 0

Kerberos: End time -878674400

Kerberos: Renew until time -878667552

Kerberos: Nonce 0xa9db408e

Kerberos: Encryption type rc4-hmac-md5

Kerberos: Encryption type des-cbc-md5

Kerberos: Encryption type des-cbc-crc

Kerberos: Encryption type des-cbc-md4

Kerberos: Encryption type des3-cbc-sha1

********** END: KERBEROS PACKET DECODE ************

In kerberos_recv_msg

In KCD_self_tkt_process_response

********** START: KERBEROS PACKET DECODE ************

Kerberos: Message type KRB_ERROR

Kerberos: Error type: Additional pre-authentication required, -1765328359

(0x96c73a19)

Kerberos: Encrypt Type: 23 (rc4-hmac-md5)

Salt: "" Salttype: 0

Kerberos: Encrypt Type: 3 (des-cbc-md5)

Salt: "KRA-SEC.CISCO.COMhostkra-s-asa-05.kra-sec.cisco.com" Salttype: 0

Kerberos: Encrypt Type: 1 (des-cbc-crc)

Salt: "KRA-SEC.CISCO.COMhostkra-s-asa-05.kra-sec.cisco.com" Salttype: 0

Kerberos: Preauthentication type unknown

Kerberos: Preauthentication type encrypt timestamp

Kerberos: Preauthentication type unknown

Kerberos: Preauthentication type unknown

Kerberos: Server time 1360917305

Kerberos: Realm KRA-SEC.CISCO.COM

Kerberos: Server Name krbtgt

********** END: KERBEROS PACKET DECODE ************

Attempting to parse the error response from KCD server.

Kerberos library reports: "Additional pre-authentication required"

In kerberos_send_request

********** START: KERBEROS PACKET DECODE ************

Kerberos: Message type KRB_AS_REQ

Kerberos: Preauthentication type encrypt timestamp

Kerberos: Option forwardable

Kerberos: Client Name KRA-S-ASA-05$

Kerberos: Client Realm KRA-SEC.CISCO.COM

Kerberos: Server Name krbtgt

Kerberos: Start time 0

Kerberos: End time -878667256

Kerberos: Renew until time -878672192

Kerberos: Nonce 0xa9db408e

Kerberos: Encryption type rc4-hmac-md5

Kerberos: Encryption type des-cbc-md5

Kerberos: Encryption type des-cbc-crc

Kerberos: Encryption type des-cbc-md4

Kerberos: Encryption type des3-cbc-sha1

********** END: KERBEROS PACKET DECODE ************

In kerberos_recv_msg

In KCD_self_tkt_process_response

********** START: KERBEROS PACKET DECODE ************

Kerberos: Message type KRB_AS_REP

Kerberos: Client Name KRA-S-ASA-05$

Kerberos: Client Realm KRA-SEC.CISCO.COM

********** END: KERBEROS PACKET DECODE ************

INFO: Successfully stored self-ticket in cache a6588e0

KCD self-ticket retrieval succeeded.

In kerberos_close_connection

remove_req 0xcc09ad18 session 0x1 id 0

free_kip 0xcc09ad18

kerberos: work queue empty

Die ASA kann der Domäne erfolgreich beitreten. Nach der richtigen Authentifizierung erhält die ASA ein Ticket für den Auftraggeber: Administrator im AS_REP-Paket (Ticket1 in Schritt 1 beschrieben).

Serviceanfrage

Der Benutzer klickt auf den WebVPN-Link:

Die ASA sendet das TGS_REQ für ein imitiertes Ticket mit dem Ticket, das im AS_REP-Paket empfangen wird:

Hinweis: Der PA-FOR-USER-Wert ist cisco (WebVPN-Benutzer). PA-TGS-REQ enthält das Ticket, das für die Kerberos Service Request empfangen wurde (der Hauptname ist der ASA-Hostname).

Die ASA erhält eine richtige Antwort mit dem imitierten Ticket für den Benutzer cisco (Ticket2 in Schritt 4 beschrieben):

Hier ist die Anfrage für das Ticket für den HTTP-Dienst (einige Debuggen werden aus Gründen der Klarheit weggelassen):

KRA-S-ASA-05# show WebVPN kcd

Kerberos Realm: TEST-CISCO.COM

Domain Join   : Complete

find_spn_in_url(): URL - /

build_host_spn(): host - test.kra-sec.cisco.com

build_host_spn(): SPN - HTTP/test.kra-sec.cisco.com

KCD_unicorn_get_cred(): Attempting to retrieve required KCD tickets.

In KCD_check_cache_validity, Checking cache validity for type KCD service

ticket cache name:  and spn HTTP/test.kra-sec.cisco.com.

In kerberos_cache_open: KCD opening cache .

Cache doesn't exist!

In KCD_check_cache_validity, Checking cache validity for type KCD self ticket

cache name: a6ad760 and spn N/A.

In kerberos_cache_open: KCD opening cache a6ad760.

Credential is valid.

In KCD_check_cache_validity, Checking cache validity for type KCD impersonate

ticket cache name:  and spn N/A.

In kerberos_cache_open: KCD opening cache .

Cache doesn't exist!

KCD requesting impersonate ticket retrieval for:

user     : cisco

in_cache : a6ad760

out_cache: adab04f8I

Successfully queued up AAA request to retrieve KCD tickets.

kerberos mkreq: 0x4

kip_lookup_by_sessID: kip with id 4 not found

alloc_kip 0xaceaf560

new request 0x4 --> 1 (0xaceaf560)

add_req 0xaceaf560 session 0x4 id 1

In KCD_cred_tkt_build_request

In kerberos_cache_open: KCD opening cache a6ad760.

KCD_cred_tkt_build_request: using KRA-S-ASA-05 for principal name

In kerberos_open_connection

In kerberos_send_request

********** START: KERBEROS PACKET DECODE ************

Kerberos: Message type KRB_TGS_REQ

Kerberos: Preauthentication type ap request

Kerberos: Preauthentication type unknown

Kerberos: Option forwardable

Kerberos: Option renewable

Kerberos: Client Realm KRA-SEC.CISCO.COM

Kerberos: Server Name KRA-S-ASA-05

Kerberos: Start time 0

Kerberos: End time -1381294376

Kerberos: Renew until time 0

Kerberos: Nonce 0xe9d5fd7f

Kerberos: Encryption type rc4-hmac-md5

Kerberos: Encryption type des3-cbc-sha

Kerberos: Encryption type des-cbc-md5

Kerberos: Encryption type des-cbc-crc

Kerberos: Encryption type des-cbc-md4

********** END: KERBEROS PACKET DECODE ************

In kerberos_recv_msg

In KCD_cred_tkt_process_response

********** START: KERBEROS PACKET DECODE ************

Kerberos: Message type KRB_TGS_REP

Kerberos: Client Name cisco

Kerberos: Client Realm KRA-SEC.CISCO.COM

********** END: KERBEROS PACKET DECODE ************

KCD_unicorn_callback(): called with status: 1.

Successfully retrieved impersonate ticket for user: cisco

KCD callback requesting service ticket retrieval for:

user     :

in_cache : a6ad760

out_cache: adab04f8S

DC_cache : adab04f8I

SPN      : HTTP/test.kra-sec.cisco.com

Successfully queued up AAA request from callback to retrieve KCD tickets.

In kerberos_close_connection

remove_req 0xaceaf560 session 0x4 id 1

free_kip 0xaceaf560

kerberos mkreq: 0x5

kip_lookup_by_sessID: kip with id 5 not found

alloc_kip 0xaceaf560

new request 0x5 --> 2 (0xaceaf560)

add_req 0xaceaf560 session 0x5 id 2

In KCD_cred_tkt_build_request

In kerberos_cache_open: KCD opening cache a6ad760.

In kerberos_cache_open: KCD opening cache adab04f8I.

In kerberos_open_connection

In kerberos_send_request

********** START: KERBEROS PACKET DECODE ************

Kerberos: Message type KRB_TGS_REQ

Kerberos: Preauthentication type ap request

Kerberos: Option forwardable

Kerberos: Option renewable

Kerberos: Client Realm KRA-SEC.CISCO.COM

Kerberos: Server Name HTTP

Kerberos: Start time 0

Kerberos: End time -1381285944

Kerberos: Renew until time 0

Kerberos: Nonce 0x750cf5ac

Kerberos: Encryption type rc4-hmac-md5

Kerberos: Encryption type des3-cbc-sha

Kerberos: Encryption type des-cbc-md5

Kerberos: Encryption type des-cbc-crc

Kerberos: Encryption type des-cbc-md4

********** END: KERBEROS PACKET DECODE ************

In kerberos_recv_msg

In KCD_cred_tkt_process_response

********** START: KERBEROS PACKET DECODE ************

Kerberos: Message type KRB_TGS_REP

Kerberos: Client Name cisco

Kerberos: Client Realm KRA-SEC.CISCO.COM

********** END: KERBEROS PACKET DECODE ************

KCD_unicorn_callback(): called with status: 1.

Successfully retrieved service ticket

for user cisco, spn HTTP/test.kra-sec.cisco.com

In kerberos_close_connection

remove_req 0xaceaf560 session 0x5 id 2

free_kip 0xaceaf560

kerberos: work queue empty

ucte_krb_authenticate_connection(): ctx - 0xad045dd0, proto - http,

host - test.kra-sec.cisco.com

In kerberos_cache_open: KCD opening cache adab04f8S.

Source: cisco@KRA-SEC.CISCO.COM

Target: HTTP/test.kra-sec.cisco.com@KRA-SEC.CISCO.COM

Die ASA erhält das korrekte imitierte Ticket für den HTTP-Service (Ticket3, beschrieben in Schritt 6).

Beide Tickets können überprüft werden. Das erste ist das imitierte Ticket für den Benutzer cisco, das zum Anfordern und Empfangen des zweiten Tickets für den HTTP-Dienst verwendet wird, auf den zugegriffen wird:

KRA-S-ASA-05(config)# show aaa kerberos

Default Principal: cisco@KRA-SEC.CISCO.COM

Valid Starting       Expires              Service Principal

19:38:10 CEST Oct 2 2013 05:37:33 CEST Oct 3 2013 KRA-S-ASA-05@KRA-SEC.CISCO.COM

Default Principal: cisco@KRA-SEC.CISCO.COM

Valid Starting       Expires              Service Principal

19:38:10 CEST Oct 2 2013 05:37:33 CEST Oct 3 2013

HTTP/test.kra-sec.cisco.com@KRA-SEC.CISCO.COM

Dieses HTTP-Ticket (Ticket3) wird für den HTTP-Zugriff (mit SPNEGO) verwendet, und der Benutzer muss keine Anmeldeinformationen angeben.

Fehlerbehebung

Manchmal kann es vorkommen, dass Sie ein Problem der falschen Delegierung haben. Beispielsweise verwendet die ASA ein Ticket, um den Dienst HTTP/test.kra-sec.cisco.com (Schritt 5) anzufordern, aber die Antwort ist KRB-ERROR mit ERR_BADOPTION:

Dies ist ein typisches Problem, das auftritt, wenn die Delegation nicht richtig konfiguriert ist. Die ASA berichtet, dass "KDC die angeforderte Option nicht erfüllen kann":

KRA-S-ASA-05# ucte_krb_get_auth_cred(): ctx = 0xcc4b5390,

WebVPN_session = 0xc919a260, protocol = 1

find_spn_in_url(): URL - /

build_host_spn(): host - test.kra-sec.cisco.com

build_host_spn(): SPN - HTTP/test.kra-sec.cisco.com

KCD_unicorn_get_cred(): Attempting to retrieve required KCD tickets.

In KCD_check_cache_validity, Checking cache validity for type KCD service ticket

cache name: and spn HTTP/test.kra-sec.cisco.com.

In kerberos_cache_open: KCD opening cache .

Cache doesn't exist!

In KCD_check_cache_validity, Checking cache validity for type KCD self ticket

cache name: a6588e0 and spn N/A.

In kerberos_cache_open: KCD opening cache a6588e0.

Credential is valid.

In KCD_check_cache_validity, Checking cache validity for type KCD impersonate

ticket cache name: and spn N/A.

In kerberos_cache_open: KCD opening cache .

Cache doesn't exist!

KCD requesting impersonate ticket retrieval for:

user : cisco

in_cache : a6588e0

out_cache: c919a260I

Successfully queued up AAA request to retrieve KCD tickets.

kerberos mkreq: 0x4

kip_lookup_by_sessID: kip with id 4 not found

alloc_kip 0xcc09ad18

new request 0x4 --> 1 (0xcc09ad18)

add_req 0xcc09ad18 session 0x4 id 1

In KCD_cred_tkt_build_request

In kerberos_cache_open: KCD opening cache a6588e0.

KCD_cred_tkt_build_request: using KRA-S-ASA-05$ for principal name

In kerberos_open_connection

In kerberos_send_request

********** START: KERBEROS PACKET DECODE ************

Kerberos: Message type KRB_TGS_REQ

Kerberos: Preauthentication type ap request

Kerberos: Preauthentication type unknown

Kerberos: Option forwardable

Kerberos: Option renewable

Kerberos: Client Realm KRA-SEC.CISCO.COM

Kerberos: Server Name KRA-S-ASA-05$

Kerberos: Start time 0

Kerberos: End time -856104128

Kerberos: Renew until time 0

Kerberos: Nonce 0xb086e4a5

Kerberos: Encryption type rc4-hmac-md5

Kerberos: Encryption type des3-cbc-sha

Kerberos: Encryption type des-cbc-md5

Kerberos: Encryption type des-cbc-crc

Kerberos: Encryption type des-cbc-md4

********** END: KERBEROS PACKET DECODE ************

In kerberos_recv_msg

In KCD_cred_tkt_process_response

********** START: KERBEROS PACKET DECODE ************

Kerberos: Message type KRB_TGS_REP

Kerberos: Client Name cisco

Kerberos: Client Realm KRA-SEC.CISCO.COM

********** END: KERBEROS PACKET DECODE ************

KCD_unicorn_callback(): called with status: 1.

Successfully retrieved impersonate ticket for user: cisco

KCD callback requesting service ticket retrieval for:

user :

in_cache : a6588e0

out_cache: c919a260S

DC_cache : c919a260I

SPN : HTTP/test.kra-sec.cisco.com

Successfully queued up AAA request from callback to retrieve KCD tickets.

In kerberos_close_connection

remove_req 0xcc09ad18 session 0x4 id 1

free_kip 0xcc09ad18

kerberos mkreq: 0x5

kip_lookup_by_sessID: kip with id 5 not found

alloc_kip 0xcc09ad18

new request 0x5 --> 2 (0xcc09ad18)

add_req 0xcc09ad18 session 0x5 id 2

In KCD_cred_tkt_build_request

In kerberos_cache_open: KCD opening cache a6588e0.

In kerberos_cache_open: KCD opening cache c919a260I.

In kerberos_open_connection

In kerberos_send_request

********** START: KERBEROS PACKET DECODE ************

Kerberos: Message type KRB_TGS_REQ

Kerberos: Preauthentication type ap request

Kerberos: Option forwardable

Kerberos: Option renewable

Kerberos: Client Realm KRA-SEC.CISCO.COM

Kerberos: Server Name HTTP

Kerberos: Start time 0

Kerberos: End time -856104568

Kerberos: Renew until time 0

Kerberos: Nonce 0xf84c9385

Kerberos: Encryption type rc4-hmac-md5

Kerberos: Encryption type des3-cbc-sha

Kerberos: Encryption type des-cbc-md5

Kerberos: Encryption type des-cbc-crc

Kerberos: Encryption type des-cbc-md4

********** END: KERBEROS PACKET DECODE ************

In kerberos_recv_msg

In KCD_cred_tkt_process_response

********** START: KERBEROS PACKET DECODE ************

Kerberos: Message type KRB_ERROR

Kerberos: Error type: KDC can't fulfill requested option, -1765328371

(0x96c73a0d)

Kerberos: Server time 1360917437

Kerberos: Realm KRA-SEC.CISCO.COM

Kerberos: Server Name HTTP

********** END: KERBEROS PACKET DECODE ************

Kerberos library reports: "KDC can't fulfill requested option"

KCD_unicorn_callback(): called with status: -3.

KCD callback called with AAA error -3.

In kerberos_close_connection

remove_req 0xcc09ad18 session 0x5 id 2

free_kip 0xcc09ad18

kerberos: work queue empty

Dies ist im Grunde das gleiche Problem, das in den Captures beschrieben wird - der Fehler ist bei TGS_REQ mit BAD_OPTION.

Wenn die Antwort Success lautet, erhält die ASA ein Ticket für den HTTP/test.kra-sec.cisco.com-Dienst, der für SPNEGO-Aushandlung verwendet wird. Aufgrund des Fehlers wird jedoch der NT LAN Manager (NTLM) ausgehandelt, und der Benutzer muss Anmeldeinformationen angeben:

Stellen Sie sicher, dass die SPN nur für ein Konto registriert ist (Skript aus dem vorherigen Artikel). Wenn Sie diesen Fehler erhalten, KRB_AP_ERR_MODIFIED, bedeutet dies normalerweise, dass der SPN nicht für das richtige Konto registriert ist. Sie sollte für das Konto registriert werden, das zum Ausführen der Anwendung (Anwendungspool auf IIS) verwendet wird.

Wenn Sie diesen Fehler erhalten, KRB_ERR_C_PRINCIPAL_UNKNOWN, bedeutet dies, dass kein Benutzer im Rechenzentrum vorhanden ist (WebVPN-Benutzer: cisco).

Dieses Problem kann auftreten, wenn Sie der Domäne beitreten. Die ASA empfängt AS-REP, schlägt aber auf der LSA-Ebene fehl, mit dem Fehler: STATUS_ACCESS_DENIED:

Um dieses Problem zu beheben, müssen Sie die Vorabauthentifizierung für diesen Benutzer (Administrator) im Rechenzentrum aktivieren/deaktivieren.

Hier einige weitere Probleme, auf die Sie stoßen könnten:

- Beim Beitritt zur Domäne können Probleme auftreten. Wenn der RZ-Server über mehrere Network Interface Controller (NIC)-Adapter (mehrere IP-Adressen) verfügt, stellen Sie sicher, dass die ASA auf alle zugreifen kann, um der Domäne beizutreten (die vom Client basierend auf der DNS-Antwort (Domain Name Server) nach dem Zufallsprinzip ausgewählt wird).

- Legen Sie SPN nicht als HOST/dc.kra-sec.cisco.com für das Administratorkonto fest. Aufgrund dieser Einstellung kann die Verbindung zum Rechenzentrum unterbrochen werden.

- Wenn die ASA der Domäne beitritt, kann überprüft werden, ob das richtige Computerkonto im Rechenzentrum erstellt wurde (ASA-Hostname). Stellen Sie sicher, dass der Benutzer über die richtigen Berechtigungen zum Hinzufügen von Computerkonten verfügt (in diesem Beispiel verfügt der Administrator über die richtigen Berechtigungen).

- Denken Sie an die richtige NTP-Konfiguration (Network Time Protocol) auf der ASA. Standardmäßig nimmt das Rechenzentrum einen 5-minütigen Taktskew an. Dieser Timer kann im Rechenzentrum geändert werden.

- Überprüfen Sie, ob die Kerberos-Verbindung für das kleine Paket UDP/88 verwendet wird. Nach dem Fehler vom Rechenzentrum, KRB5KDC_ERR_RESPONSE_TOO_BIG, wechselt der Client zu TCP/88. Es ist möglich, den Windows-Client zur Verwendung von TCP/88 zu zwingen, ASA verwendet jedoch standardmäßig UDP.

- Gleichstrom: Wenn Sie Richtlinienänderungen vornehmen, denken Sie an gpupdate /force.

- ASA: Testauthentifizierung mit dem Test aaa-Befehl, aber bedenken Sie, dass es sich nur um eine einfache Authentifizierung handelt.

- Um eine Fehlerbehebung auf der DC-Site durchzuführen, ist es hilfreich, Kerberos-Debug zu aktivieren: Aktivieren der Kerberos-Ereignisprotokollierung .

Cisco Bug-IDs

Hier finden Sie eine Liste der relevanten Cisco Bug-IDs:

- Cisco Bug ID CSCsi3224 - ASA schaltet nach dem Empfang des Kerberos-Fehlercodes 52 nicht auf TCP um

- Cisco Bug ID CSCtd92673 - Kerberos-Authentifizierung schlägt fehl, wenn Pre-Authorization aktiviert ist

- Cisco Bug-ID CSCuj19601 - ASA Webvpn KCD - versucht, erst nach einem Neustart bei AD einzutreten

- Cisco Bug ID CSCuh32106 - ASA KCD ist ab 8.4.5 defekt

Zugehörige Informationen

- Über einschränkte Delegation von Kerberos

- Funktionsweise von KCD

- PIX/ASA: Konfigurationsbeispiel für die Kerberos-Authentifizierung und LDAP-Autorisierungsserver-Gruppen für VPN-Client-Benutzer über ASDM/CLI

- Cisco ASA-Serie - Befehlsreferenz

- KDC_ERR_BADOPTION beim Versuch einer eingeschränkten Delegation

- Erzwingen der Verwendung von TCP anstelle von UDP in Windows durch Kerberos

- Technischer Support und Dokumentation - Cisco Systems