¿Le resultó útil esta página?
Sus comentarios sobre este contenido son muy importantes. Háganos saber su opinión.
¿Tiene comentarios adicionales?
Caracteres restantes: 1500
Directrices para implementar Windows Server Active Directory en máquinas virtuales de Azure

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

Actualizado: junio de 2015

En este documento se explican las diferencias importantes entre implementar Servicios de dominio de Active Directory (AD DS) de Windows Server y Servicios de federación de Active Directory (AD FS) de forma local e implementarlos en máquinas virtuales de Microsoft Azure.

Tabla de contenido

El presente documento está destinado a aquellas personas que ya tienen experiencia en implementar Active Directory de forma local. Se explican las diferencias entre implementar Active Directory en máquinas virtuales de Microsoft Azure y redes virtuales de Azure y las implementaciones de Active Directory locales tradicionales. Máquinas virtuales de Azure y Red virtual de Azure forman parte de una oferta de Infraestructura como servicio (IaaS) para que las organizaciones aprovechen los recursos de proceso de la nube.

Aquellas personas que no estén familiarizadas con la implementación de AD deben ver Guía de implementación de AD DS o Planear la implementación de AD FS, según corresponda.

En este documento se da por supuesto que el lector está familiarizado con los conceptos siguientes:

  • Implementación y administración de Windows Server AD DS

  • Implementación y configuración de DNS para admitir una infraestructura de Windows Server AD DS

  • Implementación y administración de Windows Server AD FS

  • Implementación, configuración y administración de aplicaciones de usuario de confianza (sitios web y servicios web) que pueden usar tokens de Windows Server AD FS

  • Conceptos generales de máquina virtual, como la forma de configurar una máquina virtual, discos virtuales y redes virtuales

En este documento se resaltan los requisitos para un escenario de implementación híbrido en el que Windows Server AD DS o AD FS se implementa en parte de forma local y en parte en Máquinas virtuales de Azure. Primero se explican las diferencias más importantes entre ejecutar Windows Server AD DS y AD FS en Máquinas virtuales de Azure y de forma local, así como las decisiones más importantes que afectan al diseño y la implementación. En el resto del documento se explican instrucciones más detalladas para cada uno de los puntos de decisión y cómo aplicar las instrucciones a diversos escenarios de implementación.

En este documento no se explica la configuración de Active Directory de Azure, que es un servicio basado en REST que proporciona capacidades de administración de la identidad y de control de acceso para aplicaciones en la nube. Sin embargo, Active Directory (AD) de Azure y AD DS de Windows Server están diseñados para trabajar conjuntamente con el fin de proporcionar una solución de administración de la identidad y de acceso para los entornos de TI híbridos y las aplicaciones modernas de hoy en día. Como ayuda para entender las diferencias y las relaciones existentes entre Windows Server AD DS y AD de Azure, tenga en cuenta lo siguiente:

  1. Puede ejecutar Windows Server AD DS en la nube en Máquinas virtuales de Azure si usa Azure para extender el centro de datos local a la nube.

  2. Puede usar Active Directory de Azure para proporcionar a los usuarios un inicio de sesión único en las aplicaciones de Software como servicio (SaaS). por ejemplo, Microsoft Office 365 utiliza esta tecnología y las aplicaciones que se ejecutan en Azure o en otras plataformas en la nube también pueden usarla.

  3. Puede usar Active Directory de Azure (su servicio ACS) para que los usuarios inicien sesión mediante identidades de Facebook, Google, Microsoft y otros proveedores de identidad en aplicaciones hospedadas en la nube o de forma local.

Para obtener más información sobre estas diferencias, vea Azure Identity.

Los requisitos fundamentales para implementar Windows Server Active Directory en Máquinas virtuales de Azure difieren muy poco de su implementación en máquinas virtuales (y, hasta cierto punto, en equipos físicos) locales. Por ejemplo, en el caso de Windows Server AD DS, si los controladores de dominio (DC) que implementa en máquinas virtuales de Azure son réplicas en un dominio o un bosque corporativo local existente, la implementación de Azure se puede tratar en gran medida del mismo modo que cualquier otro sitio adicional de Windows Server Active Directory. Es decir, se deben definir subredes en Windows Server AD DS, crear un sitio, vincular las subredes a ese sitio y conectarlas a otros sitios mediante los vínculos de sitio adecuados. Sin embargo, hay algunas diferencias que son comunes a todas las implementaciones de Azure y otras que varían según el escenario de implementación concreto. Aquí se describen tres diferencias fundamentales que se explican con más detalle en los párrafos siguientes:

  1. Puede ser necesario proporcionar a las máquinas virtuales de Azure conectividad a la red corporativa local.

    Para volver a conectar máquinas virtuales de Azure a una red corporativa local se necesita Red virtual de Azure, que incluye un componente de red privada virtual (VPN) de sitio a sitio o de sitio a punto capaz de conectar fácilmente máquinas virtuales de Azure y equipos locales. Este componente de VPN también puede permitir que equipos locales miembros del dominio tengan acceso a un dominio de Windows Server Active Directory cuyos controladores de dominio se hospedan exclusivamente en máquinas virtuales de Azure. Es importante tener en cuenta que si se produce un error en la VPN, la autenticación y otras operaciones que dependen de Windows Server Active Directory también darán errores. Mientras que los usuarios pueden iniciar sesión con credenciales almacenadas en memoria caché existentes, todos los intentos de autenticación punto a punto o de cliente a servidor cuyos vales todavía no se hayan emitido o estén obsoletos producirán un error.

    Vea Red virtual para obtener un vídeo de demostración y una lista de tutoriales paso a paso, incluido Configurar una VPN de sitio a sitio en el Portal de administración.

    noteNota
    También puede implementar Windows Server Active Directory en una red virtual de Azure que no tenga conectividad con una red local. Sin embargo, en las instrucciones de este tema se da por supuesto que se usa una red virtual de Azure porque proporciona capacidades de direccionamiento IP que son esenciales para Windows Server.

  2. Se deben configurar direcciones IP estáticas con Azure PowerShell.

    De manera predeterminada, se asignan direcciones dinámicas, pero en lugar de esto, use el cmdlet Set-AzureStaticVNetIP para asignar una dirección IP estática. De este modo se establece una dirección IP estática que permanecerá durante la recuperación del servicio y el apagado/reinicio de las máquinas virtuales. Para obtener más información, consulte Configurar una dirección IP interna (DIP) estática para una máquina virtual.

A continuación se muestra una lista de términos no exhaustiva en la que se definen varias tecnologías de Azure y que le ayudará a entender este documento.

  • Máquinas virtuales de Azure: oferta de IaaS de Azure que permite a los clientes implementar máquinas virtuales que ejecutan casi cualquier carga de trabajo de servidor local de forma tradicional.

  • Red virtual de Azure: servicio de red de Azure que permite a los clientes crear y administrar redes virtuales en Azure y vincularlas de forma segura a su propia infraestructura local de red mediante una red privada virtual (VPN).

  • Dirección IP virtual (VIP): dirección IP orientada a Internet que no está enlazada a ninguna tarjeta de interfaz de red ni a ningún equipo específico. A los servicios en la nube se les asigna una VIP para recibir el tráfico de red que se redirige a una máquina virtual de Azure. Una VIP es propiedad de un servicio en la nube que puede contener una o varias máquinas virtuales de Azure. Tenga en cuenta también que una red virtual de Azure puede contener uno o más servicios en la nube. Las VIP proporcionan capacidades nativas de equilibrio de carga.

  • Dirección IP dinámica (DIP): Es la dirección IP que es solo interna. Debe configurarse como dirección IP estática (con el cmdlet Set-AzureStaticVNetIP cmdlet) para máquinas virtuales que hospedan los roles de servidor DC/DNS.

  • Recuperación del servicio: proceso por el cual Azure devuelve automáticamente un servicio a un estado en ejecución después de detectar que se ha producido un error en el servicio. La recuperación del servicio es uno de los aspectos de Azure que admite disponibilidad y resistencia. Si bien es improbable, el resultado después de un incidente de recuperación del servicio para un controlador de dominio que se ejecuta en una máquina virtual es similar a un reinicio no planeado, pero tiene algunos efectos secundarios:

    • El adaptador de red virtual de la máquina virtual cambiará

    • La dirección MAC del adaptador de red virtual cambiará

    • El identificador de procesador/CPU de la máquina virtual cambiará

    • La configuración IP de adaptador de red virtual no cambiará siempre y cuando la máquina virtual esté conectada a una red virtual y la dirección IP de la máquina virtual sea estática.

    No obstante, ninguno de estos comportamientos afecta a Windows Server Active Directory, ya que no tiene ninguna dependencia de la dirección MAC o del identificador de procesador/CPU, y se recomienda que todas las implementaciones de Windows Server Active Directory en Azure se ejecuten en una red virtual de Azure como se ha descrito anteriormente.

La implementación de controladores de dominio de Windows Server Active Directory en máquinas virtuales de Azure está sujeta a las mismas instrucciones que la ejecución de controladores de dominio locales en una máquina virtual. La ejecución de controladores de dominio virtualizados es una práctica segura siempre y cuando se sigan las instrucciones para hacer copias de seguridad y restaurar los controladores de dominio. Para obtener más información acerca de las restricciones e instrucciones para ejecutar controladores de dominio virtualizados, vea Ejecutar controladores de dominio en Hyper-V.

Los hipervisores proporcionan o trivializan tecnologías que pueden causar problemas en muchos sistemas distribuidos, incluido Windows Server Active Directory. Por ejemplo, en un servidor físico puede clonar un disco, o usar métodos no admitidos para revertir el estado de un servidor, incluido el uso de SAN, etc., pero hacerlo en un servidor físico es mucho más difícil que restaurar una instantánea de máquina virtual en un hipervisor. Azure ofrece funcionalidad que puede dar lugar a la misma condición no deseable; por ejemplo, no debe copiar archivos VHD de controladores de dominio en lugar de realizar copias de seguridad periódicas porque su restauración puede producir una situación similar al uso de características de restauración de instantáneas.

Esas reversiones presentan burbujas de USN que pueden provocar un estado divergente permanentemente entre los controladores de dominio. Esto puede producir lo siguiente, entre otros:

  • Objetos persistentes

  • Contraseñas incoherentes

  • Valores de atributo incoherentes

  • Discrepancias de esquema si se revierte el maestro de esquema

Para obtener más información sobre cómo se ven afectados los controladores de dominio, vea USN y reversión de USN.

A partir de Windows Server 2012, se han integrado medidas de seguridad adicionales en AD DS . Estas medidas de seguridad ayudan a proteger los controladores de dominio virtualizado frente a los problemas mencionados previamente, siempre y cuando la plataforma de hipervisor subyacente admita VM-GenerationID. Azure admite VM-GenerationID, lo que significa que los controladores de dominio que ejecutan Windows Server 2012 o posterior en Máquinas virtuales de Azure cuentan con las medidas de seguridad adicionales.

noteNota
Debe apagar y reiniciar una máquina virtual que ejecute el rol de controlador de dominio en Azure en el sistema operativo invitado en lugar de usar la opción Apagar en el Portal de administración de Azure. Hoy en día, si se usa el Portal de administración para apagar una máquina virtual, esta se desasigna. Una máquina virtual desasignada tiene la ventaja de que no incurre en cargos, pero también restablece el VM-GenerationID, y esto no es lo deseable para un controlador de dominio. Cuando se restablece el VM-GenerationID, también se restablece el invocationID de la base de datos de AD DS, se descarta el grupo RID y SYSVOL se marca como no autoritativo. Para obtener más información, consulte Introducción a la virtualización de los Servicios de dominio de Active Directory (AD DS) (nivel 100) y Safely Virtualizing DFSR.

Muchos escenarios de implementación de Windows Server AD DS son adecuados para la implementación como máquinas virtuales en Azure. Por ejemplo, suponga que tiene una compañía en Europa que necesita autenticar a los usuarios en una ubicación remota de Asia. La compañía no ha implementado anteriormente controladores de dominio de Windows Server Active Directory en Asia debido al costo que supone y a su poca experiencia en administrar los servidores después de la implementación. Por tanto, los controladores de dominio de Europa atienden las solicitudes de autenticación de Asia con unos resultados poco óptimos. En este caso, puede implementar un controlador de dominio en una máquina virtual que haya especificado que debe ejecutarse dentro del centro de datos de Azure de Asia. La conexión de ese controlador de dominio a una red virtual de Azure que está conectada directamente a la ubicación remota mejorará el rendimiento de autenticación.

Azure también resulta muy indicado como sustituto de sitios de recuperación ante desastres (DR), que son muy costosos. El costo relativamente bajo que supone hospedar una pequeña cantidad de controladores de dominio y una única red virtual en Azure representa una alternativa atractiva.

Por último, puede que desee implementar una aplicación de red en Azure, como SharePoint, que requiera Windows Server Active Directory pero no tenga ninguna dependencia de la red local o de Windows Server Active Directory corporativo. En este caso, es óptimo implementar un bosque aislado en Azure para cumplir los requisitos del servidor de SharePoint. Una vez más, también se admite la implementación de aplicaciones de red que requieren conectividad con la red local y Active Directory corporativo.

noteNota
Puesto que ofrece una conexión Layer-3, el componente de VPN que proporciona conectividad entre una Red virtual de Azure y una red local también puede permitir que los servidores miembro que se ejecutan de forma local aprovechen los controladores de dominio que se ejecutan como máquinas virtuales de Azure en Red virtual de Azure. Pero si la VPN no está disponible, la comunicación entre los equipos locales y los controladores de dominio basados en Azure no funcionará, lo que dará lugar a errores de autenticación y de otro tipo.  

  • Para cualquier escenario de implementación de Windows Server Active Directory que incluya más de una máquina virtual, hay que usar una red virtual de Azure porque la dirección IP es constante. Tenga en cuenta que en esta guía se da por supuesto que los controladores de dominio se ejecutan en una red virtual de Azure.

  • Al igual que para los controladores de dominio locales, se recomiendan direcciones IP estáticas. Una dirección IP estática solo se puede configurar con Azure PowerShell. Vea Configurar una dirección IP interna (DIP) estática para una máquina virtual. Si tienes sistemas de supervisión u otras soluciones para comprobar la configuración de la dirección IP estática en el sistema operativo invitado, puede asignar la misma dirección IP estática a las propiedades del adaptador de red de la máquina virtual. Pero debe tener en cuenta que el adaptador de red se descartará si la máquina virtual realiza una recuperación del servicio o se apaga en el Portal de administración y se cancela su dirección. En ese caso, se deberá restablecer la dirección IP estática del sistema operativo invitado.

  • La implementación de máquinas virtuales en una red virtual no implica (ni requiere) conectividad con una red local; la red virtual habilita simplemente esa posibilidad. Debe crear una red virtual para la comunicación privada entre Azure y la red local. Necesita implementar un extremo de VPN en la red local. La VPN está abierta desde Azure a la red local. Si desea más información, consulte Información general sobre la red virtual y Configurar una VPN de sitio a sitio en el Portal de administración.

    noteNota
    Hay una opción para crear una VPN de punto a sitio disponible para conectar equipos individuales basados en Windows directamente a una red virtual de Azure.

  • Independientemente de si crea una red virtual o no, se le cobrará por el tráfico de salida de Azure, no por el de entrada. Hay varias opciones de diseño de Windows Server Active Directory que pueden afectar al tráfico de salida que genera una implementación. Por ejemplo, implementar un controlador de dominio de solo lectura (RODC) limita el tráfico de salida porque no replica la salida. Pero la decisión de implementar un controlador de dominio de solo lectura se debe valorar en relación con la necesidad de realizar operaciones de escritura en el controlador de dominio y la compatibilidad que tienen las aplicaciones y los servicios del sitio con controladores de dominio de solo lectura. Para obtener más información sobre los cargos de tráfico, vea Precios de Azure de un vistazo.

  • Si bien en Azure tiene un control total sobre qué recursos de servidor se utilizarán para las máquinas virtuales locales (como la cantidad de RAM, el tamaño de disco, etc.), debe elegir en una lista de tamaños de servidor preconfigurados. En el caso de un controlador de dominio, se necesita un disco de datos además del disco del sistema operativo para almacenar la base de datos de Windows Server Active Directory.

Sí, puede implementar Windows Server AD FS en máquinas de virtuales de Azure y los procedimientos recomendados para la implementación de AD FS localmente se aplican igualmente a la implementación de AD FS en Azure. Algunos de estos procedimientos recomendados, como el equilibrio de carga y la alta disponibilidad, requieren tecnologías más allá de lo que ofrece AD FS. Debe proporcionar la infraestructura subyacente. Vamos a revisar algunas de los procedimientos recomendados y ver cómo pueden lograrse con el uso de máquinas virtuales de Azure y una red virtual de Azure.

  1. Nunca exponga los servidores del servicio de token de seguridad (STS) directamente en Internet.

    Esto es importante porque el rol STS emite tokens de seguridad. Como consecuencia, los servidores de STS como servidores de AD FS deben tratarse con el mismo nivel de protección que un controlador de dominio. Si un STS pierde su carácter confidencial, los usuarios malintencionados tienen la posibilidad de emitir tokens de acceso que pueden contener las notificaciones que deseen para aplicaciones de terceros de confianza y servidores STS en organizaciones de confianza.

  2. Implemente controladores de dominio de Active Directory para todos los dominios de usuario de la misma red que los servidores de AD FS.

    Los servidores de AD FS usan el Servicio de dominio de Active Directory para autenticar usuarios. Se recomienda implementar controladores de dominio en la misma red que los servidores de AD FS. Esto proporciona continuidad del negocio en caso de que el vínculo entre la red de Azure y la red local se interrumpa y permite una latencia menor y un mayor rendimiento para los inicios de sesión.

  3. Implemente varios nodos de AD FS para alta disponibilidad y equilibrio de carga.

    En la mayoría de los casos, el error de una aplicación que AD FS habilita no es aceptable, ya que las aplicaciones suelen ser críticas. En consecuencia y como AD FS ahora reside en la ruta de acceso crítica para acceder a aplicaciones críticas, el servicio AD FS debe tener alta disponibilidad a través varios servidores proxy de AD FS y servidores de AD FS. Para lograr la distribución de solicitudes, los equilibradores de carga se implementan normalmente delante de los servidores proxy de AD FS y los servidores de AD FS.

  4. Implemente uno o más nodos de proxy de aplicación web para acceder a Internet.

    Cuando los usuarios necesitan acceder a las aplicaciones protegidas por el servicio AD FS, este debe estar disponible desde Internet. Esto se logra implementando el servicio de proxy de aplicación web. Se recomienda encarecidamente implementar más de un nodo para la alta disponibilidad y el equilibrio de carga.

  5. Restrinja el acceso de los nodos de proxy de aplicación web a recursos de red interna.

    Para permitir que los usuarios externos accedan a AD FS desde Internet, debe implementar nodos de proxy de aplicación web (o proxy de AD FS en versiones anteriores de Windows Server). Los nodos de proxy de aplicación web se exponen directamente en Internet. No es necesario que estén unidos al dominio y solo necesitan acceder a los servidores de AD FS a través de los puertos 80 y 443 de TCP. Se recomienda encarecidamente que se bloquee la comunicación a todos los demás equipos (especialmente los controladores de dominio).

    Por lo general esto se consigue localmente mediante una red perimetral. Los firewalls usan un modo de funcionamiento de la lista blanca para restringir el tráfico de la red perimetral a la red local (es decir, solo se permite el tráfico de las direcciones IP especificadas y a través de los puertos especificados y se bloquea el resto de tráfico).

El diagrama siguiente muestra su aspecto en una implementación AD FS local tradicional.

ADFS en Azure con DMZ

Sin embargo, ya que Azure no proporciona una posibilidad de firewall nativo con todas las características, es necesario usar otras opciones para restringir el tráfico. La siguiente tabla muestra cada opción con sus ventajas e inconvenientes.

 

Opción Ventaja Desventaja

ACL de red de Azure

Configuración inicial menos costosa y más sencilla

Es necesaria una configuración de ACL de red adicional si se agregan las nuevas máquinas virtuales a la implementación.

Barracuda NG Firewall

Modo de funcionamiento de lista blanca y no requiere configuración de ACL de red

Aumento del costo y la complejidad de la instalación inicial.

Los pasos de alto nivel para implementar AD FS en este caso son como sigue:

  1. Cree una red virtual con conectividad entre entornos, mediante una VPN o ExpressRoute.

  2. Implemente controladores de dominio en la red virtual. Este paso es opcional pero recomendado.

  3. Implemente servidores de AD FS unidos al dominio en la red virtual.

  4. Cree un conjunto de carga equilibrada interno que incluya los servidores de AD FS y que use una nueva dirección IP privada dentro de la red virtual (una DIP).

    1. Actualice el DNS para crear el FQDN que señale a la dirección IP privada (DIP) de la carga equilibrada interna.

  5. Cree un servicio en la nube (o una red virtual independiente) para los nodos de proxy de aplicación web.

  6. Implemente los nodos de proxy de aplicación web en el servicio en la nube o red virtual

    1. Cree un conjunto de carga equilibrada externo que incluya los nodos de proxy de aplicación web.

    2. Actualice el nombre DNS externo (FQDN) para que señale a la dirección IP pública (VIP) del servicio en la nube.

    3. Configure los servidores proxy de AD FS para que usen el FQDN que corresponde al conjunto de carga equilibrada interno para los servidores de AD FS.

    4. Actualice los sitios web basados en notificaciones para que usen el FQDN externo para su proveedor de notificaciones.

  7. Restrinja el acceso entre el proxy de aplicación web a cualquier máquina en la red virtual de AD FS.

Para restringir el tráfico, el conjunto de carga equilibrada para el equilibrador de carga interno de Azure se debe configurar solo para el tráfico a los puertos 80 y 443 de TCP y eliminar todo el resto de tráfico al DIP interno del conjunto de carga equilibrada.

Listas ACL de red de ADFS

Solo los orígenes siguientes permitirán el tráfico a los servidores AD FS:

  • El equilibrador de carga interno de Azure.

  • La dirección IP de un administrador de la red local.

WarningAdvertencia
El diseño debe impedir que los nodos de proxy de aplicación web lleguen a otras máquinas virtuales en la red virtual de Azure o cualquier ubicación en la red local. Esto se puede hacer mediante la configuración de reglas de firewall en el dispositivo local para las conexiones de Express Route o el dispositivo VPN para las conexiones VPN de sitio a sitio.

Una desventaja de esta opción es la necesidad de configurar las ACL de red para varios dispositivos, incluidos el equilibrador de carga interno, los servidores de AD FS y cualquier otro servidor que se agregue a la red virtual. Si cualquier dispositivo se agrega a la implementación sin configurar las ACL de red para restringir el tráfico, toda la implementación puede estar en peligro. Si alguna vez cambian las direcciones IP de los nodos de proxy de aplicación web, se deben restablecer las ACL de red (lo que significa que los servidores proxy deben configurarse para usar DIP estáticas).

ADFS en Azure con listas ACL de red

Otra opción es usar el dispositivo Barracuda NG Firewall para controlar el tráfico entre los servidores proxy de AD FS y los servidores de AD FS. Esta opción cumple con los procedimientos recomendados para alta disponibilidad y seguridad, y requiere menos administración después de la instalación inicial porque el dispositivo Barracuda NG Firewall proporciona un modo de administración del firewall de lista blanca y se puede instalar directamente en una red virtual de Azure. Así se elimina la necesidad de configurar las ACL de red cada vez que se agrega un nuevo servidor a la implementación. Pero esta opción agrega coste y complejidad a la implementación inicial.

En este caso, se implementan dos redes virtuales en lugar de una. VNet 1 contiene los servidores proxy y VNet 2 contiene los STS y la conexión de red de vuelta a la red corporativa; VNet 1 está, por tanto, físicamente (aunque prácticamente) aislada de VNet 2 y, a su vez, de la red corporativa. VNet 1, a continuación, se conecta a VNet2 mediante una tecnología de túnel especial conocida como Transport Independent Network Architecture (TINA). El túnel TINA se conecta a cada una de las redes virtuales mediante un dispositivo Barracuda NG Firewall (un Barracuda en cada una de las redes virtuales). Para alta disponibilidad, es recomendable que implemente dos Barracudas en cada red virtual; uno activo y el otro pasivo. Ofrecen capacidades de firewall extremadamente abundantes que nos permiten imitar la operación de una red perimetral local tradicional en Azure.

ADFS en Azure con firewall

Para obtener más información, consulte 2. AD FS: extender a Internet una aplicación front-end local para notificaciones.

Una alternativa para la implementación de AD FS si el objetivo es solo Office 365 SSO

Hay otra alternativa para implementar AD FS completamente si su objetivo es solo habilitar el inicio de sesión para Office 365. En este caso, puede implementar localmente DirSync con sincronización de contraseñas y lograr el mismo resultado final con una mínima complejidad de implementación, ya que este enfoque no requiere AD FS o Azure.

En la tabla siguiente se compara el funcionamiento de los procesos de inicio de sesión con y sin implementar AD FS.

 

Inicio de sesión único de Office 365 con AD FS y DirSync El mismo inicio de sesión de Office 365 con DirSync + sincronización de contraseña
  1. El usuario inicia sesión en una red corporativa y se autentica en Windows Server Active Directory.

  2. El usuario intenta obtener acceso a Office 365 (nombre@contoso.com).

  3. Office 365 redirige al usuario a Azure AD.

  4. Puesto que Azure AD no puede autenticar al usuario y entiende que hay una confianza con el AD FS local, redirige al usuario a AD FS

  5. El usuario envía un vale Kerberos al STS de AD FS.

  6. AD FS transforma el vale Kerberos en el formato de token o las notificaciones necesarios y redirige al usuario a Azure AD.

  7. El usuario se autentica en Azure AD (se produce otra transformación).

  8. Azure AD redirige al usuario a Office 365.

  9. El usuario inicia sesión en Office 365 de forma silenciosa

  1. El usuario inicia sesión en una red corporativa y se autentica en Windows Server Active Directory.

  2. El usuario intenta obtener acceso a Office 365 (nombre@contoso.com).

  3. Office 365 redirige al usuario a Azure AD.

  4. Azure AD no puede aceptar vales Kerberos directamente y no existe ninguna relación de confianza, por lo que solicita al usuario que especifique sus credenciales.

  5. El usuario especifica la misma contraseña local y Azure AD la valida con el nombre de usuario y la contraseña que DirSync sincronizó.

  6. Azure AD redirige al usuario a Office 365.

  7. El usuario puede iniciar sesión en Office 365 y OWA con el token de Azure AD.

En el escenario de Office 365 con DirSync con sincronización de contraseñas (sin AD FS), el inicio de sesión único se reemplaza por el "mismo inicio de sesión" donde "mismo" significa que los usuarios deben volver a escribir las mismas credenciales locales al acceder a Office 365. Tenga en cuenta que estos datos se pueden guardar en el explorador del usuario para ayudar a reducir el número de solicitudes posteriores. En el escenario de DirSync + sincronización de contraseñas (sin AD FS), el inicio de sesión único se reemplaza por el "mismo inicio de sesión" donde "mismo" significa que los usuarios deben volver a escribir las mismas credenciales locales al acceder a Office 365. Tenga en cuenta que estos datos se pueden guardar para ayudar a reducir el número de solicitudes posteriores.

Elementos adicionales para la reflexión

  • Si implementa un proxy de AD FS en una máquina virtual de Azure, se necesita conectividad con los servidores de AD FS. Si son locales, se recomienda que aproveche la conectividad de VPN de sitio a sitio que proporciona la red virtual para permitir que los nodos de proxy de aplicación web se comuniquen con sus servidores de AD FS.

  • Si implementa un servidor de AD FS en máquinas virtuales de Azure, es necesaria la conectividad con los controladores de dominio de Active Directory de Windows Server, los almacenes de atributos y las bases de datos de configuración y puede requerir también una ExpressRoute o una conexión VPN de sitio a sitio entre la red virtual de Azure y la red local.

  • Se le cobrará por todo el tráfico desde las máquinas virtuales de Azure (tráfico de salida). Si el coste es un factor determinante, es conveniente implementar los nodos de proxy de aplicación web, dejando los servidores de AD FS locales. Si los servidores de AD FS también se implementan en máquinas virtuales de Azure, se aplicarán cargos adicionales para autenticar a los usuarios locales. El tráfico de salida supone un coste independientemente de si atraviesa o no la ExpressRoute o la conexión VPN de sitio a sitio.

  • Si decide usar las capacidades de equilibrio de carga del servidor nativas de Azure para lograr alta disponibilidad de los servidores de AD FS, tenga en cuenta que el equilibrio de carga proporciona sondeos que se usan para determinar el estado de las máquinas virtuales dentro del servicio en la nube. En el caso de máquinas virtuales de Azure (no de los roles web o de trabajo), se debe utilizar un sondeo personalizado, ya que el agente que responde a los sondeos predeterminados no está presente en las máquinas virtuales de Azure. Para simplificar, puede usar un sondeo TCP personalizado: solo requiere que una conexión TCP (un segmento TCP SYN enviado y respondido con un segmento TCP SYN ACK) se establezca correctamente para determinar el estado de la máquina virtual. Puede configurar el sondeo personalizado para que use cualquier puerto TCP que las máquinas virtuales estén escuchando activamente. Para ello, consulte Configurar un conjunto de carga equilibrada.

    noteNota
    Los equipos que necesitan exponer el mismo conjunto de puertos directamente en Internet (como los puertos 80 y 443) no pueden compartir el mismo servicio en la nube. Por tanto, se recomienda crear un servicio en la nube dedicado para los servidores de Windows Server AD FS con el fin de evitar posibles superposiciones entre los requisitos de puertos de una aplicación y Windows Server AD FS.

En la próxima sección se describen los escenarios de implementación comunes que requieren tener en cuenta ciertas consideraciones importantes. Cada escenario contiene vínculos a más detalles sobre las decisiones y los factores que se deben tener en cuenta.

Implementación de AD DS solo en la nube

Ilustración 1

SharePoint se implementa en una máquina virtual de Azure y la aplicación no tiene ninguna dependencia de recursos de la red corporativa. La aplicación requiere Windows Server AD DS pero NO requiere Windows Server AD DS corporativo. No se necesitan confianzas Kerberos ni federadas porque los usuarios se aprovisionan automáticamente en la aplicación en el dominio de Windows Server AD DS que también se hospeda en la nube en máquinas virtuales de Azure.

  • Topología de red: cree una red virtual de Azure sin conectividad entre instalaciones (también conocida como conectividad de sitio a sitio).

  • Configuración de implementación de controlador de dominio: implemente un nuevo controlador de dominio en un bosque nuevo de un solo dominio de Windows Server Active Directory. Se debe implementar junto con el servidor DNS de Windows.

  • Topología de sitio de Windows Server Active Directory: utilice el sitio predeterminado de Windows Server Active Directory (todos los equipos estarán en Default-First-Site-Name)

  • Direccionamiento IP y DNS:

    • Establezca una dirección IP estática para el controlador de dominio usando el cmdlet Set-AzureStaticVNetIP de Azure PowerShell.

    • Instale y configure DNS de Windows Server en el controlador o los controladores de dominio de Azure.

    • Configure las propiedades de la red virtual con el nombre y la dirección IP de la máquina virtual donde se hospedan los roles de servidor de DC y DNS.

  • Catálogo global: el primer controlador de dominio del bosque debe ser un servidor de catálogo global. También se deben configurar otros controladores de dominio como catálogos globales, ya que en un bosque de un solo dominio, el catálogo global no requiere ningún trabajo adicional del controlador de dominio.

  • Colocación de la base de datos y de SYSVOL de Windows Server AD DS: agregue un disco de datos a los controladores de dominio que se ejecutan como máquinas virtuales de Azure para almacenar la base de datos, los registros y SYSVOL de Windows Server Active Directory.

  • Copias de seguridad y restauración: determine dónde desea almacenar las copias de seguridad de estado del sistema. Si es necesario, agregue otro disco de datos a la máquina virtual del controlador de dominio para almacenar las copias de seguridad.

Federación con conectividad entre entornos

Ilustración 2

Una aplicación para notificaciones que se ha implementado correctamente de forma local y que la usan usuarios corporativos debe ser accesible directamente desde Internet. La aplicación actúa como front-end web de una base de datos SQL en la que almacena y recupera datos. Los servidores SQL que usa la aplicación también se encuentran en la red corporativa. Se han implementado de forma local dos STS de Windows Server AD FS y un equilibrador de carga para proporcionar acceso a los usuarios corporativos. La aplicación necesita ahora ser accesible directamente a través de Internet por parte de asociados empresariales mediante sus propias identidades corporativas y de usuarios corporativos existentes.

En un intento de simplificar y satisfacer las necesidades de implementación y configuración de este nuevo requisito, se decidió instalar dos front-ends web adicionales y dos servidores proxy de Windows Server AD FS en máquinas virtuales de Azure. Las cuatro máquinas virtuales se expondrán directamente a Internet y se proporcionará conectividad con la red local mediante la capacidad de VPN de sitio a sitio de la red virtual de Azure.

  • Topología de red: cree una Red virtual de Azure y configure la conectividad entre entornos.

    noteNota
    Para cada uno de los certificados de Windows Server AD FS, asegúrese de que las instancias de Windows Server AD FS que se ejecutan en Azure pueden tener acceso a la dirección URL definida dentro de la plantilla de certificado y a los certificados resultantes. Esto puede requerir conectividad entre entornos con partes de la infraestructura de PKI. Por ejemplo, si el extremo de la lista de revocación de certificados (CRL) se basa en LDAP y se hospeda exclusivamente de forma local, será necesaria la conectividad entre entornos. Si esto no es deseable, puede ser necesario utilizar certificados emitidos por una entidad de certificación cuya CRL sea accesible a través de Internet.

  • Configuración de servicios en la nube: asegúrese de que tiene dos servicios en la nube para proporcionar dos VIP con equilibrio de carga. La primera dirección VIP del servicio en la nube se dirigirá a las dos máquinas virtuales de proxy de Windows Server AD FS en los puertos 80 y 443. Las máquinas virtuales de proxy de Windows Server AD FS se configurarán para que señalen a la dirección IP del equilibrador de carga local que atiende a los STS de Windows Server AD FS. La segunda dirección VIP del servicio en la nube se dirigirá a las dos máquinas virtuales que ejecutan el front-end web en los puertos 80 y 443. Configure un sondeo personalizado para asegurarse de que el equilibrador de carga solo dirige tráfico a la máquina virtual de proxy de Windows Server AD FS y a la máquina virtual que ejecuta el front-end web.

  • Configuración del servidor de federación: configure Windows Server AD FS como un servidor de federación (STS) con el fin de generar tokens de seguridad para el bosque de Windows Server Active Directory creado en la nube. Establezca relaciones de confianza del proveedor de notificaciones de la federación con los distintos asociados de los que desea aceptar identidades y configure relaciones de confianza para usuario autenticado con las distintas aplicaciones para las que desea generar tokens.

    En la mayoría de los escenarios, los servidores proxy de Windows Server AD FS se implementan con conexión a Internet por razones de seguridad, mientras que sus homólogos de una federación de Windows Server AD FS permanecen aislados de la conectividad directa a Internet. Cualquiera que sea su escenario de implementación, debe configurar el servicio en la nube con una VIP que proporcione una dirección IP expuesta públicamente y un puerto que sea capaz de equilibrar la carga entre las dos instancias de STS o de proxy de Windows Server AD FS.

  • Configuración de alta disponibilidad de Windows Server AD FS: es conveniente implementar una granja de servidores de Windows Server AD FS que tenga al menos dos servidores para la conmutación por error y el equilibrio de carga. Puede considerar la posibilidad de usar Windows Internal Database (WID) para los datos de configuración de Windows Server AD FS y utilizar la capacidad de equilibrio de carga interno de Azure para distribuir las solicitudes entrantes entre los servidores de la granja.

    Para obtener más información, consulte la Guía de implementación de AD FS.

Implementación de AD DS entre entornos

Ilustración 3

Una aplicación compatible con LDAP que admite autenticación integrada de Windows y usa Windows Server AD DS como repositorio de datos de configuración y de perfiles de usuario se implementa en una máquina virtual de Azure. Es conveniente que la aplicación aproveche el Windows Server AD DS corporativo existente y proporcione inicio de sesión único. La aplicación no es compatible con notificaciones. Los usuarios también necesitan tener acceso a la aplicación directamente desde Internet. Para optimizar el rendimiento y el costo, se decide implementar en Azure dos controladores de dominio adicionales que forman parte del dominio corporativo junto con la aplicación.

  • Topología de red: cree una red virtual de Azure y configure la conectividad entre instalaciones.

  • Método de instalación: implemente controladores de dominio de réplica desde el dominio corporativo de Windows Server Active Directory. En un controlador de dominio de réplica, puede instalar Windows Server AD DS en la máquina virtual y, opcionalmente, utilizar la característica Instalar desde medios (IFM) para reducir la cantidad de datos que es necesario replicar en el nuevo controlador de dominio durante la instalación. Encontrará el tutorial en Instalar un controlador de dominio de Active Directory de réplica en Azure. Incluso aunque utilice IFM, puede ser más eficaz crear el controlador de dominio virtual de forma local y mover todo el VHD a la nube en lugar de replicar Windows Server AD DS durante la instalación. Por motivos de seguridad, se recomienda eliminar el VHD de la red local una vez que se haya copiado a Azure.

  • Topología de sitio de Windows Server Active Directory: cree un sitio nuevo de Azure en Sitios y servicios de Active Directory. Cree un objeto de subred de Windows Server Active Directory para representar la red virtual de Azure y agregue la subred el sitio. Cree un nuevo vínculo de sitio que incluya el nuevo sitio de Azure y el sitio en el que se encuentra el extremo de VPN de red virtual de Azure para controlar y optimizar el tráfico de Windows Server Active Directory hacia y desde Azure.

  • Direccionamiento IP y DNS:

    • Establezca una dirección IP estática para el controlador de dominio usando el cmdlet Set-AzureStaticVNetIP de Azure PowerShell.

    • Instale y configure DNS de Windows Server en el controlador o los controladores de dominio de Azure.

    • Configure las propiedades de la red virtual con el nombre y la dirección IP de la máquina virtual donde se hospedan los roles de servidor de DC y DNS.

  • Controladores de dominio distribuidos geográficamente: configure las redes virtuales adicionales que necesite. Si la topología del sitio de Active Directory necesita controladores de dominio en geografías que corresponden a regiones de Azure diferentes, querrá crear sitios de Active Directory en consecuencia.

  • Controladores de dominio de solo lectura: puede implementar un controlador de dominio de solo lectura (RODC) en el sitio de Azure, en función de los requisitos para realizar operaciones de escritura en el controlador de dominio y la compatibilidad de aplicaciones y servicios en el sitio que tiene los RODC. Para obtener más información sobre la compatibilidad de aplicaciones, vea Guía de compatibilidad de aplicaciones con controladores de dominio de solo lectura.

  • Catálogo global: se necesitan catálogos globales para atender las solicitudes de inicio de sesión en los bosques de varios dominios. Si no implementa un catálogo global en el sitio de Azure, incurrirá en costos de tráfico de salida porque las solicitudes de autenticación generan consultas de catálogos globales en otros sitios. Para minimizar ese tráfico, puede habilitar Caché de pertenencia al grupo universal para el sitio de Azure en Sitios y servicios de Active Directory.

    Si implementa un catálogo global, configure los vínculos de sitio y los costos de vínculo de sitio de forma que otros catálogos globales que necesitan replicar las mismas particiones parciales de dominio no prefieran el catálogo global del sitio de Azure como controlador de dominio de origen.

  • Colocación de la base de datos y de SYSVOL de Windows Server AD DS: agregue un disco de datos a los controladores de dominio que se ejecutan en máquinas virtuales de Azure para almacenar la base de datos, los registros y SYSVOL de Windows Server Active Directory.

  • Copias de seguridad y restauración: determine dónde desea almacenar las copias de seguridad de estado del sistema. Si es necesario, agregue otro disco de datos a la máquina virtual del controlador de dominio para almacenar las copias de seguridad.

En esta tabla se resumen las áreas de tecnología de Windows Server Active Directory que se ven afectadas en los escenarios anteriores, así como las decisiones correspondientes que hay que tener en cuenta y vínculos a información más detallada. Algunas áreas de tecnología podrían no ser aplicables a todos los escenarios de implementación y algunas áreas de tecnología pueden ser más críticas que otras en un escenario de implementación determinado.

Por ejemplo, si implementa un controlador de dominio de réplica en una red virtual y el bosque solo tiene un dominio, la elección de implementar un servidor de catálogo global en ese caso no será crítica para el escenario de implementación, ya que no creará ningún requisito de replicación adicional. Por otra parte, si el bosque tiene varios dominios, la decisión de implementar un catálogo global en una red virtual puede afectar al ancho de banda disponible, el rendimiento, la autenticación, las búsquedas en directorios, etc.

 

Número de elemento

Área de tecnología de Windows Server Active Directory

Decisiones

Factores

1

Topología de red

¿Crear una red virtual?

Requisitos de acceso a recursos corporativos

Autenticación

Administración de cuentas

2

Configuración de implementación de controlador de dominio

  • ¿Implementar un bosque independiente sin confianzas?

  • ¿Implementar un nuevo bosque con federación?

  • ¿Implementar un nuevo bosque con confianza de bosque de Windows Server Active Directory para Kerberos?

  • ¿Extender el bosque corporativo implementando un controlador de dominio de réplica?

  • ¿Extender el bosque corporativo implementando un nuevo dominio secundario o un árbol de dominios?

Seguridad

Conformidad

Costo

Resistencia y tolerancia a errores

Compatibilidad de aplicaciones

3

Topología de sitio de Windows Server Active Directory

¿Cómo configurar subredes, sitios y vínculos de sitio con Red virtual de Azure para optimizar el tráfico y minimizar el costo?

Definiciones de subred y sitio

Propiedades y notificación de cambios de vínculos de sitio

Compresión de replicación

4

Direccionamiento IP y DNS

¿Cómo configurar direcciones IP y la resolución de nombres?

Use el cmdlet Set-AzureStaticVNetIP para asignar una dirección IP estática

Instale el servidor DNS de Windows Server y configure las propiedades de la red virtual con el nombre y la dirección IP de la máquina virtual donde se hospedan los roles de servidor de DC y DNS.

5

Controladores de dominio distribuidos geográficamente

¿Cómo replicar en controladores de dominio de redes virtuales diferentes?

Si la topología del sitio de Active Directory necesita controladores de dominio en geografías que corresponden a regiones de Azure diferentes, querrá crear sitios de Active Directory en consecuencia. Configure la conectividad de VNet a VNet para replicar entre controladores de dominio en Vnet separadas.

6

Controladores de dominio de solo lectura

¿Usar controladores de dominio de solo lectura o con posibilidad de escritura?

Filtrar atributos HBI/PII

Filtrar secretos

Limitar el tráfico de salida

7

Catálogo global

¿Instalar catálogo global?

En bosques de un solo dominio, hacer que todos los controladores de dominio sean catálogos globales

En bosques de varios dominios, se necesitan catálogos globales para la autenticación

8

Método de instalación

¿Cómo instalar un controlador de dominio en Azure?

  • Instalar AD DS mediante Windows PowerShell o Dcpromo

- O bien -

  • Mover el VHD de un controlador de dominio virtual local

9

Colocación de la base de datos y de SYSVOL de Windows Server AD DS

¿Dónde almacenar la base de datos, los registros y SYSVOL de Windows Server AD DS?

Cambiar valores predeterminados de Dcpromo.exe

ImportantImportante
Estos archivos críticos de Active Directory DEBEN colocarse en discos de datos de Azure en lugar de en discos del sistema operativo que implementan almacenamiento en caché de escritura.

10

Copias de seguridad y restauración

¿Cómo proteger y recuperar datos?

Crear copias de seguridad de estado del sistema

11

Configuración del servidor de federación

¿Implementar un nuevo bosque con federación en la nube?

¿Implementar AD FS local y exponer un proxy en la nube?

Seguridad

Conformidad

Costo

Acceso a las aplicaciones por parte de asociados empresariales

12

Configuración de servicios en la nube

Un servicio en la nube se implementa implícitamente la primera vez que se crea una máquina virtual. ¿Necesita implementar servicios en la nube adicionales?

¿Necesitan las máquinas virtuales una exposición directa a Internet?

¿Necesita el servicio equilibrio de carga?

13

Requisitos del servidor de federación para direccionamiento de IP público y privado (DIP frente a VIP)

¿Necesita la instancia de Windows Server AD FS ser accesible directamente desde Internet?

¿Necesita la aplicación que se va a implementar en la nube su propia dirección IP y puerto con conexión a Internet?

Crear un servicio en la nube para cada VIP que necesite la implementación

14

Configuración de alta disponibilidad de Windows Server AD FS

¿Cuántos nodos debe tener mi granja de servidores de Windows Server AD FS?

¿Cuántos nodos tengo que implementar en mi granja de proxy de Windows Server AD FS?

Resistencia y tolerancia a errores

Con el fin de cumplir los requisitos de DNS y de coherencia de las direcciones IP de Windows Server AD DS, es necesario crear una red virtual de Azure y conectar sus máquinas virtuales a ella. Durante su creación, debe decidir si desea ampliar la conectividad a la red corporativa local, que conecta de forma transparente máquinas virtuales de Azure con equipos locales; esto se logra mediante tecnologías tradicionales de VPN y requiere exponer un extremo de VPN en el borde de la red corporativa. Es decir, la VPN se inicia desde Azure hasta la red corporativa, no al contrario.

Tenga en cuenta que al extender una red virtual a la red local se aplican cargos adicionales, además de los cargos estándar que se aplican a cada máquina virtual. En concreto, se cobra por el tiempo de CPU de la puerta de enlace de Red virtual de Azure y por el tráfico de salida generado por cada máquina virtual que se comunica con equipos locales a través de la VPN. Para obtener más información sobre los cargos de tráfico de red, vea Precios de Azure de un vistazo.

La forma de configurar el controlador de dominio depende de los requisitos del servicio que desea ejecutar en Azure. Por ejemplo, puede implementar un nuevo bosque, aislado de su propio bosque corporativo, para probar una prueba de concepto, una nueva aplicación o algún otro proyecto de corta duración que requiere servicios de directorio pero no necesita un acceso específico a recursos internos corporativos.

Esto tiene la ventaja de que un controlador de dominio de un bosque aislado no se replica con controladores de dominio locales, lo que hace que el sistema genere menos tráfico de red de salida y, por tanto, reduce directamente los costos. Para obtener más información sobre los cargos de tráfico de red, vea Precios de Azure de un vistazo.

Para ver otro ejemplo, suponga que tiene requisitos de privacidad para un servicio, pero el servicio necesita acceso a su Windows Server Active Directory interno. Si se le permite hospedar datos para el servicio en la nube, podría implementar un nuevo dominio secundario en su bosque interno en Azure. En este caso, puede implementar un controlador de dominio para el nuevo dominio secundario (sin el catálogo global para ayudar a solucionar los aspectos de privacidad). Este escenario, junto con la implementación de un controlador de dominio de réplica, requiere una red virtual para la conectividad con los controladores de dominio locales.

Si crea un nuevo bosque, elija si desea utilizar Confianzas de bosque de Active Directory o Confianzas de federación. Debe lograr un equilibrio entre los requisitos que imponen los aspectos de compatibilidad, seguridad, compatibilidad, costo y resistencia. Por ejemplo, para aprovechar la autenticación selectiva, puede implementar un nuevo bosque en Azure y crear una confianza de Windows Server Active Directory entre el bosque local y el bosque de la nube. Sin embargo, si se trata de una aplicación para notificaciones, puede implementar confianzas de federación en lugar de confianzas de bosque de Active Directory. Otro factor que hay que tener en cuenta es el costo que supone replicar más datos extendiendo a la nube su Windows Server Active Directory local o generar más tráfico de salida como resultado de la autenticación y de la carga de consultas.

Los requisitos de disponibilidad y tolerancia a errores también afectan a su elección. Por ejemplo, si se interrumpe el vínculo, es probable que todas las aplicaciones que aprovechan una confianza Kerberos o una confianza de federación dejen de funcionar a menos que haya implementado una infraestructura suficiente en Azure. Las configuraciones de implementación alternativas como los controladores de dominio de réplica (con posibilidad de escritura o RODC) aumentan la probabilidad de que puedan tolerar interrupciones del vínculo.

Debe definir correctamente los sitios y los vínculos de sitio para optimizar el tráfico y minimizar el costo. Los sitios, los vínculos de sitio y las subredes afectan a la topología de replicación entre los controladores de dominio y el flujo de tráfico de autenticación. Tenga en cuenta los cargos de tráfico siguientes y, a continuación, implemente y configure los controladores de dominio según los requisitos de su escenario de implementación:

  • Hay una cuota nominal por hora para la puerta de enlace propiamente dicha:

    • Se puede iniciar y detener como considere oportuno

    • Si se detiene, las máquinas virtuales de Azure quedan aisladas de la red corporativa

  • El tráfico de entrada es gratuito

  • El tráfico de salida se cobra de acuerdo con lo indicado en Precios de Azure de un vistazo. Puede optimizar las propiedades de vínculo de sitio entre los sitios locales y los sitios en la nube de la manera siguiente:

    • Si usa varias redes virtuales, configure correctamente los vínculos de sitio y sus costos para evitar que Windows Server AD DS dé prioridad al sitio de Azure sobre uno que puede proporcionar los mismos niveles de servicio de forma gratuita. Puede que también desee considerar la posibilidad de deshabilitar la opción Enlazar todos los vínculos a sitios (BASL), que está habilitada de forma predeterminada. Esto garantiza que solo los sitios con conexión directa se replican entre sí. Los controladores de dominio de sitios conectados de forma transitiva ya no pueden replicarse directamente entre sí; en su lugar, se deben replicar a través de uno o varios sitios comunes. Si los sitios intermedios dejan de estar disponible por alguna razón, la replicación entre los controladores de dominio de sitios conectados de forma transitiva no se realizará aunque haya disponible conectividad entre los sitios. Por último, donde sea conveniente que se sigan produciendo secciones de comportamiento de replicación transitiva, cree puentes de vínculo de sitio que contengan los sitios y los vínculos de sitio adecuados, por ejemplo sitios locales de la red corporativa.

    • Configure los costos de vínculo de sitio correctamente para evitar tráfico no deseado. Por ejemplo, si se ha habilitado el valor Intentar siguiente sitio más cercano, asegúrese de que los sitios de la red virtual no sean el siguiente más cercano; para ello, aumente el costo asociado del objeto de vínculo de sitio que vuelve a conectar el sitio de Azure a la red corporativa.

    • Configure los intervalos de vínculo de sitio y las programaciones de acuerdo con los requisitos de coherencia y la tasa de cambios de objetos. Nivele la programación de replicación con la tolerancia de latencia. Los controladores de dominio solo replican el último estado de un valor, por lo que la reducción del intervalo de replicación puede ahorrar costos si hay una tasa de cambio de objetos suficiente.

  • Si la reducción de costos es una prioridad, asegúrese de que la replicación esté programada y la notificación de cambios no esté habilitada; esta es la configuración predeterminada cuando se replica entre sitios. Esto no es importante si va a implementar un RODC en una red virtual, ya que el RODC no replicará ningún cambio de salida. Sin embargo, si implementa un controlador de dominio con posibilidad de escritura, debe asegurarse de que el vínculo de sitio no esté configurado para replicar actualizaciones con una frecuencia innecesaria. Si implementa un servidor de catálogo global, asegúrese de que uno de cada dos sitios que contiene un catálogo global replique las particiones de dominio desde un controlador de dominio de origen en un sitio que está conectado con uno o varios vínculos de sitio que tienen un costo menor que el catálogo global del sitio de Azure.

  • Es posible reducir aún más el tráfico de red generado por la replicación entre sitios si se cambia el algoritmo de compresión de replicación. El algoritmo de compresión se controla mediante el valor REG_DWORD de la entrada del Registro HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\Replicator compression algorithm. El valor predeterminado es 3, que corresponde al algoritmo de compresión Xpress. Puede cambiar el valor a 2, lo que cambia el algoritmo a MSZip. En la mayoría de los casos, esto aumentará la compresión, pero a costa del uso de CPU. Para obtener más información, consulte Cómo funciona la topología de replicación de Active Directory.

A las máquinas virtuales de Azure se les asignan "direcciones cedidas por DHCP" de manera predeterminada. Puesto que las direcciones dinámicas de red virtual de Azure se conservan con una máquina virtual mientras dura la máquina virtual, se cumplen los requisitos de Windows Server AD DS.

Por tanto, cuando utilice una dirección dinámica en Azure, estará usando a todos los efectos una dirección IP estática porque es enrutable mientras dura la concesión, y el período de la concesión es igual que la duración del servicio en la nube.

Sin embargo, la asignación de las direcciones dinámicas se cancela cuando se apaga la máquina virtual. Para evitar que se cancele la asignación de la dirección IP, puede usar el cmdlet Set-AzureStaticVNetIP para asignar una dirección IP estática.

En cuanto a la resolución de nombres, implemente su propia infraestructura de servidor DNS (o aproveche la infraestructura existente); el DNS proporcionado por Azure no satisface las necesidades avanzadas de resolución de nombres de Windows Server AD DS. Por ejemplo, no admite registros SRV dinámicos. La resolución de nombres es un elemento de configuración crítico para los controladores de dominio y los clientes que se han unido al dominio. Los controladores de dominio deben ser capaces de registrar registros de recursos y resolver registros de recursos de otros controladores de dominio.

Por razones de tolerancia a errores y rendimiento, resulta óptimo instalar el servicio DNS de Windows Server en los controladores de dominio que se ejecutan en Azure. A continuación, configure las propiedades de la red virtual de Azure con el nombre y la dirección IP del servidor DNS. Cuando se arrancan otras máquinas virtuales de la misma red, se configuran las propiedades de su solucionador cliente DNS con el servidor DNS como parte de la asignación de direcciones IP dinámicas.

noteNota
No puede unir equipos locales a un dominio de Active Directory de Windows Server AD DS que se hospeda en Azure directamente a través de Internet. Los requisitos de puerto de Active Directory y la operación de unión al dominio hacen que sea poco práctico exponer directamente a Internet los puertos necesarios y todo un controlador de dominio.

Las máquinas virtuales registran automáticamente su nombre DNS al iniciarse o cuando hay un cambio de nombre.

Para obtener más información acerca de este ejemplo y otro ejemplo que muestra cómo aprovisionar la primera máquina virtual e instalar AD DS en ella, vea Instalar un nuevo bosque de Active Directory en Azure. Para obtener más información sobre cómo usar Windows PowerShell, vea Introducción a Azure PowerShell y Cmdlets de administración de Azure.

Windows Azure ofrece diversas ventajas cuando se hospedan varios controladores de dominio en redes virtuales diferentes:

  • Tolerancia a errores multisitio

  • Proximidad física a las sucursales (menor latencia)

Para obtener información sobre la configuración de la comunicación directa entre redes virtuales, vea Configurar la conectividad de VNet a VNet.

Necesita elegir si va a implementar controladores de dominio de solo lectura o con posibilidad de escritura. Puede que se incline por implementar RODC porque no tendrá control físico sobre ellos, pero los RODC están diseñados para implementarse en ubicaciones donde está en peligro la seguridad física, como las sucursales.

Windows Azure no presenta el riesgo de seguridad física de una sucursal, pero los RODC siguen siendo más rentables porque las características que proporcionan son adecuadas para estos entornos aunque por motivos muy diferentes. Por ejemplo, los RODC no tienen ninguna replicación de salida y pueden rellenar selectivamente secretos (contraseñas). El aspecto negativo es que la falta de estos secretos puede requerir tráfico de salida a petición para su validación a medida que un usuario o un equipo se autentica. Sin embargo, los secretos se pueden rellenar previamente y almacenar en memoria caché de forma selectiva.

Los RODC proporcionan una ventaja adicional en cuanto a las preocupaciones de HBI y PII, ya que puede agregar atributos que contienen datos confidenciales al conjunto de atributos con filtro (FAS) RODC. FAS es un conjunto personalizable de atributos que no se replican en los RODC. Puede utilizar FAS como medida de seguridad en caso de que no se le permita o no desee almacenar PII o HBI en Windows Azure. Para obtener más información, consulte Conjunto de atributos con filtro RODC.

Asegúrese de que las aplicaciones sean compatibles con los RODC que piensa utilizar. Muchas aplicaciones compatibles con Windows Server Active Directory funcionan correctamente con los RODC, pero algunas aplicaciones pueden tener un funcionamiento poco eficaz o generar un error si no tienen acceso a un controlador de dominio con posibilidad de escritura. Para obtener más información, consulte Compatibilidad de aplicaciones con controladores de dominio de solo lectura.

Debe elegir si desea instalar un catálogo global. En un bosque de un solo dominio, debe configurar todos los controladores de dominio como servidores de catálogo global (GC). No aumentará los costos porque no habrá tráfico de replicación adicional.

En un bosque de varios dominios, los catálogos globales son necesarios para expandir la pertenencia al grupo universal durante el proceso de autenticación. Si no implementa un catálogo global, las cargas de trabajo de la red virtual que se autentican en un controlador de dominio en Windows Azure generarán indirectamente tráfico de autenticación de salida para consultar los catálogos globales locales durante cada intento de autenticación.

Los costos asociados a los catálogos globales son menos predecibles porque hospedan todos los dominios (en parte). Si la carga de trabajo hospeda un servicio con conexión a Internet y autentica usuarios en Windows Server AD DS, los costos podrían ser completamente imprevisibles. Para ayudar a reducir las consultas de catálogos globales fuera del sitio en la nube durante la autenticación, puede habilitar Caché de pertenencia al grupo universal.

Debe elegir cómo instalar los controladores de dominio en la red virtual:

Utilice solo máquinas virtuales de Azure para los controladores de dominio (en lugar de máquinas virtuales de rol "web" o "de trabajo" de Windows Azure). Son duraderas y se necesita durabilidad de estado para un controlador de dominio. Las Máquinas virtuales de Azure están diseñadas para cargas de trabajo como los controladores de dominio.

No utilice SYSPREP para implementar o clonar controladores de dominio. La posibilidad de clonar controladores de dominio solo se encuentra disponible en Windows Server 2012. La característica de clonación requiere compatibilidad con VMGenerationID en el hipervisor subyacente. Hyper-V de Windows Server 2012 y Redes virtuales de Windows Azure admiten VMGenerationID, así como otros proveedores terceros de software de virtualización.

Seleccione dónde va a colocar la base de datos, los registros y SYSVOL de Windows Server AD DS. Se deben implementar en discos de datos de Azure. “

noteNota
Los discos de datos de Azure están limitados a 1 TB.

De manera predeterminada, las unidades de discos de datos no almacenan en memoria caché las escrituras. Las unidades de disco de datos conectadas a una máquina virtual emplean almacenamiento en caché de escritura simultánea. El almacenamiento en caché de escritura simultánea garantiza que la escritura se confirma en almacenamiento de Azure duradero antes de que se complete la transacción desde la perspectiva del sistema operativo de la máquina virtual. Proporciona durabilidad, a costa de escrituras ligeramente más lentas.

Esto es importante para Windows Server AD DS, ya que el almacenamiento en caché de escritura por detrás invalida los supuestos realizados por el controlador de dominio. Windows Server AD DS intenta deshabilitar el almacenamiento en caché de las escrituras, pero es decisión del sistema de E/S de disco respetarlo. Si no se deshabilita el almacenamiento en caché de las escrituras, en determinadas circunstancias pueden revertirse los USN, dando lugar a objetos persistentes y otros problemas.

Como práctica recomendada para los controladores de dominio virtuales, haga lo siguiente:

  • Establezca la opción Preferencia de caché de host en el disco de datos de Azure en NINGUNO. Así evitará problemas con el almacenamiento en caché de las escrituras en las operaciones de AD DS.

  • Almacene la base de datos, los registros y SYSVOL en el mismo disco de datos o en discos de datos diferentes. Normalmente, se trata de un disco diferente del disco utilizado para el sistema operativo propiamente dicho. La conclusión principal es que la base de datos y SYSVOL de Windows Server AD DS no se deben almacenar en un tipo de disco del sistema operativo de Azure. De forma predeterminada, el proceso de instalación de AD DS instala estos componentes en la carpeta %systemroot%, que NO se recomienda para Azure.

Debe saber lo que se admite y lo que no se admite para las copias de seguridad y la restauración de un controlador de dominio en general, y más concretamente para los que se ejecutan en una máquina virtual. Vea Consideraciones relacionadas con la copia de seguridad y la restauración para controladores de dominio virtualizados.

Cree copias de seguridad de estado del sistema solo mediante software de copia de seguridad que tenga en cuenta específicamente los requisitos de copia de seguridad de Windows Server AD DS, como Copias de seguridad de Windows Server.

No copie o clone archivos VHD de controladores de dominio en lugar de realizar copias de seguridad periódicas. Si alguna vez es necesario realizar una restauración, no utilice VHD clonados o copiados sin Windows Server 2012 y un hipervisor compatible porque se crearán burbujas de USN.

La configuración de los servidores de federación (STS) de Windows Server AD FS depende en parte de si las aplicaciones que desea implementar en Azure necesitan acceder a recursos de la red local.

Si las aplicaciones cumplen los siguientes criterios, puede implementarlas de forma aislada de la red local.

  • Aceptan tokens de seguridad de SAML

  • Se pueden exponer en Internet

  • No tienen acceso a recursos locales

En este caso, configure los STS de Windows Server AD FS de la manera siguiente:

  1. Configure un bosque aislado de un solo dominio en Azure.

  2. Proporcione acceso federado al bosque configurando una granja de servidores de federación de Windows Server AD FS.

  3. Configure Windows Server AD FS (granja de servidores de federación y granja de proxy del servidor de federación) en el bosque local.

  4. Establezca una relación de confianza de federación entre las instancias locales y de Azure de Windows Server AD FS.

Por otra parte, si las aplicaciones necesitan acceso a recursos locales, puede configurar Windows Server AD FS con la aplicación en Azure de la manera siguiente:

  1. Configure la conectividad entre las redes locales y Azure.

  2. Configure una granja de servidores de federación de Windows Server AD FS en el bosque local.

  3. Configure una granja de proxy del servidor de federación de Windows Server AD FS en Azure.

Esta configuración tiene la ventaja de reducir la exposición de los recursos locales, de manera similar a la configuración de Windows Server AD FS con aplicaciones en una red perimetral.

Tenga en cuenta que en cualquiera de los escenarios puede establecer relaciones de confianza con más proveedores de identidad, si se necesita colaboración de negocio a negocio.

Los servicios en la nube son necesarios si desea exponer una máquina virtual directamente a Internet o si desea exponer una aplicación con equilibrio de carga con conexión a Internet. Esto es posible porque cada servicio en la nube ofrece una única VIP configurable.

Cada máquina virtual de Azure recibe una DIP. Una DIP es una dirección privada accesible únicamente dentro de Azure. Sin embargo, en la mayoría de los casos será necesario configurar una VIP para las implementaciones de Windows Server AD FS. La VIP es necesaria para exponer extremos de Windows Server AD FS en Internet, que los asociados y los clientes federados utilizarán para la autenticación y la administración continua. Una VIP es propiedad de un servicio en la nube que contiene una o varias máquinas virtuales de Azure. Si la aplicación para notificaciones implementada en Azure y Windows Server AD FS comparte puertos y tiene conexión a Internet, cada una requerirá su propia VIP y por tanto no será necesario crear un servicio en la nube para la aplicación y un segundo servicio en la nube para Windows Server AD FS.

Encontrará las definiciones de los términos VIP y DIP en Términos y definiciones.

Aunque es posible implementar servicios de federación de Windows Server AD FS independientes, se recomienda implementar una granja con un mínimo de dos nodos para los STS y los servidores proxy de AD FS para los entornos de producción.

Vea Consideraciones sobre la topología de implementación de AD FS 2.0 en la Guía de diseño de AD FS 2.0 para decidir qué opciones de configuración de implementación se adaptan mejor a sus necesidades concretas.

noteNota
Con el fin de obtener equilibrio de carga para los extremos de Windows Server AD FS en Azure, configure todos los miembros de la granja de Windows Server AD FS en el mismo servicio en la nube, y utilice la capacidad de equilibrio de carga de Azure para los puertos HTTP (80 de forma predeterminada) y HTTPS (443 de forma predeterminada). Para obtener más información, consulte Sondeo del equilibrador de carga de Azure.

Equilibrio de carga de red (NLB) de Windows Server no se admite en Azure.

Mostrar:
© 2015 Microsoft