Compartir vía


Conceptos de administración para cuentas de usuario, contraseñas y administración en Microsoft Entra Domain Services

Al crear y ejecutar un dominio administrado de Microsoft Entra Domain Services, hay algunas diferencias en el comportamiento en comparación con un entorno de AD DS local tradicional. Puede usar las mismas herramientas administrativas en Domain Services como dominio autoadministrado, pero no puede obtener acceso directo a los controladores de dominio (DC). Hay algunas diferencias en el comportamiento para las directivas de contraseña y los valores hash de contraseñas dependiendo del origen de la creación de cuentas de usuario.

En este artículo conceptual se detalla cómo gestionar un dominio administrado y el comportamiento diferente de las cuentas de usuario dependiendo de cómo se crean.

Administración de dominios

Un dominio administrado es un espacio de nombres DNS y un directorio coincidente. En un dominio administrado, los controladores de dominio (DC) que contienen todos los recursos, como usuarios y grupos, credenciales y directivas, forman parte del servicio administrado. Para ofrecer redundancia, se crean dos DC como parte de un dominio administrado. No puede iniciar sesión en estos DC para realizar tareas de administración. En su lugar, cree una máquina virtual de administración unida al dominio administrado y, a continuación, instale sus herramientas de administración de AD DS regulares. Puede usar los complementos del Centro de administración de Active Directory o Microsoft Management Console (MMC) como, por ejemplo, objetos de directiva de grupo o DNS.

Creación de una cuenta de usuario

Las cuentas de usuario se pueden crear en un dominio administrado de varias formas. La mayoría de las cuentas de usuario se sincronizan desde Microsoft Entra ID, lo que también puede incluir cuentas de usuario sincronizadas desde un entorno de AD DS local. También puede crear de forma manual cuentas directamente en el dominio administrado. Algunas características, como la directiva de contraseñas o la sincronización de contraseña inicial, se comportan de forma diferente dependiendo de cómo y dónde se crean las cuentas de usuario.

  • La cuenta de usuario se puede sincronizar desde Microsoft Entra ID. Esto incluye las cuentas de usuario solo en la nube creadas directamente en Microsoft Entra ID y las cuentas de usuario híbridas sincronizadas desde un entorno de AD DS local mediante Microsoft Entra Connect.
    • La mayoría de las cuentas de usuario de un dominio administrado se crean a través del proceso de sincronización de Microsoft Entra ID.
  • La cuenta de usuario se puede crear manualmente en un dominio administrado y no existe en Microsoft Entra ID.
    • Si tiene que crear cuentas de servicio para aquellas aplicaciones que solo se ejecutan en el dominio administrado, puede crearlas manualmente en el dominio administrado. Dado que la sincronización es una forma de Microsoft Entra ID, las cuentas de usuario creadas en el dominio administrado no se vuelven a sincronizar con Microsoft Entra ID.

Directiva de contraseñas

Domain Services incluye una directiva de contraseñas predeterminada que define la configuración para elementos como el bloqueo de cuenta, la antigüedad máxima de contraseña y la complejidad de la contraseña. Opciones de configuración como la directiva de bloqueo de cuentas se aplican a todos los usuarios en un dominio administrado, independientemente de cómo se creó el usuario tal como se señala en la sección anterior. Algunos valores de configuración, como la longitud mínima de contraseña y la complejidad de la contraseña, solo se aplican a los usuarios creados directamente en un dominio administrado.

Puede crear sus propias directivas de contraseñas personalizadas para reemplazar la directiva predeterminada en un dominio administrado. Estas directivas personalizadas se pueden aplicar a continuación a grupos de usuarios específicos según sea necesario.

Para obtener más información sobre las diferencias en el modo en que se aplican las directivas de contraseñas dependiendo del origen de la creación de usuarios, consulte Directivas de bloqueo de cuenta y contraseña en dominios administrados.

Valores hash de contraseñas

Para autenticar a los usuarios en el dominio administrado, Domain Services necesita los hash de las contraseñas en un formato adecuado para la autenticación de NT LAN Manager (NTLM) y Kerberos. Microsoft Entra ID no genera ni almacena hash de contraseña en el formato necesario para la autenticación NTLM o Kerberos hasta que habilite Domain Services para su inquilino. Por motivos de seguridad, Microsoft Entra ID tampoco almacena las credenciales de contraseñas en forma de texto sin cifrar. Por consiguiente, Microsoft Entra ID no tiene forma de generar automáticamente estos hash de las contraseñas de NTLM o Kerberos basándose en las credenciales existentes de los usuarios.

En el caso de las cuentas de usuario solo de nube, los usuarios deben cambiar sus contraseñas para poder usar el dominio administrado. Este proceso de cambio de contraseña hace que los valores hash de contraseña para la autenticación Kerberos y NTLM se generen y almacenen en Microsoft Entra ID. La cuenta no se sincroniza desde Microsoft Entra ID a Domain Services hasta que se cambia la contraseña.

Para los usuarios sincronizados desde un entorno de AD DS local mediante Microsoft Entra Connect, habilite la sincronización de los valores hash de contraseñas.

Importante

Microsoft Entra Connect solo sincroniza los hash de contraseña heredados al habilitar Domain Services para el inquilino de Microsoft Entra. Los hashes de contraseña heredados no se usan si solo utiliza Microsoft Entra Connect para sincronizar un entorno de AD DS local con Microsoft Entra ID.

Si las aplicaciones heredadas no utilizan la autenticación NTLM o los enlaces simples LDAP, se recomienda deshabilitar la sincronización de hash de contraseña de NTLM para Domain Services. Para más información, consulte Deshabilitación de la sincronización de hash de credenciales NTLM y de conjuntos de cifrado débil.

Una vez configurados correctamente, los hash de las contraseñas que se pueden usar se almacenan en el dominio administrado. Si elimina el dominio administrado, también se eliminarán los hash de las contraseñas que haya almacenados en ese momento. La información de credenciales sincronizadas en Microsoft Entra ID no se puede reutilizar si luego crea otro dominio administrado; debe reconfigurar la sincronización de hash de contraseña para almacenar los hashes de contraseña nuevamente. Las máquinas virtuales o los usuarios previamente unidos al dominio no podrán autenticarse inmediatamente: Microsoft Entra ID necesita generar y almacenar los hashes de contraseña en el nuevo dominio administrado. Para más información, consulte Proceso de sincronización de hash de contraseñas para Domain Services y Microsoft Entra Connect.

Importante

Microsoft Entra Connect solo debe instalarse y configurarse para la sincronización con entornos de AD DS locales. No se admite la instalación de Microsoft Entra Connect en un dominio administrado para volver a sincronizar objetos con Microsoft Entra ID.

Bosques y confianzas

Un bosque es una construcción lógica que Active Directory Domain Services (AD DS) usa para agrupar uno o más dominios. Estos dominios almacenan objetos para los usuarios o grupos, y proporcionan servicios de autenticación.

En Domain Services, el bosque solo contiene un dominio. Los bosques de entornos de AD DS locales suelen contener varios dominios. En organizaciones de gran tamaño, especialmente después de fusiones y adquisiciones, es posible que acabe con varios bosques locales y que cada uno contenga varios dominios.

De forma predeterminada, un dominio administrado sincroniza todos los objetos de Microsoft Entra ID, incluidas las cuentas de usuario creadas en un entorno de AD DS local. Las cuentas de usuario se pueden autenticar directamente en el dominio administrado, por ejemplo, para iniciar sesión en una máquina virtual unida a un dominio. Esta solución funciona cuando se pueden sincronizar los hashes de contraseña y los usuarios no usan métodos de inicio de sesión exclusivos, como la autenticación de tarjeta inteligente.

En Domain Services, también puede crear una confianza de bosque con otro dominio para permitir que los usuarios accedan a los recursos. En función de los requisitos de acceso, puede crear la confianza de bosque en diferentes direcciones.

Dirección de confianza Acceso de usuarios
Bidireccional Permite a los usuarios del dominio administrado y del dominio local acceder a los recursos de cualquier dominio.
Saliente unidireccional Permite a los usuarios del dominio local acceder a los recursos del dominio administrado, pero no al contrario.
Entrante unidireccional Permite a los usuarios del dominio administrado acceder a los recursos del dominio local.

SKU de Domain Services

En Domain Services, el rendimiento y las características disponibles dependen de la SKU. Puede seleccionar la SKU al crear el dominio administrado y cambiarla después si los requisitos del negocio varían una vez implementado el dominio administrado. En la tabla siguiente, se incluyen las SKU disponibles y las diferencias entre ellas:

Nombre de SKU Número máximo de objetos Frecuencia de copia de seguridad
Estándar Sin límite Cada 5 días
Enterprise Sin límite Cada 3 días
Premium Sin límite Diario

Antes de utilizar estas SKU de Domain Services, se empleaba un modelo de facturación basado en el número de objetos (cuentas de usuario y de equipo) del dominio administrado. Este modelo de precios variables que se basaban en el número de objetos del dominio administrado ya no está disponible.

Para obtener más información, consulte la página de precios de Domain Services.

Rendimiento del dominio administrado

El rendimiento del dominio varía en función del modo en que la autenticación de una aplicación esté implementada. Además, puede haber otros recursos que mejoren el tiempo de respuesta de las consultas y reduzcan el tiempo de las operaciones de sincronización. A medida que el nivel de SKU aumenta, también lo hacen los recursos de proceso disponibles en el dominio administrado. Supervise el rendimiento de las aplicaciones y planee los recursos necesarios.

Si el negocio o la aplicación exigen cambios y necesita más capacidad de proceso para el dominio administrado, puede cambiar a otra SKU.

Frecuencia de copia de seguridad

La frecuencia de copia de seguridad determina la asiduidad con la que se toma una instantánea del dominio administrado. Las copias de seguridad son un proceso automatizado administrado por la plataforma Azure. Si se produce un problema con el dominio administrado, el Soporte técnico de Azure puede ayudarle a restaurar el sistema desde la copia de seguridad. Como la sincronización es un proceso unidireccional que se realiza desde Microsoft Entra ID, los problemas que se produzcan en el dominio administrado no afectarán a Microsoft Entra ID ni a la funcionalidad y los entornos locales de AD DS.

A medida que el nivel de SKU aumente, lo hará también la frecuencia con la que se realizan instantáneas de copia de seguridad. Analice los requisitos empresariales y el objetivo de punto de recuperación (RPO) para determinar la frecuencia de copia de seguridad necesaria para el dominio administrado. Si los requisitos del negocio o de la aplicación cambian y necesita hacer copias de seguridad con mayor frecuencia, puede cambiar a una SKU diferente.

Domain Services proporciona las siguientes instrucciones para los intervalos de tiempo de recuperación para distintos tipos de problemas:

  • El objetivo de punto de recuperación (RPO) es el intervalo de tiempo máximo en el que hay una posible pérdida de datos o transacciones de un incidente.
  • El objeto de tiempo de recuperación (RTO) es el intervalo de tiempo de destino que se produce antes de que los niveles de servicio vuelvan a funcionar después de un incidente.
Problemas RPO RTO
Problemas causados por la pérdida de datos o daños en controladores de dominio de Domain Services, servicios dependientes, una vulnerabilidad de seguridad que ha comprometido el dominio u otro incidente que requiere restaurar un controlador de dominio. Cinco días antes de la aparición del evento Dos horas a cuatro días, según el tamaño del inquilino
Problemas identificados por nuestros diagnósticos de dominio. Cero (0 minutos) Dos horas a cuatro días, según el tamaño del inquilino

Pasos siguientes

Para empezar, cree un dominio administrado de Domain Services.