Llegamos a ustedes gracias a:



Reportajes y análisis

Primer vistazo: Microsoft Azure Active Directory Domain Services pone todo en la nube

Microsoft Azure Active Directory Domain Services

[17/11/2015] El 14 de octubre Microsoft anunció la vista previa de Azure Active Directory Domain Services, o, como me gusta llamarlo, un dominio en una nube.

Lo que es realmente interesante de esta vista previa es que Microsoft ha conseguido crear un superconjunto de su producto en las instalaciones. Azure Active Directory Domain Services tiene cada característica que tiene el venerable Active Directory (AD) en las instalaciones -y algo más.

Hay una función de paridad completa para asegurar la compatibilidad con las aplicaciones existentes que ha elevado a la nube, pero también hay nuevas características específicas de Azure que amplían la funcionalidad de AD más allá de lo que recibe de Windows Server en el hardware local. Es un hito muy interesante, y en esta pieza le daré un primer vistazo de cerca a lo que es y lo que ofrece.

¿Para qué es bueno?

El primer y principal caso de uso para Azure Active Directory Domain Services es mover las aplicaciones que dependen de una implementación completa de AD hacia la nube. Antes de esta versión preliminar, se podía ejecutar SQL Server, Exchange u otras aplicaciones de directorio dependiente en Azure, pero también tenía que tener una máquina virtual de pleno derecho, con infraestructura como servicio (o dos, por mejores razones prácticas), equipada con Active Directory Domain Services para servir al directorio de su nube.

Azure Active Directory estaba alrededor, pero se utilizó principalmente para la sincronización y la federación de la nube y no soporta plenamente a AD. Si no quiere tratar con otra máquina virtual de nube solo para ejecutar las tuberías, puede crear un enlace de red privada virtual (VPN, por sus siglas en inglés) entre Azure y su centro de datos en las instalaciones de modo que puede utilizar su implementación de AD existente. Pero los VPNs son a veces su peor enemigo y otro punto de falla -y otro que necesitará administración.

Azure Active Directory Domain Services básicamente toma a AD y lo convierte en una "página web administrada" -Microsoft maneja el servicio, la aplicación de parches, las actualizaciones, el mantenimiento subyacente, la tolerancia a fallas y otras cosas. Lo que se obtiene es realmente una instancia administrada de Active Directory, con paridad de funciones con la versión de la caja, sin tener que administrar máquinas virtuales a tiempo completo. En pocas palabras, usted le paga a Microsoft y le ofrece un directorio a utilizar. No es responsable de la instalación de las cañerías subyacentes.

Un caso de uso secundario, sobre todo habilitado por el hecho de que Azure Active Directory Domain Services es un superconjunto de AD regulares, es para la recuperación de desastres y la espera. En lugar de tener una copia de seguridad de los controladores de dominio y de los centros de datos repartidos por todos lados, podría tener a Azure Active Directory Domain Services como su sitio de recuperación de errores, y el poder y la escala de Azure detrás de usted en caso de que algo le pase a su implementación de AD en las instalaciones y se haga inalcanzable.

Este escenario no se ha concretado aún, sobre todo porque el servicio está recién en la fase preliminar, pero técnicamente hay poco para prevenir -y puede ser menos costoso que los controladores de co-localización de backups globales o, para las tiendas pequeñas, incurrir en el costo de una segunda licencia de Windows Server para conseguir ese segundo controlador de dominio que ejecute las mejores prácticas.

Un tercer caso de uso es, probablemente, el pleno soporte a Lightweight Directory Access Protocol (LDAP) con el que viene repleto Azure Active Directory Domain Services. Muchas aplicaciones en la nube no necesitan necesariamente a Active Directory en sí, pero sí necesitan un directorio central para llevar a cabo operaciones de búsqueda de identidad a través del LDAP estándar de la industria. Azure ahora puede ofrecer este servicio a través de Domain Services, que es especialmente útil para aplicaciones de Linux y Unix, o para federar escenarios de identidad a través de múltiples aplicaciones y proveedores.

Finalmente, un cuarto caso de uso podría causar algunos temblores de miedo en los corazones de los administradores de Windows: Pequeñas tiendas evitando controladores de dominio local por completo y utilizando Azure Active Directory Domain Services como su único directorio. Teniendo en cuenta que en Windows 10 ya puede unir una máquina con Azure Active Directory (aún no con los servicios de dominio, pero sí con AD Azure) para aprovechar la gestión de la máquina y las características de inscripción, ese día no está muy lejos.

Cuando une eso con el hecho de que Microsoft ha hecho un gran trabajo eliminando su producto Small Business Server, paralizando Essentials SKUs que se ofrecían a este mercado y empujado a esos clientes a Office 365, no es terriblemente difícil ver un futuro donde 10 usuarios, 15 usuarios, incluso tiendas de 25 usuarios funcionarán solo con un puñado de máquinas Windows unidas a Active Directory en la nube, sin Windows Server en el armario.

Ya que Azure Active Directory Domain Services cuenta con el apoyo total para Kerberos, NTLM,y Group Policy, es más o menos un sustituto de un controlador de dominio. Asumiendo que tiene enlace ascendente a Internet sin demasiada latencia, un controlador de dominio en su armario tal vez no necesite más. Este hecho no puede significar que estamos entrando en una era "post-Active Directory", pero señala una era post "dominio local".

Cómo configurar

Vamos a mojarnos los pies y entramos.

Contrariamente a lo que debería esperar, Azure Active Directory Domain Services son dominios separados de sus contrapartes en las instalaciones. Puede sincronizarlos de manera que el mismo conjunto de credenciales funcione tanto en la implementación de AD en las instalaciones de la empresa como en el servicio Azure gestionado; pero por defecto, los dominios son distintos. Las máquinas en la nube se unen directamente a este dominio de nube; el dominio nube no es una réplica per se del directorio en las instalaciones, sino más bien un recurso que puede parecerse a él.

Azure Active Directory Domain Services se une a las redes virtuales Azure. La primera vez que inicia sesión en el portal de gestión para configurar el servicio, tiene que escoger la red virtual donde vive el dominio. Una vez que el asistente se haya completado, obtiene dos direcciones IP que corresponden a los controladores de dominio administrados que vienen con el servicio. A continuación, utiliza estas dos direcciones IP como los servidores DNS primario y secundario dentro de los miembros de dominio en la nube para que las funcionalidades de búsqueda y control vayan a través de los controladores de dominio en la nube.

Al configurar Domain Services tiene que especificar la red virtual a la que se aplica. Estos controladores de dominio de la nube también se utilizan como los principales servidores DNS para que la red virtual.

En primer lugar, abra el portal de administración de Azure. En el lado izquierdo, seleccione Active Directory y, a continuación, seleccione el directorio (probablemente se llame 'directorio predeterminado' a menos que haya creado varios directorios) y luego haga clic en la ficha Grupos. Haga clic aquí para agregar un nuevo grupo, y nómbrelo 'administradores AAD DC'. Sí, tiene que ser ese nombre.

Una vez creado el grupo, agregue a todos los usuarios del directorio que deberían ser administradores. Estas personas tendrán derecho a agregar computadoras al dominio, así como administrar la implementación en la nube de las políticas del grupo.

A continuación, tendrá que crear una nueva red virtual, o seleccionar una red virtual existente. Esta red tiene que estar en las regiones de Estados Unidos o Asia. (Estos son los únicos lugares geográficos que soporta la vista previa; por supuesto, esta característica probablemente esté disponible a nivel mundial cuando el código salga a su fase de vista previa).

Lo llevaré a través de la creación de una nueva red virtual.

En primer lugar, desde el lado izquierdo del portal de gestión de Azure, seleccione Redes, introduzca un nombre, elija una región y luego simplemente acepte los valores predeterminados.

A continuación, es necesario habilitar el aspecto de los servicios de dominio de Azure Active Directory. En el panel izquierdo de la consola de administración de Azure, haga clic en Active Directory de nuevo, seleccione el directorio que desee (de nuevo, probablemente la lista 'Directorio predeterminado') y, a continuación, haga clic en la ficha Configurar. Vaya a la sección de Servicios de dominio y bajo "Habilitar administradores de dominio de este directorio", haga clic en .

Introduzca el nombre de dominio DNS que desea utilizar -puede utilizar el proporcionado por Microsoft o ingresar uno propio-, y luego seleccione la red virtual a utilizar. Haga clic en el botón Guardar.

Tomará un poco de tiempo a medida que el servicio rueda detrás de las cortinas. En realidad, se está creando el dominio; cuando esté listo, aparecerá una dirección IP -podría tardar hasta 30 minutos- seguidos por otra dirección IP por otra media hora.

En ese punto, es necesario volver a la página de red virtual y hacer saltar esas dos direcciones IP como servidores DNS para esa red, del mismo modo en que configuraría sus clientes locales para que utilicen sus controladores de dominio como servidores DNS.

Tal vez se pregunte exactamente cómo se construye esta instancia de AD en la nube. En este momento el servicio crea una estructura de unidad organizativa única y plana. La política de grupo está agrupada en la parte superior mediante la creación de un único objeto de directiva de grupo (GPO, por sus siglas en inglés) para el contenedor de usuario y otro GPO para el contenedor de la computadora.

Puede editar la configuración de las políticas de cada uno de estos dos GPO, pero no puede crear más, y no puede apuntar a usuarios o equipos con más precisión a través del recorte de seguridad o filtrado de Windows Management Instrumentation. Ese es el grado del servicio por el momento, a pesar de que es bastante fácil imaginar cómo se ampliarán cada una de las subfunciones en futuras versiones de Azure AD Domain Services.

Por último, necesita configurar las credenciales reales de los usuarios en el directorio. Tras la creación, el directorio no tiene hashes (las credenciales protegidas) para los usuarios, por lo que los tendrán que ser sincronizadas con el directorio. Si es una organización que solo utiliza Azure en la nube y no tiene nada local para sincronizar, entonces esto es bastante simple: Indíquele a los usuarios que vayan a Azure AD en myapps.microsoft.com, y cambien sus contraseñas existentes de Azure. Esto hará que se genere un hash (ahora que Domain Services está activo en ese directorio en particular).

La mayoría de nosotros, sin embargo, tiene implementaciones de Active Directory en las instalaciones de la empresa, por lo que la instalación es un poco más complicada. Tendremos que utilizar Azure AD Connect, el producto de sincronización y conexión de tercera generación que conecta su centro de datos con servicios de Azure.

Azure AD Connect necesita ser instalado en su red de forma local en una máquina unida al dominio. Aquí está el procedimiento básico:

* Instale Azure AD Connect.

* Cree la siguiente clave del registro y establezca su valor en 1:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSOLCoExistence\PasswordSync\EnableWindowsLegacyCredentialsSync

* Ejecute el siguiente script de PowerShell proporcionado por Microsoft (para que quede claro, yo no escribí esto):

$adConnector = "NOMBRE SENSIBLE DE AD"

$azureadConnector = "NOMBRE DE CONECTOR DE AD AZURE"

Importe Module adsync

$c = Obtener el conector ADSync -Nombrar el conector $ad

$p = Nuevo objeto

Microsoft.IdentityManagement.PowerShell.ObjectModel.ConfigurationParameter

"Microsoft.Synchronize.ForceFullPasswordSync", String, ConnectorGlobal, $null, $null, $null

$p.Valor = 1

$c.GlobalParameters.Remove ($p.Nombre)

$c.GlobalParameters.Add ($p)

$c = Add-ADSyncConnector - Conector $c

Set-ADSyncAADPasswordSyncConfiguration -SourceConnector $adConnector -TargetConnector $azureadConnector -Enable $false

Set-ADSyncAADPasswordSyncConfiguration -SourceConnector $adConnector -TargetConnector $azureadConnector -Enable $true

Precios

Como con todo, hay un costo. En este momento, Azure Active Directory Domain Services cuesta un níquel por hora, o 438 dólares al año para un directorio que tiene cinco mil objetos, 20 centavos de dólar por hora o 1.752 dólares al año para 5001 y 25 mil objetos, y 4.09 dólares por hora o 3.504 dólares al año por hasta 100 mil objetos en el directorio.

Esencialmente, desde una perspectiva de flujo de efectivo, el servicio de directorio de 100 mil objetos cuesta un par de nuevos servidores por año, si no menos, dependiendo de su uso y el recuento del objeto de directorio. Estos objetos son usuarios, equipos o grupos dentro del directorio -cualquier cosa que aparece en el directorio cuenta contra de este límite.

La última palabra

Personalmente creo que Azure AD Domain Services es un hito por una serie de razones. Active Directory está disponible en la nube como un servicio gestionado. El atractivo de la infraestructura como servicio es mayor, ahora que puedo externalizar el directorio de la tubería. Y un futuro en el que no tengo que lidiar con los controladores de dominio está cada vez más cerca. Esta es una característica interesante a observar, y vale la pena darle un vistazo si ha invertido por completo en Azure.

Jonathan Hassell, Computerworld (EE.UU.)