Não sei se essa ideia é absurda, mas eu queria saber se era possível. Eu tenho um servidor FreeRadius apoiado por um servidor LDAP com uso de EAP-TTLS (ou seja, nome de usuário + senha) para autenticar. Assim, quando os usuários se conectam a um switch 802.1x, eles recebem acesso consultando a conexão do suplicante do nome de usuário+senha com os que estão no servidor LDAP. Esta parte está ok.
Mas o que eu quero é, uma vez que este usuário tenha sido concedido, distinguir entre usuários "regulares" e usuários "admin" por um certificado de cliente que será referenciado como um atributo pelo servidor LDAP para ser baixado de qualquer local adequado (um servidor NFS, por exemplo), mas apenas se esse usuário for do tipo "admin". Então, esse certificado de cliente seria usado (não sei como, essa é a questão) para pedir acesso a outro servidor FreeRadius, que usaria o método EAP-TLS nesse caso para que os usuários "admin" fossem concedidos a outro parte da rede (onde haveria outro tipo de servidores sensatos) enquanto os usuários "regulares" não.
Em resumo: eu quero ter um servidor FreeRadius para conceder acesso aos usuários a uma primeira "visão" da lan e também outro servidor FreeRadius (proxy pelo primeiro?) que daria acesso a outra zona "mais secreta" na lan dependendo no usuário. Isso é possível?
Muito obrigado!!
Em um mundo perfeito, você faria o que está descrevendo usando um método EAP como o TEAP, que oferece suporte ao provisionamento de credenciais em banda (como certificados X509). Infelizmente, o EAP-TEAP e seu predecessor EAP-FAST não tiveram uma implementação generalizada.
Eu sei que você estava usando isso apenas como exemplo, mas eu definitivamente não usaria o NFS. Mesmo que o NFS tenha suporte no host suplicante, a configuração manual seria necessária. Eu diria que HTTP(S) é a escolha mais óbvia para obter acesso aos certificados, dado seu amplo suporte e familiaridade do usuário.
Tentar criar algum tipo de mecanismo de provisionamento pós-autenticação será bastante difícil. É bastante trivial identificar um administrador fazendo login com credenciais e atribuir a ele uma VLAN que fornece acesso apenas a um jardim murado (onde ele pode baixar seu certificado de administrador). A questão é que os próprios jardins murados estão se tornando cada vez mais problemáticos.
Mais sites estão mudando para 'seguro por padrão', o que significa que a tentativa inicial de conexão que um usuário faz provavelmente será por https. Não é possível redirecionar/reescrever o tráfego https da mesma forma que o tráfego http, por isso é difícil direcionar os usuários para a página de destino do jardim murado de maneira perfeita. Se você quisesse experimentar um jardim murado, precisaria verificar se funcionava corretamente para conexões com fio em seu(s) sistema(s) de destino.
Em relação ao uso de diferentes servidores RADIUS para os diferentes métodos EAP, isso não é necessário. O EAP fornece um mecanismo para negociação de métodos. O mesmo módulo EAP no FreeRADIUS pode executar EAP-TTLS ou EAP-TLS. Se o módulo EAP solicitar EAP-TLS por padrão e o suplicante tiver um certificado disponível e tiver o EAP-TLS configurado, o EAP-TLS será executado, caso contrário, o suplicante negociará o EAP-TTLS e o EAP-TTLS será executado.
Honestamente, porém, o provisionamento de credenciais após a autenticação inicial parece um pesadelo para o helpdesk. Mesmo que um administrador consiga acessar, baixar e importar seu certificado, ele precisará reconfigurar manualmente seu suplicante para usá-lo.
Se eu estivesse implementando isso, abandonaria completamente a autenticação baseada em nome de usuário/senha e, em vez disso, usaria um dos instaladores dissolvíveis oferecidos pelo cloudpath (agora Ruckus) e outros. Esses aplicativos temporários podem fornecer certificados de usuário e configurar perfis de segurança para interfaces de rede como parte da mesma operação. Você ofereceria o instalador dissolvível por meio de um site público e direcionaria os usuários para ele durante a integração.
Todos os usuários teriam uma experiência de integração semelhante, mas os administradores poderiam receber um certificado que os identificasse como tal, seja por meio de um OID especial ou usando uma CA intermediária diferente.