Conceptos clave de AWS Managed Microsoft AD - AWS Directory Service

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Conceptos clave de AWS Managed Microsoft AD

Sacará el máximo partido de AWS Managed Microsoft AD si se familiariza con los siguientes conceptos clave.

Esquema de Active Directory

Un esquema es la definición de atributos y clases que forman parte de un directorio distribuido y es similar a los campos y las tablas de una base de datos. Los esquemas incluyen un conjunto de reglas que determinan el tipo y el formato de los datos que se pueden añadir o incluir en la base de datos. La clase User es un ejemplo de un valor class que se almacena en la base de datos. Algunos ejemplos de atributos de la clase User pueden incluir el nombre, apellidos, número de teléfono, etc.

Elementos del esquema

Los atributos, las clases y los objetos son los elementos básicos utilizados para crear definiciones de objetos en el esquema. A continuación se ofrece información detallada sobre los elementos de esquema que es importante que conozca antes de empezar el proceso de ampliación del esquema de AWS Managed Microsoft AD.

Atributos

Cada atributo de esquema, que es similar a un campo en una base de datos, tiene varias propiedades que definen las características del atributo. Por ejemplo, la propiedad LDAP que utilizan los clientes para leer y escribir el atributo es LDAPDisplayName. La propiedad LDAPDisplayName debe ser única en todos los atributos y clases. Para obtener una lista completa de las características de atributos, consulte Characteristics of Attributes en el sitio web de MSDN. Si desea obtener instrucciones adicionales sobre cómo crear un atributo, consulte Defining a New Attribute en el sitio web de MSDN.

Clases

Las clases se parecen a las tablas de una base de datos, y también tienen varias propiedades que es necesario definir. Por ejemplo, objectClassCategory define la categoría de clase. Para obtener una lista completa de las características de clase, consulte Characteristics of Object Classes en el sitio web de MSDN. Para obtener más información sobre cómo crear una nueva clase, consulte Defining a New Class en el sitio web de MSDN.

Identificador de objeto (OID)

Cada clase y atributo deben tener un OID exclusivo para todos los objetos. Los proveedores de software deben obtener su propio OID para garantizar la unicidad. La unicidad evita conflictos en el supuesto de que se utilice el mismo atributo en más de una solicitud para finalidades diferentes. Para garantizar la originalidad, puede obtener un OID raíz de una autoridad de registro de nombres de ISO. También puede obtener un OID básico de Microsoft. Para obtener más información sobre los OID y cómo obtenerlos, consulte Identificadores de objetos en el sitio web de MSDN.

Atributos vinculados a esquemas

Algunos atributos están vinculados a dos clases, con vínculos de paso y retroceso. Un excelente ejemplo de ello son los grupos. Si mira un grupo, verá los miembros de ese grupo; si echa un vistazo a un usuario, verá a qué grupos pertenece. Cuando añada un usuario a un grupo, Active Directory creará un vínculo al grupo y después Active Directory añadirá un vínculo para volver del grupo al usuario. Se debe generar un identificador de vínculo único al crear un atributo que se vinculará. Para obtener más información, consulte Linked Attributes en el sitio web de MSDN.

Aplicación de parches y mantenimiento de AWS Managed Microsoft AD

AWS Directory Service para Microsoft Active Directory, también conocido como AWS DS para AWS Managed Microsoft AD, en realidad es Microsoft Active Directory Domain Services (AD DS), entregado como un servicio administrado. El sistema utiliza Microsoft Windows Server 2019 para los controladores de dominio (DC) y AWS les agrega software para administrar servicios. AWS actualiza (aplica parches) a los DC para agregar nuevas funcionalidades y mantener el software de Microsoft Windows Server al día. Durante el proceso de aplicación de parches, el directorio continúa disponible para su uso.

Asegurar la disponibilidad

De forma predeterminada, cada directorio consta de dos DC, cada uno de ellos instalado en una zona de disponibilidad diferente. Si lo desea, puede agregar DC para aumentar aún más la disponibilidad. Para los entornos críticos que necesitan alta disponibilidad y tolerancia a errores, recomendamos implementar centros de distribución adicionales. AWSparchea los DC de forma secuencial, tiempo durante el cual el DC que AWS está parcheando activamente no está disponible. En caso de que uno o más de sus DC esté fuera de servicio temporalmente, AWS retrasa la aplicación de parches hasta que haya al menos dos DC operativos en el directorio. Esta función le permite utilizar el resto de los DC en funcionamiento durante el proceso de aplicación de parches, que suele tardar entre 30 y 45 minutos por cada DC, aunque puede variar. Para garantizar que las aplicaciones puedan obtener acceso a un DC en funcionamiento en caso de que uno o varios DC no estén disponibles por cualquier motivo, incluida la aplicación de parches, estas deberían utilizar el servicio de localización de DC de Windows y no utilizar direcciones de DC estáticas.

Cómo funciona la programación de aplicación de parches

Para mantener el software de Microsoft Windows Server actualizado en los DC, AWS utiliza actualizaciones de Microsoft. Como cada mes Microsoft ofrece paquetes acumulativos de parches para Windows Server, AWS hace todo lo posible para probar y aplicar dichos paquetes a todos los DC de los clientes en el plazo de tres semanas naturales. Además, AWS revisa las actualizaciones que Microsoft publica fuera del paquete mensual acumulativo en función de su aplicabilidad a los DC y su urgencia. En el caso de los parches de seguridad que Microsoft clasifica como críticos o importantes, y que son relevantes para los DC, AWS hace todo lo posible para probarlos e implementarlos en un plazo de cinco días.

Cuentas de servicio administradas por grupos

Con Windows Server 2012, Microsoft introdujo un nuevo método que los administradores pueden utilizar para administrar cuentas de servicio llamado “cuentas de servicio administradas por grupos (gMSA)”. Con las gMSA, los administradores de servicios ya no tienen que administrar manualmente la sincronización de contraseñas entre las instancias de servicio. En cambio, un administrador podría simplemente crear una gMSA en Active Directory y, a continuación, configurar varias instancias de servicio para utilizar esa única gMSA.

Para conceder permisos de tal forma que los usuarios de AWS Managed Microsoft AD puedan crear una gMSA, debe agregar sus cuentas como miembro del grupo de seguridad Administradores delegados de AWS para cuentas de servicio administradas. De forma predeterminada, la cuenta de administrador es miembro de este grupo. Para obtener más información sobre las GMSA, consulte Descripción general de las cuentas de servicio gestionadas por grupos en el sitio web de Microsoft TechNet .

Artículo relacionado del blog de AWS sobre seguridad

Delegación limitada de Kerberos

La delegación limitada de Kerberos es una característica de Windows Server. Esta característica otorga a los administradores del servicio la capacidad de especificar y aplicar límites de confianza en una aplicación limitando el alcance hasta el que pueden actuar los servicios de esta última en representación de un usuario. Esto puede resultar útil cuando es preciso configurar qué cuentas del servicio de frontend pueden delegar en sus servicios de backend. La delegación limitada de Kerberos también evita que la gMSA se conecte a cualquier servicio en nombre de sus usuarios de Active Directory, con lo que se evita la posibilidad de abusos por parte de un desarrollador deshonesto.

Por ejemplo, supongamos que el usuario jsmith inicia sesión en una aplicación de recursos humanos. Quiere que SQL Server aplique los permisos de base de datos de jsmith. Sin embargo, de forma predeterminada, SQL Server abre la conexión a la base de datos con las credenciales de la cuenta de servicio que aplican hr-app-service los permisos en lugar de los permisos configurados por jsmith. Debe permitir que la aplicación de pago de nóminas de recursos humanos obtenga acceso a la base de datos de SQL Server con las credenciales de jsmith. Para ello, habilita la delegación restringida de Kerberos para la cuenta de hr-app-service servicio en el directorio de AWS Microsoft AD administrado en. AWS Cuando jsmith inicie sesión, Active Directory facilitará un ticket de Kerberos que Windows utilizará automáticamente cuando jsmith intente obtener acceso a otros servicios en la red. La delegación de Kerberos permite a la hr-app-service cuenta reutilizar el vale Kerberos de jsmith al acceder a la base de datos y, por lo tanto, aplicar los permisos específicos de jsmith al abrir la conexión a la base de datos.

Para conceder permisos que permitan a los usuarios de AWS Managed Microsoft AD configurar la delegación limitada de Kerberos, debe agregar sus cuentas como miembro del grupo de seguridad Administradores delegados de AWS para la delegación Kerberos. De forma predeterminada, la cuenta de administrador es miembro de este grupo. Para obtener más información sobre la delegación restringida de Kerberos, consulte Descripción general de la delegación restringida de Kerberos en el sitio web de Microsoft. TechNet

La delegación restringida basada en recursos se introdujo con Windows Server 2012. Proporciona al administrador del servicio backend la capacidad de configurar la delegación restringida para el servicio.