Atualizações para a delegação de TGT entre relações de confiança de entrada no Windows Server

Resumo

As relações de confiança de floresta fornecem uma maneira para os recursos em uma floresta do Active Directory confiarem em identidades de outra floresta. Essa relação de confiança pode ser configurada em ambas as direções. A floresta confiável é a fonte de identidade do usuário. A floresta confiante contém o recurso para o qual os usuários se autenticam. A floresta confiável pode autenticar usuários na floresta confiável sem permitir que o inverso ocorra.

A delegação irrestrita do Kerberos é um mecanismo no qual um usuário envia suas credenciais para um serviço para permitir que o serviço acesse recursos em nome do usuário. Para habilitar a delegação irrestrita do Kerberos, a conta do serviço no Active Directory deve ser marcada como confiável para delegação. Isso cria um problema se o usuário e o serviço pertencerem a florestas diferentes. A floresta de serviço é responsável por permitir a delegação. A delegação inclui as credenciais dos usuários da floresta do usuário.

Permitir que uma floresta tome decisões de segurança que afetem as contas de outra floresta viola o limite de segurança entre as florestas. Um invasor que possui a floresta confiável pode solicitar a delegação de um TGT para uma identidade da floresta confiável, dando-lhe acesso a recursos na floresta confiável. Isso não se aplica à delegação restrita de Kerberos (KCD).

O Windows Server 2012 introduziu a Imposição do Limite de Floresta para Delegação Completa do Kerberos. Esse recurso adicionou uma política ao domínio confiável para desabilitar a delegação irrestrita por confiança. A configuração padrão desse recurso permite a delegação irrestrita e não é segura.

Atualizações que fornecem proteção de segurança existem para as seguintes versões do Windows Server:

• Windows Server 2019
• Windows Server 2016
• Windows Server 2012 R2
• Windows Server 2012

Esse recurso, juntamente com as alterações na proteção de segurança, foram reportados para as seguintes versões:

• Windows Server 2008 R2
• Windows Server 2008

Essas atualizações de segurança fazem as seguintes alterações:

• A delegação irrestrita do Kerberos é desabilitada por padrão na nova floresta e em novas relações de confiança externas depois que você instala a atualização de 14 de maio e atualizações posteriores.
• A delegação irrestrita do Kerberos é desabilitada em florestas (novas e existentes) e relações de confiança externas depois que você instala a atualização de 9 de julho de 2019 e posteriores.
• Os administradores podem habilitar a delegação irrestrita do Kerberos usando as versões de maio ou posteriores do módulo NETDOM e AD do PowerShell.

As atualizações podem causar conflitos de compatibilidade para aplicativos que atualmente exigem delegação irrestrita entre florestas ou relações de confiança externas. Isso é especialmente verdadeiro para a relação de confiança externa para a qual o sinalizador de quarentena (também conhecido como filtragem SID) está habilitado por padrão. Especificamente, as solicitações de autenticação para serviços que usam delegação irrestrita sobre os tipos de confiança listados falharão quando você solicitar novos tíquetes.

Para obter as datas de lançamento, consulte Atualizações linha do tempo.

Solução alternativa

Para fornecer segurança de dados e conta em uma versão do Windows Server que tem o recurso Imposição de Limite de Floresta para Delegação Total do Kerberos, você pode bloquear a delegação TGT depois de instalar as atualizações de março de 2019 em uma relação de confiança de entrada definindo o sinalizador netdom EnableTGTDelegation como Não, da seguinte maneira:

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

A delegação TGT é bloqueada em florestas novas e existentes e relações de confiança externas depois que você instala as atualizações de maio e julho de 2019, respectivamente.

Para reabilitar a delegação entre relações de confiança e retornar à configuração não segura original até que a delegação restrita ou baseada em recursos possa ser habilitada, defina o sinalizador EnableTGTDelegation como Sim.

A linha de comando NETDOM para habilitar a delegação TGT é a seguinte:

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

Conceitualmente, você pode pensar na sintaxe NETDOM para habilitar a delegação TGT da seguinte maneira:

netdom trust <domain that you are administering> /domain:<domain whose trust NETDOM is modifying> /EnableTgtDelegation:Yes

A sintaxe NETDOM para permitir a delegação TGT de usuários fabrakam.com em servidores contoso.com é a seguinte:

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

         Observações

• O sinalizador EnableTGTDelegation deve ser definido no domínio confiável (fabrikam.com nesse caso) para cada domínio confiável (como contoso.com). Depois que o sinalizador for definido, o domínio confiável não permitirá mais que TGTs sejam delegados ao domínio confiável.
• O estado seguro para EnableTGTDelegation é Não.
• Qualquer aplicativo ou serviço que dependa de delegação irrestrita entre florestas falhará quando EnableTGTDelegation for definido manual ou programaticamente como Sim. EnableTGTDelegation assume como padrão NO em relações de confiança novas e existentes depois de instalar as atualizações de maio de 2019 e julho de 2019. Para obter mais informações sobre como detectar essa falha, consulte Localizando serviços que dependem de delegação irrestrita. Consulte Atualizações linha do tempo para obter uma linha do tempo de alterações que afetam como essa solução alternativa pode ser aplicada.
• Para obter mais informações sobre o NETDOM, consulte a documentaçãoNetdom.exe.
• Se você precisar habilitar a delegação TGT em uma confiança, é recomendável reduzir esse risco habilitando o Windows Defender Credential Guard em computadores cliente. Isso impede toda a delegação irrestrita de um computador que tenha o Windows Defender Credential Guard habilitado e em execução.
• Se você tiver uma floresta ou confiança externa e qualquer uma delas estiver configurada como em quarentena, a delegação TGT não poderá ser habilitada porque os dois sinalizadores têm semântica oposta. O bit de quarentena fortalece o limite de segurança entre os domínios participantes. Habilitar a delegação TGT apaga os limites de segurança entre domínios, dando ao domínio confiável acesso às credenciais dos usuários do domínio confiável. Você não pode ter as duas coisas.
  Adicione o sinalizador quarantine:no à sintaxe da linha de comando NETDOM se o sinalizador de quarentena estiver habilitado no momento.
• Se você alterou EnableTGTDelegation para Sim, exclua os tíquetes Kerberos nos chamadores de origem e intermediários, conforme necessário. O tíquete relevante a ser excluído é o TGT de referência do cliente na relação de confiança relevante. Isso pode envolver mais de um dispositivo, dependendo do número de saltos de delegação em um determinado ambiente.

Para obter mais informações sobre esse procedimento, consulte o seguinte artigo do Windows IT Pro Center:

Proteger as credenciais de domínio derivadas com o Windows Defender Credential Guard

Atualizações linha do tempo

12 de março de 2019

A imposição do limite de floresta para delegação total do Kerberos estará disponível como uma atualização para habilitar esse recurso em todas as versões compatíveis do Windows Server listadas na seção Aplica-se a na parte superior deste artigo. Recomendamos que você defina o recurso em relações de confiança de floresta de entrada.

A atualização adicionará o recurso Imposição do Limite da Floresta para Delegação Total do Kerberos aos seguintes sistemas:

• Windows Server 2008 R2
• Windows Server 2008

14 de maio de 2019

Foi lançada uma atualização que adiciona uma nova configuração padrão segura a uma nova floresta e relações de confiança externas. Se você exigir delegação entre relações de confiança, o sinalizador EnableTGTDelegation deverá ser definido como Sim antes da instalação da atualização de 9 de julho de 2019. Se você não exigir delegação entre relações de confiança, não deverá definir o sinalizador EnableTGTDelegation . O sinalizador EnableTGTDelegation será ignorado até que a atualização de 9 de julho de 2019 seja instalada para dar aos administradores tempo para reabilitar a delegação irrestrita do Kerberos quando necessário.

Como parte desta atualização, o sinalizador EnableTGTDelegation será definido como Não por padrão para todas as relações de confiança recém-criadas. Isso é o oposto do comportamento anterior. Recomendamos que os administradores reconfigurem os serviços afetados para usar a delegação restrita baseada em recursos.

Para obter mais informações sobre como detectar problemas de compatibilidade, consulte Localizando serviços que dependem de delegação irrestrita.

9 de julho de 2019

Foi lançada uma atualização que impõe o novo comportamento padrão no lado de entrada da floresta e relações de confiança externas. As solicitações de autenticação para serviços que usam delegação irrestrita sobre os tipos de confiança listados serão autenticadas, mas sem delegação. O serviço falhará ao tentar executar operações delegadas.

Para mitigação, consulte a seção "Solução alternativa".

Encontrar serviços que dependem de delegação irrestrita

Para verificar se há florestas que têm relações de confiança de entrada que permitem a delegação TGT e para localizar entidades de segurança que permitem a delegação irrestrita, execute os seguintes scripts do PowerShell em um arquivo de script (por exemplo, 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 
}

A saída dos scripts do PowerShell lista as entidades de segurança do Active Directory em domínios configurados para uma relação de confiança de entrada do domínio em execução que tem delegação irrestrita configurada. A saída será semelhante ao exemplo a seguir.

Detecção de delegação irrestrita por meio de eventos do Windows

Quando um tíquete Kerberos é emitido, um controlador de domínio do Active Directory registra os eventos de segurança a seguir. Os eventos contêm informações sobre o domínio de destino. Você pode usar os eventos para determinar se a delegação irrestrita está sendo usada entre relações de confiança de entrada.

Solução de problemas de falhas de autenticação

Quando a delegação irrestrita está desabilitada, os aplicativos poderão ter problemas de compatibilidade com essas alterações se os aplicativos dependerem da delegação irrestrita. Esses aplicativos devem ser configurados para usar delegação restrita ou delegação restrita baseada em recursos. Para obter mais informações, consulte Visão geral da delegação restrita de Kerberos.

Aplicativos que dependem da autenticação de ida e volta entre relações de confiança não têm suporte usando delegação restrita. Por exemplo, uma delegação falhará se um usuário na Floresta A se autenticar em um aplicativo na Floresta B e o aplicativo na Floresta B estiver tentando delegar um tíquete de volta à Floresta A.