التحديثات إلى تفويض 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 Full Delegation، يمكنك حظر تفويض 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 افتراضيا إلى NO على علاقات الثقة الجديدة والحالية بعد تثبيت تحديثات مايو 2019 وتموز/يوليو 2019. لمزيد من المعلومات حول كيفية اكتشاف هذا الفشل، راجع البحث عن الخدمات التي تعتمد على التفويض غير المقيد. راجع التحديثات المخطط الزمني للحصول على مخطط زمني للتغييرات التي تؤثر على كيفية تطبيق هذا الحل البديل.
• لمزيد من المعلومات حول NETDOM، راجع وثائقNetdom.exe.
• إذا كان يجب تمكين تفويض TGT على ثقة، فمن المستحسن التخفيف من هذه المخاطر عن طريق تمكين Windows Defender Credential Guard على أجهزة الكمبيوتر العميلة. يمنع هذا كل التفويض غير المقيد من كمبيوتر تم تمكين Windows Defender Credential Guard وتشغيله.
• إذا كان لديك غابة أو ثقة خارجية، وتم تكوين إما على أنها معزولة، فلا يمكن تمكين تفويض TGT لأن العلامتين تحتويان على دلالات متقابلة. يعزز بت العزل حد الأمان بين المجالات المشاركة. يؤدي تمكين تفويض TGT إلى مسح حدود الأمان بين المجالات عن طريق منح المجال الموثوق به حق الوصول إلى بيانات اعتماد المستخدمين من المجال الموثوق به. لا يمكنك الحصول عليه في كلا الاتجاهين.
  أضف علامة العزل:no إلى بناء جملة سطر أوامر NETDOM إذا تم تمكين علامة العزل حاليا.
• إذا قمت بتغيير EnableTGTDelegation إلى نعم، فاحذف تذاكر Kerberos على المتصلين الأصليين والمتوسطين كما هو مطلوب. البطاقة ذات الصلة المراد حذفها هي TGT الإحالة للعميل عبر الثقة ذات الصلة. ويمكن أن يشمل ذلك أكثر من جهاز واحد، اعتمادا على عدد قفزات التفويض في بيئة معينة.

لمزيد من المعلومات حول هذا الإجراء، راجع مقالة Windows IT Pro Center التالية:

حماية بيانات اعتماد المجال المشتقة باستخدام حماية بيانات اعتماد Windows Defender

مخطط زمني التحديثات

12 مارس 2019

سيكون فرض حدود الغابة لتفويض Kerberos الكامل متوفرا كتحديث لتمكين هذه الميزة على جميع الإصدارات المدعومة من Windows Server المدرجة في القسم ينطبق على في أعلى هذه المقالة. نوصي بتعيين الميزة على ثقة الغابة الواردة.

سيضيف التحديث ميزة فرض حدود الغابة ل Kerberos Full Delegation إلى الأنظمة التالية:

• Windows Server 2008 R2
• Windows Server 2008

14 مايو 2019

تم إصدار تحديث يضيف تكوينا افتراضيا آمنا جديدا إلى مجموعة تفرعات جديدة وثقة خارجية. إذا كنت تحتاج إلى تفويض عبر الثقة، يجب تعيين علامة EnableTGTDelegation إلى نعم قبل تثبيت تحديث 9 يوليو 2019. إذا كنت لا تحتاج إلى تفويض عبر الثقة، يجب عدم تعيين علامة EnableTGTDelegation . سيتم تجاهل علامة EnableTGTDelegation حتى يتم تثبيت تحديث 9 يوليو 2019 لمنح المسؤولين الوقت لإعادة تمكين تفويض Kerberos غير المقيد عند الحاجة إليه.

كجزء من هذا التحديث، سيتم تعيين علامة EnableTGTDelegation إلى لا بشكل افتراضي لأي علاقات ثقة تم إنشاؤها حديثا. هذا هو عكس السلوك السابق. نوصي المسؤولين بدلا من ذلك بإعادة تكوين الخدمات المتأثرة لاستخدام التفويض المقيد المستند إلى الموارد.

لمزيد من المعلومات حول كيفية الكشف عن مشكلات التوافق، راجع البحث عن الخدمات التي تعتمد على التفويض غير المقيد.

9 يوليو 2019

تم إصدار تحديث يفرض السلوك الافتراضي الجديد على الجانب الوارد من الغابة والثقة الخارجية. ستتم مصادقة طلبات المصادقة للخدمات التي تستخدم التفويض غير المقيد عبر أنواع الثقة المدرجة ولكن بدون تفويض. ستفشل الخدمة عندما تحاول تشغيل العمليات المفوضة.

للتخفيف من المخاطر، راجع قسم "الحل البديل".

العثور على الخدمات التي تعتمد على التفويض غير المقيد

للفحص بحثا عن الغابات التي تحتوي على علاقات ثقة واردة تسمح بتفويض TGT، والعثور على أي أساسيات أمان تسمح بالتفويض غير المقيد، قم بتشغيل البرامج النصية PowerShell التالية في ملف برنامج نصي (على سبيل المثال، 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 
}

يسرد إخراج البرامج النصية PowerShell أساسيات أمان Active Directory في المجالات التي تم تكوينها لثقة واردة من المجال المنفذ الذي تم تكوين تفويض غير مقيد. سيكون الإخراج مشابها للمثال التالي.

الكشف عن التفويض غير المقيد من خلال أحداث Windows

عند إصدار تذكرة Kerberos، تقوم وحدة تحكم مجال Active Directory بتسجيل أحداث الأمان التالية. تحتوي الأحداث على معلومات حول المجال الهدف. يمكنك استخدام الأحداث لتحديد ما إذا كان يتم استخدام التفويض غير المقيد عبر الثقة الواردة.

استكشاف أخطاء فشل المصادقة وإصلاحها

عند تعطيل التفويض غير المقيد، قد تواجه التطبيقات مشكلات في التوافق مع هذه التغييرات إذا كانت التطبيقات تعتمد على تفويض غير مقيد. يجب تكوين هذه التطبيقات لاستخدام التفويض المقيد أو التفويض المقيد المستند إلى الموارد. لمزيد من المعلومات، راجع نظرة عامة على تفويض Kerberos المقيد.

التطبيقات التي تعتمد على مصادقة ذهابا وإيابا عبر الثقة غير مدعومة باستخدام التفويض المقيد. على سبيل المثال، يفشل التفويض إذا كان مستخدم في Forest A يصادق على تطبيق في Forest B ويحاول التطبيق في Forest B تفويض تذكرة مرة أخرى إلى Forest A.