Segurança e VPN : WebVPN / SSL VPN

A integração WebVPN SSO com Kerberos forçou o exemplo de configuração da delegação

19 Setembro 2015 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Inglês (22 Agosto 2015) | Feedback

Introdução

Este documento descreve como configurar sobre e pesquisar defeitos o único sinal WebVPN (SSO) para os aplicativos que são protegidos pelo Kerberos.

Contribuído por Michal Garcarz, engenheiro de TAC da Cisco.

Pré-requisitos

Requisitos

Cisco recomenda que você tem o conhecimento básico destes assuntos:

  • Configuração de CLI do dispositivo de Cisco Securit (ASA) e configuração de VPN adaptáveis do Secure Socket Layer (SSL)
  • Serviços de kerberos

Componentes Utilizados

As informações neste documento são baseadas nestas versões de software:

  • Software de Cisco ASA, versão 9.0 e mais recente
  • Cliente de Microsoft Windows 7
  • Server de Microsoft Windows 2003 e mais tarde

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a sua rede estiver ativa, certifique-se de que entende o impacto potencial de qualquer comando.

Informações de Apoio

O Kerberos é um protocolo de autenticação de rede que permita que as entidades de rede autentiquem entre si em uma maneira segura. Usa uma terceira parte confiada, o Key Distribution Center (KDC), que conceda bilhetes às entidades de rede. Estes bilhetes são usados pelas entidades a fim verificar e confirmar o acesso ao serviço pedido.

É possível configurar WebVPN SSO para os aplicativos que são protegidos pelo Kerberos com a delegação chamada característica de Cisco ASA Kerberos Constrained (KCD). Com esta característica, o ASA puder pedir bilhetes do Kerberos em nome do usuário portal WebVPN, quando ele os aplicativos de acessos protegidos pelo Kerberos.

Quando você alcança tais aplicativos através do portal WebVPN, você não precisa de fornecer anymore nenhumas credenciais; em lugar de, a conta que foi usada a fim registrar no portal WebVPN é usada.

Refira a compreensão como KCD trabalha a seção do manual de configuração ASA para mais informação.

Interação do Kerberos com o ASA

Para o WebVPN, o ASA deve pedir bilhetes em nome do usuário (porque o usuário portal WebVPN tem o acesso somente ao portal, não a serviço de kerberos). Para o esse, o ASA usa Ramais do Kerberos para a delegação forçada. Está aqui o fluxo:

  1. O ASA junta-se ao domínio e obtém-se um bilhete (Ticket1) para uma conta do computador com as credenciais configuradas em ASA (comando do kcd-server). Este bilhete é usado nas próximas etapas para o acesso aos serviços de kerberos.

  2. O usuário clica o link portal WebVPN para o aplicativo Kerberos-protegido.

  3. O ASA pede (TGS-REQ) um bilhete para a conta do computador com seu hostname como o principal. Este pedido inclui o campo PA-TGS-REQ com o PA-FOR-USER com o principal como o username do portal WebVPN, que é Cisco nesta encenação. O bilhete para o serviço de kerberos de etapa 1 é usado para a autenticação (delegação correta).

  4. Como uma resposta, o ASA recebe um bilhete encarnado (Ticket2) em nome do usuário WebVPN (TGS_REP) para a conta do computador. Este bilhete é usado a fim pedir bilhetes do aplicativo em nome deste usuário WebVPN.

  5. O ASA inicia um outro pedido (TGS_REQ) a fim obter o bilhete para o aplicativo (HTTP/test.kra-sec.cisco.com). Este pedido usa outra vez o campo PA-TGS-REQ, esta vez sem o campo PA-FOR-USER, mas com o bilhete encarnado recebido em etapa 4.

  6. A resposta (TGS_REQ) com o bilhete encarnado (Ticket3) para o aplicativo é retornada.

  7. Este bilhete é usado transparentemente pelo ASA a fim alcançar o serviço protegido, e o usuário WebVPN não precisa de incorporar nenhumas credenciais. Para o aplicativo HTTP, o mecanismo simples e protegido da negociação GSS-API (SPNEGO) é usado a fim negociar o método de autenticação, e o bilhete correto é passado pelo ASA.

Configurar

Topologia

Domínio: kra-sec.cisco.com (10.211.0.221 ou 10.211.0.216)

Aplicativo 7 do Internet Information Services (IIS): test.kra-sec.cisco.com (10.211.0.223)

Controlador de domínio (DC): dc.kra-sec.cisco.com (10.211.0.221 ou 10.211.0.216) - Windows2008

ASA: 10.211.0.162

Nome de usuário de VPN da Web/senha: Cisco/Cisco

Arquivo anexado: asa-join.pcap (bem sucedido se junte ao domínio)

Arquivo anexado: asa-kerberos-bad.pcap (pedido para o serviço)

Controlador de domínio e configuração do aplicativo

Ajustes do domínio

Supõe-se que há já um aplicativo IIS7 funcional protegido pelo Kerberos (se não, leia a seção das condições prévias). Você deve verificar os ajustes para ver se há as delegações dos usuários:

Assegure-se de que o nível funcional do domínio esteja levantado para Windows Server 2003 (pelo menos). O padrão é Windows Server 2000:

Ajuste o nome principal do serviço (SPN)

Você deve configurar toda a conta no AD com a delegação correta. Uma conta de administrador é usada. Quando os usos ASA que explicam, ele puderem pedir um bilhete em nome de um outro usuário (delegação forçada) para o serviço específico (aplicativo HTTP). Para que isto ocorra, a delegação correta deve ser criada para o aplicativo/serviço.

A fim fazer esta delegação através do CLI com o setspn.exe, que é parte do WindowsServer 2003 ferramentas de suporte do pacote de serviços 1, incorpore este comando:

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

Isto indica que o nome de usuário de administrador é confiado esclarece a delegação do serviço HTTP em test.kra-sec.cisco.com.

O comando SPN é igualmente necessário a fim ativar a aba da delegação para esse usuário. Uma vez que você incorpora o comando, a aba da delegação para o administrador aparece. É importante permitir o “uso todo o protocolo de autenticação,” porque do “o Kerberos uso somente” não apoia a extensão forçada da delegação.

No tab geral, é igualmente possível desabilitar a PRE-autenticação do Kerberos. Contudo, isto não é recomendado, porque esta característica é usada a fim proteger o DC contra ataques de replay. O ASA pode trabalhar com PRE-autenticação corretamente.

Este procedimento igualmente aplica-se com delegação para a conta do computador (o ASA é trazido no domínio como um computador a fim estabelecer um relacionamento da “confiança”):

Configuração no 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

Verificar

O ASA junta-se ao domínio

Depois que o comando do kcd-server é usado, o ASA tenta juntar-se ao domínio:

********** 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

O ASA pode juntar-se com sucesso ao domínio. Após a autenticação correta, o ASA recebe um bilhete para o principal: Administrador no pacote AS_REP (Ticket1 descrito em Step1).

Pedido para o serviço

O link dos cliques WebVPN do usuário:

O ASA envia o TGS_REQ para um bilhete encarnado com o bilhete que é recebido no pacote AS_REP:

Nota: O valor PA-FOR-USER é Cisco (usuário WebVPN). PA-TGS-REQ contém o bilhete recebido para o pedido do serviço de kerberos (o hostname ASA é o principal).

O ASA obtém uma resposta correta com o bilhete encarnado para o usuário Cisco (Ticket2 descrito em etapa 4):

Está aqui o pedido para o bilhete para o serviço HTTP (algum debuga é omitido para maior clareza):

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

O ASA recebe o bilhete encarnado correto para o serviço HTTP (Ticket3 descrito na etapa 6).

Ambos os bilhetes podem ser verificados. Primeiro é o bilhete encarnado para o usuário Cisco, que é usado a fim pedir e receber o segundo bilhete para o serviço HTTP que é alcançado:

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

Este bilhete HTTP (Ticket3) é usado para o acesso HTTP (com SPNEGO), e o usuário não precisa de fornecer todas as credenciais.

Troubleshooting

Às vezes você pôde encontrar um problema da delegação incorreta. Por exemplo, o ASA usa um bilhete a fim pedir o serviço HTTP/test.kra-sec.cisco.com (etapa 5), mas a resposta é KRB-ERROR com ERR_BADOPTION:

Este é um problema típico encontrado quando a delegação não é configurada corretamente. O ASA relata que o “KDC não pode cumprir a opção solicitada”:

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

Este é basicamente o mesmo problema que é descrito nas captações - a falha está em TGS_REQ com BAD_OPTION.

Se a resposta é sucesso, a seguir o ASA recebe um bilhete para o serviço HTTP/test.kra-sec.cisco.com, que é usado para a negociação SPNEGO. Contudo, devido à falha, o gerenciador de LAN de NT (NTLM) é negociado, e o usuário deve fornecer credenciais:

Certifique-se de que o SPN está registrado para uma conta somente (script do artigo precedente). Quando você recebe este erro, KRB_AP_ERR_MODIFIED, significa geralmente que o SPN não está registrado para a conta correta. Deve ser registrado para a conta que é usada a fim executar o aplicativo (pool do aplicativo no IIS).

Quando você recebe este erro, KRB_ERR_C_PRINCIPAL_UNKNOWN, significa que não há nenhum usuário no DC (usuário WebVPN: Cisco).

Você pôde encontrar este problema quando você se junta ao domínio. O ASA recebe AS-REP, mas falha no nível LSA com o erro: STATUS_ACCESS_DENIED:

A fim fixar este problema, você deve permitir/autenticação do desabilitação no DC para esse usuário (administrador).

Estão aqui alguns outros problemas que você pôde encontrar:

  • Pôde haver uns problemas quando você se junta ao domínio. Se o server DC tem adaptadores do controlador da relação de rede múltipla (NIC) (endereços IP de Um ou Mais Servidores Cisco ICM NT múltiplos), certifique-se de que o ASA pode alcançar todo a fim se juntar ao domínio (escolhido aleatoriamente pelo cliente baseado na resposta do Domain Name Server (DNS)).

  • Não ajuste SPN como o HOST/dc.kra-sec.cisco.com para a conta de administrador. É possível perder a Conectividade ao DC devido a esse ajuste.

  • Depois que o ASA se junta ao domínio, é possível verificar que a conta correta do computador está criada no DC (hostname ASA). Certifique-se de que o usuário tem as permissões correta a fim adicionar contas do computador (neste exemplo, o administrador tem as permissões correta).

  • Recorde a configuração correta do Network Time Protocol (NTP) no ASA. À revelia, o DC aceita um enviesamento minuto do pulso de disparo cinco. Esse temporizador pode ser mudado no DC.

  • Verifique que Conectividade do Kerberos para o pacote pequeno UDP/88 está usado. Após o erro do DC, KRB5KDC_ERR_RESPONSE_TOO_BIG, o cliente comuta a TCP/88. É possível forçar o cliente do Windows a usar TCP/88, mas o ASA usará o UDP à revelia.

  • DC: quando você faz alterações de política, recorde o gpupdate /force.

  • ASA: a autenticação de teste com o comando aaa do teste, mas recorda que é somente uma autenticação simples.

  • A fim pesquisar defeitos no local DC, é útil permitir o Kerberos debuga: Como permitir o logging de evento do Kerberos

Bug da Cisco ID

Está aqui uma lista do Bug da Cisco relevante ID:

  • Identificação de bug Cisco CSCsi32224 - O ASA não comuta ao TCP após ter recebido o código de erro 52 do Kerberos
  • Identificação de bug Cisco CSCtd92673 - A autenticação de Kerberos falha com o PRE-AUTH permitido
  • Identificação de bug Cisco CSCuj19601 - ASA Webvpn KCD - tentando juntar-se ao AD somente depois a repartição
  • Identificação de bug Cisco CSCuh32106 - O ASA KCD é quebrado em 8.4.5 avante

Informações Relacionadas


Discussões relacionadas da comunidade de suporte da Cisco

A Comunidade de Suporte da Cisco é um fórum onde você pode perguntar e responder, oferecer sugestões e colaborar com colegas.


Document ID: 116722