Resumen
Las confianzas de bosque proporcionan una forma para que los recursos de un bosque de Active Directory confíen en identidades de otro bosque. Esta confianza se puede configurar en ambas direcciones. El bosque de confianza es el origen de la identidad de usuario. El bosque que confía contiene el recurso en el que se autentican los usuarios. El bosque de confianza puede autenticar usuarios para el bosque que confía sin permitir que ocurra lo mismo en dirección contraria.
La delegación de Kerberos sin restricciones es un mecanismo en el que un usuario envía sus credenciales a un servicio para permitir que este último acceda a los recursos en nombre del usuario. Para habilitar la delegación de Kerberos sin restricciones, la cuenta del servicio en Active Directory debe estar marcado como de confianza para la delegación. Esto genera un problema si el usuario y servicio pertenecen a bosques distintos. El bosque del servicio es el responsable de permitir la delegación. La delegación incluye las credenciales de los usuarios del bosque de estos.
Permitir que un bosque tome decisiones sobre seguridad que afecta a las cuentas de otro bosque infringe el límite de seguridad entre bosques. Un atacante que posee el bosque que confía puede solicitar la delegación de un TGT para una identidad del bosque de confianza, dándole acceso a los recursos de este último. Esto no se aplica a la delegación de Kerberos con restricciones (KCD).
Windows Server 2012 introdujo la aplicación de límites de bosque para la delegación completa de Kerberos. Esta característica agregó una directiva al dominio de confianza para deshabilitar la delegación sin límites según la confianza. La configuración predeterminada de esta característica permite la delegación sin límites y no es segura.
Existen actualizaciones que proporcionan mayor seguridad para las siguientes versiones de Windows Server:
-
Windows Server 2019
-
Windows Server 2016
-
Windows Server 2012 R2
-
Windows Server 2012
Esta característica, junto con los cambios en el aumento de la seguridad se aplicaron a las siguientes versiones:
-
Windows Server 2008 R2
-
Windows Server 2008
Estas actualizaciones de seguridad hacen los siguientes cambios:
-
Después de instalar la actualización del 14 de mayo y actualizaciones posteriores, la delegación Kerberos sin restricciones se deshabilita de manera predeterminada en nuevos bosques y nuevas confianzas externas.
-
Después de instalar la actualización del 9 de julio de 2019 y actualizaciones posteriores, la delegación Kerberos sin restricciones se deshabilita de manera en bosques (tantos nuevos como existentes) y nuevas confianzas externas.
-
Los administradores pueden habilitar la delegación de Kerberos sin restricciones al usar las versiones de mayo o posteriores de NETDOM y el módulo PowerShell de AD.
Las actualizaciones pueden provocar problemas de compatibilidad con las aplicaciones que requieren la delegación sin restricciones entre bosques o confianzas externas. Esto se aplica especialmente en el caso de una confianza externa para la que la marca de cuarentena (también conocido como filtrado SID) está habilitado de manera predeterminada. Específicamente, se producirá un error en las solicitudes de autenticación para los servicios que usan la delegación sin restricciones por encima de los tipos de confianza enumerados.
Para consultar las fechas de lanzamiento, consulte Escala de tiempo de actualizaciones.
Solución alternativa
Para proporcionar seguridad de datos y cuentas en una versión de Windows Server con la característica de aplicación del límite de bosque para la delegación completa de Kerberos, puede bloquear la delegación TGT después de instalar las actualizaciones de marzo de 2019 en una confianza entrante. Para ello, establezca la marca de netdom EnableTGTDelegation en No, tal como se indica a continuación:
netdom.exe trust fabrikam.com /domain:contoso.com /EnableTGTDelegation:No
La delegación de TGT se bloquea en bosques nuevos y existentes después de instalar las actualizaciones de mayo y julio de 2019, respectivamente.
Para volver a habilitar la delegación entre todas las confianzas y volver a la configuración original insegura hasta que se pueda habilitar la delegación restringida o basada en recursos, establezca la marca EnableTGTDelegation en Sí.
La línea de comando de NETDOM para habilitar la delegación de TGT es la siguiente:
netdom trust <TrustedDomainName > /domain:<TrustingDomainName > /EnableTgtDelegation:Yes
Puede pensar de manera conceptual en la sintaxis de NETDOM para habilitar la delegación de TGT del siguiente modo:
netdom trust <domain that you are administering> /domain:<domain whose trust NETDOM is modifying> /EnableTgtDelegation:Yes
La sintaxis de NETDOM para habilitar la delegación de TGT de usuarios de fabrakam.com en servidores de contoso.com sería la siguiente:
netdom.exe trust fabrikam.com /domain:contoso.com /EnableTGTDelegation:Yes
Notas
-
La marca EnableTGTDelegation se debe establecer en el dominio de confianza (en este caso, fabrikam.com) para cada dominio que confía (por ejemplo, contoso.com). Después de establecer la marca, el dominio de confianza no permitirá delegar los TGT al domino que confía.
-
El estado seguro de EnableTGTDelegation es No.
-
Cuando EnableTGTDelegation se establece manualmente o mediante programación en Sí, se produce un error en las aplicaciones o servicios que dependen de la delegación sin restricciones entre bosques. El valor predeterminado de EnableTGTDelegation es No en las confianzas nuevas y existentes después de instalar las actualizaciones de mayo y julio de 2019. Para obtener más información sobre cómo detectar este error, consulte Búsqueda de servicios que confían en la delegación sin restricciones. Consulte Escala de tiempo de actualizaciones para obtener una escala de tiempo de los cambios que afectan a cómo se puede aplicar esta solución alternativa.
-
Para obtener más información sobre NETDOM, consulte la documentación de Netdom.exe.
-
Si tiene que habilitar la delegación de TGT en una confianza, es recomendable mitigar el riesgo al habilitar Credential Guard de Windows Defender en todos los equipos cliente. De este modo se impide toda delegación sin restricciones de un equipo que tenga la función Credential Guard de Windows Defender habilitada y en ejecución.
-
Si tiene un bosque o confianza externa y cualquiera de ellos está configurado como en cuarentena, la delegación de TGT no se puede habilitar porque las dos marcas tienen semánticas opuestas. La parte en cuarentena fortalece el límite de seguridad entre dominios participantes. Si se habilita la delegación de TGT, se borran los límites de seguridad entre los dominios al dar al dominio que confía acceso a las credenciales de los usuarios del dominio de confianza. No se puede tener las dos cosas.
Agregue la marca quarantine:no a la sintaxis de la línea de comandos de NETDOM si la marca de quarantine está habilitada.
-
Si cambió EnableTGTDelegation a Sí, elimine los vales de Kerberos en las llamadas de origen e intermediarias, según sea necesario. El vale pertinente que se debe eliminar es el TGT de referencia del cliente entre todas las confianzas pertinentes. Esto podría implicar más de un dispositivos, en función del número de saltos de delegación de un entorno dado.
Para obtener más información sobre este procedimiento, consulte el siguiente artículo de Windows IT Pro Center:
Proteger las credenciales de dominio derivadas con Credential Guard de Windows Defender
Escala de tiempo de actualizaciones
martes, 12 de marzo de 2019
La aplicación de límite de bosque para la delegación completa de Kerberos estará disponible como actualización para habilitar esta función en todas las versiones compatibles de Windows Server que se listan en la sección Se aplica a del principio de este artículo. Se recomienda establecer la función en confianzas de bosque entrantes.
La actualización agregará la característica aplicación de límites del bosque para la delegación completa de Kerberos en los siguientes sistemas:
-
Windows Server 2008 R2
-
Windows Server 2008
14 de mayo de 2019
Se publicó una actualización que agrega una nueva configuración predeterminada segura a nuevos bosques y confianzas externas. Si requiere delegación entre confianzas, la marca EnableTGTDelegation se debe establecer en Sí antes de instalar la actualización del 9 de julio de 2019. Si no requiere la delegación entre confianzas, no debe establecer la marca EnableTGTDelegation. Se hará caso omiso de la marca EnableTGTDelegation hasta que la actualización del 9 de julio de 2019 se instale, de modo que los administradores tengan tiempo para volver a habilitar la delegación de Kerberos sin restricciones que se necesite.
Como parte de esta actualización, la marca EnableTGTDelegation se establecerá en No de manera predeterminada para cualquier confianza recién creada. Este es un comportamiento opuesto al anterior. Recomendamos que, en su lugar, los administradores reconfiguren los servicios afectados para que usen la delegación con restricciones basada en recursos.
Para obtener más información sobre cómo detectar problemas de compatibilidad, consulte Búsqueda de servicios que confían en la delegación sin restricciones.
9 de julio de 2019
Se publicó una actualización que aplica el nuevo comportamiento predeterminado en el lado entrante de un bosque o confianza externa. Las solicitudes de autenticación para los servicios que usan la delegación sin restricciones por encima de los tipos de confianza enumerados se autenticarán, pero sin delegación. Se producirá un error en el servicio cuando intente ejecutar operaciones delegadas.
Para conocer la mitigación, consulte la sección "Solución alternativa".
Búsqueda de servicios que confían en la delegación sin restricciones
Para detectar bosques que tienen confianzas entrantes que permiten la delegación de TGT y para buscar entidades de seguridad que permiten la delegación sin restricciones, ejecute los siguientes scripts de PowerShell en un archivo de script (por ejemplo, Get-RiskyServiceAccountsByTrust.ps1 -Collect):
Nota
También se puede pasar la marca -ScanAll para buscar en todas las confianzas que no permiten la delegación de TGT.
[CmdletBinding()]
Param
(
[switch]$Collect,
[switch]$ScanAll
)
if ($Debug) {
$DebugPreference = 'Continue'
}
else {
$DebugPreference = 'SilentlyContinue'
}
function Get-AdTrustsAtRisk
{
[CmdletBinding()]
Param
(
[string]$Direction = "Inbound",
[switch]$ScanAll
)
if ($ScanAll) {
return get-adtrust -filter {Direction -eq $Direction}
}
else {
return get-adtrust -filter {Direction -eq $Direction -and TGTDelegation -eq $false}
}
}
function Get-ServiceAccountsAtRisk
{
[CmdletBinding()]
Param
(
[string]$DN = (Get-ADDomain).DistinguishedName,
[string]$Server = (Get-ADDomain).Name
)
Write-Debug "Searching $DN via $Server"
$SERVER_TRUST_ACCOUNT = 0x2000
$TRUSTED_FOR_DELEGATION = 0x80000
$TRUSTED_TO_AUTH_FOR_DELEGATION= 0x1000000
$PARTIAL_SECRETS_ACCOUNT = 0x4000000
$bitmask = $TRUSTED_FOR_DELEGATION -bor $TRUSTED_TO_AUTH_FOR_DELEGATION -bor $PARTIAL_SECRETS_ACCOUNT
$filter = @"
(&
(servicePrincipalname=*)
(|
(msDS-AllowedToActOnBehalfOfOtherIdentity=*)
(msDS-AllowedToDelegateTo=*)
(UserAccountControl:1.2.840.113556.1.4.804:=$bitmask)
)
(|
(objectcategory=computer)
(objectcategory=person)
(objectcategory=msDS-GroupManagedServiceAccount)
(objectcategory=msDS-ManagedServiceAccount)
)
)
"@ -replace "[\s\n]", ''
$propertylist = @(
"servicePrincipalname",
"useraccountcontrol",
"samaccountname",
"msDS-AllowedToDelegateTo",
"msDS-AllowedToActOnBehalfOfOtherIdentity"
)
$riskyAccounts = @()
try {
$accounts = Get-ADObject -LDAPFilter $filter -SearchBase $DN -SearchScope Subtree -Properties $propertylist -Server $Server
}
catch {
Write-Warning "Failed to query $Server. Consider investigating seperately. $($_.Exception.Message)"
}
foreach ($account in $accounts) {
$isDC = ($account.useraccountcontrol -band $SERVER_TRUST_ACCOUNT) -ne 0
$fullDelegation = ($account.useraccountcontrol -band $TRUSTED_FOR_DELEGATION) -ne 0
$constrainedDelegation = ($account.'msDS-AllowedToDelegateTo').count -gt 0
$isRODC = ($account.useraccountcontrol -band $PARTIAL_SECRETS_ACCOUNT) -ne 0
$resourceDelegation = $account.'msDS-AllowedToActOnBehalfOfOtherIdentity' -ne $null
$acct = [PSCustomobject] @{
domain = $Server
sAMAccountName = $account.samaccountname
objectClass = $account.objectclass
isDC = $isDC
isRODC = $isRODC
fullDelegation = $fullDelegation
constrainedDelegation = $constrainedDelegation
resourceDelegation = $resourceDelegation
}
if ($fullDelegation) {
$riskyAccounts += $acct
}
}
return $riskyAccounts
}
function Get-RiskyServiceAccountsByTrust
{
[CmdletBinding()]
Param
(
[switch]$ScanAll
)
$riskyAccounts = @()
$trustTypes = $("Inbound", "Bidirectional")
foreach ($type in $trustTypes) {
$riskyTrusts = Get-AdTrustsAtRisk -Direction $type -ScanAll:$ScanAll
foreach ($trust in $riskyTrusts) {
$domain = $null
try {
$domain = Get-AdDomain $trust.Name -ErrorVariable eatError -ErrorAction Ignore
} catch {
write-debug $_.Exception.Message
}
if($eatError -ne $null) {
Write-Warning "Couldn't find domain: $($trust.Name)"
}
if ($domain -ne $null) {
$accts = Get-ServiceAccountsAtRisk -DN $domain.DistinguishedName -Server $domain.DNSRoot
foreach ($acct in $accts) {
Write-Debug "Risky: $($acct.sAMAccountName) in $($acct.domain)"
}
$risky = [PSCustomobject] @{
Domain = $trust.Name
Accounts = $accts
}
$riskyAccounts += $risky
}
}
}
return $riskyAccounts
}
if ($Collect) {
Get-RiskyServiceAccountsByTrust -ScanAll:$ScanAll | Select-Object -expandProperty Accounts | format-table
}
La salida de los scripts de PowerShell lista las entidades de seguridad de Active Directory en dominios configurados para una confianza entrante desde el dominio de ejecución que tiene configurada la delegación sin restricciones. El resultado será similar al siguiente ejemplo.
|
domain |
sAMAccountName |
objectClass |
|
partner.fabrikam.com |
dangerous |
user |
|
partner.fabrikam.com |
labsrv$ |
computer |
Detección de delegación sin restricciones a través de eventos de Windows
Cuando se emite un vale de Kerberos, un controlador de dominio de Active Directory registra los siguientes eventos de seguridad. Los eventos contienen información acerca del dominio de destino. Se pueden utilizar los eventos para determinar si la delegación sin restricciones se usa a través de confianzas entrantes.
Nota
Compruebe los eventos que contienen un valor TargetDomainName que coincide con el nombre de dominio de confianza.
|
Registro de eventos |
Origen del evento |
Id. del evento |
Detalles |
|
Seguridad |
Microsoft-Windows-Security-Auditing |
4768 |
Se emitió un TGT de Kerberos. |
|
Seguridad |
Microsoft-Windows-Security-Auditing |
4769 |
Se emitió un vale de servicio de Kerberos. |
|
Seguridad |
Microsoft-Windows-Security-Auditing |
4770 |
Se renovó un vale de servicio de Kerberos. |
Solución de problemas de errores de autenticación
Cuando se deshabilita la delegación sin restricciones, las aplicaciones pueden tener problemas de compatibilidad con estos cambios si dependen de la delegación sin restricciones. Estas aplicaciones deben configurarse para usar la delegación restringida o la delegación restringida basada en recurso. Para más información, consulte Información general sobre la delegación restringida de Kerberos.
Las aplicaciones que confían en la autenticación de ida y vuelta a través de confianzas no son compatibles con el uso de la delegación restringida. Por ejemplo, una delegación genera un error si un usuario del bosque A se autentica en una aplicación del bosque B y la aplicación del bosque B intenta delegar un vale de vuelta al bosque A.
