Как изменить sid учетной записи

Привет, Хабр! Упомянутая в заголовке тема всё ещё порождает множественные дискуссии и недопонимание между системными администраторами. В своей статье я постараюсь ответить на следующие вопросы:

1. Что такое SID и каких он бывает типов?
2. Когда наличие двух и более машин с одинаковыми Machine SID будет порождать проблемы? Или, другими словами, когда всё-таки (не)нужно менять Machine SID?
3. Что такое Sysprep и нужен ли Sysprep для клонирования/развёртывания?

Эти вопросы будут рассмотрены в первую очередь в контексте задачи развёртывания/клонирования множества рабочих станций/серверов из одного мастер-образа в пределах одной компании.

В основу рассуждений была взята популярная статья Марка Руссиновича (доступна также на русском языке), которую довольно часто неправильно интерпретируют (судя по комментариям и «статьям-ответам»), что приводит к неприятным последствиям. Добро пожаловать под кат.

Что такое SID, его типы и чем отличается Machine SID от Domain SID?

В первую очередь, важно различать SID компьютера (Machine SID) и SID домена (Domain SID), которые являются независимыми и используются в разных операциях.

Machine SID и Domain SID состоят из базового SID’а (base SID) и относительного SID’а (Relative SID = RID), который «приклеивается» в конец к базовому. Базовый SID можно рассматривать как сущность, в рамках которой можно определить группы и аккаунты. Машина (компьютер) является сущностью, в рамках которой определяются локальные группы и аккаунты. Каждой машине присваивается machine SID, и SID’ы всех локальных групп и аккаунтов включают в себя этот Machine SID с добавлением RID в конце. Для примера:

Именно SID’ы (а не имена) хранятся в токенах доступа (access tokens) и дескрипторах безопасности (security descriptors), и именно SID’ы используются при проверке возможности доступа к объектам системы Windows (в том числе, например, к файлам).

На машине вне домена используются локальные SID’ы, описанные выше. Соответственно, при соединении с машиной удалённо используется локальная аутентификация, поэтому даже имея 2 или более машин с одинаковым machine SID в одной сети вне домена, проблем с логином и работой внутри системы не будет, т.к. SID’ы в операциях удалённой аутентификации попросту не используются. Единственный случай, в котором возможны проблемы, это полное совпадение имени пользователя и пароля на двух машинах – тогда, например, RDP между ними может глючить.

Когда машина добавляется в домен, в игру вступает новый SID, который генерируется на этапе добавления. Machine SID никуда не девается, так же как и локальные группы, и пользователи. Этот новый SID используется для представления аккаунта машины в рамках домена. Для примера:

Таким образом, машина DEMOSYSTEM теперь имеет два независимых SID’а:

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

• SID аккаунта машины (computer account SID) в рамках домена BIGDOMAIN (вторая строчка во второй таблице).

Увидеть точное значение machine SID можно с помощью утилиты PsGetSid, запустив её без параметров. Второй SID, относящийся к домену, можно увидеть, запустив PsGetSid со следующими параметрами: psgetsid %COMPUTERNAME%$. Соответственно, для примера из таблиц это будет “psgetsid DEMOSYSTEM$«.

Основная суть в том, что SID’ы должны быть уникальны в пределах окружения (authority), к которому они применимы. Другими словами, если машине DEMOSYSTEM присвоен machine SID S-1-5-21-3419697060-3810377854-678604692-1000, то неважно, что у другой машины в той же сети будет идентичный machine SID, т.к. этот SID используется только локально (в пределах машины DEMOSYSTEM). Но в пределах домена BIGDOMAIN computer SID у обоих машин должен быть уникальным для корректной работы в этом домене.

Смена SID при клонировании или развёртывании

В применении к продукту Acronis Snap Deploy 5 (основное предназначение — массовое развёртывание систем из мастер-образа), в котором функциональность смены SID-а присутствовала с самой первой версии, это означает, что мы, как и многие пользователи, ошибочно пошли на поводу у устоявшегося мнения, что менять SID нужно.

Однако исходя из вышесказанного, ничего страшного в развёртывании (или клонировании) машины без изменения Machine SID вовсе нет, в случае если это развёртывание происходит до добавления машины в домен. В противном случае — возникнут проблемы.

Из этого правила есть одно исключение: нельзя клонировать машину, если в дальнейшем роль этого клона планируется повышать (promote) до уровня домена контроллера. В этом случае Machine SID домен контроллера будет совпадать с computer SID в созданном домене, что вызовет проблемы при попытке добавления оригинальной машины (из которой производилось клонирование) в этот домен. Это, очевидно, относится только к серверному семейству Windows.

Проблемы, связанные со сменой SID

Пересмотреть точку зрения на функциональность смены SID нас подтолкнул выпуск новой версии Windows. При первом тестовом развёртывании образа Windows 10 со сменой SID на получившейся машине обнаружилось, что кнопка Start перестала нажиматься (и это оказалось только вершиной «айсберга»). Если же развёртывать тот же образ без смены SID, то такой проблемы не возникает.

Основная причина в том, что эта опция вносит изменения практически во всю файловую систему развёртываемой машины. Изменения вносятся в реестр Windows, в разрешения NTFS (NTFS permissions) для каждого файла, в SID’ы локальных пользователей (так как SID пользователя включает в себя в том числе и machine SID; подробнее тут) и т.д.

В случае с Windows 10 большая часть ключей реестра не могла быть модифицирована («Error code = C0000005. Access violation» и другие ошибки) и, как следствие, наша функция смены SID’а отрабатывала не до конца, что и приводило к

трагической гибели

практически нерабочей копии Windows 10.

Было принято решение убрать эту опцию в случае, если в мастер-образе мы находим Windows 10 (или Windows Server 2016). Решение было принято на основе теоретических выкладок описанных выше плюс, естественно, было подтверждено практикой при тестировании недавно вышедшего обновления Acronis Snap Deploy 5 во множестве комбинаций: с и без переименования машин после развёртывания, с добавлением в домен и рабочую группу, развёртывание из мастер-образов снятых от разных состояний мастер-машины (она была добавлена в домен или рабочую группу в разных тестах) и т.д.

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

Начиная с Windows NT клонирование (развертывание) ОСи с использованием только NewSID никогда не рекомендовалось самим Microsoft. Вместо этого рекомендуется использовать родную утилиту Sysprep (см. KB314828), которая, помимо смены SID’а, также вносит большое число других изменений, и с каждой новой версией Windows их становится только больше. Вот небольшой (неполный) список основных вносимых изменений:

• Удаляется имя машины
• Машина выводится из домена: это нужно для последующего успешного добавления в домен с новым именем
• Удаляются plug-and-play драйвера, что уменьшает риск возникновения проблем с совместимостью на новом «железе»
• Опционально удаляются Windows Event Logs (параметр ‘reseal’)
• Удаляются точки восстановления
• Удаляется профиль локального администратора и этот аккаунт отключается
• Обеспечивается загрузка целевой машины в режим аудита, позволяющий устанавливать дополнительные приложения и драйверы
• Обеспечивается запуск mini-setup при первом запуске для смены имени машины и другой дополнительной конфигурации
• Сбрасывается период активации Windows (сброс возможен до 3 раз)

Таким образом, клонирование/развертывание без использования Sysprep может повлиять (читай «скорее всего, сломает») на функциональность Windows Update, Network Load Balancing, MSDTC, Vista и выше Key Manager Activation (KMS), который завязан на CMID (не путать с Machine SID), также изменяемый Sysprep’ом, и т.д.

Итого

Повторяя TL;DR из начала статьи, основной вывод можно сделать такой: для подготовки образа машины к клонированию/развёртыванию следует использовать sysprep в подавляющем большинстве случаев.

Линки

— Как изменить SID в Windows 7 и Windows Server 2008 R2 с помощью sysprep
— How to View Full Details of All User Accounts in Windows 10
— Миф о дублировании SID компьютера
— Sysprep, Machine SIDs and Other Myths
— The Machine SID Duplication Myth (and Why Sysprep Matters)
— Yes you do need to worry about SIDs when you clone virtual machines – reasserting the ‘myth’
— Why Sysprep is a necessary Windows deployment tool

Спасибо за внимание!

Смена SID при клонировании и массовом развёртывании +19

1. Что такое SID и каких он бывает типов?
2. Когда наличие двух и более машин с одинаковыми Machine SID будет порождать проблемы? Или, другими словами, когда всё-таки (не)нужно менять Machine SID?
3. Что такое Sysprep и нужен ли Sysprep для клонирования/развёртывания?

Эти вопросы будут рассмотрены в первую очередь в контексте задачи развёртывания/клонирования множества рабочих станций/серверов из одного мастер-образа в пределах одной компании.

В основу рассуждений была взята популярная статья Марка Руссиновича (доступна также на русском языке), которую довольно часто неправильно интерпретируют (судя по комментариям и «статьям-ответам»), что приводит к неприятным последствиям. Добро пожаловать под кат.

Что такое SID, его типы и чем отличается Machine SID от Domain SID?

В первую очередь, важно различать SID компьютера (Machine SID) и SID домена (Domain SID), которые являются независимыми и используются в разных операциях.

Machine SID и Domain SID состоят из базового SID’а (base SID) и относительного SID’а (Relative SID = RID), который «приклеивается» в конец к базовому. Базовый SID можно рассматривать как сущность, в рамках которой можно определить группы и аккаунты. Машина (компьютер) является сущностью, в рамках которой определяются локальные группы и аккаунты. Каждой машине присваивается machine SID, и SID’ы всех локальных групп и аккаунтов включают в себя этот Machine SID с добавлением RID в конце. Для примера:

Именно SID’ы (а не имена) хранятся в токенах доступа (access tokens) и дескрипторах безопасности (security descriptors), и именно SID’ы используются при проверке возможности доступа к объектам системы Windows (в том числе, например, к файлам).

На машине вне домена используются локальные SID’ы, описанные выше. Соответственно, при соединении с машиной удалённо используется локальная аутентификация, поэтому даже имея 2 или более машин с одинаковым machine SID в одной сети вне домена, проблем с логином и работой внутри системы не будет, т.к. SID’ы в операциях удалённой аутентификации попросту не используются. Единственный случай, в котором возможны проблемы, это полное совпадение имени пользователя и пароля на двух машинах – тогда, например, RDP между ними может глючить.

Когда машина добавляется в домен, в игру вступает новый SID, который генерируется на этапе добавления. Machine SID никуда не девается, так же как и локальные группы, и пользователи. Этот новый SID используется для представления аккаунта машины в рамках домена. Для примера:

Таким образом, машина DEMOSYSTEM теперь имеет два независимых SID’а:

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

• SID аккаунта машины (computer account SID) в рамках домена BIGDOMAIN (вторая строчка во второй таблице).

Увидеть точное значение machine SID можно с помощью утилиты PsGetSid, запустив её без параметров. Второй SID, относящийся к домену, можно увидеть, запустив PsGetSid со следующими параметрами: psgetsid %COMPUTERNAME%$. Соответственно, для примера из таблиц это будет “psgetsid DEMOSYSTEM$«.

Основная суть в том, что SID’ы должны быть уникальны в пределах окружения (authority), к которому они применимы. Другими словами, если машине DEMOSYSTEM присвоен machine SID S-1-5-21-3419697060-3810377854-678604692-1000, то неважно, что у другой машины в той же сети будет идентичный machine SID, т.к. этот SID используется только локально (в пределах машины DEMOSYSTEM). Но в пределах домена BIGDOMAIN computer SID у обоих машин должен быть уникальным для корректной работы в этом домене.

В применении к продукту Acronis Snap Deploy 5 (основное предназначение — массовое развёртывание систем из мастер-образа), в котором функциональность смены SID-а присутствовала с самой первой версии, это означает, что мы, как и многие пользователи, ошибочно пошли на поводу у устоявшегося мнения, что менять SID нужно.

Однако исходя из вышесказанного, ничего страшного в развёртывании (или клонировании) машины без изменения Machine SID вовсе нет, в случае если это развёртывание происходит до добавления машины в домен. В противном случае — возникнут проблемы.

Из этого правила есть одно исключение: нельзя клонировать машину, если в дальнейшем роль этого клона планируется повышать (promote) до уровня домена контроллера. В этом случае Machine SID домен контроллера будет совпадать с computer SID в созданном домене, что вызовет проблемы при попытке добавления оригинальной машины (из которой производилось клонирование) в этот домен. Это, очевидно, относится только к серверному семейству Windows.

Проблемы, связанные со сменой SID

Пересмотреть точку зрения на функциональность смены SID нас подтолкнул выпуск новой версии Windows. При первом тестовом развёртывании образа Windows 10 со сменой SID на получившейся машине обнаружилось, что кнопка Start перестала нажиматься (и это оказалось только вершиной «айсберга»). Если же развёртывать тот же образ без смены SID, то такой проблемы не возникает.

Основная причина в том, что эта опция вносит изменения практически во всю файловую систему развёртываемой машины. Изменения вносятся в реестр Windows, в разрешения NTFS (NTFS permissions) для каждого файла, в SID’ы локальных пользователей (так как SID пользователя включает в себя в том числе и machine SID; подробнее тут) и т.д.

В случае с Windows 10 большая часть ключей реестра не могла быть модифицирована («Error code = C0000005. Access violation» и другие ошибки) и, как следствие, наша функция смены SID’а отрабатывала не до конца, что и приводило к

трагической гибели

практически нерабочей копии Windows 10.

Было принято решение убрать эту опцию в случае, если в мастер-образе мы находим Windows 10 (или Windows Server 2016). Решение было принято на основе теоретических выкладок описанных выше плюс, естественно, было подтверждено практикой при тестировании недавно вышедшего обновления Acronis Snap Deploy 5 во множестве комбинаций: с и без переименования машин после развёртывания, с добавлением в домен и рабочую группу, развёртывание из мастер-образов снятых от разных состояний мастер-машины (она была добавлена в домен или рабочую группу в разных тестах) и т.д.

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

Начиная с Windows NT клонирование (развертывание) ОСи с использованием только NewSID никогда не рекомендовалось самим Microsoft. Вместо этого рекомендуется использовать родную утилиту Sysprep (см. KB314828), которая, помимо смены SID’а, также вносит большое число других изменений, и с каждой новой версией Windows их становится только больше. Вот небольшой (неполный) список основных вносимых изменений:

• Удаляется имя машины
• Машина выводится из домена: это нужно для последующего успешного добавления в домен с новым именем
• Удаляются plug-and-play драйвера, что уменьшает риск возникновения проблем с совместимостью на новом «железе»
• Опционально удаляются Windows Event Logs (параметр ‘reseal’)
• Удаляются точки восстановления
• Удаляется профиль локального администратора и этот аккаунт отключается
• Обеспечивается загрузка целевой машины в режим аудита, позволяющий устанавливать дополнительные приложения и драйверы
• Обеспечивается запуск mini-setup при первом запуске для смены имени машины и другой дополнительной конфигурации
• Сбрасывается период активации Windows (сброс возможен до 3 раз)

Таким образом, клонирование/развертывание без использования Sysprep может повлиять (читай «скорее всего, сломает») на функциональность Windows Update, Network Load Balancing, MSDTC, Vista и выше Key Manager Activation (KMS), который завязан на CMID (не путать с Machine SID), также изменяемый Sysprep’ом, и т.д.

Итого

Повторяя TL;DR из начала статьи, основной вывод можно сделать такой: для подготовки образа машины к клонированию/развёртыванию следует использовать sysprep в подавляющем большинстве случаев.

Линки

— Как изменить SID в Windows 7 и Windows Server 2008 R2 с помощью sysprep
— How to View Full Details of All User Accounts in Windows 10
— Миф о дублировании SID компьютера
— Sysprep, Machine SIDs and Other Myths
— The Machine SID Duplication Myth (and Why Sysprep Matters)
— Yes you do need to worry about SIDs when you clone virtual machines – reasserting the ‘myth’
— Why Sysprep is a necessary Windows deployment tool

Спасибо за внимание!

Практически каждый администратор, работающий с доменными службами 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_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionProfileList. Здесь вы также можете обнаружить идентификатор безопасности для своей учетной записи (см. рисунок 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”

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

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

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

Как уже отмечалось, по умолчанию мастер относительных идентификаторов RID выделяет каждому контроллеру домена блоки по 500 идентификаторов. В принципе, в большинстве случаев этого количества достаточно и его можно не менять. Однако вам может понадобиться увеличить размер блока. Для этого следует внести изменения на каждом контроллере внутри вашего домена. Перейдите в редактор реестра и в разделе HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesNTDSRID 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 ".

Рисунок 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-й разряд был разблокирован.

Рисунок 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”
}