Chuyển đổi Kerberos từ RC4 sang AES trong Active Directory: Hướng dẫn CVE-2026-20833 cho IT Helpdesk

Giới thiệu: Tại sao RC4 bị khai tử và bạn cần hành động ngay

Nếu bạn đang quản trị Active Directory hoặc làm việc trong đội ngũ IT Helpdesk, thì đây là thông tin bạn không thể bỏ qua: Microsoft chính thức loại bỏ mã hóa RC4 khỏi giao thức xác thực Kerberos. Quá trình này đã bắt đầu từ bản cập nhật bảo mật ngày 13 tháng 1 năm 2026, và sẽ được thực thi hoàn toàn vào tháng 7 năm 2026.

Nghe có vẻ kỹ thuật phải không? Đúng vậy, nhưng tác động thực tế thì lại rất "đời thường": nếu không chuẩn bị kịp, hệ thống xác thực của tổ chức bạn có thể ngừng hoạt động — người dùng không đăng nhập được, ứng dụng nội bộ bị lỗi, file sharing và Remote Desktop gián đoạn. Tất cả chỉ vì một thuật toán mã hóa cũ kỹ không được cập nhật kịp thời.

Thành thật mà nói, mình đã thấy nhiều tổ chức chủ quan với thay đổi kiểu này — cho đến khi người dùng bắt đầu gọi Helpdesk ào ào vì không đăng nhập được. Đừng để điều đó xảy ra với bạn.

Trong bài viết này, chúng ta sẽ đi qua:

• RC4 là gì và tại sao nó nguy hiểm (đặc biệt với tấn công Kerberoasting)
• Lộ trình 3 giai đoạn của Microsoft (CVE-2026-20833)
• Cách phát hiện tài khoản và dịch vụ còn dùng RC4 bằng PowerShell
• Hướng dẫn di chuyển sang AES từng bước
• Các lỗi thường gặp và cách khắc phục cho đội ngũ Helpdesk
• Checklist chuẩn bị trước deadline tháng 7/2026

Nào, bắt đầu thôi.

RC4 và Kerberos: Nền tảng cần hiểu

Kerberos hoạt động như thế nào?

Kerberos là giao thức xác thực mặc định trong môi trường Active Directory (AD). Khi người dùng đăng nhập vào máy tính gia nhập domain, quá trình xác thực diễn ra qua 3 bước:

1. Authentication Service (AS) Exchange: Máy client gửi yêu cầu đến Key Distribution Center (KDC) trên Domain Controller. KDC xác minh danh tính và cấp Ticket Granting Ticket (TGT).
2. Ticket Granting Service (TGS) Exchange: Khi cần truy cập dịch vụ nào đó (file server, SQL Server chẳng hạn), client dùng TGT để yêu cầu Service Ticket từ KDC.
3. Truy cập dịch vụ: Client trình Service Ticket cho server đích để được cấp quyền.

Trong toàn bộ quy trình này, các ticket được mã hóa bằng một thuật toán — và đây chính là nơi RC4 vs AES tạo ra sự khác biệt lớn về bảo mật.

RC4 là gì và tại sao nó yếu?

RC4 (Rivest Cipher 4) là thuật toán mã hóa dòng (stream cipher) ra đời từ tận năm 1987. Trong Kerberos, biến thể được sử dụng là RC4-HMAC-MD5 (mã loại 0x17). RC4 từng là lựa chọn mặc định vì tính tương thích cao, đặc biệt từ thời Windows 2000/2003.

Nhưng nó có những điểm yếu khá nghiêm trọng:

• Không sử dụng salt: Khi chuyển đổi mật khẩu thành khóa mã hóa, RC4 không thêm giá trị ngẫu nhiên — hai mật khẩu giống nhau luôn tạo ra cùng một hash.
• Không có iterated hashing: Quá trình hash chỉ chạy một lần duy nhất, giúp kẻ tấn công thử hàng triệu mật khẩu mỗi giây.
• Dựa trên NetNTLM hash: Khóa mã hóa RC4 chính là NT hash của mật khẩu, nên bẻ khóa RC4 ticket đồng nghĩa với việc tìm ra mật khẩu tài khoản luôn.

Tấn công Kerberoasting: Mối đe dọa thực sự

Đây là phần mà các sysadmin cần đặc biệt lưu ý. Kerberoasting là kỹ thuật tấn công post-exploitation cực kỳ nguy hiểm trong môi trường AD. Quy trình tấn công diễn ra như sau:

1. Thu thập SPN: Kẻ tấn công sử dụng bất kỳ tài khoản domain user nào để tìm các tài khoản dịch vụ có Service Principal Name (SPN).
2. Yêu cầu Service Ticket: Kẻ tấn công yêu cầu TGS ticket cho các SPN này. Domain Controller cấp ticket mà không kiểm tra người dùng có thực sự cần truy cập dịch vụ hay không — đây là hành vi bình thường theo thiết kế của Kerberos (nghe hơi lạ, nhưng đúng là vậy).
3. Bẻ khóa offline: Ticket nhận được sẽ được mã hóa bằng khóa của service account. Kẻ tấn công trích xuất ticket rồi dùng công cụ như Hashcat hoặc John the Ripper để brute-force mật khẩu.
4. Chiếm quyền: Khi bẻ được mật khẩu — đặc biệt nếu tài khoản đó có đặc quyền cao — kẻ tấn công có thể lateral movement trong mạng, thậm chí lên Domain Admin.

Điểm then chốt ở đây: với mã hóa RC4, tốc độ bẻ khóa nhanh hơn hàng chục lần so với AES. Đó là lý do Microsoft quyết định loại bỏ RC4 hoàn toàn.

AES — Thuật toán thay thế

AES (Advanced Encryption Standard) hỗ trợ hai biến thể trong Kerberos:

• AES128-CTS-HMAC-SHA1-96 (mã loại 0x11)
• AES256-CTS-HMAC-SHA1-96 (mã loại 0x12)

AES sử dụng salt (kết hợp realm name và principal name) cùng 4096 vòng lặp hash, khiến việc bẻ khóa chậm hơn đáng kể. Ngoài ra, AES còn là tiêu chuẩn mã hóa được cả chính phủ Mỹ lẫn quốc tế công nhận cho dữ liệu mật — nói chung là "xịn" hơn RC4 ở mọi khía cạnh.

Lộ trình 3 giai đoạn của Microsoft (CVE-2026-20833)

Microsoft triển khai việc loại bỏ RC4 theo 3 giai đoạn rõ ràng. Hiểu rõ từng giai đoạn sẽ giúp bạn lên kế hoạch chuẩn bị phù hợp.

Giai đoạn 1: Audit Mode (13/01/2026 – tháng 4/2026)

Đây là giai đoạn hiện tại. Bản cập nhật bảo mật ngày 13/01/2026 mang đến:

• 9 sự kiện audit mới (KDCSVC Event ID 201–209) ghi vào System Event Log trên Domain Controller.
• Registry key mới RC4DefaultDisablementPhase cho phép quản trị viên kiểm soát quá trình chuyển đổi.
• Hệ thống chỉ ghi cảnh báo (warning), chưa chặn kết nối RC4 nào cả.

Mục tiêu: Giúp bạn xác định tất cả tài khoản, dịch vụ và thiết bị còn phụ thuộc RC4 trước khi enforcement bắt đầu. Đây là cơ hội vàng để rà soát — đừng bỏ lỡ.

Giai đoạn 2: AES-Only Defaults (tháng 4/2026)

Giai đoạn này bắt đầu "nghiêm túc" hơn:

• Giá trị mặc định DefaultDomainSupportedEncTypes được cập nhật thành 0x18 (chỉ AES128 + AES256).
• Các tài khoản chưa cấu hình msDS-SupportedEncryptionTypes sẽ mặc định sử dụng AES.
• RC4 fallback bị vô hiệu hóa cho các tài khoản này.
• Enforcement tự động kích hoạt trên tất cả Windows Domain Controller.
• Quản trị viên vẫn có thể rollback thủ công nếu cần.

Đây là giai đoạn nguy hiểm nhất: Nếu chưa chuẩn bị, các ứng dụng legacy và service account thiếu AES key sẽ bắt đầu gặp lỗi xác thực. Mình nhấn mạnh — lúc này không phải là lúc để "thử xem có sao không".

Giai đoạn 3: Full Enforcement (tháng 7/2026)

• Registry key RC4DefaultDisablementPhase bị loại bỏ hoàn toàn.
• Chế độ audit bị gỡ bỏ.
• RC4 bị chặn khỏi protocol path — không còn cách rollback.
• AES-SHA1 trở thành tiêu chuẩn bắt buộc.

Nói cách khác: sau mốc này, RC4 "chết" hẳn.

Tóm tắt lộ trình

Giai đoạn	Thời gian	Hành vi	Rollback?
1 — Audit	01/2026 – 04/2026	Ghi cảnh báo, không chặn	Có
2 — AES Default	04/2026	AES mặc định, RC4 bị từ chối cho tài khoản không cấu hình	Có (thủ công)
3 — Enforcement	07/2026	RC4 bị chặn hoàn toàn	Không

Hiểu các sự kiện audit KDCSVC (Event ID 201–209)

Đây có lẽ là phần quan trọng nhất trong giai đoạn chuẩn bị. 9 sự kiện mới này sẽ giúp bạn xác định chính xác những gì cần xử lý.

Bảng chi tiết Event ID

Event ID	Loại	Mô tả	Hành vi ở Phase 2
201	Warning	Client chỉ hỗ trợ RC4; service account không có msDS-SupportedEncryptionTypes	→ Chuyển thành Error 203 (bị chặn)
202	Warning	Service account thiếu AES key; không có msDS-SupportedEncryptionTypes	→ Chuyển thành Error 204 (bị chặn)
203	Error	Client chỉ dùng RC4 bị chặn (enforcement của 201)	Xác thực thất bại
204	Error	Service thiếu AES key bị chặn (enforcement của 202)	Xác thực thất bại
205	Warning	DefaultDomainSupportedEncTypes chứa cipher không an toàn	Tiếp tục cảnh báo (không chặn)
206	Warning	Cấu hình yêu cầu AES-SHA1 nhưng client thiếu AES	→ Chuyển thành Error 208
207	Warning	Service account thiếu AES key dù cấu hình yêu cầu AES	→ Chuyển thành Error 209
208	Error	AES enforced nhưng client không tương thích	Xác thực thất bại
209	Error	AES enforced nhưng service thiếu key	Xác thực thất bại

Cách kiểm tra Event Log

Mở Event Viewer trên Domain Controller, vào Windows Logs → System, lọc theo Source là KDCSVC với Event ID 201–209:

# Truy vấn Event Log bằng PowerShell trên Domain Controller
Get-WinEvent -FilterHashtable @{
    LogName   = 'System'
    Id        = 201, 202, 203, 204, 205, 206, 207, 208, 209
} -MaxEvents 100 | Format-Table TimeCreated, Id, Message -Wrap

Nếu bạn thấy Event ID 201, 202, 206, hoặc 207 — đó là tín hiệu rõ ràng rằng hệ thống còn phụ thuộc RC4. Cần xử lý trước tháng 4/2026.

Phát hiện tài khoản sử dụng RC4 bằng PowerShell

Kiểm tra thuộc tính msDS-SupportedEncryptionTypes

Thuộc tính msDS-SupportedEncryptionTypes (hay gọi tắt là msds-SET) trên mỗi tài khoản AD xác định loại mã hóa được hỗ trợ. Bảng giá trị quan trọng cần nhớ:

Giá trị (Hex)	Giá trị (Decimal)	Mã hóa được hỗ trợ	Đánh giá
0x0 / NULL	0 / không thiết lập	Phụ thuộc vào DefaultDomainSupportedEncTypes	Cần kiểm tra
0x4	4	RC4-HMAC only	Nguy hiểm — xử lý ngay
0x7	7	DES + RC4	Nguy hiểm
0x18	24	AES128 + AES256	An toàn (khuyến nghị)
0x1C	28	RC4 + AES128 + AES256	Chấp nhận được (AES ưu tiên)

Script tìm tất cả tài khoản chỉ dùng RC4

# Tìm tất cả tài khoản user có msDS-SupportedEncryptionTypes chỉ hỗ trợ RC4
Import-Module ActiveDirectory

# Tìm user accounts chỉ dùng RC4 (giá trị 4 = RC4 only)
$rc4OnlyUsers = Get-ADUser -Filter * -Properties "msDS-SupportedEncryptionTypes", "PasswordLastSet", "Enabled" |
    Where-Object {
        $_."msDS-SupportedEncryptionTypes" -eq 4 -or
        $_."msDS-SupportedEncryptionTypes" -eq 7
    } |
    Select-Object SamAccountName, Enabled, PasswordLastSet,
        @{N="EncTypes";E={$_."msDS-SupportedEncryptionTypes"}}

Write-Host "=== User accounts chi dung RC4 ===" -ForegroundColor Red
$rc4OnlyUsers | Format-Table -AutoSize

# Tìm computer accounts
$rc4Computers = Get-ADComputer -Filter * -Properties "msDS-SupportedEncryptionTypes" |
    Where-Object {
        $_."msDS-SupportedEncryptionTypes" -eq 4 -or
        $_."msDS-SupportedEncryptionTypes" -eq 7
    } |
    Select-Object Name, @{N="EncTypes";E={$_."msDS-SupportedEncryptionTypes"}}

Write-Host "`n=== Computer accounts chi dung RC4 ===" -ForegroundColor Red
$rc4Computers | Format-Table -AutoSize

Script tìm tài khoản thiếu AES key

Đây là một "bẫy" mà nhiều admin hay gặp: tài khoản có thể hỗ trợ AES theo cấu hình, nhưng thiếu AES key thực tế vì mật khẩu chưa bao giờ được reset sau khi AES được bật. Tài khoản trông có vẻ OK nhưng sẽ fail ngay khi RC4 bị chặn.

# Tìm service accounts có SPN nhưng thiếu AES key (cần reset password)
$serviceAccounts = Get-ADUser -Filter 'ServicePrincipalName -like "*"' `
    -Properties ServicePrincipalName, "msDS-SupportedEncryptionTypes", PasswordLastSet |
    Select-Object SamAccountName,
        @{N="SPN";E={$_.ServicePrincipalName -join "; "}},
        @{N="EncTypes";E={$_."msDS-SupportedEncryptionTypes"}},
        PasswordLastSet

Write-Host "=== Service accounts co SPN ===" -ForegroundColor Yellow
$serviceAccounts | Format-Table -AutoSize

# Kiem tra AES key co ton tai khong
# Neu PasswordLastSet truoc 2008 hoac khong thay doi tu lau,
# rat co the account thieu AES key
$riskyAccounts = $serviceAccounts | Where-Object {
    $_.PasswordLastSet -lt (Get-Date "2008-01-01") -or
    $_.EncTypes -eq $null -or
    $_.EncTypes -eq 4
}

Write-Host "`n=== Service accounts CAN RESET PASSWORD ===" -ForegroundColor Red
$riskyAccounts | Format-Table -AutoSize

Sử dụng script chính thức từ Microsoft

Microsoft cung cấp hai script PowerShell chính thức trên GitHub repository Kerberos-Crypto:

• List-AccountKeys.ps1: Truy vấn Security Event Log để liệt kê các khóa mã hóa có sẵn cho từng tài khoản.
• Get-KerbEncryptionUsage.ps1: Xác định loại mã hóa Kerberos đang được sử dụng, kèm tùy chọn lọc theo thuật toán.

# Tai script tu Microsoft GitHub
# https://github.com/microsoft/Kerberos-Crypto

# Liet ke encryption keys cua cac accounts
.\List-AccountKeys.ps1

# Kiem tra Kerberos encryption usage
.\Get-KerbEncryptionUsage.ps1

# Loc chi hien thi RC4 usage
.\Get-KerbEncryptionUsage.ps1 -Encryption RC4

Hướng dẫn di chuyển từ RC4 sang AES từng bước

Bước 1: Cập nhật tất cả Domain Controller

Đầu tiên và quan trọng nhất — cài bản cập nhật bảo mật Windows phát hành ngày 13/01/2026 (hoặc sau đó) trên tất cả Domain Controller trong domain. Không có ngoại lệ.

# Kiem tra phien ban OS Build tren Domain Controller
systeminfo | findstr /B /C:"OS Version"

# Hoac bang PowerShell
Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 5

Lưu ý quan trọng: Nếu có DC nào chưa được cập nhật, các sự kiện KDCSVC sẽ xuất hiện không chính xác trên toàn forest. Phải đảm bảo 100% DC đã được vá — thiếu một cái cũng không được.

Bước 2: Bật Audit Mode và giám sát

Thiết lập registry key trên tất cả Domain Controller:

# Bat Audit Mode (Phase 1) tren Domain Controller
$path = 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters'
if (-not (Test-Path $path)) {
    New-Item -Path $path -Force | Out-Null
}
New-ItemProperty -Path $path -Name 'RC4DefaultDisablementPhase' `
    -PropertyType DWord -Value 1 -Force | Out-Null

Write-Host "Da bat Audit Mode. Can restart Domain Controller." -ForegroundColor Green
Write-Host "CANH BAO: Hay restart DC ngoai gio lam viec!" -ForegroundColor Yellow

Sau khi restart, hãy giám sát Event Log trong ít nhất 2–4 tuần. Lý do là vì một số dịch vụ hoặc tài khoản có thể chỉ xác thực định kỳ (hàng tuần, hàng tháng), nên cần đủ thời gian để "bắt" hết.

Bước 3: Xử lý từng loại tài khoản

User accounts thiếu AES key

Với các tài khoản tạo từ trước khi AES được hỗ trợ (trước Windows Server 2003) và chưa bao giờ đổi mật khẩu:

# Reset password cho user account de tao AES key
# QUAN TRONG: Thong bao nguoi dung truoc khi thuc hien!
Set-ADAccountPassword -Identity "ten_tai_khoan" `
    -Reset -NewPassword (ConvertTo-SecureString "MatKhauMoiManh@2026!" -AsPlainText -Force)

# Bat buoc nguoi dung doi mat khau lan dang nhap ke tiep
Set-ADUser -Identity "ten_tai_khoan" -ChangePasswordAtLogon $true

Service accounts

Service account cần được xử lý cẩn thận hơn nhiều — thay đổi mật khẩu sai cách có thể làm sập dịch vụ đang chạy. Quy trình khuyến nghị:

1. Xác định tất cả dịch vụ sử dụng service account đó.
2. Lên lịch maintenance window.
3. Cập nhật msDS-SupportedEncryptionTypes thành 0x18 (AES only) hoặc 0x1C (AES + RC4 tạm thời).
4. Reset mật khẩu service account.
5. Cập nhật mật khẩu mới trên tất cả dịch vụ liên quan.
6. Kiểm tra dịch vụ hoạt động bình thường.

# Cap nhat msDS-SupportedEncryptionTypes cho service account
# Gia tri 24 (0x18) = AES128 + AES256 (khuyen nghi)
# Gia tri 28 (0x1C) = RC4 + AES128 + AES256 (tam thoi, giai doan chuyen tiep)

Set-ADUser -Identity "svc_sqlserver" `
    -Replace @{"msDS-SupportedEncryptionTypes" = 24}

# Xac nhan thay doi
Get-ADUser -Identity "svc_sqlserver" -Properties "msDS-SupportedEncryptionTypes" |
    Select-Object SamAccountName, "msDS-SupportedEncryptionTypes"

Computer accounts

# Cap nhat encryption type cho computer account
Set-ADComputer -Identity "SERVER01" `
    -Replace @{"msDS-SupportedEncryptionTypes" = 24}

# Doi voi nhieu may tinh cung luc
$computers = Get-ADComputer -Filter 'OperatingSystem -like "Windows Server*"' `
    -Properties "msDS-SupportedEncryptionTypes" |
    Where-Object { $_."msDS-SupportedEncryptionTypes" -eq 4 -or $_."msDS-SupportedEncryptionTypes" -eq $null }

foreach ($comp in $computers) {
    Set-ADComputer -Identity $comp.DistinguishedName `
        -Replace @{"msDS-SupportedEncryptionTypes" = 28}
    Write-Host "Da cap nhat: $($comp.Name)" -ForegroundColor Green
}

Bước 4: Cập nhật ứng dụng legacy

Phần này hay bị bỏ quên. Một số ứng dụng cũ (đặc biệt ứng dụng Java) có cấu hình Kerberos riêng trong file krb5.conf hoặc krb5.ini. Cần kiểm tra và cập nhật:

Cấu hình cũ (không an toàn):

[libdefaults]
default_tkt_enctypes = rc4-hmac
default_tgs_enctypes = rc4-hmac
permitted_enctypes = rc4-hmac

Cấu hình mới (an toàn):

[libdefaults]
default_tkt_enctypes = aes256-cts aes128-cts
default_tgs_enctypes = aes256-cts aes128-cts
permitted_enctypes = aes256-cts aes128-cts

Bước 5: Cập nhật DefaultDomainSupportedEncTypes

Trên tất cả Domain Controller, thiết lập giá trị mặc định:

# Thiet lap DefaultDomainSupportedEncTypes tren Domain Controller
# Gia tri 0x18 (24) = chi AES128 + AES256
# Gia tri 0x38 (56) = AES128 + AES256 + AES-SHA256 variants

$regPath = "HKLM:\System\CurrentControlSet\services\KDC"
Set-ItemProperty -Path $regPath -Name "DefaultDomainSupportedEncTypes" `
    -Value 0x18 -Type DWord

Write-Host "Da thiet lap DefaultDomainSupportedEncTypes = 0x18 (AES only)" -ForegroundColor Green
Write-Host "Can restart Domain Controller de ap dung." -ForegroundColor Yellow

Bước 6: Rekey tài khoản KRBTGT

Tài khoản KRBTGT là tài khoản đặc biệt dùng để mã hóa tất cả TGT trong domain. Đây là bước không được bỏ qua:

# Kiem tra encryption types cua KRBTGT
Get-ADUser -Identity "krbtgt" -Properties "msDS-SupportedEncryptionTypes", "PasswordLastSet" |
    Select-Object SamAccountName, "msDS-SupportedEncryptionTypes", PasswordLastSet

# Neu PasswordLastSet qua cu, can reset (CHU Y: reset KRBTGT can thuc hien 2 lan,
# cach nhau it nhat 10 gio de dam bao TGT cu het han)
# CANH BAO: Day la thao tac co rui ro cao - chi thuc hien khi da hieu ro tac dong!

Mình muốn nhấn mạnh: reset KRBTGT là thao tác nhạy cảm. Nếu bạn chưa từng làm, hãy tham khảo tài liệu chính thức của Microsoft và thực hiện ngoài giờ làm việc.

Bước 7: Thử nghiệm Enforcement Mode

Khi đã xử lý hết các cảnh báo, bạn có thể kích hoạt enforcement để mô phỏng Phase 2:

# CANH BAO: Chi thuc hien sau khi da xu ly het Event 201-209!
# Bat Enforcement Mode (mo phong Phase 2)
$path = 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters'
Set-ItemProperty -Path $path -Name 'RC4DefaultDisablementPhase' -Value 2 -Type DWord

Write-Host "Da bat Enforcement Mode. Restart DC va giam sat loi xac thuc." -ForegroundColor Red

Nên thử trên một DC thử nghiệm trước, rồi mới triển khai rộng. Tin mình đi, bạn không muốn phải rollback trên production vào lúc 2 giờ sáng.

Xử lý sự cố thường gặp cho IT Helpdesk

Sự cố 1: Người dùng không đăng nhập được sau khi bật AES enforcement

Triệu chứng: Người dùng nhận thông báo "The encryption type requested is not supported by the KDC" hoặc đơn giản là "Authentication failed".

Nguyên nhân: Tài khoản người dùng hoặc máy tính thiếu AES key.

Giải pháp:

1. Kiểm tra Event ID 4769 trên KDC — tìm Failure Code 0xE (KDC_ERR_ETYPE_NOTSUPP).
2. Kiểm tra msDS-SupportedEncryptionTypes của tài khoản bị ảnh hưởng.
3. Reset mật khẩu để tạo AES key mới.
4. Nếu là computer account, chạy nltest /sc_reset:TenDomain hoặc rejoin domain.

# Kiem tra loi xac thuc Kerberos tren KDC
Get-WinEvent -FilterHashtable @{
    LogName = 'Security'
    Id = 4769
} -MaxEvents 50 | Where-Object {
    $_.Message -match "0xE|0xe"
} | Format-Table TimeCreated, Message -Wrap

Sự cố 2: Ứng dụng nội bộ ngừng hoạt động

Triệu chứng: Ứng dụng web nội bộ, ERP, hoặc phần mềm kế toán báo lỗi kết nối database hoặc xác thực.

Nguyên nhân: Service account chỉ hỗ trợ RC4, hoặc ứng dụng hardcode RC4 trong file cấu hình.

Giải pháp:

1. Xác định service account mà ứng dụng sử dụng.
2. Kiểm tra file cấu hình (krb5.conf, krb5.ini, hoặc registry).
3. Cập nhật msDS-SupportedEncryptionTypes của service account.
4. Reset mật khẩu service account và cập nhật trong ứng dụng.
5. Restart dịch vụ và kiểm tra.

Sự cố 3: Chia sẻ file SMB bị lỗi

Triệu chứng: Người dùng không truy cập được thư mục chia sẻ, nhận lỗi mạng khi mở file server.

Nguyên nhân: Computer account của file server có msDS-SupportedEncryptionTypes = 4 (chỉ RC4).

Giải pháp:

# Kiem tra va cap nhat computer account cua file server
$server = Get-ADComputer -Identity "FILESERVER01" -Properties "msDS-SupportedEncryptionTypes"
Write-Host "Encryption Types hien tai: $($server.'msDS-SupportedEncryptionTypes')"

# Cap nhat sang AES
Set-ADComputer -Identity "FILESERVER01" -Replace @{"msDS-SupportedEncryptionTypes" = 28}

# Restart may hoac chay lenh sau tren file server
klist purge
nltest /sc_reset:TenDomain

Sự cố 4: Remote Desktop / WMI bị từ chối

Triệu chứng: Kết nối Remote Desktop hoặc PowerShell Remoting báo lỗi "WinRM cannot process the request" với mã 0x80090342.

Giải pháp:

1. Kiểm tra bằng klist get HOST/tenserver.domain.com để xác nhận lỗi encryption type.
2. Cập nhật msDS-SupportedEncryptionTypes của computer account máy đích.
3. Nếu cần giải pháp tạm thời, thêm RC4 vào danh sách hỗ trợ (giá trị 0x1C = 28).

# Xac nhan loi tren may client
klist get HOST/server01.contoso.com

# Output mau khi bi loi:
# Error calling API LsaCallAuthenticationPackage: 0x80090342
# klist failed with 0xc00002fd: The encryption type requested is not supported by the KDC.

Sự cố 5: Thiết bị không hỗ trợ AES (legacy devices)

Triệu chứng: Máy in mạng, thiết bị IoT, hoặc server chạy Windows Server 2003 không thể xác thực.

Đây là sự cố "đau đầu" nhất vì đôi khi không có giải pháp lý tưởng:

• Thiết bị phần cứng: Kiểm tra firmware update từ nhà sản xuất. Nếu không hỗ trợ AES, cần lên kế hoạch thay thế.
• Windows Server 2003: Bắt buộc phải nâng cấp — phiên bản này hết hỗ trợ từ lâu rồi và không hỗ trợ AES.
• Giải pháp tạm: Thiết lập msDS-SupportedEncryptionTypes rõ ràng cho tài khoản liên quan (giá trị 0x4). Tuy nhiên, sau Phase 3 (07/2026), cách này sẽ không còn hoạt động.
• Microsoft cung cấp email [email protected] để các tổ chức báo cáo thiết bị bên thứ ba không hỗ trợ AES.

Cấu hình Group Policy cho toàn domain

Để áp dụng chính sách mã hóa Kerberos cho toàn bộ domain, dùng Group Policy:

1. Mở Group Policy Management Console (gpmc.msc).
2. Tạo hoặc chỉnh sửa GPO áp dụng cho OU chứa Domain Controller.
3. Đi tới: Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → Security Options.
4. Tìm policy: Network security: Configure encryption types allowed for Kerberos.
5. Chọn AES128_HMAC_SHA1 và AES256_HMAC_SHA1.
6. Bỏ chọn RC4_HMAC_MD5 (trừ khi vẫn cần hỗ trợ legacy trong giai đoạn chuyển tiếp).
7. Áp dụng GPO và chạy gpupdate /force trên các Domain Controller.

# Kiem tra GPO da duoc ap dung chua
gpresult /r /scope:computer | findstr /i "kerberos"

# Hoac chi tiet hon
gpresult /h C:\Temp\GPReport.html
# Mo file HTML de xem bao cao day du

Checklist chuẩn bị trước deadline tháng 7/2026

Mình tổng hợp lại thành checklist để bạn dễ theo dõi tiến độ. In ra dán lên bàn làm việc cũng được!

Giai đoạn ngay lập tức (tháng 2–3/2026)

• ☐ Cập nhật tất cả Domain Controller với bản vá 01/2026 trở lên
• ☐ Bật Audit Mode (RC4DefaultDisablementPhase = 1)
• ☐ Chạy script phát hiện RC4 usage trên tất cả DC
• ☐ Lập danh sách tất cả tài khoản chỉ dùng RC4
• ☐ Xác định tất cả ứng dụng legacy phụ thuộc RC4
• ☐ Bật Kerberos audit policy: Kerberos Authentication Service và Kerberos Service Ticket Operations

Giai đoạn xử lý (tháng 3–4/2026)

• ☐ Cập nhật msDS-SupportedEncryptionTypes = 0x18 cho tất cả service accounts
• ☐ Reset mật khẩu service accounts để tạo AES key
• ☐ Cập nhật mật khẩu mới trong tất cả dịch vụ liên quan
• ☐ Cập nhật file cấu hình ứng dụng (krb5.conf) sang AES
• ☐ Cập nhật computer accounts cần thiết
• ☐ Yêu cầu người dùng có tài khoản cũ đổi mật khẩu
• ☐ Thiết lập DefaultDomainSupportedEncTypes = 0x18

Giai đoạn kiểm tra (tháng 4–5/2026)

• ☐ Giám sát Event ID 201–209 — mục tiêu: không còn warning nào
• ☐ Bật Enforcement Mode (RC4DefaultDisablementPhase = 2) trên DC thử nghiệm
• ☐ Kiểm tra tất cả ứng dụng quan trọng hoạt động bình thường
• ☐ Kiểm tra SMB, Remote Desktop, WMI, LDAP
• ☐ Kiểm tra đăng nhập workstation và laptop

Giai đoạn hoàn tất (tháng 5–6/2026)

• ☐ Bật Enforcement Mode trên tất cả Domain Controller
• ☐ Rekey tài khoản KRBTGT (2 lần, cách nhau ≥ 10 giờ)
• ☐ Xác nhận không có Event ID 203, 204, 208, 209
• ☐ Lập kế hoạch xử lý cho thiết bị legacy không thể nâng cấp
• ☐ Liên hệ [email protected] nếu có thiết bị bên thứ ba không hỗ trợ AES
• ☐ Tài liệu hóa toàn bộ thay đổi và chia sẻ với đội ngũ Helpdesk

Mẹo cho đội ngũ IT Helpdesk

Tạo Knowledge Base nội bộ

Số lượng ticket liên quan đến xác thực có thể tăng đột biến trong giai đoạn chuyển đổi. Chuẩn bị sớm sẽ giúp bạn không bị "ngập":

• Tạo FAQ nội bộ giải thích lý do thay đổi và cách xử lý cơ bản.
• Tạo template ticket cho các sự cố phổ biến (đăng nhập thất bại, ứng dụng lỗi, file share không truy cập được).
• Thiết lập escalation path rõ ràng: Tier 1 xử lý reset password và kiểm tra cơ bản; Tier 2 cập nhật msDS-SET; Tier 3 (hoặc AD admin) xử lý Group Policy và Domain Controller.

Câu lệnh nhanh cho Helpdesk

# === CAC LENH KIEM TRA NHANH CHO HELPDESK ===

# 1. Kiem tra encryption type cua user account
Get-ADUser -Identity "ten_user" -Properties "msDS-SupportedEncryptionTypes" |
    Select-Object SamAccountName, "msDS-SupportedEncryptionTypes"

# 2. Kiem tra Kerberos ticket hien tai tren may client
klist

# 3. Xoa Kerberos ticket cache (buoc nguoi dung xac thuc lai)
klist purge

# 4. Kiem tra ket noi den dich vu cu the
klist get HOST/server01.contoso.com

# 5. Kiem tra nhanh encryption type cua computer account
Get-ADComputer -Identity "TEN_MAY" -Properties "msDS-SupportedEncryptionTypes" |
    Select-Object Name, "msDS-SupportedEncryptionTypes"

# 6. Reset secure channel giua may client va domain
Test-ComputerSecureChannel -Repair -Verbose

Giao tiếp với người dùng cuối

Khi người dùng gọi Helpdesk vì không đăng nhập được, hãy nhớ 4 bước:

1. Trấn an: "Đây là thay đổi bảo mật bắt buộc của Microsoft, không phải lỗi từ phía bạn."
2. Xác minh: Kiểm tra Event Log trên DC để xác nhận nguyên nhân liên quan đến RC4/AES.
3. Xử lý: Reset mật khẩu (nếu cần) hoặc xóa Kerberos ticket cache bằng klist purge.
4. Theo dõi: Đảm bảo người dùng đăng nhập thành công sau khi xử lý.

Đơn giản vậy thôi, nhưng cách giao tiếp chuyên nghiệp sẽ giúp giảm đáng kể sự lo lắng của người dùng.

Kết luận

Việc Microsoft loại bỏ RC4 khỏi Kerberos không phải điều bất ngờ — đây là bước tiến tất yếu sau nhiều năm cảnh báo. Tuy nhiên, tác động thực tế lên môi trường Active Directory là rất lớn, đặc biệt với các tổ chức có hệ thống legacy phức tạp.

Tin tốt là Microsoft đã thiết kế lộ trình 3 giai đoạn với đầy đủ công cụ audit. Điều quan trọng nhất? Bắt đầu ngay từ bây giờ:

• Cập nhật tất cả Domain Controller.
• Giám sát các sự kiện KDCSVC 201–209.
• Xử lý từng tài khoản và ứng dụng phụ thuộc RC4.
• Kiểm tra bằng Enforcement Mode trước deadline.
• Trang bị kiến thức cho đội ngũ Helpdesk.

Tháng 7/2026 sẽ đến nhanh hơn bạn nghĩ. Đừng để đến lúc đó mới phát hiện rằng 50 service account trong tổ chức vẫn đang chạy RC4. Hành động ngay hôm nay — bạn (và đội Helpdesk) sẽ cảm ơn chính mình vì điều đó.