В этой статье я постарался собрать основные организационные и технические правила использования учетных записей администраторов в организации, направленные на повышение безопасности в домене Windows. Использование данных рекомендаций значительно повысит защиту компьютеров домена Active Directory от атак, аналогичных летнему инциденту с шифровальщиком Petya, одной из техник распространения которого между компьютерами домена (помимо уязвимости в SMBv1) был удаленный доступ с помощью полученных из памяти учетных данных администраторов (с помощью утилиты аналогичной Mimikatz). Возможно некоторые из рекомендаций спорные или неприменимые для конкретных случаев, но к ним все-таки нужно стремиться.
Итак, в предыдущей статье мы рассмотрели основные методики защиты от извлечения паролей из памяти с помощью Mimikatz. Однако все эти технические меры могут быть бесполезными, если в домене Windows не применяются базовые правила обеспечения безопасности административных учетных записей.
Основное правило, которым следует пользоваться – максимальное ограничение административных привилегий, как для пользователей, так и администраторов. Нужно стремится к тому, что предоставлять пользователям и группам поддержки только те права, которые необходимы для выполнения повседневных задач.
Базовый список правил:
- Учетные записи администраторов домена/организации должны использоваться только для управления доменом и контроллерами домена. Нельзя использовать эти учетные записи для доступа и управления рабочими станциями. Аналогичное требование должно предъявляться для учетных записей администраторов серверов
- Для учетных записей администраторов домена желательно использовать двухфакторную аутентификацию
- На своих рабочих станциях администраторы должны работать под учетными записями с правами обычного пользователя
- Для защиты привилегированных учетных записей (администраторы домена, Exchange, серверов) нужно рассмотреть возможность использования группы защищенных пользователей (Protected Users)
- Запрет использования обезличенных общих административных аккаунтов. Все аккаунты администраторов должны быть персонифицированы
- Нельзя запускать сервисы под учетными записями администраторов (а тем более администратора домена), желательно использовать выделенные учетные записи или Managed Service Accounts .
- Запрет работы пользователей под правами локального администратора
Естественно, нужно политиками обеспечить достаточную длину и сложность пароля как для пользователей, так и для администраторов и условия блокировки. Я говорю о политиках раздела Computer Configuration -> Windows Settings -> Security Settings -> Account Policies (см статью https://winitpro.ru/index.php/2018/10/26/politika-parolej-uchetnyx-zapisej-v-active-directory/):
- Password Policy
- Account Lockout Policy
Можно сделать более жёсткие требования к длине и хранимой истории паролей для администраторов с помощью Fine-Grained Password Policies.
Касательно встроенной учетной записи на компьютерах пользователей. Нельзя использовать одинаковые пароли локального администратора на всех ПК. Желательно вообще отключить (или хотя бы переименовать) локальную учетку administrator. Для регулярной смены пароля этой учетной записи на уникальный на каждом компьютере в сети можно использовать LAPS.
Доступ по сети с помощью локальных учетных записей и удаленных вход по RDP нужно запретить групповыми политиками . Данные политики находятся в разделе Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> User Rights Assignment.
- Deny access to this computer from the network – Отказать в доступе к этому компьютеру из сети
- Deny log on through Remote Desktop Services – Запретить вход в систему через службы удаленных рабочих столов
- Deny log on as a batch job – Отказать во входе в качестве пакетного задания
- Deny log on as a service — Отказать во входе в качестве службы
После окончания административного сеанса (установка ПО, настройка системы и т.д. ) компьютер пользователя лучше перезагрузить. А на RDS серверах принудительно завершать приостановленные RDP сессии с помощью политик в разделе Computer Configuration->Policies->Administrative Templates->Windows Components->Remote Desktop Services->Remote Desktop Session Host->Session Time Limits.
В домене с Windows Server 2016 для временного предоставления административных прав можно использовать новую фичу Temporary Group Membership
В этой я описал первоочередные правила, которые помогут вам повысить уровень защиты административных аккаунтов в вашем домене Windows. Конечно, это статья не претендует на полноценных гайд по защите и ограничению прав учетных записей администратора, но вполне может стать вашей отправной точкой по построению безопасной инфраструктуры. Для дальнейшего изучения темы рекомендую начать с изучения документации Microsoft: Best Practices for Securing Active Directory.
Интересная статья! Благодарю!
Вопрос на счет Protected Users. Если пользователь будет находиться в других группах — например админская группа SQL, то будет ли в этом случае работать группа защищенных групп?
Промахнулся с ответом. См. мой комментарий.
Ну а почему нет-то? Членство в этой группе не зависит/не влияет от/на членства(о) в других группах.
В реальном домене в любом случае любая учётка хоть в какой-то группе да находится. Хотя бы в «Domain Users». Чем остальные группы хуже?
Другое дело, что ограничивая аутентификацию учётки исключительно по Kerberos мы получаем побочные эффекты. Скажем я админ и решил положить свою админскую учётку в «Protected Users». Логичный вроде бы ход. Теперь я пришел домой и мне что-то понадобилось сделать на сервере на работе. Я подключаюсь к рабочей сети по VPN, пробую зайти на сервер через RDP. И.. хрен. Комп не в домене -> аутентификация не проходит.
Известная аксиома, что удобство работы обратно пропорционально безопасности. Внедрив все технологии безопасности мы, к огромному сожалению, превратим нашу систему в малоюзабельное нечто.
Все верно, группа Protected Users — довольно мощное средство, но накладывает кучу ограничений. И перед массовым внедрением нужно тщательно проверить, как будет работать ожидаемый функционал системы.
Плюс, чтобы SQL сервер корректно авторизовал с помощью Kerberos его необходимо дополнительно «готовить»
Напишите подробнее про пункт «Запрет использования обезличенных общих административных аккаунтов. Все аккаунты администраторов должны быть персонифицированы».
У администраторов уже есть персональные аккаунты для работы на своих рабочих станциях. Как предлагаете персонифицировать административные аккаунты?
У каждого админа личная учётка. В чём проблема?
Вопрос возник потому что в тексте вижу конфликт рекомендаций.
1. На своих рабочих станциях администраторы должны работать под учетными записями с правами обычного пользователя
2. Запрет использования обезличенных общих административных аккаунтов. Все аккаунты администраторов должны быть персонифицированы.
Т.е. админ Иванов не может быть одновременно простым пользователем и администратором.
Нет никакого противоречия — должно быть две разных личных учётки:
1. С правами админа только для администрирования
2. С юзерскими правами для работы
А еще лучше третья — с правами админа на рабочих станциях, но без оных на серверах. Для администрирования рабочих станций. А учётка номер 1 будет только для администрирования серверов.
Как обзываете персональные логины для разных задач, можете привести примеры?
Не вопрос.
Предположим, что у нас доменная сеть и есть админ Сергей. Тогда у нас будут такие учётки входящие в такие группы:
1. sergey-dadmin (входит в группу Domain Admins)
2. sergey-ladmin (входит в группы Domain Users, Local Admins*)
3. sergey (входит в группу Domain Users)
—
Группа «Local Admins» включена (через Group Policy) в группу локальных администраторов на рабочих станциях, но НЕ на серверах.
Эти учётки используются так:
1. Для администрирования AD и серверов
2. Для администрирования рабочих станций
3. Для работы на личном компе админа
Это конечно не единственно возможный вариант. Можно пойти дальше и, например, разграничить учётки для отдельного администрирования AD и серверов. Т.е. создать еще одну учётку которая будет иметь права локального администратора на серверах, но не будет иметь прав доменного админа. Можно автоматически назначать и менять с периодичностью пароль на каждую рабочую станцию и сервер отдельно (на этом сайте есть описание) и вообще не использовать учётку, имеющую администраторские права на нескольких машинах. В общем вариантов масса и зависит всё от степени паранойи и юзабилити выстроенной системы. Ведь не секрет, что удобство обратно пропорционально безопасности.
Приведённый пример использую лично я. Т.е. для себя я нашел в этом варианте приемлемый баланс безопасности/удобства.
Спасибо за развернутый ответ!
Сергей, а каким образом пользователь sergey-dadmin получает доступ к AD? Ведь только с группой Domain Admins на контроллере домена ничего сделать нельзя, сразу появляется окно с предложением ввести логин и пароль администратора.
Гм, я сейчас даже специально посмотрел на эту свою учётку — только Domain Admins. Ну есть еще пара групп не имеющих отношение к AD (для прокси доступ — к интернету и для файлового хранилища — доступ к папкам), но они понятное дело роли тут не играют. И под этой учёткой нормально все на контроллерах домена делается. Ну конечно если не считать таких вещей которые требуют прав администратора предприятия и схемы. Для этого конечно прав доменного админа не хватит. Но я про них даже упоминать не стал т.к. для этих задач есть еще одна учётка. Да, про неё забыл упомянуть 🙂 В своё оправдание могу сказать что:
Во-первых: отдельная учётка с правами администратора предприятия (Enterprise Admins) и схемы (Schema Admins) это.. ну как аксиома что ли.
Во-вторых: действия требующие этих прав настолько редко нужны в повседневной жизни (бывает, что и никогда за время существования домена), что тупо забыл 🙂
Так что к нашей концепции можно добавить еще одну учётку:
super-admin (входит в группу Enterprise Admins и Schema Admins)
И заметь, там не присутствует «sergey» 🙂 Я допускаю, что эту учётку можно сделать обезличенной т.к. пароль от неё ПО ХОРОШЕМУ всё равно должен знать только один какой-то главный админ (если их несколько). Т.е. по факту это все равно персонифицированная учётка. Просто несколько учёток с такими правами делать не имеет смысла почти никогда.
Тут дело не в AD. Запускаю например msconfig и тут же появляется окно контроля учетных записей с предложением ввести логин и пароль администратора. На контроллере включен 4-й уровень UAC. Но если захожу под super-admin, окно тоже появляется но без полей под логин и пароль, просто OK и пошел дальше.
У меня msconfig с правами только Domain Admin запускается вообще без предупреждений UAC. Но уровень 3-й (по умолчанию), система 2012 R2. Почему у тебя так я боюсь не отвечу. Похоже, что кто-то что-то донастроил.
Попробуй скинь на 3-й уровень. 4-й излишне параноялен. Хотя теоретически тот же msconfig должен дать запустить с правами Domain Admin хоть и с подтверждением.
Группа Domain Admins входит в группу BUILTIN\Administrators на контроллере? У меня нет.
Да, входит (и еще туда входят администраторы предприятия).
И это настройка по умолчанию, потому что я не трогал членство в этих группах.
В этом очевидно и причина. Т.к. доменный администратор не является администратором на контроллере домена. Ваш кэп 😉
Добавил в BUILTIN\Administrators и конечно заработало. Но какой тогда смысл в super-admin, если sergey-dadmin входит в наиглавнейшую группу среди групп администрирования?
Администраторы (Administrators) — находится в контейнере Builtin каждого домена. Эта группа имеет полный доступ ко всем контроллерам домена и данным в контексте именования домена. Она может изменять членство во всех административных группах домена, а группа Администраторы (Administrators) в корневом домене леса может изменять членство в группах Администраторы предприятия (Enterprise Admins), Администраторы Схемы (Schema Admins) и Администраторы домена (Domain Admins). Группа Администраторы в корневом домене леса имеет наибольшие полномочия среди групп администрирования в лесу.Ну это вряд ли ко мне вопрос, больше к MS. Понятно, что если злоумышленник заполучил пароль от учётки с правами Domain Admins, то он уже может добавить любую учётку в группы Enterprise Admins и Schema Admins. Здесь скорее больше как защита от дурака — что бы ты сам себе лес не поломал выполняя повседневные задачи с правами Domain Admins. Т.е. как бы входя под super-admin ты показываешь, что осознанно хочешь получить права Enterprise Admins и Schema Admins. Правда вот эта фраза «Группа Администраторы в корневом домене леса имеет наибольшие полномочия среди групп администрирования в лесу.» всё портит. Т.е. подразумевается, что Builtin\Administrators уже обладают правами Enterprise Admins и Schema Admins, так что ли? Но что-то я честно говоря в этом сильно сомневаюсь (хоть и не буду утверждать на 100%). Зачем тогда Enterprise Admins входит в эту группу?
Сергей, на файловом сервере UAC включаете? Если да, то как боритесь с сообщением «You don’t currently have permission to access this folder». Если сделать как тут предлагают, то UAC получается выключен. Может знаете другое решение?
Да, на файловом у меня включен. Хотя по чесноку сказать не особо-то он там и нужен, но лучше перебдеть. По ссылке да — предлагается по сути выключить UAC для админских учёток. На самом деле озвученная проблема решается изящнее. Надо создать группу, скажем «UAC Bypass». В эту группу включить админские учётки, но саму эту группу не включать в группу локальных админов. Теперь этой группе даём необходимые права на папки. Всё.
Я уже давно назначаю группу «A» на шары с правами Full Control, в которую включен пользователь из Domain Admins чтобы не было проблем с локальным доступом для самого админа. Но получается что она присутствует везде в закладке Security, я думал что может есть вариант обойтись как-то без неё.
ПС. Почему под вашими ответами нет кнопки «Ответить»? Мне приходится постоянно отвечать на ваш старый комментарий.
Ну висит она там и висит — ничего страшного. Другой способ если и есть, то я его не знаю. Логично было бы запускать проводник от имени администратора сразу с подтверждением UAC, но так не работает почему-то.
С кнопкой «Ответить» не знаю почему. К администрации сайта я отношения не имею если ты это имеешь в виду. Я такой же посетитель 🙂 Вообще тут комментарии как-то как-то странно работают, я тоже замечал.
1. Сергей все правильно изложил на счет концепции нескольких учеток. Сам тоже работаю по такой схеме — 3 учетные записи для разного класса задач
2. Касательно запуска проводника под администартором, чтобы не появлялось окно UAC на 2012 R2, можно воспользоваться ранее описанным трюком https://winitpro.ru/index.php/2016/07/28/zapusk-provodnika-windows-ot-imeni-administratora/
3. Касательно комментариев: уровнь дерева комментарием специално ограничил на уровне движка сайта (4 или 5 уровней вложенности), иначе они начинаю просто комкаться у правого края экрана и визуально это выглядит отвратительно. Ну и сами комментарии могут отображаться не сразу — связано с работой функции кэширования веб-страничек, иначе apache ложиться при большом наплыве посетителей.
Есть еще хорошее правило. Исключать группу Администраторы домена из локальных администраторов рабочих станций, и вообще где угодно кроме КД. Для этого через GPO распространяется группа с пользователями не имеющих в домене админских прав.
Все верно, так реализуется на практике. Нужно административно запретить администраторам логинится на рабочие станции.
Я это подразумевал в пункте