Applies ToWindows Server 2008 Windows Server 2008 R2 Windows Server 2012 Windows Server 2012 R2 Windows Server 2016 Windows Server 2019, all editions

Resumo

Confianças de floresta fornecem uma maneira de os recursos em uma floresta do Active Directory confiarem em identidades de outra floresta. Essa confiança pode ser configurada em ambas as direções. A floresta confiável é a origem da identidade do usuário. A floresta confiante contém o recurso no qual os usuários são autenticados. A floresta confiável pode autenticar os usuários da floresta confiante sem permitir que o inverso ocorra.

A delegação Kerberos irrestrita é um mecanismo no qual um usuário envia suas credenciais a um serviço para permitir que esse serviço acesse recursos em nome do usuário. Para habilitar a delegação Kerberos irrestrita, a conta do serviço no Active Directory deve ser marcada como confiável para delegação. Isso criará 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 afetam as contas de outra floresta viola o limite de segurança entre florestas. Um invasor que possuir a floresta confiante poderá solicitar a delegação de um TGT para uma identidade da floresta confiável, dando-lhe acesso aos recursos nessa floresta confiável. Isso não se aplica à delegação restrita de Kerberos (KCD).

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

Atualizações que fornecem reforç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 e as alterações no reforço de segurança foram transferidas 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 de Kerberos está desabilitada por padrão em novas flores e novas relações de confiança externas após a instalação da atualização de 14 de maio e posteriores.

  • A delegação irrestrita de Kerberos está desabilitada 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 posteriores.

  • Os administradores podem habilitar a delegação irrestrita de Kerberos 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 irrestrita em relações de confiança externas ou de floresta. Isso é especialmente válido para relações de confiança externas cujo sinalizador de quarentena (também conhecido como filtragem de SID) está habilitado por padrão. Especificamente, as solicitações de autenticação para serviços que usam delegação irrestrita nos tipos de confiança listados falharão quando você solicitar novos tíquetes.

Para conhecer as datas de lançamento, consulte Cronograma de atualizações.

Solução alternativa

Para fornecer dados e segurança da conta em uma versão do Windows Server que tenha o recurso Aplicação para Limite da Floresta para Delegação Completa do Kerberos, você pode bloquear a delegação do 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 em relações de confiança externas após a instalação das atualizações de maio e julho de 2019, respectivamente.

Para reabilitar a delegação entre confianças 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 do TGT é a seguinte:

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

Você pode pensar conceitualmente na sintaxe NETDOM para habilitar a delegação do TGT da seguinte maneira:

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

A sintaxe do NETDOM para habilitar a delegação do TGT de usuários de 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 neste caso) para cada domínio confiante (como contoso.com). Depois que o sinalizador estiver definido, o domínio confiável não permitirá mais que os TGTs sejam delegados ao domínio confiante.

  • O estado seguro para EnableTGTDelegation é Não.

  • Qualquer aplicativo ou serviço que dependa de delegação irrestrita entre florestas falhará quando EnableTGTDelegation for manualmente ou programaticamente definido como Sim. EnableTGTDelegation assume NO como padrão em relações de confiança novas e existentes após a instalação das 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 da delegação irrestrita. Consulte Cronograma de atualizações para um cronograma de alterações que afetam como essa solução alternativa pode ser aplicada.

  • Para obter mais informações sobre NETDOM, consulte a documentação de Netdom.exe.

  • Se você precisar habilitar a delegação do TGT em uma relação de confiança, convém reduzir esse risco, habilitando o Windows Defender Credential Guard em computadores clientes. Isso impede todas as delegações irrestritas de um computador com o Windows Defender Credential Guard habilitado e em execução.

  • Se você tiver uma floresta ou uma relação de confiança externa e uma delas estiver configurada como em quarentena, a delegação do TGT não poderá ser habilitada 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. Habilitar a delegação do TGT elimina os limites de segurança entre os domínios, fornecendo ao domínio confiante acesso às credenciais dos usuários do domínio confiável. As duas maneiras ao mesmo tempo não são possíveis.

    Adicione o sinalizador quarantine:no à sintaxe da linha de comando NETDOM se o sinalizador quarantine estiver habilitado no momento.

  • Se você alterou EnableTGTDelegation para Sim, exclua os tíquetes Kerberos nos chamadores original e intermediário, conforme necessário. O tíquete relevante a ser excluído é o TGT de referência do cliente em toda a 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 credenciais de domínio derivadas com o Windows Defender Credential Guard

Cronograma de atualizações

terça-feira, 12 de março de 2019

A imposição de limite de floresta para a delegação completa de Kerberos estará disponível como uma atualização para habilitar esse recurso em todas as versões com suporte do WindowsServer listadas na seçãoAplica-se a no começo deste artigo. Recomendamos que você defina o recurso em relações de confiança de floresta de entrada.

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

  • Windows Server 2008 R2

  • Windows Server 2008

Terça-feira, 14 de maio de 2019

Uma atualização foi lançada, adicionando uma nova configuração padrão segura a novas florestas e relações de confiança externas. Se você exige delegação entre relações de confiança, o sinalizador EnableTGTDelegation deve ser definido como Sim antes da instalação da atualização de 9 de julho de 2019. Se você não exige delegação entre relações de confiança, não deve definir o sinalizador EnableTGTDelegation. O sinalizador EnableTGTDelegation será ignorado até a atualização de 9 de julho de 2019 for instalada, para que os administradores tenham tempo de reabilitar a delegação Kerberos irrestrita quando ela for necessária.

Como parte dessa atualização, o sinalizador EnableTGTDelegation será definido como Não por padrão para qualquer relação de confiança recém-criada. 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 da delegação irrestrita.

Terça-feira, 9 de julho de 2019

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

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

Localizando serviços que dependem da delegação irrestrita

Para fazer um exame em busca florestas que tenham relações de confiança de entrada que permitem a delegação de TGT e encontrar entidades de segurança que permitem a delegação irrestrita, executar os seguintes scripts do PowerShell em um arquivo de script (por exemplo, Get-RiskyServiceAccountsByTrust.ps1 -Collect):

Observação

Também é possível transmitir o sinalizador -ScanAll para pesquisar em relações de confiança que não permitem a delegação 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 
}

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 em execução que tenha a delegação irrestrita configurada. O resultado será semelhante ao seguinte exemplo.

domain

sAMAccountName

objectClass

partner.fabrikam.com

dangerous

user

partner.fabrikam.com

labsrv$

computer

Detectando a delegação irrestrita por meio de eventos do Windows

Quando um tíquete do 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. Você pode usar os eventos para determinar se a delegação irrestrita é ser usada através de relações de confiança de entrada.

Observação

Verifique os eventos que contêm um valor TargetDomainName que corresponda ao nome de domínio confiável.

Log de eventos

Origem do evento

ID do Evento

Detalhes

Segurança

Auditoria de Segurança do Microsoft Windows

4768

Um TGT do Kerberos foi emitido.

Segurança

Auditoria de Segurança do Microsoft Windows

4769

Um tíquete de serviço do Kerberos foi emitido.

Segurança

Auditoria de Segurança do Microsoft Windows

4770

Um tíquete de serviço do Kerberos foi renovado.

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 dependerem da delegação irrestrita. Esses aplicativos devem ser configurados para usarem a delegação restrita ou a 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 a 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.

Precisa de mais ajuda?

Quer mais opções

Explore os benefícios da assinatura, procure cursos de treinamento, saiba como proteger seu dispositivo e muito mais.

As comunidades ajudam você a fazer e responder perguntas, fazer comentários e ouvir especialistas com conhecimento avançado.