Особливості відновлення RID Master

Всі знають, що всі контролери домену рівні, але деякі рівніші. Ці особливі контролери називаються майстрами операцій або FSMO Masters. Власники цих ролей потребують окремої уваги — вам потрібно планувати, як передавати їх і коли їх захоплювати, якщо щось пішло не так. Якщо ви підтримуєте Active Directory домен і щось із сказаного вище для вас новина, то настійно рекомендую ознайомитися зі статтею за посиланням, яку я навів, або почитати про це в будь-якому іншому місці.

Тим не менш, є одна роль, яка виділяється з усіх — 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 майстер вимагає до себе особливої уваги.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.