Shrnutí
Vztahy důvěryhodnosti doménové struktury poskytují způsob pro zdroje v důvěryhodných identit z jiné doménové struktury služby Active Directory doménové struktury. Tento vztah důvěryhodnosti může být nakonfigurována v obou směrech. Důvěryhodné doménové struktury je zdrojem identity uživatele. Důvěřující doménové struktury obsahuje zdroje, které uživatelé jsou ověřeni. Důvěryhodné doménové struktuře můžete ověřovat uživatele důvěřující doménové struktury, aniž by se naopak vyskytují.
Bez omezení delegování s protokolem Kerberos je mechanismus, ve kterém uživatel odešle přihlašovací údaje ke službě povolit službu pro přístup k prostředkům za uživatele. Chcete-li povolit delegování s protokolem Kerberos bez omezení, musí být účtu služby ve službě Active Directory označena jako důvěryhodná pro delegování. Tím se vytvoří problém pokud uživatele a služby patří do různých doménových strukturách. Doménové služby je zodpovědný za povolení delegování. Delegace zahrnuje pověření uživatele z doménové struktury uživatele.
Povolením jedné doménové struktuře k rozhodování zabezpečení ovlivňující jiné doménové struktuře účtů porušují bezpečnostní hranice mezi doménovými strukturami. Útočník, který vlastní důvěřující doménové struktuře můžete požádat o delegování identity TGT z důvěryhodné doménové struktury poskytují přístup k prostředkům v důvěryhodné doménové struktuře. To neplatí pro protokol Kerberos vynucené delegování (KCD).
Windows Server 2012 zavedena vynucení pro hranice doménové struktury pro úplné delegování s protokolem Kerberos. Tuto funkci Přidat zásadu k důvěryhodné doméně zakázat bez omezení delegace na svěřenském základě. Ve výchozím nastavení tato funkce umožňuje delegování bez omezení a nebezpečný.
Aktualizace, které umožňují posílení zabezpečení existují následující verze systému Windows Server:
-
Windows Server 2019
-
Windows Server 2016
-
Windows Server 2012 R2
-
Windows Server 2012
Tato funkce spolu se změnami security hardening byly přeneseny zpět do následujících verzí:
-
Windows Server 2008 R2
-
Windows Server 2008
Tyto aktualizace zabezpečení, proveďte následující změny:
-
Delegování s protokolem Kerberos bez omezení je zakázáno ve výchozím nastavení v nové doménové struktuře a nových externích vztahů důvěryhodnostiPo instalacidne 14 aktualizace a aktualizace novější.
-
Bez omezení delegování s protokolem Kerberos je zakázáno v lesích (nových i stávajících) a externí vztahy důvěryhodnosti po instalaci 9 červenci 2019, novější aktualizace a aktualizace.
-
Správci mohou povolit bez omezení delegování s protokolem Kerberos pomocí květnového nebo novějších verzích modulu NETDOM a AD PowerShell.
Aktualizace může způsobit konflikty kompatibility pro aplikace, které nyní vyžadují delegování bez omezení v doménové struktuře nebo externích vztahů důvěryhodnosti. To platí zejména pro externí vztah důvěryhodnosti, jehož vlajkou karantény (známé také jako filtrování identifikátorů SID) ve výchozím nastavení povolena. Konkrétně požadavků na ověření pro služby, které používají delegování bez omezení typů seznamu důvěryhodnosti selže při požadavku na nové lístky.
Data vydání v tématu aktualizuje časové osy.
Alternativní řešení
K zabezpečení dat a účet na verzi Windows Server, který má funkci vynucení pro hranice doménové struktury pro úplné delegování s protokolem Kerberos , můžete blokovat delegování TGT po instalaci aktualizace března 2019 přes příchozí vztah důvěryhodnosti nastavením netdom příznak EnableTGTDelegation k č takto:
netdom.exe trust fabrikam.com /domain:contoso.com /EnableTGTDelegation:No
TGT delegování je blokováno na nové a existující doménové struktuře a externí vztahy důvěryhodnosti po instalaci květnu a červenci 2019 aktualizuje v uvedeném pořadí.
Znovu povolit delegování v rámci vztahů důvěryhodnosti a vrátit původní konfiguraci nebezpečné, dokud může být povoleno delegování omezené nebo založeného na zdrojích, nastavte EnableTGTDelegation příznak na hodnotu Ano.
Chcete-li povolit delegování TGT příkazového řádku NETDOM je následující:
netdom trust <TrustedDomainName > /domain:<TrustingDomainName > /EnableTgtDelegation:Yes
Koncepčně si lze představit NETDOM syntaxe umožňující delegování TGT:
netdom trust <domain that you are administering> /domain:<domain whose trust NETDOM is modifying> /EnableTgtDelegation:Yes
NETDOM syntaxe povolit delegování TGT fabrakam.com uživatelů na serverech domény contoso.com je následující:
netdom.exe trust fabrikam.com /domain:contoso.com /EnableTGTDelegation:Yes
Poznámky:
-
Je třeba nastavit příznak EnableTGTDelegation v důvěryhodné doméně (Ramo v tomto případě) pro každý důvěřující domény (například contoso.com). Poté, co je nastaven příznak, důvěryhodné domény umožní již lístky TGT delegovat k důvěřující doméně.
-
Stav zabezpečení EnableTGTDelegation je Ne.
-
Všechny aplikace nebo služby, který je založen na bez omezení delegování v rámci doménových struktur se nezdaří, pokud EnableTGTDelegation ručně nebo programově nastavena na Ano. Výchozí hodnoty EnableTGTDelegation na hodnotu Ne u nových a stávajících vztahů důvěryhodnosti, po kterou může 2019 a červenci 2019 aktualizace nainstalovat. Další informace o tom, jak rozpoznat selhání naleznete v tématu vyhledání služeb, které spoléhají na delegování bez omezení. Časová osa na změny, které mají vliv na použití tohoto zástupného řešení naleznete v tématu aktualizuje časové osy .
-
Další informace o nástroji NETDOM naleznete v dokumentaci Netdom.exe.
-
Pokud povolíte TGT delegování na vztah důvěryhodnosti, je vhodné zmírnit toto riziko tím, že umožňuje v klientských počítačích Windows Defender pověření Guard. Tím se zabrání všem bez omezení delegace z počítače, který má Windows Defender pověření Guard povolena a spuštěna.
-
Pokud máte externí vztah důvěryhodnosti nebo doménové struktury a buď jsou nakonfigurovány jako v karanténě, TGT delegování nelze povolit, protože dva příznaky mají opačné sémantiku. Bit karanténní posílí hranice zabezpečení mezi doménami zúčastněných. Povolení delegování TGT smaže hranice zabezpečení mezi doménami přidělením přístupu důvěřující domény pověření uživatele z důvěryhodné domény. Nelze jej máte oba způsoby.
Pokud je zapnut příznak karanténní přidáte příznak karantény: Ne syntaxe příkazového řádku NETDOM.
-
Pokud jste změnili EnableTGTDelegation na hodnotu Ano, odstraňte lístky protokolu Kerberos na původní a mezilehlých volajících podle potřeby. Relevantní lístek k odstranění je odkaz klienta TGT přes odpovídající vztah důvěryhodnosti. To by mohlo zahrnovat více než jedno zařízení, v závislosti na počtu směrování delegování v daném prostředí.
Další informace o tomto postupu naleznete v následujícím článku Windows IT Pro Center:
Chránit pověření domény odvozené s Guard pověření systému Windows Defender
Aktualizace časové osy
12. března 2019
Vynucení pro hranice doménové struktury budou k dispozici jako aktualizace Chcete-li povolit tuto funkci na všech podporovaných verzích systému Windows Server jsou uvedeny v části platí pro na začátku tohoto článku úplné delegování ověřování pomocí protokolu Kerberos. Doporučujeme nastavit funkci na příchozí vztahy důvěryhodnosti doménové struktury.
Tato aktualizace přidá funkci vynucení pro hranice doménové struktury pro úplné delegování s protokolem Kerberos pro tyto systémy:
-
Windows Server 2008 R2
-
Windows Server 2008
14. května 2019
Byla vydána aktualizace, přidání nové bezpečné výchozí konfigurace nové doménové struktury a externí vztahy důvěryhodnosti. Pokud je požadováno delegování přes vztahy důvěryhodnosti, je třeba nastavit příznak EnableTGTDelegationAno před instalací aktualizace 9. července 2019. Pokud nevyžadujete delegování prostřednictvím vztahů důvěryhodnosti, neměli nastavit příznak EnableTGTDelegation . Příznak EnableTGTDelegation bude ignorována, dokud nebude nainstalována aktualizace 9. července 2019 správcům čas znovu povolit delegování s protokolem Kerberos bez omezení, pokud je to požadováno.
Jako součást této aktualizace EnableTGTDelegation příznak nastaví Ne ve výchozím nastavení pro všechny nově vytvořené vztahy důvěryhodnosti. To je opakem předchozí chování. Doporučujeme správcům namísto překonfigurovat ohrožených služeb použít vynucené delegování založeného na zdrojích.
Další informace o tom, jak rozpoznat problémy s kompatibilitou naleznete v tématu vyhledání služeb, které spoléhají na delegování bez omezení.
9. července 2019
Byla vydána aktualizace, která podpoří nové výchozí chování na vstupní straně doménové struktury a externí vztahy důvěryhodnosti. Požadavky na ověření pro služby, které používají delegování bez omezení typů seznamu důvěryhodnosti budou ověřeny, ale bez delegování. Služba selže při pokusu spustit delegovanou operace.
Ke zmírnění naleznete v části "řešení".
Vyhledání služeb, které jsou závislé na delegování bez omezení
K vyhledání doménových strukturách, které mají příchozí vztahy důvěryhodnosti, které umožňují TGT delegování a najít všechny zabezpečení objektů, které umožňují bez omezení delegování spustit následující PowerShell skripty ve skriptu souboru (například Get-RiskyServiceAccountsByTrust.ps1 - Přeprava):
Poznámka:
Můžete také předat příznak - ScanAll vyhledávání prostřednictvím vztahů důvěryhodnosti, které neumožňují TGT delegování.
[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
}
Výstup skriptů prostředí PowerShell zobrazí seznam zaregistrovaných objektů zabezpečení služby Active Directory v doménách, které jsou nakonfigurovány pro příchozí vztah důvěryhodnosti z domény vykonávajícího, který má aktivace konfigurace delegování. Výstup bude vypadat podobně jako následující příklad.
|
domény |
sAMAccountName |
objectClass |
|
partner.fabrikam.com |
nebezpečné |
uživatel |
|
partner.fabrikam.com |
labsrv$ |
počítač |
Detekce bez omezení delegování pomocí událostí systému Windows
Při vydání lístku protokolu Kerberos řadiči domény služby Active Directory zaznamenává následující události zabezpečení. Události, které obsahují informace o cílové domény. Události můžete použít k určení, zda je použit bez omezení delegování přes příchozí vztahy důvěryhodnosti.
Poznámka:
Zkontrolujte události, které obsahují Název_cílové_domény hodnotu, která odpovídá název důvěryhodné domény.
|
Protokol událostí |
Zdroj události |
ID události |
Podrobnosti |
|
Zabezpečení |
Microsoft-Windows-Security audit |
4768 |
Byl vydán TGT protokolu Kerberos. |
|
Zabezpečení |
Microsoft-Windows-Security audit |
4769 |
Byl vydán lístek služby Kerberos. |
|
Zabezpečení |
Microsoft-Windows-Security audit |
4770 |
Byl obnoven lístek služby Kerberos. |
Poradce při potížích s chybami ověření
Při delegování bez omezení zakázána, aplikace mohou mít problémy s kompatibilitou s těmito změnami, pokud jsou aplikace závislé na delegování bez omezení. Tyto aplikace by měl být nakonfigurován na použití omezeného delegování nebo vynucené delegování, který je založen na prostředku. Fnebo Další informace, see Kerberos vynucené delegování přehled.
Pomocí vynuceného delegování nepodporuje aplikace využívající ověřování přenosu prostřednictvím vztahů důvěryhodnosti. Například delegování nezdaří, pokud uživatel v doménové struktuře A ověřování do aplikace v doménové struktuře B a aplikace v doménové struktuře B se pokouší o delegování lístek zpět k doménové struktuře A.
