Segurança : Cisco Identity Services Engine

Configurar o apoio SCEP para BYOD

29 Julho 2013 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Inglês (11 Abril 2013) | Feedback

Introdução

Este documento descreve as etapas e as advertências exigidas a fim distribuir com sucesso o serviço do registro do dispositivo de rede de Microsoft (NDE) e o protocolo simple certificate enrollment (SCEP) para Bring seu próprio dispositivo (BYOD).

Contribuído por Pula de Todd, engenheiro de TAC da Cisco.

Pré-requisitos

Requisitos

A Cisco recomenda que você tenha conhecimento destes tópicos:

  • Liberação 1.1.1 do Identity Services Engine (ISE) ou mais atrasado.
  • Microsoft Windows server 2008 R2.
  • Public Key Infrastructure (PKI) e Certificados.

Componentes Utilizados

  • Liberação 1.1.1 ISE ou mais atrasado
  • Windows Server 2008 R2 SP1 com os hotfix KB2483564 e KB2633200 instalados

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.

O relativo à informação aos serviços certificados de Microsoft é fornecido como guia especificamente para Cisco BYOD. Refira por favor TechNet de Microsoft como a fonte definitiva de verdade para a autoridade de certificação MS, o serviço do registro do dispositivo de rede (NDE), e configurações do servidor relativas SCEP.

Informações de Apoio

Um dos benefícios da aplicação ISE-permitida BYOD de Cisco é capacidade dos utilizadores finais ' para executar o registo do dispositivo do autosserviço. Isto elimina a sobrecarga administrativa no TI a fim distribuir credenciais de autenticação e permitir dispositivos na rede. No centro de BYOD a solução é o processo de provisionamento do suplicante da rede, que procura distribuir os Certificados necessários aos dispositivos possuídos empregado. A fim satisfazer esta exigência, um Microsoft Certificate Authority (CA) pode ser configurado para automatizar o processo do certificado de registro com o SCEP. O SCEP foi usado por anos em ambientes do Virtual Private Network (VPN) para facilitar o certificado de registro e a distribuição aos clientes de acesso remoto e ao Roteadores. A habilitação da funcionalidade SCEP em um server R2 de Windows 2008 exige a instalação dos NDE. Durante a instalação do papel NDE, o servidor de Web do Internet Information Services de Microsoft (IIS) é instalado igualmente. O IIS é usado para terminar o HTTP ou as requisições de registro e as respostas HTTPS SCEP entre nó da política de CA e ISE. O papel NDE pode ser instalado em CA atual, ou pode ser instalado em um servidor membro. Em um desenvolvimento autônomo, o serviço NDE é instalado em CA existente que inclui o serviço da autoridade de certificação e, opcionalmente, o serviço do registro da Web da autoridade de certificação. Em um desenvolvimento distribuído, o serviço NDE é instalado em um servidor membro. O server distribuído NDE é configurado então para comunicar-se com uma raiz ou uma secundário-raiz ascendente CA. Nesta encenação, as alterações do registro esboçadas neste documento são feitas no server NDE com o molde personalizado e os Certificados que residem em CA ascendente.

Antes que você configure o apoio SCEP para BYOD, assegure-se de que o server de Windows 2008 R2 NDE tenha estes hotfix de Microsoft instalado:

Configurar

Desabilite a exigência da senha do desafio do registro SCEP

À revelia, a aplicação SCEP de Microsoft (MSCEP) usa uma senha do desafio dinâmica para autenticar clientes e valores-limite durante todo o processo do certificado de registro. Com este requisito de configuração no lugar, os usuários devem consultar à Web GUI MSCEP admin no server NDE para gerar uma senha por encomenda. Como parte da requisição de registro, o usuário deve incluir esta senha.

Em um desenvolvimento BYOD, a exigência de uma senha do desafio derrota a finalidade de uma solução do autosserviço do usuário. A fim remover esta exigência, esta chave de registro deve ser alterada no server NDE:

  1. Clique o começo e incorpore o regedit à barra da busca.
  2. Navegue a: Computador > HKEY_LOCAL_MACHINE > SOFTWARE > Microsoft > criptografia > MSCEP > EnforcePassword.
  3. Assegure-se de que o valor de EnforcePassword esteja ajustado a “0" (a opção é "1").

116068-configure-scep-support-byod-01.png

Como estender o comprimento URL no IIS

É possível para o ISE gerar as URL, que são demasiado longas para o servidor de Web IIS. Para evitar este problema, a configuração de IIS da opção pode ser alterada para permitir umas URL mais longas.

Nota: O tamanho de série da pergunta pôde variar o dependente na configuração ISE e de valor-limite. Este comando deve ser incorporado da linha de comando server NDE com privilégios administrativos:


%systemroot%\system32\inetsrv\appcmd.exe set config /section:system.webServer/security/
requestFiltering/requestLimits.maxQueryString:"8192" /commit:apphost

116068-configure-scep-support-byod-02.png

Vista geral do molde de certificado

Os administradores de Microsoft CA podem configurar uns ou vários moldes que são usados para aplicar políticas da aplicação a um grupo comum de Certificados. Estas políticas ajudam a identificar que função o certificado e as chaves associadas devem ser usada. Os valores de política da aplicação são contidos no campo chave prolongado do uso (EKU) do certificado. O autenticador analisa gramaticalmente os valores no campo EKU para assegurar-se de que o certificado apresentado pelo cliente possa ser usado para a função pretendida. Alguns de mais usos comuns incluem a autenticação de servidor, a authenticação do cliente, o IPSec VPN, e o email. Em termos do ISE, os valores mais de uso geral EKU incluem o server e/ou a authenticação do cliente.

Quando você consulta a um Web site seguro do banco, por exemplo, o servidor de Web que processa o pedido está configurado com um certificado com uma política da aplicação da autenticação de servidor. Quando o server recebe um pedido HTTPS, envia seu certificado de autenticação de servidor ao navegador da Web de conexão para a autenticação. O ponto importante aqui é que esta é uma troca unidireccional do server ao cliente. Porque se relaciona ao ISE, um uso comum para um certificado de autenticação de servidor é acesso de GUI admin. O ISE envia seu certificado configurado ao navegador conectado e não o espera receber para trás um certificado do cliente.

Quando se trata dos serviços tais como BYOD que usam o EAP-TLS, a autenticação mútua é preferida. A fim permitir esta troca bidirecional do certificado, o molde usado para gerar o certificado de identidade ISE deve possuir uma política mínima da aplicação da autenticação de servidor. O molde de certificado do servidor de Web satisfaz esta exigência. O molde de certificado que gera os Certificados do valor-limite deve conter uma política mínima da aplicação da authenticação do cliente. O molde do certificado de usuário satisfaz esta exigência. Se você configura o ISE para serviços tais como o ponto Inline do reforço de política (iPEP), o molde usado para gerar o certificado de identidade do server ISE deve conter ambos os atributos da autenticação de cliente e servidor. Isto permite que o admin e os Nós inline autentiquem-se mutuamente. Um melhor prática à prova futura o desenvolvimento ISE é assegurar-se de que os certificados de identidade do server ISE incluam ambos os atributos da autenticação de cliente e servidor. Os moldes do servidor de Web e do usuário de Microsoft CA da opção podem ser reúso ou um molde novo pode ser clonado e criado com o processo esboçado neste documento. Baseado nestas exigências do certificado, a configuração de CA e o ISE resultante e os Certificados do valor-limite devem com cuidado ser planeados a fim minimizar todas as mudanças de configuração não desejada quando instalados em um ambiente de produção.

116068-configure-scep-support-byod-03.png

Configuração do molde de certificado

Como referido na introdução, o SCEP é amplamente utilizado em ambientes do IPSec VPN. Em consequência, a instalação do papel NDE configura automaticamente o server para utilizar o molde do IPsec (pedido autónomo) para o SCEP. Devido a isto, uma das primeiras etapas na preparação de Microsoft CA para BYOD é construir um molde novo com a política correta da aplicação. Em um desenvolvimento autônomo, a autoridade de certificação e os serviços NDE são arranjados no mesmo server. Em consequência, os moldes e as alterações exigidas do registro são contidos ao mesmo server. Em um desenvolvimento distribuído NDE, as alterações do registro são feitas no server NDE; contudo, os moldes reais são definidos no server de CA da raiz ou da secundário-raiz especificados na instalação do serviço NDE.

Estão aqui as etapas usadas a fim configurar o molde de certificado:

  1. Início de uma sessão ao server de CA com usuário admin.
  2. Iniciar > Ferramentas Administrativas > autoridade de certificação do clique.
  3. Expanda os detalhes do server de CA e selecione o dobrador dos moldes de certificado. Este dobrador contem uma lista dos moldes permitidos atualmente.
  4. A fim controlar os moldes de certificado, para clicar com o botão direito no dobrador dos moldes de certificado e para escolher controle.
  5. No console dos moldes de certificado, um número de moldes inativos são indicados.
  6. A fim configurar um molde novo para o uso com SCEP, clicar com o botão direito em um molde que já exista, como o usuário, e escolha o molde duplicado.
  7. Escolha então Windows 2003 ou Windows 2008, dependente do operating system (OS) mínimo de CA no ambiente.
  8. No tab geral, adicionar um nome do indicador, tal como ISE-BYOD e período de validade; deixe todas as outras opções desmarcadas

    Nota: O período de validade do molde deve ser inferior ou igual ao período de validade dos Certificados da raiz e do intermediário de CA.
  9. Clique sobre a aba dos Ramais; clique sobre políticas da aplicação; clique então editam.
  10. O clique adiciona e assegura-se de que a authenticação do cliente esteja adicionada como uma política da aplicação. Clique em OK.
  11. Clique sobre a ABA de segurança, clique adicionam…. Assegure-se de que a conta de serviço SCEP definida na instalação do serviço NDE tenha o controle total do molde. Clique em OK.
  12. Retorne à interface GUI da autoridade de certificação.
  13. Clicar com o botão direito no diretório dos moldes de certificado. Navegue a novo > molde de certificado a emitir.
  14. Selecione o molde ISE-BYOD configurado previamente e clique a APROVAÇÃO.
  15. Alternativamente, permita o molde com o CLI:
    certutil - SetCAtemplates +ISE-BYOD
  16. O molde ISE-BYOD deve agora ser alistado na lista permitida do molde de certificado.

Configuração do registro do molde de certificado

Estão aqui as etapas usadas a fim configurar as chaves de registro do molde de certificado:

  • Conecte aos NDE o server.
  • Clique o começo e incorpore o regedit à barra da busca.
  • Navegue a: Computador > HKEY_LOCAL_MACHINE > SOFTWARE > Microsoft > criptografia > MSCEP.
  • Mude as chaves de EncryptionTemplate, de GeneralPurposeTemplate, e de SignatureTemplate do IPsec (pedido autónomo) ao molde ISE-BYOD criado previamente.
  • Recarregue o server NDE a fim aplicar a configuração de registro.

116068-configure-scep-support-byod-04.png

Configurar o ISE como um proxy SCEP

Em um desenvolvimento BYOD, o valor-limite não se comunica diretamente com o server backend NDE. Em lugar de, o nó da política ISE é configurado como um proxy SCEP e comunica-se com o server NDE em nome dos valores-limite. Os valores-limite comunicam-se diretamente com o ISE. O exemplo IIS no server NDE pode ser configurado para apoiar emperramentos HTTP e/ou HTTPS para os diretórios virtuais SCEP.

Estão aqui as etapas a fim configurar o ISE como um proxy SCEP:

  1. Registro em ISE GUI com credenciais admin.
  2. Clique sobre a administração > Certificados > perfis SCEP CA.
  3. Clique em Add.
  4. Incorpore o nome do servidor e a descrição.
  5. Incorpore a URL para o server SCEP com o IP ou nome de domínio totalmente qualificado (FQDN), por exemplo, http://10.10.10.10/certsrv/mscep/
  6. Clique a Conectividade do teste.
  7. Uma conexão bem sucedida conduz a uma mensagem bem sucedida do PNF-acima da resposta de servidor.
  8. Salvaguarda do clique para aplicar a configuração.
  9. A fim verificar, clique sobre a administração > Certificados > loja do certificado e confirme que o certificado do server RA SCEP NDE estêve transferido automaticamente ao nó ISE.

Troubleshooting

Esta seção fornece informações que podem ser usadas para o troubleshooting da sua configuração.

  • Divida a topologia de rede BYOD em pontos intermediários lógicos a fim ajudar a identificar debugam e capturam pontos ao longo do trajeto entre estes valores-limite - ISE, NDE, e CA.
  • Assegure-se de que o TCP 80 e/ou o TCP 443 estejam permitidos bidirecional entre o ISE e o server NDE.
  • Teste com uma máquina de Windows devido ao registo melhorado do lado do cliente.
  • Monitore registros do aplicativo de servidor de CA e NDE para erros de registro e use Google ou TechNet para pesquisar aqueles erros.
  • Ao longo da fase de teste, use o HTTP para o SCEP a fim facilitar capturas de pacote de informação entre o ISE, os NDE, e o CA.
  • Use a utilidade da descarga TCP no ISE PSN e monitore o tráfego a e do server NDE. Isto é ficado situado sob operações > ferramentas de diagnóstico > ferramentas gerais.
  • Instale Wireshark no server de CA e NDE ou use o PERÍODO no Switches intermediário a fim capturar o tráfego SCEP a e do ISE PSN.
  • Assegure-se de que a corrente de certificado de CA apropriada instalada no nó da política ISE para a autenticação dos certificados de cliente.
  • Assegure-se de que a corrente de certificado de CA apropriada esteja instalada automaticamente nos clientes durante onboarding.
  • Inspecione os certificados de identidade ISE e de valor-limite e confirme que os atributos corretos EKU estam presente.
  • Monitore a autenticação viva entra o ISE GUI para falhas da authentication e autorização.

    Nota: Alguns suplicantes não inicializam uma troca do certificado de cliente se o EKU errado esta presente, por exemplo, um certificado de cliente com o EKU da autenticação de servidor. Conseqüentemente, as falhas de autenticação não puderam estam presente sempre nos registros ISE.
  • Quando os NDE são instalados em um desenvolvimento distribuído, uma raiz ou uma secundário-raiz remota CA estarão designadas pelo nome ou pelo nome de computador de CA na instalação do serviço. O server NDE envia requisições de registro do certificado a este server de CA do alvo. Se o processo de registro do certificado do valor-limite falha, as capturas de pacote de informação (PCAP) puderam mostrar ao retorno do server NDE um erro 404 não encontrado ao nó ISE. Na tentativa de resolver, reinstale o serviço NDE e selecione a opção do nome de computador em vez do nome de CA.

Registo do lado do cliente

Registo ISE

Use estas etapas a fim ver o registro ISE:

  • Navegue à administração > registrando > debugam a configuração do registro e selecionam o nó apropriado da política ISE.
  • Ajuste estes registros para debugar como necessário ou seguir: cliente, abastecimento.
  • Reproduza o problema e documente a informação relevante da semente a fim facilitar procurarar, como o MAC, IP, o usuário, e assim por diante.
  • Navegue às operações > aos registros da transferência e selecione o nó apropriado ISE.
  • Nos registros debugar catalogue, transfira os registros nomeados ise-psc.log ao desktop.
  • Use um editor inteligente, tal como o bloco de notas ++ a fim analisar gramaticalmente os arquivos de registro.
  • Quando a edição foi isolada, a seguir retorne os níveis do registro a seu nível padrão.

NDE que registram e que pesquisam defeitos

Para mais informação, refira os NDE que registram e que pesquisam defeitos a documentação em TechNet.

Informações Relacionadas


Comunidade de Suporte da Cisco - Conversas em Destaque

A Comunidade de Suporte da Cisco é um fórum onde você pode perguntar e responder, oferecer sugestões e colaborar com colegas. Eis aqui algumas das conversas mais importantes apresentadas em nosso fórum.


Document ID: 116068