¿Debo exponer mi Active Directory a Internet público para usuarios remotos?

Tengo un cliente cuya fuerza laboral está compuesta en su totalidad por empleados remotos que usan una combinación de PC / laptops Apple y Windows 7.

Los usuarios no se autentican en un dominio en este momento, pero a la organización le gustaría moverse en esa dirección por varias razones. Estas son máquinas propiedad de la compañía, y la firma busca tener cierto control sobre la desactivación de la cuenta, la política de grupo y alguna prevención ligera de pérdida de datos (deshabilitar medios remotos, USB, etc.). Les preocupa que requieran autenticación VPN para acceder a AD sería engorroso, especialmente en la intersección de un empleado despedido y las credenciales almacenadas en caché en una máquina remota.

La mayoría de los servicios en la organización están basados ​​en Google (correo, archivo, chat, etc.), por lo que los únicos servicios de dominio son DNS y la autenticación para su VPN ASA de Cisco.

Al cliente le gustaría entender por qué no es aceptable exponer sus controladores de dominio al público. Además, ¿cuál es una estructura de dominio más aceptable para una fuerza de trabajo remota distribuida?

Editar:

Centrify está en uso para un puñado de clientes Mac.

Estoy publicando esto como respuesta principalmente porque todos tienen su propia "opinión educada" basada en la experiencia, información de terceros, rumores y conocimientos tribales dentro de TI, pero esta es más una lista de citas y lecturas "directamente" de Microsoft. Utilicé citas porque estoy seguro de que no filtran correctamente todas las opiniones hechas por sus empleados, pero esto debería ser útil si buscas authoritativereferencias directas de Microsoft.

Por cierto, también creo que es MUY FÁCIL decir DOMINIO CONTROLADOR == DIRECTORIO ACTIVO, que no es el caso. Los servidores proxy de AD FS y otros medios (autenticación basada en formularios para OWA, EAS, etc.) ofrecen una forma de "exponer" el propio AD a la web para permitir que los clientes al menos intenten autenticarse a través de AD sin exponer los propios DC. Ir en el sitio OWA de una persona y el intento de inicio de sesión y AD será obtener la solicitud de autenticación en un motor de corriente continua, por lo que la EA está técnicamente "expuesta" ... pero está asegurada a través de SSL y un servidor proxy a través de un servidor de Exchange.

Cita n. ° 1

Directrices para implementar Windows Server Active Directory en máquinas virtuales de Windows Azure

Antes de continuar "Azure no es AD" ... PUEDE implementar ADDS en una máquina virtual de Azure.

Pero para citar los bits relevantes:

Nunca exponga los STS directamente a Internet.

Como práctica recomendada de seguridad, coloque instancias STS detrás de un firewall y conéctelas a su red corporativa para evitar la exposición a Internet. Esto es importante porque el rol STS emite tokens de seguridad. Como resultado, deben tratarse con el mismo nivel de protección que un controlador de dominio. Si un STS se ve comprometido, los usuarios malintencionados tienen la capacidad de emitir tokens de acceso que posiblemente contengan reclamos de su elección para confiar en aplicaciones de terceros y otros STS en organizaciones de confianza.

ergo ... no exponga los controladores de dominio directamente a internet.

Cita # 2

Active Directory - El misterio de UnicodePwd de AD LDS

Exponer un controlador de dominio a Internet suele ser una mala práctica, ya sea que la exposición provenga directamente del entorno de producción o de una red perimetral. La alternativa natural es colocar un servidor Windows Server 2008 con la función de Servicios de directorio ligero de Active Directory (AD LDS) que se ejecuta en la red perimetral.

Cita # 3 - no de MS ... pero útil aún para mirar hacia el futuro

Directorio Activo como un Servicio? Azure, Intune insinuando un futuro AD alojado en la nube

Al final, no hay una gran respuesta "corta" que cumpla con los objetivos de deshacerse de la oficina del servidor AD a cambio de una alternativa de Azure. Si bien Microsoft se muestra complaciente al permitir que los clientes alojen los Servicios de dominio de Active Directory en los cuadros Server 2012 y 2008 R2 en Azure, su utilidad es tan buena como la conectividad VPN que puede reunir para su personal. DirectAccess, aunque es una tecnología muy prometedora, tiene las manos atadas debido a sus propias limitaciones desafortunadas.

Cita # 4

Implemente AD DS o AD FS y Office 365 con inicio de sesión único y máquinas virtuales de Windows Azure

Los controladores de dominio y los servidores AD FS nunca deben exponerse directamente a Internet y solo deben ser accesibles a través de VPN

Active Directory (AD) no fue diseñado para ese tipo de implementación.

Los modelos de amenaza utilizados en el diseño del producto suponen una implementación "detrás del firewall" con cierta cantidad de actores hostiles filtrados en el borde de la red. Si bien ciertamente puede fortalecer Windows Server para exponerse a la red pública, el funcionamiento correcto de Active Directory requiere una postura de seguridad que es decididamente más laxa que un host reforzado para redes públicas. Una gran cantidad de los servicios tienen que estar expuestos a un controlador de dominio (DC) para la EA para que funcione correctamente.

La sugerencia de Zoredache en los comentarios, particularmente haciendo referencia a algo como OpenVPN que se ejecuta como un servicio de toda la máquina con autenticación de certificado, podría ser una buena opción. DirectAccess, como otros han mencionado, es exactamente lo que necesita, excepto que no tiene el soporte multiplataforma que le gustaría.

Como comentario adicional: jugué con la idea de usar IPSEC en modo de transporte basado en certificados para exponer AD directamente a Internet, pero nunca tuve tiempo de hacerlo. Microsoft realizó cambios en el marco de tiempo de Windows Server 2008 / Vista que supuestamente hicieron esto factible, pero en realidad nunca lo he ejercido.

Lo que todos los demás dijeron. Estoy particularmente nervioso por los intentos de fuerza bruta que mencionó Christopher Karel. Una presentación en la última Def Con fue sobre el tema:

¿Entonces crees que tu controlador de dominio es seguro?

INGENIERO DE SEGURIDAD DE JUSTIN HENDRICKS, MICROSOFT

Los controladores de dominio son las joyas de la corona de una organización. Una vez que caen, todo en el dominio cae. Las organizaciones hacen todo lo posible para proteger sus controladores de dominio, sin embargo, a menudo no logran proteger adecuadamente el software utilizado para administrar estos servidores.

Esta presentación cubrirá métodos no convencionales para obtener dominio de administrador al abusar del software de administración de uso común que las organizaciones implementan y usan.

Justin Hendricks trabaja en el equipo de seguridad de Office 365, donde participa en equipos rojos, pruebas de penetración, investigación de seguridad, revisión de código y desarrollo de herramientas.

Estoy seguro de que puedes encontrar muchos otros ejemplos. Estaba buscando artículos sobre controladores de dominio y piratería con la esperanza de obtener una descripción de qué tan rápido se encontraría el DC, etc., pero creo que eso funcionará por ahora.

Si intenta convencer a la gerencia, un buen comienzo sería que:

It goes against Microsoft's Best Practices for Active Directory Deployment.

Actualización : consulte este artículo de technet sobre cómo proteger los controladores de dominio contra ataques y la sección titulada Perimeter Firewall Restrictionsque dice:

Perimeter firewalls should be configured to block outbound connections
from domain controllers to the Internet. 

Y la sección titulada Blocking Internet Access for Domain Controllersque dice:

Launching web browsers on domain controllers should be prohibited not only
by policy, but by technical controls, and domain controllers should not be
permitted to access the Internet

Estoy seguro de que puede obtener algo de documentación de Microsoft sobre el asunto, así que eso es todo. Además de eso, podría indicar los riesgos de tal movimiento, algo como:

A gaping hole would be created, possibly resulting in severe data loss and/or loss of company secrets.

Las credenciales almacenadas en caché son solo eso: almacenadas en caché. Funcionan para la máquina local cuando no se puede conectar al dominio , pero si esa cuenta estuviera deshabilitada, no funcionarían para ningún recurso de red (svn, vpn, smb, fbi, cia, etc.), por lo que no deben preocuparse por eso . También recuerde que los usuarios ya tienen derechos completos sobre cualquier archivo en su carpeta de perfil en una máquina local de todos modos (y probablemente en medios extraíbles), por lo que las credenciales deshabilitadas o no pueden hacer lo que quieran con esos datos. Tampoco funcionarían para la máquina local una vez que se vuelva a conectar a la red.

¿Se refiere a los servicios que proporciona Active Directory o un controlador de dominio, como LDAP? Si es así, LDAP a menudo se divide de forma segura para fines de autenticación y consulta de directorio, pero solo apagar el Firewall de Windows (o abrir todos los puertos necesarios al público: lo mismo en este ejemplo) podría causar problemas graves.

AD realmente no administra Macs, por lo que se requeriría una solución separada (piense en OS X Server). Puede unir una Mac a un dominio, pero eso hace poco más que permitir que se autentiquen con credenciales de red, establecer administradores de dominio como administradores locales en la Mac, etc. Sin política de grupo. MS está tratando de romper ese terreno con nuevas versiones de SCCM que afirman poder implementar aplicaciones en macs y * nix boxes, pero aún no lo he visto en un entorno de producción. También creo que podría configurar los Mac para conectarse al servidor OS X que se autenticaría en su directorio basado en AD, pero podría estar equivocado.

Dicho esto, se podrían idear algunas soluciones creativas, como la sugerencia de Evan de utilizar OpenVPN como servicio, y desactivar el certificado de máquina si llega el momento de dejar ir a ese empleado.

Parece que todo está basado en Google, ¿entonces Google está actuando como su servidor ldap? Recomendaría a mi cliente que lo mantenga así si es posible. No conozco la naturaleza de su negocio, pero para aplicaciones basadas en la web, como un servidor git o redmine, incluso cuando la configuración en casa puede autenticarse con OAuth, aprovechando una cuenta de Google.

Por último, una configuración de roadwarrior como esta casi requeriría una VPN para tener éxito. Una vez que las máquinas se llevan a la oficina y se configuran (o se configuran de forma remota a través de un script), necesitan una forma de recibir cualquier cambio en la configuración.

Los Mac necesitarían un enfoque de administración separado además de la VPN, es una lástima que ya no sean servidores Mac reales, pero tenían algunas implementaciones de políticas decentes en el servidor OS X la última vez que lo comprobé (hace un par de años )

Es lamentable que DirectAccess solo esté disponible en Win7 + Enterprise Edition, porque está hecho a medida para su solicitud. Pero no conocer su edición y ver que tiene MacOS, eso no funcionará.

/ Editar: parece que algunos terceros afirman que tienen clientes DA para Unices: http://www.centrify.com/blogs/tomkemp/what_is_microsoft_directaccess_and_unix_linux_interoperability.asp

Hay soluciones MDM disponibles que pueden funcionar para satisfacer sus necesidades; Estamos lanzando uno de ellos (MAAS360) a un cliente que está en una posición similar.

Obviamente, esto sería un riesgo de seguridad significativo. Además, probablemente no funcionaría tan bien como te gustaría. Si personas aleatorias en Internet pueden intentar iniciar sesión en su entorno de AD, es muy probable que todos sus usuarios sean bloqueados. Siempre. Y eliminar los requisitos de bloqueo significa que es bastante fácil verificar la fuerza bruta para contraseñas simples.

Más importante aún, no debería tener problemas para implementar su objetivo (usuarios finales que inician sesión en una computadora portátil con credenciales de dominio) sin hacer que los servidores de AD sean directamente accesibles. Es decir, las máquinas Windows pueden almacenar en caché los últimos X inicios de sesión exitosos, para que esas mismas credenciales funcionen cuando se desconectan. Esto significa que los usuarios finales pueden iniciar sesión y realizar un trabajo útil, sin necesidad de tocar sus servidores AD. Obviamente necesitarán utilizar una VPN para conectarse a otros recursos corporativos importantes, y pueden actualizar la configuración de AD / GPO al mismo tiempo.

Ewwhite

Su pregunta es extremadamente válida y merece una revisión cuidadosa.

Todos los profesionales de seguridad recomiendan capas de seguridad frente a cualquier recurso de red, incluidos los firewalls SPI, IDS, firewalls basados ​​en host, etc. Siempre debe usar un firewall proxy de puerta de enlace perimetral como ISA (ahora TMG) ​​cuando sea posible.

Dicho esto, Microsoft Active Directory 2003+ no ha tenido vulnerabilidades importantes reveladas públicamente. La tecnología LDAP y sus algoritmos hash son generalmente muy seguros. Podría decirse que es más seguro que la VPN SSL si esa VPN SSL ejecuta OpenSSL y es vulnerable a los ataques cardíacos.

Yo advertiría 5 cosas:

1. Preocúpese por los otros servicios que enfrenta la red, como Terminal Server, Servicios de DNS, CIFS y especialmente IIS con su terrible historial de seguridad.

2. Use LDAPS con un certificado de seguridad para evitar pasar credenciales de dominio de texto claro a través del cable. Esto sucede automáticamente después de instalar Servicios de certificados (use una máquina separada para PKI)

3. Coloque un rastreador de paquetes en la interfaz y observe su tráfico, corrija las contraseñas de texto sin cifrar debido a firewall o no, si no está utilizando una VPN o LDAPS, algunos sistemas heredados enviarán contraseñas de texto sin cifrar.

4. Sepa que los ataques MITM pueden forzar a los mecanismos de autenticación nativos a degradar y exponer las contraseñas a una autenticación NTLM más débil.

5. Tenga en cuenta algunas vulnerabilidades de enumeración de usuarios que aún pueden existir.

Dicho esto, Active Directory tiene un excelente historial de seguridad. Además, MS Active Directory no almacena contraseñas, solo hashes que también pueden mitigar la gravedad de un compromiso.

Puede beneficiarse de una infraestructura de seguridad más fluida, no tiene que configurar servidores DNS especiales o usar domain.local y puede usar su dominio real en Internet público como domain.com.

En mi opinión profesional, la implementación de tecnologías de seguridad como Active Directory es un beneficio sustancial, donde otras tecnologías como Exchange y DNS y los servidores web simplemente no brindan ningún beneficio y todo el riesgo.

Nota: si implementa Active Directory, incluirá un servidor DNS. Asegúrese de deshabilitar la recursividad en sus servidores DNS (habilitada de manera predeterminada) o participará absolutamente en ataques de denegación de servicio.

Salud,

-Brian

Dell (mediante la compra de Quest (mediante la compra de Vintela)) tiene una solución multiplataforma que se implementa con frecuencia en empresas F500 para este propósito expreso .

Cosas para considerar...

1. ¿Sus usuarios están siempre conectados? Si es así, será mejor servido con un entorno de alojamiento flexible basado en VM que puede flexionarse cuando muchos usuarios activos están golpeando LDAP
2. ¿Está ejecutando en más de un centro de datos físicos? Considere el equilibrio de carga geográfica frente a los servicios de AD para reducir la cantidad de saltos entre los usuarios y sus sistemas.
3. Además, si la respuesta al n. ° 2 es sí, asegúrese de configurar algunos recursos de red dedicados para replicar su bosque como se muestra aquí

Y asegúrese de que su solución de firewall sea capaz de manejar velocidades de retransmisión extremadamente altas si tiene usuarios en enlaces ascendentes acelerados, conectándose desde centros wifi ruidosos, etc.