Entender os prós e contras da restrição de acesso da máquina

Introdução

Este documento descreve um problema encontrado com a Machine Access Restriction (MAR) e fornece uma solução para o problema.

Pré-requisitos

Com o crescimento dos dispositivos pessoais, é mais importante do que nunca que os administradores de sistema ofereçam uma maneira de restringir o acesso a certas partes da rede apenas aos ativos corporativos. O problema descrito neste documento diz respeito a como identificar com segurança essas áreas de preocupação e autenticá-las sem interrupções na conectividade do usuário.

Requisitos

A Cisco recomenda que você tenha conhecimento de 802.1X para entender completamente este documento. Este documento assume familiaridade com a autenticação 802.1X do usuário e destaca os problemas e as vantagens ligadas ao uso do MAR e, mais geralmente, a autenticação de máquina.

Componentes Utilizados

Este documento não se restringe a versões de software e hardware específicas.

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.

Problema

O MAR basicamente tenta resolver um problema comum inerente à maioria dos métodos atuais e populares do EAP (Extensible Authentication Protocol), ou seja, que a autenticação de máquina e a autenticação de usuário são processos separados e não relacionados.

A autenticação de usuário é um método de autenticação 802.1x familiar à maioria dos administradores de sistema. A ideia é que as credenciais (nome de usuário/senha) sejam fornecidas a cada usuário, e esse conjunto de credenciais representa uma pessoa física (também pode ser compartilhado entre várias pessoas). Portanto, um usuário pode fazer login de qualquer lugar na rede com essas credenciais.

Uma autenticação de máquina é tecnicamente a mesma, mas o usuário geralmente não é solicitado a inserir as credenciais (ou certificado); o computador ou a máquina faz isso por conta própria. Isso exige que a máquina já tenha credenciais armazenadas. O nome de usuário enviado é host/<MyPCHostname>, contanto que sua máquina tenha <MyPCHostname> definido como um nome de host. Em outras palavras, ele envia host/ seguido pelo seu nome de host.

Embora não esteja diretamente relacionado ao Microsoft Windows e ao Cisco Ative Diretory, esse processo será renderizado mais facilmente se a máquina ingressar no Ative Diretory, pois o nome de host do computador é adicionado ao banco de dados do domínio e as credenciais são negociadas (e renovadas a cada 30 dias por padrão) e armazenadas na máquina. Isso significa que a autenticação da máquina é possível a partir de qualquer tipo de dispositivo, mas ela é renderizada de forma muito mais fácil e transparente se a máquina ingressar no Ative Diretory, e as credenciais permanecem ocultas do usuário.

MAR como solução

É fácil dizer que a solução é que o Cisco Access Control System (ACS) ou o Cisco Identity Services Engine (ISE) concluam o MAR, mas há vantagens e desvantagens a serem consideradas antes de implementar isso. Como implementar isso é melhor descrito nos guias de usuário do ACS ou ISE, portanto, este documento simplesmente descreve se deve ou não ser considerado e alguns possíveis obstáculos.

Os profissionais

O MAR foi inventado porque as autenticações de usuário e de máquina são totalmente separadas. Portanto, o servidor RADIUS não pode impor uma verificação em que os usuários devem fazer login a partir de dispositivos de propriedade da empresa. Com o MAR, o servidor RADIUS (ACS ou ISE, no lado da Cisco) impõe, para uma determinada autenticação de usuário, que deve haver uma autenticação de máquina válida nas X horas (normalmente 8 horas, mas isso é configurável) que precede a autenticação de usuário para o mesmo endpoint.

Portanto, uma autenticação de máquina será bem-sucedida se as credenciais da máquina forem conhecidas pelo servidor RADIUS, normalmente se a máquina estiver associada ao domínio, e o servidor RADIUS verificará isso com uma conexão com o domínio. Cabe inteiramente ao administrador de rede determinar se uma autenticação de máquina bem-sucedida fornece acesso total à rede ou apenas um acesso restrito; normalmente, isso pelo menos abre a conexão entre o cliente e o Ative Diretory para que o cliente possa executar ações como renovação da senha do usuário ou download de Objetos de Diretiva de Grupo (GPOs).

Se uma autenticação de usuário vier de um dispositivo onde uma autenticação de máquina não ocorreu nas duas horas anteriores, o usuário será negado, mesmo que o usuário seja normalmente válido.

O acesso total é concedido a um usuário somente se a autenticação for válida e concluída de um ponto de extremidade onde uma autenticação de máquina ocorreu nas últimas duas horas.

Os Contras

Esta seção descreve os contras do uso do MAR. 

Solicitante do MAR e do Microsoft Windows

A ideia por trás do MAR é que, para que uma autenticação de usuário seja bem-sucedida, esse usuário deve ter credenciais válidas e uma autenticação de máquina bem-sucedida também deve ser registrada desse cliente. Se houver algum problema com isso, o usuário não poderá se autenticar. O problema que surge é que esse recurso às vezes pode bloquear inadvertidamente um cliente legítimo, o que força o cliente a reinicializar para recuperar o acesso à rede.

O Microsoft Windows executa a autenticação da máquina apenas no momento da inicialização (quando a tela de logon é exibida); assim que o usuário digita as credenciais do usuário, uma autenticação de usuário é executada. Além disso, se o usuário fizer logoff (retornar à tela de logon), uma nova autenticação de máquina será executada.

Aqui está um exemplo de cenário que mostra por que o MAR às vezes causa problemas:

O usuário X trabalhou o dia todo em seu laptop, que foi conectado por uma conexão sem fio. No fim das contas, ele simplesmente fecha o laptop e sai do trabalho. Isso coloca o notebook em hibernação. No dia seguinte, ele volta ao escritório e abre seu laptop. Agora, ele não consegue estabelecer uma conexão sem fio.

Quando o Microsoft Windows hiberna, ele faz um instantâneo do sistema em seu estado atual, que inclui o contexto de quem estava conectado. Durante a noite, a entrada em cache do MAR para o laptop do usuário expira e é eliminada. No entanto, quando o notebook é ligado, ele não executa uma autenticação de máquina. Em vez disso, ele entra diretamente em uma autenticação de usuário, já que foi isso que a hibernação registrou. A única maneira de resolver isso é desconectar o usuário ou reinicializar o computador.

Embora o MAR seja um bom recurso, ele tem o potencial de causar interrupções na rede. Essas interrupções são difíceis de solucionar até que você compreenda como o MAR funciona; quando você implementa o MAR, é importante educar os usuários finais sobre como desligar corretamente os computadores e fazer logoff de cada máquina no final de cada dia.

Servidores MAR e vários servidores RADIUS

É comum ter vários servidores RADIUS na rede para fins de balanceamento de carga e redundância. No entanto, nem todos os servidores RADIUS suportam um cache de sessão MAR compartilhado. Somente as versões 5.4 e posteriores do ACS e as versões 2.3 e posteriores do ISE suportam a sincronização de cache MAR entre nós. Antes dessas versões, não é possível executar uma autenticação de máquina em um servidor ACS/ISE e executar uma autenticação de usuário em outro, pois eles não correspondem um ao outro.

MAR e switching com fio e sem fio

O cache MAR de muitos servidores RADIUS depende do endereço MAC. É simplesmente uma tabela com o endereço MAC dos laptops e o carimbo de data/hora da última autenticação de máquina bem-sucedida. Dessa forma, o servidor pode saber se o cliente foi autenticado pela máquina nas últimas X horas.

No entanto, o que acontece se você inicializar seu notebook com uma conexão com fio (e, portanto, fazer uma autenticação de máquina a partir do seu MAC com fio) e, em seguida, mudar para a rede sem fio durante o dia? O servidor RADIUS não tem meios de correlacionar seu endereço MAC sem fio com seu endereço MAC com fio e saber que você foi autenticado pela máquina nas últimas X horas. A única maneira é fazer logoff e fazer com que o Microsoft Windows conduza outra autenticação de máquina via conexão sem fio.

Solução

Entre muitos outros recursos, o Cisco AnyConnect tem a vantagem de perfis pré-configurados que acionam a autenticação de máquina e usuário. No entanto, as mesmas limitações vistas com o solicitante do Microsoft Windows são encontradas, com relação à autenticação de máquina ocorrendo apenas quando você faz logoff ou reinicializa.

Além disso, com as versões 3.1 e posteriores do AnyConnect, é possível executar EAP-FAST com encadeamento EAP. Essa é basicamente uma autenticação única, em que você envia dois pares de credenciais, o nome de usuário/senha da máquina e o nome de usuário/senha do usuário, ao mesmo tempo. Assim, o ISE verifica mais facilmente se ambos são bem-sucedidos. Sem cache usado e sem necessidade de recuperar uma sessão anterior, isso apresenta maior confiabilidade.

Quando o PC inicializa, o AnyConnect envia apenas uma autenticação de máquina, pois nenhuma informação de usuário está disponível. No entanto, após o login do usuário, o AnyConnect envia as credenciais da máquina e do usuário simultaneamente. Além disso, se você for desconectado ou desconectar/reconectar o cabo, as credenciais da máquina e do usuário serão novamente enviadas em uma única autenticação EAP-FAST, que difere das versões anteriores do AnyConnect sem encadeamento EAP.

O EAP-TEAP é a melhor solução a longo prazo, pois é feito especialmente para suportar esses tipos de autenticações, mas o EAP-TEAP ainda não é suportado no solicitante nativo de muitos sistemas operacionais até hoje