Bỏ qua để tới nội dung chính
Đăng nhập với Microsoft
Đăng nhập hoặc tạo một tài khoản.
Xin chào,
Chọn một tài khoản khác.
Bạn có nhiều tài khoản
Chọn tài khoản bạn muốn đăng nhập.

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

Thao tác không thành công. Mã lỗi: 0x209a
Truy cập vào thuộc tính không được phép vì thuộc tính thuộc tính thuộc sở hữu của Trình quản lý Tài khoản Bảo mật (SAM).

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 được 0x5

Thao tác không thành công. Mã lỗi: 0x5
Quyền truy nhập bị từ chối.


00000005:SecErr:DSID-031A11ED, sự cố 4003 (INSUFF_ACCESS_RIGHTS), dữ liệu 0.

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:

  1. 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 )
    ;…

  2. 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.)

  3. 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.

  4. Đă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 đó.

  5. 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: delete

    Gợ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.

  6. 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.

  7. 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ơ đồ".

Bạn cần thêm trợ giúp?

Bạn muốn xem các tùy chọn khác?

Khám phá các lợi ích của gói đăng ký, xem qua các khóa đào tạo, tìm hiểu cách bảo mật thiết bị của bạn và hơn thế nữa.

Cộng đồng giúp bạn đặt và trả lời các câu hỏi, cung cấp phản hồi và lắng nghe ý kiến từ các chuyên gia có kiến thức phong phú.

Thông tin này có hữu ích không?

Bạn hài lòng đến đâu với chất lượng dịch thuật?
Điều gì ảnh hưởng đến trải nghiệm của bạn?
Khi nhấn gửi, phản hồi của bạn sẽ được sử dụng để cải thiện các sản phẩm và dịch vụ của Microsoft. Người quản trị CNTT của bạn sẽ có thể thu thập dữ liệu này. Điều khoản về quyền riêng tư.

Cảm ơn phản hồi của bạn!

×