Estate atento porque en este post hallarás el resultado que buscas.Este artículo ha sido evaluado por nuestros especialistas para garantizar la calidad y exactitud de nuestro post.
Solución:
Solución
¿No lo sabría? Aproximadamente un mes después de haber abandonado este enfoque de usar un servidor RADIUS para controlar el acceso al SBC, encontramos una posible solución. Por supuesto, en este punto estamos demasiado ocupados con otros proyectos para volver atrás y probar esta solución, por lo que no puedo decir al 100% si esto solucionaría el problema, pero una vez que lo explique, probablemente estará de acuerdo en que esta es la respuesta.
Uno de mis colegas estaba en una conferencia de Microsoft teniendo varias discusiones cuando se dio cuenta de que MSCHAPv2 se basa en NTLM para generar los desafíos y respuestas de contraseña. Ahora, MSCHAP y MSCHAPv2 (es decir, no EAP-MSCHAPv2 o PEAP), cuando se usan en los servicios RAS de Windows, usarán NTLMv1 de forma predeterminada.
Como muchos de ustedes ya han comenzado a darse cuenta, nosotros, al igual que muchos administradores, hemos deshabilitado NTLMv1 en nuestros DC y, como tal, los DC solo aceptarán solicitudes NTLMv2. Esto explica por qué la falla que seguí obteniendo fue un error de “contraseña incorrecta”. La contraseña que se enviaba a los DC estaba en formato NTLMv1 y se ignoraba.
Una vez que nos dimos cuenta de esto, pude investigar un poco más y encontré el siguiente artículo:
http://support.microsoft.com/kb/2811487
Este artículo describe el mismo comportamiento que estaba experimentando, incluido el código de error E=691 que he mencionado. Este artículo también proporciona una solución alternativa para obligar a los servicios RAS a usar NTMLv2 al generar una respuesta MSCHAPv2. Es curioso lo fácil que es encontrar estos artículos después de saber con precisión cuál es el problema.
Nuevamente, todavía tengo que verificar que este sea el problema, ya que no he tenido tiempo de reconstruir los servidores RADIUS que ya he dado de baja, pero planeo probar esto en algún momento si tengo la oportunidad. Solo quería publicar esta posible solución en caso de que alguien más tropiece con este problema. Si alguien puede confirmar esto antes que yo, por favor hágamelo saber.
Editar – Confirmado
Se nos pidió que asumiéramos un papel más importante con estos SBC y, como tal, volvimos a este proyecto y volvimos a mostrar un servidor RADIUS de Windows. Esta vez aplicamos el registro key descrito en el enlace de arriba. Después de tomar una captura de paquetes de la comunicación entre el servidor RADIUS y los SBC, ahora puedo ver los mensajes de “Acceso aceptado” que se envían a los SBC. Así que ahora puedo confirmar, al menos en nuestro escenario, que el problema que teníamos es el descrito anteriormente.
TL;DR
NTLMv1 estaba deshabilitado en los controladores de dominio. Establecer un registro key forzar al servidor RADIUS a usar NTLMv2 solucionó el problema.
Si crees que ha resultado de utilidad este post, sería de mucha ayuda si lo compartes con otros seniors y nos ayudes a extender esta información.