Active Directory Expiring Links
Active Directory Expiring Links - настройка и использование
Управление безопасностью в Active Directory – тема практически неисчерпаемая, и в каждой версии Windows Server добавляются не только новые возможности, но и изменяются схемы применения старых, уже давно существующих.
Это одна из причин, по которой часто случается удивительное – спешно нагугленный вариант решения проблемы оную решает, но как-то странно и с кучей побочных и неочевидных для применяющего последствий. В итоге выясняется, что “набравшее больше всего на техническом форуме лайков” решение просто было эффективно во времена Windows Server 2003, а сейчас уже приносит больше проблем, чем преимуществ. Если человек после этого начинает рефлексировать и думать мозгом, то он догадывается, что надо не гуглить “самое рекомендуемое по поголовью лайкнувших” решение, а разобраться в том, как именно работает используемая технология. Если же нет – например, банально не тянет переход от “гуглить пошаговое решение” до “разобраться в технологии” – то начинает веровать, допустим, в убунту.
Один из примеров такой ситуации мы разберём в данной статье.
Использование механизма Active Directory Expiring Links
Предпосылки к автоматизации управления составом групп
Функция Manager can update membership list
Механизм Restricted Groups
- Задачи, решаемые Active Directory Expiring Links
- Включение механизма Active Directory Expiring Links
- Использование Active Directory Expiring Links
Начнём.
Предпосылки к автоматизации управления составом групп
То, что управлять группами вручную неэффективно – знали давно. Администратор может, конечно, получать от helpdesk’а инциденты, одним из действий для закрытия которых является изменение членства в одной или нескольких группах, но объём этой работы, как и любой рутинной, влечёт за собой рост человеческих ошибок, а также является занимающим время процессом, при этом – не требуя сколь-нибудь заметной квалификации. Очевидно, что такое действие – первый кандидат на оптимизацию – как в плане “уменьшить количество подобных действий”, так и в плане “снизить затраты времени на каждое”.
Первая попытка упростить управление группами в Active Directory появилась вместе с Active Directory, и называлась вот так:
Функция Manager can update membership list
Если у группы задан владелец, то параметр Manager can update membership list, будучи включённым, позволяет владельцу управлять её составом.
Параметр Manager can update membership list
(кликните для увеличения до 400 px на 473 px)
Технически это реализуется крайне просто – в DACL добавляется одиночная ACE про Write Members:
Иногда на авторизованных курсах Microsoft можно услышать очешуительную байку о том, что это Специальный Механизм В Обход Стандартных Средств и чуть ли не Хитрый Хак, но по факту это микро-wizard по добавлению в DACL одной строчки. Вы можете проверить это просто – создать нового security principal’а, и выдать ему вручную право записи именно в этот одиночный атрибут, а после зайти в GUI-панель управления группой и увидеть, что галочка рядом с Manager can update membership list появилась “сама по себе”. Никакой мистики, в общем.
Идея Microsoft, породившая добавление этой feature, была примерно такая:
Давайте всё будет децентрализованное и самоорганизующееся. Например обычный руководитель отдела будет сам поадминивать Active Directory – мы сделаем ему специальную урезанную MMC-консоль, после выдадим права на управление группами Active Directory, относящимися к его отделу – и в результате он сможет сам и добавлять и удалять сотрудников.
В реальности же среднестатистический руководитель отдела логистики – или, допустим, главбух – с ледяным изумлением воспринимает подобные инициативы, опираясь на тривиальное “в мою оплату не входит эта новая обязанность, а также следующая из неё ответственность”. Поэтому с инициативой “насоздавать всем на рабочих столах иконок для управления технической стороной работы со своим подразделением в Active Directory” вышло как-то не очень. Контроль в GUI остался, но использования его не наблюдается.
ОК, с переложением на пользователей части задачи ничего не вышло. Не проблема, есть и другой вариант, уже чисто технический.
Механизм Restricted Groups
Появившийся в NT 5.0 механизм Restricted Groups послужил очень неплохим подспорьем для автоматизации труда администраторов. Механизм срабатывает каждый раз при применении объекта Group Policy, где он определён, и предоставляет две возможности:
- Изменить состав группы N на явно заданный;
- Включить группу N в другую группу;
Выглядеть он в применении будет примерно так:
Механизм Restricted Groups
(кликните для увеличения до 1114 px на 713 px)
Изображённые на картинке настройки приведут к тому, что каждый раз, когда на данном участнике домена Active Directory, классифицируемом как CN=Computer – т.е. на рабочей станции или сервере – будет применяться комплект групповых политик, среди которых есть наша Hong Kong Clockenflap Festival, то локально (это важно) будет осуществляться поиск группы ATRAINING\Hong Kong Clockenflap Festival, после чего, если группа будет найдена, её состав будет заменён на одного участника – ATRAINING\Die Antwoord. Именно заменён, а не дополнен. В случае, если данная политика будет применяться на контроллер домена, соответственно, поиск группы будет вестись в домене.
Этот механизм очень удобен для целой группы применений.
Первый вариант – это массовая фиксация состава служебных групп на локальных системах. Допустим, есть задача “обеспечить наличие в локальных администраторах на всех системах группы ATRAINING\Local Admins” – при помощи Restricted Groups она решается элементарно.
Второй – удаление ненужных участников. Если пользователь Василий разово получит права локального администратора, то на него может напасть т.н. “кукушечная болезнь” – Василий объявит себя царём горы и удалит из группы BUILTIN\Administrators всех остальных, включая ATRAINING\Domain Admins. Это затруднит администрирование и приведёт к ненужному всплеску насилия в коллективе. Гораздо проще, если регулярно, со стандартным временем применения в 90-120 минут, в группе BUILTIN\Administrators будет фиксироваться наличие нужного перечня участников – скажем, BUILTIN\Administrator, ATRAINING\Domain Admins и ATRAINING\Local Admins. Текущий состав группы будет просто игнорироваться, она будет форсированно “приводиться к нужному составу”.
Третий – ликвидация “закладок” в составе административных групп. В достаточно крупных организациях возможны ситуации, когда уходящий администратор, либо сотрудник с нужным уровнем доступа, делает для себя “закладку”, добавляя в технические группы дополнительные учётные записи. Чтобы предотвратить это, нужно написать документ, в котором будет явно указан состав всех технических групп – от BUILTIN\Administrators домена до \Schema Admins. После чего создать объект Group Policy с Restricted Groups, фиксирующими эту ситуацию. Нет никого в Backup Operators, Server Operators, и так далее? Отлично, зафиксируйте это, “раздав” пустой состав этих групп. Себя же подстрахуете от ситуации “экс-админ Вася создал левую учётку, спрятал её в неочевидный контейнер, подсунул в Server Operators и получил нехарактерные права на системе”.
Все эти штуки полезны, но всё же остаётся целый класс задач, не покрываемых данным функционалом – который, замечу, без изменений живёт два десятка лет, т.к. появляется в 1999 году. Этот класс задач – про временное членство в группах Active Directory.
Задачи, решаемые Active Directory Expiring Links
Задача “временно предоставить права для выполнения конкретного перечня операций, а потом убрать” – весьма широка. Она может быть связана как с административными и техническими задачами – например, разово предоставить права на расширение схемы Active Directory – так и с работой обычных пользователей, в сценарии вида “пока идёт работа над задачей X, у участников рабочей группы должны быть права на доступ к определённому перечню информационных ресурсов, ну а после доступ необходимо убрать”.
Механизм Restricted Groups частично позволяет решать это – например, если сделать применяемую раз в час политику, которая очищает группу Schema Admins, то можно, добавившись в Schema Admins, срочно запустить расширение схемы, держа в уме, что примерно через полчаса (а может и через минуту) права закончатся. Ну а через час так точно закончатся. Так как процесс трудно предсказуем, то такой вариант нельзя считать рабочим.
Добавление нужного security principal’а в группу с автоматическим удалением из оной по прошествии нужного времени – это как раз то, что делает механизм Expiring Links.
Включение механизма Active Directory Expiring Links
Для включения AD Expiring Links нам нужен будет лес уровня Windows Server 2016 – потому что понимать что надо регулярно “подчищать” группы от “устаревших” участников будут только DC/GC на Windows Server 2016. Если быть совсем точным – они начали это уметь с Windows Server 2016 TP4, в оригинальной первой превью-версии функции ещё не было.
Далее, отдельного включения именно данной функции нет – начиная с Windows Server 2016 вы можете включить feature с названием PAM – Privileged Access Management:
Enable-ADOptionalFeature -Identity 'Privileged Access Management Feature' -Target (Get-ADForest) -Scope ForestOrConfigurationSet
Active Directory Expiring Links входит в её состав.
Как и в случае с другими AD Feature’ами – типа Recycle Bin – можете проверить факт включения, зайдя в раздел Configuration и проверив наличие в CN=Optional Features,CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=контекст домена объекта CN=Privileged Access Management Feature.
Это будет выглядеть примерно так:
Как использовать?
Использование Active Directory Expiring Links
Графического интерфейса к новому варианту добавления участника в группу нет. Или пока ещё нет, или совсем не будет – в принципе, некритично. Сделаем это через Powershell:
$time = New-TimeSpan -Hours 8
Add-ADGroupMember -Identity 'Schema Admins' -Members Ninja -MemberTimeToLive $time
Новый атрибут командлета Add-ADGroupMember, называющийся MemberTimeToLive, содержит тривиальную информацию “через сколько времени данного участника надо удалить из группы”. Как понятно, держать это на контроле и фактически проводить операцию будет какой-либо DC.
Что интересно, технически это будет реализовано как дополнительное поле данных в базе NTDS, называющееся expiration_time_col. То есть несмотря на то, что при просмотре состава группы участники, использующие Expiring Links будут выводиться с модифицированными DN:
(на скриншоте видно, что в Schema Admins два участника, и у первого из них необычное DN) – вот несмотря на это, такие DN будут “синтезироваться” только по специфичному LDAP-запросу. Новые сервера, на Windows Server 2016, умеющие обрабатывать эти доп.данные, будут добавлять в LDAP-запрос специальный OID, называющийся LDAP_SERVER_LINK_TTL – и в результате в ответ будет добавляться новая информация. Старые же не сломаются, получая “странные” DN – потому что если не добавить этот OID, то список участников группы будет выглядеть обычно.
Также интересно, что при выводе DN’ов новые данные добавляются впереди в формате <TTL=x>,DN=имя объекта – то есть конструкция <TTL=x> явно добавлена отдельно; это делается исключительно для упрощения визуального чтения вывода, потому что технически DN будет возвращаться в виде TTL=2880,CN=Ninja,OU=Crew,DC=atraining,DC=lab. Это на случай, если попробуете вручную добавлять через ADSI/ldp.exe – не ставьте закрывающую угловую скобку после значения TTL.
Дополнительным плюсом данной технологии будет то, что при создании Kerberos’овского TGT для конкретного security principal’а будет проводиться поиск “а не заявлен ли этот security principal как временный участник одной или более групп”. Если такое будет найдено, то срок жизни выдаваемого TGT будет установлен на минимальный срок ожидания изменения членства данного security principal’а в группах. То есть если пользователь Василий будет временно добавлен в две группы, из одной из которых его надо удалить через полчаса, а из другой – через три часа – то срок жизни TGT для Василия будет максимум 1800 секунд. Что, соответственно, приведёт к необходимости повторной авторизации и исключит ситуацию “Вася разово залогинился, получил тикет с SID CN=Enterprise Admins и хорошо себя чувствует”.
Вкратце всё – и не забывайте, что удаление из группы в Active Directory не равнозначно модификации lsass’овского маркера локальной сессии – поэтому у залогиненных локально на рабочих станциях пользователей SID’ы групп, из которых их уже удалил механизм AD Expiring Links, всё же будут сохраняться до конца сеанса.