GSSAPI - это спецификация Kerberos 5. И еще, STARTTLS-сертификация на стороне клиента не была должным образом протестирована.
Когда STARTTLS разрешен, PLAIN SASL-механизм (если установлен) также будет доступен. Это нормально, потому что всеравно нельзя будет передать пароль открытым текстом по шифрованному соединению.
Saslauthd - это один из компонентов библиотеки Cyrus SASL. Пока он распространен не так как PAM, но его проще настраивать. SMTP/IMAP-сервер просто посылает идентификатор пользователя и соответствующий пароль по пайпу (Unix domain pipe). Затем, saslauthd берет этот идентификатор с паролем и пытается его аутентифицировать -- с помощью аутентификации, которую вы используете - а потом просто возвращает "yes" или "no", т.е. правильный пароль или нет.
Есть возможность настроить saslauthd на работу через PAM-механизм, /etc/passwd, или на что-то другое.
PAM поддерживает встраиваемые аутентификационные модули для обеспечения общего API приложениям, которым необходимо аутентифицировать пользователей. Можно использовать PAM как дополнительный слой под SASL-слоем. Читайте http://www.kernel.org/pub/linux/libs/pam/FAQ для более детальной информации о PAM. При использовании модуля PAM, другие приложения в Вашей системе тоже могут им пользоваться -- например, login, xlock и т. д.
Имейте в виду, что при использовании PLAIN или LOGIN появляется необходимость в шифровании потока (канала), т. к. id пользователя и пароль может быть легко перехвачен сниффером.
Cyrus SASL имеет множество опций, кторое могут быть настроены через использующее ее (библиотеку) приложение. Для настройки через smtp/imapd.conf, к нужной опции просто добавляется префикс sasl_ (например: pwcheck_method будет выглядеть как sasl_pwcheck_method).
Простейший метод аутентификации заключается в использовании аутентификационной базы libsasl, аккаунты в которой создаются с помощью утилиты "saslpasswd2". В настройках должно стоять "sasl_pwcheck_method: auxprop" и в SASL у sasldb должен быть установлен auxprop-модуль (это ставится по умолчанию). Удостоверьтесь, что Cyrus может прочитать из "/etc/sasldb2":
chown cyrus /etc/sasldb2*
Реализация аутентификации пользователей из "/etc/shadow" более сложна , т. к. cyrus-пользователь не может чиатть файл теневых паролей. Также, это не полволит использовать механизмы shared secret. Чтобы осуществить это, необходимо настроить libsasl с поддержкой saslauthd, и прописать в настройках "sasl_pwcheck_method: saslauthd". Библиотека SASL будет вызывать внешнююутилиту, запущенную от имени root'а, чтобы аутентифицировать пользователей.
Cyrus IMAP сможет поддерживаеть Kerberos v4 если библиотеку SASL собрать(откомпилировать) с поддержкой KERBEROS_V4.
Вам потребуется создать для сервера идентификатор Kerberos v4 и добавить ключ сервера в файл "srvtab". Cyrus-пользователь должен иметь право на чтение на этот файл. Сервер убдет иметь идентификатор Kerberos вида "imap.HOST@REALM", где "HOST " - первый компонент имени хоста сервера, а "REALM " - область Kerberos.
ksrvutil -f /var/imap/srvtab add
Ниже идет информация для запроса "ksrvutil". Необходимо вводить значения или нажимать RETURN(Enter) . В этом примере имя хоста - "foobar", а имя области - "ANDREW.CMU.EDU".
Name: imap Instance: foobar Realm: ANDREW.CMU.EDU Version number: New principal: imap.foobar@ANDREW.CMU.EDU; version 0 Is this correct? (y,n) [y] Password: Verifying, please re-enter Password: Key successfully added. Would you like to add another key? (y,n) [y] n
chown cyrus /var/imap/srvtab
srvtab: /var/imap/srvtab
Запустите программу "krbck"(находится в директории imap) как cyrus-пользователь на IMAP-сервере. Эта программа продиагностирует неготорые конфигурачионные ошибки Kerberos v4.
Cyrus IMAP сможет поддерживать Kerberos v5 если библиотека SASL собрана с поддержкой GSSAPI.
Вам нужно будет создать идентификатор Kerberos v5 для сервера. Ключи Kerberos v5 хранятся в "/etc/krb5.keytab".
chown cyrus /etc/krb5.keytab