Аутентификация клиентского приложения

При подключении к серверу баз данных клиентское приложение указывает, под каким именем пользователя базы данных QHB оно хочет подключиться, почти так же, как при обычном входе пользователя в компьютер с Unix. В среде SQL по имени пользователя базы данных определяется, какие у него есть права доступа к объектам базы данных; более подробную информацию см. в главе Роли в базе данных. Таким образом, крайне важно указать, к каким базам данных пользователь может подключаться.

Примечание
Как объясняется в главе Роли в базе данных, QHB на самом деле управляет правами посредством так называемых «ролей». Соответственно, в этой главе под термином пользователь базы данных подразумевается «роль с правом LOGIN».

Аутентификация — это процесс, посредством которого сервер баз данных идентифицирует клиента, а в более широком смысле определяет, разрешено ли клиентскому приложению (или пользователю, запустившему это приложение) подключиться с указанным именем пользователя.

QHB предлагает несколько различных методов аутентификации клиента. Метод аутентификации конкретного клиентского подключения можно выбрать на основе адреса хоста клиента, имени базы данных и имени пользователя.

Имена пользователей базы данных QHB логически отделены от имен пользователей операционной системы, в которой запущен сервер. Если у всех пользователей определенного сервера есть учетные записи в операционной системе сервера, имеет смысл назначить им точно такие же имена пользователей базы данных. Однако у сервера, принимающего удаленные подключения, может быть много пользователей базы данных, у которых нет локальной учетной записи в операционной системе, и в таких случаях в соответствии между именами пользователей базы данных и именами пользователей ОС нет необходимости.

Файл qhb_hba.conf

Аутентификация клиентов управляется файлом конфигурации, который традиционно называется qhb_hba.conf и хранится в каталоге данных кластера баз данных. (HBA расшифровывается как host-based authentication — аутентификация по узлу.) Стандартный файл qhb_hba.conf устанавливается при инициализации каталога данных утилитой qhb_bootstrap (или initdb). Однако файл конфигурации аутентификации можно разместить в любом другом месте; см. параметр конфигурации hba_file.

Общий формат файла qhb_hba.conf — набор записей, по одной на строку. Пустые строки игнорируются, как и любой текст после знака отбивки комментария (#). Запись можно продолжить на следующей строке, завершив текущую строку обратным слэшем. (Обратный слэш является спецсимволом только в конце строки.) Запись состоит из ряда полей, разделенных пробелами и/или табуляциями. Поля могут содержать пробелы, если значение поля заключено в кавычки. Если в кавычки берется одно из ключевых слов в поле базы данных, пользователя или адреса (например all или replication), это слово теряет свое особое значение и просто обозначает базу данных, пользователя или хост с этим именем. Обратный слэш означает перенос строки даже в тексте в кавычках или комментариях.

В каждой записи указывается тип соединения, диапазон IP-адресов клиента (если это важно для типа соединения), имя базы данных, имя пользователя и метод аутентификации, который будет использован для подключения в соответствии с этими параметрами. Первая же запись с соответствующим типом соединения, адресом клиента, требуемой базой данных и именем пользователя используется для аутентификации. Процедуры «передачи управления вниз» или «резервирования» отсутствуют: если выбрана запись, и аутентификация провалилась, последующие записи не рассматриваются. Если ни одна запись не подходит, в доступе будет отказано.

Запись может иметь несколько форматов:

local         база_данных  пользователь  метод-аутентификации [параметры-аутентификации]
host          база_данных  пользователь  адрес     метод-аутентификации  [параметры-аутентификации]
hostssl       база_данных  пользователь  адрес     метод-аутентификации  [параметры-аутентификации]
hostnossl     база_данных  пользователь  адрес     метод-аутентификации  [параметры-аутентификации]
hostgssenc    база_данных  пользователь  адрес     метод-аутентификации  [параметры-аутентификации]
hostnogssenc  база_данных  пользователь  адрес     метод-аутентификации  [параметры-аутентификации]
host          база_данных  пользователь  IP-адрес  IP-маска      метод-аутентификации  [параметры-аутентификации]
hostssl       база_данных  пользователь  IP-адрес  IP-маска      метод-аутентификации  [параметры-аутентификации]
hostnossl     база_данных  пользователь  IP-адрес  IP-маска      метод-аутентификации  [параметры-аутентификации]
hostgssenc    база_данных  пользователь  IP-адрес  IP-маска      метод-аутентификации  [параметры-аутентификации]
hostnogssenc  база_данных  пользователь  IP-адрес  IP-маска      метод-аутентификации  [параметры-аутентификации]

Эти поля имеют следующие значения:

local
Эта запись соответствует попыткам подключения через сокеты домена Unix. Без записи этого типа подключения через сокеты домена Unix не допускаются.

host
Эта запись соответствует попыткам подключения по TCP/IP. Записи host соответствуют попыткам подключения с SSL или без SSL, а также попыткам подключения с криптографической защитой GSSAPI или без GSSAPI.

Примечание
Удаленные подключения по TCP/IP будут невозможны, если сервер запущен без соответствующего значения для параметра конфигурации listen_addresses, поскольку по умолчанию система принимает подключения по TCP/IP только для локального loopback-адреса localhost.

hostssl
Эта запись соответствует попыткам подключения по TCP/IP, но только когда это подключение устанавливается с шифрованием SSL.

Чтобы воспользоваться этим параметром, сервер должен быть собран с поддержкой SSL. Более того, SSL должен быть включен параметром конфигурации ssl (более подробную информацию см. в разделе Защита TCP/IP-соединений посредством SSL). В противном случае запись hostssl игнорируется, не считая вывода предупреждения о том, что ей не будут соответствовать никакие подключения.

hostnossl
У этого типа записей поведение противоположно hostssl; ему соответствуют только попытки подключения по TCP/IP без шифрования SSL.

hostgssenc
Эта запись соответствует попыткам подключения по TCP/IP, но только когда это подключение устанавливается с шифрованием GSSAPI.

Чтобы воспользоваться этим параметром, сервер должен быть собран с поддержкой GSSAPI. В противном случае запись hostgssenc игнорируется, не считая вывода предупреждения о том, что ей не будут соответствовать никакие подключения.

hostnogssenc
У этого типа записей поведение противоположно hostgssenc; ему соответствуют только попытки подключения по TCP/IP без шифрования GSSAPI.

база_данных
Определяет, какому имени (или именам) базы данных соответствует эта запись. Значение all указывает, что она соответствует всем базам данных. Значение sameuser указывает, что эта запись соответствует, если имя запрашиваемой базы данных совпадает с именем запрашиваемого пользователя. Значение samerole указывает, что запрашиваемый пользователь должен быть членом роли с тем же именем, что и у запрашиваемой базы данных. (samegroup — это устаревший, но все еще принимаемый вариант значения samerole.) Суперпользователи считаются членами роли в контексте samerole, только если они явно входят в такую роль, непосредственно или опосредованно; просто быть суперпользователем для этого недостаточно. Значение replication указывает, что эта запись соответствует, если запрашивается подключение физической репликации, однако при этом не соответствует подключениям логической репликации. Обратите внимание, что для подключения физической репликации не указывается никакая конкретная база данных, тогда как для подключений логической репликации она должна указываться. Любое другое значение воспринимается как имя конкретной базы данных QHB. Можно задать несколько имен баз данных, разделив их запятыми. Кроме того, можно задать отдельный файл с именами баз данных, написав имя этого файла после знака @.

пользователь
Определяет, какому имени (или именам) пользователя базы данных соответствует эта запись. Значение all указывает, что она соответствует всем пользователям. Любое другое значение воспринимается либо как имя конкретного пользователя базы данных, либо как имя группы, если написать его после знака +. (Напомним, что в QHB нет никакой разницы между пользователями и группами; знак + фактически означает «соответствует любым ролям, которые непосредственно или опосредованно являются членами этой роли», тогда как имя без знака + соответствует только этой конкретной роли.) По этой причине суперпользователь рассматривается как член роли, только если он явно является членом этой роли, непосредственно или опосредованно; просто быть суперпользователем для этого недостаточно. Можно задать несколько имен пользователей, разделив их запятыми. Кроме того, можно задать отдельный файл с именами пользователей, написав имя этого файла после знака @.

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

Диапазон IP-адресов указывается посредством стандартного цифрового представления для начального адреса диапазона, дополненного слэшем (/) и длиной маски CIDR. Длина маски определяет количество старших битов клиентского IP-адреса, которые должны соответствовать. Биты, находящиеся правее, в заданном IP-адресе должны быть нулевыми. Между IP-адресом, знаком / и длиной маски CIDR не должно быть пробелов.

Типичные примеры диапазона адресов IPv4, заданных таким образом: 172.20.143.89/32 для одного хоста, 172.20.143.0/24 для небольшой и 10.6.0.0/16 для более крупной сети. Диапазон адресов IPv6 может выглядеть как ::1/128 для одного хоста (это шлейфовый адрес IPv6) или как fe80::7a31:c1ff:0000:0000/96 для небольшой сети. 0.0.0.0/0 представляет все адреса IPv4, а ::0/0 — все адреса IPv6. Чтобы указать один хост, используйте длину маски 32 для IPv4 или 128 для IPv6. Не опускайте замыкающие нули в сетевом адресе.

Запись, сделанная в формате IPv4, будет соответствовать только подключениям по IPv4, а запись в формате IPv6 — только подключениям по IPv6, даже если представленный адрес находится в диапазоне IPv4-в-IPv6. Обратите внимание, что записи в формате IPv6 не будут приниматься, если системная библиотека C не поддерживает адреса IPv6.

Также можно написать значение all для соответствия записи любому адресу IP, samehost для соответствия любым IP-адресам данного сервера или samenet для соответствия любому адресу любой подсети, к которой сервер подключен напрямую.

Если задано имя хоста (все, что не является диапазоном адресов IP или специальным ключевым словом, воспринимается как имя хоста), это имя сравнивается с результатом обратного преобразования имени IP-адреса клиента (например, обратного DNS-поиска, если используется DNS). При сравнении имен хостов регистр не учитывается. Если имена совпали, выполняется прямое преобразование имени хоста (например, прямой DNS-поиск) для проверки, совпадает ли какой-либо из разрешенных адресов с IP-адресом клиента. Если двусторонняя проверка пройдена, запись считается соответствующей хосту. (Имя хоста в файле qhb_hba.conf должно быть тем, что возвращается при преобразовании IP-адреса клиента в имя, иначе строка не будет соответствовать узлу. Некоторые базы имен хостов позволяют связать один IP-адрес с несколькими именами хостов, но операционная система при запросе на разрешение IP-адреса вернет только одно имя.)

Указание имени хоста, начинающееся с точки (.), соответствует суффиксу актуального имени хоста. Так, .example.com будет соответствовать foo.example.com (а не только example.com).

Когда в qhb_hba.conf указываются имена хостов, следует добиться того, чтобы разрешение имен выполнялось достаточно быстро. Для этого может быть полезно установить локальный кэш разрешения имен, например nscd. Также можно включить параметр конфигурации log_hostname, чтобы видеть в журнале имя хоста клиента вместо IP-адреса.

Эти поля не применимы к записям local.

Примечание
Иногда пользователи задаются вопросом, почему имена хостов обрабатываются таким сложным, на первый взгляд, способом, с разрешениями двух имен, включая обратный поиск IP-адреса клиента. Это усложняет использование этой функциональности в случае, если обратная DNS-запись клиента не установлена или выдает какое-нибудь нежелательное имя хоста. Это сделано, в первую очередь, из соображений эффективности: при таком подходе попытка подключения требует максимум два поиска разрешения, один обратный и один прямой. Если есть проблема разрешения с каким-то адресом, она становится проблемой только этого клиента. Гипотетическая альтернативная реализация, при которой выполнялись бы только прямые поиски, могла бы разрешать все имена хостов, упомянутые в qhb_hba.conf во время каждой попытки подключения. Но если перечислено много имен, этот процесс был бы довольно медленным. И в случае наличия проблемы разрешения у одного имени хоста, это становится общей проблемой.

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

Обратите внимание, что это поведение согласуется с другими популярными реализациями управления доступом на основе имен хостов, такими как Apache HTTP Server и TCP Wrappers.

IP-адрес
IP-маска
Эти два поля можно использовать как альтернативу записи IP-адрес/длина-маски. Вместо того чтобы указывать длину маски, в отдельном столбце указывается сама маска. Например, 255.0.0.0 представляет собой маску CIDR для IPv4 длиной 8 бит, а 255.255.255.255 представляет маску CIDR длиной 32 бита.

Эти поля не применимы к записям local.

метод-аутентификации
Задает метод аутентификации, который будет использован, когда подключение соответствует этой записи. Варианты выбора перечислены ниже; подробности см. в разделе Методы аутентификации.

trust
Разрешить безусловное подключение. Этот метод позволяет любому, кто может подключиться к серверу баз данных QHB, войти под любым желаемым пользователем QHB без необходимости вводить пароль или какой-либо другой аутентификации. Подробности см. в подразделе Аутентификация trust.

reject
Отклонить безусловное подключение. Это полезно для «отфильтровывания» некоторых хостов из группы; например, строка reject может заблокировать подключение от определенного хоста, тогда как следующая строка позволит подключиться остальным хостам в той же сети.

scram-sha-256
Выполнить аутентификацию SCRAM-SHA-256 для проверки пароля пользователя. Подробности см. в подразделе Аутентификация по паролю.

md5
Выполнить аутентификацию SCRAM-SHA-256 или MD5 для проверки пароля пользователя. Подробности см. в подразделе Аутентификация по паролю.

password
Потребовать для аутентификации введения клиентом незашифрованного пароля. Поскольку пароль посылается открытым текстом через сеть, такой метод нельзя использовать в недоверенных сетях. Подробности см. в подразделе Аутентификация по паролю.

gss
Использовать GSSAPI для аутентификации пользователя. Этот метод доступен только для подключений по TCP/IP. Подробности см. в подразделе Аутентификация GSSAPI. Его можно применять в сочетании с шифрованием GSSAPI.

ident
Получить имя пользователя операционной системы клиента, связываясь с сервером ident, и проверить, соответствует ли оно имени пользователя запрашиваемой базы данных. Аутентификацию ident можно использовать только при подключениях по TCP/IP. Если указать этот метод для локальных подключений, вместо него будет применяться аутентификация peer. Подробности см. в подразделе Аутентификация ident.

peer
Получить имя пользователя операционной системы клиента из операционной системы и проверить, соответствует ли оно имени пользователя запрашиваемой базы данных. Доступно только для локальных подключений. Подробности см. в подразделе Аутентификация peer.

ldap
Провести аутентификацию, используя сервер LDAP. Подробности см. в подразделе Аутентификация LDAP.

radius
Провести аутентификацию, используя сервер RADIUS. Подробности см. в подразделе Аутентификация RADIUS.

cert
Провести аутентификацию, используя клиентские сертификаты SSL. Подробности см. в подразделе Аутентификация по сертификату.

pam
Провести аутентификацию, используя службу подключаемых модулей аутентификации (Pluggable Authentication Modules, PAM), предоставляемую операционной системой. Подробности см. в подразделе Аутентификация PAM.

bsd
Провести аутентификацию, используя службу аутентификации BSD, предоставляемую операционной системой. Подробности см. в подразделе Аутентификация BSD.
.

параметры-аутентификации
После поля метод-аутентификации может идти поле (или поля) вида имя=значение, задающее параметры метода аутентификации. Подробнее о том, какие параметры доступны для различных методов аутентификации, рассказывается ниже.

Кроме перечисленных ниже параметров, относящихся к различным методам, есть один общий параметр аутентификации clientcert, который можно задать в любой записи hostssl. Этот параметр может принимать значения verify-ca и verify-full. В обоих случаях требуется, чтобы клиент предоставил действительный (доверенный) сертификат SSL, но вариант verify-full дополнительно требует, чтобы значение cn (Common Name, общее имя) в сертификате соответствовало имени пользователя или применимому сопоставлению. Это поведение схоже с методом аутентификации cert (см. подраздел Аутентификация по сертификату), но позволяет связать проверку сертификатов клиента с любым методом аутентификации, поддерживающим записи hostssl.

В любой записи, где используется аутентификация по сертификату клиента (т. е. в записи с методом аутентификации cert или с параметром clientcert), в параметре clientname можно указать, какая часть учетных данных в сертификате клиента будет сопоставляться при проверке. Этот параметр может принимать одно из двух значений. Если задано значение clientname=CN (это значение по умолчанию), имя пользователя сопоставляется с полем сертификата Common Name (CN, общее имя). Если задано значение clientname=DN, имя пользователя сопоставляется со всем отличительным именем, Distinguished Name (DN), в сертификате. Этот параметр, вероятно, лучше всего применять в сочетании с сопоставлением пользователя. Сравнение с DN выполняется в формате RFC 2253. Чтобы просмотреть в этом формате поле DN сертификата клиента, выполните

openssl x509 -in myclient.crt -noout --subject -nameopt RFC2253 | sed "s/^subject=//"

Использовать этот параметр следует с осторожностью, особенно когда для сопоставлений с DN применяются регулярные выражения.
.

Файлы, включенные в запись конструкциями, начинающимися с @, читаются как список имен, разделенных пробелами или запятыми. Комментарии предваряются знаками #, как и в qhb_hba.conf, и вложенные конструкции с @ допустимы. Если имя файла, начинающееся с @, не является абсолютным путем, оно считается относящимся к каталогу, содержащему ссылающийся файл.

Поскольку записи в qhb_hba.conf просматриваются последовательно для каждой попытки подключения, порядок записей имеет большое значение. Обычно более ранние записи содержат жесткие параметры соответствия для подключения и более гибкие методы аутентификации, тогда как в более поздних записях параметры соответствия менее требовательны, а методы аутентификации более строгие. Например, некто желает использовать аутентификацию trust для локальных подключений по TCP/IP, но при этом запрашивать пароль для удаленных подключений по TCP/IP. В этом случае запись, задающая аутентификацию trust для подключений с адреса 127.0.0.1 должна предшествовать записи, задающей аутентификацию по пароль для более широкого диапазона клиентских IP-адресов.

Файл qhb_hba.conf прочитывается при запуске системы, а также при получении основным серверным процессом сигнала SIGHUP. При редактировании этого файла во время работы системы необходимо послать сигнал процессу qhbmaster (воспользовавшись pg_ctl reload, вызвав функцию SQL pg_reload_conf() или выполнив kill -HUP), чтобы он заново прочел файл.

Системное представление pg_hba_file_rules может быть полезно для предварительной проверки изменений в файле qhb_hba.conf или для диагностики проблем, если загрузка этого файла не привела к желаемым результатам. Строки в этом представлении, содержащие в поле error не NULL, указывают на проблемы в соответствующих строках файла.

Совет
Чтобы подключиться к определенной базе данных, пользователь должен не только пройти проверки файла qhb_hba.conf, но и иметь право CONNECT для этой базы данных. Если требуется ограничить доступ к каким-либо базам данных для определенных пользователей, как правило, этим проще управлять, предоставляя/ отзывая право CONNECT, нежели устанавливая правила в записях qhb_hba.conf.

Некоторые примеры записей файла qhb_hba.conf показаны в Примере 1 ниже. Более подробную информацию о различных методах аутентификации см. в следующем разделе.

Пример 1. Пример записей qhb_hba.conf

# Позволить любому пользователю локальной системы подключаться к любой базе данных,
# используя любое имя пользователя баз данных, через сокеты домена Unix
# (по умолчанию для локальных подключений).
#
# TYPE  DATABASE        USER            ADDRESS                 METHOD
  local all             all                                     trust

# То же самое, но для локальных подключений loopback по TCP/IP.
#
# TYPE  DATABASE        USER            ADDRESS                 METHOD
  host  all             all             127.0.0.1/32            trust

# То же, что и в предыдущей строке, но с указанием сетевой маски в отдельном столбце
#
# TYPE  DATABASE        USER            IP-ADDRESS      IP-MASK             METHOD
  host  all             all             127.0.0.1       255.255.255.255     trust

# То же самое для IPv6.
#
# TYPE  DATABASE        USER            ADDRESS                 METHOD
  host  all             all             ::1/128                 trust

# То же самое, но с использованием имени хоста (обычно охватывает и IPv4, и IPv6).
#
# TYPE  DATABASE        USER            ADDRESS                 METHOD
  host  all             all             localhost               trust

# Позволить любому пользователю любого узла с IP-адресом 192.168.93.x подключаться
# к базе данных «qhb» с тем же именем пользователя, которое сообщает для данного
# подключения ident (как правило, имя пользователя операционной системы).
#
# TYPE  DATABASE        USER            ADDRESS                 METHOD
  host  qhb             all             192.168.93.0/24         ident

# Позволить любому пользователю узла 192.168.12.10 подключаться к базе данных
# «qhb», если передается правильный пароль пользователя.
#
# TYPE  DATABASE        USER            ADDRESS                 METHOD
  host  qhb             all             192.168.12.10/32        scram-sha-256

# Позволить любому пользователю хостов в домене example.com подключаться к
# любой базе данных, если передается правильный пароль пользователя.
#
# Для большинства пользователей требуется аутентификация SCRAM, за исключением
# пользователя 'mike', который использует более старый клиент, не поддерживающий
# аутентификацию SCRAM.
#
# TYPE  DATABASE        USER            ADDRESS                 METHOD
  host  all             mike            .example.com            md5
  host  all             all             .example.com            scram-sha-256

# В случае отсутствия предшествующих строчек с «host», эти три строки откажут
# в любых подключениях с 192.168.54.1 (поскольку эта запись будет сопоставлена
# первой), но разрешат подключения с шифрованием GSSAPI с любых других адресов
# интернета. С нулевой маской ни один бит из IP-адреса узла не учитывается,
# так что этой строке соответствует любой узел. Подключения без GSSAPI (которые
# «опускаются» до третьей строки, поскольку записи "hostgssenc" соответствуют
# только подключения с GSSAPI) разрешены, но только с адреса 192.168.12.10.
#
# TYPE       DATABASE        USER            ADDRESS                 METHOD
  host       all             all             192.168.54.1/32         reject
  hostgssenc all             all             0.0.0.0/0               gss
  host       all             all             192.168.12.10/32        gss

# Позволить пользователям с узлов 192.168.x.x подключаться к любой базе данных,
# если они проходят проверку ident.  Если же ident говорит, к примеру, что это
# пользователь "bryanh" и он запрашивает подключение как пользователь QHB "guest1",
# подключение будет разрешено, если в qhb_ident.conf есть запись с сопоставлением
# "omicron", разрешающим пользователю "bryanh" подключаться как "guest1".
#
# TYPE  DATABASE        USER            ADDRESS                 METHOD
  host  all             all             192.168.0.0/16          ident map=omicron

# Если для локальных подключений предусмотрены только эти три строки, они позволят
# локальным пользователям подключаться только к их собственным базам данных (базам
# данных с именами, совпадающими с их именами пользователей баз данных), за
# исключением администраторов и членов роли "support", которые могут подключаться
# ко всем базам данных. Список имен администраторов содержится в файле
# $PGDATA/admins. Пароли требуются в любом случае.
#
# TYPE   DATABASE         USER              ADDRESS               METHOD
  local  sameuser         all                                     md5
  local  all              @admins                                 md5
  local  all              +support                                md5

# Последние две строки выше можно объединить в одну:
  local  all              @admins,+support                        md5

# В столбце DATABASE также можно указывать списки и имена файлов:
  local  db1,db2,@demodbs all                                     md5

Файл сопоставлений имен пользователей

При использовании внешней системы аутентификации, например Ident или GSSAPI, имя пользователя операционной системы, устанавливающего подключение, может не совпадать с целевым именем пользователя (роли) базы данных. В этом случае можно применить сопоставление имен пользователей ОС и пользователей базы данных. Чтобы воспользоваться этим сопоставлением, следует указать map=имя-сопоставления в поле параметров в файле qhb_hba.conf. Этот параметр поддерживается для всех методов аутентификации, принимающих внешние имена пользователей. Поскольку для разных подключений могут понадобиться разные сопоставления, имя применяемого сопоставления задается в параметре имя-сопоставления в qhb_hba.conf для каждого отдельного подключения.

Сопоставления имен пользователей определяются в файле сопоставления ident, который по умолчанию называется pg_ident.conf и хранится в каталоге данных кластера. (Однако этот файл можно поместить и в другое место; см. описание параметра конфигурации ident_file.) Файл сопоставления ident содержит строки общего вида:

имя-сопоставления имя-пользователя-ос имя-пользователя-бд

Синтаксис комментариев, пробелов и переносов строк такой же, как в файле qhb_hba.conf. имя-сопоставления является произвольным именем, по которому будут обращаться к этому сопоставлению в qhb_hba.conf. Два других поля указывают имя пользователя операционной системы и соответствующее имя пользователя базы данных. имя-сопоставления можно использовать неоднократно, чтобы задать несколько сопоставлений имен пользователей в рамках одного файла сопоставления.

Нет никаких ограничений касательно количества пользователей баз данных, на которые может ссылаться пользователь операционной системы, и наоборот. В связи с этим записи в файле сопоставления скорее имеют смысл «этому пользователю операционной системы разрешено подключаться под этим именем пользователя базы данных», нежели подразумевают, что эти имена пользователей равнозначны. Подключение будет разрешено, если в файле сопоставления есть запись, соединяющая имя пользователя, полученное от внешней системы аутентификации, с именем пользователя базы данных, под которым этот пользователь хочет подключиться.

Если поле имя-пользователя-ос начинается со слэша (/), оставшаяся часть поля рассматривается как регулярное выражение. (Более подробную информацию о синтаксисе регулярных выражений QHB см. в подразделе Подробное описание регулярных выражений.) Регулярное выражение может включать в себя одно обобщение или заключенное в скобки вложенное выражение, на которое можно сослаться в поле имя-пользователя-бд, написав \1 (обратный слэш-один). Это позволяет сопоставить несколько имен пользователей в одной строке, что особенно полезно для простых синтаксических замен. Например, эти записи

mymap   /^(.*)@mydomain\.com$      \1
mymap   /^(.*)@otherdomain\.com$   guest

удалят доменную часть для пользователей, чье имя пользователя системы оканчивается на @mydomain.com, и позволят всем пользователям, чье имя пользователя системы оканчивается на @otherdomain.com, подключиться как guest.

Совет
Помните, что по умолчанию регулярное выражение может совпасть только с частью строки. Разумным выходом будет использовать символов ^ и $, как показано в примере выше, чтобы обеспечить совпадение со всем именем пользователя ОС.

Файл pg_ident.conf прочитывается при запуске системы, а также при получении основным серверным процессом сигнала SIGHUP. При редактировании этого файла во время работы системы необходимо послать сигнал процессу qhbmaster (воспользовавшись pg_ctl reload, вызвав функцию SQL pg_reload_conf() или выполнив kill -HUP), чтобы он заново прочел файл.

Файл pg_ident.conf, который можно использовать в сочетании с файлом qhb_hba.conf из Примера 1, показан в Примере 2. В этом примере любому, выполнившему вход в систему на компьютере в сети 192.168 под именем пользователя операционной системы, отличным от bryanh, ann или robert, будет отказано в доступе. Пользователь ОС Unix robert получит доступ, только когда попытается подключиться как пользователь QHB bob, но не как robert или какой-либо другой пользователь. Пользователь ann сможет подключиться только как ann. Пользователь bryanh сможет подключиться как bryanh или как guest1.

Пример 2. Пример файла pg_ident.conf

# MAPNAME       SYSTEM-USERNAME         PG-USERNAME

omicron         bryanh                  bryanh
omicron         ann                     ann
# у пользователя БД bob на этих компьютерах имя пользователя robert
omicron         robert                  bob
# bryanh также может подключаться как guest1
omicron         bryanh                  guest1

Методы аутентификации

QHB предоставляет к использованию разнообразные методы аутентификации пользователей:

Аутентификация trust, которая просто верит, что пользователи именно те, за кого себя выдают.
Аутентификация по паролю, которая требует, чтобы пользователи ввели пароль.
Аутентификация GSSAPI, которая полагается на библиотеку безопасности, совместимую с GSSAPI. Обычно этот метод используется для доступа к серверу аутентификации, например Kerberos или Microsoft Active Directory.
Аутентификация ident, которая полагается на службу «Протокол идентификации» (RFC 1413) на машине клиента. (При подключениях через локальные сокеты домена Unix этот метод воспринимается как аутентификация peer.)
Аутентификация peer, которая рассчитывает, что средства операционной системы определят процесс на другой стороне локального подключения. Для удаленных подключений этот метод не поддерживается.
Аутентификация LDAP, которая полагается на сервер аутентификации LDAP.
Аутентификация RADIUS, которая полагается на сервер аутентификации RADIUS.
Аутентификация по сертификату, которая требует подключения SSL и опознает пользователей, проверяя передаваемые ими сертификаты SSL.
Аутентификация PAM, которая полагается на библиотеку PAM (Pluggable Authentication Modules, подключаемые модули аутентификации).
Аутентификация BSD, которая полагается на инфраструктуру аутентификации BSD (в настоящее время доступна только в системе OpenBSD).

Для локальных подключений обычно рекомендуется аутентификация peer, хотя в некоторых обстоятельствах может быть достаточно и аутентификации trust. Для удаленных подключений самой простой будет аутентификация по паролю. Все прочие варианты требуют участия некоторой внешней инфраструктуры безопасности (обычно это сервер аутентификации или центр сертификации, выдающий сертификаты SSL) или поддерживаются не на всех платформах.

Аутентификация trust

Когда указан метода аутентификации trust, QHB предполагает, что любой подключающийся к серверу авторизован для доступа к базе данных, независимо от указанного имени пользователя базы данных (даже если это имя суперпользователя). Разумеется, ограничения, прописанные в столбцах database и user, продолжают действовать. Этот метод следует применять только в том случае, когда на уровне операционной системы обеспечена адекватная защита подключений к серверу.

Аутентификация trust оптимальна и очень удобна для локальных подключений на однопользовательской рабочей станции. Обычно сам по себе этот метод не подходит для машин с несколькими пользователями. Однако его можно использовать даже на многопользовательской машине, если ограничить доступ к серверному файлу сокета домена Unix посредством разрешений файловой системы. Для этого нужно установить параметры конфигурации unix_socket_permissions (и, возможно, unix_socket_group) как описано в подразделе Подключения и аутентификация. Или можно установить параметр конфигурации unix_socket_directories, чтобы разместить файл сокета в должным образом защищенном каталоге.

Установка разрешений на уровне файловой системы помогает только в случае подключения через для сокета домена Unix. На локальные подключения по TCP/IP ограничения файловой системы не действуют. Таким образом, если вы хотите использовать разрешения файловой системы для обеспечения локальной безопасности, уберите строку host ... 127.0.0.1 ... из файла qhb_hba.conf или смените метод аутентификации.

Аутентификация trust подойдет для подключений по TCP/IP, только если вы доверяете каждому пользователю на каждом компьютере, который получил разрешение на подключение к серверу строками файла qhb_hba.conf, указывающими метод trust. Не рекомендуется использовать trust для любых подключений по TCP/IP, отличных от localhost (127.0.0.1).

Аутентификация по паролю

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

scram-sha-256

С методом scram-sha-256 выполняется аутентификация SCRAM-SHA-256, как описано в RFC 7677. Она производится по схеме запрос-ответ, предотвращающей перехват паролей через недоверенные соединения и поддерживающей хранение паролей на сервере в криптографически хэшированной форме, которая считается безопасной.

Это наиболее безопасный из предоставляемых на данный момент методов, но он не поддерживается старыми клиентскими библиотеками.

md5

В методе md5 применяется нестандартный и менее безопасный механизм запрос- ответ. Он предотвращает перехват паролей и не допускает хранение паролей на сервере в виде простого текста, но не обеспечивает защиту, если злоумышленнику удается похитить хэши паролей с сервера. Кроме того, в наши дни алгоритм хэширования MD5 уже не считается способным защитить от целенаправленных атак.

Метод md5 несовместим с функциональностью db_user_namespace.

Для облегчения перехода от метода md5 к более новому методу SCRAM, если в качестве метода аутентификации в файле qhb_hba.conf указан md5, но пароль пользователя на сервере зашифрован для SCRAM (см. ниже), то будет автоматически выполняться аутентификация на основе SCRAM.

password

С методом password пароль передается открытым текстом и поэтому является уязвимым для атак с перехватом паролей. По возможности его всегда следует избегать. Однако если подключение защищено шифрованием SSL, то метод password может быть безопасен. (Хотя при использовании SSL, возможно, лучшим выбором будет аутентификация по сертификату SSL.)

Пароли баз данных QHB отделены от паролей пользователей операционной системы. Пароли всех пользователей базы данных хранятся в системном каталоге pg_authid. Управлять паролями можно либо с помощью команд SQL CREATE ROLE и ALTER ROLE, например CREATE ROLE foo WITH LOGIN PASSWORD 'secret', либо с помощью команды psql \password. Если пароль для пользователя не задан, вместо него хранится NULL, и пройти аутентификацию по паролю этот пользователь не сможет.

Доступность различных методов аутентификации по паролю зависит от того, как пароли пользователей шифруются на сервере (или, если точнее, хэшируются). Это определяется параметром конфигурации password_encryption в момент назначения пароля. Если пароль шифруется алгоритмом scram-sha-256, его можно будет использовать для методов аутентификации scram-sha-256 и password (но в последнем случае пароль будет передаваться открытым текстом). При этом в случае указания метода аутентификации md5 произойдет автоматическое переключение на использование метода scram-sha-256, как описано выше, так что этот вариант тоже будет работать. Если пароль шифруется алгоритмом md5, то его можно будет использовать только для методов аутентификации md5 и password (опять же, в последнем случае пароль будет передаваться открытым текстом). Чтобы проверить хранящиеся в данный момент в базе данных хэши паролей, обратитесь к системному каталогу pg_authid.

Чтобы перевести существующую установку с md5 на scram-sha-256, сперва убедитесь о том, что все клиентские библиотеки были обновлены до версий, поддерживающих SCRAM, задайте password_encryption = 'scram-sha-256' в qhb.conf, заставьте всех пользователей сменить свои пароли, а затем поменяйте указание метода аутентификации в qhb_hba.conf на scram-sha-256.

Аутентификация GSSAPI

GSSAPI — это принятый в качестве отраслевого стандарта протокол для безопасной аутентификации, определенный в RFC 2743. QHB поддерживает применение GSSAPI для аутентификации, шифрования соединений, а также для аутентификации с шифрованием. GSSAPI предоставляет автоматическую аутентификацию (система единого входа) для систем, которые ее поддерживают. Сама по себе аутентификация безопасна, но данные, передаваемые через подключение к базе данных, будут кодироваться, только если используется шифрование GSSAPI или SSL.

Поддержку GSSAPI следует включать при сборке QHB; дополнительную информацию см. в главе Установка.

При работе с Kerberos GSSAPI использует стандартные имена субъектов-служб (аутентификационные идентификаторы) в формате имя_службы/ имя_хоста@область. Имя субъекта-службы, используемое конкретной установкой, не закодировано в сервере QHB ни в каком виде; оно задается в файле keytab, который сервер прочитывает для определения его идентификатора. Если в файле keytab перечислено несколько субъектов-служб, сервер выберет любой из них. В качестве области сервера задается предпочитаемая область, указанная в доступном серверу файле (или файлах) конфигурации Kerberos.

Клиент должен знать имя субъекта-службы сервера, к которому он намерен подключиться. Обычно в качестве элемента имя_службы субъекта-службы указывается qhb, но в параметре подключения krbsrvname в libpq можно выбрать и другое значение. В элементе имя_хоста задается полное имя узла, к которому будет подключаться libpq. В элементе область задается предпочитаемая область, указанная в доступном клиенту файле (или файлах) конфигурации Kerberos.

У клиента также должно быть имя субъекта-службы для его собственного идентификатора (и он должен иметь действительный билет для этого субъекта- службы). Чтобы использовать GSSAPI для аутентификации, субъект-служба клиента должен быть связан с именем пользователя базы данных QHB. Для сопоставления имен субъектов-служб с именами пользователей можно воспользоваться файлом конфигурации pg_ident.conf; например, pgusername@realm можно сопоставить с простым pgusername. Как вариант, можно использовать полное имя субъекта-службы username@realm в качестве имени роли в QHB без какого-либо сопоставления.

QHB также поддерживает сопоставление субъектов-служб клиентов с именами пользователей путем простого удаления элемента области из имени субъекта- службы. Этот метод оставлен для обратной совместимости и настоятельно не рекомендуется к использованию, поскольку при этом невозможно различить разных пользователей с одинаковыми именами, но приходящих из разных областей. Чтобы включить этот режим, установите для include_realm значение 0. В простых установках с одной областью исключение области в сочетании с установкой параметра krb_realm (который позволяет ограничить область субъекта-службы значением, заданным в параметре krb_realm) все же будет безопасным, но менее эффективным подходом по сравнению с явным сопоставлением в pg_ident.conf.

Расположение файла keytab на сервере задается параметром конфигурации krb_server_keyfile. По соображениям безопасности рекомендуется использовать отдельный файл keytab специально для сервера QHB, а не разрешать серверу читать системный файл keytab. Сделайте так, чтобы пользователь, от имени которого запущен сервер QHB, имел право на чтение этого серверного файла keytab (право на запись давать не стоит). (См. также раздел Учетная запись пользователя QHB.)

Файл keytab генерируется с использованием ПО; подробную информацию см. в документации Kerberos. Следующий пример показывает, как его сгенерировать с помощью программы kadmin в MIT-совместимых реализациях Kerberos 5:

kadmin% addprinc -randkey postgres/server.my.domain.org
kadmin% ktadd -k krb5.keytab postgres/server.my.domain.org

Для метода аутентификации GSSAPI поддерживаются следующие параметры аутентификации:

include_realm
При значении 0 перед проведением сопоставления имен пользователей из субъекта- службы аутентифицированного пользователя убирается область (см. раздел Файл сопоставлений имен пользователей). Этот вариант не рекомендуется и поддерживается в основном для обратной совместимости, поскольку он небезопасен в средах с несколькими областями, если только дополнительно не установить krb_realm. Рекомендуется оставить в include_realm значение по умолчанию (1) и задать в pg_ident.conf явное сопоставление для преобразования имен субъектов-служб в имена пользователей QHB.

map
Разрешает сопоставление субъектов-служб с именами пользователей базы данных. Подробную информацию см. в разделе Файл сопоставлений имен пользователей. Для субъекта-службы GSSAPI/Kerberos, такого как username@EXAMPLE.COM (или более редкого username/hostbased@EXAMPLE.COM), именем пользователя в сопоставлении будет username@EXAMPLE.COM (или username/hostbased@EXAMPLE.COM соответственно), если include_realm не равно 0; иначе имя системного пользователя в сопоставлении будет username (или username/hostbased).

krb_realm
Задает область, с которой будут сопоставляться имена субъектов-служб пользователей. Если этот параметр установлен, подключаться смогут только пользователи из этой области. Если он не установлен, подключаться смогут пользователи из любой области, в зависимости от выполняемого сопоставления имен пользователей.

Помимо этих параметров, которые могут отличаться в разных записях файла qhb_hba.conf, существует параметр конфигурации уровня сервера krb_caseins_users. Если он равен true, субъекты-службы пользователей сопоставляются с записями пользователей без учета регистра. Если установлен параметр krb_realm, области тоже сопоставляются без учета регистра.

Аутентификация ident

Метод аутентификации ident работает, получая имя пользователя операционной системы клиента от сервера Ident и используя его в качестве разрешенного имени пользователя базы данных (с возможным сопоставлением имен пользователей). Этот метод поддерживается только для подключений по TCP/IP.

Примечание
При указании ident для локального подключения (не TCP/IP), вместо него будет использован метод подключения peer (см. подраздел Аутентификация peer).

Для метода ident поддерживаются следующие параметры конфигурации:

map
Позволяет сопоставить имена пользователей системы и базы данных. Подробную информацию см. в разделе Файл сопоставлений имен пользователей.

«Протокол идентификации» (Ident) описан в RFC 1413. Практически каждая Unix- подобная операционная системы поставляется с сервером Ident, по умолчанию прослушивающим TCP-порт 113. Базовая функциональность этого сервера — отвечать на вопросы вроде «Какой пользователь инициировал подключение, которое идет через твой порт X и подключается к моему порту Y?». Поскольку после установления физического подключения QHB знает и X, и Y, она может опрашивать сервер Ident на хосте клиентского подключения и теоретически может определять пользователя операционной системы при каждом подключении.

Недостаток этой процедуры состоит в том, что она зависит от интеграции с клиентом: если компьютер клиента недоверенный или взломанный, злоумышленник может запустить практически любую программу на порту 113 и вернуть любое имя пользователя по своему выбору. Таким образом, этот метод аутентификации подходит только для закрытых сетей, где каждый компьютер клиента находится под строгим контролем и где администраторы операционных систем и баз данных работают в тесном контакте. Другими словами, вы должны доверять компьютеру, на котором работает сервер Ident. Относитесь серьезно к предупреждению:

Протокол идентификации не предназначен для использования в качестве протокола авторизации или управления доступом.

--RFC 1413

У некоторых серверов Ident есть нестандартная функциональность, позволяющая зашифровывать возвращаемое имя пользователя, используя ключ, который известен только администратору исходного компьютера. Эту функциональность нельзя использовать с QHB, так как у QHB нет никакой возможности расшифровать возвращаемую строку и получить фактическое имя пользователя.

Аутентификация peer

Метод аутентификации peer работает, получая имя пользователя операционной системы клиента из ядра и используя его в качестве разрешенного имени пользователя базы данных (с возможным сопоставлением имен пользователей). Этот метод поддерживается только для локальных подключений.

Для метода peer поддерживаются следующие параметры конфигурации:

Аутентификация peer доступна только в операционных системах, предоставляющих функцию getpeereid(), параметр сокета SO_PEERCRED или схожие механизмы. В настоящее время это Linux, большинство разновидностей BSD, включая macOS, и Solaris.

Аутентификация LDAP

Этот метод аутентификации работает сходным с методом password образом, за исключением того, что он использует LDAP в качестве метода подтверждения пароля. LDAP используется только для подтверждения пар имя пользователя/пароль. Поэтому пользователь должен уже существовать в базе данных до того, как для аутентификации можно будет использовать LDAP.

Аутентификация LDAP может работать в двух режимах. В первом режиме, который мы назовем простым связыванием, сервер связывается с отличительным именем, составленным в виде префикс имя_пользователя суффикс. Как правило, параметр префикс используется для указания cn= или DOMAIN\ в среде Active Directory. Параметр суффикс используется для указания оставшейся части DN в среде, отличной от Active Directory.

Во втором режиме, который мы назовем поиск+связывание, сервер сначала связывается с каталогом LDAP с постоянным именем пользователя и паролем, указанными в ldapbinddn и ldapbindpasswd, и выполняет поиск этого пользователя, пытающегося подключиться к базе данных. Если пользователь и пароль не определены, сервер пытается связаться с каталогом анонимно. Поиск осуществляется в поддереве ldapbasedn с попыткой подобрать точное соответствие атрибуту, заданному в ldapsearchattribute. Как только при поиске находится пользователь, сервер разрывает подключение и заново связывается с каталогом уже как этот пользователь, используя указанный клиентом пароль, чтобы удостовериться, что эта учетная запись корректна. Этот же режим применяется в схемах аутентификации LDAP в другом программном обеспечении, например в mod_authnz_ldap и pam_ldap в Apache. Этот режим дает гораздо больше гибкости в выборе расположения объектов пользователей в каталоге, но при этом требует дважды подключаться к серверу LDAP.

В обоих режимах используются следующие параметры конфигурации:

ldapserver
Имена или IP-адреса серверов LDAP для подключения. Можно указать несколько серверов, разделяя их пробелами.

ldapport
Номер порта для подключения к серверу LDAP. Если порт не указан, будет использован установленный по умолчанию порт библиотеки LDAP.

ldapscheme
Значение ldaps выбирает протокол LDAPS. Это нестандартный способ использования LDAP поверх SSL, поддерживаемый некоторыми реализациями сервера LDAP. Альтернативный вариант см. в описании параметра ldaptls.

ldaptls
При значении 1 в соединении QHB с сервером LDAP применяется шифрование TLS. При этом используется операция StartTLS, описанная в RFC 4513. Альтернативный вариант см. в описании параметра ldapscheme.

Обратите внимание, что при использовании ldapscheme или ldaptls шифруется только трафик между сервером QHB и сервером LDAP. Соединение между сервером QHB и клиентом QHB останется незашифрованным, если только и для него не применяется SSL.

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

ldapprefix
Эта строка подставляется перед именем пользователя во время формирования DN для связывания при аутентификации в режиме простого связывания.

ldapsuffix
Эта строка подставляется после имени пользователя во время формирования DN для связывания при аутентификации в режиме простого связывания.

Следующие параметры используются только в режиме поиск+связывание:

ldapbasedn
Корневая папка DN, с которой начинается поиск пользователя при аутентификации в режиме поиск+связывание.

ldapbinddn
DN пользователя для связывания с каталогом при выполнении поиска в ходе аутентификации в режиме поиск+связывание.

ldapbindpasswd
Пароль пользователя для связывания с каталогом при выполнении поиска в ходе аутентификации в режиме поиск+связывание.

ldapsearchattribute
Атрибут для сравнения с именем пользователя при выполнении поиска в ходе аутентификации в режиме поиск+связывание. Если атрибут не указан, будет использован атрибут uid.

ldapsearchfilter
Фильтр поиска, используемый при аутентификации в режиме поиск+связывание. Вхождения $username в нем будут заменяться именем пользователя. Это позволяет задавать более гибкие фильтры поиска, чем ldapsearchattribute.

ldapurl
URL-адрес LDAP согласно стандарту RFC 4516. Это альтернативный способ записи некоторых других параметров LDAP в более компактной и стандартной форме. Формат адреса выглядит так:

ldap[s]://хост[:порт]/dn_базы[?[атрибут][?[область_действия][?[фильтр]]]]

Элемент область_действия должен иметь значение base, one или sub, обычно последнее. (Значение по умолчанию, base, обычно не очень полезно при таком применении.) В элементе атрибут можно назначить один атрибут; в этом случае он используется как значение параметра ldapsearchattribute. Если атрибут не указан, в качестве значения параметра ldapsearchfilter можно использовать фильтр.

Схема URL-адреса ldaps выбирает для установления LDAP-подключений поверх SSL метод LDAPS, что равнозначно указанию ldapscheme=ldaps. Для применения шифрованных LDAP-подключений с операцией StartTLS используйте обычную схему URL-адреса ldap и в дополнение к параметру ldapurl укажите ldaptls.

Для неанонимных связываний ldapbinddn и ldapbindpasswd следует указывать как отдельные параметры.

В настоящее время URL-адреса LDAP поддерживаются только с OpenLDAP.
.

Не стоит путать параметры конфигурации для режима простого связывания с параметрами для режима поиск+связывание, это будет ошибкой.

В режиме поиск+связывание поиск может выполняться либо по одному атрибуту, заданному в ldapsearchattribute, либо по произвольному фильтру поиска, заданному в ldapsearchfilter. Указание ldapsearchattribute=foo равнозначно указанию ldapsearchfilter="(foo=$username)". Если ни один параметр не указан, по умолчанию подразумевается ldapsearchattribute=uid.

Если QHB была скомпилирована с OpenLDAP в качестве клиентской библиотеки LDAP, параметр ldapserver может быть опущен. В этом случае за списком имен хостов и портов сервер, согласно стандарту RFC 2782, обращается в DNS, к SRV-записи с именем _ldap._tcp.DOMAIN, где DOMAIN извлекается из ldapbasedn.

Пример конфигурации LDAP для простого связывания:

host ... ldap ldapserver=ldap.example.net ldapprefix="cn=" ldapsuffix=", dc=example, dc=net"

Когда запрашивается подключение к серверу баз данных в качестве пользователя базы данных someuser, QHB пытается связаться с сервером LDAP, используя DN cn=someuser, dc=example, dc=net и пароль, предоставленный клиентом. Если это подключение удалось, то доступ к базе данных будет открыт.

Пример конфигурации для режима поиск+связывание:

host ... ldap ldapserver=ldap.example.net ldapbasedn="dc=example, dc=net" ldapsearchattribute=uid

Когда запрашивается подключение к серверу баз данных в качестве пользователя базы данных someuser, QHB пытается связаться с сервером LDAP анонимно (поскольку параметр ldapbinddn не был задан), выполняет поиск для (uid=someuser) под указанным DN базы. Если запись найдена, QHB пытается связаться с использованием этой найденной информации и пароля, предоставленного клиентом. Если это второе подключение удалось, то доступ к базе данных будет открыт.

Пример той же конфигурации для режима поиск+связывание, записанной в виде URL-адреса:

host ... ldap ldapurl="ldap://ldap.example.net/dc=example,dc=net?uid?sub"

Такой же формат URL-адреса используется и другим программным обеспечением, поддерживающим аутентификацию по протоколу LDAP, так что эту конфигурацию будет легче использовать совместно.

Пример конфигурации для режима поиск+связывание, в котором ldapsearchfilter используется вместо ldapsearchattribute для прохождения аутентификации по ID или почтовому адресу пользователя:

host ... ldap ldapserver=ldap.example.net ldapbasedn="dc=example, dc=net" ldapsearchfilter="(|(uid=$username)(mail=$username))"

Пример конфигурации для режима поиск+связывание, в котором используется поиск SRV-записи в DNS для получения имен хостов и портов службы LDAP в домене example.net:

host ... ldap ldapbasedn="dc=example,dc=net"

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

Аутентификация RADIUS

Этот метод аутентификации работает сходным с методом password образом, за исключением того, что он использует RADIUS в качестве метода проверки пароля. RADIUS используется только для подтверждения пар имя пользователя/пароль. Поэтому пользователь должен уже существовать в базе данных до того, как для аутентификации можно будет использовать RADIUS.

При использовании аутентификации RADIUS настроенному серверу RADIUS посылается сообщение с запросом доступа. Это запрос типа Authenticate Only (только аутентификация), который включает в себя элементы user name (имя пользователя), password (зашифрованный пароль) и NAS Identifier (идентификатор NAS). Запрос шифруется с использованием общего с сервером секрета. Сервер RADIUS отвечает на этот запрос либо Access Accept (Доступ разрешен), либо Access Reject (В доступе отказано). Система ведения учета для RADIUS отсутствует.

Можно указать несколько серверов RADIUS, тогда они будут перебираться по очереди. Если от любого из серверов будет получен отрицательный ответ, произойдет сбой аутентификации.Если ответ не будет получен, последует попытка подключения к следующему серверу в списке. Чтобы указать несколько серверов, следует разделить их имена запятыми и заключить список в кавычки. При этом все остальные параметры RADIUS тоже можно задать в списках через запятую, чтобы каждый сервер получил отдельное значение. Также их можно задавать одним значением, тогда оно будет применяться ко всем серверам.

Для метода RADIUS поддерживаются следующие параметры конфигурации:

radiusservers
DNS-имена или IP-адреса серверов RADIUS для подключения. Это обязательный параметр.

radiussecrets
Общие секреты, используемые при защищенном обращении к серверам RADIUS. Значение этого параметра должно быть одинаковым на серверах QHB и RADIUS. Рекомендуется использовать стоку как минимум из 16 символов. Это обязательный параметр.

Примечание
Вектор шифрования будет криптографически эффективен только в том случае, если QHB собрана с поддержкой OpenSSL. В остальных случаях передача данных серверу RADIUS следует считать замаскированной, но не защищенной, поэтому при необходимости нужно применить дополнительные меры безопасности.

radiusports
Номера портов для подключения к серверам RADIUS. Если никакой порт не задан, будет использован порт RADIUS по умолчанию (1812).

radiusidentifiers
Сроки, используемые в запросах RADIUS как NAS Identifier. Этот параметр можно использовать, например, для обозначения того, к какому кластеру баз данных пытается подключиться пользователь, что может быть полезно для выбора соответствующей политики на сервере RADIUS. Если никакой идентификатор не задан, по умолчанию будет использован qhb.

Если в значение параметра RADIUS необходимо добавить запятую или пробел, это можно сделать, заключив это значение в кавычки, но это неудобно, поскольку теперь потребуется два уровня кавычек. Например, так добавляются пробелы в строки секретов RADIUS:

host ... radius radiusservers="server1,server2" radiussecrets="""secret one"",""secret two"""

Аутентификация по сертификату

В данном методе аутентификации используются клиентские сертификаты SSL, поэтому он применим только для подключений SSL. При использовании этого метода аутентификации сервер запросит у клиента предъявления действительного и доверенного сертификата. Пароль у клиента запрашиваться не будет. Атрибут cn (CommonName, Обычное имя) сертификата сравнивается с запрашиваемым именем пользователя базы данных, и если они совпадают, вход будет разрешен. Если cn отличается от имени пользователя базы данных, то можно использовать сопоставление имен пользователей.

Для аутентификации по сертификату SSL поддерживаются следующие параметры конфигурации:

Указывать параметр clientcert для аутентификации cert излишне, поскольку метод cert по сути является методом trust с параметром clientcert=verify-full.

Аутентификация PAM

Этот метод аутентификации работает сходным с методом password образом, за исключением того, что он использует PAM (Pluggable Authentication Modules, подключаемые модули аутентификации) в качестве механизма аутентификации. По умолчанию имя службы PAM — qhb. PAM используется только для подтверждения пар имя пользователя/пароль и, при необходимости, имени или IP-адреса подключенного удаленного хоста. Поэтому пользователь должен уже существовать в базе данных до того, как для аутентификации можно будет использовать PAM. Более подробную информацию о PAM см. на странице описания Linux-PAM.

Для метода PAM поддерживаются следующие параметры конфигурации:

pamservice
Имя службы PAM.

pam_use_hostname
Определяет, предоставляется ли модулям PAM через элемент PAM_RHOST IP-адрес или имя удаленного хоста. По умолчанию используется IP-адрес. При значении 1 вместо него используется разрешенное имя хоста. Разрешение имени хоста может привести к задержкам при подключении. (Большинство конфигураций PAM не пользуются этой информацией, так что этот параметр необходим, только если была создана специальная конфигурация PAM, в которой он используется.)

Примечание
Если PAM настроен для чтения /etc/shadow, произойдет сбой аутентификации, потому что сервер QHB запущен не пользователем root. Однако это не имеет значения, когда PAM настроен для использования LDAP или других методов аутентификации.

Аутентификация BSD

Этот метод аутентификации работает сходным с методом password образом, за исключением того, что он использует аутентификацию BSD для подтверждения пароля. Аутентификация BSD используется только для подтверждения пар имя пользователя/ пароль. Поэтому пользователь должен уже существовать в базе данных до того, как для аутентификации можно будет использовать BSD. Инфраструктура аутентификации BSD в настоящее время доступна только в системе OpenBSD.

Для аутентификации BSD в QHB применяется тип входа auth-qhb и проверка с классом входа qhb, если это определено в login.conf. По умолчанию этот класс входа не существует и QHB использует стандартный класс входа.

Примечание
Для применения аутентификации BSD необходимо сначала добавить учетную запись пользователя QHB (то есть пользователя операционной системы, запускающего сервер) в группу auth. Группа auth существует в системах OpenBSD по умолчанию.

Проблемы аутентификации

Сбои и другие проблемы с аутентификацией обычно проявляют себя посредством сообщений об ошибках, подобных следующему:

FATAL:  no qhb_hba.conf entry for host "123.123.123.123", user "andym", database "testdb"
-- КРИТИЧЕСКАЯ ОШИБКА: в qhb_hba.conf отсутствует запись для сервера "123.123.123.123", пользователя "andym", базы данных "testdb"

Это сообщение вы, скорее всего, получите, если сможете связаться с сервером, но он не захочет с вами общаться. В сообщении содержится предположение, что сервер отказал в подключении, потому что не может найти соответствующую запись в своем файле конфигурации qhb_hba.conf.

FATAL:  password authentication failed for user "andym"
-- КРИТИЧЕСКАЯ ОШИБКА: аутентификация пользователя "andym" по паролю не удалась

Сообщения вроде этого показывают, что вы связались с сервером и он готов общаться с вами, но только после того, как вы пройдете авторизацию по методу, указанному в файле qhb_hba.conf. Проверьте вводимый вами пароль либо настройки Kerberos или Ident, если в сообщении упоминается один из этих типов аутентификации.

FATAL:  user "andym" does not exist
-- КРИТИЧЕСКАЯ ОШИБКА: пользователь "andym" не существует

Указанное имя пользователя базы данных не найдено.

FATAL:  database "testdb" does not exist
-- КРИТИЧЕСКАЯ ОШИБКА: база данных "testdb" не существует

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

Совет
В журнале сервера может содержаться больше информации по сбою аутентификации, чем в выдаваемых клиенту сообщениях. Если вам не до конца понятны причины сбоя, проверьте журнал сервера.