KB5040758: Изтриване на остарял, повреден или осиротял обект на доверие в Active Directory

Въведение

Обектите, които се съхраняват в Active Directory, може да станат остарели, повредени или осиротели поради конфликти при репликация.

Тази статия се фокусира върху надеждни обекти, които могат да бъдат идентифицирани с бита "INTERDOMAIN_TRUST_ACCOUNT" в атрибута userAccountControl . За подробна информация за този бит вижте userAccountControl Битове.

Симптоми

Взаимоотношенията с гарантите се представят в Active Directory по следния начин:

• Потребителски акаунт, закрепен от завършващ $ знак.

• Надежден обект на домейн (TDO), съхранен в системния контейнер на дяла на указателя на домейна.

Създаването на дублирани гаранти ще създаде два обекта, които имат дублирани имена на акаунти в Security Account Manager (SAM). На втория обект SAM решава конфликта, като преименува обекта на $DUPLICATE<Account RID>. Дублираният обект не може да бъде изтрит и става "осиротял".

Има два основни неактуални сценария за доверяване:

• Сценарий 1: Доверяване на потребителя в състояние на конфликт

  Потребител с гарант може да се наложи да бъде изтрит в сценарии, при които има две гори и преди това е създадено доверие между домейни в тези гори. При първоначалното създаване на гаранта възникна проблем, който не позволяваше репликация. Администратор може да е прехвърлил или иззел ролята на първичен домейнов контролер (PDC) Flexible Single Master Operation (FSMO) и да е създал доверие отново на друг домейнов контролер (DC).

  По-късно, когато репликацията на Active Directory бъде установила отново, двамата потребители на доверие ще репликират на един и същ DC, което води до конфликт при именуване. На обекта на потребителя с гарант ще бъде назначен конфликт (CNF)-mangled DN; Например:

  CN=contoso$\0ACNF:a6e22a25-f60c-4f07-b629-64720c6d8b08,CN=Users,DC=northwindsales,DC=com

  SamAccountName също така ще изглежда с един поглед:

  $DUPLICATE 3159f

  Обектът без конфликта на имената ще изглежда нормален и да функционира правилно. Възможно е да премахнете и да създадете отново доверието.

• Сценарий 2: Безстоверен потребител

  По същия начин, както в сценарий 1, може да се наложи да редактирате или изтриете надежден потребител, ако партньорът за сигурност и доверие вече не съществуват, но потребителят на доверие все още е в базата данни на Active Directory. Обикновено паролата за тези акаунти ще бъде стара, което води до маркиране на този акаунт с флаг от инструментите за сканиране на защитата.

Съобщения за грешка, когато администратор се опитва да редактира атрибутите на доверие

Не е възможно да промените атрибутите на ключа или да изтриете нестаирания потребителски обект на доверие. Следната грешка се дава след опит за промяна на атрибутите, които защитават обекта:

Диалогов прозорец "Грешка"	Съобщение за грешка
	Неуспешна операция. Код на грешка: 0x209a Достъпът до атрибута не е разрешен, защото атрибутът е собственост на Security Accounts Manager (SAM). 0000209A: SvcErr: DSID-031A1021, проблем 5003 (WILL_NOT_PERFORM), данни 0

Когато администратор се опита да премахне обекта, той не успява с грешка 0x5, което е еквивалентно на "Отказан достъп". Или конфликтният обект с гарант може да не се покаже в конзолната добавка "Домейни и гаранти" на Active Directory.

Диалогов прозорец "Грешка"	Съобщение за грешка
	Неуспешна операция. Код на грешка: 0x5 Достъпът е отказан. 00000005:SecErr:DSID-031A11ED,проблем 4003 (INSUFF_ACCESS_RIGHTS), данни 0.

Причина

Този проблем възниква, защото надеждни обекти са собственост на системата и могат да бъдат променяни или изтривани само от администратори, които използват MMC за домейни и гаранти на Active Directory. Тази функционалност е замисъл.

„Разделителна способност”

След инсталирането на актуализациите на Windows от 14 май 2024 г. на домейнови контролери, работещи с Windows Server 2019 или по-нова версия на Windows Server, сега е възможно да изтриете осиротелите акаунти на доверие с помощта на операцията schemaUpgradeInProgress. За да направите това, следвайте тези стъпки:

1. Идентифицирайте осиротял потребителски акаунт за доверие във вашия домейн. Например този резултат от LDP.exe; показва флаг userAccountControl на 0x800 , който идентифицира потребителя на доверие:

   Разгъване база ' CN=northwindsales$,CN=Потребители,DC=contoso,DC=com'...
   Получаване на 1 записа:
   Dn: CN=northwindsales$,CN=Users,DC=contoso,DC=com
   …

   primaryGroupID: 513 = ( GROUP_RID_USERS );
   pwdLastSet: 27.4.2013 10:03:05 PM Координирано универсално време;
   sAMAccountName: NORTHWINDSALES$;
   sAMAccountType: 805306370 = ( TRUST_ACCOUNT );
   userAccountControl: 0x820 = ( PASSWD_NOTREQD | INTERDOMAIN_TRUST_ACCOUNT )
   ;…

2. Ако е необходимо, добавете акаунт на администратор на домейн от остарял домейн за акаунти на доверие към групата "Администратори на схеми" в главния домейн на гората. (Акаунтът, използван за изтриване, трябва да има достъп за управление "Control-Schema-Master" направо в корена на репликата на схемата NC И трябва да може да влиза в DC, който държи осиротял акаунт.)

3. Уверете се, че от 14 май 2024 г. или по-нови актуализации на Windows са инсталирани на записваем DC в остарял домейн за акаунти с доверие.

4. Влезте в този DC с акаунт на администратор на схема. Ако сте добавили акаунт към групата "Администратори на схеми" в стъпка 2, използвайте този акаунт.

5. Подгответе файл за импортиране на LDIFDE , за да модифицирате SchemaUpgradeInProgress и да изтриете обекта.
   
   Например текстът по-долу може да бъде поставен във файл за импортиране LDIFDE, за да се изтрие обектът, идентифициран в стъпка 1:

   dn:
   changetype: modify
   add: SchemaUpgradeInProgress
   SchemaUpgradeInProgress: 1
   -

   dn: CN=northwindsales$,CN=Users,DC=contoso,DC=com
   changetype: delete

   Съвети за синтаксиса на LDIFDE:

   • Линията само с тире ("-") е жизненоважна, тъй като прекратява последователността от промени под типа промяна "модифициране".

   • Празният ред след реда с тирето също е жизненоважен, тъй като показва LDIFDE, че всички модификации на обекта са завършени и промените трябва да бъдат извършени.

6. Импортиране на LDIFDE файла с помощта на следния синтаксис:

   ldifde /i /f nameOfLDIFFileCreatedInStep5.txt /j

   Бележки

   • Параметърът /i показва операция за импортиране.

   • Параметърът /f, последван от име на файл, показва файла, съдържащ промените.

   • Параметърът /j, последван от път в logfile, ще запише ldif.log и файл ldif.err с резултатите от актуализацията, дали процедурата е работила, и ако не, грешката, възникнала по време на мод.

   • Задаване на точка (".") с параметъра /j ще запише регистрационните файлове в текущата работна директория.

7. Ако е необходимо, премахнете администратора на домейна, който преди това е добавен в стъпка 2, от групата "Администратори на схеми".