Atualizações à delegação da TGT em trusts de entrada no Windows Server

Resumo

As fidedignidades de floresta proporcionam uma forma de os recursos de um floresta do Active Directory confiarem em identidades de outra floresta. Esta confiança pode ser configurada em ambas as direções. A floresta confiável é a origem da identidade do usuário. A floresta confiável contém o recurso no 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 Kerberos sem restrições é 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 Kerberos sem restrições, a conta do serviço no Active Directory deve ser marcada como confiável para delegação. Isto cria um problema se o utilizador 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 florestas. Um invasor proprietário da 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. Isto não se aplica à delegação restrita de Kerberos (KCD).

Windows Server 2012 introduziu a Imposição do Limite Florestal para a Delegação Completa de Kerberos. Esta funcionalidade adicionou uma política ao domínio fidedigno para desativar a delegação sem restrições numa base por confiança. A predefinição desta funcionalidade permite uma delegação sem restrições e não é segura.

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

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

Esta funcionalidade, juntamente com as alterações na proteção de segurança, foram retroportadas para as seguintes versões:

• Windows Server 2008 R2
• Windows Server 2008

Estas atualizações de segurança efetuam as seguintes alterações:

• A delegação Kerberos sem restrições está desativada por predefinição na nova floresta e nas novas relações de confiança externas após a instalação da atualização de 14 de maio e atualizações posteriores.
• A delegação Kerberos sem restrições é desativada em florestas (novas e existentes) e relações de confiança externas após a instalação da atualização de 9 de julho de 2019 e atualizações posteriores.
• Os administradores podem habilitar a delegação Kerberos sem restrições usando as versões de maio ou posteriores do módulo NETDOM e AD PowerShell.

As atualizações podem causar conflitos de compatibilidade para aplicativos que atualmente exigem delegação sem restrições entre florestas ou relações de confiança externas. Isto aplica-se especialmente à confiança externa para a qual o sinalizador de quarentena (também conhecido como filtragem SID) está ativado por predefinição. Mais concretamente, quando pedir novas permissões, os pedidos de autenticação para serviços que utilizam delegação sem restrições sobre os tipos de fidedignidade listados irão falhar.

Para conhecer as datas de lançamento, consulte Atualizações linha cronológica.

Solução

Para fornecer segurança de dados e conta em uma versão Windows Server que tenha o recurso Imposição de Limite de Floresta para Delegação Total 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 de netdom EnableTGTDelegation como Não, da seguinte maneira:

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

A delegação TGT é bloqueada em confianças florestais e externas novas e existentes após a instalação das atualizações de maio e julho de 2019, respetivamente.

Para reativar a delegação entre confianças e retornar à configuração insegura 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

Você pode conceitualmente 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 habilitar 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

         Notas

• O sinalizador EnableTGTDelegation deve ser definido no domínio confiável (fabrikam.com neste 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 sem restrições entre florestas falhará quando EnableTGTDelegation estiver definido manual ou programaticamente como Sim. EnableTGTDelegation tem como predefinição NO em confianças 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 sem restrições. Consulte Atualizações linha cronológica das alterações que afetam a forma como esta solução pode ser aplicada.
• Para obter mais informações sobre o NETDOM, consulte a documentaçãoNetdom.exe.
• Se tiver de ativar a delegação TGT numa relação de confiança, recomenda-se que mitigue esse risco ativando o Windows Defender Credential Guard em computadores cliente. Isto impede toda a delegação sem restrições de um computador que tenha o Windows Defender Credential Guard ativado e em execução.
• Se você tiver uma floresta ou confiança externa, e ambos estiverem configurados 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 a fronteira 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 tê-lo nos dois sentidos.
  Adicione o sinalizador quarantine:no à sintaxe da linha de comandos NETDOM se o sinalizador de quarentena estiver atualmente ativado.
• Se você alterou EnableTGTDelegation para Sim, exclua tíquetes Kerberos em chamadores de origem e intermediários, conforme necessário. O bilhete relevante a ser excluído é a referência do TGT do cliente em todo o trust 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 este procedimento, consulte o seguinte artigo do Windows IT Pro Center:

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

Atualizações linha cronológica

12 de março de 2019

A imposição para limite de floresta para delegação total Kerberos estará disponível como uma atualização para habilitar esse recurso em todas as versões suportadas do Windows Server listadas na seção Aplica-se a no topo deste artigo. Recomendamos que defina a funcionalidade nas confianças de floresta recebidas.

A atualização adicionará o recurso Imposição para Limite de Floresta para Delegação Total de 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 predefinida segura a novas florestas e confianças externas. Se necessitar de delegação entre confianças, o sinalizador EnableTGTDelegation deverá estar definido como Sim antes de a atualização de 9 de julho de 2019 ser instalada. Se não necessitar de delegação entre relações de confiança, não deve 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 reativar a delegação Kerberos sem restrições quando for necessária.

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. Este comportamento é o oposto do comportamento anterior. Em vez disso, recomendamos que os administradores reconfigurem os serviços afetados para utilizarem 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 sem restrições.

9 de julho de 2019

Foi lançada uma atualização que impõe o novo comportamento predefinido no lado de entrada da floresta e confianças externas. Os pedidos de autenticação para serviços que utilizem delegação sem restrições nos tipos de confiança listados serão autenticados, mas sem delegação. O serviço falhará quando tentar executar operações delegadas.

Para a mitigação, consulte a secção "Solução".

Localizar serviços que dependem de delegação sem restrições

Para procurar florestas com confianças de entrada que permitam delegação TGT e para localizar quaisquer entidades de segurança que permitam delegação sem restrições, 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 confiança de entrada do domínio de execução que tem a delegação sem restrições configurada. A saída será semelhante ao exemplo a seguir.

Detetar a delegação sem restrições através de eventos do Windows

Quando um tíquete Kerberos é emitido, um controlador de domínio do Active Directory registra os seguintes eventos de segurança. Os eventos contêm informações sobre o domínio de destino. Pode utilizar os eventos para determinar se a delegação sem restrições está a ser utilizada nas relações de confiança de entrada.

Resolução de problemas de falhas de autenticação

Quando a delegação sem restrições está desativada, as aplicações poderão ter problemas de compatibilidade com estas alterações se dependerem da delegação sem restrições. 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 Kerberos.

Os aplicativos que dependem da autenticação de ida e volta entre confianças não são suportados usando delegação restrita. Por exemplo, uma delegação falha se um utilizador na Floresta A efetuar a autenticação para uma aplicação na Floresta B e a aplicação na Floresta B estiver a tentar delegar um pedido de volta para a Floresta A.