Resumo
Fidedignidades de floresta fornecem uma forma de recursos na floresta de Active Directory para confiar identidades de outra floresta. Esta fidedignidade pode ser configurada em ambas as direcções. Floresta fidedigna é a origem da identidade do utilizador. A floresta confiante contém o recurso ao qual os utilizadores autenticados. Floresta fidedigna pode autenticar os utilizadores para a floresta confiante sem permitir a reversão ocorra.
Sem restrições a delegação Kerberos é um mecanismo no qual um utilizador envia as respectivas credenciais para um serviço para activar o serviço aceder a recursos em nome do utilizador. Para activar a delegação de Kerberos sem restrições, a conta do serviço no Active Directory deve ser marcada como fidedignas para delegação. Isto cria um problema se o utilizador e o serviço pertencem a diferentes florestas. A floresta de serviço é responsável, para permitir a delegação. A delegação inclui as credenciais dos utilizadores da floresta do utilizador.
Permitir que uma floresta tomar decisões de segurança que afecta as contas de outra floresta viola o limite de segurança entre florestas. Um intruso que possui a floresta confiante pode pedir delegação de uma TGT para uma identidade de floresta fidedigna, atribuindo-lhe acesso a recursos na floresta fidedigna. Não é aplicável a delegação Kerberos limitada (KCD).
Windows Server 2012 introduzidos imposição para o limite da floresta para delegação de Kerberos completo. Esta funcionalidade adicionada uma política para o domínio fidedigno para desactivar a delegação sem restrições, numa base por fidedignidade. A predefinição para esta funcionalidade permite a delegação sem restrições e não é segura.
As actualizações que fornecem protecção de segurança existem para as seguintes versões do Windows Server:
-
Servidor de Windows 2019
-
Windows Server 2016
-
Windows Server 2012 R2
-
Windows Server 2012
Esta funcionalidade e as endurecimento de segurança foram backported às seguintes versões:
-
Windows Server 2008 R2
-
Windows Server 2008
Estas actualizações de segurança efectuar as seguintes alterações:
-
A delegação Kerberos sem restrições está desactivada por predefinição numa nova floresta e novas fidedignidades externasdepois de instalar oa actualização de 14 de Maio e actualizações mais recentes.
-
Sem restrições a delegação Kerberos está desactivada nas florestas (novos e existentes) e as fidedignidades externas, depois de instalar o de Julho de 9 de Maio de 2019, update e actualizações mais recentes.
-
Os administradores podem activar sem restrições a delegação Kerberos através da utilização de Maio ou versões posteriores do módulo NETDOM e AD PowerShell.
As actualizações podem causar conflitos de compatibilidade para aplicações que requerem actualmente delegação sem restrições através de fidedignidades externas ou floresta. Isto é especialmente verdade de fidedignidade externa para o qual o sinalizador de quarentena (também conhecido como a filtragem por SID) está activado por predefinição. Especificamente, os pedidos de autenticação para os serviços que utilizam a delegação sem restrições sobre os tipos de fidedignidade listados irão falhar quando solicitar novos bilhetes.
Para as datas de lançamento, consulte actualizações da linha cronológica.
Solução
Para fornecer segurança de dados e conta numa versão de servidor do Windows que tenha a funcionalidade de imposição para o limite da floresta para delegação de Kerberos completo , pode bloquear delegação TGT depois de instalar as actualizações de Março de 2019 através de uma fidedignidade de entrada, definindo o Sinalizador de Netdom EnableTGTDelegation como n, do seguinte modo:
netdom.exe trust fabrikam.com /domain:contoso.com /EnableTGTDelegation:No
Delegação TGT está bloqueada em fidedignidades externas e a floresta nova e existente depois de instalar o Maio e de Julho de 2019 actualiza, respectivamente.
Para activar novamente a delegação em fidedignidades e voltar a configuração original como não segura até que a delegação restrita ou baseadas em recursos pode ser activada, defina o sinalizador EnableTGTDelegation para Sim.
A linha de comandos NETDOM para activar a delegação TGT é o seguinte:
netdom trust <TrustedDomainName > /domain:<TrustingDomainName > /EnableTgtDelegation:Yes
Conceptualmente pode considerar a sintaxe do NETDOM para activar a delegação TGT do seguinte modo:
netdom trust <domain that you are administering> /domain:<domain whose trust NETDOM is modifying> /EnableTgtDelegation:Yes
A sintaxe do NETDOM para activar a delegação TGT de utilizadores de fabrakam.com em servidores de contoso.com é o seguinte:
netdom.exe trust fabrikam.com /domain:contoso.com /EnableTGTDelegation:Yes
Notas
-
Deve ser definido o sinalizador EnableTGTDelegation no domínio fidedigno (fabrikam.com neste caso) para cada domínio confiante (por exemplo, contoso.com). Depois do sinalizador estiver definido, o domínio fidedigno deixará de permitir TGT delegada ao domínio confiante.
-
O estado protegido para EnableTGTDelegation é não.
-
Qualquer aplicação ou serviço que dependa de delegação sem restrições entre florestas irá falhar quando EnableTGTDelegation está manualmente ou programaticamente definida como Sim. Predefinições de EnableTGTDelegation para não em fidedignidades de novas e existentes depois de instalar as actualizações de Maio de 2019 e de Julho de 2019. Para mais informações sobre como detectar esta falha, consulte Localizar serviços que dependem de delegação sem restrições. Consulte actualizações de linha de tempo para uma linha cronológica de alterações que afectam a forma como esta solução alternativa pode ser aplicada.
-
Para mais informações sobre o NETDOM, consulte a documentação de Netdom.exe.
-
Se deve activar a delegação de TGT uma fidedignidade, recomenda-se que reduza este risco activando a protecção de credenciais do Windows Defender em computadores cliente. Isto impede que todos os delegação sem restrições de um computador que tenha o Windows Defender credencial Guard activada e em execução.
-
Se tiver uma floresta ou fidedignidade externa e quer estão configuradas da forma em quarentena, delegação de TGT não pode ser activada porque dois sinalizadores tem semânticas opostas. O bit de quarentena reforça o limite de segurança entre domínios de participantes. Activar a delegação TGT apaga os limites de segurança entre domínios, atribuindo o acesso ao domínio confiante para as credenciais de utilizadores do domínio fidedigno. Não pode ter, nos dois sentidos.
Adicione o sinalizador de quarentena: n a sintaxe de linha de comandos NETDOM, se o sinalizador de quarentena estiver actualmente activado.
-
Se tiver alterado o EnableTGTDelegation para Sim, elimine bilhetes Kerberos na fonte e intermédias aos autores das chamadas conforme necessário. Bilhete para eliminar é a referência do cliente TGT na fidedignidade relevante. Isto pode envolver mais do que um dispositivo, consoante o número de saltos de delegação num determinado ambiente.
Para mais informações sobre este procedimento, consulte o seguinte artigo do Centro de profissionais de TIs do Windows:
Proteger credenciais de domínio derivados com protecção de credenciais do Windows Defender
Linha cronológica de actualizações
12 de Março de Maio de 2019
A imposição para o limite da floresta para Kerberos delegação completa vai estar disponível como uma actualização para activar esta funcionalidade em todas as versões suportadas do Windows Server que estão listados na secção aplica-se a parte superior deste artigo. Recomendamos que defina a funcionalidade em fidedignidades de floresta de entrada.
A actualização irá adicionar a funcionalidade de imposição para o limite da floresta para delegação de Kerberos completo para os seguintes sistemas:
-
Windows Server 2008 R2
-
Windows Server 2008
14 de Maio de 2019
Foi disponibilizada uma actualização que adicionar uma nova predefinição de segurança configuração nova floresta e fidedignidades externas. Se necessitar de delegação em fidedignidades, o sinalizador de EnableTGTDelegation deve ser definido para Sim antes de é instalada a actualização de 9 de Julho de 2019. Se necessitar de delegação em fidedignidades, não deve definir o sinalizador EnableTGTDelegation . O sinalizador EnableTGTDelegation será ignorado até que seja instalada a actualização de 9 de Julho de 2019 para proporcionar aos administradores tempo para voltar a activar a delegação de Kerberos sem restrições, quando for necessário.
Como parte desta actualização, o sinalizador EnableTGTDelegation será definido para não por predefinição para qualquer fidedignidades recém-criado. Este é o oposto do comportamento anterior. Recomendamos que os administradores reconfigurar em vez disso, os serviços afectados para utilizar a delegação restrita baseadas em recursos.
Para mais informações sobre como detectar problemas de compatibilidade, consulte Localizar serviços que dependem de delegação sem restrições.
De Julho de 9 de Maio de 2019
Foi disponibilizada uma actualização que imponha o novo comportamento predefinido no lado entrado da floresta e fidedignidades externas. Pedidos de autenticação para serviços que utilizam a delegação sem restrições sobre os tipos de fidedignidade listados serão autenticados, mas sem delegação. O serviço irá falhar quando tenta executar operações de delegado.
Para a atenuação, consulte a secção "como contornar".
Localizar serviços que dependem de delegação sem restrições
Para verificar a existência de florestas que têm fidedignidades de entrada que permitem a delegação TGT e para localizar qualquer segurança principais que permitem a delegação sem restrições, execute o seguinte PowerShell scripts num script de ficheiros (por exemplo, Get-RiskyServiceAccountsByTrust.ps1- Recolher):
Nota
Também pode transmitir o sinalizador - ScanAll para procurar através de fidedignidades que permite a delegação 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 de PowerShell lista de principais de segurança do Active Directory em domínios que estão configurados para uma fidedignidade de entrada do domínio de execução que tenha sem restrições a delegação configurada. O resultado será semelhante ao seguinte exemplo.
|
domínio |
sAMAccountName |
classe de objecto |
|
partner.fabrikam.com |
perigosas |
utilizador |
|
partner.fabrikam.com |
labsrv$ |
computador |
Detectar delegação sem restrições através de eventos do Windows
Quando uma permissão Kerberos é emitida, 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 está a ser utilizada sem restrições de delegação em fidedignidades de entrada.
Nota
Procurar eventos que contêm um valor de NomeDomínioDestino que corresponda ao nome de domínio fidedigno.
|
Registo de eventos |
Origem do evento |
ID de evento |
Detalhes |
|
Segurança |
Microsoft-Windows--a auditoria de segurança |
4768 |
Foi emitida uma TGT de Kerberos. |
|
Segurança |
Microsoft-Windows--a auditoria de segurança |
4769 |
Foi emitida uma permissão de serviço Kerberos. |
|
Segurança |
Microsoft-Windows--a auditoria de segurança |
4770 |
Foi renovada uma permissão de serviço Kerberos. |
Resolução de problemas de falhas de autenticação
Quando está desactivada delegação sem restrições, aplicações podem ter problemas de compatibilidade com estas alterações se as aplicações dependem de delegação sem restrições. Estas aplicações deverão estar configuradas para delegação constrangida de utilização ou delegação que é baseada no recurso restrita. Fou mais informações, see Descrição geral de delegação constrangida Kerberos.
Não são suportadas aplicações que dependam de autenticação de ida e volta em fidedignidades utilizando a delegação restrita. Por exemplo, uma delegação de falha se um utilizador na floresta A autentica a uma aplicação na floresta B e a aplicação na floresta B está a tentar delegar uma permissão para a floresta.
