Cập nhật ủy quyền TGT trên các tin cậy đến trong Windows Server

Tóm tắt

Tin cậy rừng cung cấp cách thức để các tài nguyên trong Rừng Active Directory tin cậy danh tính từ một rừng khác. Tin cậy này có thể được cấu hình theo cả hai hướng. Rừng tin cậy là nguồn nhận dạng người dùng. Rừng đáng tin cậy chứa tài nguyên mà người dùng xác thực. Rừng tin cậy có thể xác thực người dùng với rừng tin cậy mà không cho phép điều ngược lại xảy ra.

Đại diện Kerberos không ràng buộc là một cơ chế trong đó người dùng gửi thông tin xác thực của mình cho một dịch vụ nhằm cho phép dịch vụ truy nhập tài nguyên thay mặt cho người dùng. Để cho phép ủy quyền Kerberos không bị ràng buộc, tài khoản của dịch vụ trong Active Directory phải được đánh dấu là đáng tin cậy để ủy quyền. Điều này sẽ tạo ra sự cố nếu người dùng và dịch vụ thuộc các nhóm khác nhau. Rừng dịch vụ chịu trách nhiệm cho phép ủy quyền. Đại diện bao gồm thông tin xác thực của người dùng từ rừng của người dùng.

Việc cho phép một rừng đưa ra các quyết định bảo mật ảnh hưởng đến tài khoản của rừng khác sẽ vi phạm ranh giới bảo mật giữa các rừng. Kẻ tấn công sở hữu rừng tin cậy có thể yêu cầu ủy quyền TGT cho danh tính từ rừng tin cậy, cho phép nó truy nhập vào các tài nguyên trong rừng tin cậy. Điều này không áp dụng cho Ủy quyền Hạn chế Kerberos (KCD).

Windows Server 2012 giới thiệu Thực thi ranh giới rừng cho Ủy quyền Đầy đủ Kerberos. Tính năng này đã thêm chính sách vào tên miền tin cậy để tắt ủy quyền không bị ràng buộc trên cơ sở từng sự tin cậy. Thiết đặt mặc định cho tính năng này cho phép ủy quyền không bị ràng buộc và không an toàn.

Cập nhật cung cấp khả năng tăng cường bảo mật tồn tại cho các phiên bản Windows Server sau:

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

Tính năng này cùng với các thay đổi trong việc tăng cường bảo mật, đã được áp dụng trở lại cho các phiên bản sau:

• Windows Server 2008 R2
• Windows Server 2008

Các bản cập nhật bảo mật này thực hiện những thay đổi sau:

• Đại diện Kerberos không ràng buộc bị vô hiệu hóa theo mặc định trên rừng mới và tin cậy bên ngoài mới sau khi bạn cài đặt bản cập nhật 14 Tháng Năm và các bản cập nhật sau đó.
• Đại diện Kerberos không ràng buộc bị vô hiệu hóa trên các rừng (cả rừng mới và hiện tại) và các tin cậy bên ngoài sau khi bạn cài đặt bản cập nhật 09/07/2019 và các bản cập nhật mới hơn.
• Người quản trị có thể bật ủy quyền Kerberos không bị ràng buộc bằng cách sử dụng các phiên bản Tháng Năm hoặc mới hơn của mô-đun NETDOM và AD PowerShell.

Các bản cập nhật có thể gây ra xung đột tương thích cho các ứng dụng hiện yêu cầu ủy quyền không ràng buộc trên toàn bộ rừng hoặc tin cậy bên ngoài. Điều này đặc biệt đúng với sự tin cậy bên ngoài mà cờ cách ly (còn được gọi là lọc SID) được bật theo mặc định. Cụ thể, yêu cầu xác thực cho các dịch vụ sử dụng tính năng ủy quyền không hạn chế đối với các loại tin cậy được liệt kê sẽ không thành công khi bạn yêu cầu phiếu mới.

Để biết ngày phát hành, hãy xem dòng thời gian Cập nhật.

Giải pháp thay thế

Để cung cấp bảo mật dữ liệu và tài khoản trên phiên bản Windows Server có tính năng Ủy quyền Đầy đủ Ranh giới Rừng đối với Kerberos, bạn có thể chặn ủy quyền TGT sau khi cài đặt bản cập nhật Tháng Ba 2019 trên một tin cậy đến bằng cách đặt cờ netdom EnableTGTDelegation thành No, như sau:

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

Đại diện TGT bị chặn trên rừng mới và hiện có cũng như các quỹ tín thác bên ngoài sau khi bạn cài đặt các bản cập nhật Tháng Năm và Tháng Bảy 2019 tương ứng.

Để kích hoạt lại ủy quyền giữa các quỹ tín thác và trở về cấu hình không an toàn ban đầu cho đến khi ủy quyền bị ràng buộc hoặc dựa trên tài nguyên có thể được kích hoạt, hãy đặt cờ EnableTGTDelegation thành Yes.

Dòng lệnh NETDOM để bật ủy quyền TGT như sau:

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

Bạn có thể hiểu về cú pháp NETDOM để bật ủy quyền TGT như sau:

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

Cú pháp NETDOM để bật ủy quyền TGT của người dùng fabrakam.com trên máy chủ contoso.com là như sau:

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

         Ghi chú

• Cờ EnableTGTDelegation nên được đặt trong tên miền tin cậy (fabrikam.com trong trường hợp này) cho mỗi tên miền tin cậy (chẳng hạn như contoso.com). Sau khi gắn cờ, miền tin cậy sẽ không còn cho phép ủy nhiệm TGT cho miền tin cậy.
• Trạng thái bảo mật cho EnableTGTDelegation là No.
• Bất kỳ ứng dụng hoặc dịch vụ nào dựa vào ủy quyền không ràng buộc xuyên các rừng sẽ không hoạt động khi ủy quyền EnableTGTDelegation được đặt thành Yes theo cách thủ công hoặc theo chương trình. EnableTGTDelegation mặc định là NO đối với các quỹ tín thác mới và hiện có sau khi bạn cài đặt các bản cập nhật vào tháng 5 năm 2019 và tháng 7 năm 2019. Để biết thêm thông tin về cách phát hiện lỗi này, hãy xem Tìm các dịch vụ dựa trên ủy quyền không ràng buộc. Xem đường thời gian Cập nhật để biết đường thời gian về những thay đổi ảnh hưởng đến cách áp dụng giải pháp thay thế này.
• Để biết thêm thông tin về NETDOM, hãy xem tài liệuNetdom.exe.
• Nếu phải bật ủy quyền TGT trên một quỹ tín thác, bạn nên giảm thiểu rủi ro đó bằng cách bật Tính năng Bảo vệ Thông tin xác thực của Bộ bảo vệ Windows trên máy tính khách. Điều này ngăn tất cả các sự ủy quyền không bị hạn chế từ máy tính đã bật và đang chạy Windows Defender Credential Guard.
• Nếu bạn có một cụm rừng hoặc tin cậy bên ngoài, và một trong hai mục này được đặt cấu hình là được cách ly, thì không thể bật ủy quyền TGT vì hai cờ này có ngữ nghĩa trái nhau. Bit cách ly tăng cường ranh giới bảo mật giữa các miền tham gia. Bật ủy quyền TGT sẽ xóa ranh giới bảo mật giữa các miền bằng cách cấp cho miền tin cậy quyền truy nhập vào thông tin xác thực của người dùng từ miền tin cậy. Bạn không thể có được nó bằng cả hai cách.
  Thêm cờ quarantine:no vào cú pháp dòng lệnh NETDOM nếu cờ cách ly hiện đang được bật.
• Nếu bạn đã thay đổi EnableTGTDelegation thành Yes, hãy xóa phiếu Kerberos trên người gọi gốc và trung gian như cần thiết. Phiếu có liên quan cần xóa là TGT giới thiệu của khách hàng trên quỹ tín thác có liên quan. Hoạt động này có thể liên quan đến nhiều thiết bị, tùy thuộc vào số bước nhảy ủy quyền trong một môi trường nhất định.

Để biết thêm thông tin về quy trình này, hãy xem bài viết sau trong Trung tâm Chuyên gia CNTT của Windows:

Bảo vệ thông tin xác thực miền phái sinh bằng tính năng Bảo vệ thông tin xác thực của Bộ bảo vệ Windows

Cập nhật dòng thời gian

12/03/2019

Việc thực thi ranh giới rừng đối với ủy quyền đầy đủ Kerberos sẽ có sẵn dưới dạng bản cập nhật để bật tính năng này trên tất cả các phiên bản được hỗ trợ của Windows Server được liệt kê trong phần Áp dụng cho ở đầu bài viết này. Chúng tôi khuyên bạn nên đặt tính năng này trên tin cậy rừng đến.

Bản cập nhật sẽ thêm tính năng Ủy quyền Đầy đủ Thực thi Ranh giới Rừng cho Kerberos vào các hệ thống sau:

• Windows Server 2008 R2
• Windows Server 2008

14/5/2019

Bản cập nhật đã được phát hành thêm cấu hình mặc định an toàn mới vào rừng mới và tin cậy bên ngoài. Nếu bạn yêu cầu ủy quyền xuyên các quỹ tín thác, cờ EnableTGTDelegation nên được đặt thành Yes trước khi cài đặt bản cập nhật 09/07/2019. Nếu bạn không yêu cầu ủy quyền giữa các quỹ tín thác, bạn không nên đặt cờ EnableTGTDelegation . Cờ EnableTGTDelegation sẽ bị bỏ qua cho đến khi bản cập nhật ngày 9 tháng 7 năm 2019 được cài đặt để cho người quản trị thời gian bật lại ủy quyền Kerberos không bị ràng buộc khi được yêu cầu.

Là một phần của bản cập nhật này, cờ EnableTGTDelegation sẽ được đặt thành No theo mặc định cho bất kỳ tin cậy mới được tạo nào. Điều này ngược lại với hành vi trước đó. Thay vào đó, chúng tôi khuyên người quản trị nên đặt cấu hình lại các dịch vụ bị ảnh hưởng để sử dụng ủy quyền hạn chế dựa trên tài nguyên.

Để biết thêm thông tin về cách phát hiện vấn đề tương thích, hãy xem Tìm các dịch vụ dựa trên ủy quyền không ràng buộc.

9/07/2019

Bản cập nhật đã được phát hành nhằm thực thi hành vi mặc định mới ở phía đến của rừng và tin cậy bên ngoài. Yêu cầu xác thực cho các dịch vụ sử dụng ủy quyền không ràng buộc đối với các loại tin cậy được liệt kê sẽ được xác thực nhưng không có ủy quyền. Dịch vụ sẽ thất bại khi cố gắng chạy các thao tác đại diện.

Để biết cách giảm thiểu, hãy xem phần "Giải pháp thay thế".

Tìm các dịch vụ dựa trên ủy quyền không ràng buộc

Để quét các rừng có các tin cậy đến cho phép ủy quyền TGT và tìm bất kỳ tài khoản bảo mật chính nào cho phép ủy quyền không bị ràng buộc, hãy chạy các tập lệnh PowerShell sau trong một tệp tập lệnh (ví dụ: 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 
}

Đầu ra của các tập lệnh PowerShell liệt kê các mã chính bảo mật Active Directory trong các miền được đặt cấu hình cho một tin cậy đến từ miền thực thi đã đặt cấu hình cho ủy quyền không ràng buộc. Đầu ra sẽ giống như ví dụ sau đây.

Phát hiện ủy quyền không ràng buộc thông qua các sự kiện Windows

Khi phiếu Kerberos được phát hành, bộ kiểm soát miền Active Directory sẽ ghi nhật ký các sự kiện bảo mật sau đây. Các sự kiện này chứa thông tin về miền đích. Bạn có thể sử dụng các sự kiện để xác định xem ủy quyền không ràng buộc có được sử dụng trên các quỹ tín thác đến hay không.

Khắc phục sự cố các lỗi xác thực

Khi tắt tính năng ủy quyền không ràng buộc, các ứng dụng có thể gặp vấn đề về tính tương thích với những thay đổi này nếu các ứng dụng dựa vào ủy quyền không ràng buộc. Các ứng dụng này nên được cấu hình để sử dụng ủy quyền ràng buộc hoặc ủy quyền ràng buộc dựa trên tài nguyên. Để biết thêm thông tin, hãy xem Tổng quan về Đại diện Hạn chế Kerberos.

Các ứng dụng dựa vào xác thực khứ hồi giữa các quỹ tín nhiệm không được hỗ trợ bằng cách sử dụng ủy quyền hạn chế. Ví dụ: ủy quyền không thành công nếu người dùng trong Rừng A xác thực với một ứng dụng trong Rừng B và ứng dụng trong Rừng B đang cố gắng ủy quyền một phiếu trở lại Rừng A.