О пустых корневых доменах в Active Directory
2011-09-05, 09:00 / ArgonВ своей практике я часто встречаю пустые корневые домены Active Directory: воплощенные как в реальных инфраструктурах заказчиков, так и в публикуемых в интернетах материалах. Причем, на мой вопрос «А зачем так?» обычно я не получаю ответа, либо слышу что-то невразумительное, вроде «Так рекомендуют в статьях».
В данной заметке я попытаюсь провести анализ полезности пустых корневых доменов для современной инфраструктуры AD.
Античность: служба каталогов Windows NT 4
Во времена службы каталогов Windows NT 4 существовало вполне достижимое ограничение на максимальное количество объектов в домене. С целью экономии на количестве объектов, предлагались следующие ухищрения:
- создавать разные домены для пользовательских учетные записей и ресурсов (сервера, данные приложений в службе каталогов)
- если и в этом случае лимитов домена NT4 было недостаточно, предлагалось создавать отдельные домены для крупных организационных единиц предприятия.
Средние века: Active Directory на WS 2000 / 2003
С выходом Windows 2000 и обновленной службы каталогов, Active Directory, проблемы с ограничением количества хранимых объектов были решены. Помимо этого, значимым нововведением (в контексте данной заметки) стала возможность создавать леса доменов. Домены в одном лесу:
- организованы и управляются иерархически
- разделяют общую схему хранения данных в службе каталогов
- имеют с возможность полностью реплицировать некоторые разделы службы каталогов на все контроллеры домена в лесу
- некоторые атрибуты всех объектов любого домена в лесу могут быть доступны на глобальном каталоге любого другого контроллера домена в том же лесу
Однако, осадок в виде накопленного с Windows NT 4 опыта остался: по-прежнему можно встретить необоснованные рекомендации по созданию ресурсных и пользовательских доменов, а также дочерних доменов для больших структурных подразделений в организации. Естественно, при создании множества доменов является разумным пользоваться возможностью Active Directory строить иерархию доменов в одном лесу.
Многодоменная иерархическая структура действительно оправдана в следующих случаях:
- Управление ИТ-инфраструктурой предприятия выполняется децентрализовано: местные ИТ-службы крупных орг. подразделений предприятия автономны от центра, полностью управляют и несут ответственность за свою инфраструктуру. Вполне логично использовать отдельные домены для изоляции полномочий администраторов в пределах только своего автономного подразделения.
- Каналы связи между крупными орг. подразделениями настолько узки и ненадежны, что даже трафик репликации вызывает проблемы. При прочих равных, трафик репликации между доменами намного меньше трафика репликации в пределах одного домена.
Если иерархия доменов в пределах одного леса строиться именно по перечисленным выше причинам, то вполне разумно в качестве корня иерархии использовать «пустой» домен, который не будет выполнять никаких ответственных функций, кроме как логического корня и высшей точки назначения привилегий.
Смутное время
В реальном мире можно встретить обобщение приведенной выше практики и на случаи, когда пустой корневой домен в действительности не требуется. Пустому корневому домену придаётся неоправданный сакральный смысл, налёт неоспоримой лучшей практики.
Приведу некоторые распространенные суждения:
- Пустой корневой домен необходим для изоляции мастера схемы от возможных покушений на чистоту схемы.
- Только в корневом домене есть группа высшей исполнительной власти — Enterprise Administrators, и её необходимо защитить от посягательств «обычных» Администраторов домена.
- Если требуются разные политики безопасности паролей для пользователей разных категорий, то эта задача может быть реализована только в разных доменах.
Хотя данные суждения не лишены разумных оснований, только ради таких соображений безопасности выделение отдельного пустого корневого домена не оправдано:
- Требуется дополнительное оборудование для работы контроллеров корневого домена.
- Требуется дополнительное сопровождение и организация отказоустойчивости для контроллеров корневого домена.
- Общая логическая иерархия AD увеличивается дополнительным уровнем, удлиняя имя домена, цепочку разрешения имён и аутентификации при работе с доверительными отношениями с другими лесами.
- И последнее, самое интересное… Было доказано, что домен в пределах леса на самом деле не является границей безопасности. Иными словами, при наличии административного (физического) доступа к любому контроллеру любого дочернего домена можно получить любые права в корневом домене.
Если требуется реальная граница безопасности между службами каталогов AD, она реализуется только между разными лесами.
Наше время: Active Directory на Windows Server 2008 / R2
За счет нового функционала, переход Active Directory на уровень функционирования Windows Server 2008 (R2) решает многие озвученные ранее проблемы:
- контроллеры домена только для чтения позволяют больше особо не беспокоиться за их безопасность при размещении в подозрительных местах: даже прямой физический доступ к такому контроллеру не угрожает безопасности административных учетных записей
- возможность аппаратного шифрования дисков с помощью BitLocker пишущих и только читающих контроллеров домена
- использование режима Core установки ОС еще сильнее сокращает поверхность для возможных атак
- возможность создавать различные политики безопасности паролей для разных групп пользователей
- ну и… каналы связи со времён Windows 2000 значительно расширились, так что проблема объёма трафика репликации данных AD в пределах домена более не стоит так остро
Таким образом, в настоящее время нет смысла использовать пустой корневой домен AD, если на то нет требований бизнеса. Большинство задач, ради которых ранее предлагалось создавать развитую иерархию леса AD, в данный момент можно решить проще: за счет возможностей нового уровня функционирования AD и грамотного применения делегирования полномочий.
Разумеется, если текущий лес AD достался в наследство уже с пустым корневым доменом, то здесь остаётся либо смириться, либо, собравшись силами, пойти по пути джедая: устроить миграцию…
Годные ссылки
| Рубрика | Core Infrastructure |
|---|---|
| Метки | active directory, ad, security, безопасность, windows server, совместимость |
| Опубликовано | 2011-09-05, 9:00; обновлено 2012-02-09, 17:38 |
| Комментарии | 11 комментариев » | Лента комментариев RSS |
| Ссылки | Постоянная ссылка | Обратная ссылка |
11 комментариев
«Общая логическая иерархия AD увеличивается дополнительным уровнем, удлиняя имя домена, цепочку разрешения имён и аутентификации при работе с доверительными отношениями с другими лесами.» — не всегда так. Ничто не мешает в рамках одного леса создать корневой домен root.local и «дочерние» домены domain1.local, domain2.local итд. Настройки доверия между лесами при этом могут немного усложниться (за счёт дополнительных dns-форвардеров), зато имена станут короче =)
Верно. Я даж где-то читал, что рекомендуют корневой домен со схема-мастером именно таким образом «прятать» от посторонних глаз.
Однако, для варианта Forest Trust этот дополнительный уровень все равно удлинняет цепочку аутентификации (Kerberos, NTLM).
>>>контроллеры домена только для чтения позволяют больше особо не беспокоиться за их безопасность при размещении в подозрительных местах: даже прямой физический доступ к такому контроллеру не угрожает безопасности административных учетных записей
это не совсем так. физический доступ к такому контроллеру всеже при неправильной политике администрирования может привести к плохим последствиям.. все таки он только на уровне DSA read-only.. а так изменяй — нехочу..
>>>Если иерархия доменов в пределах одного леса строиться именно по перечисленным выше причинам, то вполне разумно в качестве корня иерархии использовать «пустой» домен, который не будет выполнять никаких ответственных функций, кроме как логического корня и высшей точки назначения привилегий.
ну какбы иерархия доменов в назначении привилегий не играет…
вообще можно добавить еще один миф: доступ к схеме-мастеру не приводит к компрометации :) вот возьмите учетку со schema admin и попробуйте нарушить работу службы каталогов.. :) создали много классов? атрибутов? что еще можете сделать? модифицировать системную часть схемы можете?
еще в догонку по схеме.. и по мастеру:
корневым доменом его не скроешь и не спрячешь, а тем более не защитишь…
Очень легко посмотреть где мастер схемы. Это раз.
Очень легко форсануть схема мастера куда угодно, имея физический доступ к любому RwDC, а иногда и RoDC. И тогда делай все что хочешь. Это два. Но опять же, «все что хочешь» — это слишком громко сказано, поскольку DSA на схему накладывает очень большие ограничения на расширение. Ключевое слово расширение. Начиная с 2003 ограничений только прибавилось.
gex, спасибо за комменты!
Во многом согласен, особенно с развеянием мифов по поводу «безопасности» мастера схемы в корневом домене.
А вот с инфой о практической реализации возможности наделать гадостей, имея прямой доступ только к RODC, пока не сталкивался.
Если сцылок накидаешь, буду рад :)
вот возьмите учетку со schema admin и попробуйте нарушить работу службы каталогов.. :) создали много классов? атрибутов? что еще можете сделать?
Да кому такая схема нужна будет, после таких-то надругательств ;)
Вот что нашел
A malicious user who compromises an RODC can attempt to configure it in such a way that it tries to replicate attributes that are defined in the RODC filtered attribute set. If the RODC tries to replicate those attributes from a domain controller that is running Windows Server 2008, the replication request is denied. However, if the RODC tries to replicate those attributes from a domain controller that is running Windows Server 2003, the replication request can succeed.
Therefore, as a security precaution, ensure that forest functional level is Windows Server 2008 if you plan to configure the RODC filtered attribute set. When the forest functional level is Windows Server 2008, an RODC that is compromised cannot be exploited in this manner because domain controllers that are running Windows Server 2003 are not allowed in the forest.
>>>Да кому такая схема нужна будет, после таких-то надругательств ;)
ну просто никто и не заметит особо, что там классы и атрибуты новые появились. Чтобы заметить нужно реализовать использование на уровне приложения. Но тут можно и все-таки на проблему наткнуться, которая также решается. Если подытожить свою мысль, то я хотел сказать, что необходимо в комплексе смотреть безопасность и что компрометация контроллера со схемой мастера имеет не большую опасность чем компрометация любого контроллера.
по поводу RODC. Я тут статейку писал, как можно получить полномочия используя RODC:
http://gexeg.blogspot.com/2009/12/active-directory.html
Спасибо за ссылку! Очень интересно. Там отписал своё мнение об извращениях над RODC.
На памяти еще один вариант, зачем нужен корневой домен и он вполне реалистичен. Корневой домен позволяет более проще провести реструктуризацию доменов в лесе. Например — еще давно обратился один заказчик у которого структура СК состояла предположим из одного дерева где коревой домен назывался из серии msk.company.com, собственно когда MSK регион отвалился стало понятно что не так то просто удалить корневой домен )). Не смотря на то что название домена которое я привел не совсем корректно — смысл остается в том, что можно создать корневой домен с абстрагированным — нейтральным названием а дочерние создавать по всем православным канонам ICANN и т.д. дочерние домены можно легко реструктурировать. Про безопасность вы сам и все сказали выше. На 99% эти домены создаются по слухам о безопасности.