802.1x valida automaticamente o certificado em clientes windows

Question

Estamos implantando uma rede sem fio usando o NAC do Windows Server 2008 como um servidor RADIUS. Quando o Windows XP ou 7 clientes se conectam, eles inicialmente não conseguem se conectar.

Para permitir que o cliente se conecte, precisamos adicionar a rede manualmente e desmarcar a opção "Validar certificado do servidor", conforme mostrado na captura de tela abaixo.

Alguém sabe de uma maneira de evitar ter que fazer isso? Estamos perfeitamente dispostos a comprar um certificado da Verisign, Thwarte, etc, se ele ajudar, mas tiver tentado o nosso certificado SSL curinga Comodo, que não o corrigiu.

Essas máquinas pertencem aos usuários finais, por isso não podemos controlar facilmente as configurações com políticas de grupo ou hacks de registro.

    

Answer 1

Você precisa distribuir o certificado do seu servidor RADIUS (se foi auto-assinado) ou o certificado da Autoridade de Certificação que o assinou para seus clientes.

Agora você está dizendo aos seus clientes (ou suplicantes no 802.1X-ese) para verificar o caminho de confiança do certificado do seu servidor RADIUS. Não sei como você gerou seu par de chaves pública e privada para seu servidor RADIUS, mas, em geral, ele será auto-assinado ou assinado por uma autoridade de certificação. Por sua vez, a chave pública da autoridade de certificação de assinatura será distribuída aos clientes, por meio de GPOs, Serviços de Certificados do Active Directory ou foi incluída pela Microsoft no repositório da Autoridade de Certificação Raiz Confiável.

Does anyone know of a way to avoid having to do this? We are perfectly willing to buy a certificate from Verisign, Thwarte, etc if it will help but have tried our Comodo wildcard SSL certificate which hasn't fixed it.

Não é uma configuração recomendada que uma CA raiz externa assine o certificado do seu servidor RADIUS.

Isso é da documentação do FreeRADIUS, mas espero que seja igual válido para a implementação da Microsoft:

In general, you should use self-signed certificates for 802.1x (EAP)
authentication. When you list root CAs from other organizations in
the "CA_file", you permit them to masquerade as you, to authenticate
your users, and to issue client certificates for EAP-TLS.

These machines belong to the end users so we can't easily control settings with group policy or registry hacks.

Bem, há o seu problema! É fácil distribuir certificados usando GPOs. Por que isso não é uma opção no seu caso? Descobrindo isso, faça seu próprio certificado de estrela (que é assinado por uma CA raiz), você poderia assinar o certificado do seu servidor RADIUS com?

EDITAR: Infelizmente, o BYOD e o WPA2-Enterprise não são projetados para funcionar juntos. Você tem três opções:

1. Configure seus clientes para não verificar o caminho de confiança do certificado do seu servidor RADIUS (ou seja, desmarque a caixa que diz "validar certificados do servidor").
2. Obtenha o certificado do seu servidor RADIUS assinado por uma autoridade de certificação "Externa" cujo certificado de assinatura é distribuído no repositório da Autoridade de Certificação Raiz Confiável (como VeriSign, Comodo, etc.).
3. Configure algum tipo de portal cativo que atue como suplicante em nome de seus clientes.

As desvantagens das duas primeiras opções é que ele abre seu esquema 802.1X até ataques MiTM. Eu poderia criar meu próprio servidor RADIUS e interceptar as credenciais AD do seu usuário. Não é uma configuração ideal, mas seu departamento precisará fazer a análise de risco. Se você seguir esse caminho, certifique-se de documentar para fins de CYA.

Do ponto de vista de segurança, a melhor opção é configurar um portal cativo. Os alunos podem usar seus dispositivos BYOD para se conectar e acessar o portal, passar suas credenciais de autenticação de usuário para o portal e o portal pode então conversar com o servidor RADIUS.

Eduroam é outra escolha popular para organizações educacionais.

    

Answer 2

Eu sei que este post é realmente antigo, mas isso é semelhante ao meu problema, exceto que na semana passada, qualquer cliente pode se conectar à minha rede sem fio e esta semana não conseguirá. Eu tenho um Aruba EOL 3200 com 8 pontos de acesso. Os clientes windows / android / iphone puderam se conectar com a verificação do 802.1x em relação a um banco de dados local baseado em Aruba com um nome de usuário. Esta semana, quando entro, noto que meu telefone não consegue se conectar ao wireless. Então meu laptop do Windows 10 não pôde conectar (ambos se conectaram antes). Somente clientes que não se desconectaram da rede ainda podiam acessá-lo. Isso só acontece com o ssid 802.1x (pessoal) e não com o ssid PSK (para convidados). Depois, verifiquei que a única maneira de um computador Windows se conectar a isso é desmarcar a opção "verificar a identidade do servidor validando o certificado" ao adicionar manualmente o perfil. Dispositivos Android ainda não conseguem se conectar.

    

Answer 3

Acabei de implantar uma configuração muito semelhante a esta semana, para fornecer acesso à Internet a um evento de acampamento de uma semana. Esta é a abordagem que usei e algumas lições aprendidas:

Primeiro, usei vários SSIDs para fornecer a rede principal no WPA2-Enterprise e uma rede aberta para inscrição do usuário. A rede aberta redireciona para um portal cativo personalizado (usando HTTPS e um certificado normal emitido por uma autoridade de certificação) onde os usuários se inscreveram e forneceram informações de pagamento. Após o pagamento ser concluído, os usuários são habilitados no banco de dados RADIUS e podem se reconectar ao SSID WPA2-Enterprise para ficar on-line.

Desde que eu tinha um prazo difícil para colocar tudo em prática, ele só foi testado com Android e iOS, e nenhum deles teve problemas reais. Na produção, aprendi rapidamente que o Windows não gostou nada disso.

• O Windows XP precisava do SP3 para usar a rede segura, então mantive uma cópia local como um download direto no portal cativo. Um usuário realmente apareceu com o XP SP2 e teve que ser atualizado.
• O Windows XP, Vista e 7 se recusaram a se conectar com o nome de usuário e a senha, mas nunca reclamaram especificamente sobre o certificado do servidor. Eu descobri que esta foi a causa por tentativa e erro com o primeiro usuário do Windows para se inscrever. Na verdade, a configuração manual do perfil da rede foi bem direta quando o problema foi identificado.
• O Windows 8, o iOS e a versão GNOME / Ubuntu do NetworkManager foram solicitados sobre o certificado do servidor RADIUS, mas permitiram que os usuários aceitassem o certificado e se conectassem.
• A versão do KDE do NetworkManager nunca tentou conexão sem configuração manual, e os padrões escolhidos estavam errados. Felizmente, apenas um usuário apareceu com essa configuração específica.
• Ninguém solicitou suporte para o Mac OS X. Mais tarde, soube que os clientes do Mac OS X não tinham problemas.

Para evitar todo esse problema, na próxima iteração (ou seja, no próximo ano), pretendo oferecer a instalação do certificado do servidor diretamente do portal cativo, para que os usuários (principalmente usuários do Windows) não tenham um problema de login no rede segura.