EXTENSION DE ACTIVE DIRECTORY DOMAIN SERVICES- AZURE

Cuando un cliente nos solicita extender su plataforma on-premise para la nube de Microsoft (Azure) https://docs.microsoft.com/en-us/azure/active-directory/ , existen dos oportunidades para atender este requerimiento, cada cual tiene sus bondades, pero también tienen diferentes requisitos y comportamientos. A continuación quiero clarificar ambos escenarios, uno es el configurar AD-Connect para «sincronizar» el directorio activo local con la nube *{en este escenario no se REPLICAN las cuentas y sus SID, se crean nuevas cuentas en Azure Active Directory -AAD con el mismo nombre de usuario y unos cuantos atributos copiados desde directorio activo}, el otro escenario es configurar una VPN site-to-site (S2S) y al extender la red se puede matricular un servidor de infraestructura como servicio (IAAS), pero en este escenario es necesario tener presentes los puertos que se han de permitir a nivel de firewall para evitar inconvenientes, https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd772723(v=ws.10)

Cuestionario

El siguiente cuestionario es necesario para reconocer el escenario del cliente.

  • ¿Como se llama su dominio?
  • ¿Cuántos servidores controladores de dominio, Sitios y subredes componen su ADDS?
  • ¿Qué servidor/es tiene roles FSMO?
  • ¿Qué versión tienen sus controladores de dominio?
  • ¿Su dominio tiene subdominios?
  • ¿Su dominio tiene relaciones de confianza?
  • ¿Qué aplicaciones u servicios dependen de autenticación ADDS?
  • ¿Qué nivel funcional tiene su dominio y su forest?
  • ¿Cuál es la clave del administrador de dominio?
  • ¿Cuál es la clave de recuperación del dominio?
  • ¿Cuánto pesa su archivo c:\Windows\NTDS\NTDS.DIT?
  • ¿Cuántos objetos tiene su directorio activo entre usuarios, equipos, y grupos? (un aproximado)
  • ¿Esta usted actualmente utilizando Exchange, Sharepoint, o Skype for Business?
  • ¿Utiliza usted SQL, CRM, o algún ERP que requiere autenticación?
  • ¿Su Active Directory esta sincronizado con ADConnect contra Azure Active Directory?

Diseño propuesto

El siguiente diagrama es una propuesta para el escenario de un cliente que extiende su red por S2S a un domain controler en Azure.

Escenario

AD DS se usa para autenticar usuarios, equipos, aplicaciones u otras entidades que se incluyen en un dominio de seguridad. Se puede hospedar de forma local, pero si parte de la aplicación se hospeda en el entorno local y parte en Azure, puede que resulte más eficaz replicar esta funcionalidad en Azure. Esto puede reducir la latencia causada por el envío de solicitudes de autorización locales y de autenticación desde la nube a los servicios AD DS que se ejecutan en un entorno local.

Esta arquitectura suele usarse cuando la red local y la red virtual de Azure están conectadas mediante una conexión VPN S2S o ExpressRoute. Esta arquitectura también admite la replicación bidireccional, lo que significa que los cambios se pueden realizar en el entorno local o en la nube, de tal forma que se mantiene la coherencia de ambos orígenes. Los usos típicos de esta arquitectura incluyen aplicaciones híbridas en las que la funcionalidad se distribuye entre el entorno local y Azure, y las aplicaciones y los servicios que realizan la autenticación con Active Directory.

Arquitectura

Red local. La red local incluye servidores locales de Active Directory que pueden realizar la autenticación y autorización de componentes que se encuentran en entornos locales.

Servidores de Active Directory. Se trata de controladores de dominio que implementan servicios de directorio (AD DS) que se ejecutan como máquinas virtuales en la nube. Estos servidores pueden proporcionar la autenticación de componentes que se ejecutan en la red virtual de Azure.

Subred de Active Directory. Los servidores de AD DS se hospedan en una subred independiente. Las reglas de los grupos de seguridad de red (NSG) protegen los servidores de AD DS y proporcionan un firewall contra el tráfico procedente de orígenes inesperados.

Azure Gateway y sincronización de Active Directory. Azure Gateway proporciona una conexión entre la red local y la red virtual de Azure. Puede ser una conexión VPN o Azure ExpressRoute. Todas las solicitudes de sincronización entre los servidores de Active Directory en la nube y locales pasan a través de la puerta de enlace. Las rutas definidas por el usuario (UDR) controlan el enrutamiento del tráfico local que pasa a Azure. El tráfico hacia y desde los servidores de Active Directory no pasa a través de las aplicaciones virtuales de red (NVA) utilizadas en este escenario.

Recomendaciones

Las siguientes recomendaciones sirven para la mayoría de los escenarios. Sígalas a menos que tenga un requisito concreto que las invalide.

Recomendaciones de VM

Determine los requisitos de tamaño de la máquina virtual en función del volumen esperado de solicitudes de autenticación. Use las especificaciones de los equipos que hospedan AD DS de forma local como punto de partida y hágalas coincidir con los tamaños de máquina virtual de Azure. Una vez realizada la implementación, supervise la utilización y escale o reduzca verticalmente en función de la carga real de las máquinas virtuales. Para más información sobre cómo ajustar el tamaño de los controladores de dominio de AD DS, vea Capacity Planning for Active Directory Domain Services (Planeamiento de capacidad de Active Directory Domain Services).

Crear un disco de datos virtual independiente para almacenar la base de datos, los registros y SYSVOL de Active Directory. No almacene estos elementos en el mismo disco que el sistema operativo. Tenga en cuenta que, de forma predeterminada, los discos de datos que están conectados a una máquina virtual usan una caché de escritura simultánea. Sin embargo, esta forma de almacenamiento en caché puede entrar en conflicto con los requisitos de AD DS. Por ello, establezca la preferencia de caché de host en el disco de datos en Ninguna. Para más información, consulte Directrices para implementar Windows Server Active Directory en máquinas virtuales de Azure.

Implemente al menos dos máquinas virtuales que ejecutan AD DS como controladores de dominio y agréguelas a un conjunto de disponibilidad.

Recomendaciones de redes

Configure la interfaz de red (NIC) de VM para cada servidor de AD DS con una dirección IP privada estática para la compatibilidad total del Servicio de nombres de dominio (DNS). Para más información, vea Configuración de direcciones IP privadas para una máquina virtual mediante Azure Portal.

*** Nota: ****

No configure la NIC de VM para cualquier AD DS con una dirección IP pública. Vea las consideraciones de seguridad para más información.

El NSG de la subred de Active Directory requiere reglas para permitir el tráfico entrante desde el entorno local. Para obtener información detallada sobre los puertos que AD DS utiliza, vea Active Directory and Active Directory Domain Services Port Requirements (Requisitos de puertos de Active Directory Domain Services y Active Directory). Asegúrese también de que las tablas UDR no enruten el tráfico de AD DS a través de las NVA utilizadas en esta arquitectura.

Sitio de Active Directory

En AD DS, un sitio representa una ubicación física, una red o un conjunto de dispositivos. Los sitios de AD DS se utilizan para administrar la replicación de base de datos de AD DS mediante la agrupación de objetos de AD DS que se encuentran cerca unos de otros y que están conectados mediante una red de alta velocidad. AD DS incluye la lógica para seleccionar la mejor estrategia para replicar la base de datos de AD DS entre sitios.

Se recomienda crear un sitio de AD DS, incluidas las subredes definidas para la aplicación en Azure. Después, configure un vínculo de sitio entre los sitios de AD DS locales, y AD DS realizará automáticamente la replicación de base de datos más eficaz posible. Tenga en cuenta que esta replicación de base de datos requiere poco más aparte de la configuración inicial.

Maestros de operaciones de Active Directory

El rol de maestro de operaciones se puede asignar a los controladores de dominio de AD DS para admitir la comprobación de coherencia entre instancias de bases de datos de AD DS replicadas. Hay cinco roles de maestro de operaciones: maestro de esquema, maestro de nomenclatura de dominios, maestro de identificadores relativos, maestro emulador del controlador de dominio principal y maestro de infraestructuras. ¿Para más información sobre estos roles, vea What are Operations Masters? (¿Qué son los maestros de operaciones?).

Se recomienda no asignar roles de maestros de operaciones a los controladores de dominio implementados en Azure.

Supervisión

Supervise los recursos de las máquinas virtuales del controlador de dominio y los servicios de AD DS y cree un plan para corregir rápidamente los problemas. Para más información, vea Monitoring Active Directory (Supervisión de Active Directory). También puede instalar herramientas como Microsoft Systems Center en un servidor de supervisión (vea el diagrama de la arquitectura) para ayudar a realizar estas tareas

Contenido tomado de: https://docs.microsoft.com/es-es/azure/architecture/reference-architectures/identity/adds-extend-domain#deploy-the-solution

Dejar un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *