Giới thiệu
Các đối tượng được lưu trữ trong Active Directory có thể trở nên dập tắt, hỏng hoặc mồ côi gây ra bởi các xung đột tái tạo.
Bài viết này tập trung vào các đối tượng tin cậy có thể được xác định bằng bit "INTERDOMAIN_TRUST_ACCOUNT" trong thuộc tính userAccountControl . Để biết thông tin chi tiết về bit này, hãy xem userAccountControl Bits.
Dấu hiệu
Mối quan hệ Tin cậy được thể hiện trong Active Directory bằng cách:
-
Tài khoản người dùng được gắn với ký tự $ở cuối.
-
Đối tượng miền đáng tin cậy (TDO) được lưu trữ trong bộ chứa Hệ thống của phân vùng thư mục miền.
Tạo mục tin cậy trùng lặp sẽ tạo ra hai đối tượng có tên tài khoản người quản lý tài khoản bảo mật trùng lặp (SAM). Trên đối tượng thứ hai, SAM giải quyết xung đột bằng cách đổi tên các đối tượng $DUPLICATE-<tài khoản rid>. Không thể xóa bỏ đối tượng trùng lặp và trở thành "mồ côi".
Lưu ý Một đối tượng Active Directory được cho là "mồ côi" khi đối tượng này đại diện cho một đối tượng con trực tiếp được lưu trữ trong Active Directory có nơi chứa cha mẹ bị thiếu. Thuật ngữ này đôi khi được sử dụng để tham chiếu đến một đối tượng cũ hoặc bị hỏng trong Active Directory mà không thể xóa bỏ bằng cách sử dụng dòng công việc bình thường.
Có hai kịch bản tin cậy tín dụng chính:
-
Kịch bản 1: Tin tưởng người dùng ở trạng thái xung đột
Người dùng tin cậy có thể phải bị xóa trong trường hợp có hai rừng và tin cậy đã được tạo trước đó giữa các miền trong những rừng đó. Khi tin cậy lần đầu tiên được tạo ra, đã có một vấn đề mà ngăn nhân bản. Người quản trị có thể đã chuyển giao hoặc thu giữ vai trò điều khiển miền chính (PDC) Hoạt động Đơn Chính Linh hoạt (FSMO) và tạo lại độ tin cậy trên bộ điều khiển miền khác (DC).
Sau đó, khi nhân bản Active Directory tái thiết lập, hai người dùng tin cậy sẽ nhân rộng đến DC cùng, gây ra một xung đột đặt tên. Đối tượng người dùng tin cậy sẽ được gán một xung đột (CNF)-mangled DN; chẳng hạn:
CN=contoso$\0ACNF:a6e22a25-f60c-4f07-b629-64720c6d8b08,CN=Users,DC=northwindsales,DC=com
SamAccountName cũng sẽ xuất hiện do mangled:
$DUPLICATE-3159f
Đối tượng không có xung đột tên sẽ xuất hiện bình thường và hoạt động bình thường. Có thể loại bỏ và tái tạo độ tin cậy.
-
Kịch bản 2: Tin tưởng người dùng mồ côi
Tương tự như trong Kịch bản 1, có thể cần chỉnh sửa hoặc xóa người dùng tin cậy nếu đối tác tin cậy và tin cậy không còn tồn tại nữa nhưng người dùng tin cậy vẫn nằm trong cơ sở dữ liệu Active Directory. Thông thường, mật khẩu cho các tài khoản này sẽ cũ, khiến tài khoản đó bị gắn cờ bởi các công cụ quét bảo mật.
Thông báo lỗi khi Người quản trị cố gắng chỉnh sửa các thuộc tính của một tin cậy
Không thể thay đổi các thuộc tính chính hoặc xóa đối tượng người dùng tin cậy mồ côi. Lỗi sau đây được đưa ra sau khi cố gắng thay đổi các thuộc tính bảo vệ đối tượng:
Hộp thoại Lỗi |
Thông báo lỗi |
Thao tác không thành công. Mã lỗi: 0x209a 0000209A: SvcErr: DSID-031A1021, sự cố 5003 (WILL_NOT_PERFORM), dữ liệu 0 |
Khi người quản trị tìm cách loại bỏ đối tượng, việc này sẽ không thành công với lỗi 0x5, điều này tương đương với "Quyền truy nhập bị Từ chối". Hoặc đối tượng tin cậy xung đột có thể không xuất hiện trong phần đính kèm "Miền và Tin cậy" của Active Directory.
Hộp thoại Lỗi |
Thông báo lỗi |
Thao tác không thành công. Mã lỗi: 0x5
|
Nguyên nhân
Sự cố này xảy ra vì các đối tượng tin cậy thuộc sở hữu của hệ thống và chỉ người quản trị sử dụng MIỀN và Tin cậy MMC active Directory mới có thể sửa đổi hoặc xóa. Chức năng này là do thiết kế.
Giải pháp
Sau khi cài đặt Bản cập nhật Windows ngày 14 tháng 5 năm 2024 trên bộ kiểm soát miền chạy Windows Server 2019 hoặc phiên bản Windows Server mới hơn, giờ đây bạn có thể xóa các tài khoản tin cậy mồ côi bằng cách sử dụng thao tác lược đồUpgradeInProgress. Để thực hiện điều này, hãy làm theo các bước sau:
-
Xác định tài khoản người dùng tin cậy mồ côi trong tên miền của bạn. Ví dụ: đầu ra này từ LDP.exe; hiển thị cờ userAccountControl0x800 xác định người dùng tin cậy:
Mở rộng cơ sở ' CN=northwindsales$,CN=Người dùng,DC=contoso,DC=com'...
Nhận 1 mục nhập:
Dn: CN=northwindsales$,CN=Users,DC=contoso,DC=com
…primaryGroupID: 513 = ( số GROUP_RID_USERS );
pwdLastSet: 27/04/2013 10:03:05 CH Giờ Quốc tế Phối hợp;
sAMAccountName: NORTHWINDSALES$;
sAMAccountType: 805306370 = ( TRUST_ACCOUNT );
userAccountControl: 0x820 = ( PASSWD_NOTREQD | INTERDOMAIN_TRUST_ACCOUNT )
;… -
Nếu cần, hãy thêm tài khoản người quản trị miền từ miền tài khoản tin cậy đáng tin cậy vào nhóm "Người quản trị Sơ đồ" trong miền gốc rừng. (Tài khoản được sử dụng để xóa phải có quyền truy cập kiểm soát "Control-Schema-Master" quyền truy cập vào gốc của bản sao Schema NC VÀ phải có khả năng đăng nhập vào DC giữ tài khoản mồ côi.)
-
Hãy đảm bảo rằng các bản cập nhật Windows ngày 14 tháng 5 năm 2024 trở lên được cài đặt trên một DC ghi được trong miền tài khoản tin cậy stale.
-
Đăng nhập vào DC đó bằng tài khoản Người quản trị Sơ đồ. Nếu bạn đã thêm tài khoản vào nhóm "Người quản trị Sơ đồ" ở Bước 2, hãy sử dụng tài khoản đó.
-
Chuẩn bị tệp nhập LDIFDE để sửa đổi SchemaUpgradeInProgress và xóa đối tượng.
Ví dụ: văn bản bên dưới có thể được dán vào tệp nhập LDIFDE để xóa đối tượng được xác định ở Bước 1:dn:
changetype: sửa đổi
add: SchemaUpgradeInProgress
SchemaUpgradeInProgress: 1
-dn: CN=northwindsales$,CN=Users,DC=contoso,DC=com
changetype: deleteGợi ý về Cú pháp LDIFDE:
-
Đường chỉ có dấu gạch nối ("-") rất quan trọng, vì nó chấm dứt chuỗi thay đổi dưới kiểu thay đổi "sửa đổi".
-
Dòng trống sau dòng có gạch nối cũng rất quan trọng, vì nó cho thấy LDIFDE rằng tất cả các sửa đổi trên đối tượng đều được hoàn thành và các thay đổi cần được cam kết.
-
-
Nhập tệp LDIFDE bằng cú pháp sau đây:
ldifde /i /f nameOfLDIFFileCreatedInStep5.txt /j
Lưu ý
-
Tham số /i cho biết thao tác nhập.
-
Tham số /f theo sau là tên tệp cho biết tệp có chứa các thay đổi.
-
Tham số /j theo sau là một đường dẫn logfile sẽ viết một ldif.log và một tệp ldif.err với các kết quả của bản cập nhật, cho dù các thủ tục làm việc, và nếu không, lỗi xảy ra trong mod.
-
Xác định dấu chấm (".") với tham số /j sẽ ghi nhật ký trong thư mục làm việc hiện tại.
-
-
Nếu cần, hãy loại bỏ người quản trị miền đã được thêm vào Bước 2 trước đó khỏi nhóm "Người quản trị Sơ đồ".