No meu log de eventos, quando meu roteador tenta usar o Radius para authetnicate, recebo o seguinte:
"""The user could not be authenticated using Challenge Handshake Authentication Protocol (CHAP). A reversibly encrypted password does not exist for this user account. To ensure that reversibly encrypted passwords are enabled, check either the domain password policy or the password settings on the user account. """
No entanto, ativei isso para a conta que estou usando nas Propriedades do usuário no AD. Existe algum outro lugar que isso precisa ser ativado, ou talvez eu tenha que esperar para replicar ou reiniciar um serviço (diferente do Radius)? O servidor IAS é a mesma máquina que um controlador de domínio, e eu fiz a alteração nessa máquina, então eu acho que ele entraria em vigor imediatamente.
Além disso, quão inseguro é isso para "senhas criptografadas reversivelmente"?
Editar:
Eu provavelmente também devo dizer por que estou fazendo isso, caso haja uma maneira melhor. Estou configurando um roteador Cisco para um endpoint para túneis L2TP / IPSec Iniciados pelo Cliente. Eu quero autenticar contra o AD, por isso, se há uma maneira melhor de lidar com a autenticação, por favor, deixe-me saber :-) Idealmente, eu ainda poderia usar o built-in Windows VPN Client.
Por que não estava funcionando, aparentemente, porque a senha precisa ser redefinida. Consegui fazer isso via Active Directory.
Além disso, parece que posso configurar o roteador e o servidor Radius para usar ms-chap-v2, o que não exige que eu armazene as senhas com criptografia reversível.
A página do TechNet da Microsoft sobre isso ( aqui ) basicamente diz:
"Storing passwords using reversible encryption is essentially the same as storing plaintext versions of the passwords. For this reason, this policy should never be enabled unless application requirements outweigh the need to protect password information."
O link do mh está no local - uma vez que algo é armazenado de forma que possa ser recuperado, ele deve ser considerado não melhor do que o texto simples. Como é implementado no AD, habilitar a criptografia reversível significa que qualquer pessoa (ou qualquer coisa) com direitos de administrador do domínio pode descriptografar senhas porque elas têm acesso ao segredo global da LSA, que é a única parte do processo que é secreta em qualquer sentido. tudo o mais envolvido pode ser lido do AD por qualquer pessoa ou está contido em uma DLL que pode ser manipulada \ engenharia reversa.
Do ponto de vista de ataque, se alguém tiver direitos de administrador de domínio, o jogo já está em andamento, mas do ponto de vista da segurança interna, isso também significa que os administradores de domínio podem descriptografar as senhas no texto original que não é bom. Se nada mais eu não gostaria de estar enfrentando uma investigação de segurança, onde a evidência chave era entradas de log de eventos mostrando um usuário entrando e saindo usando uma senha que tecnicamente eu poderia saber se eu quisesse.
Há um conjunto interessante de postagens de blog de Niels Teusink sobre o assunto, começando aqui .
Existem muitas alternativas melhores em termos de autenticação (X.509 Certs, One Time Password Tokens, Smart Cards ...), mas se você pode usá-las ou não, depende do aplicativo e do sistema do cliente que os usuários precisam usar. Se você tem controle total do ambiente, você deve ser capaz de encontrar uma solução que lhe permita evitar usá-los, mas implementá-los corretamente pode ser caro e seus usuários podem considerá-los inconvenientes.
Editado após a sua atualização eu sugiro usar Certificados Integrados do AD, será um pouco trabalhoso, mas o resultado final é sólido e você pode reutilizar a capacidade para muitas outras coisas.