Аутентификация пользователей 

Введение

Аутентификационные механизмы

GSSAPI - это спецификация Kerberos 5. И еще, STARTTLS-сертификация на стороне клиента не была должным образом протестирована.

Когда STARTTLS разрешен, PLAIN SASL-механизм (если установлен) также будет доступен. Это нормально, потому что всеравно нельзя будет передать пароль открытым текстом по шифрованному соединению.

Протокол IMAP также поддерживает аутентификацию пользователей без использования SASL (спецификация). Это можно осуществить через команду 'LOGIN' (не путать с механизмом LOGIN в SASL). Команда IMAP LOGIN (как с PLAIN) посылает Ваш пароль серверу открытым текстом. В этом случае пароль все еще проверяется через библиотеку Cyrus SASL, хотя и никакой SASL-механизм при этом не используется.

POP-сервер может осуществлять APOP-аутентификацию. В этом случае Cyrus SASL должна быть собрана с ключем " --with-checkapop" ,  а пароли должны храниться в auxprop-базе (например: sasldb, auxprop, plugin).

Рекомендации

• Если Вы делаете почтовый сервер на одной машине, мы рекомендуем настроить систему на использование CRAM-MD5 или DIGEST-MD5. У нас пока нет утилит, с помощью которых пользователи могли бы менять свои пароли, но скоро мы, или кто-нибудь еще обязятельно напишет их.
• Если у Вас более одного почтового сервера, мы рекомендуем настроить систему на использование GSSAPI или Kerberos5.
• Если Вам нужен какой-либо другой аутентификационный механизм, который требует пароля в открытом виде(plain-text), вы должны использовать  saslauthd.

  Saslauthd - это один из компонентов библиотеки Cyrus SASL. Пока он распространен не так как PAM, но его проще настраивать. 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 имеет множество опций, кторое могут быть настроены через использующее ее(библиотеку) приложение. Для настройки через imapd.conf, к нужной опции просто добавляется префикс  sasl_ (например: pwcheck_method будет выглядеть как  sasl_pwcheck_method).

/etc/sasldb2

Простейший метод аутентификации заключается в использовании аутентификационной базы libsasl, аккаунты в которой создаются с помощью утилиты "saslpasswd2". В настройках должно стоять "sasl_pwcheck_method: auxprop" и в SASL у sasldb должен быть установлен auxprop-модуль (это ставится по умолчанию). Удостоверьтесь, что Cyrus может прочитать из "/etc/sasldb2": chown cyrus /etc/sasldb2*

Shadow Passwords(Теневые пароли)

Реализация аутентификации пользователей из "/etc/shadow" более сложна , т. к. cyrus-пользователь не может чиатть файл теневых паролей. Также, это не полволит использовать механизмы shared secret. Чтобы осуществить это, необходимо настроить libsasl с поддержкой  saslauthd, и прописать в настройках "sasl_pwcheck_method: saslauthd". Библиотека SASL будет вызывать внешнююутилиту, запущенную от имени root'а, чтобы аутентифицировать пользователей.

Kerberos

Настройка Kerberos v4

Cyrus IMAP сможет поддерживаеть Kerberos v4 если библиотеку SASL собрать(откомпилировать) с поддержкой KERBEROS_V4.

Вам потребуется создать для сервера идентификатор Kerberos v4  и добавить ключ сервера в файл "srvtab". Cyrus-пользователь должен иметь право на чтение на этот файл. Сервер убдет иметь идентификатор Kerberos вида "imap.HOST@REALM", где "HOST " - первый компонент имени хоста сервера, а "REALM " - область Kerberos.

1. Вот пример процедуры создания srvtabфайла для хоста с именем "foobar": 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

2. Если Вы планируете внедрять Kerberized POP, создайте идентификатор Kerberos "pop.HOST@REALM" и добавте ключ в файл "srvtab". Аналогично, если использовать LMTP через TCP, создайте Kerberos-идентификатор "lmtp.HOST@REALM" и добавте ключ в файл "srvtab ".

3. Сделайте cyrus-пользователя владельцем файла "srvtab ": chown cyrus /var/imap/srvtab

4. Добавте поцию srvtab в /etc/imapd.conf: srvtab: /var/imap/srvtab
5. Протестируйте все это командой  imtest -m KERBEROS_V4. i mtest попытается авторизовать текущего Unix-пользователя независимо от текущей авторизации. Этого не бутет при использовании опции " -u" .

Разрешение проблем Kerberos_V4

Запустите программу "krbck"(находится в директории  imap) как cyrus-пользователь на IMAP-сервере. Эта программа продиагностирует неготорые конфигурационные ошибки Kerberos v4.

Настройка Kerberos v5

Cyrus IMAP сможет поддерживать Kerberos v5 если библиотека SASL собрана с поддержкой GSSAPI.

Вам нужно будет создать идентификатор Kerberos v5 для сервера. Ключи Kerberos v5 хранятся в "/etc/krb5.keytab".

1. Добавте ключ "imap/hostname" используя "kadmin".
2. Дайте cyrus-пользователю право на чтение "/etc/krb5.keytab ": chown cyrus /etc/krb5.keytab
3. Проверте настройки с помощью  imtest -m GSSAPI. i mtest  попытается авторизовать текущего Unix-пользователя независимо от текущей авторизации. Этого не бутет при использовании опции " -u" .