Поделиться через

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

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

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

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

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

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

Заметка

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

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

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

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

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

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

Случай Описание
Исходный домен — 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) или более поздним, чтобы обеспечить правильную поддержку аудита.

Следующее значение реестра должно быть создано в качестве значения 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 проверяет, включен ли режим аудита в каждом домене, а также включен ли аудит управления учетными записями для событий успешного выполнения и сбоя. В целевом домене создается уникальное событие аудита "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, либо учетные данные вызывающей стороны для взаимной проверки подлинности и защиты целостности при чтении SID исходной учетной записи (с помощью поиска SAM) и sIDHistory (с помощью чтения LDAP).

Модели угроз

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

Потенциальная угроза Мера безопасности
Атака посредника
Несанкционированный пользователь перехватывает вызов с идентификатором безопасности поиска для исходного объекта, заменяя его на произвольный идентификатор безопасности для вставки в историю SID целевого объекта.
 Идентификатор безопасности поиска исходного объекта является проверенным RPC, использующим учетные данные администратора вызывающего абонента с защитой целостности сообщений пакетов. Это гарантирует, что обратный вызов нельзя изменить без возможности обнаружения. Контроллер домена назначения создает уникальное событие аудита "Добавить историю SID", отражающее идентификатор безопасности, добавленный в целевую учетную запись sIDHistory.
Домен источника троянских программ
Несанкционированный пользователь создает «Троянский конь» — исходный домен в частной сети с таким же идентификатором безопасности домена и некоторыми идентификаторами учетных записей, как у легитимного исходного домена. Затем несанкционированный пользователь пытается запустить dsAddSidHistory в целевом домене, чтобы получить идентификатор безопасности исходной учетной записи. Это делается без необходимости использовать учетные данные администратора домена реального источника и не оставляя следов аудита в реальном исходном домене. Метод несанкционированного пользователя для создания исходного домена Троянского коня может быть одним из следующих:
  • Получите копию (резервную копию BDC) исходного домена SAM.
  • Создайте новый домен, изменив идентификатор безопасности домена на диске, чтобы соответствовать допустимому идентификатору безопасности исходного домена, а затем создайте достаточно пользователей, чтобы создать экземпляр учетной записи с требуемым идентификатором безопасности.
  • Создайте реплику BDC. Для этого требуются учетные данные администратора домена источника. Затем несанкционированный пользователь принимает реплику в частную сеть для реализации атаки.

 Хотя для несанкционированного пользователя существует множество способов получения или создания требуемого исходного идентификатора безопасности исходного объекта, несанкционированный пользователь не может использовать его для обновления SIDHistory учетной записи, не являясь членом целевой группы администраторов домена. Так как проверка на целевом контроллере домена для членства администратора домена жестко закодирована, на целевом контроллере домена нет метода изменения диска, чтобы изменить данные управления доступом, защищающие эту функцию. Попытка клонировать исходную учетную запись Троянского коня проверяется в целевом домене. Эта атака устраняется путем резервирования членства в группе администраторов домена только для высоконадежных лиц.
Изменение SID History на диске
Опытный несанкционированный пользователь с учетными данными администратора домена и физическим доступом к контроллеру домена в целевом домене может изменить значение sIDHistory учетной записи на диске.
 Эта попытка не разрешена использованием DsAddSidHistory. Эта атака устраняется путем предотвращения физического доступа к контроллерам домена всем, кроме администраторов с высоким уровнем доверия.
Изгойный код, используемый для удаления защиты
Несанкционированный пользователь или администратор-изгой с физическим доступом к коду службы каталогов может создать изгойный код, который:
  1. Удаляет проверку членства в группе администраторов домена в коде.
  2. Изменяет вызовы на исходном контроллере домена, которые указывают идентификатор безопасности для функции LookupSidFromName, которая не контролируется.
  3. Удаляет вызовы журнала аудита.

 Кто-то с физическим доступом к коду DS и обладающий достаточными знаниями для создания вредоносного кода, имеет возможность произвольно изменять атрибут sIDHistory учетной записи. API DsAddSidHistory не повышает этот риск безопасности.
Ресурсы уязвимы для украденных идентификаторов SID
Если несанкционированный пользователь успешно использовал один из способов, описанных здесь, чтобы изменить учетную запись sIDHistory, и если домены ресурсов доверяют несанкционированному домену учетной записи пользователя, то несанкционированный пользователь может получить доступ к ресурсам, связанным с украденным идентификатором безопасности (SID), возможно, не оставляя следов в аудиторских журналах домена учетной записи, из которого был украден идентификатор безопасности.
 Администраторы домена ресурсов защищают свои ресурсы, настраивая только те отношения доверия, которые имеет смысл с точки зрения безопасности. Использование dsAddSidHistory ограничено в доверенном целевом домене для членов группы "Администраторы домена", у которых уже есть широкие разрешения в рамках их обязанностей.
Ненадежный целевой домен
Несанкционированный пользователь создает домен Windows 2000 с учетной записью, sIDHistory содержит идентификатор безопасности, украденный из исходного домена. Несанкционированный пользователь использует эту учетную запись для несанкционированного доступа к ресурсам.
 Несанкционированный пользователь нуждается в учетных данных администратора для исходного домена, чтобы использовать DsAddSidHistoryи оставляет след аудита на исходном контроллере домена. Потенциально нарушающий домен получает несанкционированный доступ только в тех доменах, которые ему доверяют, что требует прав администратора в этих доверяющих доменах ресурсов.

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

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

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

Заметка

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

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

  • Пользователь

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

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

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

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

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

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

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

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

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

    Операторы учетных записей, Администраторы, Операторы резервного копирования, Гости, Операторы печати, Репликатор, Операторы сервера, Пользователи

Если SrcPrincipal имеет известный относительный идентификатор (RID) и доменный префикс, такие как администраторы домена, пользователи домена и компьютеры домена, то 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. В User Manager для доменовщелкните меню Параметры и выберите Проверка.
  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 , или клонирования. Убедитесь, что в группе нет участников. Нажмите кнопку ОК.

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

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

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

  • Исходный домен — Windows Server 2003.
  • Исходный домен — Windows NT 4.0 и SrcDomainCredsNULL.
  • Last updated on