13 октября 2009 г. 0:01 пользователь Paul Wolneykien <mano...@altlinux.org> написал: > В Пнд, 12/10/2009 в 21:53 +0400, Evgeny Sinelnikov пишет: >> 12 октября 2009 г. 15:13 пользователь Paul Wolneykien >> <mano...@altlinux.org> написал: >> > >> > Всем привет, >> > >> > В ходе обсуждения текущего состояния модулей alterator-openldap и >> > alterator-ldap-users, у нас с Димой (dkr@) возник вопрос о том, каким >> > вообще должно быть правильное построение авторизации управляющего модуля >> > в управляемые службы? >> > >> >> Давайте уточним вопрос о том, что мы называем авторизацией, а что >> аутентификацией? > > Речь про аутентификацию, естественно. Наверное, следовало так и > написать, да? :p >
Да. >> Если я правильно понял, то вы имеете в виду единый механизм >> аутентификации. Такой механизм существует. Он называется Kerberos. >> Разработан он в MIT и уже давно активно используется. > > В ПП есть некоторая поддержка Кербероса. Поэтому этот вариант уже был > взят на заметку. Но вот ведь в чём вопрос: наверняка не все сервисы > поддерживают аутентификацию через Керберос. Взять тот же LDAP. Как в > рамках вызова команды ldapsearch, например, сказать, что "у меня есть > тикет, пустите"? В man ldapsearch упоминается некий SASL как подсистема > аутентификации. Может быть через него? А MySQL? А Samba? > Есть мнение, что ldap для таких задач слишком громоздок. Хороший пример - Samba. Этот сервис построен на базе RPC. Всё, что нужно, чтобы удалённо выполнять заданные команды - это RPC. Samba построена поверх механизма с прозрачной аутентификацией в Kerberos. При этом, она имеет аутентифицироваться не только через Kerberos. В Active Directory управление сервисами осуществляется всё тем же RPC на основе, которого построена сетевая файловая система (CIFS), которая и реализована в Samba. Но это один из сервисов. Это и есть единый набор механизмов управления, даже Samba поддерживает некоторые из механизмов удалённого управления на основе этого RPC. При наличии таких механизмов, в виде заданного, расширяемого протокола, нивелирует необходимость использования каких-либо других. Тем не менее такие монстры, как LDAP, остаются в силу legacy - большого числа клиентских наработок. Не стоит, конечно, забывать и о специализация. LDAP ориентирован на доступ к иерархическим данным, SQL - к табличным.... В случае же с управлением и получением авторизационной информации, использование LDAP является излишним. Вместо него можно использовать всё тот же выбранный RPC с прозрачной аутентификацией... В общем, это моя, вероятно спорная, но аргументированная позиция. > Однако, если окажется, что самые популярные сервисы пускают по > билетам, то значит велосипед изобретать не нужно. > Действительно... Но, если они вдруг пускают через PAM, то толку от них всё равно немного. Проще научить пускать по билетам. >> >> В частности, на нём построена и Microsoft Active Directory, которая и >> является, по сути, системой управления сетевыми сервисами. >> >> В принципе, Kerberos можно использовать и отдельно от единого >> механизма авторизации (LDAP, MySQL, etc). Например, именно так его >> используют в простых решениях описанных в документации по безопасности >> для FreeBSD. Последняя, конечно, не является примером для подражания, >> но, как пример, посмотрите. > > Кроме того, у Димы почему-то были возражения на счёт Кербероса на всех > узлах. Аргументы были примерно такими: "а что если сеть 'простая' и там > нет Kerberos?". > В простых системах, где нет Kerberos - нет прозрачной аутентифкации. Там используются разные механизмы. Обычно простой пароль или хеш развёрнутый в SSL. С некоторый пор. У нас SSL умеет Kerberos. В любом случае поддержка всех необходимых видов аутентификации требуетс сразу на вех клиентах, где планируется такое то централизованное, то "простое" управление. > 2dkr@: Существует ли проблема развёртки Kerberos на каждом из узлов? Существует. Kerberos жёстко привязан DNS именам и ко времени. Хотя, для DNS, можно обойтись и Avahi, в сети с централизованным управлением имеет смысл держать свой DNS. В плане же ntp, для синхронизации времени, есть некоторые особенности протокола, которые мешают разёртыванию при отсутствии интернета. > Если да, то в чём она заключается? И что, по твоему мнению, поможет > облегчить развёртку? > Наиболее облегчённый вариант развёртывания разрабатывался в рамках Tartarus. В двух словах всех сложностей не описать - это механизм нужно отрабатывать. В текущем виде можно увидеть процесс развёртывания, установив Tartarus из сизифа. PS: Я думаю, что сейчас уже можно сделать работающее решение, несмотря на костыли и утечки памяти в kerberos, которые можно обойти. Но, для реализации этого, нужно потратить некоторое время. Если решение требуется в короткие сроки (менее года), если, вместо разработки архитектуры придётся кому-то что-то доказывать, если нет опыта и денег на привлечение разработчиков, то лучше за эту задачу не браться. PPS: Присоединяйтесь к Tartarus - давайте сделаем для него поддержку в alterator, давайте обновим Samba, соберём sssd. В общем, всё это требует работы - давайте пробовать, -- Sin (Sinelnikov Evgeny) _______________________________________________ devel-conf mailing list devel-conf@lists.altlinux.org https://lists.altlinux.org/mailman/listinfo/devel-conf
