Модуль 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.

рис. 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.

рис. 154 Политика паролей для участников группы администраторов
Механизм политик паролей позволяет для каждой группы пользователей создать отдельный набор правил, которые поддерживают стандартные требования к паролям MIT Kerberos. Система будет сверяться с этим списком правил каждый раз, когда пользователь захочет установить себе новый пароль. В случае если пользователь входит сразу в несколько групп, будет применена самая строгая политика с наивысшим приоритетом. Если на пользователя не распространяется действие ни одной политики, ему будет назначена глобальная политика по умолчанию (global_policy).
Политики HBAC (англ. Host-based access control — контроль доступа к узлу) задают набор правил для настройки доступа пользователей или групп пользователей к определенным хостам с использованием конкретных PAM-сервисов. Механизм реализован средствами PAM-модуля службы SSSD. Например, после установки первого контроллера в домене будет правило allow_all (см. рис. 155), которое рекомендуется назначить только на администраторов, а для обычных пользователей создать еще одно правило, ограничивающее их доступом только к обычным рабочим станциям.

рис. 155 Политика доступа к узлу
Похожим образом работают политики повышения привилегий (правила SUDO), которые позволяют дать пользователю или группе пользователей возможность выполнять на определенных хостах заданные команды через утилиту sudo. Например, вы можете дать возможность контент-менеджеру сайта при необходимости перезапускать веб-сервер с использованием команды sudo systemctl restart apache2.service»
.
Базовые политики FreeIPA очень полезны, но они не позволят вам изменить окружение пользователей и компьютеров, установить и настроить дополнительное программное обеспечение, поэтому в продукте ALD Pro реализованы дополнительные групповые политики за счет интеграции с системой конфигурирования SaltStack, см. рис. 156.

рис. 156 Групповые политики ALD Pro
Групповые политики ALD Pro работают так же, как в MS AD, по методу Pull. Параметры извлекаются из домена по протоколу LDAP с учетом положения пользователя/компьютера в иерархии структурных подразделений. Для обеспечения безопасности при подключении к серверу клиентская служба aldpro-salt-minion выполняет аутентификацию по протоколу Kerberos V5 с использованием учетной записи компьютера из файла /etc/krb5.keytab. Для снижения нагрузки с контроллеров домена суммирование параметров выполняется на стороне клиента. Для повышения надежности применения параметров групповых политик изменения в операционную систему компьютера вносятся с помощью скриптов одной из лучших систем конфигурирования SaltStack, которая предоставляет множество проверенных модулей для управления содержимым конфигурационных файлов различных форматов.
Продуктовая команда ведет непрерывную работу по расширению перечня параметров групповых политик, доступных из коробки, но при необходимости системные администраторы могут самостоятельно разработать дополнительные параметры, с помощью которых можно обеспечить централизованное управление любыми корпоративными приложениями.
В завершение следует отметить, что базовые возможности службы каталога значительно расширяются дополнительными подсистемами, которые построены на хорошо известных компонентах с открытым исходным кодом:
Подсистема «Репозиторий программного обеспечения» (Reprepro)
Подсистема «Общий доступ к файлам» (Samba)
Подсистема «Служба печати» (CUPS)
Подсистема «Динамическая настройка узла» (ISC DHCP)
Подсистема «Установка ОС по сети» (TFTP HPA + PXE)
Подсистема «Мониторинг» (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), и Триджеллу понадобилось организовать доступ с 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% от необходимого функционала, но этого хватило, чтобы ряд компаний стал делать на этом бизнес.

рис. 157 История развития проекта Samba
В вопросах внедрения Samba AD дальше всех продвинулась французская компания Tranquil IT (https://www.tranquil.it), которой на данный момент удалось реализовать более 300 проектов, в самом крупном из которых было порядка 140 контроллеров домена. Начинали они с развертывания доменов NT4 на Samba 3, поэтому часть клиентов им нужно было просто обновить. Выступая на конференции SambaXP в 2017 году, основатели компании Tranquil IT Денис и Винсент Кардон (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).
Для национального агентства по безопасности информационных систем значительно доработана документация в части функций безопасности.
Проект Samba развивается не быстро, но за последние годы в направлении Enterpise было сделано уже достаточно много, чтобы даже крупные проекты стали принципиально возможны. Конечно, нет поддержки лесов, штатной репликации SYSVOL, не стоит рассчитывать на поддержку некоторых приложений, таких как Exchange, имеющих сильную привязку к расширенным функциям Active Directory, но при необходимости без всего этого можно обойтись. Основные причины, по которым мы не сделали выбор в пользу Samba, заключаются в другом.
Проект Samba AD изначально был направлен на то, чтобы можно было создать отдельный лес из одного домена полностью на контроллерах Samba для обслуживания исключительно Windows-компьютеров. Для управления Linux-инфраструктурой домены Samba ничем не лучше, чем MS Active Directory, а возможности Samba по внедрению в состав существующих лесов Active Directory (тем более при наличии дочерних доменов) крайне ограничены. Более того, такие попытки приводят к большому количеству трудно отслеживаемых и зачастую нерешаемых проблем, что не только не дает никаких преимуществ в реализации проектов замещения, но и ставит их под угрозу.
Например, всем известно, что Windows-компьютеры загружают шаблоны групповых политик из общей папки SYSVOL, но мало кто обращает внимание на то, что DFS-клиент доменного компьютера обслуживается ближайшим контроллером за счет того, что DNS-сервер Microsoft в зависимости от IP-адреса клиента поднимает A-записи соответствующих контроллеров в начало списка. Учитывая, что DNS-сервер от Samba не реализует такую логику, работа групповых политик Windows в больших инфраструктурах окажется невозможна.
Учитывая все вышесказанное, мы настоятельно рекомендуем создавать новую службу каталога изначально под Linux на базе FreeIPA и интегрировать ее с заменяемой службой MS AD только по открытым протоколам, чтобы обеспечить стабильную работу гибридной инфраструктуры.
Служба каталога 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.

рис. 158 История развития FreeIPA
Изначально стандарт электронных каталогов 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.
В случае FreeIPA служба SSSD использует идентификаторы безопасности POSIX, хоторые хранятся напрямую в службе каталога, а не рассчитывает их с использованием вероятностей из идентификаторов SID. Вам становятся доступны такие функции, как правила HBAC и SUDO, политики монтирования AutoFS. На компьютерах под управлением 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 в развитии этой функциональности.

рис. 159 Сравнение объема кода по количеству строк
Еще более показательным окажется сравнение динамики изменений, которую можно получить командой shortstat
.
$ cd samba/
$ git log --shortstat --pretty='^ "%h", "%as", "%an", ' | tr "\n" " " | tr "^" "\n"
"4c291514a9e", "2023-10-17", "Joseph Sutton", 2 files ...
"d209cdf4f0c", "2023-10-17", "Joseph Sutton", 2 files ...
"37594035547", "2023-10-17", "Joseph Sutton", 1 file ...
Если сравнить показатели по добавлению/удалению строк, то станет очевидным, что в последние годы компания Red Hat инвестировала в проект значительно больше усилий, чем Samba Team. И это не считая того, что часть изменений Samba внесена теми же сотрудниками Red Hat.

рис. 160 Динамика изменений по проектам
Выводы
По нашему мнению, при планировании полного перехода на отечественные операционные системы, использующие в подавляющем большинстве ядро 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.

рис. 161 Типовая схема развертывания ALD Pro
Контроллер домена
В 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, двухфакторной аутентификации на основе синхронизированных по времени одноразовых паролей, разрешения конфликтов при репликации, возможности сопоставления журналов событий с разных серверов.
Мы проанализировали лучшие практики реализации синхронизации времени в 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, который позволяет контроллеру формировать корректный PAC-сертификат и отвечать на 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, сохраняя всю необходимую информацию в расширенных атрибутах файлов, но это исключает возможность работы с файлами напрямую из Linux.
Подсистема «Служба печати»
В ходе реализации проектов импортозамещения на предприятиях крайне важно сохранить привычный уровень удобства в работе с наиболее востребованными сервисами, такими как печать. В продукте 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 используется улучшенная реализация этого сервера от Hans Peter Anvin, которая так и называется TFTP-HPA.
По мере удешевления микросхем и увеличения доступного объема памяти функциональность загрузчиков стали расширять, поэтому современные прошивки сетевых карт поддерживают в том числе и более продвинутый протокол 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, через которую устанавливаются и настраиваются остальные клиентские приложения и сервисы. Содержит в том числе скрипты для автоматического обнаружения сервисов, например, aldpro-client-service-discovery и aldpro-samba-discovery.
astra-freeipa-client — утилита от Astra Linux для внесения дополнительных настроек в конфигурацию sssd и других служб в соответствии с требованиями операционной системы.
freeipa-client – клиентская часть подсистемы FreeIPA, настраивает службу SSSD.
krb5-user — поддержка работы с билетами Kerberos, включает утилиты kinit, kdestroy и др.
sssd — набор служб для работы машины в составе домена.
sssd-ldap — LDAP бэкенд службы SSSD.
ldap-utils — утилиты ldapsearch, ldapmodify и другие.
freeipa-admintools — набор утилит администрирования ipa CLI.
aldpro-salt-minion и salt-aldpro-salt-common — пакеты кастомизированной службы salt-minion, которая обеспечивает работу групповых политик ALD Pro.
syslog-ng — клиентская часть подсистемы журналирования.
zabbix-agent — клиентская часть подсистемы мониторинга.
Подробнее об этих компонентах будет рассказано в следующих модулях, которые посвящены соответствующим подсистемам и работе компьютера в домене ALD Pro в целом.
Перед развертыванием ALD Pro
Минимальные требования к инфраструктуре для развертывания ALD Pro
Для обеспечения базовой функциональности ALD Pro нужен только один контроллер домена, но для обеспечения отказоустойчивости рекомендуется устанавливать не менее двух серверов, поскольку такая конфигурация позволит обновлять контроллеры и выполнять другие задачи обслуживания без прерывания сервисов аутентификации и авторизации. Минимальная конфигурация оборудования для развёртывания подсистем приведена в нижеследующей таблице.
Компонент |
Ядер ЦПУ |
RAM |
SSD |
Кол-во |
---|---|---|---|---|
Контроллер домена |
||||
для обслуживания до 3000 пользователей и 3000 компьютеров из расчета потребностей службы каталога и механизма групповых политик |
4 шт. |
8 ГБ |
>= 50 ГБ |
2 шт. |
для обслуживания 10000 дополнительных компьютеров |
10 шт. |
- |
- |
- |
для хранения 10000 дополнительных пользователей в каталоге |
- |
0.5 ГБ |
0.5 ГБ |
- |
Подсистема «Репозитории ПО» |
2 шт. |
2 ГБ |
>=100 ГБ |
1 шт. |
Подсистема «Общий доступ к файлам» |
2 шт. |
2 ГБ |
>=30 ГБ |
1 шт. |
Подсистема «Служба печати» |
2 шт. |
2 ГБ |
>=30 ГБ |
1 шт. |
Подсистема «Динамическая настройка узла» DHCP |
2 шт. |
2 ГБ |
>=30 ГБ |
1 шт. |
Подсистема «Установка ОС по сети» |
2 шт. |
2 ГБ |
>=30 ГБ |
1 шт. |
Подсистема «Мониторинг» |
2 шт. |
2 ГБ |
>=30 ГБ |
1 шт. |
Подсистема «Аудит» |
2 шт. |
2 ГБ |
>=30 ГБ |
1 шт. |
Рекомендации по планированию дополнительных ресурсов службы каталога
От работы доменных служб зависит надежность работы всей ИТ-инфраструктуры, поэтому при планировании домена администраторы должны действовать проактивно и применять различные способы вертикального и горизонтального масштабирования, чтобы исключить проблемы недостаточной производительности. В данном разделе представлены рекомендации, которые помогут вам в планировании ресурсов службы каталога.
Вертикальным масштабированием называют повышение производительности системы за счет увеличения производительности отдельного узла путем выделения серверу дополнительных вычислительных ресурсов: оперативной памяти, потоков центрального процессора и т. п.
Объем памяти
В работе службы каталога преобладают операции чтения, поэтому в производительности контроллера решающую роль играет достаточный объем оперативной памяти, чтобы контроллер мог обрабатывать запросы без обращения к медленным дискам.
Файлы каталога расположены в папке /var/lib/dirsrv
. После развертывания первого контроллера размер базы составляет порядка 45 Мб и увеличивается по мере создания объектов, в среднем по 50 КБ на каждую дополнительную учетную запись пользователя. Таким образом, размер файлов на диске можно рассчитать математически: для нужд самой операционной системы контроллеру следует выделить не менее 50 ГБ, а под хранение каталога для упрощения расчетов возьмем по 1 ГБ на каждые 20 тысяч объектов. Расчетное значение должно составлять не более 40% от доступного пространства.
Для загрузки каталога требуется чуть больше оперативной памяти, т.к. служба ns-slapd индексирует отдельные атрибуты каталога, но в среднем можно использовать те же нормативы. Пустая база данных занимает в памяти не менее 65 Мб, и это значение растет по мере увеличения числа объектов, на каждую дополнительную учетную запись в среднем добавляется 50 КБ. Таким образом, минимально необходимый объем оперативной памяти можно рассчитать математически: для нужд самой операционной системы контроллеру следует выделить порядка 2-3 ГБ, а для работы с каталогом в целях упрощения расчетов возьмем по 1ГБ на каждые 20 тысяч объектов:
Приведем несколько примеров:
Для работы с каталогом, в котором содержится 10 000 пользователей и 100 групп, контроллеру нужно выделить порядка 4 ГБ ОЗУ:
Для работы с каталогом, в котором 100 000 пользователей и 30 000 групп, контроллеру нужно выделить до 16 ГБ ОЗУ:
Внимание
При создании учетных записей контроллер домена потребляет в два раза больше оперативной памяти, т.е. примерно 100 КБ на каждую новую запись, которая высвобождается после перезапуска службы dirsrv. Эта особенность работы не проявляется в сценарии репликации, но ее следует учитывать при планировании начальной миграции.
Примечание
Для обеспечения надёжной работы контроллеров домена и сопутствующих сервисов, а также для исключения увеличения времени репликации из-за дополнительных операций чтения данных с диска, контроллерам домена рекомендуется выделять не менее 8 ГБ оперативной памяти.
Ресурсы центрального процессора
Если объем потребляемой оперативной памяти зависит от количества записей в каталоге, то количество ресурсов центрального процессора определяется тем, сколько пользователей (компьютеров) должен обслуживать конкретный контроллер. Например, в базе может быть 100 тысяч пользователей, но нагрузка по их обслуживанию может распределяться между 20 репликами, и в этом случае на каждый контроллер будет приходиться не более 5 тысяч обслуживаемых пользователей.
Примечание
Учетные записи уволенных сотрудников, которые просто находятся в каталоге, напрямую не влияют на то, сколько ядер процессора потребуется контроллеру для нормальной работы. Деградация сервиса при увеличении количества пользователей в каталоге возможна только в тех сценариях, когда используется перебор всех записей, особенно по неиндексированным атрибутам.
Корпоративные приложения очень по-разному взаимодействуют с каталогом. Например, Kerberos нагружает процессор значительно больше LDAP-аутентификации, т.к. использует сложные криптографические алгоритмы, а использование кеширования помогает снизить нагрузку в разы, если не на порядок. Поэтому предложить какой-то универсальный нормативный показатель на одного сотрудника не представляется возможным, и системным администраторам следует рассчитать его для своей организации самостоятельно, достигая использования ЦПУ на уровне 40% от максимума.
Отправной точкой в расчетах может быть выделение одного потока процессора для работы операционной системы и еще по одному потоку на каждую тысячу обслуживаемых пользователей (компьютеров):
Приведем несколько примеров.
Пример 1.
Для обслуживания 2 - 3 тысяч пользователей контроллеру домена нужно выделить порядка 4 потоков:
Компания RedHat в своей документации рекомендует использовать контроллеры домена именно такой производительности, но эта рекомендация не подойдет крупным организациям, в штате которых работает несколько сотен тысяч сотрудников, т. к. контроллер, обслуживающий 5-10 тысяч сотрудников, будет в 2-3 раза эффективнее использовать оперативную память в пересчете на активного пользователя, чем контроллер, обслуживающий 3 тысячи сотрудников.
Пример 2.
Для обслуживания 10 тысяч пользователей контроллеру домена нужно выделить 11 потоков.
Повторимся, что данные оценки сильно зависят от сценария использования службы каталога, поэтому на такое количество пользователей мы рекомендуем для начала выделять порядка 8-12 потоков, а затем подбирать точное значение, опираясь на целевой показатель в 40% нагрузки от максимума.
Пример 3.
Если под контроллер домена выделить физический сервер с двумя процессорами Xeon Silver (48 потоков), то теоретически он сможет обслуживать 47 тысяч пользователей. При планировании таких контроллеров следует принимать во внимание пропускную способность сети (потребуется не менее гигабитного интерфейса) и другие ограничения системы.
Внимание
При изменении количества потоков процессора (замена процессора или изменение настроек виртуальной машины) необходимо обновить переменную DAEMON_ARGS в файле /etc/default/krb5-kdc
и перезапустить службу krb5-kdc.
Примечание
Если нагрузка на ЦПУ не превышает 40%, то добавлять ядра не имеет смысла и дополнительный прирост в скорости обработки запросов можно получить только за счет увеличения частоты центрального процессора. Мы рекомендуем использовать процессоры с базовой тактовой частотой ниже 1,8 ГГц.
Примечание
До версии 2.4.0 на контроллерах домена работала служба Salt Master, которой нужно было выделять столько же ресурсов, сколько и службе каталога. После перехода на автономную службу aldpro-salt-minion требования к ресурсам были существенно снижены, что отражено в приведенных выше расчетах.
Пропускная способность сети
В процессе обслуживания клиентов контроллеры домена, как правило, получают небольшие входящие запросы на предоставление относительно больших объемов данных, поэтому на контроллерах обычно преобладает исходящий трафик.
Любые оценки являются субъективными, но в качестве общих рекомендаций следует исходить из того, что при количестве пользователей до 5 000 будет достаточно интерфейса с пропускной способностью в 100 Мбит/с, а если предполагается обслуживать больше пользователей, установите на контроллере интерфейс с пропускной способностью в 1 Гбит/с. В результате оптимизации нужно добиться, чтобы показатель использования сети не выходил за пределы 40% от максимума.
Учитывая то, что внешние каналы связи редко достигают гигабитных скоростей и активно используются пользователями для выхода в Интернет, для каждого офиса рекомендуется создавать отдельный сайт (локацию) и размещать в нем один-два контроллера для локальной обработки клиентских запросов. Такой подход к организации домена позволит разгрузить VPN-туннели между офисами и использовать эти каналы связи только для репликации.
Модуль синхронизации
Основные ресурсы, потребляемые при работе модуля синхронизации — это дисковое пространство, размер которого будет прямо пропорционален количеству синхронизируемых объектов. Дисковое пространство потребляется БД PostgreSQL, где хранятся метаданные всех синхронизированных объектов. Для корректной работы модуля синхронизации необходимо выделить дополнительно 15-20% дискового пространства от расчётного.
С настройками по умолчанию PostgreSQL хранит кеш объектов в оперативной памяти. Учитывая, что около 80% обрабатываемых запросов являются запросами на чтение, будет достаточно выделить дополнительно 10-15% от расчетного объёма ОЗУ.
Прочие службы
Начиная с версии ALD Pro 2.4.0, служба Salt Master больше не используется на контроллерах домена, поэтому выделение дополнительных ресурсов на ее работу не требуется.
Начиная с версии ALD Pro 2.3.0, брокер сообщений RabbitMQ не использует кластеризацию, поэтому его накладными расходами можно пренебречь, отнеся их к базовым потребностям операционной системы.
Горизонтальное масштабирование
Горизонтальным масштабированием называют повышение производительности системы за счет увеличения количества вычислительных узлов, обслуживающих клиентов, без изменения их производительности. Например, если предполагается использовать контроллеры с 8-12 потоками ЦПУ, которые могут обслуживать по 10 тысяч пользователей, то в организации со штатом в 30 тысяч сотрудников потребуется не менее 3 контроллеров такой производительности:
Синхронизация данных между контроллерами обеспечивается процессом репликации, и в службе каталога FreeIPA она происходит в мультимастер-режиме, т.е. изменения можно вносить на любом контроллере. Балансировка нагрузки и отказоустойчивость реализована на стороне клиента и обеспечивается через DNS.
К механизму репликации мы вернемся, когда будем изучать Модуль 8. Управление топологией в домене.
Рекомендации по именованию домена
В документации и обучающих курсах применяются домены contoso.com или ad.example.test, которые используют для обучающих целей, но не приемлемы для развёртывания продуктивных сред. Поэтому мы рекомендуем придерживаться следующих правил:
Лучший вариант – это использовать свой домен третьего уровня. Например, если организация приобрела домен mycompany.ru для своего веб-сайта и почты, то для ALD Pro можно выделить доменное имя третьего уровня ald.mycompany.ru.
Крайне важно не использовать DNS-зоны, которые принадлежат другим субъектам или могут быть ими заняты.
Если вы не хотите использовать публичный домен, то можно задействовать зоны «.lan» или «.internal», например, ald.mycompany.lan.
Microsoft активно продвигает зону «.local», поэтому она упоминается во многих инструкциях, но при использовании этой зоны вы можете столкнуться с конфликтами Multicast DNS (RFC6762) и невозможностью использования протокола zeroconf, который реализован в Linux службой Avahi, поэтому зону .local мы не рекомендуем.
Не пытайтесь использовать для домена однокомпонентные имена (Single Label Domain, SLD), такие как .yandex, .google или .microsoft, даже если ваша организация (вдруг) приобрела себе такое имя. В домене MS AD конфигурация SLD для новых доменов больше не поддерживается, и в службе каталога FreeIPA на развертывание домена с таким именем тоже установлен явный запрет.
Важно
Зоны «.lan» и «.internal» не зарегистрированы в глобальном списке Top-Level Domains, поэтому чисто теоретически их могут ввести в эксплуатацию, что приведет к конфликту в будущем, но вероятность этого события крайне мала.
Выбор префикса для домена:
Выберите префикс, который вряд ли устареет, т. е. избегайте имен, таких как линейка продуктов или операционная система, которые могут измениться в будущем. Рекомендуется использовать универсальные имена, такие как 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) после ввода в домен, то вы столкнетесь с ошибками при установке подсистем ALD Pro на такие хосты.
Для именования хостов на предприятиях обычно используют определенные соглашения. Например, в соответствии с правилом <type>-<number>.<суффикс домена>
сервер может называться dc-18.ald.company.lan. Это существенно упрощает работу с большой инфраструктурой и позволяет обрабатывать имена в заданиях автоматизации. Указанное имя можно легко разделить на части по символу «-» с помощью утилиты cut
. Результат выполнения команды покажет, что выбранный узел является контроллером домена, а не сервером мониторинга:
admin@dc-1:~$ echo "dc-18.ald.company.lan" | cut -d "." -f 1 | cut -d "-" -f 1
dc
Понятное дело, что на имена не стоит сильно полагаться, т.к. сервер dc-18 может быть пока еще просто сервером, который только предполагается сделать контроллером домена. Но мы надеемся, что основная суть понятна.
Практика и тестирование
Заключение
В этом модуле мы познакомились со службой каталога, а в следующем будем уже устанавливать первый контроллер домена и, конечно же, вводить клиентскую машину в домен.
Дополнительные источники информации
Обратная связь
Если остались вопросы, то их всегда можно задать в специальной теме.