Мы — долго запрягаем, быстро ездим, и сильно тормозим.

RFC
Программирование
FreeBSD
man
EXIM
  4.62
  4.70
  часть 1
  часть 2
  часть 3
  часть 4
  часть 5
  часть 6
  часть 7
  часть 8
  часть 9
  часть 10
  часть 11
  часть 12
  часть 13
  часть 14
  часть 15
  часть 16
  часть 17
  часть 18
  часть 19
  часть 20
  часть 21
  часть 22
  часть 23
  часть 24
  часть 25
  часть 26
  часть 27
  часть 28
  часть 29
  часть 30
  часть 31
  часть 32
  часть 33
  часть 34
  часть 35
  часть 36
  часть 37
  часть 38
  часть 39
  часть 40
  часть 41
  часть 42
  часть 43
  часть 44
  часть 45
  часть 46
  часть 47
  часть 48
  часть 49
  часть 50
  часть 51
  часть 52
  часть 53
  часть 54
  часть 55
  filter facility


www.lissyara.su —> документация —> EXIM —> 4.70 —> часть 34

34. Аутентификатор “plaintext”


    Аутентификатор plaintext может быть сконфигурирован для поддержки аутентификационных механизмов PLAIN и LOGIN, оба которые передают аутентификационные данные в виде открытого (незашифрованного) текста (хотя и кодированного base64). Использование открытого текста - риск для безопасности; настоятельно рекомендуем на использовании SMTP-шифрования (смотрите раздел 39), если вы используете механизмы PLAIN и LOGIN. Если вы используете открытый текст, то вы не должны использовать для SMTP-подключений те же самые пароли, что и для учётных записей пользователей (имеются ввиду системные учётки - чтоб не могли перехватить и залогинится - прим. lissyara).

34.1 Опции plaintext

   При конфигурировании как сервера, plaintext имеет следующие опции:
Имя
Использование
Тип
Дефолтовое значение
server_condition authenticators string† незадана

   Фактически, это глобальная аутентификационная опция, но, она может быть установлена для конфигурирования драйвера plaintext как сервера. Её использование описано ниже.
Имя
Использование
Тип
Дефолтовое значение
server_prompts plaintext string† незадана

   Содержимое этой опции, после раскрытия, должно быть списком строк подсказок, разделённых двоеточиями. Если раскрытие неудачно, даётся временное отклонение аутентификации.

34.2 Использование plaintext в сервере

   При работе в качестве сервера, plaintext выполняет тест аутентификации путём раскрытия строки. Данные посылаются клиентом с командой AUTH, или в ответе на последующие подсказки, закодированные по base64, таким образом, после декодирования они могут содержать любые символы. Если с командой предоставлюятся какие-то данные, они рассматриваются как список строк, разделённых NUL (бинарным нулём), первые три из которых помещаются в переменные раскрытия $auth1, $auth2 и $auth3 (ни LOGIN ни PLAIN не используют более чем три строки).
   Для совместимости с предыдущими релизами exim`a, значения, также, помещаются в переменные раскрытия
$1, $2 и $3. Однако, использование этих перемнных с этой целью, сейчас, осуждается, поскольку оно может привети к беспорядку в раскрытиях строк, котоые также их используют для других целей.
   Если в
server_prompts находится больше строк, чем переданных с командой AUTH, остающиеся подсказки используются для получения дополнительных данных. Каждый ответ клиента может быть списком строк, разделённых NUL-символами.
   Как только получено достаточное число строк данных, раскрывается
server_condition. Если раскрытие принудительно неудачно, аутентификация непройдена. Любые другие ошибки аутентификации вызывают возврат временного кода ошибки. Если результат успешного раскрытия - пустая строка,  0, no, или false, - аутентификация неудачна. Если результат раскрытия - 1, yes, или true, - аутентификация успешна, и раскрывается общая опция server_set_id, и сохраняется в $authenticated_id. Для любого другого результата, возвращается временный код ошибки, с раскрытой строкой в качестве текста ошибки.
   Предупреждение: Если вы используете, для нахождения пароля пользователя, поиск в раскрытии - убедитесь, что сделали неудачу аутентификации, если пользователь неизвестен. В конце следующего раздела есть хорошие и плохие примеры.

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

   Аутентификационный механизм PLAIN (RFC2595), определяет, что три строки посылаются как один элемент данных (т.е. одна, комбинированная строка, содержащая два NUL-разделителя). Данные посылаются или как часть команды AUTH, или впоследствии, в ответе на пустую подсказку сервера.
   Вторая и третья строки - имя пользователя и соответствующий пароль. Используя одно фиксированное имя пользователя и пароль, как пример, это могло бы быть сконфигурировано следующим образом:
fixed_plain:
  driver = plaintext
  public_name = PLAIN
  server_prompts = :
  server_condition = \
    ${if and {{eq{$auth2}{username}}{eq{$auth3}{mysecret}}}}
  server_set_id = $auth2

   Отметьте, что по-умолчанию результирующая строка из if (true или пустая строка) в точности то что мы тут хотим, таким образом, она должна быть не задана. Очевидно, если пароль содержит символы зависимые от раскрытия, например - доллар, обратный слэш, или закрывающую скобку, они будут экранированы.

   Установка
server_prompts задаёт единственную, пустую подсказку (пустые элементы в конце списка строки - игнорируются). Если все данные прибывают как часть команды AUTH, как обычно и бывает, - подсказка не используется. Об этом аутентификаторе извещается в ответе на EHLO
250-AUTH PLAIN

и клиентский хост может аутентифицироваться путём посыла команды
AUTH PLAIN AHVzZXJuYW1lAG15c2VjcmV0

   Поскольку тут содержится три строки (больше чем число подсказок), от клиента не требуется больше данных. Альтернативно, клиент может лишь послать
AUTH PLAIN

для начала аутентификации, в этом случае сервер ответчает пустой подсказкой. Клиент должен ответить комбинированной строкой данных.
   Строка данных - закодирована base64, как требуется по RFC. Этот пример, после расшифровки, -
<NUL>username<NUL>mysecret, где <NUL> - нулевой байт. Она разделяется на три строки, первая из которых - пустая. Опция server_condition, в проверках аутентификаторов, что вторые две - username и mysecret - соответствуют.
   Наличие лишь одного фиксированного имени пользователя и пароля, как в этом примере, - не очень реалистично, хотя, для маленькой организации, с горсткой аутентифицируемых клиентов, - это могло бы иметь смысл.
   Более сложный случай этого аутентификатора может использовать имя пользователя в
$auth2, для поиска пароля в файле, или БД, и, возможно, делать шифрованное сравнение (смотрите crypteq, в разделе 11). Вот - пример этого подхода, где пароли ищутся в DBM-файле. Предупреждение: Это - неправильный пример:
server_condition = \
  ${if eq{$auth3}{${lookup{$auth2}dbm{/etc/authpwd}}}}

   Раскрытие использует имя пользователя ($auth2), как ключ для поиска пароля, который, затем, сравнивается с переданным паролем ($auth3). Почему этот пример неправилен? Он прекрасно работает для существующих пользователей, но рассмотрим, что происходит если даётся имя несуществующего пользователя. Поиск неудачен, но поскольку для поиска не даны строки удачи/неудачи, он приводит к пустой строке. Таким образом, чтобы обойти аутентификацию, все клиенты должны предоставлять несуществующее имя пользователя, и пустой пароль. Корректный способ написать эту проверку:
server_condition = ${lookup{$auth2}dbm{/etc/authpwd}\
  {${if eq{$value}{$auth3}}} {false}}

   В этом случае, если поиск успешен, результат проверяется; если поиск неудачен, возвращается false и аутентификация неуспешна. Если вместо eq используется crypteq, первый пример, фактически, безопасен, поскольку crypteq всегда неудачна, если второй аргумент пуст. Однако, второй способ написания проверки, делает логику более понятной.

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

   Аутентификационный механизм LOGIN не задокументирован в каком-либо RFC, но - он используется множестовм программ. С командой AUTH никаких данных не посылается.Вместо этого, имя пользователя и пароль даются раздельно, в ответах на подсказки. Аутентификатор plaintext может быть сконфигурирован для поддержки этого, как в этом примере:
fixed_login:
  driver = plaintext
  public_name = LOGIN
  server_prompts = User Name : Password
  server_condition = \
    ${if and {{eq{$auth1}{username}}{eq{$auth2}{mysecret}}}}
  server_set_id = $auth1

   Поскольку работает plaintext, этот аутентификатор принимает данные предоставленные с командой AUTH (в нарушение спецификации LOGIN), но, если клиент не предоставляет их (как в случае LOGIN клиентов), строка подсказки используется для получения двух элементов данных.
   Некоторые клиенты очень следят за точным текстом подсказок. Например, Outlook Express, как сообщают, распознаёт только
Username: и Password:. Вот - пример аутентификатора LOGIN, использующего эти строки. Они использует условие раскрытия ldapauth, для проверки имени пользователя и пароля, путём связи с LDAP-сервером:
login:
  driver = plaintext
  public_name = LOGIN
  server_prompts = Username:: : Password::
  server_condition = ${if and{{
    !eq{}{$auth1} }{ \
    ldapauth{user="cn=${quote_ldap_dn:$auth1},ou=people,o=example.org" \
             pass=${quote:$auth2} \
             ldap://ldap.example.org/} }} }
  server_set_id = uid=$auth1,ou=people,o=example.org

   Мы делаем проверку что имя пользователя не пустое до его использования, поскольку LDAP не разрешает пустые компоненты DN. Также, мы должны использовать оператор quote_ldap_dn для корректного квотирования DN для аутентификации. Однако, базовый оператор quote, а не любой из операторов квотирования LDAP, явялется правильным при использовании для пароля, поскольку квотирование необходимо лишь для того, чтобы пароль соответствовал синтаксису exim'a. На уровне LDAP, пароль - неинтерпретируемая строка.

34.5 Поддержка для иных видов аутентификации

   Множество особенностей раскрытия строк предоставлены как интерфейс к иным способам аутентификации пользователей. Они включают проверку традиционно зашифрованных паролей /etc/passwd (или эквивалент), PAM, Radius, ldapauth, pwcheck, and saslauthd. Для дополнительных деталей смотрите раздел 11.7.

34.6 Использование plaintext как клиента

   Аутентификатор plaintext имеет две клиентские опции:
Имя
Использование
Тип
Дефолтовое значение
client_ignore_invalid_base64 plaintext boolean ложь

   Если клиент получает подсказку сервера не являющуюся допустимой base64 строкой, оставляется аутентификация по-умолчанию. Однако, если эта опция установлена в истину, ошибка в вызове игнорируется, и клиент посылает обычный ответ.

Имя
Использование
Тип
Дефолтовое значение
client_send plaintext string† незадана

   Строка - список разделённых двоеточиями строк аутентификационных данных. Каждая строка независимо раскывается до отправки на сервер. Первая строка - посылается с командой AUTH; дополнительные строки посылаются на подсказки сервера. До раскрытия каждой строки, значение новой подсказки помещается в следующую переменную $auth<n>, начинающихся с $auth1, для первой подсказки. Этим способом сохраняется вплоть до трёх подсказок. Таким образом, подсказка полученная в ответ на отправленную первую строку (с командой AUTH), может быть использована в раскрытии второй строки, и так далее. Если получена недопустимая base64 строка при установленной опции client_ignore_invalid_base64, в переменную $auth<n> помещается пустая строка.
   Отметьте: Вы не можете использовать раскрытия для создания нескольких строк, поскольку у разбиения приоритет выше и оно происходит раньше.
   Поскольку аутентификационный механизм PLAIN требует байт NUL (бинарный ноль) в данных, к каждой строке до её отправки применяется дальнейшая обработка. Если в строке есть символы крышки (^), они конвертируются в NUL. Если в строке требуется крышка как данные, символ должен быть удвоен в строке.
   Это - пример клиентской конфигурации, которая воплощает аутентификационный механизм PLAIN с фиксированным именем пользователя и паролем:
fixed_plain:
  driver = plaintext
  public_name = PLAIN
  client_send = ^username^mysecret

   Нехватка двоеточий означает, что весь текст посылается с командой AUTH, с символами крышки преобразованными в NUL. Подобный пример, использующий механизм LOGIN:
fixed_login:
  driver = plaintext
  public_name = LOGIN
  client_send = : username : mysecret

   Начальное двоеточие означает, что первая строка пустая, таким образом, с командой AUTH никаких данных не посылается. Оставшиеся строки посылаются в ответ на подсказки.


=============
translated by lissyara
verifying by Gerk



Ссылка на обсуждение: http://forum.lissyara.su/viewforum.php?f=20.



Хостинг HOST-FOOD

2014-07-27, lissyara
gmirror

Удалённое создание софтверного зеркала средствами gmirror, на диске разбитом с использованием gpart. Использование меток дисков для монтирования разделов.
2013-08-20, zentarim
Scan+Print server FreeBSD 9

Настройка сервера печати и сервера сканирования под управлением операционной системы FreebSD 9 для МФУ Canon PIXMA MP540
2011-11-20, BlackCat
Разъём на WiFi-карту

Делаем съёмной несъёмную антену на WiFi-карте путём установки ВЧ-разъёма
2011-09-14, manefesto
Настройка git+gitosis

Настройка системы контроля версия исходного кода в связке git+gitosis+ssh
2011-08-14, zentarim
Wi-FI роутер + DHCP + DNS

Настройка Wi-Fi роутера на Freebsd 8 + DNS сервер + DHCP сервер: чтобы Wi-Fi клиенты были в одной подсети с проводными, проводные и беспроводные клиенты получали адреса автоматически по DHCP, кэширующ
2011-06-15, -ZG-
Охранная система на FreeBSD+LPT

В этой статье описана попытка реализации простой охранной системы на базе FreeBSD с подключением к ней охранных устройтсв на LPT порт и видеорегистрацией.
2011-03-13, terminus
ng_nat

Описание работы ng_nat, практическое использование, достоинства и недостатки в сравнении с ipfw nat
2011-02-20, Капитан
Nagios+Digitemp

Статья описывает создание системы оповещения о превышении температуры в специальных помещениях на основе Nagios с использованием программы Digitemp.
2011-02-17, Le1
Zyxel Configuration

Скрипт для массового изменения конфига свичей Zyxel. Берет из файла iplist список ip-шек, заходит последовательно на каждый и выполняет комманды из файла commands, записывая происходящее в лог файл.
2011-02-16, fox
hast carp zfs ucarp cluster

HAST (Highly Available Storage), CARP, UCARP, ZFS, Cluster настройка и одаптация плюс личные размышления…
2011-02-04, BlackCat
Восстановление ZFS

История о том, как был восстановлен развалившийся RAIDZ ZFS-пул (перешедший в FAULTED) с помощью скотча и подручных средств. Или о том, какие приключения ожидают тех, кто не делает резервных копий.
2011-02-03, Капитан
1-Wire

Статья описывает самостоятельное изготовление контроллера DS9097 для съёма показаний с датчиков температуры DS1820 с помощью программы Digitemp.
2011-01-28, Капитан
Температура в серверной

Статья описывает построение системы наблюдения за температурой в помещении серверной с использованием программы Digitemp и выводом графиков в MRTG
2011-01-21, m4rkell
Syslog server

Как то буквально на днях, у нас завалилось, что то в еве) или не в еве не суть. Суть в том, что когда захотели снять логи с хостов esx обнаружили, что хранят эти негодяи логии только за последнии сутк
2011-01-07, lissyara
Canon/gphotofs

Монтирование цифровых фотоаппаратов Canon (PTP) как файловой системы, автоматизация этого процесса через события devd и внешние скрипты.
2010-12-13, Al
IPSec

Описание принципов работы IPSEC и способов аутентификации.
2010-12-07, manefesto
FreeBSD on flash

Было принято решении переехать на USB Flash и установить минимальный джентельменский набор для работы своего роутера. Делаем =)
2010-12-05, Fomalhaut
root ZFS, GPT

Инструкция по установке FreeBSD с использованием в качестве таблицы разделов GPT и в качестве основной файловой системы - ZFS
2010-09-05, Cancer
Настройка аудиоплеера на ximp3

Цели: Простенький аудиоплеер, для того что бы тетя продавец в магазине утром пришла нажала на кнопку Power и заиграла в зале музыка, так же был доступ по сети, общая шара куда можно заливать музыку, к
2010-08-31, Cancer
Установка и настройка OpenVPN

На днях появилась задача - объединить головной офис и 3 филиала в одну сеть через интернет посредством OpenVPN, чтобы люди могли подключаться через RDP к базам 1С на серверах.
2010-08-25, manefesto
freebsd lvm

Использование linux_lvm для работы с LVM разделами из-под FreeBSD. Проблемы которые возники при монтирование lvm раздела
подписка

    вверх      
Статистика сайта
Сейчас на сайте находится: 15 чел.
За последние 30 мин было: 65 человек
За сегодня было
11653 показов,
514 уникальных IP
 

  Этот информационный блок появился по той простой причине, что многие считают нормальным, брать чужую информацию не уведомляя автора (что не так страшно), и не оставляя линк на оригинал и автора — что более существенно. Я не против распространения информации — только за. Только условие простое — извольте подписывать автора, и оставлять линк на оригинальную страницу в виде прямой, активной, нескриптовой, незакрытой от индексирования, и не запрещенной для следования роботов ссылки.
  Если соизволите поставить автора в известность — то вообще почёт вам и уважение.

© lissyara 2006-10-24 08:47 MSK

Время генерации страницы 0.0375 секунд
Из них PHP: 31%; SQL: 69%; Число SQL-запросов: 56 шт.
У Вас отключено GZIP-сжатие в браузере. Размер страницы 130774