Atualizações à delegação de TGT em confianças de entrada no Windows Server

Resumo

As confianças de floresta fornecem uma forma de os recursos numa floresta do Active Directory confiarem em identidades de outra floresta. Esta confiança pode ser configurada em ambas as direções. A floresta fidedigna é a origem da identidade do utilizador. A floresta fidedigna contém o recurso ao qual os utilizadores se autenticam. A floresta fidedigna pode autenticar os utilizadores na floresta fidedigna sem permitir que ocorra o inverso.

A delegação kerberos sem restrições é um mecanismo no qual um utilizador envia as credenciais para um serviço para permitir que o serviço aceda aos recursos em nome do utilizador. Para ativar a delegação kerberos sem restrições, a conta do serviço no Active Directory tem de ser marcada como fidedigna para delegação. Isto cria um problema se o utilizador e o serviço pertencerem a florestas diferentes. A floresta de serviços é responsável por permitir a delegação. A delegação inclui as credenciais dos utilizadores da floresta do utilizador.

Permitir que uma floresta tome decisões de segurança que afetam as contas de outra floresta viola o limite de segurança entre florestas. Um atacante que possua a floresta fidedigna pode pedir a delegação de um TGT para uma identidade da floresta fidedigna, dando-lhe acesso a recursos na floresta fidedigna. Isto não se aplica à delegação restrita de Kerberos (KCD).

Windows Server 2012 introduziu a Imposição do Limite de Floresta para 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 fidedignidade. A predefinição desta funcionalidade permite uma delegação sem restrições 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

Esta funcionalidade, juntamente com as alterações na proteção de segurança, foram suportadas nas 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 em novas confianças externas depois de instalar a atualização de 14 de maio e atualizações posteriores.
• A delegação kerberos sem restrições está desativada em florestas (novas e existentes) e confianças externas após instalar as atualizações de 9 de julho de 2019, atualizações e atualizações posteriores.
• Os administradores podem ativar a delegação kerberos sem restrições através das versões de maio ou posteriores do módulo NETDOM e AD PowerShell.

As atualizações podem causar conflitos de compatibilidade para aplicações que necessitam atualmente de delegação sem restrições em confianças externas ou florestas. 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. Especificamente, os pedidos de autenticação para serviços que utilizam delegação sem restrições sobre os tipos de fidedignidade listados falharão quando pedir novos pedidos de suporte.

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

Solução

Para fornecer segurança de dados e conta numa versão Windows Server que tenha a funcionalidade Imposição de Limite de Floresta para Delegação Completa kerberos, pode bloquear a delegação de TGT após instalar as atualizações de março de 2019 numa fidedignidade de entrada ao definir o sinalizador netdom EnableTGTDelegation como Não, da seguinte forma:

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

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

Para reativar a delegação entre fidedignidades e regressar à configuração não segura original até que a delegação restrita ou baseada em recursos possa ser ativada, defina o sinalizador EnableTGTDelegation como Sim.

A linha de comandos NETDOM para ativar a delegação de TGT é a seguinte:

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

Pode pensar conceptualmente na sintaxe NETDOM para ativar a delegação TGT da seguinte forma:

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

A sintaxe NETDOM para ativar a delegação de TGT de utilizadores 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 fidedigno (fabrikam.com neste caso) para cada domínio de confiança (como contoso.com). Depois de o sinalizador ser definido, o domínio fidedigno deixará de permitir que os TGTs sejam delegados ao domínio de confiança.
• O estado seguro para EnableTGTDelegation é Não.
• Qualquer aplicação ou serviço que dependa de delegação não preparada entre florestas falhará quando EnableTGTDelegation estiver definido manual ou programaticamente como Sim. A predefinição EnableTGTDelegation é NÃO 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 detetar esta falha, veja Localizar serviços que dependem de uma delegação sem restrições. Veja Atualizações linha cronológica de uma linha cronológica de alterações que afetam a forma como esta solução pode ser aplicada.
• Para obter mais informações sobre o NETDOM, veja a documentação doNetdom.exe.
• Se tiver de ativar a delegação TGT numa fidedignidade, recomenda-se que mitimente esse risco ao ativar o Windows Defender Credential Guard em computadores cliente. Isto impede todas as delegações não preparadas de um computador que tenha o Windows Defender Credential Guard ativado e em execução.
• Se tiver uma floresta ou confiança externa e estiver configurado como em quarentena, a delegação TGT não pode ser ativada porque os dois sinalizadores têm semântica oposta. O bit de quarentena reforça o limite de segurança entre os domínios participantes. Ativar a delegação TGT apaga os limites de segurança entre domínios ao conceder ao domínio fidedigno acesso às credenciais dos utilizadores do domínio fidedigno. Não podes tê-lo nos dois sentidos.
  Adicione o sinalizador quarentena:no à sintaxe da linha de comandos NETDOM se o sinalizador de quarentena estiver atualmente ativado.
• Se alterou EnableTGTDelegation para Sim, elimine as permissões Kerberos nos chamadores de origem e intermédios, conforme necessário. O pedido de eliminação relevante é o TGT de referência do cliente na confiança relevante. Isto pode envolver mais do que um dispositivo, dependendo do número de saltos de delegação num 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

linha cronológica do Atualizações

12 de março de 2019

A imposição do limite de floresta para a delegação completa de Kerberos estará disponível como uma atualização para ativar esta funcionalidade em todas as versões suportadas do Windows Server que estão listadas na secção Aplica-se a na parte superior deste artigo. Recomendamos que defina a funcionalidade em confianças de floresta de entrada.

A atualização adicionará a funcionalidade Imposição de Limite de Floresta para Delegação Completa de Kerberos aos seguintes sistemas:

• Windows Server 2008 R2
• Windows Server 2008

14 de maio de 2019

Foi lançada uma atualização adicionando uma nova configuração predefinida segura a novas confianças externas e florestas. Se precisar de delegação entre fidedignidades, o sinalizador EnableTGTDelegation deve ser definido como Sim antes da instalação da atualização de 9 de julho de 2019. Se não precisar de delegação entre fidedignidades, 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 tempo aos administradores para reativarem a delegação kerberos sem restrições quando for necessário.

Como parte desta atualização, o sinalizador EnableTGTDelegation será definido como Não por predefinição para quaisquer fidedignidades recentemente criadas. Este é o oposto do comportamento anterior. 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 detetar problemas de compatibilidade, veja Localizar serviços que dependem de uma 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 utilizam delegação sem restrições sobre os tipos de fidedignidade listados serão autenticados, mas sem delegação. O serviço falhará quando tentar executar operações delegadas.

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

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

Para procurar florestas que tenham fidedignidades de entrada que permitam a delegação de TGT e para encontrar os principais de segurança que permitam a delegação sem restrições, execute os seguintes scripts do PowerShell num ficheiro 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 
}

O resultado dos scripts do PowerShell lista principais 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 não restrita configurada. O resultado será semelhante ao seguinte exemplo.

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

Quando é emitida uma permissão Kerberos, um controlador de domínio do Active Directory regista 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 não restrita está a ser utilizada em confianças de entrada.

Resolver problemas de falhas de autenticação

Quando a delegação sem restrições estiver desativada, as aplicações poderão ter problemas de compatibilidade com estas alterações se as aplicações dependerem de uma delegação sem restrições. Estas aplicações devem ser configuradas para utilizar delegação restrita ou delegação restrita baseada em recursos. Para obter mais informações, veja Descrição Geral da Delegação Restrita de Kerberos.

As aplicações que dependem da autenticação de ida e volta entre fidedignidades não são suportadas através da delegação restrita. Por exemplo, uma delegação falha se um utilizador na Floresta A se autenticar numa aplicação na Floresta B e a aplicação na Floresta B estiver a tentar delegar uma permissão de volta à Floresta A.