Все знают, что все контроллеры домена равны, но некоторые равнее. Эти особенные контроллеры называются мастерами операций или FSMO Masters. Держатели этих ролей требуют отдельного внимания — вам нужно планировать, как передавать их и когда их захватывать, если что-то пошло не так. Если вы поддерживаете Active Directory домен и что-то из сказанного выше для вас новость, то настоятельно рекомендую ознакомиться со статьёй по ссылке, которую я привёл, либо почитать об этом в любом другом месте.
Тем не менее, есть одна роль, которая выделяется из всех — RID Master. Я несколько раз видел, как люди забывали о тех дополнительных действиях, которые требуются при работе с этой ролью, и у меня появилось желание рассказать, о чём стоит помнить, когда вы восстанавливаете свою Active Directory среду из резервной копии или захватываете роль RID Master.
Если вы хотите вспомнить или, тем более, не знаете, что такое rIDAvailablePool и инвалидация диапазона RID, то добро пожаловать под кат.
Для начала, давайте вспомним, зачем нам, вообще, нужен RID Master и каких нериятностей он помогает нам избегать.
Идентификатор безопасности (SID) каждого объекта в домене имеет вид — Domain SID-RID. Где уникальность относительного идентификатора (RID), гарантирует уникальность SID объекта в рамках домена. Если бы каждый контроллер генерировал RID самостоятельно, то сложно было бы придумать понятный и простой механизм обеспечения их уникальности. Если сделать один контроллер ответственным за генерацию RID при каждом создании объекта (по аналогии с мастерами схемы и именования доменов), то потеряется главный плюс мультимастер системы Active Directory — возможность распределённого хранения и изменения данных. Поэтому в домене есть RID Master, который выделяет каждому контроллеру блоки RID и, в результате каждый контроллер может создавать новые SID для объектов (ведь блок выдан ему в единоличное пользование) и при этом, если RID Master будет выключен или сломан, то система продолжит работу, ведь размер блока позволяет Active Directory какое-то время функционировать и без активного мастера.
Чем же так страшно получить несколько объектов с одинаковым SID? Чтобы ответить на этот вопрос, обратим внимание, как работают списки контроля доступа (ACL) и локальные группы на доменных серверах и рабочих станциях. И те и другие раздают пользователям права на основе их SID а не имени (именно поэтому иногда вы можете увидеть SID в графических оснастках — система просто не смогла разрешить его в приятное для вас имя и показывает как есть).
То есть, если представить, что в вашей среде оказались два, допустим пользователя, с одним SID, то они получат одни и те же права. Причём, что самое неприятное, если администраторы в двух разных частях вашего домена попытаются давать этим двум пользователям права на различные ресурсы, то права будут выданы на этот самый совпадающий SID и не будет никакой возможности, в последствии, определить кому они предназначались. В общем, это очень неприятно и такого допускать нельзя, с чем успешно и справляется RID Master.
Всё хорошо ровно до тех пор пока мы не попытаемся восстановить RID Master из резервной копии. Здесь нужно сделать отступление. Восстанавливать контроллеры из резервной копии не нужно. В случае проблем с контроллером правильным будет удалить его из домена, переставить сервер начисто и заново ввести его в домен в роли контроллера. Однако, есть сценарии, где резервная копия — ваш единственный выбор. Например, если вся ваша AD DS инфраструктура была уничтожена и вам надо её восстановить. Что же может пойти не так?
RID Master хранит данные роли в системном объекте DOMAIN\System\RID Manager$:
Атрибуты этого объекта позволяют узнать, например, кто является текущим RID Master в вашем домене. Нас же интересует атрибут rIDAvailablePool:
Именно здесь хранится информация о том, какой блок выдавался последним и сколько еще RID осталось в вашем домене. Проблема в том, что если ваша AD инфраструктура была восстановлена из резервной копии, значение этого атрибута окажется устаревшим. При этом членство в локальных группах на серверах или в приложениях задается SIDом пользователей и групп. То есть если оставить всё как есть, то новые объекты будут получать права старых. Чтобы этого избежать, нам придётся вручную изменить величину rIDAvailablePool. Если вы обратили внимание, то на предыдущем скриншоте он имеет странное очень большое значение. Дело в том, что эта величина хранится в формате large integer и включает и верхнюю и нижнюю границы диапазона. Для просмотра можно воспользоваться любым инструментом для работы с верхней и нижней частями large integer величин. Например, Large Integer Converter в ldp в разделе Utilities:
Если мы хотим обезопасить себя от конфликтов, то нижнюю часть нужно поменять, прибавив к ней число, заведомо большее чем могло быть создано объектов в домене после снятия этой резервной копии. Для этого уже никакие специальные утилиты не нужны — сколько вы хотите прибавить к нижней части, столько вы прибавляете к атрибуту, в целом.
Теперь, наш новый мастер будет выдавать диапазоны RID начиная с нового значения. Обезопасили ли мы себя от конфликтов? Нет.
Несмотря на то, что мы гарантировали, что новые диапазоны RID будут выданы верно, у нас всё еще осталась одна проблема — наш восстановленный контроллер домена, на момент снятия резервной копии, уже имел свой собственный диапазон. Этот диапазон никуда не делся после восстановления и может доставить нам неприятности, если будет использован.
Для того, чтобы этого избежать нам нужно провести операцию "инвалидации" (если кто-то встречал или знает более подходящее русское слово, то озвучьте его, пожалуйста, в комментариях). Для этого мы воспользуемся скриптом iRIDPool.vbs, предлагаемым Microsoft. Создаем этот скрипт на нашем контроллере и выполняем с правами администратора. Microsoft любезно предупреждает нас, что каждый раз, когда мы проводим такую операцию мы сокращаем число теоретически доступных нам в домене RID, так как инвалидированные идентификаторы уже не смогут быть использованы.
Вот теперь мы в безопасности и можем продолжать восстановление нашей среды после того, что у нас случилось (для AD, например, дальше имеет смысл очистить метаданные и ввести в домен новые контроллеры и т.д.).
Надеюсь, статья помогла вам узнать или освежить в памяти, почему, из всех FSMO ролей, именно RID мастер требует к себе особого внимания.
Тем не менее, есть одна роль, которая выделяется из всех — RID Master. Я несколько раз видел, как люди забывали о тех дополнительных действиях, которые требуются при работе с этой ролью, и у меня появилось желание рассказать, о чём стоит помнить, когда вы восстанавливаете свою Active Directory среду из резервной копии или захватываете роль RID Master.
Если вы хотите вспомнить или, тем более, не знаете, что такое rIDAvailablePool и инвалидация диапазона RID, то добро пожаловать под кат.
RID Master
Для начала, давайте вспомним, зачем нам, вообще, нужен RID Master и каких нериятностей он помогает нам избегать.
Идентификатор безопасности (SID) каждого объекта в домене имеет вид — Domain SID-RID. Где уникальность относительного идентификатора (RID), гарантирует уникальность SID объекта в рамках домена. Если бы каждый контроллер генерировал RID самостоятельно, то сложно было бы придумать понятный и простой механизм обеспечения их уникальности. Если сделать один контроллер ответственным за генерацию RID при каждом создании объекта (по аналогии с мастерами схемы и именования доменов), то потеряется главный плюс мультимастер системы Active Directory — возможность распределённого хранения и изменения данных. Поэтому в домене есть RID Master, который выделяет каждому контроллеру блоки RID и, в результате каждый контроллер может создавать новые SID для объектов (ведь блок выдан ему в единоличное пользование) и при этом, если RID Master будет выключен или сломан, то система продолжит работу, ведь размер блока позволяет Active Directory какое-то время функционировать и без активного мастера.
Чем же так страшно получить несколько объектов с одинаковым SID? Чтобы ответить на этот вопрос, обратим внимание, как работают списки контроля доступа (ACL) и локальные группы на доменных серверах и рабочих станциях. И те и другие раздают пользователям права на основе их SID а не имени (именно поэтому иногда вы можете увидеть SID в графических оснастках — система просто не смогла разрешить его в приятное для вас имя и показывает как есть).
То есть, если представить, что в вашей среде оказались два, допустим пользователя, с одним SID, то они получат одни и те же права. Причём, что самое неприятное, если администраторы в двух разных частях вашего домена попытаются давать этим двум пользователям права на различные ресурсы, то права будут выданы на этот самый совпадающий SID и не будет никакой возможности, в последствии, определить кому они предназначались. В общем, это очень неприятно и такого допускать нельзя, с чем успешно и справляется RID Master.
Атрибут rIDAvailablePool
Всё хорошо ровно до тех пор пока мы не попытаемся восстановить RID Master из резервной копии. Здесь нужно сделать отступление. Восстанавливать контроллеры из резервной копии не нужно. В случае проблем с контроллером правильным будет удалить его из домена, переставить сервер начисто и заново ввести его в домен в роли контроллера. Однако, есть сценарии, где резервная копия — ваш единственный выбор. Например, если вся ваша AD DS инфраструктура была уничтожена и вам надо её восстановить. Что же может пойти не так?
RID Master хранит данные роли в системном объекте DOMAIN\System\RID Manager$:
Атрибуты этого объекта позволяют узнать, например, кто является текущим RID Master в вашем домене. Нас же интересует атрибут rIDAvailablePool:
Именно здесь хранится информация о том, какой блок выдавался последним и сколько еще RID осталось в вашем домене. Проблема в том, что если ваша AD инфраструктура была восстановлена из резервной копии, значение этого атрибута окажется устаревшим. При этом членство в локальных группах на серверах или в приложениях задается SIDом пользователей и групп. То есть если оставить всё как есть, то новые объекты будут получать права старых. Чтобы этого избежать, нам придётся вручную изменить величину rIDAvailablePool. Если вы обратили внимание, то на предыдущем скриншоте он имеет странное очень большое значение. Дело в том, что эта величина хранится в формате large integer и включает и верхнюю и нижнюю границы диапазона. Для просмотра можно воспользоваться любым инструментом для работы с верхней и нижней частями large integer величин. Например, Large Integer Converter в ldp в разделе Utilities:
Если мы хотим обезопасить себя от конфликтов, то нижнюю часть нужно поменять, прибавив к ней число, заведомо большее чем могло быть создано объектов в домене после снятия этой резервной копии. Для этого уже никакие специальные утилиты не нужны — сколько вы хотите прибавить к нижней части, столько вы прибавляете к атрибуту, в целом.
Теперь, наш новый мастер будет выдавать диапазоны RID начиная с нового значения. Обезопасили ли мы себя от конфликтов? Нет.
Инвалидация диапазона RID
Несмотря на то, что мы гарантировали, что новые диапазоны RID будут выданы верно, у нас всё еще осталась одна проблема — наш восстановленный контроллер домена, на момент снятия резервной копии, уже имел свой собственный диапазон. Этот диапазон никуда не делся после восстановления и может доставить нам неприятности, если будет использован.
Для того, чтобы этого избежать нам нужно провести операцию "инвалидации" (если кто-то встречал или знает более подходящее русское слово, то озвучьте его, пожалуйста, в комментариях). Для этого мы воспользуемся скриптом iRIDPool.vbs, предлагаемым Microsoft. Создаем этот скрипт на нашем контроллере и выполняем с правами администратора. Microsoft любезно предупреждает нас, что каждый раз, когда мы проводим такую операцию мы сокращаем число теоретически доступных нам в домене RID, так как инвалидированные идентификаторы уже не смогут быть использованы.
Вот теперь мы в безопасности и можем продолжать восстановление нашей среды после того, что у нас случилось (для AD, например, дальше имеет смысл очистить метаданные и ввести в домен новые контроллеры и т.д.).
Надеюсь, статья помогла вам узнать или освежить в памяти, почему, из всех FSMO ролей, именно RID мастер требует к себе особого внимания.