Практически каждый администратор, работающий с доменными службами Active Directory, знает о существовании мастеров операций, обозначаемых аббревиатурой FSMO. Кроме того, всем известно, что существуют две роли мастеров операций уровня леса (мастер схемы и мастер именования доменов), а также три роли мастеров операций уровня домена (мастер относительных идентификаторов RID, эмулятор главного контроллера домена PDC и мастер инфраструктуры).

Полагаю, большинство системных администраторов знают и о том, что роль мастера RID используется для управления пулом идентификаторов RID с целью создания идентификаторов безопасности (SID) и отвечает за перемещение объектов из одного домена в другой. Таким образом, мастер операций RID отвечает за поддержку пула относительных идентификаторов и предоставление групп относительных идентификаторов каждому контроллеру домена. В этой статье я планирую рассказать о том, что собой представляют эти относительные идентификаторы, чем фактически отличается относительный идентификатор (RID) от идентификатора безопасности (SID), а также о том, как можно управлять пулом RID.

Прежде чем давать определение относительным идентификаторам, вспомним, что такое объекты идентификации. Объекты идентификации — это представления сущностей, выполняющих какие-либо действия в сети. Получается, что компьютеры или группы, которые выполняют различные операции, должны быть представлены объектами идентификации. А перед тем как рассматривать назначение относительных идентификаторов, следует вкратце обозначить, что собой представляют идентификаторы безопасности, которые, естественно, тесно связаны с идентификаторами RID.

Идентификатор безопасности SID

Идентификатор безопасности security identifier (SID) — это уникальное значение переменной длины, которое используется для идентификации принципала или группы безопасности. Например, идентификаторы безопасности используются в токенах доступа. Как это выглядит? В токене доступа один SID будет идентифицировать пользователя, а все его дополнительные идентификаторы безопасности должны идентифицировать группы безопасности, к которым принадлежит этот пользователь. Скажем, чтобы выявить на компьютере идентификатор безопасности для учетной записи пользователя, вы можете в окне командной строки выполнить команду wmic useraccount get name, sid (соответственно для просмотра SID групп выполните команду wmic group get name, sid) либо в редакторе системного реестра следует перейти к разделу HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList. Здесь вы также можете обнаружить идентификатор безопасности для своей учетной записи (см. рисунок 1).

 

Поиск идентификатора безопасности для локальной учетной записи пользователя
Рисунок 1. Поиск идентификатора безопасности для локальной учетной записи пользователя

 

Учтите, что для учетных записей пользователей или групп идентифицирующие их SID являются уникальными. Поэтому в случае как с локальными, так и с доменными учетными записями пользователей или групп вы не найдете одинаковых идентификаторов безопасности, даже если речь идет об удаленных объектах. Более того, SID, созданные в одном домене предприятия, никогда не совпадут с идентификаторами безопасности, созданными в другом домене. Таким образом, даже если пользователь, которому был назначен определенный идентификатор безопасности, уволился с работы и его учетная запись была удалена, а потом он решил вернуться, то при повторном создании его учетной записи будет сгенерирован новый идентификатор SID.

Кроме того, SID используются в дескрипторах безопасности и в элементах управления доступом. В случае с дескрипторами безопасности один SID будет идентифицировать самого владельца объекта, а другой — основную группу, к которой принадлежит этот владелец объекта. А в случае с элементами управления доступом, access control entries (ACE), каждый такой элемент будет включать в себя идентификатор безопасности, связанный с пользователем либо с группой, для которой доступ будет либо разрешен, либо, наоборот, запрещен.

Во время создания учетной записи пользователя или группы операционной системой также генерируется идентификатор безопасности, который в свою очередь будет идентифицировать данную учетную запись. Для локальных учетных записей идентификаторы безопасности создаются на компьютере при помощи локальной системы безопасности (LSA) и сохраняются в защищенной области системного реестра. В случае с объектами Active Directory SID создаются службой безопасности домена и хранятся в Active Directory в качестве атрибутов User или Group.

Как же выглядят идентификаторы безопасности? Если рассматривать структуру идентификаторов безопасности, то можно обнаружить, что SID являются структурированными данными, представленными в двоичном формате, и включают некоторое количество значений. По сути, сам SID можно рассматривать как очень длинный идентификатор для учетной записи пользователя. Сначала указываются значения, определяющие структуру идентификатора безопасности, а затем в иерархическом порядке идут данные, определяющие службу выдачи SID, домен, выдавший идентификатор безопасности, а также группу безопасности. Рассмотрим эти значения более подробно на примере SID, показанного на рисунке 2.

S-1-5-21-705789055-1138749243-
   1717242729-1108

 

Разбивка идентификатора безопасности на составляющие
Рисунок 2. Разбивка идентификатора безопасности на составляющие

 

Здесь мы можем выделить следующие значения.

  • Литеральный префикс с ревизией. Буква S называется литеральным префиксом; она указывает на то, что данная строка является идентификатором SID. Следующее значение, называемое ревизией, определяет версию структуры идентификатора безопасности, используемую в конкретном SID. Во всех идентификаторах безопасности, созданных в Windows NT и всех последующих версиях Windows, уровень ревизии представляет собой 1. Поэтому каждый SID начинается с S-1.
  • Служба идентификаторов. Далее следует шестибайтовое значение, которое называется службой идентификаторов (identifier authority). Данное значение представляет собой наивысший уровень службы, выдающей SID для любого принципала безопасности. Как правило, значение службы безопасности для учетных записей пользователей или групп, созданных в операционных системах, начиная с Windows NT, равняется 5, то есть это NT Authority.
  • Части идентификатора безопасности subauthority. Эта часть SID является наиболее важной и интересной. Как правило, в этой части идентификатора безопасности можно найти несколько таких значений subauthority, которые в свою очередь идентифицируют домен организации. Эту часть также принято называть идентификатором домена Domain Identifier. Получается, что идентификатор домена представляет собой серию значений subauthority из sub1-subn, как правило состоящую из первого значения 21, которое является корневым значением последующих subauthority. За ним следует 96-разрядное случайное число, которое делится на три блока по 32 разряда. Польза от этой части идентификатора безопасности особенно заметна тогда, когда в лесу организации создано несколько доменов. Идентификатор домена SID, выданного одним доменом, обязательно будет отличаться от идентификатора домена SID, выданного другим доменом. Иными словами, в организации не может быть одинаковых идентификаторов домена для разных доменов. Скажем, в данном примере идентификатором домена является значение S-1-5-21-705789055-1138749243-1717242729. Для того чтобы получить идентификатор безопасности домена, вы можете в командной строке PowerShell выполнить следующую команду:
import-module activedirectory
(Get-ADDomain).DomainSID.value;
  • Относительный идентификатор RID. Последнее 32-разрядное значение идентификатора безопасности олицетворяет определенную доменную учетную запись пользователя или группы. Вот это значение и называется относительным идентификатором. О нем я расскажу подробнее немного ниже, а сейчас лишь отмечу, что именно благодаря относительному идентификатору можно отличить одну учетную запись или группу от всех остальных в домене. Учтите, что невозможно найти две учетные записи, имеющие один и тот же относительный идентификатор в рамках одного домена. Например, в данном случае для учетной записи DCAdmin назначен относительный идентификатор 1108.

Условно SID можно разбить следующим образом:

S-1-<служба идентификаторов>-
   --…--

Обратите внимание на то, что на каждом компьютере, входящем как в состав домена, так и в обычную рабочую группу, в операционных системах Windows, начиная с Windows NT, присутствуют группы, входящие в определенный домен Builtin. К таким группам можно отнести локальные группы «Администраторы» или, скажем, «Операторы архива». Ввиду того что такие группы имеют локальную область действия исключительно в рамках учетных записей одного компьютера, на всех компьютерах они должны быть идентичны. Следовательно, у встроенных учетных записей пользователей и групп всегда должно быть одинаковое значение идентификатора домена. Это значение 32, и оно подразумевает встроенный домен. А для того чтобы встроенные учетные записи и группы операционная система могла отличать друг от друга в рамках локального компьютера и встроенного домена, идентификатору безопасности каждой учетной записи и группы назначается уникальный относительный идентификатор.

Таким образом, в операционных системах Windows относительные идентификаторы RID до значения 1000 считаются зарезервированными системой. Например, всем локальным учетным записям из встроенных групп администраторов назначаются RID в диапазоне от 500 до 599. А для новых учетных записей пользователей и групп уже назначаются RID начиная с 1001-го. Например, идентификатор безопасности для локальной группы «Администраторы Hyper-V» выглядит так: S-1-5-32-578.

Если смотреть на идентификаторы безопасности с точки зрения управления доступом к ресурсам, то операционная система Windows не делает каких-то различий между тем, назначался ли SID группе или учетной записи пользователя. Обратите внимание на то, что последующее изменение имени пользователя, его компьютера или даже домена не изменит базовый SID для такой учетной записи. Более того, для этой учетной записи даже администратор не сможет изменить SID. Как правило, администраторы даже и не знают идентификаторов безопасности пользователей, так как для них в этом нет необходимости. По сути, идентификаторы безопасности в основном предназначены для внутренней работы операционной системы и, как уже отмечалось выше, отвечают за обеспечение уникальной идентификации учетных записей в домене.

Если вы захотите просмотреть идентификатор SID для учетной записи в домене Active Directory, потребуется локализовать атрибут objectSid, значением которого является сгенерированный для выбранной вами учетной записи идентификатор безопасности или атрибут sIDHistory, представляющий собой SID, который был сохранен на старых доменах.

Изучаем RID

С идентификаторами безопасности мы разобрались, теперь можно перей­ти к определению и назначению относительных идентификаторов Relative Identifier (RID).

Как мы выяснили, относительные идентификаторы являются частью идентификаторов безопасности, определяющей учетные записи пользователей или групп и позволяющей гарантировать их уникальность. Кроме того, я упоминал о RID, зарезервированных операционной системой Windows. Как вы понимаете, относительные идентификаторы могут быть созданы двумя способами: на локальном компьютере, который входит в рабочую группу, и в доменном окружении. Как именно генерируются RID?

В случае с локальными учетными записями пользователей или групп процесс генерации относительных идентификаторов довольно прозрачный и не должен вызывать каких-либо вопросов. На компьютерах, входящих в рабочую группу, все учетные записи (как пользователей, так и групп) хранятся в базе данных учетных записей, которая в свою очередь управляется диспетчером учетных записей безопасности Security Accounts Manager (SAM). Ввиду небольшого количества учетных записей и отсутствия необходимости их репликации на другие компьютеры, диспетчеру SAM не составит труда отследить все когда-либо существовавшие на данном компьютере значения относительных идентификаторов и создать новые идентификаторы, которые никогда не использовались.

В свою очередь, в доменном окружении картина несколько иная и сам процесс генерации идентификаторов RID является более сложной и трудоемкой процедурой. Как мы знаем, все учетные записи пользователей и групп в доменном окружении хранятся в базе данных на контроллере домена Active Directory. Как правило, в каждом домене размещают несколько контроллеров домена и каждый такой контроллер обязательно должен хранить у себя актуальную базу данных. Также следует помнить о том, что на каждом контроллере домена база данных учетных записей считается не дополнительной, а основной копией. Следовательно, новые учетные записи пользователей или групп могут быть созданы на любом контроллере домена в рамках своего домена. Сразу после этого информация о новой учетной записи должна реплицироваться на каждый контроллер домена в текущем домене. Так как же должны создаваться идентификаторы RID?

В Active Directory за процесс создания относительных идентификаторов RID отвечает мастер операций уровня домена, «Мастер относительных идентификаторов RID» (RID Master). Такой мастер операций назначается лишь для одного контроллера домена, и его основной задачей считается распределение последовательности относительных идентификаторов для каждого контроллера в домене. Получается, что когда на контроллере домена будет создана новая учетная запись, этот контроллер домена назначит для нее идентификатор SID, а уже для этого SID относительный идентификатор RID будет взят из пула выданных этому контроллеру домена относительных идентификаторов. Ввиду того что на данном контроллере домена размещены уникальные RID, после репликации учетной записи на остальные контроллеры домена конфликтов с назначенным относительным идентификатором не возникнет.

Каждый контроллер домена, на котором создавались учетные записи, гарантирует, что после использования уникального относительного идентификатора из своего пула он впредь никогда не назначит для другой учетной записи этот же идентификатор RID. Мастер операций RID в свою очередь гарантирует, что после назначения определенного блока относительных идентификаторов он больше никому эти значения не выделит. Таким образом в домене реализуется согласованность относительных идентификаторов, и каждая учетная запись будет обладать своим уникальным идентификатором RID и, как следствие, идентификатором SID.

Мастер операций RID может использовать 31-разрядное глобальное пространство RID и обладать 2 млрд значений относительных идентификаторов (это 231, то есть 2 147 483 647). В операционных системах, предшествующих Windows Server 2012, размер глобального пространства RID был ограничен 230 (то есть 1 073 741 823) идентификаторами RID. При достижении этого предела создание новых идентификаторов безопасности было возможным только после миграции домена или восстановления всего леса Active Directory.

Когда на контроллере домена, создающего учетные записи, источник RID иссякает, такой контроллер домена отправляет запрос мастеру RID на получение другого блока относительных идентификаторов. По умолчанию контроллерам домена Active Directory выделяется блок с 500 относительными идентификаторами RID, но это значение может быть увеличено, о чем речь пойдет ниже. Таким образом, можно просчитать количество выделенных идентификаторов RID. Например, если в вашей организации развернуто пять контроллеров домена, то им сразу будет выделено 2500 относительных идентификаторов.

Теперь, в качестве итога данного раздела статьи, исходя из всего сказанного выше, давайте определим, чем же отличается идентификатор безопасности от относительных идентификаторов:

  • если SID предназначен для идентификации учетной записи пользователя или группы, RID является лишь фрагментом идентификатора безопасности, отвечающим за уникальность самого SID для всего домена;
  • идентификатор безопасности может быть сгенерирован на любом контроллере домена во время создания самого объекта, а относительные идентификаторы во избежание конфликтов во время репликации выдаются блоками каждому контроллеру домена мастером RID;
  • ввиду того что каждый контроллер домена обладает ограниченным уникальным блоком RID, сгенерированные идентификаторы безопасности никогда не повторяются и после удаления и повторного создания учетной записи не будут использоваться повторно;
  • каждый контроллер домена обладает базой данных учетных записей, и каждая такая база данных считается основной.

Управление относительными идентификаторами

Теперь, после того как мы рассмотрели определение и назначение идентификаторов безопасности (SID) и относительных идентификаторов (RID), можно перейти к основным операциям, выполняемым с относительными идентификаторами. Операций по управлению RID не так уж и много, поэтому для удобства можно разбить их на следующие категории:

  • проверка доступных RID в домене;
  • ограничение на размер блока относительных идентификаторов;
  • управление верхним порогом RID;
  • разблокирование пула относительных идентификаторов RID.

Рассмотрим каждую из операций по порядку.

Проверка доступных RID в домене

Операция, связанная с проверкой доступных относительных идентификаторов RID, может выполняться в разных случаях. Возможно, вы новый администратор Active Directory и хотите узнать, сколько было выдано идентификаторов RID и сколько еще может выдать домен. Возможно, вам нужно проверить, был ли в домене разблокирован 31-й разряд для увеличения глобального пула до 2 млрд идентификаторов RID. Причины могут быть разные. Данное значение расположено в атрибуте SidCompatibilityVersion в контексте RootDSE каждого контроллера домена. Однако этот атрибут является скрытым, и вы не сможете просмотреть его значение при помощи такого инструмента, как LDP, или средствами редактора ADSIEdit. Для этого вам следует воспользоваться возможностями командной строки.

Вы можете ввести команду DCDiag.exe с параметрами /TEST: RidManager и /v. В этом случае будут выведены следующие данные:

  • доступный пул RID для вашего домена;
  • наименование хозяина операций RID;
  • доступность сервера;
  • диапазон всех доступных пулов относительных идентификаторов;
  • диапазон предыдущего пула идентификаторов RID;
  • следующий RID, который будет выдан.

Если вам нужно узнать только доступный пул относительных идентификаторов, то необходимости в остальной информации нет. Для того чтобы ограничить вывод команды лишь одной строкой, нужно задействовать дополнительный параметр find/i «Available RID Pool for the Domain», который следует указать после конвейера. Таким образом, у вас должна получиться такая команда (рисунок 3):

DCDiag.exe/TEST: RidManager/v |
   find/i “Available RID Pool for the Domain”

 

Просмотр доступных идентификаторов RID
Рисунок 3. Просмотр доступных идентификаторов RID

 

Если же вы стараетесь для выполнения различных операций полностью перейти на Windows PowerShell и не хотите прибегать к возможностям командной строки, стоит воспользоваться сценарием, написанным Брэдом Рутковски, или же подготовить такой сценарий самостоятельно. Пример подобного сценария приведен в листинге.

Ограничение на размер блока относительных идентификаторов

Как уже отмечалось, по умолчанию мастер относительных идентификаторов RID выделяет каждому контроллеру домена блоки по 500 идентификаторов. В принципе, в большинстве случаев этого количества достаточно и его можно не менять. Однако вам может понадобиться увеличить размер блока. Для этого следует внести изменения на каждом контроллере внутри вашего домена. Перейдите в редактор реестра и в разделе HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\RID Values измените значение параметра RID Block Size типа DWORD.

Учтите, что с некоторых пор (если говорить точнее, то с выходом Windows Server 2012) для этого параметра запрещено указывать произвольное значение. Почему так? Раньше единственным ограничением было предельное значение для типа DWORD, то есть 0xffffffff, что соответствует 4 294 967 295. Как мы видим, данное значение в два раза превышает общий глобальный размер пространства относительных идентификаторов (причем с учетом разблокированного пула). Следовательно, можно было назначить такой размер блока, что при добавлении нового контроллера домена мастер RID попросту не смог бы назначить ему блок относительных идентификаторов. Теперь же такую оплошность допустить уже не получится. Начиная с Windows Server 2012 максимальным пороговым значением данного параметра является 15 000 в десятичной системе счисления. Если вы попробуете ввести значение, превышающее пороговое, контроллер домена все равно его перезапишет в виде максимальных 15 000.

Если вы хотите сразу предопределить значения данного параметра реестра на всех контроллерах домена, рекомендую воспользоваться возможностями групповой политики. Для этого в редакторе управления групповыми политиками сгенерируйте новый объект GPO, который будет привязан к подразделению Domain Controllers, и в оснастке редактора управления групповыми политиками создайте элемент предпочтения реестра, где в качестве значений для параметров укажите соответствующую ветвь реестра, раздел реестра и указанный выше параметр. В качестве его значения, например, можно указать 0x3A98 (что в десятичной системе счисления будет релевантно 15 000). Диалоговое окно данного элемента предпочтения показано на рисунке 4.

 

Изменение размера блока относительных идентификаторов при помощи групповой политики
Рисунок 4. Изменение размера блока относительных идентификаторов при помощи групповой политики

Управление верхним порогом RID

Во избежание проблем, связанных с выдачей контроллерами домена относительных идентификаторов, в Active Directory предусмотрено пороговое значение для глобального пространства относительных идентификаторов. Работает это следующим образом.

В доменных службах Active Directory по умолчанию установлено пороговое значение в размере 10% оставшегося доступного глобального пространства относительных идентификаторов. Иначе говоря, когда мастер RID выдаст 90% всех своих относительных идентификаторов (по умолчанию он должен выдать 230 — 1 × 0,90 = 966 367 640 RID или же, в случае с разблокированным 31-разрядным пространством, 1 932 735 282 относительных идентификатора), он перестанет выделять контроллерам доменов блоки RID до тех пор, пока верхний порог не будет переопределен. В это же время в журнале событий (в журнале System от источника Directory-Services-SAM) будет сгенерировано событие с идентификатором 16 657. Более того, мастер относительных идентификаторов назначит для атрибута msDS-RIDPoolAllocationEnabled значение FALSE.

Однако, несмотря на все это, контроллеры домена смогут продолжить назначать новым объектам относительные идентификаторы. Когда значение в очередной раз дойдет до 10%, будет сгенерировано еще одно событие. Таким образом, в случае с 30 разрядами может быть создано 110 событий, а в случае с 31 разрядом — 117. Последнее событие будет сгенерировано тогда, когда у мастера RID останется для выдачи лишь 100 000 RID. После данного этапа контроллеры доменов смогут сгенерировать сколько угодно объектов, пока их блоки идентификаторов RID не иссякнут.

До этого момента, когда у мастера RID останется 1% относительных идентификаторов до порогового значения, на всех контроллерах доменов в журнале Directory-Services-SAM будет сгенерировано событие 16 656, сигнализирующее системному администратору о том, что пора принимать какие-то меры, пока еще есть такая возможность.

В случае необходимости вы можете снять блокировку выдачи идентификаторов RID после превышения порогового значения, тем самым позволив по-прежнему выдавать идентификаторы контроллерам домена. Для этого указанному выше атрибуту присваивается значение TRUE. Однако помните, что, несмотря на то что пороговое значение в дальнейшем не будет применяться, глобальное пространство RID может когда-нибудь закончиться, что приведет к соответствующим последствиям.

Выполните следующие действия:

  1. Перейдите к контроллеру домена, обладающему ролью мастера операций RID, и откройте на нем утилиту LDP.exe с правами администратора. Помните, что на таком контроллере домена должна быть установлена как минимум операционная система Windows Server 2012.
  2. В меню утилиты выберите пункт «Подключение» (Connection), а затем пункт «Подключить» (Connect). В открывшемся диалоговом окне укажите в соответствующем текстовом поле имя мастера RID и нажмите ОК. Далее из этого же раздела меню выберите вариант привязки для текущего пользователя (обратите внимание, что если вы вошли в систему не под учетной записью администратора домена, то в открывшемся диалоговом окне вам придется указать такую учетную запись).
  3. Для того чтобы можно было быстро локализовать искомый контейнер, в меню «Вид» (View) выберите режим «Дерево» (Tree), а в соответствующем текстовом поле укажите контекст именования вашего домена. В моем случае это будет «DC=Biopharmaceutic, DC=local».
  4. Теперь вы в панели навигации можете локализовать искомый объект. В данном случае нам следует развернуть контейнер CN=System, а затем из контекстного меню выбрать пункт изменения объекта CN=RID Manager$.
  5. Находясь в диалоговом окне, в текстовом поле «Атрибут» (Attribute) укажите изменяемый атрибут msDS-RIDPoolAllocationEnabled. В текстовом поле «Значения» (Values) следует указать значение TRUE. Для того чтобы атрибут был изменен, вам нужно в группе «Операция» (Operation) установить переключатель на вариант «Заменить» (Replace), а затем нажать кнопку «Ввод» (Enter). Изменения должны отобразиться в поле списка значений. Далее убедитесь в том, что вы установили флажки напротив вариантов «Синхронно» и «Расширенный» (Synchronous и Extended), а затем нажмите кнопку «Выполнить» (Run). Как показано на рисунке 5, в области вывода информации должен появиться следующий текст:
***Call Modify…
ldap_modify_ext_s
   (ld, 'CN=RID Manager$, CN=System,
    DC=Biopharmaceutic, DC=local',
   [1] attrs, SvrCtrls, ClntCtrls);
Modified "CN=RID Manager$,
   CN=System, DC=Biopharmaceutic,
   DC=local ".

 

Снятие блокировки верхнего порога RID
Рисунок 5. Снятие блокировки верхнего порога RID

Это означает, что все действия выполнены удачно.

Разблокировка пула относительных идентификаторов RID

Последняя рассматриваемая в этой статье операция связана с разблокировкой пула относительных идентификаторов. Как уже упоминалось, по умолчанию в доменах Active Directory на мастере относительных идентификаторов RID установлено глобальное пространство RID в размере 230 идентификаторов. Начиная с Windows Server 2012 у вас появилась возможность при необходимости расширить размер глобального пространства RID путем разблокировки 31-го разряда. Как было сказано выше, в таком случае для вас станут доступными 2 147 483 648 относительных идентификаторов.

Однако, перед тем как разблокировать этот разряд, обратите внимание на то, что даже в такой компании, как Microsoft (по данным официального источника), использовано немногим больше чем 8 млн идентификаторов RID. Следовательно, как показывает практика, в большинстве случаев вам не придется выполнять перечисленные ниже действия. Поэтому перед выполнениями этих действий в рабочей среде я порекомендовал бы вам для начала проверить, сколько идентификаторов RID уже было выдано в вашей организации. Также учтите, что, единожды разблокировав 31-й разряд, вы уже не сможете отменить эти действия, и в качестве единственного возможного варианта отмены изменений вам придется выполнить восстановление из резервных копий, что явно может причинить ряд неудобств.

Для выполнения операции разблокирования вам придется изменить значение атрибута SidCompatibilityVersion, который изначально вы не сможете найти стандартными средствами. Для его изменения, как и в предыдущем случае, будет использоваться утилита LDP.exe.

Итак, для выполнения операции разблокирования пула относительных идентификаторов произведите следующие действия:

  1. Откройте утилиту LDP.exe с правами администратора, подключитесь к серверу, мастеру операций RID, и выполните привязку к учетной записи с соответствующими административными правами.
  2. Не выбирая какие-либо контейнеры и объекты, разверните меню «Обзор» (Browse) и выберите вариант изменения.
  3. В уже знакомом по предыдущему подразделу диалоговом окне укажите в соответствующем текстовом поле имя атрибута SidCompatibilityVersion. Так как в данном примере выполняется разблокировка 31-го разряда, в качестве значения для данного атрибута будет указано 1. В отличие от предыдущего примера, вносимые нами изменения будут не заменять значения существующего атрибута, а добавлять новый. Следовательно, в группе режимов нужно установить переключатель на вариант «Добавить» (Add), а затем нажать кнопку «Ввод» (Enter). Убедитесь, что вносимые изменения были добавлены в список записей, а затем, по аналогии с предыдущим примером, установите флажки на вариантах «Синхронно» и «Расширенный» (Synchronous и Extended) и выполняйте операцию. Об удачном выполнении действий вы будете проинформированы в области вывода.

Чтобы удостовериться в том, что глобальное пространство относительных идентификаторов было расширено, вы можете перейти в журнал событий и в журнале System отыскать событие Directory-Services-SAM с EventID 16655. Как показано на рисунке 6, в этом событии отражена информация о том, что 31-й разряд был разблокирован.

 

Разблокировка пула относительных идентификаторов RID
Рисунок 6. Разблокировка пула относительных идентификаторов RID

Итак, я вкратце рассказал о выполнении различных задач, связанных с относительными идентификаторами (RID). Была подробно описана структура идентификаторов безопасности SID, а также относительных идентификаторов (напомню, что RID представляет собой часть идентификатора безопасности SID). Кроме того, мы рассмотрели основные операции, которые системный администратор может выполнять с RID. Были описаны два метода проверки доступных RID в домене: при помощи утилиты командной строки и сценария Windows PowerShell. Также вы узнали о том, как можно изменить ограничение на размер блока относительных идентификаторов, установленных по умолчанию, при помощи функциональных возможностей групповой политики. Далее мы рассмотрели процесс снятия блокировки выдачи идентификаторов RID после превышения установленного в домене порогового значения. Не забывайте, что эти действия рекомендуется выполнять лишь в случае крайней необходимости. И наконец, вы узнали о том, как можно разблокировать 31-й разряд глобального пространства пула относительных идентификаторов RID.

Листинг. Сценарий для просмотра доступных идентификаторов RID
function Get-RIDsRemaining   
{
    param ($domainDN)
    $de = [ADSI]”LDAP://CN=RID Manager$,CN=System,$domainDN”
    $return = new-object system.DirectoryServices.DirectorySearcher($de)
    $property= ($return.FindOne()).properties.ridavailablepool
    [int32]$totalSIDS = $($property) / ([math]::Pow(2,32))
    [int64]$temp64val = $totalSIDS * ([math]::Pow(2,32))
    [int32]$currentRIDPoolCount = $($property) - $temp64val
    $ridsremaining = $totalSIDS - $currentRIDPoolCount
    Write-Host “RIDов выдано: $currentRIDPoolCount”
    Write-Host “RIDов осталось: $ridsremaining”
}