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.
