Single Sign-On, или Танцы Шестерых

[ildarz]

А зачем вы используете для апача winbind и NTLM, если ставили Kerberos?

Ну и если серьезно, то про эти схемы пора начать забывать и использовать SAML SSO (с ADFS на стороне винды).

[Greyder]

Согласен, однако иначе было не выкрутиться (ну или не получилось) – серьёзная компания, серьёзная безопасность, все гайки закручены «по самое не хочу», требование невмешательства в MS-инфраструктуру и много прочих ограничений, в т.ч. сетевых.
Копания с прочими Апачевыми mod_* результата не дали, в лучшем случае получилось аутентифицироваться, но опять-таки с появлением дополнительного окошка ввода логина-пароля. А требование было однозначное – юзер входит в Windows под доменным аккаунтом, и более нигде никогда и никто никаких credentials у него не спрашивает.

SAML SSO – согласен.

[pda0]

А есть где-нибудь адекватные инструкции как настроить saml sso на apache 2.4 на linux? Как раз сейчас бьюсь. (Так чтобы имя пользователя было передано сайту, а то у MS в качестве примера даже показано «сначала вы вводите логин/пароль на adfs, а потом в сайте»)

[DAiMor]

Дмитрий, поздравляю с первой статьей.
Несколько лет назад, работая в одной известной нам обоим компании, для одного из клиентов с SuseLinux на сервере, так же стояла такая задача. Реализовано было с помощью керберос, самба там действительно не нужна. Насколько я помню использовал mod_auth_kerb, проблема с ним только что он под 2.4 не работает вроде, старый. Проблемы вроде возникали с обновлением керберос тикетов. А так вроде работает и по сей день и кстати во всех браузерах а у них основной был Firefox.
Для других клиентов с Windows Apache, этого модуля не было, использовали mod_auth_sspi, вроде.

[Greyder]

Дима, спасибо!
Ты прав. В принципе можно обойтись Керберосом (не забывая на кронтаб повесить обновление тикетов). Но на площадке он был, мягко говоря, «прикрыт», и да, модуль староват.
A модуль SSPI вроде только для виндового апача есть?..

[DAiMor]

да, sspi насколько я помню был только виндовый

[sebres]

Нужно наверно как то отделять котлеты от мух.
SSO-аутентификация (да и другие shared схемы аутентификации) делается на раз-два. И так как вы описали, и на том же nginx и другом каком стэке...

А вот AAA — это штука совсем не тревиальная. Т. е. идентифицировать пользователя это одно, а протащить его token через все "шлюзы" от load-balancer до конечного backend (работающего как правило еще и не на том же самом сервере, который получил/валидировал credential), чтобы собрать ACL или получить security descriptor (или имперсонировать handle воркера), например чтобы прочитать/изменить какой-либо ресурс (тот же файл), для которого права выдали в AD/PDC/etc — то еще удовольствие.
И на стэке НЕ от мелко-мягких, нередко отбивает всякое желание юзать AAA (в не обрезаном виде).

Про лиса и хром… Не знаю, у меня всегда работало все из коробки. Может у вас NTLMv1 (или подобное)? Тогда действительно нужно включать network.auth.force-generic-ntlm-v1 и иже с ним (например добавлять домен в network.automatic-ntlm-auth.trusted-uris) в about:config.

[Abyss777]

Как-то всё сложно…

1. Ставим PBIS Open
2. Вводим в домен sudo /opt/pbis/bin/domainjoin-cli join --assumeDefaultDomain yes --ou ... MY-DOMAIN.RU admin
3. Ставим модуль apache mod_auth_kerb
4. В конфиг сайта apache добавляем
   AuthType Kerberos
AuthName "Domain Login"
KrbMethodNegotiate On
KrbMethodK5Passwd On
KrbAuthRealms MY-DOMAIN.RU
Krb5KeyTab /etc/krb5.keytab
KrbServiceName Any

Последние две строчки означают использовать keytab компьютера и любой ServiceName, а не только HTTP/host.my-domain.ru