Pull to refresh

Comments 19

В настоящее время многие компании задумываются над миграцией в Linux инфраструктуру и вместо Microsoft AD DS планируют использовать службу каталога с открытым исходным кодом FreeIPA или более функциональные решения на ее основе, такие как ALD Pro.

Не многие, а лишь самые отчаянные и те, у кого много свободного времени на работе, а занять себя нечем )))

Хм... Между "задумываться" и "делать" разница есть. Правда, некоторым организациям (не "компаниям", а именно "организациям" ;) ) таки приходится не только задумываться, и не просто планировать, несмотря на отсутствие "много свободного времени". В общем, если в процитированной фразе заменить "многие компании" на "различные организации" - то было бы даже близко к истине.

Windows Server, на котором поднимается AD DS, можно даже не активировать, т.к. после окончания пробного периода он продолжит работать как полноценный сервер без каких-либо ограничений. Просто вместо красивых обоев на рабочем столе будет чёрный цвет и надпись, что нужна активация. В таком состоянии оно может работать десятками лет.


Иными словами, можно вообще не покупать никаких лицензий на Windows Server, но иметь при этом работающий сервер Active Directory (AD DS).

Иными словами, можно вообще не покупать никаких лицензий на Windows Server

Технически - да, но некоторым компаниям всё еще надо изображать законопослушность...

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

Вот на этой странице пишут, что в группу FreeIPA можно добавить пользователя, другую группу, сервис или внешнюю сущность из AD.

Там небольшой костыль по федерализации гетерогенной среды, к моему тезису он не имеет отношения.

В смысле — не имеет отношения? Вы писали что нельзя добавить одну группу в другую. Я привёл ссылку где написано как это делается.

Попробуйте практически добавить одну группу Linux в другую, в терминах FreeIPA это "POSIX group", и это должно работать локально на Linux, т.е. адекватно с PAM, nsswitch, sudoers и т.д.

Чтобы это пробовать, надо сначала где-то развернуть freeipa и клиент к нему. Может, вы всё-таки сами расскажете, что не так с командой ipa group-add-member foo --groups=bar?


"Linux не поддерживает" — это вообще не ответ, линуксу сервер аутентификации передаст полный список групп, ему и не надо ничего поддерживать...

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

Процесс получения списка групп для пользователя определяется настройкой initgroups в файле nsswitch.conf, и ему можно подсунуть библиотеку с абсолютно любым алгоритмом.


Поэтому я не вижу ничего фундаментального в этих ограничениях.

Ваш комментарий, хотя и не имеет отношения к изначально озвученному тезису, но показывает другую проблему подобных навесных защит - представьте, у вас предприятие с парой тысяч пользователей разбитых на пару сотен групп, по подразделениям и ролям. Как вы думаете какая будет производительность у любых программ, попытавшихся получить список пользователей и групп описанным вами способом (всего одном из, к слову)? Это риторический вопрос.

Конкретно у initgroups производительность будет достаточной, пара десятков групп (а у пользователя больше не будет) — не то что может сильно ударить по производительности.


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

Конкретно у initgroups производительность будет достаточной

Практика показывает, что настолько "достаточной", что демоны будут сниматься по тайм-аутам как зависшие, логин в систему происходить минуты, а консольные программы и скрипты станут практически неюзабельными.

Это точно где-то в другом месте проблема, не в количестве групп. Скорее всего, кто-то в цепочке не умеет управлять постоянными TCP соединениями и устанавливает новое на каждый запрос.

Вот вы и разрешили фундаментальное отличие в моделях безопасности, теперь ГК "Астра" не нужно создавать/продавать ALD Pro и специальную версию дистрибутива, дело оказывается просто в цепочке неумелых соединений TCP...

"Доверительные отношения могут быть установлены как между лесами, где FreeIPA выступает в роли леса с одним доменом (Forest Trust), так и между конкретными доменами (External Trust)" - В терминологии AD DS, Forest Trust - это доверительные отношения по протоколу Kerberos между двумя лесами AD DS, которые могут быть односторонними и двусторонними, с выборочной (Selective) и Forest-Wide авторизацией, кроме того, эти доверительные отношения транзитивны внутрь обоих лесов. Под External Trust в ADDS понимаются доверительные отношения с legacy доменами Windows. Они односторонние, не транзитивные и не используют протокол Kerberos (используют NTLM). Доверительные отношения между доменом ADDS и Kerberos realm в ADDS называются Realm trust, используют протокол Kerberos, могут быть односторонними и двухсторонними, транзитивными и нет (в зависимости от того, поддерживает ли СК многодоменную структуру). Какие типы доверительных отношений имеет ввиду автор статьи?

К тому же в этом утверждении "Доверительные отношения дают возможность пользователям одного домена выполнять прозрачную аутентификацию по протоколу Kerberos при обращении к ресурсам другого домена. "автор путает термины аутентификация и авторизация.

какие типы доверительных отношений

В некоторых публикациях действительно встречается информация о том, что внешние доверительные отношения (External Trust) работают через NTLM и не поддерживают транзитивность, но в настоящее это уже не так. Этот вид отношений используют в тех случаях, когда доверие нужно организовать между двумя конкретными доменами. Аутентификация, как и в случае Forest Trust, будет выполнена с использованием протокола Kerberos V5, и только в случае неудачи произойдет переключение на NTLM. Предлагаем ознакомиться со следующей статьей:

https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/dd560679(v=ws.10)?redirectedfrom=MSDN#external-trusts-vs-forest-trusts

термины аутентификация и авторизация

Если вдаваться в детали, то при обращении пользователя к ресурсу сначала выполняется идентификация (пользователь должен представиться), затем аутентификация (выполняется проверка, что пользователь является тем, за кого себя выдает), и уже в конце авторизация (проверяется, что пользователю предоставлено право на доступ к запрашиваемому ресурсу). Если полностью исключить любую недосказанность, то предложение станет просто длиннее: Доверительные отношения дают возможность пользователям одного домена выполнять прозрачную аутентификацию по протоколу Kerberos, [что необходимо для получения авторизованного доступа] при обращении к ресурсам другого домена.

Sign up to leave a comment.