الملخص
توفر الثقة طريقة للموارد في مجموعة تفرعات "Active Directory" الثقة بالهويات من غابة أخرى. يمكن تكوين هذه الثقة في كلا الاتجاهين. مجموعة تفرعات موثوقة هو مصدر هوية المستخدم. تتضمن مجموعة التفرعات الثقة المورد الذي مصادقة المستخدمين. مجموعة تفرعات موثوقة يمكن مصادقة المستخدمين إلى مجموعة التفرعات الثقة دون السماح بحدوث العكس.
تفويض Kerberos غير مقيد هو إليه الذي يرسل مستخدم بيانات الاعتماد الخاصة به إلى خدمة لتمكين الدائرة من الوصول إلى الموارد نيابة عن المستخدم. لتمكين غير مقيد تفويض Kerberos، يجب وضع حساب الخدمة في "Active Directory" موثوق بها للتفويض. يؤدي هذا إلى إنشاء مشكلة إذا كان مستخدم والخدمة التي تنتمي إلى مجموعة تفرعات مختلفة. الغابة الخدمة مسؤولة عن السماح بالتفويض. ويضم الوفد بيانات اعتماد المستخدمين من المجال الأم الخاص بالمستخدم.
تسمح مجموعة واحدة لاتخاذ قرارات الأمن يؤثر على حسابات مجموعة تفرعات أخرى انتهاك حدود الأمان بين الغابات. مهاجم الذي يملك الغابة الثقة طلب تفويض TGT الهوية من مجموعة تفرعات موثوقة، منح الوصول إلى الموارد في مجموعة تفرعات موثوقة. لا يتم تطبيق هذا على تفويض Kerberos مقيد (ككد).
يقدم Windows Server 2012 فرض "حدود الغابات" "تفويض Kerberos الكامل". إضافة هذه الميزة نهجاً للمجال الموثوق به لتعطيل التفويض غير مقيد على أساس كل ثقة. الإعداد الافتراضي لهذه الميزة يسمح التفويض غير مقيد وغير أمن.
توجد تحديثات توفر أسلوب الأمان للإصدارات التالية من Windows Server:
-
Windows Server 2019
-
Windows Server 2016
-
Windows Server 2012 R2
-
Windows Server 2012
وكانت هذه الميزة جنبا إلى جنب مع التغيرات في تقوية الأمن backported للإصدارات التالية:
-
Windows Server 2008 R2
-
Windows Server 2008
تحديثات الأمان هذه التغييرات التالية:
-
تفويض Kerberos غير مقيد معطل بشكل افتراضي في مجموعة التفرعات الجديدة والثقة الخارجية الجديدةبعد تثبيتتحديث 14 أيار/مايو والتحديثات اللاحقة.
-
تم تعطيل تفويض Kerberos غير مقيد على الغابات (الجديدة والقائمة) والثقة الخارجية بعد تثبيت في تموز/يوليه 9، 2019، تحديث والتحديثات اللاحقة.
-
تمكين المسؤولين تفويض Kerberos غير مقيد باستخدام قد أو الإصدارات الأحدث من الوحدة النمطية NETDOM و PowerShell الإعلان.
التحديثات قد يسبب تعارضات توافق للتطبيقات التي تتطلب التفويض غير مقيد حاليا عبر الغابة أو الثقة الخارجية. وهذا ينطبق بشكل خاص الثقة الخارجية التي يتم تمكين العلامة الفحص (تعرف أيضا باسم SID التصفية) افتراضياً. وبوجه خاص، سوف تفشل طلبات المصادقة للخدمات التي تستخدم التفويض غير مقيد في أنواع الثقة المذكورة عند طلب تذاكر جديدة.
لمواعيد الإصدار، راجع تحديثات المخطط الزمني.
الحل البديل
لتوفير البيانات وحساب الأمان على إصدار Windows Server الذي يحتوي على ميزة فرض "حدود الغابات" "تفويض Kerberos الكامل" ، يمكنك حظر التفويض TGT بعد تثبيت تحديثات 2019 آذار/مارس عبر علاقة ثقة واردة بتعيين علم الأسماء انابليتجتديليجيشنلا كما يلي:
netdom.exe trust fabrikam.com /domain:contoso.com /EnableTGTDelegation:No
يتم حظر التفويض TGT الغابة الجديدة والقائمة والثقة الخارجية بعد تثبيت قد وتحديث 2019 يوليو على التوالي.
لإعادة تمكين التفويض عبر علاقات الثقة والعودة إلى التكوين الأصلي غير آمنة حتى يمكن تمكين التفويض المقيد أو القائمة على الموارد، تعيين العلامة انابليتجتديليجيشن إلى نعم.
سطر الأوامر 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
ملاحظات
-
يجب تعيين إشارة انابليتجتديليجيشن في المجال الموثوق به (fabrikam.com في هذه الحالة) لكل المجال المانح للثقة (مثل contoso.com). بعد تعيين العلامة، لم يعد يسمح المجال الموثوق به Tgt ستفوض إلى المجال المانح للثقة.
-
حالة الأمان انابليتجتديليجيشن هو " لا".
-
سوف تفشل أي تطبيق أو خدمة تعتمد على التفويض غير مقيد عبر مجموعة تفرعات عند انابليتجتديليجيشن يدوياً أو برمجياً تعيين إلى نعم. افتراضيات انابليتجتديليجيشن إلى " لا" على علاقات الثقة الجديدة والموجودة بعد تثبيت التحديثات 2019 أيار/مايو وتموز/يوليه عام 2019. لمزيد من المعلومات حول كيفية اكتشاف هذا الفشل، راجع البحث عن الخدمات التي تعتمد على التفويض غير مقيد. راجع تحديث المخطط الزمني للمخطط زمني للتغييرات التي تؤثر على كيفية تطبيق هذا الحل البديل.
-
لمزيد من المعلومات حول NETDOM، راجع وثائق Netdom.exe.
-
إذا كان يجب تمكين التفويض TGT على ثقة، من المستحسن الحد من هذه المخاطر عن طريق تمكين حماية بيانات اعتماد Windows Defender على أجهزة الكمبيوتر العميلة. هذا يمنع كافة التفويض غير مقيد من كمبيوتر يحتوي Windows Defender اعتماد حماية ممكنة وتشغيلها.
-
إذا كان لديك ثقة خارجية أو الغابات، وأما تم تكوينها كالحجر الصحي، لا يمكن تمكين التفويض TGT وجود اثنين من الإعلام دلالات المعاكس. بت الفحص تعزيز حدود الأمان بين المجالات المشتركة. تمكين التفويض TGT مسح حدود الأمان بين المجالات عن طريق منح الوصول إلى المجال المانح للثقة لبيانات الاعتماد للمستخدمين من المجال الموثوق به. التي لا تحصل على كل شيء.
إضافة علامة الفحص: لا إلى بناء جملة سطر الأوامر NETDOM إذا تم تمكين العلامة الحجر الصحي .
-
إذا قمت بتغيير انابليتجتديليجيشن إلى نعم، حذف تذاكر Kerberos لطالبي الاستدعاء الأصلي والمتوسطة كما هو مطلوب. بطاقة ذات الصلة لحذف تم إحالة العميل TGT عبر التوثيق ذات الصلة. يمكن أن يشمل أكثر من جهاز واحد، استناداً إلى عدد القفزات التفويض في بيئة معينة.
لمزيد من المعلومات حول هذا الإجراء، راجع مقالة مركز Pro تكنولوجيا Windows التالية:
حماية أوراق اعتماد المجال المشتقة بحماية بيانات اعتماد Windows Defender
تحديثات المخطط الزمني
12 آذار/مارس عام 2019
الفرض لحدود الغابات ل Kerberos التفويض الكامل ستكون متوفرة كتحديث لتمكين هذه الميزة في كافة الإصدارات المعتمدة من ملقم Windows المسردة في قسم " تنطبق على " في بداية هذه المقالة. نوصي بتعيين الميزة على الثقة الواردة.
سيضيف التحديث ميزة فرض "حدود الغابات" "تفويض Kerberos الكامل" للأنظمة التالية:
-
Windows Server 2008 R2
-
Windows Server 2008
14 أيار/مايو سنة 2019
تم إصدار تحديث إضافة جديد افتراضي أمن تكوين لمجموعة التفرعات الجديدة والثقة الخارجية. إذا كنت تطلب التفويض عبر علاقات الثقة، يجب تعيين العلامة انابليتجتديليجيشن إلى نعم قبل تثبيت التحديث 9 يوليو عام 2019. إذا لم تكن تطلب التفويض عبر علاقات الثقة، يجب عدم تعيين علامة انابليتجتديليجيشن . سيتم تجاهل علامة انابليتجتديليجيشن حتى يتم تثبيت تحديث 9 يوليو عام 2019 لإعطاء مزيد من الوقت لإعادة تمكين تفويض Kerberos غير مقيد عندما يكون مطلوباً المسؤولين.
كجزء من هذا التحديث، سيتم تعيين العلامة انابليتجتديليجيشن إلى " لا" بشكل افتراضي لأي علاقات الثقة التي تم إنشاؤها حديثا. وهذا هو عكس السلوك السابق. نوصي بأن المسؤولين تكوين الخدمات المتأثرة لاستخدام التفويض المقيد تستند إلى الموارد بدلاً من ذلك.
لمزيد من المعلومات حول كيفية اكتشاف مشكلات التوافق، راجع البحث عن الخدمات التي تعتمد على التفويض غير مقيد.
9 تموز/يوليه عام 2019
تم إصدار تحديث فرض السلوك الافتراضي الجديد على الجانب الواردة من الغابة والثقة الخارجية. طلبات مصادقة للخدمات التي تستخدم التفويض غير مقيد في أنواع الثقة المذكورة تتم مصادقة ولكن بدون تفويض. سوف تفشل الخدمة عند محاولة تشغيل العمليات المفوضة.
للتخفيف من حدتها، راجع قسم "الحل البديل".
البحث عن الخدمات التي تعتمد على التفويض غير مقيد
للبحث عن الغابات التي الثقات الواردة السماح بتفويض TGT، والعثور على أسس تسمح بتفويض غير مقيد، أي أمان تشغيل PowerShell التالية ملفات البرامج النصية في برنامج نصي (على سبيل المثال، RiskyServiceAccountsByTrust.ps1-الحصول على تجمع):
ملاحظة
يمكنك أيضا تمرير العلامة -سأنال للبحث عبر علاقات الثقة التي لا تسمح بتفويض 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
}
سرد إخراج البرامج النصية PowerShell أساسيات أمان Active Directory في المجالات التي تم تكوينها لثقة واردة من تنفيذ المجال الذي قد يقيد تكوين الوفد. الإخراج سوف تشبه المثال التالي.
|
المجال |
sAMAccountName |
فئة الكائن |
|
partner.fabrikam.com |
الخطيرة |
المستخدم |
|
partner.fabrikam.com |
labsrv$ |
جهاز الكمبيوتر |
الكشف عن التفويض غير مقيد من خلال أحداث Windows
عندما يتم إصدار تذكرة Kerberos، وحدة تحكم مجال "Active Directory" تسجيل أحداث الأمان التالية. الأحداث التي تحتوي على معلومات حول المجال الهدف. يمكنك استخدام الأحداث لتحديد ما إذا كان يتم استخدام التفويض غير المقيد عبر الثقات الواردة.
ملاحظة
للتحقق من الأحداث التي تحتوي على قيمة تارجيتدوماينامي الذي يتطابق مع اسم المجال الموثوق به.
|
سجل الأحداث |
مصدر الحدث |
معرف الحدث |
تفاصيل |
|
أمان |
مايكروسوفت-Windows--تدقيق الأمان |
4768 |
وقد صدر Kerberos TGT. |
|
أمان |
مايكروسوفت-Windows--تدقيق الأمان |
4769 |
تم إصدار بطاقة خدمة Kerberos. |
|
أمان |
مايكروسوفت-Windows--تدقيق الأمان |
4770 |
وتم تجديد بطاقة خدمة Kerberos. |
استكشاف أخطاء فشل المصادقة
عندما يتم تعطيل التفويض غير مقيد، قد يكون للتطبيقات مشاكل التوافق مع هذه التغييرات إذا التطبيقات التي تعتمد على التفويض غير مقيد. يجب أن يتم تكوين وفد مقيدة باستخدام هذه التطبيقات أو المقيدة التي ترتكز على الموارد. هندسة كهربائيةأو مزيد من المعلومات, sو نظرة عامة من تفويض Kerberos مقيد.
لا يتم اعتماد التطبيقات التي تعتمد على التوثيق ذهابا وإيابا عبر علاقات الثقة باستخدام التفويض المقيد. على سبيل المثال، فشل وفد إذا مصادقة مستخدم في المجموعة أ إلى تطبيق موجود في "المجموعة ب" ويحاول التطبيق في "الغابات ب" تفويض تذكرة العودة إلى الغابة أ.
