Понятно, что, в первую очередь, задача замены Microsoft Active Directory стоит перед теми организациями, для которых отказ от продуктов Microsoft является регуляторным требованием. Но при этом наблюдается все больший интерес к миграции с AD со стороны ИТ-служб, которые целенаправленно развивают экосистему Linux-решений, даже если от них не требуется срочная миграция с экосистемы Microsoft.
Почему же не пойти в данном случае просто в сторону Open Source, и не встроить службу каталогов на базе Samba DC или, например, FreeIPA? На самом деле, во многих случаях этот подход будет оправдан, если у системного администратора хватает квалификации для сборки, обслуживания и обновления всей экосистемы Linux. Но для крупных корпораций задача стоит иначе — мигрировать с AD без потери комфорта и производительности. И именно на этом поле играет Avanpost DS.
В чем сложность?Проблема в том, что служба каталогов существует не в вакууме. Это инфраструктурный сервис, который интегрируется практически со всеми прикладными системами предприятия и другими системообразующими компонентами. Фактически MS AD прорастает корнями во всю ИТ-экосистему, охватывает почти все решения. Именно поэтому замена MS AD на другую службу каталога — процесс небыстрый, он затрагивает все смежные системы.
Если говорить про нашу службу каталога, существует две версии Avanpost DS — это Avanpost DS Pro, предназначенная для самых высоких нагрузок, и Avanpost DS Public — бесплатная служба каталогов, поддерживающая до 200 учетных записей и до 1 тыс. объектов. На данный момент мы гарантируем полную совместимость с тремя дистрибутивами наиболее распространенных российских ОС: RedOS, Astra Linux и Alt Linux. Естественно, установка возможна и с любым другим Linux, но для этих наиболее популярных систем протестированы уже все аспекты интеграций, и развертывание службы каталогов на базе Avanpost DS происходит с экономией сил (физических и душевных) системных администраторов.
Проблема курицы и яйцаНо давайте вернемся к реальной жизни. Разумеется, в ходе процесса «переезда» обязательно встречаются системы, заточенные под MS AD, которые могут работать только с ней. Самые яркие примеры — это Exchange и SharePoint. Понятно, что их тоже нужно заменить. Но мы не можем внедрить новый портал, пока не подключимся к новой службе каталога, а с ней не будет работать SharePoint.
Мигрировать все сразу не получается на практике, и поэтому возникает вопрос переходного периода. То есть в процессе миграции должен присутствовать достаточно длительный период сосуществования, когда часть сервисов обслуживается Avanpost DS, а часть — MS AD. И все это должно работать как единая система.
На мой взгляд, существует только один способ решения этой дилеммы — реализовать доверительные отношения между MS AD и Avanpost DS. Они позволяют сохранить прозрачный доступ пользователей к ресурсам на все время совместной работы сервисов.
Чтобы не нарушать существующую архитектуру, мы разработали утилиту миграции, которая позволяет перенести пользователей из Active Directory c сохранением паролей, идентификаторов безопасности (через Seed History) и прочих параметров. После такого переноса пользователь уже опирается на сервисы Avanpost DS, но при этом сохраняет доступ к ресурсам в MS AD.
Таким образом, бесплатная версия Avanpost DS Public позволяет заменить MS AD для не слишком нагруженных доменных структур, либо провести тестирование и убедиться в производительности и совместимости перед полномасштабным переездом на Avanpost DS Pro.
Однако реализация самой практики сосуществования — интересная и сложная задача, особенно если речь идет о поддержке «структуры леса» в Avanpost DS Pro.
Почему у нас нет DNS и PXE?Это вопрос, который часто задают, когда идет обсуждение замены стека MS. И тут дело в том, что это один из секретов высокой стабильности и скорости работы нашего сервиса. Дело в том, что путь Avanpost совпадает с постулатами Linux-программирования:
- Пишите программы, которые делают что-то одно и делают это хорошо.
- Пишите программы, которые работали бы вместе.
Опираясь на эти два постулата, мы разрабатываем Avanpost DS с максимальными инвестициями в сторону основного назначения продукта. В итоге мы предлагаем службу каталогов, которая подойдет для крупного Enterprise и будет поддерживать миллионы пользователей.
Да, мы не реализуем то, что не относится к службе каталогов. И для сервисов, которые тесно интегрируются со службой каталогов, существуют проверенные схемы интеграции — например, это касается DNS и сервера времени. А что касается PXE и DHCP, их работа настолько стандартизована, что эти сервисы вообще не нуждаются ни в какой дополнительной интеграции.