Exportar (0) Imprimir
Expandir todo
Este tema aún no ha recibido ninguna valoración - Valorar este tema

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

Actualizado: diciembre de 2013

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 Windows Azure.

Tabla de contenido

Ámbito y audiencia

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 Windows Azure y Redes virtuales de Windows Azure y las implementaciones de Active Directory locales tradicionales. Máquinas virtuales de Windows Azure y Red virtual de Windows 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 Guía de implementación de AD FS 2.0, 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 Windows Azure. Primero se explican las diferencias más importantes entre ejecutar Windows Server AD DS y AD FS en Máquinas virtuales de Windows 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 implementación y la configuración de Active Directory de Windows 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, AD de Windows Azure y Windows Server AD DS 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 Windows Azure, tenga en cuenta lo siguiente:

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

  2. Puede usar Active Directory de Windows 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 Windows Azure o en otras plataformas en la nube también pueden usarla.

  3. Puede usar Active Directory de Windows Azure (su servicio Access Control) 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 Windows Azure Identity.

Recursos relacionados

Introducción

Los requisitos fundamentales para implementar Windows Server Active Directory en Máquinas virtuales de Windows 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 Windows Azure son réplicas en un dominio o un bosque corporativo local existente, la implementación de Windows 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 Windows 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 que hay a continuación:

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

    Para volver a conectar máquinas virtuales de Windows Azure a una red corporativa local se necesita Red virtual de Windows 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 Windows 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 Windows 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 Crear una red virtual con conectividad entre entornos.

    noteNota
    También puede implementar Windows Server Active Directory en una red virtual de Windows 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 Windows Azure porque proporciona capacidades de direccionamiento IP que son esenciales para Windows Server. En el párrafo siguiente se describen otros detalles adicionales.

  2. NO se admiten direcciones IP estáticas en máquinas virtuales de Windows Azure.

    Por tanto, se deben usar direcciones dinámicas en su lugar, lo que requiere la creación de una Red virtual de Windows Azure. A primera vista, esto parece contradictorio con las prácticas recomendadas existentes de Windows Server Active Directory, pero como las direcciones IP dinámicas de las máquinas virtuales de Windows Azure conectadas a una Red virtual de Windows Azure se conservan mientras dura la máquina virtual, se cumplen los requisitos de Windows Server Active Directory para el direccionamiento IP (y los de DNS si comparte ubicación con el controlador de dominio).

    Además, las Redes virtuales de Windows Azure proporcionan mayores grados de control sobre el direccionamiento IP y DNS.

    Vea Direccionamiento IP y DNS.

  3. Windows Azure proporciona dos tipos de disco diferentes para las máquinas virtuales.

    La selección del tipo de disco es fundamental a la hora de implementar controladores de dominio. Windows Azure ofrece “discos del sistema operativo” y “discos de datos”. Los discos de datos emplean almacenamiento en caché de escritura simultánea, lo que garantiza la durabilidad de las escrituras; esto es fundamental para la integridad de cualquier bosque de Windows Server Active Directory que tenga más de un único controlador de dominio, ya que la pérdida de una sola escritura puede afectar a todo el sistema distribuido, no a un solo equipo. En el resto de este documento se explican en detalle otros factores que hay que tener en cuenta, así como los escenarios en los que influyen las opciones de configuración y de implementación.

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

Términos y definiciones

A continuación se muestra una lista de términos no exhaustiva en la que se definen varias tecnologías de Windows Azure y que le ayudará a entender este documento. Para obtener un glosario completo, vea Glosario de Windows Azure.

  • Máquinas virtuales de Windows Azure: oferta de IaaS de Windows 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 Windows Azure: servicio de red de Windows Azure que permite a los clientes crear y administrar redes virtuales en Windows 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 Windows Azure. Una VIP es propiedad de un servicio en la nube que puede contener una o varias máquinas virtuales de Windows Azure. Tenga en cuenta también que una red virtual de Windows 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 DHCP asignará dinámicamente al adaptador de red virtual de una máquina virtual de Windows Azure. Sin embargo, la dirección IP se conservará con esa máquina virtual mientras dure la implementación, del mismo modo que las reservas de DHCP está asociadas a direcciones MAC individuales.

  • Recuperación del servicio: proceso por el cual Windows 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 Windows 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 configuración IP de la máquina virtual se defina como parte de la red virtual o de la propia máquina virtual (no del sistema operativo invitado)

    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 Windows Azure se ejecuten en una red virtual de Windows Azure como se ha descrito anteriormente, lo que garantiza que la dirección IP se conserve durante la recuperación del servicio.

¿Es seguro virtualizar controladores de dominio de Windows Server Active Directory?

La implementación de controladores de dominio de Windows Server Active Directory en máquinas virtuales de Windows 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. Si bien Windows Azure no proporciona funcionalidad de restauración de instantáneas, 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 que 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. Windows Azure admite VM-GenerationID, lo que significa que los controladores de dominio que ejecutan Windows Server 2012 o posterior en Máquinas virtuales de Windows Azure cuentan con las medidas de seguridad adicionales. Para obtener más información, vea Introducción a la virtualización de los Servicios de dominio de Active Directory (AD DS).

¿Por qué implementar Windows Server AD DS en Máquinas virtuales de Windows Azure?

Muchos escenarios de implementación de Windows Server AD DS son adecuados para la implementación como máquinas virtuales en Windows 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 Windows Azure de Asia. La conexión de ese controlador de dominio a una red virtual de Windows Azure que está conectada directamente a la ubicación remota mejorará el rendimiento de autenticación.

Windows 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 Windows Azure representa una alternativa atractiva.

Por último, puede que desee implementar una aplicación de red en Windows 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 Windows 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 Windows 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 Windows Azure en Red virtual de Windows Azure. Pero si la VPN no está disponible, la comunicación entre los equipos locales y los controladores de dominio basados en Windows Azure no funcionará, lo que dará lugar a errores de autenticación y de otro tipo.  

Contrastes entre implementar controladores de dominio de Windows Server Active Directory en Máquinas virtuales de Windows Azure e implementarlos de forma local

  • En cualquier escenario de implementación de Windows Server Active Directory que incluya más de una sola máquina virtual, se recomienda utilizar una red virtual de Windows Azure para la coherencia de las direcciones IP, ya que no se admiten direcciones asignadas estáticamente. Tenga en cuenta que en esta guía se da por supuesto que los controladores de dominio se ejecutan en una red virtual de Windows Azure.

    La coherencia de las direcciones IP de Red virtual de Windows Azure se logra mediante un tercer tipo conceptual nuevo de dirección IP que es similar a las reservas de DHCP. Actualmente, las direcciones IP estáticas se asignan dentro del sistema operativo a una tarjeta de interfaz de red específica. Las direcciones dinámicas se conceden automáticamente desde servidores DHCP según los ámbitos definidos en el servidor DHCP.

    Las redes virtuales de Windows Azure presentan en un tercer tipo conceptual de dirección que difiere ligeramente de la asignación de direcciones de DHCP. Con máquinas virtuales de Windows Azure, se debe configurar la máquina virtual para que conceda una dirección IP desde DHCP. No obstante, a diferencia de lo que ocurre con las direcciones dinámicas típicas, que pueden modificar cuándo caduca una concesión, las direcciones dinámicas de redes virtuales de Windows Azure están garantizadas mientras dure la máquina virtual, de forma parecida a como funcionan las reservas de DHCP.

    ImportantImportante
    La configuración de una dirección IP estática dentro de la máquina virtual producirá finalmente la pérdida completa de conectividad con ella.

  • 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 Windows Azure y la red local. Necesita implementar un extremo de VPN en la red local. La VPN está abierta desde Windows Azure a la red local. Para obtener más información, vea Información general sobre Red virtual de Windows Azure y Tutorial 2: Creating a Virtual Network for cross-premises connectivity.

    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 Windows Azure.

  • Independientemente de si crea una red virtual o no, se le cobrará por el tráfico de salida de Windows 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. Para obtener más información sobre los cargos de tráfico, vea Información general sobre precios de Windows Azure.

  • Es importante tener en cuenta que no hay conectividad directa entre distintas redes virtuales de Windows Azure. Es decir, si crea dos redes virtuales, puede que distribuidas geográficamente, la comunicación entre las máquinas virtuales de Windows Azure conectadas a ellas solo se puede lograr si se conectan las dos redes virtuales a la misma red corporativa mediante la capacidad de VPN de sitio a sitio. Entonces es posible la comunicación entre las dos redes virtuales, pero solo si se enruta el tráfico a través de la red corporativa. Por tanto, la comunicación entre controladores de dominio distribuidos geográficamente en redes virtuales diferentes debe atravesar ambas redes virtuales y la red corporativa. Por ejemplo, para que una máquina virtual de Windows Azure ubicada en una red virtual de Asia pueda comunicarse con otra máquina virtual de Windows Azure de una red virtual ubicada en Sudamérica, la comunicación de un extremo a otro debe atravesar la red interna.

  • Si bien en Windows 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. Para obtener más información sobre los recursos de proceso disponibles, vea 7 cosas que saber acerca de la capacidad de Windows Azure.

¿Se puede implementar Windows Server AD FS en máquinas virtuales de Windows Azure?

Se admite la implementación de AD FS en Máquinas virtuales de Windows Azure, pero hay prácticas recomendadas de AD FS que requieren tecnologías más allá de lo que ofrece AD FS, como equilibrio de carga y alta disponibilidad. Puesto que esas tecnologías no forman parte del conjunto de características nativas de AD FS, debe proporcionarlas la infraestructura subyacente. Por ejemplo, se recomienda encarecidamente que los roles Proxy de AD FS y Servicio de token de seguridad (STS) tengan equilibrio de carga y alta disponibilidad. Windows Azure no puede cumplir esos requisitos de equilibrio de carga y alta disponibilidad en las interfaces privadas (DIP) de una máquina virtual, por lo que hay que hacer concesiones recíprocas.

Para entender mejor la necesidad de esa concesión, considere la actualización siguiente sobre la típica implementación local de AD FS y, a continuación, compárela con las posibilidades que hay actualmente con las máquinas virtuales de Windows Azure. El diagrama siguiente de Planear la implementación de AD FS muestra una implementación típica de AD FS.

WID y servidores proxy de AD FS

Los STS se implementan dentro del firewall corporativo y utilizan NLB para el equilibrio de carga. Cuando un usuario que está conectado a la red corporativa y ha iniciado sesión en el dominio corp.fabrikam.com desea obtener acceso a Office 365 en este escenario, se le redirige al extremo con equilibrio de carga y alta disponibilidad delante de los STS.

Los servidores proxy de AD FS se implementan en las redes perimetrales y también usan NLB para equilibrar la carga de las solicitudes de los usuarios externos. Los servidores proxy de AD FS pasan las solicitudes externas al extremo con equilibrio de carga y alta disponibilidad delante de los STS.

En todos los casos, tenga en cuenta que la recomendación garantiza que las interfaces utilizadas tienen equilibrio de carga y alta disponibilidad. Los medios por los que esto se consigue no es importante y NLB se utiliza como un ejemplo posible.

noteNota
Para obtener más información sobre cómo el usuario se autentica en este escenario, vea ¿Cómo funciona ADFS con Office 365?

En la mayoría de los casos, el error de una aplicación que AD FS habilita no es aceptable, ya que estas aplicaciones suelen ser críticas. Por tanto, y como AD FS reside ahora en la ruta de acceso crítica para obtener acceso a las aplicaciones, se recomienda encarecidamente adherirse a las prácticas recomendadas siguientes (que se muestran en el diagrama anterior):

  1. Nunca exponga STS directamente a Internet.

    Como práctica recomendada de seguridad, ponga las instancias de STS detrás de un firewall y conéctelas a la red corporativa para impedir su exposición a Internet. Esto es importante porque el rol STS emite tokens de seguridad. Por tanto, 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 otros STS en organizaciones de confianza.

  2. El servicio AD FS debe contar con alta disponibilidad.

    Si la aplicación que requiere AD FS es crítica, el servicio AD FS debe tener alta disponibilidad para mantener el acceso a la aplicación. Para lograr una alta disponibilidad, los equilibradores de carga se implementan normalmente delante de los servidores proxy de AD FS y los STS.

Ahora considere cómo se implementaría esta configuración en máquinas virtuales de Windows Azure. Las marcas de verificación verdes indican que el requisito de las prácticas recomendadas se puede cumplir sin perder confidencialidad y una X roja indica que el requisito no se puede cumplir con las máquinas virtuales de Windows Azure.

AD FS y servidores proxy en Windows Azure

Tenga en cuenta que no se puede proporcionar equilibrio de carga y alta disponibilidad para los STS. La única forma de equilibrar la carga de los STS sería exponerlos mediante una VIP, ya que las VIP proporcionan capacidades nativas de equilibrio de carga, mientras que las DIP no lo hacen. Sin embargo, esto infringe la práctica recomendada número 1 (nunca exponga los STS directamente a Internet).

En resumen, la solución requiere que se ponga en peligro la alta disponibilidad o la seguridad. Ninguno de estos riesgos suele ser aceptable si la aplicación es crítica, ya que AD FS reside en la ruta crítica para tener acceso a la aplicación.

¿Se pueden implementar los STS con una VIP y configurando un firewall?

Aunque se pueden imponer restricciones de firewall en la propia VIP, debe racionalizar el requisito de estabilidad a largo plazo, configuración y mantenimiento con el valor especificado. Considere qué reglas deberían agregarse o cómo expresar una regla de firewall de VIP que permita el acceso al extremo de VIP con equilibrio de carga desde los servidores proxy y los usuarios locales. Además, tenga en cuenta la logística necesaria para mantener la ACL a medida que los proveedores de red de la corporation cambien con el tiempo y, lo que es más importante, la pérdida resultante de acceso a la aplicación. También es posible cumplir los requisitos de equilibrio de carga si se implementa la tecnología de equilibrio de carga de forma local, que de esta forma se orienta a los STS que se encuentran en Windows Azure, pero esto crea una solución muy complicada y una solución de problemas igualmente exigente en caso de que se produzcan errores. Probablemente, esto contradice una de las razones fundamentales para pasarse a Windows Azure en primer lugar (simplificación, reducción de costos, etc.).

Si el objetivo es Office 365 solamente, hay una alternativa

Si el objetivo es Office 365 solamente, se puede implementar simplemente DirSync con la sincronización de contraseñas de forma local y conseguir el mismo resultado final con una complejidad de la implementación casi inexistente. Nota: este método no requiere AD FS o Windows 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 Windows Azure AD.

  4. Puesto que Windows 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 Windows Azure AD.

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

  8. Windows 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 Windows Azure AD.

  4. Windows 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 Windows Azure AD la valida con el nombre de usuario y la contraseña que DirSync sincronizó.

  6. Windows Azure AD redirige al usuario a Office 365.

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

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 tener acceso a Office 365. Tenga en cuenta que estos datos se pueden recordar para contribuir a reducir los mensajes posteriores.

Conclusión

La implementación de AD FS en Máquinas virtuales de Windows Azure es cuestión de riesgo frente a recompensa. La recompensa de implementar AD FS en Windows Azure puede pesar más que los riesgos, pero esta es una decisión que se debe tomar en el contexto del escenario de implementación. En la tabla siguiente se intenta capturar la matriz de decisiones.

 

Implementación Recompensa Riesgo

Implementar los STS usando solo su DIP

Implementación segura que se adhiere a las prácticas recomendadas

Poner en peligro la alta disponibilidad y el equilibrio de carga

Implementar los STS mediante una VIP

Obtener alta disponibilidad y equilibrio de carga

No respeta las prácticas recomendadas legítimas relativas a la seguridad

Implementar los STS mediante una VIP y reglas de firewall

Obtener seguridad y alta disponibilidad

Poner en peligro la simplicidad y una configuración frágil

Implementar equilibradores de carga locales delante de los STS que solo utilizan DIP en Windows Azure

Obtener seguridad y alta disponibilidad

Poner en peligro la sencillez de la solución de problemas

Un escenario de implementación que cumple todas las prácticas recomendadas y no pone nada en peligro consiste en mover simplemente los servidores proxy de AD FS de la red perimetral local a Windows Azure. Para obtener más información acerca de este escenario, vea 2. AD FS: extender a Internet una aplicación front-end local para notificaciones.

Elementos adicionales para la reflexión

  • Si implementa un proxy de Windows Server AD FS en una máquina virtual de Windows Azure, se necesita conectividad con los STS 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 la comunicación de los servidores proxy con sus STS.

  • Si implementa un STS de Windows Server AD FS en una máquina virtual de Windows Azure, se necesita conectividad con los controladores de dominio, los almacenes de atributos y las bases de datos de configuración de Windows Server Active Directory y también puede ser necesaria una VPN de sitio a sitio.

  • Se le cobrará por todo el tráfico de salida de las máquinas virtuales de Windows Azure. Si el costo es un factor determinante, es conveniente implementar los servidores proxy de AD FS en Windows Azure, dejando los STS locales. Si los STS también se implementan en máquinas virtuales de Windows Azure, se aplicarán cargos adicionales para autenticar a los usuarios locales. El tráfico de salida supone un costo independientemente de si está atravesando la VPN o no.

  • Si decide usar las capacidades de equilibrio de carga del servidor nativas de Windows Azure para lograr alta disponibilidad de los STS de AD FS, tenga en cuenta que el equilibrio de carga proporciona sondeos que se utilizan para determinar el estado de las máquinas virtuales dentro del servicio en la nube. En el caso de Máquinas virtuales de Windows 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 Windows Azure. Para simplificar, puede usar un sondeo TCP personalizado, ya que solo requiere que se establezca correctamente una conexión TCP (syn ack) para determinar el estado de las máquinas virtuales. Puede configurar el sondeo personalizado para que utilice cualquier puerto TCP que está escuchando activamente en las máquinas virtuales. Para ello, vea Sondeo del equilibrador de carga de Windows Azure.

    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.

Escenarios de implementación

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.

1. AD DS: implementar una aplicación compatible con AD DS sin necesidad de conectividad a la red corporativa

Implementación de AD DS solo en la nube

Ilustración 1

Descripción

SharePoint se implementa en una máquina virtual de Windows 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 Windows Azure.

Consideraciones sobre el escenario y cómo se aplican las áreas de tecnología al escenario

  • Topología de red: cree una Red virtual de Windows Azure sin conectividad entre entornos (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:

    1. use direcciones concedidas por DHCP (esto es obligatorio, NO se admiten direcciones estáticas).

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

  • 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 Windows 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.

2. AD FS: extender a Internet una aplicación front-end local para notificaciones

Federación con conectividad entre entornos

Ilustración 2

Descripción

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 Windows 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 Windows Azure.

Consideraciones sobre el escenario y cómo se aplican las áreas de tecnología al escenario

  • Topología de red: cree una Red virtual de Windows 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 Windows 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 dirección VIP del primer 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 apunten a la dirección IP del equilibrador de carga local que atiende a los STS de Windows Server AD FS. La dirección VIP del segundo servicio en la nube se dirigirá a las dos máquinas virtuales que ejecutan el front-end web, también 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 de 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 nativa de equilibrio de carga del servidor de Windows Azure para distribuir las solicitudes entrantes entre los servidores de la granja. El equilibrio de carga nativo de Windows Azure solo se admite cuando se utiliza una VIP accesible desde Internet; las DIP no pueden tener equilibrio de carga.

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

3. AD DS: implementar una aplicación compatible con Windows Server AD DS que necesita conectividad con la red corporativa

Implementación de AD DS entre entornos

Ilustración 3

Descripción

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 Windows 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 Windows Azure dos controladores de dominio adicionales que forman parte del dominio corporativo junto con la aplicación.

Consideraciones sobre el escenario y cómo se aplican las áreas de tecnología al escenario

  • Topología de red: cree una Red virtual de Windows Azure con conectividad entre entornos. Esto requerirá implementar un extremo de VPN compatible en el borde de la red corporativa. para obtener más información, vea Acerca de los dispositivos VPN para la red virtual.

  • 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. Para obtener un tutorial, vea Install a replica Active Directory DC in Windows Azure Virtual Network. 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 Windows Azure.

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

  • Direccionamiento IP y DNS:

    1. use direcciones concedidas por DHCP (esto es obligatorio, NO se admiten direcciones estáticas).

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

  • Controladores de dominio distribuidos geográficamente: configure otras redes virtuales adicionales según sea necesario. Si se necesita comunicación directa entre las redes virtuales, se deben configurar ambas para que utilicen sus capacidades de VPN de sitio a sitio; todo el tráfico entre ellas se enrutará a través de la red corporativa interna.

  • Controladores de dominio de solo lectura: puede implementar un controlador de dominio de solo lectura (RODC) en el sitio de Windows 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 Windows 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 Windows 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 Windows 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 Windows 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.

Factores y decisiones sobre la implementación

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 Windows 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?

Usar solo direcciones concedidas por DHCP de Windows Azure

Instalar el servidor DNS de Windows Server

5

Controladores de dominio distribuidos geográficamente

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

Sin comunicación directa entre redes virtuales geográficamente independientes

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?

ImportantImportante
No usar SYSPREP para clonar controladores de dominio. Sin embargo, puede usar la clonación virtual del controlador de dominio con máquinas virtuales de Windows Azure que ejecutan Windows Server 2012.

  • 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 Windows 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

No copiar ni clonar archivos VHD

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

Topología de red

Con el fin de cumplir los requisitos de DNS y de coherencia de las direcciones IP de Windows Server AD DS, es necesario crear un Red virtual de Windows 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 Windows 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 Windows 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 Windows 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 Información general sobre precios de Windows Azure.

Configuración de implementación de controlador de dominio

La forma de configurar el controlador de dominio depende de los requisitos del servicio que desea ejecutar en Windows 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 Información general sobre precios de Windows Azure.

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 Windows 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 Windows 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 Windows 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.

Topología de sitio de Windows Server Active Directory

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 Windows 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 Información general sobre precios de Windows Azure. 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 Windows 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 Windows 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 Windows 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, vea Cómo funciona la topología de replicación de Active Directory.

Direccionamiento IP y DNS

Las máquinas virtuales de Windows Azure requieren “direcciones concedidas por DHCP” y, como se ha indicado anteriormente, esto parece contradictorio con las prácticas recomendadas existentes. Puesto que las direcciones dinámicas de red virtual de Windows Azure se conservan con una máquina virtual mientras dura la máquina virtual, se cumplen los requisitos de Windows Server AD DS. Si bien el uso de direcciones estáticas puede parecer suficiente inicialmente, con el tiempo su uso producirá en última instancia una pérdida completa de conectividad con la máquina virtual y entre las máquinas virtuales afectadas.

Por tanto, cuando utilice una dirección dinámica en Windows 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.

En cuanto a la resolución de nombres, implemente su propia infraestructura de servidor DNS (o aproveche la infraestructura existente); el DNS proporcionado por Windows 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 Windows Azure.

noteNota
No puede unir equipos locales a un dominio de Active Directory de Windows Server AD DS que se hospeda en Windows 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 Instale un nuevo bosque de Active Directory en Windows Azure. Para obtener más información sobre cómo usar Windows PowerShell, vea la introducción a Windows PowerShell Azure y Cmdlets de administración de Windows Azure.

Controladores de dominio distribuidos geográficamente

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)

Pero no existe comunicación directa entre las redes virtuales de Windows Azure. Cualquier comunicación entre distintas redes virtuales de Windows Azure debe enrutarse a través de la red local, lo que puede generar una gran cantidad de tráfico de salida (y los costos asociados a ese tráfico).

Sin conectividad entre redes virtuales

Ilustración 4

Controladores de dominio de solo lectura

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, vea 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, vea Compatibilidad de aplicaciones con controladores de dominio de solo lectura.

Catálogo global

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.

Método de instalación

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

Utilice solo Máquinas virtuales de Windows Azure para los controladores de dominio (al contrario que con las 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 Windows 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 capacidad de clonar controladores de dominio solo está disponible a partir de 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.

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

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 Windows Azure. Los “discos de datos” y los “discos del sistema operativo” son dos tipos de unidad de disco virtual diferentes para Windows Azure. Presentan comportamientos distintos (y valores predeterminados diferentes).

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

A diferencia de las unidades de disco del sistema operativo, las unidades de disco de datos no almacenan en memoria caché las escrituras de forma predeterminada. 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 Windows 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, almacene la base de datos, los registros y SYSVOL en el mismo disco de datos o en discos de datos distintos. 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 Windows Azure. De forma predeterminada, el proceso de instalación de AD DS instala estos componentes en la carpeta %systemroot%, que NO se recomienda para Windows Azure.

Copias de seguridad y restauración

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.

Configuración del servidor de federación

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 Windows 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 Windows 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 Windows 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 Windows Azure de la manera siguiente:

  1. Configure la conectividad entre las redes locales y Windows 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 Windows 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.

Configuración de servicios en la nube

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.

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

Cada máquina virtual de Windows Azure recibe una DIP. Una DIP es una dirección privada accesible únicamente dentro de Windows 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 Windows Azure. Si la aplicación para notificaciones implementada en Windows 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.

Para conocer las definiciones de los términos VIP y DIP, vea Términos y definiciones.

Configuración de alta disponibilidad de Windows Server AD FS

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 Windows 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 Windows Azure para los puertos HTTP (80 de forma predeterminada) y HTTPS (443 de forma predeterminada). Para obtener más información, vea Sondeo del equilibrador de carga de Windows Azure.

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

¿Te ha resultado útil?
(Caracteres restantes: 1500)
Gracias por sus comentarios
Mostrar:
© 2014 Microsoft. Reservados todos los derechos.