Ejecución de evaluaciones con cuentas de servicio administradas
Las cuentas de servicio administradas (MSA) son un tipo de entidad de seguridad disponible en las versiones compatibles actualmente de Active Directory Domain Services. Comparten características de entidades de seguridad del equipo y del usuario. Se pueden agregar a grupos de seguridad y autenticarse, y también pueden acceder a los recursos de una red. Están destinados a usarse en servicios, grupos de aplicaciones de IIS y tareas programadas.
Ventajas de las cuentas de servicio administradas
Las cuentas de servicio administradas abordan retos específicos inherentes al uso de cuentas de usuario para ejecutar servicios, tareas programadas y grupos de aplicaciones de IIS:
- Administración de contraseñas automática
- Administración de nombres de entidad de servicio (SPN) simplificada
- No se puede usar para el inicio de sesión interactivo en Windows
- Controle fácilmente qué equipos son MSA de autenticación autorizados y ejecute código en su contexto
Evaluaciones a petición que pueden usar cuentas de servicio administradas
Las cuentas de servicio administradas se pueden configurar para ejecutar las evaluaciones a petición siguientes:
- Active Directory
- Active Directory Security
- System Center Configuration Manager
- SharePoint
- SQL Server
- Cliente Windows
- Windows Server
Nota:
El servicio de atención al cliente de Microsoft no admite oficialmente las cuentas de servicio administradas para algunas configuraciones de entorno. Aunque funcionan en la mayoría de los escenarios, es posible que sea necesario usar una cuenta de dominio cuando las configuraciones de entorno impidan el uso de la cuenta de servicio administrada.
Aprovisionar cuentas de servicio administradas
Un requisito previo para configurar una tarea programada de evaluación para que se ejecute como una MSA es el de aprovisionar o crear la MSA en Active Directory Domain Services. Cada una de las evaluaciones admitidas especifica los requisitos de autorización y acceso para que la cuenta de la tarea programada se ejecute correctamente. Consulta los documentos de introducción y los documentos de requisitos previos de la evaluación admitida para obtener los detalles de requisitos de acceso de la cuenta de la tarea programada.
Existen dos tipos de cuentas de servicio administradas. Cualquiera de estas cuentas se puede configurar para la tarea programada de las evaluaciones admitidas:
- Las cuentas de servicio administradas independientes (también conocidas como cuentas virtuales) solo se pueden autorizar para la autenticación en un solo equipo unido a un dominio.
- Las cuentas de servicio administradas de grupo se pueden autorizar para la autenticación en varios equipos de dominio.
El módulo de Active Directory para Windows PowerShell es necesario para el aprovisionamiento y la configuración de ambos tipos de MSA. En los controladores de dominio se suele instalar este módulo de PowerShell durante la instalación del rol de controlador de dominio.
El módulo, un componente de las herramientas del administrador del servidor remoto, se puede agregar a las SKU de Windows Server a través del Administrador del servidor. El módulo también se puede agregar a Windows 10.
Escenario 1: Cuenta de servicio administrada independiente (sMSA)
El esquema de bosque de Active Directory Domain Services debe tener como mínimo Windows Server 2008 R2 para aprovisionar cuentas de servicio administradas independientes correctamente. Los equipos que ejecutan tareas programadas como una sMSA deben ejecutar Windows Server 2012 o una versión más reciente.
Existen tres pasos para aprovisionar una sMSA para la ejecución de evaluaciones a petición:
- Crear la sMSA mediante el cmdlet New-ADServiceAccount de PowerShell.
- Autorizar a la máquina de recopilación de datos para obtener la contraseña de la sMSA mediante el cmdlet Add-ADComputerServiceAccount de PowerShell.
- Conceder a la sMSA el acceso necesario para el entorno que se está evaluando según la documentación de requisitos previos de la evaluación que se está configurando.
Crear una cuenta de servicio administrada independiente
Para crear la sMSA, ejecute el comando siguiente en una sesión de PowerShell de un controlador de dominio o un miembro de dominio con el módulo de Active Directory para Windows PowerShell instalado mediante una cuenta con los permisos necesarios para crear cuentas en Active Directory (los operadores de cuentas y los administradores de dominio tienen los permisos necesarios de forma predeterminada).
New-ADServiceAccount -Name <sMSAaccountname> -RestrictToSingleComputer
Por ejemplo: PS C:> New-ADServiceAccount -Name sMSA-SVC -RestrictToSingleComputer
Autorizar a la máquina de recopilación de datos para usar la sMSA
Para autorizar a la máquina de recopilación de datos para obtener la contraseña de la sMSA, ejecute el comando siguiente en una sesión de PowerShell de un controlador de dominio o un miembro de dominio con el módulo de Active Directory para Windows PowerShell instalado mediante una cuenta con los permisos necesarios para crear cuentas en Active Directory (los operadores de cuentas y los administradores de dominio tienen los permisos necesarios de forma predeterminada).
Add-ADComputerServiceAccount -Identity “datacollectionmachine$” -ServiceAccount “sMSA samaccountname”
Por ejemplo: Add-ADComputerServiceAccount -Identity "OMS-AD-Tools$" -ServiceAccount "sMSA-SVC$"
Instalación de sMSA en la máquina de recopilación de datos
El almacenamiento en caché previo de sMSA en la máquina de recopilación de datos es un importante paso de validación para garantizar que la cuenta se aprovisiona correctamente y la máquina de recopilación de datos puede recuperar correctamente la contraseña de sMSA y usar la cuenta. En la máquina de recopilación de datos con el módulo Active Directory Powershell instalado, ejecute lo siguiente.
Install-ADServiceAccount -Identity “sMSA samaccountname”
Por ejemplo: Install-ADServiceAccount -Identity "sMSA-SVC$"
Nota:
Si se devuelve un error de cmdlet no encontrado, instala el módulo Active Directory Powershell, como se explica en Aprovisionar cuentas de servicio administradas más arriba.
Para otros errores, revisa el canal de registro de eventos de Microsoft-Windows-Security-Netlogon/Operational para eventos de categoría MSA.
Escenario 2: Cuenta de servicio administrada de grupo (gMSA)
El esquema de bosque de Active Directory Domain Services debe tener como mínimo Windows Server 2012 para aprovisionar cuentas de servicio administradas de grupo correctamente. Los equipos que ejecutan tareas programadas como una gMSA deben ejecutar Windows Server 2012 o una versión más reciente.
Existen tres pasos para aprovisionar una gMSA para la ejecución de evaluaciones a petición:
- Crear la clave raíz del Servicio de distribución de claves KDS en Active Directory mediante Add-KDSRootKey
- Crear la gMSA y autorizar a la máquina de recopilación de datos para obtener la contraseña de la gMSA mediante el cmdlet New-ADServiceAccount de PowerShell.
- Conceder a la gMSA el acceso necesario para el entorno que se está evaluando según la documentación de requisitos previos de la evaluación que se está configurando.
Aprovisionar la clave raíz de KDS
Es necesario crear primero la clave raíz de KDS si nunca se ha creado en el bosque de Active Directory. Para determinar si existe una clave raíz de KDS, ejecute el comando siguiente desde una sesión de PowerShell.
Get-KdsRootKey
Nota:
Si el comando no devuelve nada, no existe ninguna clave raíz en el bosque de Active Directory.
Para crear la clave raíz de KDS, ejecute el comando siguiente en una sesión de PowerShell de un controlador de dominio o un miembro de dominio con el módulo de Active Directory para Windows PowerShell instalado mediante una cuenta con los permisos necesarios para crear cuentas en Active Directory (los administradores empresariales y los administradores de dominio del dominio raíz del bosque tienen los permisos necesarios de forma predeterminada).
Add-KdsRootKey -EffectiveImmediately
Add-KdsRootKey -EffectiveImmediately permite la creación de gMSA después de 10 horas para garantizar la convergencia de la replicación en todos los controladores de dominio.
Add-KdsRootKey -EffectiveTime ((get-date).addhours(-10))
Add-KdsRootKey -EffectiveTime ((get-date).addhours(-10)) permite la creación inmediata de gMSA.
Este enfoque implica algunos riesgos de creación o uso de gMSA con errores si la convergencia de replicación de AD en todo el bosque tarda varias horas en operaciones normales.
Crear una cuenta de servicio administrada de grupo
Para crear la gMSA, ejecute el comando siguiente en una sesión de PowerShell de un controlador de dominio o un miembro de dominio con el módulo de Active Directory para Windows PowerShell instalado mediante una cuenta con los permisos necesarios para crear cuentas en Active Directory (los operadores de cuentas y los administradores de dominio tienen los permisos necesarios de forma predeterminada).
New-ADServiceAccount -Name <gMSAaccountname> -DNSHostname <gMSAaccountname.FQDN> -PrincipalsAllowedToRetrieveManagedPassword “data collection machine samaccountname”
Por ejemplo: PS C:> New-ADServiceAccount -Name gMSA-SVC -DNSHostName gMSA-SVC.contoso.local -PrincipalsAllowedToRetrieveManagedPassword "oms-ad-tools$"
Instalación de gMSA en la máquina de recopilación de datos
El almacenamiento en caché previo de gMSA en la máquina de recopilación de datos es un importante paso de validación para garantizar que la cuenta se aprovisiona correctamente y la máquina de recopilación de datos puede recuperar correctamente la contraseña de gMSA y usar la cuenta. En la máquina de recopilación de datos con el módulo Active Directory Powershell instalado, ejecute lo siguiente.
Install-ADServiceAccount -Identity “gMSA samaccountname”
Por ejemplo: Install-ADServiceAccount -Identity "gMSA-SVC$"
Nota:
Si se devuelve un error de cmdlet no encontrado, instala el módulo Active Directory Powershell, como se explica en Aprovisionar cuentas de servicio administradas más arriba.
Para otros errores, revisa el canal de registro de eventos de Microsoft-Windows-Security-Netlogon/Operational para eventos de categoría MSA.