Чек-лист: Как выбрать замену Microsoft Active Directory и безболезненно мигрировать на нее

При миграции на отечественную службу каталогов очень важно сохранить прозрачный доступ сотрудников компании к ресурсам независимо от того в каком сегменте они находятся. Это означает, что сервисы под управлением Microsoft Windows и рабочие станции и сервисы под управлением различных дистрибутивов Linux должны быть интегрированы в единое информационное пространство до тех пор, пока переход на отечественное ПО в компании не будет завершен полностью.

Важно чтобы служба каталогов, на которую будет производится миграция, поддерживала двусторонние отношения доверия, обеспечивая и доступ пользователей еще не перенесенных из MS AD на рабочие станции Linux, и доступ пользователей импортозамещенной службы каталогов к ресурсам, все еще находящимся в среде MS Windows.

Для сценариев, когда даже через доверительные отношения невозможно получить доступ к другим системам, можно использовать синхронизацию учетных записей, когда учетная запись не только мигрирует из одного каталога в другой, но и постоянно синхронизируется с помощью IDM-решения, что позволяет пользователю с одними и теми же учетными данными получать доступ и к своей почте, и к ресурсам, к которым имеет доступ новая учетная запись в импортозамещенной службе каталогов. Яркий пример — почтовый сервер Microsoft Exchange, который не может работать ни с какой другой службой каталогов кроме MS Active Directory и требует синхронизации каталога.

Пользователям Microsoft AD привычна древовидная схема организации каталогов — она позволяет легко управлять пользователями и делегировать полномочия за счет иерархического хранения и разделения информации в домене. В этом случае для разных подразделений организуются отдельные контейнеры, в которых хранятся различные объекты: пользователи, группы, компьютеры. Такая схема позволяет удобно разграничивать доступ к разным объектам, например, по географическому признаку, и легко находить нужных пользователей.

В некоторых решениях, доступные в рамках импортозамещения, реализована плоская структура хранения информации. Она не позволяет быстро найти нужных пользователей и сильно сокращает возможности управления правами доступа к объектам. Перейти на такие решения с Microsoft AD можно будет только с потерей привычной функциональности.

Одной из ключевых функций Microsoft AD, помимо централизованной аутентификации и авторизации в домене, было управление компьютерным парком с помощью групповых политик. Соответственно, решение по импортозамещению службы каталогов MS AD также должно реализовывать данный функционал.

В готовых Open Source решениях такая возможность отсутствует. В доработках от вендоров групповые политики реализуются за счет интеграции со сторонней системой управления конфигурацией, например, Puppet или SaltStack.

Важно помнить, что служба каталогов от Microsoft обслуживала только ОС Windows, а новое решение должно поддерживать широкий перечень дистрибутивов Linux, используемых на предприятии. Для каждого из них потребуются собственные шаблоны конфигурации.

В текущих реалиях фактически невозможно создать гомогенную инфраструктуру на базе одной операционной системы. Разные дистрибутивы Linux используются не только для клиентской или серверной инфраструктуры, часто специфические задачи диктуют выбор того или иного дистрибутива.

Оценивая решение, способное заменить MS Active Directory, важно обращать внимание на возможности интеграции с клиентами под управлением различных дистрибутивов Linux. Такая функциональность будет крайне важна при слиянии и поглощении компаний, когда из двух служб каталогов нужно сформировать единый каталог в новой организации.

Использование службы каталогов с поддержкой только одного дистрибутива Linux потребует при миграции полной замены инфраструктуры поглощаемой компании без возможности включить ее в собственный контур. Если же реализована поддержка разных операционных систем, решение просто включается в контур компании, что помогает оптимизировать процессы для быстрого внедрения и контролировать риски и затраты.

Многие отечественные службы каталогов — это продукты вендоров российских ОС, а значит, они поддерживают только конкретный дистрибутив Linux. Проприетарные решения, создаваемые независимыми разработчиками, как правило не зависят от конкретной ОС и поддерживают все популярные дистрибутивы.

Безопасность службы каталогов важно рассматривать в двух аспектах.

1. Безопасность самого продукта

Выбирая Open Source решения, компания должна четко понимать риски — открытость кода часто приводит к отсутствию преград в эксплуатации уязвимостей злоумышленниками. Исправление выявленных багов может длиться месяцами, а может и вообще не выполняться. Но с другой стороны эта же доступность позволяет всему сообществу разработчиков быть в курсе проблем с безопасностью, а значит в продуктах, разработанных на базе Open Source решений, часть таких уязвимостей может быть закрыта «заплатками».
В проприетарном ПО уязвимости найти сложнее, так как исходный код закрыт для посторонних пользователей. Если у вендора реализован процесс безопасной разработки с тестированием на уязвимости, продукт становится еще более защищенным.

2. Безопасность использования
Чем обширнее инфраструктура компании, тем бОльшая команда требуется для работы со службой каталогов: это не только администраторы, но и сотрудники техподдержки, и локальные администраторы, и операторы, заводящие в систему учетные записи. При выборе решения стоит обратить внимание на средства гибкого делегирования полномочий к объектам службы каталогов. Это позволит организовать надежный с точки зрения безопасности принцип наименьших привилегий, когда сотрудникам выдается ограниченный набор прав доступа. Например, сотрудник техподдержки сможет сбросить пароль пользователя, но не сможет предоставить ему права администратора.

Служба каталогов должна быть достаточно производительной и уметь масштабироваться на большие объемы инфраструктуры, чтобы не стать узким местом при росте компании и увеличении числа пользователей.

У Open Source решений этот пункт всегда был «ахиллесовой пятой»: в основе таких продуктов лежат, как правило, не самые современные технологии, системы обновляются намного медленнее проприетарного ПО. Многие решения с открытым исходным кодом создавались для небольших организаций и развернуть их на десятки и сотни тысяч пользователей бывает очень проблематично.

1. Производительность
На производительность службы каталогов напрямую влияет используемый стек технологий — язык программирования, СУБД.

Высокую скорость разработки и работы готовых приложений обеспечивает, например, современный язык Golang. В качестве хранилища можно использовать любые современные БД, оптимизированные под современное оборудование, например, высокопроизводительную базу данных BadgerDB, которая показывает высокую производительность при работе на SSD-дисках.

Использование современного технологического стека позволяет проприетарным решениям кратно превосходить по производительности такие Open source продукты, как FreeIPA и SambaDC. Так, например, Аванпост DS позволяет добиться показателей производительности сравнимых с Microsoft Active Directory на каталоге в 3,5 млн объектов.

Сохранить высокую производительность и надежность системы позволяют регулярные нагрузочные тестирования, проводимые разработчиками ПО. Но эта опция чаще встречается в разработке проприетарных решений. Avanost DS показывает устойчивую работу при одновременной обработке более 100 000 запросов (50 000 запросов на один контроллер домена).

2. Масштабируемость
Один из подходов, обеспечивающих отказоустойчивую работу и быстрое масштабирование службы каталогов — гибкая система репликации, при которой контроллеры доменов имеют полные копии данных каталога, а значит, могут обслуживать любого клиента. Если в решении реализована такая возможность, значит оно позволит масштабировать службу каталогов в геораспределенных сценариях.

Непредсказуемость поведения западных вендоров, под влиянием санкций отключающих российских пользователей от своих сервисов, приводит к тому, что миграцию на российские решения часто приходится проводить экстренно, в очень сжатые сроки. Выбирая отечественные ИТ-продукты, стоит заранее оценить сложность внедрения и факторы, которые на нее влияют, например, наличие технической поддержки и команды внедрения.

Квалифицированную техническую поддержку и требуемый уровень SLA при внедрении и эксплуатации решения могут оказать вендоры — как проприетарного ПО, так и разработок на базе Open Source. Но ожидать, что разработчик систем на базе открытого исходного кода сможет быстро внести доработки в продукт, не стоит. Выбирая Open Source решение, компания должна быть готова к тому, чтобы взять все риски внедрения на себя — централизованной службы поддержки у таких систем нет, рассчитывать придется лишь на опыт и компетенции собственных специалистов и на поддержку со стороны коммьюнити.

Как и любое другое ПО, службу каталогов можно внедрять собственными силами заказчика или привлекать к внедрению специалистов вендора или интегратора. Выбор определяется компетенциями собственной ИТ-команды и спецификой самого продукта.

1. Заказчик выбирает проприетарное решение и обращается к вендору за помощью во внедрении. Преимущество такого подхода — прямой доступ к вендорской экспертизе по продукту.
2. Заказчик обращается к интегратору, который помогает выбрать подходящее решение и внедряет его силами своих специалистов. Это организационно более сложный, но самый безопасный вариант, так как риски делят вендор и интегратор. Если речь идет об Open Source решении или проприетарной службе каталогов, основанной на открытом коде, сотрудничество с интегратором — оптимальный вариант, так как собственной экспертизы в компании скорее всего будет недостаточно. Также участие интегратора потребуется в том случае, если заказчик внедряет службу каталогов в составе комплекса импортозамещения, то есть одновременно заменяет еще и почту, корпоративный портал и другие сервисы.
3. Заказчик сам выбирает решение и внедряет его собственными силами. Такой подход может быть эффективным при покупке коробочной версии проприетарного ПО. Внедрение своими силами готового Open Source решения — самый рискованный вариант.

При внедрении службы каталогов рекомендуется проделать ряд важных шагов, которые будут способствовать эффективной работе не только самого решения, но и всей ИТ-инфраструктуры компании.

Функциональное тестирование — проверка решения на соответствие всем функциональным требованиям и возможности интеграции с интересующими компанию продуктами.

Нагрузочное тестирование — стимуляция на тестовом стенде рабочей нагрузки, проверка работоспособности в условиях, максимально приближенных к реальным.

Период тестирования обычно длится 2−3 месяца, особенно если речь идет о широком функциональном тестировании, когда служба каталогов проверяется на совместимость со всеми сервисами компании.

Пилотный проект — начинается после успешного завершения тестирования. Разворачивается инстанс службы каталогов, интегрируемый в инфраструктуру, с ним начинает работать пилотная группа пользователей. Проект обязательно курируют архитектор, инженеры, руководители проекта со стороны вендора или интегратора. Пилот не должен длиться дольше полугода, при положительном фидбеке от фокусной группы принимается решение о внедрении службы каталогов в промышленную эксплуатацию и масштабировании ее на всю компанию.

Непосредственная реализация самого проекта может длиться в среднем еще год.

* * *
Российский бизнес вынужден обходить санкционное давление, постепенно снижая долю иностранного ПО в своей инфраструктуре. Уже сейчас существует ряд достойных альтернатив для организации корпоративной службы каталогов. Выбор решения должен учитывать как функциональные требования к безопасности, масштабируемости, поддержке мультивендорной инфраструктуры, так и вопросы внедрения нового решения. На подбор оптимального решения может уйти время, поэтому мы рекомендуем не откладывать эту задачу, и, воспользовавшись чек-листом, приступить к поиску российского решения, способного заменить Microsoft Active Directory.