Jabber (XMPP) + Windows + SSO, часть 1
Под катом чисто техническая статья про настройку Jabber-сервера под Linux и клиентов к нему под Windows с одновременным прикручиванием формирования контакт-листа из AD LDAP с SSO-авторизацией посредством Kerberos.
Сперва небольшой обзор имеющихся доступных решений.
Как ни странно, из актуальных Jabber-серверов SSO / GSSAPI поддерживают все три: eJabberd, Openfire, Prosody. Первый я не осилил ввиду зубодробительности erLang-а. Точнее, в дефолтной конфигурации его запустить как раз плюнуть (спасибо дистростроителям). Но вот если надо прикрутить что-то эх-такое, чего изначально не было предусмотрено в конструкции, возникает дикая попа-боль. Второй весьма user-friendly, большинство фич работают из коробки. Но это Java со всеми вытекающими. В частности, даже банальное подсовывание SSL-сертификата сразу превращается в увлекательнейший траходром. Третья лишена большинства недостатков первых двух, но она отвратительно (точнее, почти вообще никак) не документирована и не масштабируется. В том плане, что до 100...150 пользователей работает ОК, потом начинает тупить, тормозить и валиться. Конкретно мне больше и не надо, поэтому я взял в качестве сервера Prosody. О ней и пойдет дальнейший разговор.
Касаемо клиентов. Всего хоть как-то GSSAPI под виндой сейчас поддежривают: Miranda, Psi, Spark, Pidgin.
Miranda хороша-красива, когда "обвешана". На "голую" (без плагинов) без слёз не взглянешь. Если же надо обновить версию, то "обвес" придётся формировать заново. Она не enterprise-friendly. Она глючновата в плане интерфейса. Может, например, почему-то не показать поступившее входящее сообщение. Может обвалиться после очередного обновления винды. Не проверяет SSL-сертификат сервера на валидность. Одним словом, мы попробовали, попользовались, нам не понравилось.
Что касается Psi, то для реализации GSSAPI там надо самостоятельно собирать Qt-шную библиотеку под названием qca-wingss. Готового бинарника я ожидаемо не нашёл, а скопилировать самостоятельно ниасилил.
Spark - это опять же Java, со всеми вытекающими. Кто желает, может пользовать. Меня от неё тошнит.
Остался Pidgin. Но и тут всё не слава богу. Во-первых, последняя виндовая версия, которая ещё умеет GSSAPI - это 2.10.11. В более свежих поддержку GSSAPI/SSPI выпилили (это касается только виндовых сборок; под линуксом всё нормально). Во-вторых, на клиентские машины нужно дополнительно ставить MIT Kerberos for Windows. Берут здесь. В более-менее "стандартной" конфигурации каких-то дополнительных настроек не требуется, в не совсем типичных случаях его тоже потребуется "подкрутить".
Окей, с выбором софта более-менее разобрались. Теперь некоторые неочевидные нюансы. Полностью процесс "от А до Я" расписывать не буду. Потому что в энторнетах есть некоторое количество хаутушек, да и админ, взявшийся за подобную задачу, наверняка уже обладает некоторыми навыками и компетенцией. Расскажу о том, во что "влетел" конкретно я.
Что касается сервера. Документация к нему не отличается точностью и полнотой. Там есть определённая путаница. Следует учитывать, что до версии 0.8 данный механизм был реализован в модуле "mod_saslauth" через прокладку в виде saslauthd. После версии 0.8 функционал был перенесён в отдельный модуль "mod_auth_cyrus", а saslauthd больше не нужен. То есть пакет "sasl2-bin" можно и не ставить, а руководствоваться нужно вот этой статьёй.
Далее. Как всегда, требуется сформировать в системе правильный конфиг "/etc/krb5.conf" и сгенерировать keytab. И самое главное, prosody должна иметь доступ на чтение и к тому, и к другому. Если вовремя не вспомнить, что в Debian-е по умолчанию она запускается из-под отдельного непривилегированного пользователя, то могут возникнуть весьма трудно диагностируемые проблемы и странные совершенно неинформативные фатальные ошибки в логах.
Кроме того, если в том же OpenFire функционал импорта пользователей из AD реализован "из коробки", то в случае c Prosody его придётся колхозить самостоятельно, ручками. Это не так уж и сложно, но это нужно сделать. Об этом я напишу во второй части.
Теперь что касается клиента.
Pidgin-а ставим как обычно, но не свежее версии 2.10.11. С MIT Kerberos никаких премудростей нет, обычный wizard типа "xyяк, xyяк и в продакшн" "next, next и готово". На последнем шаге он спросит, надо ли автоматически стартовать при логине пользователя и надо ли сразу получать Kerberos-тикеты. Ответ: нет, не надо. Впрочем, на самом деле пофиг. Будет работать и так, и так.
В самом Pidgin-е в настройках аккаунта указываем только логин, имя домена и ресурс. Поле "пароль" оставляем пустым. Примерно так.
Если по условию задачи Kerber-осовский Realm совпадает с Jabber-овым доменом, то больше никаких действий предпринимать не нужно. Всё заведётся, пользователь успешно залогинится. В противном случае придётся совершить ещё ряд небольших шаманств.
Во-первых, сделать текстовый файл с названием "krb5.ini" по аналогии с линуксовым "krb5.conf" с указанием KDC и сопоставлением сущностей "domain" и "realm". Чтобы оно понимало, из какого Realm-а запрашивать ключи для того или иного домена и где вообще искать KDC (Key Distribution Center). Упомянутый "krb5.ini" следует положить либо в "c:\windows", либо в профиль пользователя (по желанию админа). Во вторых, после неудачной попытки залогиниться нужно назначить "Default Ticket" прямо в интерфейсе MIT Kerberos (на скриншоте обвёл синим прямоугольником). Это требуется сделать ровно один раз. Возможно, данную настройку можно выполнить и через реестр. Не знаю, настолько глубоко не ковырял.
Как-то так и настраивается SSO-аутентификация. Про формирование ростера (списка контактов и групп) читайте в следующем псто.