¿Las mejores prácticas para conectar un servidor público a LDAP / Active Directory interno?

No me parece que esto produzca una superficie de ataque especialmente peligrosa: siempre que sus cuentas de AD estén lo suficientemente seguras de que sus contraseñas no puedan ser forzadas de manera bruta, y que su servidor LDAP esté debidamente protegido y parchado. Si bien es cierto que un compromiso del servidor web abriría su servidor LDAP a los ataques, no hay necesariamente mucho que pueda hacer para mitigar esto.

Consideré que si su servidor web se ve comprometido, podría ser útil tener un proxy entre su servidor web y el servidor LDAP, pero eso le da un servidor más para actualizar y parchear, de lo contrario, solo se pondrá en peligro y se usará para atacar el servidor LDAP en su lugar. Eso, por supuesto, no es una cosa determinada, y requiere otra serie de ataques para llegar a la misma situación que la situación sin el servidor web, pero puede proporcionar alguna defensa adicional en profundidad.

El libro, Política de grupo: Fundamentos, Seguridad y Managed Desktop, tercera edición tiene un Apéndice E que cubre el uso de Microsoft Intune para la aplicación de parches externos en combinación con PolicyPak Cloud para la configuración de políticas de grupo cuando se encuentran remotos y unidos a un dominio (por ejemplo, , VPN) - o unidas remotas y sin dominio.

  

Sin embargo, no me siento muy cómodo con esta configuración.

Y en mi opinión, tienes razón con tu sentimiento.

Ejemplo: si los administradores de dominio activaron el bloqueo de la cuenta después de repetidos fallos de inicio de sesión, un atacante externo puede iniciar un ataque de denegación de servicio en todos sus nombres de usuario de adivinación de dominio.

Podría mitigarlo al limitar los inicios de sesión fallidos en su aplicación web. Pero tiene que implementarlo de manera confiable en todas las aplicaciones web que utilizan este tipo de inicio de sesión.

Otra solución sería la autenticación de dos factores utilizada para verificar la OTP antes de verificar realmente la contraseña del usuario.

Otra cosa a considerar con sus administradores de dominio: A veces, actualizan su infraestructura de controlador de dominio (DC) instalando nuevos controladores de dominio con una versión más nueva de Windows que se ejecuta en diferentes direcciones IP pero con el mismo dominio. Esto no es un problema en el mundo de Windows porque los CD se anuncian a través de los RR SRV de DNS. Pero es probable que tengas que ajustar las reglas de tu firewall.

Además, sugiero instalar un proxy de nivel de aplicación LDAP basado en OpenLDAP 's back-ldap porque OpenLDAP tiene una validación de entrada bastante estricta en las PDU de LDAP. Con una configuración de este tipo, también podría restringir el acceso LDAP a, por ejemplo, un determinado grupo de AD que mitiga el riesgo para el resto de su dominio.

Con respecto al cifrado de transporte: Sí, ¡use TLS en todas partes!

En cuanto a Web-SSO: Sí, esa es una solución viable porque con la mayoría de los protocolos de SSO, el navegador del usuario se redirige a un proveedor de identidad, los mensajes de SSO están firmados y, por lo tanto, no es necesario acceder directamente a la administración de usuarios desde su aplicación. Tienes que sumergirte un poco en los protocolos para entenderlo.