Grundik's lair

Надоело набирать каждый раз пароли? Надоело иметь отдельный пароль для почты, для шар, для ssh и т.п.? Решение есть — подход  называемый Single Sign-On (SSO, единый вход), при которой пароль вводится один раз, и уже в дальнейшем он не нужен. О его реализации с помощью Kerberos я попробую рассказать. Также речь пойдет об NFSv4 с kerberos авторизацией и о настройке различных служб и сервисов для использования SSO/Kerberos.

Цербер — централизованная система проверки подлинности. Чем-то похож на RADIUS, но предназначен исключительно для авторизации, и в том числе авторизации по ранее выданному ключу. В знакомой многим технологии Active Directory авторизация реализована именно на основе kerberos. RADIUS сервера зачастую умеют авторизировать своих пользователей через kerberos.

Пароли цербера в открытом виде по сети не передаются, и вообще система считается весьма безопасной. Однако следует понимать важность SSO пароля — он един для всех сервисов, доступных данной учетной записи, и его разглашение или утеря могут привести к катастрофичным последствиям. Однако из-за того что пароль един, то и запоминать надо его одного, что позволяет менять его сколь угодно часто. А так как он требуется один раз — пароль может быть сколь угодно сложным. И этими двумя возможностями пренебрегать не следует. Также следует понимать, что хоть для самого цербера пароли в открытом виде не передаются, однако если вы его вводите не для авторизации на локальной машине, а передаете через незащищенное соединение — то это компрометирует пароль.

Учетные записи в kerberos обозначаются следующим образом: пользователь@ДОМЕН или сервис/хост@ДОМЕН. Где ДОМЕН (Realm) это собирательное наименование, которое принято писать заглавными буквами, и обычно с приставкой @. Имена учетных записей чувствительны к регистру. Все сервера, пользователи и машины как правило имеют один realm. Однако допустима и кросс-доменная авторизация, но ее настройка это отдельный вопрос. В данной статейке я буду предполагать, что у всех используемых записей одинаковый домен.

Серверная часть цербера состоит из двух компонентов: сервер выдачи ключей (KDC) и сервер администрации (KADMIN). KDC предназначен для клиентов: он авторизирует клиентов и выдает им тикеты. KADMIN же, в свою очередь, предназначен в основном для администраторов. В реальности при штатной работе он практически не нужен, за исключением смены паролей клиентами.

Существует несколько реализаций цербера, как открытых так и закрытых. Они совместимы между собой, но отличаются настройкой (серверной части, для клиентов в основном все одинаково и автоматически). В этой статейке предполагается реализация MIT. В ней KDC работает и по IPv4 и по IPv6, а KADMIN только по IPv4.

Вкратце система авторизации в kerberos такова: клиент авторизируется с помощью пароля на сервере выдачи ключей, и тот выдает клиенту «мастер-тикет», который действителен определенное время. В дальнейшем, когда клиенту нужно авторизоваться на каком-либо ресурсе, из «мастер-тикета» клиент делает сессионный тикет, который и используется для авторизации. Т.е. вводить пароль второй раз уже не нужно. Из этого следует необходимость синхронизации времени между всеми машинами, участвующими в обмене данными: сессионный ключ действителен обычно 5 минут, и если часы расходятся на бóльшее время, то авторизация не удастся. Благо во всех современных ОС есть клиенты NTP, что эту проблему эффективно решает.

Установка Kerberos сервера

Установку в дальнейшем расписываю для debian-based дистрибутивов linux, однако в других системах больших отличий быть не должно. Итак, для начала нужно поставить необходимые программы: они находятся в панетах krb5-admin-server и krb5-kdc. Также полезны krb5-clients. При установке можно разрешить сгенерировать начальные настройки. В результате настройки будут сгенерированы приблизительно следующие:

/etc/krb5kdc/kdc.conf:

[kdcdefaults]
    kdc_ports = 750,88
[realms]
    ДОМЕН = {
        database_name = /var/lib/krb5kdc/principal
        admin_keytab = FILE:/etc/krb5kdc/kadm5.keytab
        acl_file = /etc/krb5kdc/kadm5.acl
        key_stash_file = /etc/krb5kdc/stash
        kdc_ports = 750,88
        max_life = 10h 0m 0s
        max_renewable_life = 7d 0h 0m 0s
        master_key_type = des3-hmac-sha1
        supported_enctypes = aes256-cts:normal arcfour-hmac:normal des3-hmac-sha1:normal des-cbc-crc:normal des:normal des:v4 des:norealm des:onlyrealm des:afs3
        default_principal_flags = +preauth
    }

И в /etc/krb5.conf (за вычетом стандартной фигни):

[libdefaults]
        default_realm = ДОМЕН
[realms]
        ДОМЕН = {
#                kdc = kdc.сервер.домена
                admin_server = kadmin.сервер.домена
                default_domain = dns.зона.домена
        }
[domain_realm]
        .dns.зона.домена = ДОМЕН
        dns.зона.домена = ДОМЕН
[logging]
        kdc = FILE:/var/log/kerberos/krb5kdc.log
        admin_server = FILE:/var/log/kerberos/kadmin.log
        default = FILE:/var/log/kerberos/krb5lib.log

Если что-то в вашем случае отсутствует — полезно это добавить. Параметр «kdc» следует раскомментировать, если вы не собираетесь настраивать DNS, в противном случае он скорее вреден т.к. теряется централизованное управление этой настройкой через DNS. Параметр «admin_server», к сожалению, указывать придется хотя-бы на избранных машинах — kadmin не смотрит содержимое DNS. В качестве адреса kadmin сервера указывать 127.0.0.1 нельзя — на этом адресе сервер входящие соединения не слушает. Если сервисы не стартовали, и выдали какие-либо ошибки — ничего страшного. Т.к. фактически записей еще нет, то они и будут ругаться.

Создаем наш домен командой krb5_newrealm. На вопрос пароля важно дать ей действительно надежный пароль. Он практически никогда более не будет нужен, но лучше все-таки его где-то записать. После того, как домен создастся сервисы krb5-kdc и krb5-admin-server должны запуститься нормально.

Тестируем работоспособность, и заодно добавляем административного пользователя с помощью программы kadmin.local (здесь и далее в примерах жирным выделен вводимый текст, остальное — вывод программы):

# kadmin.local
Authenticating as principal root/admin@ДОМЕН with password.
kadmin.local:  listprincs
K/M@ДОМЕН
kadmin/admin@ДОМЕН
kadmin/changepw@ДОМЕН
kadmin/адрес.kadmin.сервера@ДОМЕН
kadmin/history@ДОМЕН
krbtgt/ДОМЕН@ДОМЕН
kadmin.local:  addprinc root/admin
WARNING: no policy specified for root/admin@ДОМЕН; defaulting to no policy
Enter password for principal "root/admin@ДОМЕН":
Re-enter password for principal "root/admin@ДОМЕН":
Principal "root/admin@ДОМЕН" created.
kadmin.local:  quit

kadmin.local — программа, предназначенная для администрирования базы учетных данных с сервера администрации. Она не требует пароля, т.к. работает непосредственно с файлами базы. Но при этом ей нужен полный доступ к этим файлам, т.е. запускать ее надо из-под root и на сервере. И лучше ее вообще не запускать, для штатной работы есть программа kadmin.

Делаем так, чтобы этот новый аккаунт имел административные права: в файле /etc/krb5kdc/kadm5.acl раскомментируем строку «*/admin *» и перезапускаем krb5-admin-server.

Проверяем новый аккаунт, и, заодно, работу kadmin. Заодно добавляем обычных пользоватей, которые в дальнейшем смогут пользоваться системой (имя пользователя должно совпадать с логином):

# kadmin
Authenticating as principal root/admin@ДОМЕН with password.
Password for root/admin@ДОМЕН:
kadmin.local: listprincs
K/M@ДОМЕН
kadmin/admin@ДОМЕН
kadmin/changepw@ДОМЕН
kadmin/адрес.kadmin.сервера@ДОМЕН
kadmin/history@ДОМЕН
krbtgt/ДОМЕН@ДОМЕН
root/admin@ДОМЕН
kadmin:  addprinc пользователь
WARNING: no policy specified for пользователь@ДОМЕН; defaulting to no policy
Enter password for principal "пользователь@ДОМЕН":
Re-enter password for principal "пользователь@ДОМЕН":
Principal "пользователь@ДОМЕН" created.
kadmin.local: quit

Итак, если все успешно, то можно логиниться в домен кербероса этим пользователем. Мастер-тикет получается и обновляется программой kinit, посмотреть статус полученных тикетов можно программой klist. Обе программы не требуют каких либо опций, и догадываются автоматически обо всем что надо.

Возможная ошибка «kadmin: Missing parameters in krb5.conf required for kadmin client while initializing kadmin interface» скорее всего означает, что в krb5.conf не прописан admin_server, или имя прописанного сервера не резолвится по IPv4.

Для упрощения настройки клиентов можно прописать настройки kerberos домена в DNS. Для этого следует создать такие записи в зоне, имеющей то же имя что и kerberos домен:

$ORIGIN домен.
_kerberos               TXT     "ДОМЕН"
_kerberos._udp          SRV     0 0 88 имя.kdc.сервера
_kerberos-master._udp   SRV     0 0 88 имя.kdc.сервера
_kerberos-adm._tcp      SRV     0 0 749 имя.admin.сервера

На этом настройка серверной части практически закончена. Ссылки для дальнейшего изучения на тему цербера:

• http://www.debian-administration.org/articles/570
• https://help.ubuntu.com/9.10/serverguide/C/kerberos.html
• http://www.informatik.fh-mannheim.de/linux/rhl-rg-en-9/ch-kerberos.html
• http://web.mit.edu/Kerberos/
• http://techpubs.spinlocksolutions.com/dklar/kerberos.html

Установка и настройка Kerberos клиентов

Базовая работа и основные принципы

Следующие программы будут полезны для работы и настройки:

• kinit — получает мастер-тикет с сервера. Если не указывать параметры, то получит тикет для текущего пользователя.
• klist — выводит список полученных тикетов. С параметром «-k» может показать содержимое файла ключей.
• kpasswd — позволяет сменить пароль учетной записи kerberos.
• kadmin — программа для администрирования базы учетных записей, требует права администратора KADMIN (прописываются в /etc/krb5krc/kadm5.acl).

Эти и другие полезные программы и нужные библиотеки предоставляются пакетами krb5-user и krb5-clients (а для винды можно воспользоваться реализацией от MIT). Настройка элементарна (особенно если вы прописали в DNS параметры сервера): устанавливаем пакеты, указываем наш домен и вуаля. Работоспособность проверяется через kinit и klist. kinit должен авторизироваться и не выдавать ошибок, klist же должен показывать тикеты.

Для удобной работы могу порекомендовать программку kredentials в одноименном пакете — она позволяет быстро, просто и через GUI получать и обновлять тикеты. Если она ругается на «unable to run aklog», что происходит когда не используется AFS, то создайте в /usr/local/bin файл aklog с правами на выполнение и содержимым:

#!/bin/sh
exit 0

А если/когда будете использовать AFS, то этот файл надо будет удалить.

Учетные записи бывают двух типов — учетные записи сервисов и учетные записи пользователей. Пользовательские записи предназначены (сюрприз) для пользователей и имеют пароль. Сервисные же для автоматической работы, пароля не имеют, состоят по сути из ключей для шифрования. и для их использования сервисами помещаются в специальные файлы ключей, keytab’ы.

Как уже говорилось выше, сервисные учетные записи выглядят как сервис/адрес@ДОМЕН. Имя сервиса предопределено для каждого из сервисов, домен также предопреден, а вот на адресе хочу остановиться поподробней т.к. это очень важный момент и может вызвать проблемы. Для доступа к сервису на какой-либо машине определяется ее адрес. Также он определяется, когда сам сервис на этой машине пытается получить свой ключ. Цербер чувствителен к имени хоста: если на клиенте имя распозналось иначе чем на сервере, то авторизация не произойдет. Алгоритм един для всех случаев:

• Начиная с версии 1.9.1+dfsg-2 в дебиане IPv6 (AAAA) запись также учитывается, и, по обыкновению, имеет приоритет перед v4 (A) записью.

  Распознается IPv4 (A) адрес машины. Именно A, AAAA не учитываются. Для определения «своего» адреса используется `hostname`, и далее резолвинг идет по стандартному алгоритму: берутся домены из поля search файла /etc/resolv.conf, и проверяется наличие в каждом из них нужного адреса. Если нету — берется следующий.

• От этого адреса этой A записи берется обратка. Если обратки нет — используется последнее имя, приведшее к этой A записи (что следует учитывать при использовании CNAME записей). Следует понимать, что записи в /etc/hosts работают в обе стороны: и для прямого определения имен, и для обратного. Причем для обратного определения используется первое имя.
  • Тонкость: при рапознавании адреса используется не только DNS, но и /etc/hosts. Причем используется не только при прямом, но и при обратном распознавании. Результат распознавания обратного адреса — первая прямая запись.
• Полученное таким образом имя и используется как имя хоста.

Т.е. адрес нормализуется с помощью обратки. Вытекающие нюансы и частные случаи:

• Обратка очень важна, при ее отсутствии нормализация не работает. Для многоадресных машин это вдвойне важно.
• Если вы коннектитесь к хосту, у которого нет A имени вообще, то для авторизации будет предъявлено то имя, которое вы используете.
• Если A запись есть, то имя нормализуется (при наличии обратки) в некоторое единое для этой машины (при этом сам коннект может быть и по IPv6, IPv4 нужно только для нормализации имени предъявляемого для авторизации).
• К сожалению загрузить несколько серверных ключей сервисы не могут, так что такую систему нормализации имен можно считать некоторым компромиссом. Но нужно понимать ее особенности, чтобы не было проблем. Основная проблема при отсутствии A записей или обраток — тогда нормализация не работает, и начинается кавардак. Также могут сильно подгадить настройки в /etc/hosts на серверах или клиентах.
• На сервере для настройки хостнейма для kerberos часто надежней всего вписать в /etc/hosts строку
  127.0.1.1 каноничное_имя короткое_имя_хоста имя_хоста
  где имя_хоста это вывод «hostname --fqdn», короткое_имя_хоста — вывод «hostname», а каноничное_имя — то имя, которое будет использоваться как хостнейм цербера. При таких настройках локальное имя будет распознаваться предопределенным образом. При этом необходимо добиться, чтобы это каноничное_имя также распознавалось и с удаленных хостов — прописать правильную обратку.
• В локальной сети весьма полезно настроить DHCP сервер так, чтобы он вписывал в DNS и прямые и обратные записи.

Сервисные учетные записи создаются также как и пользовательские, но с параметром «-randkey»:

kadmin:  addprinc -randkey сервис/адрес.машины
WARNING: no policy specified for сервис/адрес.машины@ДОМЕН; defaulting to no policy
Principal "сервис/адрес.машины@ДОМЕН" created.

В отличии от пользовательских учетных данных, которые хранятся исключительно на KDC, сервисные необходимо копировать на машину, которая этот сервис предоставляет. Для этого есть следующие подходы:

• С самой машины из-под рута запускаем kadmin, и даем команду сохранения ключей в файл: «ktadd сервис/адрес.машины» (если ругается на «kadmin: Missing parameters in krb5.conf for kadmin client while initializing kadmin interface», то необходимо вписать в секцию [realms] в /etc/krb5.conf блок используемого домена. К сожалению, как уже говорилось, kadmin не берет нужные параметры из DNS).
• С другой машины запускаем kadmin, даем команду сохранения ключей в файл: «ktadd -k файл сервис/адрес.машины», и безопасно перемещаем этот файл на целевую машину в нужное место.

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

Keytab файлы следует держать с соответствующими правами, т.к. они не зашифрованы. Их содержимое можно посмотреть утилитой klist. По умолчанию используется системный keytab: /etc/krb5.keytab, однако переменной окружения KRB5_KTNAME можно разнести keytab’ы разных программ в разные файлы.

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

NFS 4

Знакомый многим протокол виндового «сетевого окружения» samba/cifs далеко не единственный протокол для удаленного доступа к файлам. Например в мире unix есть вполне аналогичный протокол NFS. У NFS довольно много версий и реализаций, однако фактически они все весьма близки, и их можно разбить на две группы — с kerberos и без. Kerberos поддерживается начиная с 4й версии протокола.

Когда kerberos нет — все просто: устанавливаем NFS сервер, прописываем экспорты, и вуаля все работает. Правда с авторизацией по IP адресу (ну и максимум еще и ключевому слову). Фактически же это простой и быстрый способ реализовать обмен файлами между доверенными машинами в локальной сети (работает конечно и через инет, но завязана на фиксированные адреса, прописываемые в настройках, что мало подходит для инета. Да и передача данных совершенно открыта). Доверие к машинам тоже немаловажный момент в этом случае: доступ дается по сути всей машине, а не отдельному ее пользователю. Из-за простоты настройки такой системы не буду на ней останавливаться — man exports, man mount.nfs.

Вообще общая система довольно похожа на систему доменов на протоколе samba: также выделяется отдельный сервер для авторизации пользователей, также авторизируются и компьютеры и пользователи. Только в samba все «в одном флаконе», а тут по отдельности, что и приводит к сложностям настройки. Итак.

• Внимание: nfs-common версии 1.2.6 (до 1.2.6-3 включительно) с kerberos не работает. Необходимо либо ставить из снапшотов 1.2.5, либо версию 1.2.6-4 или старше (рекомендуется, т.к. в ней нет и бага в idmapd, описанного ниже)

  Пакеты, предоставляющие нужные возможности: nfs-common (для клиента) и nfs-kernel-server (для сервера).

• Имя сервиса — nfs.
• Сервисную запись необходимо создать не только для NFS-серверов, но и для NFS-клиентов (т.к. монтирует ресурсы де-факто не пользователь, а NFS-демон). И для сервера и для клиента имя сервиса одинаковое — nfs.
• Соответственно созданные записи необходимо прописать в keytab’ы. Для каждой машины ее собственный ключ.
• Внимание: idmapd до версии 1.2.6 настройку Domain игнорирует, проверить, какой именно домен используется для распознавания имен, можно проставив параметр Verbosity в 3 и перезапустив nfs-common, см. пост. А для настройки домена придется играться с /etc/hosts

  Для того, чтобы владельцы файлов примонтированных ФС отображались нормально, а не как nobody, в файле /etc/idmapd.conf и на серверах и на клиентах прописываем:

[General]
Verbosity = 0
Pipefs-Directory=/var/lib/nfs/rpc_pipefs
Domain=домен

[Mapping]
Nobody-User=nobody
Nobody-Group=nobody

[Translation]
Method=nsswitch

Параметр «домен» при этом должен быть одинаковым на всех машинах.

• Это не требуется для достаточно свежих версий ядра (3.2.0+) и nfs-kernel-server (1.2.5-3+, версии указаны приблизительно)
  В /etc/krb5.conf в секцию [libdefaults] желательно добавить «allow_weak_crypto=true» — в новых версиях цербера DES по умолчанию отключено, однако для NFS оно нужно.
• Удостоверяемся чтобы у всех машин в /etc/default/nfs-common были указаны параметры «NEED_IDMAPD=yes» и «NEED_GSSD=yes»
• Для серверов удостоверяемся чтобы в /etc/default/nfs-kernel-server был указан параметр «NEED_SVCGSSD=yes»
• Перезапускаем сервисы, и все должно работать: «invoke-rc.d nfs-common restart», «invoke-rc.d nfs-kernel-server restart».
• Одна и та же машина может быть одновременно и клиентом и сервером. Часто целесообразно чтобы все машины были одновременно и серверами и клиентами, поэтому действия для всех машин идентичны.

Для автоматического монтирования в /etc/fstab на клиенте следует указывать что-нибудь типа такого:

сервер:шара точка_монтирования nfs4 auto,user,rw,sec=krb5p 0 0

Для экспорта каталога можно использовать следующее (/etc/exports на сервере):

/ gss/krb5p(rw,sync,fsid=0,crossmnt,no_subtree_check)
/home gss/krb5p(rw,sync,crossmnt,no_subtree_check,no_root_squash)

Нюанс: экспорт корня (fsid=0) по gss/* обязателен, иначе будет возникать ошибка вида mount.nfs4: mounting failed, reason given by server: No such file or directory т.к. путь к экспорту не будет находиться сервером.

Параметр sec допускает следующие значения (каждый последующий включает все предыдущие):

• krb5 — требуется авторизация пользователя через цербера;
• krb5i — требуется проверка передаваемых данных на целостность;
• krb5p — требуется шифрование передаваемых данных.

Если указана авторизация через цербера, то для доступа к файлам будет обязателен тикет. Локальный рут будет иметь доступ как пользователь nobody (т.к. руту доступен тикет-ключ в keytab’е), но он не сможет читать/писать файлы если их права не позволяют. Менять права локальный рут также не сможет. Полноценный доступ будет только у тех локальных пользователей, у которых есть тикет от цербера.

Вот собственно и все, а напоследок еще несколько ссылок:

• https://help.ubuntu.com/community/NFSv4Howto
• http://wiki.debian.org/LDAP/Kerberos
• http://wiki.debian.org/NFS/Kerberos

Возможные проблемы:

• все работало, но вдруг на ровном месте перестало, и говорит что permission denied или аналогичное:
  • ключи устаревают, и вероятно следует их перегенерировать (если ключи созданы более года назад);
  • вероятно обновился какой-то пакет NFS, следует стараться держать по возможности одинаковые версии на всех машинах;
  • демоны NFS должны иметь возможность как минимум видеть каталог, чтобы позволить его монтировать, т.е. нужны права X на всю цепочку каталогов к требуемому для пользователя nobody;
  • проверяйте хостнеймы, /etc/hosts, hostname --fqdn и т.п;
• не работает отображение пользователей на ФС: проверьте чтобы домены, указанные в /etc/idmap.conf были одинаковы, а также т.к. иногда idmap почему-то игнорирует данные в конфиге, проверьте, какой именно домен он пытается использовать (пишет при запуске). Попробуйте установить домен системы командой domainname. Также некорректные имена могут закешироваться, поэтому при проверках «заработало ли» не забывайте передергивать nscd и, возможно, nfs-common на сервере (или имейте терпение в ~10 минут).

SSH

• Имя сервиса: host, сервисная запись требуется только для сервера. Естественно с ключами (см. про keytab’ы).
• Для авторизации ssh через kerberos достаточно указать в параметрах сервера (/etc/ssh/sshd_config) и клиента (~/.ssh/config) «GSSAPIAuthentication yes».
• В файле ~/.k5login можно указать какие kerberos аккаунты могут использовать данную учетную запись. По умолчанию допускаются только одноименные с именем логина.

Почта

Получение почты через IMAP на примере cyrus:

• Имена сервисов: imap и sieve. Оба необходимы только для сервера.
• Права доступа на keytab файл должны быть такие, чтобы cyrus мог прочитать этот файл (Например через ACL: «setfacl -m g:sasl:r /etc/krb5.conf» или вынести их в отдельный файл с нужным владельцем через KRB5_KTNAME)
• В /etc/imap.conf удостовериться в наличии таких строк: «sasl_pwcheck_method:  auxprop» и «loginrealms: ДОМЕН» (параметров может быть и больше, но эти обязательны), также sasl_mech_list должно или отсутствовать или включать в себя GSSAPI
• Поставить gssapi плагин для sasl/gssapi и на сервер и на клиент (пакет libsasl2-modules-gssapi-mit)

Почтовые клиенты, которые умеют авторизироваться через gssapi это как минимум thunderbird и kmail. Если у вас есть тикет, то они не должны спрашивать пароль. Для kmail необходимо выбрать этот тип авторизации явно, а для thunderbird (версий до 3.1) поставить галочку «Use secure authentication» в настройках аккаунта. С версии 3.1 появился выбор механизма авторизации, в котором соответственно следует указать Kerberos/GSSAPI.

Отправка через SMTP, exim:

• Имя сервиса smtp
• Удостовериться, что exim сможет прочитать файл ключей (опять же или дать права или вынести в отдельный файл).
• Добавить в настройки (/etc/exim4/conf.d/auth/40_auth если используется конфигурация разнесенная по файлам) следующий аутентификатор:

gssapi_sasl_server:
  driver = cyrus_sasl
  public_name = GSSAPI
  server_set_id = $auth1
  server_mech = gssapi

• Необходимо поставить gssapi плагин для sasl/gssapi и на сервер и на клиент (пакет libsasl2-modules-gssapi-mit)

Как и с получением, kmail и thunderbird умеют такую авторизацию.

HTTP, т.е. веб

Apache2:

• Для авторизации через gssapi есть модуль mod_auth_kerb, в дебиане он в пакете libapache2-mod-auth-kerb
• Имя сервиса HTTP (обращаю внимание: заглавными буквами)
• Как обычно файл с ключами должен иметь такие права, чтобы апач смог его прочитать, и тут крайне желательно вынести ключи в отдельный файл.
• Для включения авторизации в конфиге следует указать что-нибудь такое:

Require valid-user
AuthName "Protected area"
AuthType Kerberos
KrbAuthRealms ДОМЕН
Krb5Keytab путь_к_keytab_файлу

Браузеры, которые поддерживают такую авторизацию (Для HTTP она называется SPNEGO, метод авторизации — Negotiate):

• IE — использует учетку AD.
• Konqueror — по умолчанию все работает.
• Firefox — для него необходимо в about:config в параметр network.negotiate-auth.trusted-uris вписать через запятую домены, для которых подобная авторизация дозволена. Можно указать «http://,https://», и будет работать для всех. Т.к. ФФ об ошибках молчит, то для отладки проверки такой авторизации можно его запускать следующим образом: «env NSPR_LOG_MODULES=negotiateauth:5 firefox -console».
• Opera — за поддержкой SPNEGO отмечена не была.

Также существует возможность добавить авторизацию через цербера в скриптах на PHP, Ruby, и, наверняка, не только.

Прокси, squid:

• Имя сервиса как и для http — HTTP
• Файл ключей, само собой, должен быть доступен сквиду на чтение. Опять же желательно вынести ключи в отдельный файл.
• Настройка сквида (/etc/squid3/squid.conf):

auth_param negotiate program /usr/sbin/squid_kerb_auth
auth_param negotiate children 10
auth_param negotiate keep_alive on
acl auth proxy_auth REQUIRED

http_access deny !auth
http_access allow auth
http_access deny all

С клиентами аналогично http.

PAM

А именно авторизация системного логина через цербера, и, соответственно, получения мастер тикета еще при логине.

• В debian все сделано по умолчанию, достаточно поставить пакет libpam-krb5
• В документации указано, что достаточно внести следующие правки (повторяюсь — по умолчанию они вносятся автоматически при установке пакета):

  • /etc/pam.d/common-auth:
    auth  sufficient  pam_krb5.so minimum_uid=1000
    auth  required    pam_unix.so try_first_pass nullok_secure

  • /etc/pam.d/common-session:
    session  optional  pam_krb5.so minimum_uid=1000
    session  required  pam_unix.so
    

  • /etc/pam.d/common-account:
    account  required  pam_krb5.so minimum_uid=1000
    account  required  pam_unix.so
    

  • /etc/pam.d/common-password:
    password  sufficient  pam_krb5.so minimum_uid=1000
    password  required    pam_unix.so nullok obscure min=4 max=8 md5
    

С указанными настройками для обычных пользователей (с uid не менее 1000) в начале производится попытка авторизации через цербера (с получением мастер тикета), а потом через обычный unix password. Если клиентская машина к инету подключена редко, то порядок строк можно изменить, чтобы в начале проверялся доступ через локальную базу пользователей и паролей. Причем проверка авторизации через цербера будет производиться при любых проверках пользовательского пароля — и для системного логина, и для sudo, и вообще для всего что авторизируется через PAM и включает правило common-auth. Мастер-тикет будет выдаваться тогда, когда в настройках PAM включается правило common-session.

XMPP, ejabberd:

Мне пока не удалось настроить. Из коробки ejabberd не поддерживает gssapi, также не очень понятен статус поддержки клиентами.

• http://www.ejabberd.im/cyrsasl_gssapi
• http://my.opera.com/Zl0/blog/2009/06/09/jabber-gssapi-ldap

Postgresql

Постгря должна быть скомпилирована с поддержкой GSSAPI (по умолчанию в debian это так).

• имя сервиса — postgres
• файл ключей, как обычно, должен быть доступен постгре на чтение
• в pg_hba.conf необходимо добавить строки вида:
  

  hostssl all             all             0.0.0.0/0                gss krb_realm=ДОМЕН
  hostssl all             all             ::/0                     gss krb_realm=ДОМЕН
  

  (соответственно домен надо поставить свой)
• psql умеет авторизоваться таким образом, остальные — не знаю
• авторизация будет действовать только для пользователя, одноименного с тем, кто получил тикет (если через pg_ident.conf не прописан маппинг), соответственно по умолчанию будет доступ только к базе с тем же именем. Поэтому не забываем давать права на таблицы и т.п. по мере надобности.
• Подробности в документации.

Mysql

Напрямую цербера не поддерживает, однако начиная с версии 5.5 позволяет авторизировать пользователей с помощью плагинов, в частности через PAM, который в свою очередь поддерживает kerberos. Но это конечно совсем не то, чего хотелось бы.

FTP, RSH, Telnet, etc

Here be dragons

Заключение

 Во всех вышеперечисленных случаях (кроме PAM, само собой) авторизация будет работать по тикету, не спрашивая пароль.

Список программ не исчерпывающий, т.к. многие программы позволяют авторизироваться через gssapi, что включает и цербера. Еще большее число программ умеет проверять пароль клиента через цербера непосредственно или через RADIUS, правда это не всегда безопасно, т.к. требует передачи пароля по сети.

Возможно позже напишу про LDAP.

Часто возникающие ошибки и проблемы:

• Проблемы с именами хостов. Или сервис не находит в keytab’е свою запись, или клиент пытается авторизоваться предъявляя другой адрес. Диагностика зачастую невнятна, и сервисы не пишут какой именно хостнейм им нужен. Для решения см. секцию про адреса.
• Проблемы с синхронизацией часов. Расхождение времени на машинах не должно превышать 5 минут, используйте синхронизацию по NTP.
• Проблемы с отсутствием библиотек: при авторизации через sasl соответствующие модули должны стоять и на сервере, и на клиенте. Предоставляются пакетом libsasl2-modules-gssapi-mit.