Использование DsAddSidHistory

Функция DsAddSidHistory получает первичный идентификатор безопасности учетной записи (SID) субъекта безопасности из одного домена (исходного домена) и добавляет его в атрибут sIDHistory субъекта безопасности в другом (целевом) домене в другом лесу. Если исходный домен находится в собственном режиме Windows 2000, эта функция также извлекает значения sIDHistory исходного субъекта и добавляет их в SIDHistory целевого субъекта.

Добавление идентификаторов SID в sIDHistory субъекта безопасности — это операция с учетом безопасности, которая эффективно предоставляет целевому субъекту доступ ко всем ресурсам, доступным исходному субъекту, если доверие существует из применимых доменов ресурсов к целевому домену.

В собственном режиме домен Windows 2000 пользователь войдите в систему, создает маркер доступа, содержащий идентификаторы безопасности основной учетной записи пользователя и групповые идентификаторы безопасности, а также идентификаторы SIDHistory и sIDHistory групп, в которых пользователь является членом. Наличие этих бывших идентификаторов SID (sIDHistory values) в маркере пользователя предоставляет пользователю доступ к ресурсам, защищенным списками управления доступом (ACL), содержащими бывшие идентификаторы SID.

Эта операция упрощает некоторые сценарии развертывания Windows 2000. В частности, он поддерживает сценарий, в котором учетные записи в новом лесу Windows 2000 создаются для пользователей и групп, которые уже существуют в рабочей среде Windows NT 4.0. Поместив идентификатор безопасности учетной записи Windows NT 4.0 в SIDHistory учетной записи Windows 2000, доступ к сетевым ресурсам сохраняется для входа пользователя в новую учетную запись Windows 2000.

DsAddSidHistory также поддерживает перенос серверов ресурсов контроллеров домена резервного копирования Windows NT 4.0 (или DCs и серверов-членов в собственном режиме Windows 2000) в домен Windows 2000 в качестве членов. Для этой миграции требуется создание в целевом домене Windows 2000 локальных групп домена, содержащихся в их SIDHistory, первичные идентификаторы локальных групп, определенных на BDC (или локальные группы домена, на которые ссылаются списки управления доступом на серверах Windows 2000) в исходном домене. Создавая локальную группу назначения, содержащую SIDHistory и все члены исходной локальной группы, доступ к перенесенным ресурсам сервера, защищенным списками управления доступом, ссылающимся на исходную локальную группу, сохраняется для всех участников.

Примечание.

Использование DsAddSidHistory требует понимания его более широких административных и безопасности последствий в этих и других сценариях. Дополнительные сведения см. в техническом документе "Планирование миграции из Windows NT в Microsoft Windows 2000", доставленном как Dommig.doc в средствах поддержки Windows 2000. Эту документацию также можно найти на компакт-диске продукта в разделе \support\tools.

Требования к авторизации

DsAddSidHistory требует прав администратора в исходных и целевых доменах. В частности, вызывающий этот API должен быть членом группы доменных Администратор istrators в целевом домене. Выполняется жестко закодированный проверка для этого членства. Кроме того, учетная запись, указанная в параметре SrcDomainCreds, должна быть членом группы Администратор istrators или доменных Администратор istratorов в исходном домене. Если значение NULL передается в SrcDomainCreds, вызывающий API должен быть членом группы Администратор istrator или доменных Администратор istrators в исходном домене.

Требования к домену и доверию

DsAddSidHistory требует, чтобы целевой домен был в собственном режиме Windows 2000 или более поздней версии, так как только этот тип домена поддерживает атрибут sIDHistory. Исходный домен может быть windows NT 4.0 или Windows 2000, смешанный или собственный режим. Исходные и целевые домены не должны находиться в одном лесу. Домены Windows NT 4.0 по определению не находятся в лесу. Это ограничение между лесами гарантирует, что в одном лесу не создаются повторяющиеся идентификаторы SID или sIDHistory значения.

DsAddSidHistory требует внешнего доверия из исходного домена в целевой домен в случаях, перечисленных в следующей таблице.

Регистр	Description
Исходный домен — Windows 2000.	Исходный атрибут sIDHistory, доступный только в исходных доменах Windows 2000, может быть прочитан только с помощью LDAP, который требует этого доверия для защиты целостности.
Исходный домен — Windows NT 4.0, а SrcDomainCreds — NULL.	Олицетворение, необходимое для поддержки операций исходного домена с использованием учетных данных вызывающего объекта, зависит от этого доверия. Олицетворение также требует, чтобы целевой контроллер домена был включен по умолчанию для контроллеров домена.

Однако между исходными и целевыми доменами нет доверия, если исходный домен — Windows NT 4.0 и SrcDomainCreds не имеет значения NULL.

Требования к исходному контроллеру домена

DsAddSidHistory требует, чтобы контроллер домена, выбранный в качестве целевого объекта для операций в исходном домене, был PDC в доменах Windows NT 4.0 или эмулятором PDC в доменах Windows 2000. Аудит исходного домена создается путем операций записи, поэтому PDC требуется в исходных доменах Windows NT 4.0, а ограничение только для PDC гарантирует, что аудиты DsAddSidHistory создаются на одном компьютере. Это снижает потребность в проверке журналов аудита всех контроллеров домена для мониторинга использования этой операции.

Примечание.

В исходных доменах Windows NT 4.0 PDC (целевой объект операций в исходном домене) должен работать с пакетом обновления 4 (SP4) и более поздним пакетом обновления 4 (SP4), чтобы обеспечить правильную поддержку аудита.

Следующее значение реестра должно быть создано в качестве значения REG_DWORD и присвоено значение 1 на исходном контроллере домена для исходных контроллеров домена Windows NT 4.0 и Windows 2000.

HKEY_LOCAL_MACHINE
   System
      CurrentControlSet
         Control
            Lsa
               TcpipClientSupport

Задание этого значения позволяет вызывать RPC через транспорт TCP. Это необходимо, так как по умолчанию интерфейсы SAMRPC можно использовать только для именованных каналов. Использование именованных каналов приводит к тому, что система управления учетными данными подходит для интерактивного входа пользователей, выполняющих сетевые вызовы, но не является гибким для системного процесса, выполняющего сетевые вызовы с учетными данными, предоставленными пользователем. RPC по протоколу TCP более подходит для этой цели. Установка этого значения не уменьшает системную безопасность. Если это значение создано или изменено, для того чтобы этот параметр вступил в силу, необходимо перезапустить исходный контроллер домена.

Для аудита необходимо создать новую локальную группу SrcDomainName<>}.

Аудит

Операции DsAddSidHistory проверяются, чтобы администраторы исходного и целевого домена могли обнаруживать, когда эта функция запущена. Аудит является обязательным как в исходном, так и в целевом доменах. DsAddSidHistory проверяет, включен ли режим аудита в каждом домене, а аудит управления учетными записями о событиях success/Failure включен. В целевом домене создается уникальное событие аудита "Add Sid History" для каждой успешной или неудачной операции DsAddSidHistory .

Уникальные события аудита "Добавление журнала sid" недоступны в системах Windows NT 4.0. Чтобы создать события аудита, которые однозначно отражают использование DsAddSidHistory в исходном домене, он выполняет операции с специальной группой, имя которой является уникальным идентификатором в журнале аудита. Локальная группа< "SrcDomainName>", имя которой состоит из имени исходного домена NetBIOS, добавленного с тремя знаками доллара ($) (код ASCII = 0x24 и Юникод = U+0024), необходимо создать на исходном контроллере домена перед вызовом DsAddSidHistory. Каждый исходный пользователь и глобальная группа, которая является целью этой операции, добавляется, а затем удаляется из членства в этой группе. Это создает события аудита элемента и удаления участников в исходном домене, которые можно отслеживать путем поиска событий, ссылающихся на имя группы.

Примечание.

Операции DsAddSidHistory с локальными группами в исходном домене Windows NT 4.0 или Windows 2000 с смешанным режимом не могут быть проверены, так как локальные группы не могут быть сделаны членами другой локальной группы и поэтому не могут быть добавлены в специальную локальную< группу SrcDomainName>?. Это отсутствие аудита не представляет проблемы безопасности исходного домена, так как доступ к ресурсам исходного домена не влияет на эту операцию. Добавление идентификатора безопасности исходной локальной группы в целевую локальную группу не предоставляет доступ к исходным ресурсам, защищенным этой локальной группой, для любых дополнительных пользователей. Добавление участников в целевую локальную группу не предоставляет им доступ к исходным ресурсам. Добавленные члены предоставляют доступ только к серверам в целевом домене, перенесенным из исходного домена, которые могут иметь ресурсы, защищенные идентификатором безопасности исходной локальной группы.

Безопасность передачи данных

DsAddSidHistory применяет следующие меры безопасности:

• Вызываемая с рабочей станции Windows 2000 учетные данные вызывающего объекта используются для проверки подлинности и защиты конфиденциальности вызова RPC к целевому контроллеру домена. Если SrcDomainCreds не имеет значения NULL, рабочая станция и целевой контроллер домена должны поддерживать 128-разрядное шифрование для защиты учетных данных в конфиденциальности. Если 128-разрядное шифрование недоступно и предоставляется SrcDomainCreds , вызов должен быть выполнен в целевом контроллере домена.
• Контроллер домена назначения взаимодействует с исходным контроллером домена с помощью SrcDomainCreds или учетных данных вызывающего объекта для взаимной проверки подлинности и целостности, защиты чтения идентификатора безопасности исходной учетной записи (с помощью подстановки SAM) и sIDHistory (с помощью чтения LDAP).

Модели угроз

В следующей таблице перечислены потенциальные угрозы, связанные с вызовом DsAddSidHistory , и рассматриваются меры безопасности, относящиеся к определенной угрозе.

Потенциальная угроза	Мера безопасности
Атака "злоумышленник в середине" Несанкционированный пользователь перехватывает идентификатор безопасности подстановки вызова возврата исходного объекта, заменив идентификатор безопасности исходного объекта произвольным идентификатором безопасности для вставки в целевой объект SIDhistory.	Идентификатор безопасности подстановки исходного объекта — это прошедший проверку подлинности RPC, используя учетные данные администратора вызывающего объекта с защитой целостности пакетов. Это гарантирует, что обратный вызов нельзя изменить без обнаружения. Контроллер домена назначения создает уникальное событие аудита "Добавить журнал sid", которое отражает идентификатор безопасности, добавленный в целевую учетную запись sIDHistory.
Домен источника троянских программ Несанкционированный пользователь создает исходный домен "Троянский конь" в частной сети с одинаковым идентификатором безопасности домена и некоторыми из таких же идентификаторов учетных записей, что и допустимый исходный домен. Затем несанкционированный пользователь пытается запустить DsAddSidHistory в целевом домене, чтобы получить идентификатор безопасности исходной учетной записи. Это делается без необходимости использовать учетные данные реального исходного домена Администратор istrator и не покидая след аудита в реальном исходном домене. Метод несанкционированного пользователя для создания исходного домена Троянского коня может быть одним из следующих: Получите копию (резервную копию BDC) исходного домена SAM. Создайте новый домен, изменив идентификатор безопасности домена на диске, чтобы соответствовать допустимому идентификатору безопасности исходного домена, а затем создайте достаточно пользователей, чтобы создать экземпляр учетной записи с требуемым идентификатором безопасности. Создайте реплика BDC. Для этого требуются учетные данные исходного домена Администратор istrator. Затем несанкционированный пользователь принимает реплика в частную сеть для реализации атаки.	Хотя для несанкционированного пользователя существует множество способов получения или создания требуемого исходного идентификатора безопасности исходного объекта, несанкционированный пользователь не может использовать его для обновления SIDHistory учетной записи, не являясь членом целевой группы доменных Администратор istratorов. Так как проверка на целевом контроллере домена для членства в домене Администратор istrator жестко закодирован, на целевом контроллере домена нет метода изменения диска для изменения данных управления доступом, защищающих эту функцию. Попытка клонировать исходную учетную запись Троянского коня проверяется в целевом домене. Эта атака устраняется путем резервирования членства в группе доменных Администратор istrators только для высоконадежных лиц.
Изменение журнала безопасности на диске Сложный несанкционированный пользователь с учетными данными домена Администратор istrator и физическим доступом к контроллеру домена в целевом домене может изменить значение sIDHistory учетной записи на диске.	Эта попытка не включена с помощью DsAddSidHistory. Эта атака устраняется путем предотвращения физического доступа к контроллерам домена всем, кроме администраторов с высоким уровнем доверия.
Изгойный код, используемый для удаления защиты Несанкционированный пользователь или администратор-изгой с физическим доступом к коду службы каталогов может создать изгойный код, который: Удаляет проверка для членства в группе доменных Администратор istrators в коде. Изменяет вызовы исходного контроллера домена, который указывает идентификатор безопасности на lookupSidFromName, который не проверяется. Удаляет вызовы журнала аудита.	Кто-то с физическим доступом к коду DS и достаточно знаний, чтобы создать код изгоев, имеет возможность произвольного изменения атрибута sIDHistory учетной записи. API DsAddSidHistory не повышает этот риск безопасности.
Ресурсы уязвимы для украденных идентификаторов SID Если несанкционированный пользователь успешно использовал один из методов, описанных здесь, чтобы изменить идентификатор SIDHistory учетной записи, и если домены ресурсов доверяют несанкционированному домену учетной записи, то несанкционированный пользователь может получить несанкционированный доступ к ресурсам украденного идентификатора БЕЗОПАСНОСТИ, потенциально не оставляя след аудита в домене учетной записи, из которого был украден идентификатор безопасности.	Администраторы домена ресурсов защищают свои ресурсы, настраивая только те отношения доверия, которые имеет смысл с точки зрения безопасности. Использование DsAddSidHistory ограничено в доверенном целевом домене для членов группы доменных Администратор istratorов, которые уже имеют широкие разрешения в рамках область своих обязанностей.
Целевой домен rogue Несанкционированный пользователь создает домен Windows 2000 с учетной записью, sIDHistory содержит идентификатор безопасности, украденный из исходного домена. Несанкционированный пользователь использует эту учетную запись для несанкционированного доступа к ресурсам.	Несанкционированный пользователь требует Администратор istrator учетных данных для исходного домена для использования DsAddSidHistory и оставляет путь аудита на исходном контроллере домена. Целевой домен изгоев получает несанкционированный доступ только в других доменах, которым требуется Администратор истатор привилегий в этих доменах ресурсов.

Операционные ограничения

В этом разделе описываются операционные ограничения использования функции DsAddSidHistory.

Идентификатор безопасности SrcPrincipal не должен существовать в целевом лесу либо как идентификатор основной учетной записи, либо в sIDHistory учетной записи. Исключением является то, что DsAddSidHistory не создает ошибку при попытке добавить идентификатор безопасности в sIDHistory, содержащий идентичный идентификатор безопасности. Это поведение позволяет выполнять dsAddSidHistory несколько раз с одинаковыми входными данными, что приводит к успешному выполнению и согласованному состоянию конечного состояния для разработчика инструментов.

Примечание.

Задержка реплика глобального каталога может предоставить окно, в течение которого могут быть созданы повторяющиеся идентификаторы SID. Однако повторяющиеся идентификаторы SID можно легко удалить администратором.

SrcPrincipal и DstPrincipal должны быть одним из следующих типов:

• User

• Группа с поддержкой безопасности, в том числе:

  Локальная группа глобальной группы "Локальный домен" (только в собственном режиме Windows 2000) универсальная группа (только в собственном режиме Windows 2000)

Типы объектов SrcPrincipal и DstPrincipal должны соответствовать.

• Если SrcPrincipal является пользователем, DstPrincipal должен быть пользователем.
• Если SrcPrincipal является локальной или локальной группой домена, DstPrincipal должна быть локальной группой домена.
• Если SrcPrincipal является глобальной или универсальной группой, DstPrincipal должна быть глобальной или универсальной группой.

SrcPrincipal и DstPrincipal не могут быть одним из следующих типов: (DsAddSidHistory завершается ошибкой в этих случаях)

• Компьютер (рабочая станция или контроллер домена)

• Доверие между доменами

• Временная повторяющаяся учетная запись (практически неиспользуемая функция, устаревшая версия LANman)

• Учетные записи с известными идентификаторами SID. Известные идентификаторы безопасности идентичны в каждом домене; Таким образом, добавление их в sIDHistory нарушает требование уникальности безопасности леса Windows 2000. Учетные записи с известными идентификаторами SID включают следующие локальные группы:

  Операторы учетных записей Администратор istrator Backup операторы "Гости печати" операторов репликатора сервера Users

Если SrcPrincipal имеет известный относительный идентификатор (RID) и определенный домен, то есть доменные Администратор istrator, доменные пользователи и доменные компьютеры, то DstPrincipal должен иметь тот же известный RID, чтобы dsAddSidHistory удалось выполнить. Учетные записи с известными идентификаторами RID включают следующих пользователей и глобальных групп:

• Администратор
• Гость
• Администраторы домена
• Гости домена
• пользователи домена;

Установка значения реестра

В следующей процедуре показано, как задать значение реестра TcpipClientSupport.

Установка значения реестра TcpipClientSupport

1. Создайте следующее значение реестра в качестве значения REG_DWORD на исходном контроллере домена и задайте для нее значение 1.

   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\TcpipClientSupport

2. Затем перезапустите исходный контроллер домена. Это значение реестра приводит к тому, что SAM прослушивает TCP/IP. DsAddSidHistory завершится ошибкой, если это значение не задано на исходном контроллере домена.

Включение аудита событий управления пользователями или группами

В следующей процедуре показано, как включить аудит событий управления пользователем или группами в исходном или целевом домене Windows Server 2000 или Windows Server 2003.

Включение аудита событий управления пользователями и группами в исходном или целевом домене Windows Server 2000 или Windows Server 2003

1. В оснастке MMC Пользователи и компьютеры Active Directory выберите контейнер контроллеров домена назначения.
2. Щелкните правой кнопкой мыши контроллеры домена и выберите пункт "Свойства".
3. Перейдите на вкладку групповой политики .
4. Выберите политику контроллеров домена по умолчанию и нажмите кнопку "Изменить".
5. В разделе "Конфигурация компьютера\Windows Параметры\Безопасность Параметры\Локальные политики\Политика аудита" дважды щелкните "Управление учетными записями аудита".
6. В окне "Управление учетными записями аудита" выберите "Успех" и "Сбой аудита". Обновления политики вступили в силу после перезапуска или после обновления.
7. Убедитесь, что аудит включен, просмотрев эффективную политику аудита в оснастке MMC групповой политики.

В следующей процедуре показано, как включить аудит событий управления пользователем или группами в домене Windows NT 4.0.

Включение аудита событий управления пользователем и группами в домене Windows NT 4.0

1. В диспетчере пользователей для доменов щелкните меню "Политики" и выберите "Аудит".
2. Выберите "Аудит этих событий".
3. Для управления пользователями и группами проверка успех и сбой.

В следующей процедуре показано, как включить аудит событий управления пользователем и группами в исходном домене Windows NT 4.0, Windows 2000 или Windows Server 2003.

Включение аудита событий управления пользователем и группами в исходном домене Windows NT 4.0, Windows 2000 или Windows Server 2003

1. В диспетчере пользователей для доменов щелкните меню "Пользователь" и выберите "Создать локальную группу".
2. Введите имя группы, состоящее из имени исходного домена NetBIOS, добавленного с тремя знаками доллара ($), например FABRIKAM}. Поле описания должно указывать, что эта группа используется для аудита использования операций dsAddSidHistory или клонирования. Убедитесь, что в группе нет участников. Щелкните OK.

Операция DsAddSidHistory завершается ошибкой, если аудит источника и назначения не включен, как описано здесь.

Настройка доверия при необходимости

Если одно из следующих значений имеет значение true, необходимо установить доверие из исходного домена в целевой домен (это должно произойти в другом лесу):

• Исходный домен — Windows Server 2003.
• Исходный домен — Windows NT 4.0, а SrcDomainCreds — NULL.