Права по минимуму: делегирование в домене без раздачи администраторов

Запрос пришёл от HR-директора, минуя техотдел клиента. Это уже само по себе сигнал.

Суть была проста: кадровик постоянно ходит к системному администратору с просьбой сбросить пароль очередному сотруднику. Сисадмин каждый раз отрывается от дел, кадровик ждёт, оба недовольны. Директор хочет, чтобы кадровик делал это сам. Логично.

Вопрос в том, как это сделать, не выдав кадровику права доменного администратора.

Почему «добавить в Domain Admins» - плохой ответ

Это первое, что приходит в голову и последнее, что стоит делать. Domain Admins - это полный доступ ко всему домену: можно читать чужие почтовые ящики через Exchange, можно заходить на серверы, можно менять права другим пользователям, можно случайно снести групповую политику. Кадровик не планирует ничего из этого - но доступ будет.

Добавление лишнего человека в Domain Admins - это не «дать права на сброс пароля». Это открыть дверь в серверную и повесить ключ на гвоздь у входа, потому что кому-то нужно иногда заходить взять швабру.

Проблема ещё в том, что права администратора имеют свойство размножаться. Сегодня кадровик, завтра - главный бухгалтер, которому нужно что-то своё, послезавтра - руководитель отдела, у которого «срочно». Через год в Domain Admins пять человек, и никто уже не помнит зачем.

Что такое делегирование в Active Directory

Active Directory позволяет передать конкретные полномочия на конкретное подразделение (OU) без выдачи каких-либо глобальных прав. Это называется делегирование управления.

Механика простая: у каждого объекта в AD есть список управления доступом (ACL), точно как у файлов на NTFS. Можно сказать: «пользователь Иванова имеет право на объекты типа User в подразделении OU=Kadry право Reset Password и Change Password». Ничего больше. Иванова не видит другие подразделения, не может менять настройки компьютеров, не может трогать группы.

В Windows 2003 это делается через Delegation of Control Wizard прямо в ADUC - Active Directory Users and Computers. Мастер проведёт за руку: выбрать OU, выбрать пользователя или группу, выбрать задачу из типовых. Для сброса паролей - это буквально один из стандартных вариантов в списке.

Как настроили

У клиента домен уже был нормально структурирован по подразделениям - мы разбирались с этим ещё при миграции с NT4. Все сотрудники лежали по отделам в соответствующих OU. Это важно: делегирование работает по OU, и если пользователи свалены в кучу без структуры, делегировать будет нечего или придётся давать права на весь домен.

Создали отдельную доменную группу - grp-hr-password-reset. Добавили в неё кадровика. Дальше - правой кнопкой на OU=Kadry, Delegate Control, указали группу, выбрали «Reset user passwords and force password change at next logon».

Мастер написал ACL-записи сам. Мы потом проверили через ADSI Edit, что именно туда попало, - убедились, что права ограничены нужным подразделением и нужным типом операции.

На этом, собственно, всё. Кадровик заходит в ADUC, видит только OU=Kadry, щёлкает правой кнопкой на пользователе, выбирает Reset Password. Пароль сброшен. Остальной домен для неё закрыт полностью.

Что получили в итоге

Кадровик сбрасывает пароли сам. Без звонков, без ожидания, без отрыва сисадмина. Это и была исходная задача.

Сисадмин остался единственным Domain Admin. Не полтора, не два с половиной - один. Это важнее, чем кажется.

Кадровик не видит лишнего. Она видит свои объекты и может делать ровно то, для чего её настроили. Случайно снести что-нибудь важное при таких правах физически невозможно.

Права задокументированы и обратимы. Если кадровик уволится или сменится - убираем из группы, и всё. Никаких остаточных доступов, никакого «а, он же ещё в администраторах был, надо убрать».

Отдельно стоит упомянуть момент, который не очевиден: делегирование лучше вешать на группу, а не напрямую на пользователя. Именно потому что люди меняются. Группа grp-hr-password-reset остаётся, состав меняется - ACL трогать не нужно.

Почему это важнее, чем кажется

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

Если кадровик с правами сброса паролей попадёт под фишинг и его учётка скомпрометирована - злоумышленник получит возможность сбрасывать пароли в одном подразделении. Неприятно, но ограниченно. Если в такой ситуации окажется лишний Domain Admin - компрометация всего домена, Exchange, файловых серверов, всего.

Когда мы разбирались с разграничением доступа к конфиденциальным данным, та же логика работала на уровне файловых папок. Здесь - на уровне объектов Active Directory. Инструменты разные, принцип один: у каждого ровно те права, которые нужны для его задачи, и не байтом больше.

Это не делает систему неуязвимой. Но делает взлом или ошибку - ограниченными по масштабу. А это уже очень много.

Практика показывает: большинство инцидентов с правами в домене происходят не из-за внешних атак, а из-за того, что кому-то когда-то дали лишнее «для удобства». Удобство осталось, необходимость прошла, права никто не убрал.