עדכונים להקצאת TGT ביחסי אמון נכנסים ב- Windows Server

סיכום

יחסי אמון ביער מספקים למשאבים ביער של יער Active Directory דרך לתת אמון בזהויות מיער אחר. ניתן להגדיר אמון זה בשני הכיוונים. היער המהימן הוא המקור של זהות המשתמש. היער נותן האמון מכיל את המשאב שבפניו המשתמשים מבצעים אימות. היער המהימן יכול לאמת משתמשים ביער הנותן אמון מבלי לאפשר את ההיפך.

הקצאת Kerberos בלתי מוגבלת היא מנגנון שבו משתמש שולח את האישורים שלו לשירות כדי לאפשר לשירות לגשת למשאבים בשם המשתמש. כדי לאפשר הקצאת Kerberos בלתי מאולצת, יש לסמן את חשבון השירות ב- Active Directory כמהימן להקצאה. הדבר יוצר בעיה אם המשתמש והשירות שייכים ליערות שונים. יער השירות אחראי לאפשר האצלה. ההקצאה כוללת את אישורי המשתמשים מהיער של המשתמש.

מתן אפשרות ליער אחד לקבל החלטות אבטחה המשפיעות על חשבונות של יער אחר מפר את גבול האבטחה בין יערות. תוקף שהוא הבעלים של היער הנותן אמון יכול לבקש הקצאה של TGT עבור זהות מהיער המהימן, דבר שמעניק לו גישה למשאבים ביער המהימן. הדבר אינו חל על הקצאה מוגבלת של Kerberos (KCD).

ב- Windows Server 2012 הוצגה אכיפה עבור גבול היער לצורך הקצאה מלאה של Kerberos. תכונה זו הוסיפה מדיניות לתחום המהימן כדי להפוך הקצאה בלתי מאולצת ללא זמינה על בסיס אמון. הגדרת ברירת המחדל עבור תכונה זו מאפשרת הקצאה בלתי מאולצת ואינה בטוחה.

קיימים עדכונים שמספקים הקשחת אבטחה עבור הגירסאות הבאות של Windows Server:

• Windows Server 2019
• Windows Server 2016
• Windows Server 2012 R2
• Windows Server 2012

תכונה זו יחד עם שינויים בהקשחת האבטחה הועברו לאחור בגירסאות הבאות:

• Windows Server 2008 R2
• Windows Server 2008

עדכוני אבטחה אלה מבצעים את השינויים הבאים:

• הקצאת Kerberos בלתי מאולצת אינה זמינה כברירת מחדל ביער חדש ובאמון חיצוני חדש לאחר התקנת העדכון של 14 במאי ועדכונים מאוחרים יותר.
• הקצאת Kerberos בלתי מוגבלת אינה זמינה ביערות (חדשים וקיימים כאחד) ויחסי אמון חיצוניים לאחר התקנת העדכון של 9 ביולי, 2019 ועדכונים מאוחרים יותר.
• מנהלי מערכת יכולים להפוך הקצאת Kerberos בלתי מאולצת לזמינה באמצעות מודול NETDOM ו- AD PowerShell שפורסם במאי או בגירסאות מאוחרות יותר.

העדכונים עלולים לגרום להתנגשויות תאימות עבור יישומים שדורשים כעת הקצאה בלתי מאולצת בין יחסי אמון חיצוניים או יער. הדבר נכון במיוחד לגבי אמון חיצוני שעבורו דגל ההסגר (הידוע גם כסינון SID) זמין כברירת מחדל. באופן ספציפי, בקשות אימות עבור שירותים שמשתמשים בהקצאה לא מאולצת בסוגי יחסי האמון הרשומים ייכשלו כשתבקש כרטיסים חדשים.

לקבלת תאריכי ההפצה, עיין בציר הזמן של 'עדכונים'.

פתרון

כדי לספק אבטחת נתונים וחשבונות בגירסה של Windows Server שכוללת את התכונה 'אכיפה עבור גבול היער עבור הקצאה מלאה של Kerberos', באפשרותך לחסום הקצאת TGT לאחר התקנת עדכוני מרץ 2019 באמון נכנס על-ידי הגדרת דגל Netdom EnableTGTDelegationל'לא', באופן הבא:

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

הקצאת TGT נחסמת באמון חדש וקיים של יער וחיצוני לאחר התקנת העדכונים של מאי ויולי 2019 בהתאמה.

כדי להפוך מחדש את ההקצאה לזמינה בין יחסי אמון ולחזור לתצורה המקורית הלא בטוחה עד שניתן יהיה להפוך הקצאה מוגבלת או מבוססת משאבים לזמינה, הגדר את הדגל EnableTGTDelegationל'כן'.

שורת הפקודה של NETDOM כדי להפוך הקצאת TGT לזמינה היא כדלקמן:

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

ניתן לחשוב על תחביר NETDOM להפיכת הקצאת TGT לזמינה באופן הבא:

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

התחביר של NETDOM לאפשר הקצאת TGT של משתמשי fabrakam.com בשרתי contoso.com הוא כדלהלן:

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

         הערות

• יש להגדיר את דגל EnableTGTDelegation בתחום המהימן (fabrikam.com במקרה זה) עבור כל תחום נותן אמון (כגון contoso.com). לאחר הגדרת הדגל, התחום המהימן לא יאפשר עוד הקצאה של TGTs לתחום המהימן.
• המצב הבטוח עבור EnableTGTDelegation הוא לא.
• כל יישום או שירות המסתמכים על הקצאה בלתי מאולצת על-פני יערות ייכשלו כאשר EnableTGTDelegation מוגדר ידנית או תוכניתית ככן. ברירת המחדל של EnableTGTDelegation היא 'לא ' בנאמנות חדשות וקיימות לאחר התקנת העדכונים של מאי 2019 ויולי 2019. לקבלת מידע נוסף אודות האופן שבו ניתן לזהות כשל זה, ראה חיפוש שירותים שמסתמכים על הקצאה בלתי מאולצת. עיין בציר הזמן של עדכונים לקבלת ציר זמן של שינויים המשפיעים על האופן שבו ניתן להחיל פתרון זה.
• לקבלת מידע נוסף אודות NETDOM, עיין בתיעוד שלNetdom.exe.
• אם עליך להפוך הקצאת TGT לזמינה באמון, מומלץ לצמצם סיכון זה על-ידי הפעלת Windows Defender Credential Guard במחשבי לקוח. הדבר מונע כל הקצאה בלתי מאולצת ממחשב שבו Windows Defender Credential Guard זמין ופועל.
• אם יש לך יער או אמון חיצוני, ואחד מהם מוגדר כבהסגר, לא ניתן להפוך הקצאת TGT לזמינה מאחר שלשני הדגלים יש סמנטיקה מנוגדת. סיבית ההסגר מחזקת את גבול האבטחה בין התחומים המשתתפים. הפיכת הקצאת TGT לזמינה מוחקת את גבולות האבטחה בין תחומים על-ידי מתן גישה לתחום הנותן אמון באישורים של משתמשים מהתחום המהימן. אתה לא יכול לקבל את זה בשני הכיוונים.
  הוסף את דגל quarantine:no לתחביר שורת הפקודה של NETDOM אם דגל ההסגר זמין כעת.
• אם שינית את EnableTGTDelegationל-Yes, מחק כרטיסי Kerberos במתקשרים מקוריים ומתווכים כנדרש. הכרטיס הרלוונטי למחיקה הוא TGT ההפניה של הלקוח ברחבי האמון הרלוונטי. הדבר עשוי לכלול יותר ממכשיר אחד, בהתאם למספר דילוגי הקצאה בסביבה נתונה.

לקבלת מידע נוסף אודות הליך זה, עיין במאמר הבא של Windows IT Pro Center:

הגנה על אישורי תחום נגזרים באמצעות Windows Defender Credential Guard

ציר הזמן של עדכונים

12 במרץ 2019

האכיפה עבור הקצאה מלאה של גבול יער עבור Kerberos תהיה זמינה כעדכון כדי להפוך תכונה זו לזמינה בכל הגירסאות הנתמכות של Windows Server המפורטות בסעיף חל על בראש מאמר זה. מומלץ להגדיר את התכונה ביחסי אמון נכנסים בין יערות.

העדכון יוסיף את התכונה 'אכיפה עבור גבול יער עבור הקצאה מלאה של Kerberos' למערכות הבאות:

• Windows Server 2008 R2
• Windows Server 2008

14 במאי 2019

הופץ עדכון שמוסיף תצורת ברירת מחדל בטוחה חדשה ליחסי אמון חיצוניים ויער חדשים. אם אתה דורש הקצאה בין יחסי אמון, יש להגדיר את הדגל EnableTGTDelegationל'כן' לפני התקנת העדכון של 9 ביולי, 2019. אם אינך דורש הקצאה בין יחסי אמון, לא מומלץ להגדיר את הדגל EnableTGTDelegation . המערכת תתעלם מהדגל EnableTGTDelegation עד להתקנת העדכון של 9 ביולי, 2019, כדי לתת למנהלי המערכת זמן לאפשר מחדש הקצאת Kerberos בלתי מוגבלת בעת הצורך.

כחלק מעדכון זה, דגל EnableTGTDelegation יוגדר כלא כברירת מחדל עבור כל יחסי אמון חדשים שנוצרו. זה ההפך מההתנהגות הקודמת. במקום זאת, אנו ממליצים למנהלי מערכת להגדיר מחדש את השירותים המושפעים כדי שניתן יהיה להשתמש בהקצאה מבוססת משאבים.

לקבלת מידע נוסף אודות האופן שבו ניתן לזהות בעיות תאימות, ראה חיפוש שירותים המסתמכים על הקצאה בלתי מאולצת.

9 ביולי 2019

פורסם עדכון שאוכף את אופן הפעולה החדש המוגדר כברירת מחדל בצד הנכנס של יחסי אמון חיצוניים ויער. בקשות אימות עבור שירותים שמשתמשים בהקצאה לא מאולצת בסוגי יחסי האמון הרשומים יאומתו אך ללא הקצאה. השירות ייכשל כאשר הוא ינסה להפעיל פעולות מוקצות.

לקבלת צמצום סיכונים, עיין בסעיף "פתרון".

איתור שירותים שתלויים בהקצאה בלתי מוגבלת

כדי לסרוק לאיתור יערות הכוללים יחסי אמון נכנסים המאפשרים הקצאת TGT, וכדי למצוא מנהלי אבטחה שמאפשרים הקצאה בלתי מאולצת, הפעל את קבצי ה- Script הבאים של PowerShell בקובץ Script (לדוגמה, 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 
}

הפלט של קבצי ה- Script של PowerShell מפרט מנהלי אבטחה של Active Directory בתחומים שתצורתם נקבעה עבור אמון נכנס מהתחום המבצע שהוגדרה בו הקצאה לא מוגדרת. הפלט יהיה דומה לדוגמה הבאה.

זיהוי הקצאה בלתי מאולצת באמצעות אירועי Windows

כאשר מונפק כרטיס Kerberos, בקר תחום של Active Directory רושם את אירועי האבטחה הבאים. האירועים מכילים מידע אודות תחום היעד. תוכל להשתמש באירועים כדי לקבוע אם נעשה שימוש בהקצאה בלתי מאולצת ביחסי אמון נכנסים.

פתרון בעיות של כשלי אימות

כאשר הקצאה בלתי מאולצת אינה זמינה, יישומים עשויים להיתקל בבעיות תאימות עם שינויים אלה אם היישומים מסתמכים על הקצאה בלתי מאולצת. יש להגדיר יישומים אלה לשימוש בהקצאה מוגבלת או בהקצאה מוגבלת המבוססת על משאבים. לקבלת מידע נוסף, ראה סקירת הקצאה מאולצת של Kerberos.

יישומים המסתמכים על אימות הלוך ושוב בין יחסי אמון אינם נתמכים באמצעות הקצאה מוגבלת. לדוגמה, הקצאה נכשלת אם משתמש ביער א' מבצע אימות מול יישום ביער ב' והיישום ביער ב' מנסה להקצות כרטיס חזרה ליער א'.