Ce mécanisme d'authentification opère de façon similaire à
password
à ceci près qu'il utilise LDAP comme
méthode de vérification des mots de passe.
LDAP n'est utilisé que pour valider les paires
nom d'utilisateur/mot de passe. De ce fait, pour pouvoir utiliser LDAP
comme méthode d'authentification, l'utilisateur doit préalablement exister
dans la base.
L'authentification LDAP peut opérer en deux modes. Dans le premier mode,
que nous appelerons le mode « simple bind », le serveur fera un « bind »
sur le nom distingué comme préfixe
nom_utilisateur
suffixe
.
Typiquement, le paramètre prefix
est utilisé pour spécifier
cn=
ou DOMAIN
\
dans un
environnement Active Directory. suffix
est utilisé pour spécifier le reste
du DN dans un environnement autre qu'Active Directory.
Dans le second mode, que nous appelerons mode « search+bind »,
le serveur commence un « bind » sur le répertoire
LDAP avec un nom d'utilisateur et un mot de passe fixés, qu'il indique à
ldapbinddn
et
ldapbindpasswd
. Il réalise une recherche de
l'utilisateur en essayant de se connecter à la base de données. Si aucun
utilisateur et aucun mot de passe n'est configuré, un « bind » anonyme
sera tenté sur le répertoire. La recherche sera réalisée sur le sous-arbre
sur ldapbasedn
, et essaiera une correspondance
exacte de l'attribut indiqué par
ldapsearchattribute
. Une fois que
l'utilisateur a été trouvé lors de cette recherche, le serveur se
déconnecte et effectue un nouveau « bind » au répertoire en tant que
cet utilisateur, en utilisant le mot de passe indiqué par le client pour
vérifier que la chaîne de connexion est correcte. Ce mode est identique à
celui utilisé par les schémas d'authentification LDAP dans les autres
logiciels, tels que les modules Apache mod_authnz_ldap
et pam_ldap
. Cette méthode permet une plus grande
flexibilité sur l'emplacement des objets utilisateurs dans le répertoire
mais demandera deux connexions au serveur LDAP.
Les options de configuration suivantes sont utilisées dans les deux modes :
ldapserver
Noms ou adresses IP des serveurs LDAP auxquels se connecter. Plusieurs serveurs peuvent être indiqués, en les séparant par des espaces.
ldapport
Numéro de port du serveur LDAP auquel se connecter. Si aucun port n'est spécifié, le port par défaut de la bibliothèque LDAP sera utilisé.
ldapscheme
Positionner à ldaps
pour utiliser LDAPS. Il s'agit
d'une utilisation non standard de LDAP sur SSL, supportée par certaines
implémentations de serveurs LDAP. Voir aussi l'option
ldaptls
pour une méthode alternative.
ldaptls
Positionnez à 1 pour que la connexion entre PostgreSQL et le serveur
LDAP utilise du chiffrage TLS. Ceci utilise l'opération StartTLS
d'après la RFC 4513. Voir aussi l'option ldapscheme
pour une alternative.
Veuillez noter que l'utilisation de ldapscheme
ou de
ldaptls
ne chiffre que le trafic entre le serveur
PostgreSQL et le serveur LDAP. La connexion entre le serveur PostgreSQL et
le client PostgreSQL ne sera pas pour autant chiffée, à moins que SSL ne
soit également utilisé pour la connexion.
Les options suivantes sont utilisées uniquement dans le mode « simple bind » :
ldapprefix
Chaîne à préfixer au nom de l'utilisateur pour former le DN utilisé comme lien lors d'une simple authentification bind.
ldapsuffix
Chaîne à suffixer au nom de l'utilisateur pour former le DN utilisé comme lien lors d'une simple authentification bind.
Les options suivantes sont utilisées uniquement dans le mode « search+bind » :
ldapbasedn
Racine DN pour commencer la recherche de l'utilisateur lors d'une authentification search+bind.
ldapbinddn
DN de l'utilisateur pour se lier au répertoire avec lequel effectuer la recherche lors d'une authentification search+bind.
ldapbindpasswd
Mot de passe de l'utilisateur pour se lier au répertoire avec lequel effectuer la recherche lors d'une authentification search+bind.
ldapsearchattribute
Attribut à faire correspondre au nom d'utilisateur dans la recherche
lors d'une authentification search+bind.
Si aucun attribut n'est indiqué, l'attribut uid
sera utilisé.
ldapsearchfilter
Le filtre de recherche à utiliser lors d'une authentification
search+bind. Toutes les occurences de $username
seront remplacées par le nom d'utilisateur. Cela permet des filtres de
recherche plus flexibles que ldapsearchattribute
.
ldapurl
Une URL LDAP dont le format est spécifié par la RFC 4516. C'est une autre façon d'écrire certaines options LDAP d'une façon plus compacte et standard. Le format est :
ldap[s]://hote
[:port
]/basedn
[?[attribut
][?[scope
][?[filtre
]]]]
scope
doit faire partie des possibilités
suivantes : base
, one
,
sub
. Ce sera généralement la dernière possibilité.
(La valeur par défaut est base
, qui n'est
généralement pas utile dans ce cadre là.)
attribute
peut désigner un unique attribut,
auquel cas il sera utilisé comme valeur pour
ldapsearchattribute
. Si
attribute
est vide, alors
filter
peut être utilisé comme valeur pour
ldapsearchfilter
.
Le schéma d'URL ldaps
choisit la méthode LDAPS pour
établir une connexion LDAP sur SSL, qui est équivalent à l'utilisation
de ldapscheme=ldaps
. Pour utiliser une connexion
LDAP chiffrée en utilisant l'opération StartTLS
,
utilisez le schéma d'URL normal ldap
et spécifiez
l'option ldaptls
en plus de
ldapurl
.
Pour les « bind » non anonymes, ldapbinddn
et
ldapbindpasswd
doivent être spécifiées comme des
options séparées.
Les URL LDAP sont actuellement seulement supportées par OpenLDAP, et pas sous Windows.
Mixer les options de configurations du mode « simple bind » et du mode « search+bind » est une erreur.
Lorsque vous utilisez le mode search+bind mode, la recherche peut être
effectuée en utilisant l'attribut unique spécifié avec
ldapsearchattribute
, ou en utilisant un filtre de
recherche personnalisé avec ldapsearchfilter
.
Spécifier ldapsearchattribute=foo
est équivalent à
spécifier ldapsearchfilter="(foo=$username)"
. Si aucune
de ces options n'est spécifiée, le comportement par défaut est
ldapsearchattribute=uid
.
Voici un exemple de configuration LDAP pour le mode « simple bind » :
host ... ldap ldapserver=ldap.example.net ldapprefix="cn=" ldapsuffix=", dc=example, dc=net"
Quand une connexion au serveur de base de données est demandée en tant que
un_utilisateur
, PostgreSQL tentera un « bind » vers le
serveur LDAP en utilisant le DN cn=un_utilisateur, dc=example,
dc=net
et le mot de passe fourni par le client. Si cette connexion
réussit, l'accès à la base de données est accepté.
Voici un exemple de configuration LDAP pour le mode « search+bind » :
host ... ldap ldapserver=ldap.example.net ldapbasedn="dc=example, dc=net" ldapsearchattribute=uid
Quand une connexion au serveur de base de données est tentée en tant que
un_utilisateur
, PostgreSQL tentera un « bind » anonyme
(car ldapbinddn
n'a pas été précisé) au serveur LDAP,
effectuera une recherche pour (uid=un_utilisateur)
sous
le DN de base spécifié. Si une entrée est trouvée, il tentera alors de faire un
« bind » en utilisant l'information trouvée et le mot de passe fourni par le
client. Si cette deuxième connexion réussit, l'accès à la base est autorisé.
Voici la même configuration « search+bind » écrite sous la forme d'une URL :
host ... ldap ldapurl="ldap://ldap.example.net/dc=example,dc=net?uid?sub"
D'autres logiciels qui supportent l'authentification LDAP utilisent le même format d'URL donc cela facilitera le partage de configuration.
Voici un exemple de configuration search+bind configuration qui utilise
ldapsearchfilter
plutôt que
ldapsearchattribute
pour permettre l'authentification
par nom d'utilisateur ou adresse mail :
host ... ldap ldapserver=ldap.example.net ldapbasedn="dc=example, dc=net" ldapsearchfilter="(|(uid=$username)(mail=$username))"
Comme LDAP utilise souvent des virgules et des espaces pour séparer les différentes parties d'un DN, il est souvent nécessaire d'utiliser des paramètres entourés de guillemets durant le paramétrage des options LDAP, comme montré dans les exemples.