Primeiro o método EAP: que hash de contrasinal pode usar unha VPN
Unha VPN verifica o segredo, non o hash web. Le o método e despois comproba que garda o almacén antes de prometer que os mesmos contrasinais seguirán funcionando.
Moitos equipos teñen un inicio de sesión web que funciona e unha VPN que rexeita cada contrasinal da mesma táboa. A aplicación web compara un hash que calculou ela mesma, mentres que o túnel pide ao cliente que demostre a posesión dun segredo dun xeito que o servidor debe poder comprobar. Son requisitos distintos sobre o material almacenado. É no oco entre ambos onde se atascan a maioría destes proxectos.
Primeiro o método, despois o esquema
Anota que proba esixe o método escollido antes de mirar calquera esquema. Un método de desafío-resposta necesita material do que o servidor poida calcular a resposta esperada, o que na práctica significa o contrasinal ou unha forma derivada compatible. Un método que leva o contrasinal dentro dun túnel protexido necesita o propio contrasinal no verificador. Le a documentación do método polo requisito do verificador e non pola configuración do cliente, porque os requisitos do cliente adoitan ser a parte doada.
Un hash con sal producido por un marco web moderno non achega ningunha das dúas cousas. Verifica unha comparación concreta e non se pode devolver ao segredo do que saíu.
O desafío-resposta non pode usar un hash con sal
MSCHAPv2 é un intercambio de desafío-resposta, así que o servidor nunca recibe o contrasinal e non pode comparar unha cadea almacenada. Ten que derivar a resposta esperada do material que xa posúe, e por iso as formas almacenadas compatibles son tan estreitas. Un valor bcrypt ou Argon2 cunha sal por usuario é dun só sentido dun xeito que descarta o intercambio por completo. A táboa de abaixo parte da forma de almacenamento e non do nome do método, porque a forma de almacenamento é o que decide a resposta.
| What the store holds | What that material can verify | What has to change |
|---|---|---|
| A bcrypt or Argon2 value with a per-user salt | nothing challenge-response can use, and not the password either | re-enrol the users, or place a verifying service in front |
| An unsalted NT-hash | MSCHAPv2, and inner PAP through a TLS tunnel | nothing, as long as that store is the verifier |
| A client certificate with a revocation list | EAP-TLS only | move enrolment and revocation to the PKI owner |
A documentación do complemento SQL para strongSwan define un esquema propio para a configuración e as credenciais, e o proxecto segue marcando ese complemento como experimental. Nada nela se adapta á táboa de usuarios dunha aplicación nin adiviña que esquema de hash produciu un valor almacenado. As opcións realistas son, por tanto, migrar a un almacén que a pasarela poida usar, ou un servizo de autenticación diante do almacén existente que poida realizar o intercambio. Calquera outra cousa é un conector cunha suposición oculta dentro.
RADIUS move o traballo, non o requisito
Delegar EAP nun servidor RADIUS cambia onde ocorre a verificación e normalmente mellora o rastro de auditoría. Non recupera un contrasinal dun hash dun só sentido, así que o servizo de autenticación segue necesitando material compatible co método que remata. Os equipos descobreno despois de construír a ruta RADIUS e de atopar o mesmo muro no outro extremo.
Onde o servidor RADIUS pode ler un directorio cunha credencial compatible, o deseño funciona e a pasarela VPN mantense sinxela. Onde non pode, a resposta honesta é un cambio de alta e non outro conector. O aprovisionamento e a revocación pertencen a quen posúe a identidade, así que unha táboa copiada sen un proceso de sincronización admitido é un segundo ciclo de vida de credenciais e non un inicio de sesión único. Desvíase a primeira vez que alguén restablece un contrasinal nun só lugar, e a desviación é silenciosa ata que unha conta que existe nos dous sistemas se comporta de xeito distinto en cada un.
Limita a conta que le o directorio a esa lectura e mantena separada da conta que a pasarela usa para a súa propia configuración. Unha conta administrativa compartida converte un deseño de só lectura nun radio de impacto moito maior.
Onde debería vivir a conta
Unha vez resolvida a cuestión do material, quedan dúas arquitecturas. A pasarela pode ter un pequeno almacén de credenciais que só ela le, ou pode delegar nun servizo de autenticación que se sitúa diante do directorio corporativo.
A primeira é máis doada de razoar e peor para o usuario, que acaba cun segundo contrasinal que manter. A segunda conserva unha soa identidade e engade unha dependencia dun servizo que agora ten que estar dispoñible antes de que ninguén poida conectarse. Ningunha é incorrecta, pero a elección debería rexistrarse xunto á configuración da pasarela, porque doutro xeito o seguinte enxeñeiro dará por feito que se escolleu a outra. Escollas o que escollas, os dous comandos de abaixo son os que mostran o estado actual antes de cambialo.
mysql -N -e "SELECT id, username FROM vpn_users WHERE active = 1 LIMIT 5" vpn
swanctl --list-connsA autenticación da conta tampouco resolve a autorización. A pertenza a grupos, o estado do dispositivo e o permiso de rede seguen necesitando unha asignación explícita unha vez que o usuario demostrou a identidade requirida. Unha conexión que se autentica perfectamente e non autoriza nada é un resultado de política, non un fallo do método.