Instrucciones sobre cómo configurar cuentas protegidas
Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2 y Windows Server 2012.
En los ataques del tipo "pasar el hash" (PtH), un atacante puede autenticarse en un servidor o servicio remoto usando el hash de NTLM subyacente de la contraseña de un usuario (u otros derivados de las credenciales). Microsoft ya ha publicado instrucciones para mitigar los ataques pass-the-hash. Windows Server 2012 R2 incluye nuevas características para mitigar aún más estos ataques. Para obtener más información sobre otras características de seguridad que ayudan a proteger contra el robo de credenciales, consulte Protección y administración de credenciales. En este tema se explica cómo configurar las siguientes características nuevas:
Hay otras soluciones integradas en Windows 8.1 y Windows Server 2012 R2 para ayudar a proteger contra el robo de credenciales, que se tratan en los siguientes temas:
Usuarios protegidos
Usuarios protegidos es un nuevo grupo de seguridad global al que puedes agregar usuarios nuevos o existentes. Los dispositivos de Windows 8.1 y los hosts de Windows Server 2012 R2 se comportan de una manera especial con los miembros de este grupo para proporcionar más protección contra el robo de credenciales. Para los miembros del grupo, un dispositivo con Windows 8.1 o un host con Windows Server 2012 R2 no almacenan en caché credenciales no admitidas para Usuarios protegidos. Los miembros de este grupo no tienen protección adicional si han iniciado sesión en un dispositivo que ejecuta una versión de Windows anterior a Windows 8.1.
Los miembros del grupo Usuarios protegidos que han iniciado sesión en dispositivos de Windows 8.1 y hosts de Windows Server 2012 R2 ya no pueden usar:
Delegación de credenciales predeterminada (CredSSP): las credenciales de texto sin formato no se almacenan en caché aunque la directiva Permitir delegación de credenciales predeterminadas esté habilitada.
Autenticación implícita de Windows: las credenciales de texto sin formato no se almacenan en caché aunque estén habilitadas.
NTLM: NTOWF no se almacena en caché.
Claves a largo plazo de Kerberos: el vale de concesión de vales (TGT) de Kerberos se adquiere al iniciar sesión y no se puede volver a adquirir automáticamente.
Inicio de sesión sin conexión: no se crea el comprobador de inicio de sesión en caché.
Si el nivel funcional del dominio es Windows Server 2012 R2, los miembros del grupo ya no pueden:
Autenticarse mediante autenticación NTLM.
Usar los conjuntos de cifrado Estándar de cifrado de datos (DES) o RC4 en la autenticación previa de Kerberos.
Ser delegados mediante delegación limitada o sin limitar.
Renovar los vales de usuario (TGT) más allá de las 4 horas de vigencia inicial.
Para agregar usuarios al grupo, puede usar Herramientas de interfaz de usuario como el Centro de administración de Active Directory (ADAC) o Usuarios y equipos de Active Directory, o una herramienta de línea de comandos como Dsmod group o el cmdlet Add-ADGroupMember de Windows PowerShell. Las cuentas de servicio y de equipo no deben ser miembros del grupo Usuarios protegidos. En estas cuentas, la pertenencia no proporciona protección local porque la contraseña o el certificado siempre están disponibles en el host.
Advertencia
Las restricciones de autenticación no tienen solución alternativa, lo que significa que los miembros de los grupos de privilegios elevados, como el grupo Administradores de organización o el grupo Admins. del dominio están sujetos a las mismas restricciones que los demás miembros del grupo Usuarios protegidos. Si se agregan todos los miembros de estos grupos al grupo Usuarios protegidos, es posible que todas esas cuentas se bloqueen. No agregue nunca cuentas con privilegios elevados al grupo Usuarios protegidos hasta que haya probado exhaustivamente sus posibles efectos.
Los miembros del grupo Usuarios protegidos deben poder autenticarse mediante Kerberos con Estándar de cifrado avanzado (AES). Este método requiere claves de AES para la cuenta en Active Directory. El administrador integrado no tiene una clave de AES a menos que la contraseña se haya cambiado en un controlador de dominio que ejecute Windows Server 2008 o posterior. Además, se bloquean todas las cuentas que tengan una contraseña que se cambió en un controlador de dominio que ejecute una versión anterior de Windows Server. Por lo tanto siga estos procedimientos recomendados:
No realice pruebas en dominios a menos que todos los controladores de dominio ejecuten Windows Server 2008 o posterior.
Usa Cambiar contraseña para todas las cuentas de dominio que se crearon antes de crear el dominio. De lo contrario, estas cuentas no se podrán autenticar.
Use Cambiar contraseña para cada usuario antes de agregar la cuenta al grupo Usuarios protegidos o asegúrese de que la contraseña se cambió recientemente en un controlador de dominio que ejecute Windows Server 2008 o posterior.
Requisitos para usar cuentas protegidas
Las cuentas protegidas tienen los siguientes requisitos de implementación:
Para proporcionar restricciones en el lado del cliente para los usuarios protegidos, los hosts deben ejecutar Windows 8.1 o Windows Server 2012 R2. Un usuario solo tiene que iniciar sesión con una cuenta que sea miembro del grupo Usuarios protegidos. En este caso, el grupo Usuarios protegidos se puede crear transfiriendo el rol de emulador del controlador de dominio principal (PDC) a un controlador de dominio que ejecute Windows Server 2012 R2. Una vez replicado ese grupo a otros controladores de dominio, el rol de emulador de PDC se puede hospedar en un controlador de dominio que ejecuta una versión anterior de Windows Server.
Para proporcionar restricciones en el lado del controlador de dominio para los usuarios protegidos, es decir, para restringir el uso de la autenticación NTLM y otras restricciones, el nivel funcional del dominio debe ser Windows Server 2012 R2. Para obtener más información sobre los niveles funcionales inferiores, consulte Descripción de los niveles funcionales de Servicios de dominio de Active Directory (AD DS).
Nota
El administrador de dominio integrado (S-1-5-<domain>-500) siempre está exento de las directivas de autenticación, incluso cuando se asignan a un silo de directiva de autenticación.
Solucionar problemas de eventos relativos a usuarios protegidos
En esta sección se describen los nuevos registros que ayudan a solucionar problemas de eventos relativos a los usuarios protegidos, y cómo los usuarios protegidos pueden afectar a los cambios para solucionar problemas como la expiración de los vales de concesión de vales (TGT) o los problemas de delegación.
Nuevos registros para usuarios protegidos
Hay dos nuevos registros administrativos operativos para ayudar a solucionar problemas de eventos que están relacionados con los usuarios operativos: Usuario protegido – Registro de clientes y errores de usuarios protegidos – Registro de controladores de dominio. Estos nuevos registros están ubicados en el Visor de eventos y están deshabilitados de forma predeterminada. Para habilitar un registro, haz clic en Registros de aplicaciones y servicios, en Microsoft, en Windows, en Autenticación y haz clic en el nombre del registro, en Acción (o haz clic con el botón derecho en el registro) y en Habilitar registro.
Para obtener más información acerca de los eventos de estos registros, consulte Directivas de autenticación y silos de directivas de autenticación.
Solucionar problemas de expiración de TGT
Normalmente, el controlador de dominio establece la vigencia del TGT y su renovación según la directiva del dominio, tal y como se muestra en la siguiente ventana del Editor de administración de directivas de grupo.
Para los Usuarios protegidos, las siguientes opciones se codifican de forma rígida:
Vigencia máxima del vale de usuario: 240 minutos
Vigencia máxima de renovación de vales de usuario: 240 minutos
Solucionar problemas de delegación
Anteriormente, si una tecnología que usa delegación de Kerberos producía un error, se comprobaba la cuenta de cliente para ver si la opción La cuenta es importante y no se puede delegar estaba establecida. Sin embargo, si la cuenta es miembro de Usuarios protegidos, quizás no tenga esta opción configurada en el Centro de administración de Active Directory (ADAC). Por lo tanto, comprueba la opción y la pertenencia al grupo cuando soluciones problemas de delegación.
Auditar los intentos de autenticación
Para auditar los intentos de autenticación explícitamente para los miembros del grupo Usuarios protegidos, puedes continuar recopilando eventos de auditoría del registro de seguridad o puedes recopilar los datos de los nuevos registros administrativos operativos. Para obtener más información acerca de estos eventos, consulte Directivas de autenticación y silos de directivas de autenticación.
Proporcionar protección en el lado del controlador de dominio para servicios y equipos
Las cuentas de servicios y equipos no pueden ser miembros de Usuarios protegidos. En esta sección se explica qué protecciones de controlador de dominio se pueden ofrecer para estas cuentas:
Rechazar la autenticación NTLM: Solo se puede configurar a través de directivas de bloqueo de NTLM
Rechazar el estándar de cifrado de datos (DES) en la autenticación previa de Kerberos: los controladores de dominio de Windows Server 2012 R2 no aceptan DES para cuentas de equipo a menos que se configuren solo para DES porque todas las versiones de Windows lanzadas con Kerberos también admiten R2.
Rechazar RC4 en la autenticación previa de Kerberos: no configurable.
Nota
Aunque se puede cambiar la configuración de los tipos de cifrado admitidos, no se recomienda cambiar esta configuración para las cuentas de equipo sin probarla en el entorno de destino.
Restringir los vales de usuario (TGT) a las 4 horas de vigencia inicial: usa directivas de autenticación.
Denegar la delegación con delegación limitada o no limitada: Para restringir una cuenta, abre el Centro de administración de Active Directory (ADAC) y activa la casilla La cuenta es importante y no se puede delegar .
Directivas de autenticación
Directivas de autenticación es un nuevo contenedor de AD DS que contiene objetos de directiva de autenticación. Las directivas de autenticación pueden especificar configuraciones que ayuden a mitigar la exposición a robos de credenciales, como restringir la vigencia de los TGT para las cuentas o agregar otras condiciones relativas a notificaciones.
En Windows Server 2012 R2, el control de acceso dinámico incorporó una clase de objeto en el ámbito del bosque de Active Directory llamada Directiva de acceso central, que ofrece una manera fácil de configurar los servidores de archivos de una organización. En Windows Server 2012 R2, se puede usar una nueva clase de objeto llamada Directiva de autenticación (objectClass msDS-AuthNPolicies) para aplicar la configuración de autenticación a clases de cuentas en dominios de Windows Server 2012 R2. Las clases de cuentas de Active Directory son las siguientes:
Usuario
Computer
Cuenta de servicio administrada y cuenta de servicio administrada de grupo (GMSA)
Actualizador de Kerberos rápido
El protocolo de autenticación Kerberos consiste en tres tipos de intercambios, también conocidos como subprotocolos:
Intercambio del servicio de autenticación (AS) (KRB_AS_*)
Intercambio del servicio de concesión de vales (TGS) (KRB_TGS_*)
Intercambio cliente/servidor (AP) (KRB_AP_*)
En el intercambio AS, el cliente usa la contraseña o la clave privada de la cuenta para crear un autenticador previo para solicitar un vale de concesión de vales (TGT). Esto sucede durante el inicio de sesión o la primera vez que se necesita un vale de servicio.
En el intercambio TGS, se usa el TGT de una cuenta para crear un autenticador para solicitar un vale de servicio. Esto sucede cuando se necesita una conexión autenticada.
El intercambio AP se produce con la misma frecuencia que los datos dentro del protocolo de la aplicación, y no se ve afectado por las directivas de autenticación.
Para obtener información más detallada, consulte Cómo funciona el protocolo de autenticación Kerberos versión 5.
Información general
Las directivas de autenticación complementan el grupo de usuarios protegidos porque proporcionan una manera de aplicar restricciones configurables a las cuentas, además de restricciones a las cuentas de servicios y equipos. Las directivas de autenticación se aplican durante el intercambio AS o el intercambio TGS.
Puedes configura lo siguiente para limitar la autenticación inicial o el intercambio AS:
Una vigencia de TGT.
Condiciones de control de acceso para restringir el inicio de sesión de usuarios, que deben cumplir los dispositivos desde los que procede el intercambio AS.
Puedes configurar lo siguiente para restringir las solicitudes de vales de servicio mediante un intercambio de servicio de concesión de vales (TGS):
- Condiciones de control de acceso que deben cumplir el cliente (usuario, servicio, equipo) o los dispositivos desde los que procede el intercambio TGS.
Requisitos para usar directivas de autenticación
| Directiva | Requisitos |
|---|---|
| Proporcionar vigencias de TGT personalizadas | Dominios de cuentas con nivel funcional de dominio de Windows Server 2012 R2 |
| Restringir el inicio de sesión de usuarios | - Dominios de cuentas con nivel funcional de dominio de Windows Server 2012 R2 con compatibilidad para control de acceso dinámico - Dispositivos Windows 8, Windows 8.1, Windows Server 2012 o Windows Server 2012 R2 con compatibilidad con Control de acceso dinámico |
| Restringir la emisión de vales de servicio en función de cuentas de usuario o grupos de seguridad | Dominios de recursos con nivel funcional de dominio de Windows Server 2012 R2 |
| Restringir la emisión de vales de servicio en función de notificaciones de usuario o cuentas de dispositivo, grupos de seguridad o notificaciones | Dominios de recursos con nivel funcional de dominio de Windows Server 2012 R2 con compatibilidad para control de acceso dinámico |
Restringir una cuenta de usuario a dispositivos y hosts específicos
Una cuenta de gran valor con privilegios administrativos debe ser miembro del grupo Usuarios protegidos. De forma predeterminada, ninguna cuenta es miembro del grupo Usuarios protegidos. Antes de agregar cuentas al grupo, configura la compatibilidad del controlador de dominio y crea una directiva de auditoría para asegurarte de que no haya problemas de bloqueo.
Configurar la compatibilidad del controlador de dominio
El dominio de la cuenta del usuario debe estar en el nivel funcional de dominio de Windows Server 2012 R2. Asegúrese de que todos los controladores de dominio son Windows Server 2012 R2 y, a continuación, utilice dominios y confianzas de Active Directory para Elevar el nivel funcional de dominio a Windows Server 2012 R2.
Para configurar la compatibilidad para el control de acceso dinámico
En la Directiva predeterminada de controladores de dominio, haz clic en Habilitada para habilitar Compatibilidad del cliente Kerberos con notificaciones, autenticación compuesta y protección de Kerberos en Configuración del equipo | Plantillas administrativas | Sistema | KDC.
En Opciones, en el cuadro de lista desplegable, selecciona Proporcionar notificaciones siempre.
Nota
También se puede configurar Compatible, pero como el dominio está en el nivel funcional de Windows Server 2012 R2, hacer que los controladores de dominio proporcionen siempre notificaciones permitirá realizar las comprobaciones de acceso habilitado para notificaciones de usuario cuando se usen dispositivos y hosts no habilitados para notificaciones para conectar con servicios habilitados para notificaciones.
Advertencia
Configurar Producir error en solicitudes de autenticación sin protección provocará errores de autenticación en sistemas operativos que no admitan la protección de Kerberos, como Windows 7 y versiones anteriores, o los sistemas operativos a partir de Windows 8 que no hayan sido configurados explícitamente para admitirla.
Crear una auditoría de cuenta de usuario para directiva de autenticación con ADAC
Abre el Centro de administración de Active Directory (ADAC).
Nota
El nodo Autenticación seleccionado es visible para los dominios que están en el nivel funcional de dominio de Windows Server 2012 R2. Si el nodo no aparece, inténtalo de nuevo usando una cuenta de administrador de dominio de un dominio que esté en el nivel funcional de dominio de Windows Server 2012 R2.
Haz clic en Directivas de autenticacióny, después, haz clic en Nueva para crear una nueva directiva.
Las directivas de autenticación deben tener un nombre para mostrar y se aplican de forma predeterminada.
Para crear una directiva solo de auditoría, haz clic en Solo restricciones de directiva de auditoría.
Las directivas de autenticación se aplican en función del tipo de cuenta de Active Directory. Una única directiva se puede aplicar a los tres tipos de cuentas configurando las opciones de cada tipo. Los tipos de cuentas son:
Usuario
Computer
Cuenta de servicio administrada y cuenta de servicio administrada de grupo
Si has extendido el esquema con nuevas entidades de seguridad que el Centro de distribución de claves (KDC) pueda usar, el nuevo tipo de cuenta se clasifica a partir del tipo de cuenta derivado más próximo.
Para configurar una vigencia de TGT para cuentas de usuario, activa la casilla Especifique la duración de un vale de concesión de vales para las cuentas de usuario y especifica el tiempo en minutos.
Por ejemplo, si quieres una vigencia máxima de TGT de 10 horas, especifica 600 tal y como se indica. Si no hay configurada una vigencia de TGT, si la cuenta es miembro del grupo Protected Users, la vigencia y la renovación del TGT es de 4 horas. De lo contrario, la vigencia y la renovación del TGT se basan en la directiva de dominio tal y como se observa en la siguiente ventana del Editor de administración de directivas de grupo para un dominio con configuración predeterminada.
Para restringir la cuenta de usuario a los dispositivos seleccionados, haz clic en Editar para definir las condiciones necesarias para el dispositivo.
En la ventana Editar condiciones del control de acceso , haz clic en Agregar una condición.
Agregar condiciones para cuentas de equipo o grupos
Para configurar cuentas de equipo o grupos, en la lista desplegable, selecciona el cuadro de lista desplegable Miembro de cada y cámbialo a Miembro de cualquiera.
Nota
Este control de acceso define las condiciones del servicio o host desde el que el usuario inicia sesión. En la terminología del control de acceso, la cuenta de equipo para el dispositivo o host es el usuario, motivo por el que Usuario es la única opción.
Haz clic en Agregar elementos.
Para cambiar los tipos de objeto, haz clic en Tipos de objeto.
Para seleccionar objetos de equipo en Active Directory, haz clic en Equiposy, después, haz clic en Aceptar.
Escribe el nombre de los equipos para restringir el usuario y haz clic en Comprobar nombres.
Haz clic en Aceptar y crea otras condiciones para la cuenta de equipo.
Una vez hecho, haz clic en Aceptar y las condiciones definidas aparecerán para la cuenta de equipo.
Agregar condiciones de notificaciones de equipo
Para configurar notificaciones de equipo, abre la lista desplegable Grupo para seleccionar la notificación.
Las notificaciones solo están disponibles si ya se han aprovisionado en el bosque.
Escribe el nombre de la OU; la cuenta de usuario debe restringirse al inicio de sesión.
Una vez hecho, haz clic en Aceptar y el cuadro mostrará las condiciones definidas.
Solucionar problemas de notificaciones de equipo que faltan
Si la notificación se ha aprovisionado pero no está disponible, quizás solo se ha configurado para las clases Equipo.
Supongamos que quiere restringir la autenticación en función de la unidad organizativa del equipo, que ya estaba configurada, pero solo para las clases Equipo.
Para que la notificación esté disponible para restringir el inicio de usuarios en el dispositivo, activa la casilla Usuario .
Aprovisionar una cuenta de usuario con una directiva de autenticación con ADAC
En la cuenta Usuario , haz clic en Directiva.
Activa la casilla Asigne una directiva de autenticación a esta cuenta .
Después, selecciona la directiva de autenticación que se aplicará al usuario.
Configurar la compatibilidad con el control de acceso dinámico en dispositivos y hosts
Puedes configurar la vigencia de los TGT sin configurar el control de acceso dinámico (DAC). DAC solo se necesita para comprobar AllowedToAuthenticateFrom y AllowedToAuthenticateTo.
Usa el Editor de directivas de grupo o el Editor de directivas de grupo local para habilitar Compatibilidad del cliente Kerberos con notificaciones, autenticación compuesta y protección de Kerberos en Configuración del equipo | Plantillas administrativas | Sistema | Kerberos:
Solucionar problemas de directivas de autenticación
Determina las cuentas que están directamente asignadas a una directiva de autenticación
La sección de cuentas de la directiva de autenticación muestra las cuentas a las que se ha aplicado directamente la directiva.
Uso del registro administrativo Errores de directiva de autenticación: Controlador de dominio
Se ha creado un nuevo registro administrativo Errores de directiva de autenticación: Controlador de dominio en Registros de aplicaciones y servicios>Microsoft>Windows>Autenticación para que sea más fácil detectar errores debidos a las directivas de autenticación. El registro está deshabilitado de forma predeterminada. Para habilitarlo, haz clic con el botón derecho en el nombre del registro y haz clic en Habilitar registro. El contenido de los nuevos eventos es muy similar al de los eventos de auditoría de TGT y de vales de servicio de Kerberos existentes. Para obtener más información acerca de estos eventos, consulte Directivas de autenticación y silos de directivas de autenticación.
Administrar directivas de autenticación mediante Windows PowerShell
Este comando crea una directiva de autenticación llamada TestAuthenticationPolicy. El parámetro UserAllowedToAuthenticateFrom especifica los dispositivos desde los que los usuarios pueden autenticarse mediante una cadena SDDL en el archivo someFile.txt.
PS C:\> New-ADAuthenticationPolicy testAuthenticationPolicy -UserAllowedToAuthenticateFrom (Get-Acl .\someFile.txt).sddl
Este comando obtiene todas las directivas de autenticación que coinciden con el filtro especificado por el parámetro Filter.
PS C:\> Get-ADAuthenticationPolicy -Filter "Name -like 'testADAuthenticationPolicy*'" -Server Server02.Contoso.com
Este comando modifica la descripción y las propiedades de UserTGTLifetimeMins de la directiva de autenticación especificada.
PS C:\> Set-ADAuthenticationPolicy -Identity ADAuthenticationPolicy1 -Description "Description" -UserTGTLifetimeMins 45
Este comando quita la directiva de autenticación especificada por el parámetro Identity.
PS C:\> Remove-ADAuthenticationPolicy -Identity ADAuthenticationPolicy1
Este comando usa el cmdlet Get-ADAuthenticationPolicy con el parámetro Filter para obtener todas las directivas de autenticación que no se aplican. El conjunto resultante se canaliza al cmdlet Remove-ADAuthenticationPolicy.
PS C:\> Get-ADAuthenticationPolicy -Filter 'Enforce -eq $false' | Remove-ADAuthenticationPolicy
Silos de directivas de autenticación
Silos de directivas de autenticación es un nuevo contenedor (objectClass msDS-AuthNPolicySilos) de AD DS para cuentas de usuario, equipo y servicio. Ayudan a proteger las cuentas de gran valor. Aunque todas las organizaciones necesitan proteger a los miembros de los grupos Administradores de organización, Admins. del dominio y Administradores de esquema porque esas cuentas podrían ser usadas por un atacante para acceder al bosque, otras cuentas también pueden necesitar protección.
Algunas organizaciones aíslan las cargas de trabajo; para ello, crean cuentas únicas para ellas y aplican configuraciones de directiva de grupo para limitar el inicio de sesión interactivo local y remoto, y los privilegios administrativos. Los silos de directivas de autenticación complementan este trabajo y crean una manera de definir una relación entre las cuentas de usuario, de equipo y de servicio administradas. Las cuentas solo pueden pertenecer a un silo. Puedes configurar la directiva de autenticación para cada tipo de cuenta para controlar lo siguiente:
Una vigencia de TGT no renovable.
Las condiciones de control de acceso para devolver TGT. (Nota: no se puede aplicar a sistemas porque se necesita la protección de Kerberos).
Las condiciones de control de acceso para devolver vales de servicio.
Además, las cuentas de un silo de directivas de autenticación tienen una notificación de silo, que los recursos habilitados para notificaciones, como los servidores de archivos, pueden usar para controlar el acceso.
Se puede configurar un nuevo descriptor de seguridad para controlar la emisión de vales de servicio en función de lo siguiente:
Usuario, grupos de seguridad del usuario y notificaciones del usuario.
Dispositivo, grupos de seguridad del dispositivo y notificaciones del dispositivo.
Para obtener esta información para los controladores de dominio del recurso se necesita control de acceso dinámico:
Notificaciones de usuario:
Los clientes de Windows 8 y versiones posteriores admiten control de acceso dinámico.
Los dominios de cuenta admiten control de acceso dinámico y notificaciones
Dispositivo o grupo de seguridad del dispositivo:
Los clientes de Windows 8 y versiones posteriores admiten control de acceso dinámico.
Recurso configurado para autenticación compuesta
Notificaciones de dispositivo:
Los clientes de Windows 8 y versiones posteriores admiten control de acceso dinámico.
Los dominios de dispositivo admiten control de acceso dinámico y notificaciones
Recurso configurado para autenticación compuesta
Las directivas de autenticación se pueden aplicar a todos los miembros de un silo de directivas de autenticación en lugar de a cuentas individuales, o se pueden aplicar directivas de autenticación diferentes a los distintos tipos de cuentas de un silo. Por ejemplo, se puede aplicar una directiva de autenticación a cuentas de usuario con privilegios elevados, y se puede aplicar una directiva diferente a las cuentas de servicios. Se debe crear al menos una directiva de autenticación antes de poder crear un silo de directivas de autenticación.
Nota
Se puede aplicar una directiva de autenticación a los miembros de un silo de directivas de autenticación, o se puede aplicar de forma independiente de los silos para restringir el ámbito de cuenta específico. Por ejemplo, para proteger una sola cuenta o un conjunto pequeño de cuentas, se puede establecer una directiva para esas cuentas sin agregar las cuentas a un silo.
Puede crear un silo de directivas de autenticación usando el Centro de administración de Active Directory o Windows PowerShell. De forma predeterminada, un silo de directivas de autenticación solo audita directivas de silo, lo que equivale a especificar el parámetro WhatIf en los cmdlets de Windows PowerShell. En este caso, no se aplican restricciones de silo de directivas, pero se generan auditorías para indicar si se producirán errores si se aplican las restricciones.
Para crear un silo de directivas de autenticación usando el Centro de administración de Active Directory
Abre el Centro de administración de Active Directory, haz clic en Autenticación, haz clic con el botón derecho en Silos de directivas de autenticación, haz clic en Nuevoy, después, en Silo de directivas de autenticación.
En Nombre para mostrar, escribe un nombre para el silo. En Cuentas permitidas, haz clic en Agregar, escribe el nombre de las cuentas y, después, haz clic en Aceptar. Puedes especificar cuentas de usuario, de equipo o de servicio. Después, especifica si se usará una única directiva para todas las entidades de seguridad, o una directiva diferente para cada tipo de entidad de seguridad, y el nombre de la directiva o directivas.
Administrar silos de directivas de autenticación mediante Windows PowerShell
Este comando crea un objeto de silo de directivas de autenticación y lo aplica.
PS C:\>New-ADAuthenticationPolicySilo -Name newSilo -Enforce
Este comando obtiene todos los silos de directivas de autenticación que coinciden con el filtro especificado por el parámetro Filter. Después, el resultado se pasa al cmdlet Format-Table para mostrar el nombre de la directiva y el valor de Enforce en cada directiva.
PS C:\>Get-ADAuthenticationPolicySilo -Filter 'Name -like "*silo*"' | Format-Table Name, Enforce -AutoSize
Name Enforce
---- -------
silo True
silos False
Este comando usa el cmdlet Get-ADAuthenticationPolicySilo con el parámetro Filter para obtener todos los silos de directiva de autenticación que no aplican y canalizar el resultado del filtro al cmdlet Remove-ADAuthenticationPolicySilo.
PS C:\>Get-ADAuthenticationPolicySilo -Filter 'Enforce -eq $False' | Remove-ADAuthenticationPolicySilo
Este comando concede al silo de directivas de autenticación Silo el acceso a la cuenta de usuario User01.
PS C:\>Grant-ADAuthenticationPolicySiloAccess -Identity Silo -Account User01
Este comando revoca al silo de directivas de autenticación Silo el acceso a la cuenta de usuario User01. Como el parámetro Confirm está establecido en $False, no aparece ningún mensaje de confirmación.
PS C:\>Revoke-ADAuthenticationPolicySiloAccess -Identity Silo -Account User01 -Confirm:$False
Este ejemplo usa primero el cmdlet Get-ADComputer para obtener todas las cuentas de equipo que coinciden con el filtro especificado por el parámetro Filter. El resultado de este comando se pasa a Set-ADAccountAuthenticatinPolicySilo para asignarles el silo de directivas de autenticación Silo y la directiva de autenticación AuthenticationPolicy02 .
PS C:\>Get-ADComputer -Filter 'Name -like "newComputer*"' | Set-ADAccountAuthenticationPolicySilo -AuthenticationPolicySilo Silo -AuthenticationPolicy AuthenticationPolicy02