Le portail francophone de la géomatique

Bonjour,

dans le cas d'un bind simple, postgresql va tenter une connexion (ou un bind en jargon ldap) en utilisant le DN  que vous lui avez spécifié, qui est le "chemin d'accès" d'un object ldap. Donc oui, il faut spécifier le chemin complet vers l'OU ou réside les utilisateurs qui vont se connecter à votre serveur.

Search+bind est utilisé quand par exemple vos utilisateurs se trouvent dans sur plusieurs OU. Dans ce cas la vous spécifiez un utilisateur bien défini, dont le DN ne changera pas (donc il faut également spécifier le DN), avec lequel postgresql va bind pour rechercher dans l'annuaire l'utilisateur qui tente de se connecter en faisant correspondre un attribut au nom d'utillisateur (par défaut uid, on lui préfère souvent sAMAccountName qui possède normalement la même valeur mais qui ne peut pas être vide). Si une correspondance est trouvée postgresql refait un bind avec l'utilisateur trouvé.

A noter que si votre serveur ldap le permet, la phase search peut se faire de manière anonyme, c'est à dire sans avoir a spécifier d'utilisateur (déconseillé pour des raisons de sécurité).

Sinon je pense que vous avez oublié de spécifier le prefixe dans votre hba :

ldapprefix="CN="

Dans la methode bind simple, le DN est constitué par la concaténation de chaine suivante :

ldapprefix || nom_dutilisateur || ldapsuffix

Dernière modification par tumasgiu (Tue 16 July 2024 07:33)

Bonjour,

votre serveur refuse sans doute de démarrer, très certainement à cause de la ligne que vous avez rajoutée dans le hba qui doit être incorrecte.
Il faudrait que vous regardiez les logs pour savoir exactement ce qui ne va pas.

Je ne sais pas si c'est cette erreur qui empêche postgres de démarrer, mais votre paramètre ldapsearchfilter est incorrecte. Ce paramètre est le filtre qui est utilisé pour tester si un utilisateur précis existe dans l'annuaire.

Pour ce faire il faut construire la requête à l'aide de la variable $username, qui contient le nom d'utilisateur utilisé pour se connecter au serveur postgres. La requête va s'executer sur tous les éléments du sous arbre de l'annuaire désigné par le paramètre ldapbasedn. Il faut donc que vos utilisateurs soient situés dans ce sous arbre (dans votre cas, cela a l'air bon car vous désignez l'intégralité de votre annuaire).

L'attribut testé par la requête doit donc contenir le nom d'utilisateur postgres. Dans un active directory, on utilise généralement :

ldapsearchfilter="sAMAccountName=$username"

ou

ldapsearchattribute=sAMAccountName

La documentation en français : https://docs.postgresql.fr/current/auth-ldap.html

Dernière modification par tumasgiu (Mon 22 July 2024 11:44)

Bonjour,

dans votre hba, est ce qu'il existe un enregistrement avant votre enregistrement ldap dont les 5 premiers champs seraient identiques ? (même type de connexion, même base de donnée, même plage d'adresse ip, même utilisateur)

par exemple :

host ma_bdd 192.168.1.0/24 USER md5
#plein d'autre enregistrements 
#plein d'autre enregistrements 
host ma_bdd 192.168.1.0/24 USER ldap ldapserver=ldap.dcnt1.org ldapport=XXXX ldapbasedn="dc=dcnt1,dc=org" ldapbinddn="READ@dcnt1.org" ldapbindpasswd="PASSWORD" ldapsearchattribute=sAMAccountName

Si c'est le cas, c'est obligatoirement le premier enregistrement de la liste qui corresponds à ces champs qui est utilisé pour authentifier la connexion. Si l'authentification échoue, la connexion est annulée, postgresql ne cherche pas à savoir s'il existe une autre méthode permettant de valider l'authentification plus bas dans le hba.

Cela a l'air de correspondre à votre problème.

Dernière modification par tumasgiu (Fri 06 September 2024 11:10)