Novedades para la delegación TGT entre confianzas entrantes en Windows Server

Resumen

Las confianzas de bosque proporcionan una manera 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 del usuario. El bosque de confianza contiene el recurso en el que los usuarios se autentican. El bosque de confianza puede autenticar a los usuarios en el bosque de confianza sin permitir que ocurra lo contrario.

La delegación de Kerberos sin restricciones es un mecanismo por el que un usuario envía sus credenciales a un servicio para permitir que el servicio 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 marcarse como de confianza para la delegación. Esto crea un problema si el usuario y el servicio pertenecen a bosques diferentes. El bosque de servicio es responsable de permitir la delegación. La delegación incluye las credenciales de los usuarios del bosque del usuario.

Permitir que un bosque tome decisiones de seguridad que afecten a las cuentas de otro bosque infringe el límite de seguridad entre bosques. Un atacante propietario del bosque de confianza puede solicitar la delegación de un TGT para obtener una identidad del bosque de confianza, lo que le proporciona acceso a los recursos del bosque de confianza. Esto no se aplica a la delegación restringida de Kerberos (KCD).

Windows Server 2012 introdujo el requisito de límite 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 restricciones por confianza. La configuración predeterminada de esta característica permite la delegación sin restricciones y no es segura.

Existen novedades que proporcionan protección de 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 la protección de seguridad, se ha migrado a las siguientes versiones:

• Windows Server 2008 R2
• Windows Server 2008

Estas actualizaciones de seguridad realizan los siguientes cambios:

• La delegación de Kerberos sin restricciones está deshabilitada de forma predeterminada en los nuevos bosques y en las nuevas confianzas externas después de instalar la actualización del 14 de mayo y las posteriores.
• La delegación de Kerberos sin restricciones se deshabilita en bosques (tanto nuevos como existentes) y confianzas externas después de instalar la actualización del 9 de julio de 2019 y las actualizaciones posteriores.
• Los administradores pueden habilitar la delegación de Kerberos sin restricciones mediante el módulo de PowerShell de mayo o versiones posteriores de NETDOM y AD.

Las actualizaciones pueden provocar conflictos de compatibilidad para las aplicaciones que actualmente requieren la delegación sin restricciones entre bosques o confianzas externas. Esto es especialmente cierto en el caso de las confianzas externas, para las que la marca de cuarentena (también conocida como filtrado SID) está habilitada de forma predeterminada. Específicamente, al solicitar nuevos vales, se producirá un error en las solicitudes de autenticación para los servicios que usan la delegación sin restricciones sobre los tipos de confianza enumerados.

Para conocer las fechas de lanzamiento, consulte la escala de tiempo de Novedades.

Solución alternativa

Para proporcionar seguridad de datos y de cuentas en una versión de Windows Server que tenga la característica Cumplimiento de límite de bosque para delegación completa de Kerberos, puede bloquear la delegación TGT después de instalar las actualizaciones de marzo de 2019 a través de una confianza entrante estableciendo la marca de netdom EnableTGTDelegation en No, como se indica a continuación:

netdom.exe trust fabrikam.com /domain:contoso.com /EnableTGTDelegation:No

La delegación TGT se bloquea en bosques y confianzas externas nuevas y existentes después de instalar las actualizaciones de mayo y julio de 2019, respectivamente.

Para volver a habilitar la delegación entre confianzas y volver a la configuración no segura original hasta que se pueda habilitar la delegación restringida o basada en recursos, establezca la marca EnableTGTDelegation en Sí.

La línea de comandos de NETDOM para habilitar la delegación TGT es la siguiente:

netdom trust <TrustedDomainName > /domain:<TrustingDomainName > /EnableTgtDelegation:Yes

Puede pensar conceptualmente en la sintaxis de NETDOM para habilitar la delegación TGT de la siguiente manera:

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 TGT de fabrakam.com usuarios en contoso.com servidores es la siguiente:

netdom.exe trust fabrikam.com /domain:contoso.com /EnableTGTDelegation:Yes

         Notas

• La marca EnableTGTDelegation debe establecerse en el dominio de confianza (fabrikam.com en este caso) para cada dominio de confianza (como contoso.com). Una vez establecida la marca, el dominio de confianza ya no permitirá que los TGT se deleguen al dominio de confianza.
• El estado seguro de EnableTGTDelegation es No.
• Se producirá un error en cualquier aplicación o servicio que se base en la delegación sin restricciones entre bosques cuando EnableTGTDelegation se establezca manual o mediante programación en Sí. EnableTGTDelegation tiene como valor predeterminado NO 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, vea Buscar servicios que se basen en la delegación sin restricciones. Vea la escala de tiempo de Novedades para ver una escala de tiempo de los cambios que afectan a la forma en que se puede aplicar esta solución alternativa.
• Para obtener más información acerca de NETDOM, consulte la documentaciónNetdom.exe.
• Si debe habilitar la delegación TGT en una confianza, se recomienda mitigar ese riesgo habilitando Credential Guard de Windows Defender en equipos cliente. Esto impide toda delegación sin restricciones de un equipo que tenga Credential Guard de Windows Defender habilitado y en ejecución.
• Si tiene un bosque o una confianza externa y están configurados como en cuarentena, no se puede habilitar la delegación TGT porque las dos marcas tienen una semántica opuesta. La parte de cuarentena refuerza el límite de seguridad entre los dominios participantes. Al habilitar la delegación TGT, se borran los límites de seguridad entre dominios, ya que se concede al dominio de confianza 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 línea de comandos NETDOM si la marca de cuarentena está habilitada actualmente.
• Si cambió EnableTGTDelegation a Sí, elimine los vales de Kerberos en los autores de llamadas de origen e intermedios según sea necesario. El ticket relevante a eliminar es el TGT de referencia del cliente a través de la confianza relevante. Esto podría implicar a más de un dispositivo, en función del número de saltos de delegación en un entorno determinado.

Para obtener más información acerca de este procedimiento, consulta 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 novedades

12 de marzo de 2019

El cumplimiento del límite de bosque para la delegación completa de Kerberos estará disponible como actualización para habilitar esta característica en todas las versiones compatibles de Windows Server que se enumeran en la sección "Se aplica a" en la parte superior de este artículo. Se recomienda establecer la característica en confianzas de bosque entrantes.

La actualización agregará la característica Cumplimiento del límite de bosque para la delegación completa de Kerberos a los siguientes sistemas:

• Windows Server 2008 R2
• Windows Server 2008

14 de mayo de 2019

Se ha publicado una actualización que agrega una nueva configuración predeterminada segura para los nuevos bosques y confianzas externas. Si necesita delegación entre confianzas, la marca EnableTGTDelegation debe establecerse en Sí antes de instalar la actualización del 9 de julio de 2019. Si no necesita delegación entre confianzas, no debe establecer la marca EnableTGTDelegation . La marca EnableTGTDelegation se omitirá hasta que se instale la actualización del 9 de julio de 2019 para dar tiempo a los administradores de volver a habilitar la delegación Kerberos sin restricciones cuando sea necesario.

Como parte de esta actualización, la marca EnableTGTDelegation se establecerá en No de forma predeterminada para las confianzas recién creadas. Esto es lo opuesto al comportamiento anterior. En su lugar, recomendamos que los administradores vuelvan a configurar los servicios afectados para que usen la deleción con restricciones basada en recursos.

Para obtener más información sobre cómo detectar problemas de compatibilidad, vea Buscar servicios que se basen 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 de entrada del bosque y confianzas externas. Las solicitudes de autenticación para los servicios que usan la delegación sin restricciones sobre los tipos de confianza enumerados se autenticarán, pero sin delegación. Se producirá un error en el servicio al intentar ejecutar operaciones delegadas.

Para mitigarla, consulte la sección "Solución alternativa".

Buscar servicios que se basen en la delegación sin restricciones

Para buscar bosques que tengan confianzas entrantes que permitan la delegación de TGT y para buscar entidades de seguridad que permitan la delegación sin restricciones, ejecute los siguientes scripts de PowerShell en un archivo de script (por ejemplo, Get-RiskyServiceAccountsByTrust.ps1 -Collect):

[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 enumera las entidades de seguridad de Active Directory en dominios configurados para una confianza entrante del dominio ejecutor que tiene configurada la delegación sin restricciones. El resultado será similar al del ejemplo siguiente.

Detección de la delegación sin restricciones a través de eventos de Windows

Cuando se emite un vale Kerberos, un controlador de dominio de Active Directory registra los siguientes eventos de seguridad. Los eventos contienen información sobre el dominio de destino. Puede utilizar los eventos para determinar si se está usando la delegación sin restricciones entre confianzas entrantes.

Solución de fallas de autenticación

Cuando la delegación sin restricciones está deshabilitada, las aplicaciones pueden tener problemas de compatibilidad con estos cambios si se basan en la delegación sin restricciones. Estas aplicaciones deben configurarse para usar la delegación restringida o la delegación restringida basada en recursos. Para obtener más información, vea Introducción a la delegación restringida de Kerberos.

Las aplicaciones que se basan en la autenticación de ida y vuelta entre confianzas no se admiten mediante la delegación restringida. Por ejemplo, se produce un error en una delegación si un usuario del bosque A se autentica en una aplicación del bosque B y la aplicación del bosque B está intentando delegar un vale de nuevo al bosque A.