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

Функциональные требования к продукту

Выбор лицензии

На волне активного импортозамещения российские разработчики создают собственные продукты практически для любых бизнес-задач.

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

Выбирая подход к лицензированию, стоит обратить внимание на следующие моменты

1. Стоимость. Решения на базе открытого исходного кода часто дешевле проприетарных или бесплатны. Но стоимость владения Open Source решением может оказаться гораздо дороже за счет постоянного устранения недоработок, и поиска специалистов.
2. Техническая поддержка. Готовые Open Source-решения или вендорские доработки на их основе имеют общие проблемы — огромный техдолг и отсутствие владения кодом. Даже созданные вендорами решения, например, на базе Samba, не имеют полноценной техподдержки, так как разработчики вендора не владеют исходным кодом системы, и вносить доработки в ядро не могут. Есть известные примеры, когда решения на базе Samba долгое время имели ограничения на размер базы данных в 4 Гбайт. Вендорам пришлось ждать, пока коммьюнити почти 5 лет готовило обновление системы. Важные задачи обновления в бэклогах коммьюнити могут висеть годами.

Некоторые поставщики ПО закрывают недостатки ядра внешними обвязками, но этот подход может ухудшить производительность системы или помешать ее росту.

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

Возможность обеспечения длительного сосуществования ПО Microsoft и, например, ОС Linux во время переходного периода

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

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

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

Чьими силами реализуется внедрение

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

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

Этапы проекта

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

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

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

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

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

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

* * *

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