Модуль 1. Система ALD Pro и ее компоненты.
Введение
ALD Pro - это служба каталога, которая позволит при переходе от Windows к Linux сохранить лучшие практики системного администрирования, доступные ранее при эксплуатации Active Directory.
Из этого модуля вы узнаете об истории развития служб каталогов, архитектуре ALD Pro и рекомендациях по планированию ресурсов. «Буков много», но будет очень интересно!
Система ALD Pro
Используя продукты ведущих вендоров, мы не всегда задумываемся о том, что в них реализованы лучшие бизнес-практики, позволяющие экономить на администрировании, повышать безопасность инфраструктуры и обеспечивать удобство для работы пользователей. Но эти детали, как шило в… мешке, не дают покоя, и при попытке заменить проверенное ПО свободным оказывается, что ни одно из альтернативных решений неспособно без существенных доработок обеспечить сопоставимые показатели по безопасности, удобству и эффективности.
Сегодня нужно заменить большое количество программных продуктов, а времени совсем мало, поэтому приходится расставлять приоритеты и начинать с самого важного. Так, одним из стратегических направлений компании Астра стала разработка службы каталога, которая должна заменить Microsoft Active Directory и стать сердцем обновленной ИТ-инфраструктуры российских предприятий.
Система централизованного управления ИТ-инфраструктурой ALD Pro позволит при переходе от Windows к Linux сохранить лучшие практики системного администрирования, доступные ранее при эксплуатации Active Directory.
Эта служба каталога построена на базе FreeIPA и позволяет объединить Linux-компьютеры в один домен, обеспечивая единую точку входа, централизованное управление правами доступа, установку и настройку программного обеспечения — все то, без чего невозможно поддерживать инфраструктуру на том же уровне удобства и безопасности, сохраняя прежний размер команды системных администраторов.
Контроллеры домена ALD Pro обеспечивают те же сервисы, что и в Active Directory:
Центр распространения ключей на базе MIT Kerberos обеспечивает возможность централизованной аутентификации по безопасному протоколу Kerberos V5.
Система доменных имён на базе ISC Bind9 тесно интегрирована с доменом и обеспечивает взаимодействие клиентов друг с другом, контроллерами домена и другими сервисами.
LDAP-каталог на базе 389 Directory Server обеспечивает хранение и репликацию информации между контроллерами домена. В LDAP каталоге хранятся учетные записи пользователей и компьютеров, DNS записи и другая информация.
Механизм групповых политик обеспечивает возможность централизованной настройки доменных компьютеров с доставкой параметров через LDAP.
Служба синхронизации времени на базе Chrony обеспечивает возможность синхронизации времени с контроллером домена по стандартному протоколу NTP, что крайне важно для корректной работы Kerberos-аутентификации.
Продукт ALD Pro (Astra Linux Directory Pro) быстро развивается, и с даты первого релиза было опубликовано уже несколько сотен улучшений, что позволило стать лидером на рынке доменных решений. У нас уже сотни инсталляций по всей стране, и с каждым днем их становится все больше.
Возможности службы каталога
Служба каталога (англ. Directory Service) — это в первую очередь средство централизованного управления ИТ-ресурсами предприятия, такими как пользователи и компьютеры. В ALD Pro на каждом контроллере домена установлен веб-портал, с помощью которого можно получить доступ к базе данных LDAP-каталога, чтобы просматривать список пользователей, редактировать их атрибуты, сбрасывать пароли, создавать новые учетные записи, см. рис. 153.
Каталог содержит также учетные записи компьютеров, которые нужны для возможности организации единой точки входа с аутентификацией по безопасному протоколу Kerberos V5. Для того чтобы Linux-компьютер мог быть участником домена, на него устанавливается агентская часть ALD Pro, ключевым компонентом которой является служба SSSD. Эта служба встраивает свои модули в стандартные стеки PAM и NSS, за счет чего она может перехватывать запросы на аутентификацию и авторизацию и обрабатывать через контроллеры домена.
Поиск доступного контроллера домена выполняется в рамках процедуры автоматического обнаружения доступных сервисов. Когда пользователь в первый раз входит в компьютер, его аутентификация возможна только через контроллер домена, но при получении успешного статуса PAM_SUCCESS служба SSSD сохранит хеш в локальной базе, что гарантирует возможность автономной аутентификации этого пользователя даже в условиях отсутствия связи с сервером. В случае строгих правил безопасности кэширование паролей можно отключить.
Еще одной сильной стороной службы каталога ALD Pro являются групповые политики, часть из которых реализована непосредственно в службе FreeIPA на связке с SSSD. Аббревиатура IPA вообще-то является сокращением от слов «Identity, Policy, Audit» и указывает на то, что эта служба является средством централизованного управления идентификацией, политиками и аудитом. Базовых политик FreeIPA немного, но все они крайне полезные – это политики паролей, правила HBAC и SUDO, политики SELinux и монтирования дисков. Наибольший интерес для нас представляют первые три.
Как вы знаете, пароли являются самым простым, но вместе с тем и не самым безопасным способом аутентификации пользователей. Поэтому в службе каталога реализованы политики паролей, которые позволяют снизить риск взлома привилегированных учетных записей за счет предъявления к ним повышенных требований, см. рис. 154.
Механизм политик паролей позволяет для каждой группы пользователей создать отдельный набор правил, которые поддерживают стандартные требования к паролям MIT Kerberos. Система будет сверяться с этим списком правил каждый раз, когда пользователь захочет установить себе новый пароль. В случае если пользователь входит сразу в несколько групп, будет применена самая строгая политика с наивысшим приоритетом. Если на пользователя не распространяется действие ни одной политики, ему будет назначена глобальная политика по умолчанию (global_policy).
Политики HBAC (англ. Host-based access control — контроль доступа к узлу) задают набор правил для настройки доступа пользователей или групп пользователей к определенным хостам с использованием конкретных PAM-сервисов. Механизм реализован средствами PAM-модуля службы SSSD. Например, после установки первого контроллера в домене будет правило allow_all, которое рекомендуется назначить только на администраторов, а для обычных пользователей создать еще одно правило, ограничивающее их доступом только к обычным рабочим станциям, см. рис. рис. 155.
Похожим образом работают политики повышения привилегий (правила SUDO), которые позволяют дать пользователю или группе пользователей возможность выполнять на определенных хостах заданные команды через утилиту sudo. Например, вы можете дать возможность контент-менеджеру сайта перезапускать веб-сервер при необходимости с использованием команды sudo systemctl restart apache2.service»
.
Базовые политики FreeIPA очень полезны, но они не позволят вам изменить параметры операционной системы, установить и настроить дополнительное программное обеспечение, поэтому в продукте реализованы также групповые политики ALD Pro, которые работают за счет интеграции с системой конфигурирования Salt Stack, см. рис. 156.
Механика групповых политик ALD Pro во многом повторяет механику MS AD. Параметры извлекаются из домена по модели pull кастомизированной службой Standalone-миньон системы конфигурирования SaltStack. Если сравнивать с Windows, то эта служба является аналогом GPSVC: она проходит Kerberos-аутентификацию на LDAP-сервере, используя учетную запись компьютера; извлекает актуальные параметры групповой политики в соответствии с положением пользователя и компьютера в иерархии структурных подразделений; она выполняет суммирование параметров в той же логике, как это делает Windows-компьютер. Для применения параметров на Linux-компьютерах используются Salt-скрипты, которые предоставляют огромное количество модулей для работы с конфигурационными файлами.
Продуктовая команда ведет непрерывную работу по расширению перечня параметров групповых политик, доступных из коробки, но при необходимости администраторы могут самостоятельно создать дополнительные параметры, с помощью которых могут реализовать управление, например, корпоративными приложениями.
В завершение следует отметить, что базовые возможности службы каталога значительно расширяются дополнительными подсистемами, которые построены на хорошо известных компонентах с открытым исходным кодом:
Подсистема «Репозиторий программного обеспечения» (Reprepro)
Подсистема «Общий доступ к файлам» (Samba)
Подсистема «Служба печати» (CUPS)
Подсистема «Динамическая настройка узла» (ISC DHCP)
Подсистема «Установка ОС по сети» (TFTP HPA)
Подсистема «Мониторинг» (Zabbix, Grafana)
Подсистема «Аудит» (Syslog-NG)
Установка и настройка подсистем выполняется в несколько кликов из единого портала управления, что существенно упрощает развертывание и управление инфраструктурой.
Почему FreeIPA, а не Samba AD
Выбор компонентов технологического стека является одним из наиболее важных моментов в разработке программного обеспечения, поэтому мы хотели бы раскрыть причины, по которым мы сделали ставку на службу каталога FreeIPA.
На данный момент работу Linux-компьютера в домене можно обеспечить с помощью нескольких клиентских компонентов с открытым исходным кодом: это служба SSSD от проекта FreeIPA, служба Winbind от проекта Samba и отдельные PAM/NSS модули. В качестве бэкенда у этих компонентов могут выступать FreeIPA, MS Active Directory, Samba AD, MIT KDC или даже простые LDAPv3 каталоги.
Выбирая простые бэкенды, такие как MIT KDC или LDAPv3-каталоги, потребуется направить излишне много усилий на решение задач репликации или интеграции с DNS и Kerberos. Поэтому выбор фактически лежит между FreeIPA и Samba AD. Давайте посмотрим на эти службы каталога внимательнее.
Служба каталога Samba AD
Когда речь заходит о Samba (https://www.samba.org), в первую очередь нужно определиться, в каком контексте обсуждается продукт, т. к. этот швейцарский нож может предоставить и общий доступ к файлам, и совместное использование принтеров, и доменные сервисы, причем как в формате Active Directory, так и в устаревшей реализации NT4.
Работу над созданием службы совместного доступа к файлам Эндрю Триджелл (Andrew Tridgell) начал еще в конце 1991 года, когда обучался в аспирантуре Австралийского национального университета и по совместительству отвечал за сетевое администрирование. Образовательное учреждение закупило программное обеспечение PC X server eXcursion от компании DEC (Digital Equipment Corporation), и Триджеллу [STRIKEOUT:захотелось] понадобилось организовать доступ с eXcursion к файлам, размещаемым на других серверах под управлением операционной системы Sun.
Программного продукта, который бы решал эту задачу, не было, и Триджелл (как настоящий «тыжпрограммист») путем реверс-инжиниринга сетевого протокола, просто анализируя трафик, повторил реализацию одного из наиболее успешных продуктов компании DEC, что принесло автору заслуженное признание. Впоследствии, конечно, оказалось, что у протокола все-таки есть открытая спецификация, и этот RevEng не имел большого практического смысла, но, как говорится, бешеной собаке семь верст не крюк.
Важно
Я немного покопался, немного поспрашивал и обнаружил, что нужная мне спецификация предназначена для протокола SMB и что она доступна через ftp. Тогда скачал ее и начал удалять все эти ужасные константы из кода, когда они стали понятны. Я был шокирован, увидев реальную спецификацию SMB, и понял, как мне повезло, что мой первоначальный код вообще работал.
Изначально проект так и назывался — SMB Server, то есть по названию протокола Server Message Block. Но это имя оказалось уже занято, и, по легенде, Триджелл выбрал новое название из слов, начинающихся с буквы «S» и содержащих «M» и «B» в том же порядке, получив их командой grep
по системному словарю:
grep -i '^s.*m.*b' /usr/share/dict/words
samba
В дальнейшем танцевать в ритме Samba стало для Триджелла по большому счету его основной деятельностью. С 1994 года он возглавляет в университете проект, в рамках которого создавалась распределенная файловая система HiDIOS для компьютеров Fujitsu, и за это время выходит несколько релизов Samba, в том числе вторая версия, где впервые появилась поддержка службы каталога в стиле NT4.
С 2001 года Триджелл работает в VA Linux Systems над устройствами сетевого хранения данных и развивает Samba в части оптимизации под ядро Linux. Работая в Quantum с октября 2001 года над корпоративными системами хранения, Триджелл добавляет в Samba возможность работы Linux-компьютера в составе домена Active Directory. С января 2003 года Триджелл работал над развитием систем хранения в исследовательском центре IBM, и в том же году выходит Samba 3, в которой была реализована поддержка протоколов SMB2.2 и SMB3.
В части функций Active Directory переломным моментом для проекта Samba стал 2004 год, когда комиссия Европейского союза признала Microsoft виновной в злоупотреблении монопольным положением и наложила штраф в 500 млн евро с требованием предоставить полную информацию о протоколах для обеспечения совместимости. Триджелл работал в исследовательском центре IBM, там решили воспользоваться ситуацией и запросить необходимые спецификации, но теперь этот запрос уже соответствовал интересам корпорации Microsoft. Для усиления своих позиций в судах несколько лет спустя Microsoft даже наняла разработчика Samba Криса Хартела (Chris Hertel) для написания документации.
Открывшиеся возможности определили дальнейший вектор развития продукта, и с 2005 года Триджелл полностью переключился на разработку Samba 4 как участник OSDL (Open Source Development Laboratory). Эту некоммерческую организацию IBM учредила вместе с другими технологическими гигантами — Intel, Hitachi, Hewlett-Packard, Fujitsu, NEC, Computer Associates — для ускорения проникновения Linux в корпоративную среду. Через нее финансировались ключевые проекты, именно там работал сам Линус Торвальдс и несколько других разработчиков ядра операционной системы.
При этом важно понимать, что директора этих ИТ-компаний не были какими-то наивными альтруистами, коммунистами или сторонниками культуры хиппи. Просто к тому моменту общество уже пришло к осознанию, что, закрывая исходные коды, коммерческие организации создают точно такие же барьеры для развития индустрии, как это делала AT&T несколькими десятилетиями ранее, ограничивая доступ к использованию своих патентов. Поэтому совместная работа над системными решениями может значительно способствовать развитию и выгодна всем.
Благодаря беспрецедентной открытости компании Microsoft (по известным причинам) через семь лет удалось выпустить релиз Samba 4, в котором появилась возможность работы в роли контроллера Active Directory с Heimdal Kerberos и анонсировалась возможность промышленной эксплуатации, см. рис. 157. На тот момент было реализовано только 40% от необходимого функционала, но этого хватило, чтобы ряд компаний стал делать на этом бизнес.
В вопросах внедрения Samba AD дальше всех продвинулась французская компания Tranquil IT (https://www.tranquil.it), которой на данный момент удалось реализовать более 300 проектов, в самом крупном из которых было порядка 140 контроллеров домена. Начинали они с развертывания доменов NT4 на Samba 3, поэтому часть клиентов им нужно было просто обновить. Выступая на конференции SambaXP в 2017 году, основатели компании Денис и Винсент Кардон (Denis Cardon, Vincent Cardon) отметили, что для миграции небольших инфраструктур на Samba AD препятствий практически нет, а проблемы в основном связаны с недостаточной квалификацией сотрудников: незнанием компьютерных сетей, устройства Active Directory, отсутствием навыков администрирования Linux.
Опытные инженеры в основном хвалят продукт, но предостерегают, что потребуется проштудировать большой объем плохо написанной документации, перечитать сотни тематических подписок, выполнить бессчетное количество экспериментов, и все равно что-то будет работать не так, как нужно, или не работать вовсе, а претензии можно будет предъявить только самому себе. Кстати, в части документации обязательно обратите внимание на сайт Tranqil IT, на который ссылаются даже на официальном сайте wiki.samba.org.
Важно
Берите продукт, используйте его. А если он не решит ваших задач, то вспомните, сколько вы за него заплатили. И не забудьте отправить мне отчет об ошибке.
Если с маленькими инфраструктурами понятно, то крупные проекты внедрения возможны только при значительных доработках продукта, которые Tranquil IT воплощала через коммерческие заказы в Catalyst, например:
При внедрении продукта в центральных банках западноафриканских государств была реализована поддержка последнего входа (4.4.0).
На проекте министерства окружающей среды Франции потребовалось реализовать поддержку дополнительных протоколов шифрования (4.7.0), журналов в формате JSON (4.9.0), функций экспорта/импорта объектов групповой политики (4.9.0).
Внедрение в министерстве культуры и коммуникаций Франции не обошлось без реализации Read Only Domain Controller (4.7.0).
Внедрение в министерстве государственных финансов Франции стало возможным благодаря устранению ограничения в 4 ГБ на размер базы данных (4.9.0), разработке графических инструментов анализа топологии (4.9.0), улучшению управления DNS (4.9.0) и работы pre-fork (4.10.0).
Для национального агентства по безопасности информационных систем значительно доработана документация в части функций безопасности.
Проект развивается не быстро, но за последние годы в направлении Enterpise было сделано уже достаточно много, чтобы даже крупные проекты стали принципиально возможны. Конечно, еще нет поддержки лесов, штатной репликации SYSVOL, не стоит рассчитывать на поддержку таких приложений, как Exchange, которые имеют сильную привязку к расширенным функциям Active Directory, но при необходимости без всего этого можно обойтись. Основные причины, по которым мы не сделали выбор в пользу Samba, заключаются в другом.
Если проанализировать последние коммиты, то можно увидеть, что большинство улучшений в Samba вносят сотрудники Catalyst, Red Hat (IBM), SerNet, SUSE, имеющие прямой коммерческий интерес, а иногда даже конкурирующие между собой. Но интересы Microsoft никуда не делись, и этот держатель фишек продолжит препятствовать развитию проекта в той мере, насколько это будет уместно в рамках установленных правил. Ну, и самое главное, что проект Samba AD изначально был направлен на создание совместимости с Windows, а не разработку нативного доменного решения для Linux, поэтому участникам Samba Team навсегда уготована роль догоняющих.
Служба каталога FreeIPA
Возможность вводить Linux-компьютеры в домен Active Directory впервые появилась в службе Winbind из состава компонентов Samba, что позволило сократить разрыв между двумя мирами и начать проникновение Linux в корпоративную среду, где в то время безгранично доминировала компания Microsoft со своей активной директорией. Но если Samba искала простые способы интеграции с Windows, то команда FreeIPA направила свои усилия на то, чтобы создать новое решение с оглядкой на лучшие практики Microsoft, которое бы в полной мере соответствовало потребностям Linux, как сделала сама Microsoft в конце 90-х, когда создала свою Active Directory, используя передовые технологии UNIX, такие как LDAP, Kerberos и DNS.
Проект IPA (https://www.freeipa.org) официально стартовал в 2007 году, но готовиться к этому компания Red Hat начала сильно раньше, когда в 2004 году приобрела у компании AOL (America Online) права на код Netscape Directory Server, а заодно и команду разработчиков, которые развивали этот продукт последнее десятилетие. Если внимательно приглядеться к истории LDAP, то за сухими формулировками из пресс-релизов откроется настоящая детективная история, полная экшена, конфликтов интересов, провалов и свержений, по которой можно снять настоящий блокбастер, см. рисунок рис. 158.
Изначально стандарт электронных каталогов X.500 был разработан международным союзом электросвязи (International Telecommunication Union, ITU), и драйвером развития технологии были телекоммуникационные компании, которым нужно было предоставлять авторизованные услуги связи миллионам абонентов. К слову, в инфраструктуре российских операторов из большой тройки LDAP тоже использовался.
Основную роль в разработке технологии сыграли исследователи из Мичиганского университета (University of Michigan), Университетского колледжа Лондона (University College London), компаний PSI, Critical Angle, Netscape, Sun, America Online, HP и др. Компания Microsoft тоже участвовала в обсуждении стандарта, но ее роль заключалась в большей степени в том, что она показала альтернативный способ применения технологии для построения корпоративных доменов, и далее эстафетную палочку у телекоммуникационных компаний перехватили уже ИТ-гиганты.
На момент покупки Netscape их программный код вобрал в себя последние разработки ведущих игроков рынка, поэтому в LDAP-сервере Red Hat до сих пор таится большой потенциал, который пока еще не задействован в их IdM-решении. Например, 389 Directory Server позволяет выстраивать трехуровневую топологию, состоящую из Мастеров, Хабов и Потребителей, в которой практически нет ограничений по горизонтальному масштабированию для построения систем, испытывающих колоссальные нагрузки по операциям чтения.
В фокусе внимания FreeIPA находится разработка функций централизованной идентификации, политик и аудита (от англ. identity, policy, audit). Для этого разработчики интегрировали с LDAP-сервером эталонную реализацию Kerberos SSO (MIT Kerberos) и одну из лучших реализаций DNS-службы (ISC Bind9). А для взаимодействия с Active Directory команда Red Hat воспользовалась наработками проекта Samba AD, в создании которых принимала и продолжает принимать участие.
Еще большее значение имеют усилия команды FreeIPA в развитии клиентской части. Переосмысление потребностей Linux в части аутентификации привело к созданию новой службы SSSD, работа над которой в 2009 году была выделена в отдельный проект. Данная аббревиатура официально расшифровывается как System Security Services Daemon, но, как рассказывает один из разработчиков продукта в кулуарах, это на самом деле первые буквы имен четырех основателей: Simo Sorce, Sumit Bose, Stephen Gallagher и Dmitri Pal.
Для становления проекта SSSD потребовалось некоторое время, но на сегодняшний день эта служба практически полностью вытеснила Winbind и является самым правильным ответом на вопрос о том, как обеспечить работу компьютера под управлением операционной системы из семейства Linux в составе домена. С помощью этой службы компьютер Linux можно ввести в домен Microsoft Active Directory, Samba AD и даже использовать в качестве бэкенда простой LDAP v3 - сервер. Но в полном объеме продукт раскрывается, конечно же, если в роли бэкенда выступает FreeIPA. В этом случае становятся доступны такие функции, как правила HBAC и SUDO, политики монтирования AutoFS, сопоставление пользователей SELinux. А на компьютерах под управлением Astra Linux, оснащенных подсистемой безопасности PARSEC, через FreeIPA можно централизованно управлять мандатным доступом для защиты конфиденциальной информации.
Для того чтобы окончательно развеять сомнения, сравним продукты через анализ программного кода. Разработка Samba AD выполнялась в условиях нехватки ресурсов, поэтому исходные коды предыдущей версии, отвечающие за работу SMB-протокола, были добавлены на скорую руку практически без изменений, и эти проблемы остаются в проекте до сих пор: достаточно открыть репозиторий с исходными кодами, и вы увидите папку с названием «Samba 3». И так было всегда. Например, еще в начале 2000-х Люк Лейтон (Luke Leighton) предлагал переписать продукт на микросервисную архитектуру, но привлечь финансирование ему не удалось, поэтому форк Samba TNG (The Next Generation) в 2005 году окончательно умер. И только 20 лет спустя в версии 4.16 его идеи наконец-то были реализованы, и службы MS-RPC были разнесены по отдельным приложениям с взаимодействием через сокеты unix. В проекте FreeIPA дела обстоят совсем иначе: разработчики вкладывают значительные ресурсы в рефакторинг программного кода. Например, с выходом Python3 весь программный код был переписан под новый язык, чтобы задействовать его новые возможности.
Если посмотреть на объем кода командой wc -l $(git ls-files)
, то окажется, что в Samba сейчас почти 5.5 млн строк, в то время как в проектах FreeIPA суммарно только 3 млн, но, как известно, больше не значит лучше, и следует учесть еще два обстоятельства:
Проект Samba 4 вобрал в себя порядка 2,5 млн строк Samba 3, где была реализована поддержка протоколов SMB, что не относится напрямую к функциям службы каталога. И с учетом этой поправки объем кода будет уже сопоставим.
Продукт FreeIPA использует программный код Samba AD для интеграции с Active Directory, и, более того, именно сотрудники Red Hat помогают проекту Samba в развитии этой функциональности.
Еще более показательным окажется сравнение динамики изменений, которую можно получить командой shortstat
.
cd samba/
git log --shortstat --pretty='^ "%h", "%as", "%an", ' | tr "\n" " " | tr "^" "\n"
"4c291514a9e", "2023-10-17", "Joseph Sutton", 2 files changed, 2 insertions(+), 12
deletions(-)
"d209cdf4f0c", "2023-10-17", "Joseph Sutton", 2 files changed, 3 insertions(+), 2 deletions(-
)
"37594035547", "2023-10-17", "Joseph Sutton", 1 file changed, 1 insertion(+), 1 deletion(-)
Если сравнить показатели по добавлению/удалению строк, то станет очевидным, что в последние годы компания Red Hat инвестировала в проект значительно больше усилий, чем Samba Team. И это не считая того, что часть изменений Samba внесена теми же сотрудниками Red Hat.
Выводы
По нашему мнению, при планировании полного перехода на отечественные операционные системы, использующие в подавляющем большинстве ядро Linux, стратегически правильным выбором будут, конечно же, решения на базе службы каталога FreeIPA. Именно с этим бэкендом клиентская служба SSSD реализует весь свой потенциал, именно эту службу каталога будет активно развивать открытое сообщество.
По результатам наших нагрузочных тестов мы с уверенностью можем сказать, что служба каталога FreeIPA сможет закрыть потребности предприятий любого масштаба. Мы поднимали домены, содержащие 400 контроллеров, и загружали в базу миллионы учетных записей пользователей — во всех тестах FreeIPA по производительности показывает сопоставимые результаты с Active Directory. Также значительный прирост производительности бэкенда ожидается с переводом движка встроенной СУБД с Berkeley DB на LMDB, официальная поддержка которого уже появилась в LDAP-каталоге 389 Directory Server .
Возвращаясь к службе каталога Samba AD, мы можем сказать, что она подойдет тем предприятиям, которые планируют заменить только контроллеры домена, оставляя всю инфраструктуру рабочих мест под управлением операционной системы Windows. Сильной стороной Samba AD является ее возможность мимикрировать под Active Directory.
Но даже в случае выбора Samba AD нельзя ожидать, что можно будет просто заменить одни контроллеры на другие, и уж тем более не стоит рассчитывать на надежную работу домена, в составе которого будут одновременно контроллеры Samba AD и Microsoft Active Directory: эксплуатация такой инфраструктуры потребует от сотрудников запредельных компетенций по устройству активной директории вообще и каждой реализации в частности, если такие вообще есть на рынке труда. Как говорится, кто считает, что трудно найти настоящую любовь, тот не искал разработчиков на Scala.
Система ALD Pro и ее компоненты
Продукт ALD Pro состоит из нескольких подсистем, каждую из которых нужно устанавливать в отдельной операционной системе во избежание проблем с зависимостями пакетов и нежелательной конкуренции за ресурсы. Поэтому вместе с лицензией на контроллер домена ALD Pro предоставляется восемь лицензий на ALSE, одна из которых потребуется для установки контроллера, а остальные можно использовать для установки любых подсистем. Типовая схема развертывания продукта в отказоустойчивом режиме с использованием двух лицензий на контроллеры ALD Pro представлена на рис. рис. 161.
Контроллер домена
В ALD Pro мы придерживаемся концепции домена Microsoft, поэтому контроллер домена – это сервер, управляющий доступом к сетевым ресурсам. На контроллер домена устанавливаются следующие компоненты:
NTP — для синхронизации времени была выбрана служба Chrony.
Служба каталога — в основу была положена служба FreeIPA, в состав которой входят:
KDC — используется MIT Kerberos.
DNS-сервер — используется ISC Bind9.
LDAP-каталог — используется 389 Directory Server
Портал управления ALD Pro — реализован на Django с использованием дополнительных компонентов RabbitMQ и Celery.
Через портал управления настраиваются в том числе объекты групповых политик, параметры которых предоставляются компьютерам через LDAP. Применение параметров на рабочих станциях выполняется с использованием Salt-скриптов.
Служба синхронизации времени chrony
Синхронизация времени необходима в домене для корректной работы следующих механизмов: протокола аутентификации Kerberos, двухфакторной аутентификации на основе синхронизированных по времени одноразовых паролей, разрешения конфликтов при репликации, возможности сопоставления журналов событий с разных серверов.
Ранее служба синхронизации времени входила в состав FreeIPA, но разработчики этой службы каталога решили сконцентрироваться на решении более системных задач и отдать синхронизацию времени на откуп системным администраторам, поэтому исключили этот компонент из состава продукта.
ALD Pro берет на себя эту задачу. Мы проанализировали лучшие практики реализации синхронизации времени в MS Active Directory и реализовали трехуровневую модель, в состав которой входят корневые серверы времени (аналог ePDC), рядовые контроллеры домена, все остальные серверы и рабочие станции.
Управление синхронизацией времени осуществляется через службу Chrony, которая является открытой реализацией протокола сетевого времени NTP (англ. Network Time Protocol) и рассчитана на работу даже в перегруженных сетях.
Для настройки Chrony используется параметр групповой политики ALD Pro. Как уже было сказано выше, по умолчанию реализуется трехуровневая модель, но администраторы могут реализовать и более сложные схемы, настраивая этот параметр групповой политики вручную.
Служба каталога FreeIPA
Продукт FreeIPA является службой каталога, которая объединяет в себе LDAP-сервер на базе 389 Directory Server , центр распространения ключей Kerberos от MIT и ISC Bind9 в качестве DNS-сервера. Для интеграции с Active Directory на контроллерах FreeIPA устанавливается также компонент Samba AD, который позволяет контроллеру отвечать на RPC-вызовы по протоколу SMB.
Эта служба каталога представляет собой не просто какой-то набор скриптов, с помощью которых можно установить и настроить отдельные компоненты. FreeIPA тесно интегрирует эти компоненты между собой и оборачивает их своим программным интерфейсом JSON-RPC API, через который работает утилита командной строки ipa и веб-портал.
Единая точка входа реализована средствами MIT Kerberos, а DNS-служба построена на базе ISC Bind9, но в качестве базы данных оба компонента используют LDAP-каталог службы 389 Directory Server . Служба FreeIPA автоматически расширяет схему, добавляя необходимые атрибуты и объектные классы, поэтому при вводе компьютера в домен для него автоматически создаются все необходимые DNS-записи, а при продвижении дополнительного контроллера автоматически настраивается репликация.
Если вернуться к MIT KDC, то этот продукт является эталонной реализацией протокола Kerberos V5, который изначально был разработан Массачусетским технологическим институтом и принят в MS Active Directory в качестве основного протокола аутентификации. До сих пор еще довольно часто можно встретить Heimdal Kerberos, но эта реализация была создана для обхода экспортных ограничений USA, поэтому она обладает меньшей совместимостью и не рекомендуется к использованию в гибридных средах.
Служба DNS построена с использованием одного из самых популярных и проверенных временем компонентов — ISC Bind9 (англ. Berkeley Internet Name Domain, BIND). Этот продукт способен выдерживать нагрузку Интернет-провайдеров, и 8 из 10 корневых серверов DNS работают именно на BIND, поэтому потребности даже самых крупных предприятий ему совершенно не страшны.
Портал управления
Система централизованного управления ИТ-инфраструктурой ALD Pro значительно расширяет возможности службы каталога FreeIPA, добавляя групповые политики на базе SaltStack и интеграцию с наиболее востребованными сервисами, такими как файловый сервер, принт-сервер, установка ОС по сети и т.д. Так же как FreeIPA, система ALD Pro оборачивает все свои функции с помощью программного интерфейса JSON API, через который работает портал управления, и этот интерфейс можно использовать для решения задач автоматизации.
В техническом плане портал управления представляет собой серверное веб-приложение, которое устанавливается на всех контроллерах в домене. Это Django-приложение, у которого есть собственная SQL база данных на PostgreSQL, но вся основная информация находится в LDAP-каталоге, поэтому не имеет значения, к порталу какого контроллера домена вы будете обращаться.
Подсистема «Репозиторий программного обеспечения»
Репозиторий ПО является одним из самых важных компонентов ALD Pro, так как в Linux повторное использование кода доведено до абсолюта и без репозиториев невозможно устанавливать и обновлять программное обеспечение. Подсистема реализована на базе продукта RepRepro, который поддерживает создание локальных Debian-совместимых репозиториев.
С помощью подсистемы вы можете создать локальный репозиторий с пакетами операционной системы и частные репозитории для размещения пакетов, которые требуется устанавливать через групповые политики.
Подсистема «Общий доступ к файлам»
Для организации общего доступа к файлам команда ALD Pro выбрала набор компонентов Samba, т.к. в нем реализована поддержка SMB-протокола, через который можно предоставить доступ в том числе клиентам Active Directory с рабочих станций Windows в гибридных сценариях развертывания.
Из коробки Samba максимально приближается к тому, как Linux работает с моделями RWX и UGO. Несовместимые DOS атрибуты, с помощью которых в Windows файл отмечается как «архивный», «скрытый» или «системный», можно отбрасывать (что снижает совместимость с Windows), сопоставлять со стандартными битами Execute (что снижает совместимость с Linux) или хранить в расширенных атрибутах файлов, если это поддерживается файловой системой.
Однако с помощью подключаемых модулей виртуальной файловой системы (англ. Virtual File System, VFS) служба Samba способна имитировать одну из следующих моделей безопасности:
Плагин acl_xattr — позволяет значительно приблизиться к имитации Windows ACL, сохраняя часть информации в расширенных атрибутах, но продолжая активно использовать POSIX ACL, что дает возможность сохранить пользователям Linux прямой доступ к файлам.
Плагин nfs4acl_xattr — переводит файловый сервер в режим максимальной совместимости с Windows ACL, сохраняя всю необходимую информацию в расширенных атрибутах файлов, но это исключает возможность работы с файлами напрямую.
Подсистема «Служба печати»
В ходе реализации проектов импортозамещения на предприятиях крайне важно сохранить привычный уровень удобства в работе с наиболее востребованными сервисами, такими как печать. В продукте ALD Pro подсистема печати реализована с использованием CUPS (англ. Common UNIX Printing System).
Служба CUPS обеспечивает стандартизированный способ взаимодействия между компьютером и принтером, обрабатывает очередь печати, управляет настройками принтера и выполняет другие задачи, связанные с печатью. Она поддерживает различные протоколы, такие как IPP (англ. Internet Printing Protocol), SMB (англ. Server Message Block) и другие, что позволяет подключать принтеры через локальные сети или сети Интернет.
Подсистема «Динамическая настройка узла»
Для поддержки сценария установки операционных систем по сети в продукте ALD Pro реализована подсистема динамической настройки узлов (англ. Dynamic Host Configuration Protocol, DHCP) на базе ISC DHCP.
При необходимости вы можете использовать этот продукт для настройки рабочих станций во всей сети, но вам нужно понимать, что веб-портал имеет ограниченные средства управления и для управления инфраструктурой вам потребуется обращаться к утилитам командной строки.
Подсистема «Установка ОС по сети»
Для установки ОС по сети используется технология PXE (англ. Preboot eXecution Environment, произносится «пикси»), которая создает клиент-серверную среду для загрузки компьютера с сетевой карты без локальных носителей данных, таких как HDD или USB-накопители.
Если в настройках BIOS/UEFI в качестве загрузочного устройства выбрана сетевая карта, то после включения компьютера базовая система передаст управление загрузчику из постоянного запоминающего устройства сетевой карты (ПЗУ). Загрузчик сетевой карты получит настройки с помощью встроенного DHCP-клиента, качает необходимые файлы с PXE-сервера по TFTP или HTTP-протоколу и передаст управление загрузчику операционной системы из этих файлов.
Первоначально для раздачи файлов был выбран упрощенный протокол TFTP (англ. Trivial File Transfer Protocol), работающий поверх UDP, т.к. программный код, обеспечивающий его поддержку на стороне клиентов, можно было уместить на дискетах и даже в ПЗУ сетевых устройств. В продукте ALD Pro используется улучшенная реализация этого сервера от HansPeterAnvin, которая так и называется TFTP-HPA.
По мере удешевления микросхем памяти и увеличения доступного объема функциональность клиентской части стали расширять, поэтому современные PXE-загрузчики поддерживают в том числе и более продвинутый протокол HTTP, который работает поверх TCP. В продукте ALD Pro для раздачи файлов по протоколу HTTP используется веб-сервер от Apache.
Подсистема «Мониторинг»
Для отслеживания состояния серверной группировки в продукте реализована подсистема мониторинга на базе открытой системы мониторинга Zabbix. Веб-интерфейс системы написан на PHP, для хранения данных используется база PostgreSQL.
В продукте используется агентская схема, для этого на все компьютеры домена устанавливается агент Zabbix, но отслеживание состояния включается только после продвижения сервера до одной из подсистем.
Подсистема «Аудит»
Для возможности интеграции продукта с SIEM системами реализована подсистема аудита, которая выступает в роли коллектора и способна принимать события безопасности от всех участников домена. Подсистема основана на использовании syslog-ng —одного из лучших решений. Из коробки вы можете настроить сбор трех простых событий, дополнительная настройка подсистемы возможна через механизм групповых политик.
Совместно с коллегами из компании Positive Technologies был разработан пакет экспертизы, который позволяет анализировать события службы ALD Pro для автоматического выявления инцидентов безопасности.
В продуктовой команде ALD Pro мы сформировали экспертные компетенции по FreeIPA и ее технологическим компонентам: 389 Directory Server , MIT Kerberos, ISC Bind 9. Но знать, как извлечь максимум информации о событиях безопасности из системы и как правильно построить корреляции для точного выявления инцидентов безопасности, — это две большие разницы. Поэтому мы рады нашему сотрудничеству с Positive Technologies (с PT Expert Security Center — командой MaxPatrol SIEM) и благодарны за то, что эксперты компании применили свой опыт работы с Active Directory для выявления подозрительной активности в FreeIPA. Уверены, что новые правила корреляции — заметный вклад в развитие этого направления.
Клиентская часть ALD Pro
В роли клиентской части на доменных машинах в ALD Pro выступает набор из следующих компонентов:
chrony – клиент сервера времени.
aldpro-client – клиентская часть «ALD Pro», через которую устанавливаются и настраиваются остальные клиентские приложения и сервисы.
astra-freeipa-client — утилита от Astra Linux для внесения дополнительных настроек в конфигурацию sssd и других служб в соответствии с требованиями операционной системы.
freeipa-client – клиентская часть подсистемы FreeIPA, настраивает службу SSSD.
krb5-user — поддержка работы с билетами Kerberos, включает утилиты kinit, kdestroy и др.
sssd — набор служб для работы машины в домене.
sssd-ldap — LDAP бэкенд службы SSSD.
ldap-utils — утилиты ldapsearch и другие.
freeipa-admintools — набор утилит администрирования ipa CLI.
salt-minion — клиентская часть групповых политик.
syslog-ng — клиентская часть подсистемы журналирования.
zabbix-agent — клиентская часть подсистемы мониторинга.
Модуль автообнаружения SaltStack-агента — скрипт.
Модуль автообнаружения клиента Samba — скрипт.
Модуль автообнаружения клиента мониторинга — скрипт.
Подробнее об этих компонентах будет рассказано в модулях, посвященных соответствующим системам и работе компьютера в домене ALD Pro.
Перед развертыванием ALD Pro
Минимальные требования к инфраструктуре для развертывания ALD Pro
Для обеспечения базовой функциональности «ALD Pro» нужен только один контроллер домена, но рекомендуется устанавливать не менее двух для обеспечения отказоустойчивости. Это нужно для обслуживания системы без прерывания доступа к сервисам аутентификации и авторизации. Минимальная конфигурация оборудования для развёртывания подсистем приведена в таблице ниже:
Компонент |
Ядер CPU |
RAM |
SSD |
Кол-во |
---|---|---|---|---|
Контроллер домена до 3000 пользователей, из расчета потребностей службы каталога и механизма групповых политик SaltStack |
8 |
16 ГБ |
>= 50 ГБ |
2 шт. |
Дополнительные ресурсы на 10000 пользователей |
10 |
1 ГБ |
+300 МБ |
1 шт. |
Подсистема мониторинга |
2 |
2 ГБ |
>=30 ГБ |
1 шт. |
Подсистема «Динамическая настройка узла» DHCP |
2 |
2 ГБ |
>=30 ГБ |
1 шт. |
Подсистема «Репозитория ПО» |
2 |
2 ГБ |
>=100 ГБ |
1 шт. |
Подсистема «Установка ОС по сети» |
2 |
2 ГБ |
>=30 ГБ |
1 шт. |
Подсистема «Служба печати» |
2 |
2 ГБ |
>=30 ГБ |
1 шт. |
Подсистема «Общий доступ к файлам» |
2 |
2 ГБ |
>=30 ГБ |
1 шт. |
Рекомендации по планированию дополнительных ресурсов службы каталога
От работы доменных служб зависит надежность работы всей ИТ-инфраструктуры, поэтому при планировании домена администраторы должны действовать проактивно и применять различные способы вертикального и горизонтального масштабирования, чтобы исключить проблемы недостаточной производительности. В данном разделе представлены рекомендации, которые помогут вам в планировании ресурсов службы каталога.
Вертикальным масштабированием называют повышение производительности системы за счет повышения производительности отдельного узла путем выделения серверу дополнительных вычислительных ресурсов: оперативной памяти, потоков центрального процессора и т. п.
Объем памяти
В работе службы каталога преобладают операции чтения, поэтому в производительности контроллера решающую роль играет достаточный объем оперативной памяти, чтобы контроллер мог обрабатывать запросы без обращения к медленным дискам.
Файлы каталога расположены в папке /var/lib/dirsrv
. После развертывания первого контроллера размер базы составляет порядка 45 Мб и увеличивается по мере создания объектов, в среднем по 30 КБ на каждую дополнительную учетную запись пользователя. Таким образом, размер файлов на диске можно рассчитать математически: для нужд самой операционной системы контроллеру следует выделить порядка 30-50 ГБ, а под хранение каталога для упрощения расчетов возьмем по 1 ГБ на каждые 35 тысяч объектов. Расчетное значение должно составлять не более 40% от доступного пространства.
Для загрузки каталога требуется больше оперативной памяти, чем на диске, т. к. для ускорения операций поиска служба ns-slapd индексирует данные каталога. Пустая база данных занимает в памяти порядка 65 Мб, и это значение растет по мере увеличения числа объектов, в среднем по 50 КБ на каждую дополнительную учетную запись. По ходу работы службы каталога для ускорения операций чтения происходит кэширование запросов, и потребление оперативной памяти возрастает до 100 КБ на каждую учетную запись каталога. Таким образом, минимально необходимый объем оперативной памяти можно рассчитать математически: для нужд самой операционной системы контроллеру следует выделить порядка 2-3 ГБ (с учетом SaltMaster все 16, см. минимальные требования), а для работы с каталогом в целях упрощения расчетов возьмем по 1 ГБ на каждые 10 тысяч объектов:
Приведем несколько примеров:
Для работы с каталогом, в котором содержится 10 000 пользователей и 100 групп, контроллеру нужно выделить порядка 4 ГБ ОЗУ:
\[ОЗУ, ГБ = 3 + 10 100\ объектов / 10 000 ≈ 4\ Гб\ ОЗУ\]Для работы с каталогом, в котором 100 000 пользователей и 30 000 групп, контроллеру нужно выделить до 16 ГБ ОЗУ:
\[ОЗУ, ГБ = 3 + 130 000\ объектов / 10 000 ≈ 16\ Гб\ ОЗУ\]
Ресурсы центрального процессора
Если требуемый объем оперативной памяти зависит от размера базы данных, то количество ресурсов центрального процессора определяется тем, сколько пользователей должен обслуживать конкретный контроллер. Например, в базе может быть 100 тысяч пользователей, но нагрузка по их обслуживанию может распределяться между 20 репликами, и в этом случае на каждый контроллер будет приходиться не более 5 тысяч обслуживаемых пользователей.
Приложения имеют разный сценарий взаимодействия с каталогом, какие-то нагружают его больше, какие-то меньше, таким образом у каждой организации получается свой уникальный профиль использования ресурсов этой службы, и предложить какой-то универсальный нормативный показатель на одного сотрудника не представляется возможным. Поэтому администраторам следует рассчитать данный показатель для своей организации самостоятельно, достигая использования ЦПУ на уровне 40% от максимума в пиковые периоды, а отправной точкой может быть выделение одного потока для работы операционной системы и еще по одному потоку на каждую тысячу пользователей, обслуживаемых службой каталога. С учетом потребности службы SaltStack рекомендуется брать значение в два раза больше.
Приведем несколько примеров:
- Пример 1.
Для обслуживания 2 - 3 тысяч пользователей контроллеру домена нужно выделить порядка 4 потоков:
\[ЦПУ\ потоков = (1 + 3000 / 1000) * 2 = 8\]Компания RedHat в своей документации рекомендует использовать контроллеры домена именно такой производительности, но эта рекомендация не подойдет крупным организациям, в штате которых работает несколько сотен тысяч сотрудников, т. к. контроллер, обслуживающий 10 тысяч сотрудников, будет в три раза эффективнее использовать оперативную память в пересчете на активного пользователя, чем контроллер, обслуживающий 3 тысячи сотрудников.
- Пример 2.
Для обслуживания 10 тысяч пользователей контроллеру домена нужно выделить 22 ядра.
\[ЦПУ\ потоков = (1 + 10000 / 1000) * 2 = 22\]Повторимся, что данные оценки сильно зависят от сценария использования службы каталога, поэтому на такое количество пользователей мы рекомендуем выделять порядка 8-12 потоков.
- Пример 3.
Если под контроллер домена выделить физический сервер с двумя процессорами Xeon Silver (48 потоков), то теоретически он сможет обслуживать 20+ тысяч пользователей.
\[ЦПУ\ потоков = (1 + 23500 / 1000) * 2 = 48\]При планировании таких контроллеров следует принимать во внимание ограничения по пропускной способности сети. Для обслуживания такого числа пользователей потребуется не менее гигабитного интерфейса.
Пропускная способность сети
В процессе обслуживания клиентов контроллеры домена, как правило, получают небольшие входящие запросы на предоставление относительно больших объемов данных, поэтому на контроллерах обычно преобладает исходящий трафик.
Любые оценки являются субъективными, но в качестве общих рекомендаций следует исходить из того, что при количестве пользователей до 5 000 будет достаточно интерфейса с пропускной способностью в 100 Мбит/с, а если предполагается обслуживать больше пользователей, установите на контроллере интерфейс с пропускной способностью в 1 Гбит/с. В результате оптимизации нужно добиться, чтобы показатель использования сети не выходил за пределы 40% от максимума в пиковые периоды.
Учитывая то, что внешние каналы связи редко достигают гигабитных скоростей и активно используются пользователями для выхода в Интернет, в каждом офисе рекомендуется создавать отдельный сайт и размещать в нем один-два контроллера для локальной обработки клиентских запросов. Такой подход к организации домена позволит разгрузить VPN-туннели между офисами и использовать эти каналы связи только для репликации.
Рекомендации по именованию домена «ALD Pro» и компьютеров в нем
В документации и обучающих курсах применяются домены contoso.com или ad.example.test, которые используют для обучающих целей, но не приемлемы для развёртывания продуктивных сред. Поэтому мы рекомендуем придерживаться следующих правил:
Лучший вариант - это использовать свой домен третьего уровня. Например, если организация приобрела домен mycompany.ru для своего Web-сайта и почты, то для «ALD Pro» можно использовать доменное имя третьего уровня ald.mycompany.ru. Если в группе компаний планируется несколько юридических лиц, то каждому юр. лицу можно создать домен четвертого уровня. Таким образом будет гарантироваться отсутствие конфликтов с публичными DNS именами.
Если вы не хотите использовать публичный домен, то можно задействовать зоны «.lan» или «.internal». Во многих инструкциях упоминается возможность использования зоны «.local» в качестве частного домена верхнего уровня для внутренних нужд предприятия, но в этом случае вы столкнетесь с конфликтами Multicast DNS (RFC6762) и невозможностью использования протокола zeroconf, который реализован в Linux службой Avahi, поэтому данную зону мы не рекомендуем.
Важно
Предложенные зоны «.lan» и «.internal» не зарегистрированы в глобальном списке Top-Level Domains, но всегда будет оставаться вероятность, что их введут в эксплуатацию в будущем и она будет также с проблемой разрешения имен. Соответственно, используйте зоны «.lan», «.internal» и «.local», учитывая эти риски.
Выбор префикса для домена:
Выберите префикс, который вряд ли устареет, т. е. избегайте имен, таких как линейка продуктов или операционная система, которые могут измениться в будущем. Рекомендуется использовать универсальные имена, такие как corp, ent или ald.
Выберите префикс, содержащий только стандартные символы Интернета a–z, 0–9 и (-), но не полностью числовые.
Выберите префикс длиной не более 15 символов, потому что первый компонент доменного имени будет использован в качестве NetBIOS-имени.
При выборе префикса учитывайте, что два домена не смогут работать в доверительных отношениях, если у них будут совпадать NetBIOS-имена, например, если у вас текущий домен AD DS имеет имя corp.mycompany.com, то не стоит для домена «ALD Pro» использовать имя corp.mycompany.ru. Иначе вы не сможете создать между этими доменами доверительные отношения.
Важно
В стандарте доменных имен (RFC1034) разрешается использовать заглавные буквы латинского алфавита A-Z, но служба каталога FreeIPA налагает дополнительные требования и обязует использовать только нижний регистр символов.
Если вы в команде ввода в домен укажите имя хоста большими буквами, то процедура завершится ошибкой. Если поменять имя хоста на заглавные (например, FS-01.ald.company.lan) после ввода в домен, то вы столкнетесь с ошибками при установке подсистем на такие хосты.
На предприятии принято называть серверы и персональные компьютеры по заданной конвенции наименований, например, конвенция для серверов <location>-<type>-<number>.<domain>
разрешает такой вариант наименования msk-dc-1.ald.company.lan. Во-первых, это нужно для стандартизации и общего понимания архитектуры системы, а во-вторых, позволит использовать эту особенность в заданиях автоматизации. Например, имя узла dc-1 с легкостью разделяется на части по разделителю «-» с помощью команды cut
:
$ echo "dc-1.ald.company.lan" | cut -d"." -f 1 | cut -d"-" -f 1
Результат выполнения покажет, что выбранный узел является контроллером, а не мониторингом:
admin@dc-1:~$ echo "dc-1.ald.company.lan" | cut -d"." -f 1 | cut -d"-" -f 1
dc
На имена серверов, понятное дело, не стоит сильно полагаться, т.к. какой-нибудь dc-18 может быть еще не контроллером, а обычным сервером, который только предполагалось сделать контроллером домена. Но мы надеемся, что основная суть понятна.
Практика и тестирование
Заключение
В этом модуле мы познакомились со службами каталога, а в следующем будем уже устанавливать первый контроллер и, конечно же, вводить клиентскую машину в домен.