Comments 25
Объективно, AD нужна там, где есть продукты M$. Exchange, SSCM, SFB, клиентские ОС Windows. Описывамые же продукты всего этого функционала не зыкрывают, точнее будут работать, но со старым софтом 7-10 летней давности. Всё, для чего оно надо - сделать похожее на AD. Но если рассматривать вариант, где нет ни Exchange ни других продуктов M$ (их же планируется импортозаместить), то для чего нужны эти изделия?
AD и ее аналоги нужны для централизованного ведения УЗ, средства аутентификации, управления АРМ, политиками пользователей и ПК и много чего ещё. Все это нужно не только для продуктов Microsoft. Для того же Communigate, Р7-офис корпоративный сервер, Naumen и т.д. (аналоги указанных вами продуктов Microsoft).
Давайте для объективности. AD требуется для уплавления продуктами M$. Samba DC - форк, чтобы работать с этими же продуктами, но под *nix. Я говорю об объективности, если уж пилится что-то своё, которое якобы отличается от продуктов M$, то давайте и технологии утправления будут отличаться - не? Иначе получается, что вроде и отличается, но только на бумаге - а в реальности всё то же самое.
Я с вами и согласен и нет. С одной стороны, вроде бы да, создаётся такое ощущение. А с другой стороны, по моему мнению, MS довольно вдумчиво подошли к проектированию AD. В результате, если вы тоже хорошо поработаете, то просто повторите тоже самое, но чуть чуть иначе. А может и не получится так хорошо. Достойная ли это цель?
Но что если можно было бы сделать гораздо лучше? Проще и гибче, универсальнее? Вы бы, вот, что изменили?
AD требуется в первую очередь нужна для централизованной авторизации, это может использоваться в огромном количестве продуктов: Dovecot, Zimbra, Jira, авторизация в различных ОС, Bitbucket, Zabbix и многое другое. Конечно для этого могут использоваться и другие продукт реализующие LDAP.
Странная логика про аналоги. По вашему если есть какой-то продукт, то делать аналоги не имеет никакого смысла? Кроме того в статье указано, что приобрести M$ для корпоративных заказчиков в России нельзя. И функционал "аналогов" отличается, во многом он значительно хуже, но есть и небольшие плюсы, например, "GPO" для ПК с ОС Linux.
Если исходить из концепции, что AD требуется для авторизации, то Хьюстон у нас проблемы. Есть отличные протоколы - SAML, OpenID или OAuth - бери да пользуйся, но мы тянем AD, LDAP и Radius в наш современный мир. AD может быть на каком-то из этапов, но не является необходимостью. AD в текущих реалиях всё ещё используется, но по факту, все описанные продукты - чуть переписанные форки OpenSource продуктов (которые выпускались как альтернатива управления AD), которые, в свою очередь, пытаются быть "импортозамещением".
Что называется на коленке бабла срубить.
Я может что-то упустил, на ПК можно авторизоваться для интерактивного входа с помощью OAuth или сервис запустить, например, ms sql agent?
Друзья, спасибо за ваши комментарии! Многое сказано верно, действительно, производя такие масштабные изменения в ИТ-инфраструктуре, как пересборка ее ядра на отечественном ПО, нужно воспользоваться моментом и создать систему, лучшую, чем существующая «унаследованная» инфраструктура, соглашусь со следующим:
Вовсе не обязательно создавать отечественную ИТ-инфраструктуру такой же, как она была на Microsoft, поэтому при разработке концепции целевого решения мы внимательно изучаем требования Заказчика, в том числе на уровнях, выше, чем ИТ-инфраструктура (прикладные ИС, иногда даже бизнес-процессы) и формируем архитектуру не всегда такой же, как была на Microsoft.
Те же задачи, которые AD решала для Windows и других продуктов MS, должны решаться и в импортозамещенной ИТ-инфраструктуре, поэтому рассмотренные решения очень востребованы для управления отечественными ОС на базе Linux. И да, многие Заказчики желают видеть те же функции, что были в AD, поэтому нашим продуктам приходится быть на нее похожими.
Действительно, согласно ТРИЗ, «идеальной службой каталога является та, которой нет, но функции аутентификации и централизованного управления выполняются». В каких-то случаях можно организовать инфраструктуру без аналога AD, но скорее не в классической корпоративной ИТ-инфраструктуре, а в каком-нибудь интернет-магазине/маркетплейсе/портале где пользователи преимущественно внешние. Когда будет придумано что-то более успешное (удобное, востребованное), чем служба каталогов для управления учетными записями и аутентификации, наступит новая эра ИТ-инфраструктур.
Что касается «на коленке бабла срубить», хочу сказать, что разработчики данных продуктов на самом деле делают большое дело. Текущее состояние Open Source продуктов таково, что для многих российских организаций очень сложно будет переходить на них – слишком высок порог входа и множество препятствий придется преодолеть. Создавая новые продукты, даже если кажется, что это «просто» сборка из открытых компонентов, они снижают этот порог и вместе с партнерами, такими, как К2Тех, приближают момент реального замещения ИТ-инфраструктуры на отечесественные решения. Мы общаемся с коллегами из всех перечисленных вендоров и видим как у них горят глаза и чувствуется желание сделать качественный и востребованный продукт. Конечно, заработать им тоже необходимо, иначе продукт не выживет. Получается, что все мы (партнеры, заказчики) даже очень заинтересованы в том, чтобы отечественные разработчики зарабатывали, чтобы они и далее развивали и поддерживали свои продукты, придумывали что-то новое, большее, чем «еще один аналог AD».
А где отечественное ПО в статье?
Ну, в *nix вроде pam_oidc есть - но я лично с ним не работал.
Эм. В каком месте оно "форк"? Оно вообще не имеет отношение к кодовой базе MS. ЕМНИП, исходная samba была результатом реверс-инжениринга решения от MS, а четвертую samba'у еще и переписали примерно полностью.
Сомневаюсь, что там кто-то занимался обратной разработкой, ибо не нужно: все протоколы работы с AD подробно описаны на сайте MS (не совсем по доброй воле: антимонопольные регуляторы заставили).
Гм. Ну, мужики чуть-чуть не в курсе...
Речь ,skf не про SMB (как у вас по ссылке) а про протоколы, используемые AD DS
В любом случае "форком" оно не является и отношения к "кодовой базе MS" не имеет. Да и насчет качества документации и соответствия, в том числе и собственным стандартам Microsoft - я бы не обольщался ).
Дык, я и не утверждал, что Samba использует кодовую базу MS. Я — чисто про реализацию функцилнальности AD: в части доступа к каталогу и протоколов аутентифкации ничто не мешает использовать открытые спецификации.
А с SMB (который v1) — несколько сложнее, да: протокол развивался исторически, ещё со времен DOS, поэтому там реализация в DOS/Windows от более поздней спецификации CIFS на практике таки отличается. И вообще, там бардак, там дыра (CVE-2017-0144) много лет жила, только в 2017 ее закрыли.
Гм. Это чуть-чуть, самую капельку, малость - не совсем так. AD прежде всего - централизованное управление учетными записями, прозрачная аутентификация для пользователей на РМ, плюс политики управления этими самыми РМ в достаточно широких пределах + немножко интегрированной инфраструктуры в виде DHCP+DNS, CA и т.д.
Да, теоретически можно сделать троллейбус-из-буханки почти как настоящий - openldap + keyrberos + какой ansible\puppet - но работать оно ээээ... будет эээ... как-то. Причем скорее "нет", чем "да".
Если обсуждать вариант замены ОС на РМ на что-то "более другое"(ТМ) то рассматривать альтернативы можно (А какие?), но в большинстве случаев это игра ну очень "в долгую" - и тут идея слепить "из палка и веревка" что-нибудь "никакввинде!" но чтобы управлять в том числе и "виндой" - ну, такоэ.
AD (точнее, AD DS) — это, прежде всего, иерархический каталог общего назначения, поддерживающий доступ через LDAP, с надстроенной поверх него подсистемой хранения учетных записией, с аутентификации и авторизации на их основе по протоколам Kerberos(с расширениями от MS для авторизации)/NTLM — для любых клиентов, которые эти протоколы поддерживают. Ещё на контроллере домена AD DS используется для хранения зон DNS (вместо файлов зон), при этом сам сервер DNS — это отдельная служба. CA — это вообще отдельная служба, со своей БД, из AD он может брать только шаблоны сертификатов и права доступа к ним. DHCP — совсем отдельная служба, к AD отношения не имеющая (просто в маленьких сетях удобно ставить ее на КД). В групповых политиках AD тоже используется как каталог, хранящий информацию (и то не всю): реально он содержит иерархию политик применяемых к клиентам, содержимое политик живет в файловой системе (на SYSVOL), а интепретация политик и применение их — это чисто клиентская задача, выполняемая на конкретных ПК.
Так что всю описанную вами функциональность ничто не мешает собрать из кусоков (разработчику дистрибутива или самому администратору, по месту работы) — лишь бы куски поддерживали нужные протоколы.
Ну в общем да - как говорил один мой начальник: "Да можно сделать все, что угодно! Да - даже ракету в космос запустить! Да с помощью одного напильника! Силами одного человека! При условии, что этот человек - не ты"(Ц)
А так да - все слагаемые успеха в наличии - и даже альтернативная реализация в виде 4ой samba'ы есть - вот только ОЧЕНЬ я вам не рекомендую её поддерживать в качестве drop-in replacement'а для MS'овской инфраструктуры - даже при наличии фуллтайм специалистов для этого. Тот еще "троллейбус из буханки" - выглядит похоже, но пользоваться нельзя.
Directory Services - службы каталога (не служба каталогов). Каталог един, в этом его смысл, а служб у него много...
Из обзора совершенно непонятно, что поддерживается каждым продуктом из возможнойстей AD, кроме базовых: каталог LDAP, хранение пользователей и групп в рамках одного домена, доступ к спискам пользователей и групп по протоколу Netlogon, аутентификация с передачей авторизационной информацией по протоколам Kerberos и NTLM. Интересует:
-возмиожность изменения содержимого каталога параллельно на нескольких контроллерах домена с репликацией этих изменений на другие контроллеры и разрешением конфликтов при репликации;
-возможность хранения в одном каталоге учетных записей и групп для нескольких разных доменов (поддержка леса доменов) с автоматическими доверительными отношениями между этими доменами;
-возможность установки доверительных отношений через протоколы NTLM (внешнее доверие) и Kerberos (межлесное доверие);
-возможность репликации с контроллерами AD под Windows (поддержка соответствующего протокола репликации)
IMHO в техническом обзоре всё это должно быть.
Да, действительно, данный обзор достаточно верхнеуровневый. Он изначально и задумывался как первые впечатления от новинок рынка (РЕД АДМ и Атом.Домен). Более детальный и глубокий разбор, на мой взгляд, имеет смысл делать на примере сравнения всех 4 решений. Мы с коллегами планировали к нему приступить в том случае, если аудитории Хабра зайдет эта тема. Сейчас вижу, что интерес начинает проявляться :)
Ну и чем же ред адм лучше того же ald от астры? По факту - интерфейс старое произведение, да и нотки своего нету, да основана на стареньком и уважаемом samba. Можно сказать freeipa и samba сейчас главнце конкуренты друг друга на линуксе, но эти системы используют только эти наработки в то время как ald может использовать это всё.
Обзор РЕД АДМ и Атом.Домен: новые альтернативы службе каталогов MS Active Directory