Единая база пользователей для windows и Linux

LDAP
статьи ищи не опеннете

LDAP мало чем может помочь для реализации single sign-on. LDAP служит для хранения авторизационной информации пользователей, аутентификацию (проверку паролей) нужно организовывать через Kerberos. Kerberos - это протокол, одна из реализаций включена в AD. Мелкомягкая реализация страдает некоторыми особенностями, но свободные реализации (MIT-Kerberos, Heimdal) по слухам могут с ней взаимодействовать. Я пробовал только в обратном направлении - виндовые клиенты аутентифицируются в линуксовом контроллере Kerberos.
Как такового исчерпывающего документа как реализовать, то что вы хотите (smtp, pop, imap, samba) нет, но есть много статей где рассматривается взаимодействие с одним из этих протоколов. Про самбу была статья в Системном Администраторе - Танцуем Самбу Роман Гребенников (11-2004). Можно начать оттуда. Все почтовые протоколы интегрируются с Kerberos через Cyrus-SASL (механизм GSSAPI), но, насколько я знаю, никакой документации уровня HOWTO по этой теме не существует. Единственная проблема, что почтовых клиентов, которые используют этот механизм в полном объеме ровно 2 - Pine и последние RC Thunderbird.

> LDAP мало чем может помочь для реализации single sign-on.
> LDAP служит для хранения авторизационной информации пользователей,
> аутентификацию (проверку паролей) нужно организовывать через Kerberos.
Опять же вести две паралельные базы и в ldap и в kerberos?
если не считать тот ущербный тестовый вариант heidmal когда он работает с ldap от anonymous
У меня ldap, домен samba, jabber, sendmail, pop, squid все завязано на авторизации.
может чего и забыл.
отсутствием kerberos не страдаем :)

У вопрошающего было требование - "Пароль при этом должен запрашиваться один раз - при входе в домен." Расскажите как этого добиться средствами LDAP.
>Опять же вести две паралельные базы и в ldap и в kerberos?
А что тут неправильно? kerberos держит имя пользователя и его пароль, ldap все остальное (кроме пароля) + имя пользователя. Типичная ситуация двух таблиц с общим индексом.

копай nsswitch и winbind

>>копай nsswitch и winbind

Нафиг мне копать winbind? Чтобы обнаружить, что внутри это тот же самый Kerberos, только в профиль?

и с каких ето пор winbind стал керберосом =)

The service provided by winbindd is called `winbind' and can be used to resolve
user and group information from a Windows NT server. The service can also pro-
vide authentication services via an associated PAM module.

The pam_winbind module supports the auth, account and password module-types. It
should be noted that the account module simply performs a getpwnam() to verify
that the system can obtain a uid for the user, as the domain controller has al-
ready performed access control. If the libnss_winbind library has been correctly
installed, or an alternate source of names configured, this should always suc-
ceed.

С 2000 года ;)
http://www.redmondmag.com/columns/article.asp?EditorialsID=858
* Winbind with Samba: The winbind service uses Samba for configuration information. For AD interoperability, make sure your system is running a current version of Samba (3.05 or newer).
* Kerberos: Winbind uses Kerberos to get tickets for accessing AD. A Windows domain controller acts as the Key Distribution Center (KDC).

Чтобы прекратить бессмысленный обмен цитатами - расскажи каким образом удаленный IMAP сервер только через LDAP (или winbindd) может узнать, что некий пользователь может прочитать мэйл-бокс пользователя vasya. По условию задачи IMAP не спрашивает у пользователя пароль. Каким волшебным образом сервер проверит, что этот пользователь именно vasya. Я совершенно серьезно спрашиваю. Если ты считаешь, что мне нужно RTFM, кинь ссылку на внятный документ, а не на man winbindd.
nsswitch тут совершенно не причем. Это средство получения UID/GID для линуксового пользователя из какого-то хранилища авторизационной информации (не обязательно LDAP). Пусть даже у тебя записано shadow: ldap. Но что это дает? Что пароли сверяются с базой ldap, а не с локальным /etc/shadow. Как IMAP сервер узнает, что я уже ввел пароль при входе на свою рабочую станцию и его не нужно проверять снова?

Не умничайте, как работает kerberos здесь все представляют. неспрашивает пароль но спрашивает билеты !?!?
Только вот сами же сказали что работать с этим могу только _всего_две_клиентские_программы_ вот в этом и все проблемы.

Уважаемый gekkoo а про какой домен вы говорите? В первый раз слышу чтобы samba могла авторизоваться из kerberos. По крайне мере smb.conf на предмет passwd backend об этом молчит да и вообще упоминания слова kerberos в нем минимальны. Подтолкните пожалуйста в нужном направлении, хочу сделать у себя!

поверь мне все работает через winbindd и на linux машине нет ниодного
пользователя все пользовотели в AD win3k и в IMAP rev1 проверка о входе происходит по NTLM и любой Outlook работает по NTLM протоколу


0000 CAPABILITY
* CAPABILITY IMAP4 IMAP4rev1 IDLE LITERAL+ AUTH=NTLM
0000 OK CAPABILITY completed
0001 AUTHENTICATE NTLM
бла бла бла
0001 OK AUTHENTICATE NTLM completed

ешо вопросы будут ?

Здорово пофлеймили, если к одиннадцатому посту стали выяснять, о чём именно флеймили :)

Далее будет длинный и занудный текст, так что просьба подготовиться. Я вообще-то рассчитывал, что мне тут тоже кое-что интересное расскажут, но оппоненты многословием не балуют.

В случае, если у нас в сети смесь виндовых и линуксовых станций, единственно возможная система удаленной аутентификации _И_ авторизации это ActiveDirectory. Различие между ау. и ав. в том, что для аутентификации пользователь Вася должен доказать, что он vasya, а не petya или masha. После того как vasya аутентифицирован (и только после того!) система должна решить какими правами этот vasya обладает (т.е. выдать ему линуксовый UID/GID или виндовый SID) - это и есть авторизация. Если аутентификация вещь универсальная, то авторизация зависит от операционной системы, поскольку никакого стандарта на то, как выглядит авторизационная информация пользователя нет. Поэтому в сети к авторизации следует относиться как к своего рода информационной службе, и не следует еакручивать на ней какую-либо систему безопасности. Вообще говоря, LDAP хорош, когда нужно организовать что-то вроде общей address-book внутри сети. Единая система авторизации - вопрос только удобства администрирования, хочет ли администратор сети управлять всей информацией о пользователях с помощью единой базы или ему достаточно синхронизировать локальные данные о пользователях.
В сетевом окружении (совершенно абстрактном) аутентификация гораздо важнее, чем авторизация. В принципе любой сервис, который хоть как-то спроектирован на секурность, должен аутентифицировать пользователя, а его права это уже дело десятое, но никак не наоборот. Опять же по желанию администратора авторизационная информация может храниться в одном месте или быть индивидуальной для каждого из сервисов. Администратор может ту же сказать - "Хочу штоб из одного!", но тут есть несколько возражений.
Поскольку никакого стандарта о том как должна выглядеть авторизационная информация нет, то любая система (а также сервис) может потребовать определенных прав у пользователя, причем для другой службы они совсем лишние. LDAP наиболее близко вписывается в универсальную модель, но далеко не всегда.

В принципе этих доводов, на мой взгляд достаточно, чтобы требовать разделения (как сервисов) сервиса удаленной аутентификации и сервиса авторизации. Kerberos выполняет только аутентификацию пользователя, поэтому нет проблем использовать его в гетерогенной среде. Те любая реализация Kerberos (MIT, Heimdal, мелкомягкий AD) с этим справится. Но способ авторизации уже зависит от того, какая система стоит на локальном компьютере, где и какой сервис используется. В принципе возможна даже ситуация, что на рабочих станциях информация о пользователе локальна, а на серваках используется отдельная система авторизации (общая между серверами). Важно только, чтобы сервисы аутентифицировали пользователя в Kerberos и было бы соответствие между локальным именем пользователя и принципалом Kerberos. И всё!

Теперь про ActiveDirectory. Если бы сеть состояла только из юниксовых тачек (что нереально), AD нафиг не нужен - аутентификация через Kerberos, авторизационная информация в LDAP (или даже просто в Hesiod). Но WinXP понимает только либо локальную авторизацию (SID хранится на локальном компьютере), либо AD. Причем это не касается аутентификации - можно заставить виндовые рабочие станции аутентифицироваться в Kerberos (те при входе на рабочую машину пользователь вводит свой пароль, который потом проверяется Керберосом, и в результате пользователю выдается билетик, который он потом может использовать для доступа к сетевым ресурсам). Но SID, который выдается пользователю, все равно локальный, те берётся откуда-то из реестра или что-там у них вместо /etc/passwd. Эта настройка совершенно ортогональна ActiveDirectory. AD - это прохаченный Керберос, куда мелкомягкие умельцы напихали еще авторизационную информацию, а способ которым они это сделали тщательно прикрыли лицензиями. В результате ни одной свободной реализации AD не существует. Т.е. в домене AD сервером может выступать только машина c Windows, клиенты, впрочем, могут быть любыми. Опять же, AD нужен только если вам важно, чтобы аутентификация и авторизация проходила, так сказать одновременно и одинаково по всей сети. Как уже я говорил, если в сети пользователи кувыркаются как хотят, а на серверах (в DZ), которые уже могут быть сплошь линуксовыми, используется своя собственная база пользователей, то AD в такой конфигурации может быть не нужен. Достаточно, что есть LDAP используемый сервисами и Kerberos, используемый по всей сети.

По поводу самбы. Самба3 поддерживает Kerberos. Скачайте исходники, зайдите в samba-3.0

Это ещё не конец :), кнопкой промахнулся.

Самба3 поддерживает Kerberos. Скачайте исходники, зайдите в samba-3.0.21/source и выполните ./configure --help. и ищите опцию --with-krb5 и --with-ads. Как настроить самбу для работы c AD написано в статье, ссылку на которую я уже давал. Можно скачать здесь - ftp://194.67.79.2/32-38+Samba.zip Там же две части статьи про heimdal (в частности рассказано как настроить виндовые тачки на работу с хеймдалевым kdc) - heimdal_2.zip heimdal_part2.zip. Настройка самбы (и виндовз машин) тоже можно нагуглить (ссылку я потерял), но ничего особенного там нет - настраивается как обычный сервис-принципал cifs/<server>. Если найду ссылку - кину сюда.

Замечания и критика приветствуются ;)

Какой смысл поддерживать закрытый стандарт, от которого сами мелкомягкие отказываются ?
http://www.webopedia.com/TERM/N/NTLM.html

У нас много есть "любых аутглюков" на Линуксе?

Ну, я даже могу согласиться, что такой вариант тоже имеет право на существование. С оговорками только, что этот способ уже deprecated и вскоре вообще может накрыться.

ненравится NTLM
тогда можно и SFU как вапиант
http://www.osp.ru/win2000/2004/01/028.htm

NIS R.I.P.

> Самба3 поддерживает Kerberos.
> Скачайте исходники, зайдите в samba-3.0.21/source
> и выполните ./configure --help. и ищите опцию --with-krb5
> и --with-ads

Но только _как_клиент_АД_ !!
Но на вопрос не ответил, какой у Вас домен?
Или все что сейчас здесь написано это только в твоей теории?
Давай ткни меня в доку где samba контроллер домена + авторизация через kerberos и где все sidы ridы аля uidы хранить?

Какая, в жопу, авторизация через керберос? Ты читать умеешь или только писать? У меня не домен, а realm. Какой тебе еще домен нужен, да ещё с самбой в качестве контроллера?
http://sial.org/howto/kerberos/windows/