Discussion :

[maxeur]

Bonjour à tous,

Afin d'améliorer ma configuration postgreSQL, j'ai suivi le tutoriel suivant :

http://www.postgresql.org/docs/9.1/s...-hba-conf.html

Dans mon fichier pg_hba.conf J'ai la configuration suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
# IPv4 local connections:
host    all         robot,+gtf_ldap  127.0.0.1/32         trust
host    all             all             127.0.0.1/32            md5
# IPv6 local connections:
host    all         robot,+gtf_ldap    ::1/128         trust
host    all             all             ::1/128                 md5

Par contre ce que je ne comprends pas c'est que tous mes superutilisateurs peuvent se connecter en trust alors que ce n'est pas ce qui est configuré.

Auriez-vous une idée de là où ça peut venir ?
Je précise que le groupe gtf_ldap n'est pas surperutilisateur

Merci d'avance pour votre aide

[estofilo]

Ces superutilisateurs sont membres du groupe gtf_ldap ou non?

[maxeur]

Non ils ne sont pas membres du groupe gtf_ldap, c'est là le problème.

J'ai trouvé une nouvelle info : les superutilisateurs sont apparemments membres de tous les groupes. C'est pourquoi j'ai ce problème ...

Par contre tous les logins contenus dans le groupe gtf_ldap correspondent à une ou plusieurs expressions régulières, serait-il possible de définir ceci dans le fichier pg_hba.conf :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

host    all          /^(.*)@siege\.veremes\.com$   ::1/128         trust

[estofilo]

J'ai trouvé une nouvelle info : les superutilisateurs sont apparemments membres de tous les groupes. C'est pourquoi j'ai ce problème ...

Ah oui effectivement. Ou en tout cas ils sont considérés comme tels dans les tests d'accès.
Dans ce cas une solution serait peut-être d'inverser la logique et de leur interdire l'accès sans mot de passe. Sachant que les lignes de pg_hba.conf sont testées dans l'ordre et la première qui satisfait les conditions est prise en compte, il pourrait y avoir en premier:

host    ALL             +superusers             127.0.0.1/32            md5

Avec le groupe superusers qui contiendrait les utilisateurs en question. Ou pas, puisque justement s'ils sont superviseurs, qu'ils soient dans le groupe ou pas reviendra au même.
Il faut juste que le groupe existe.

Et md5 peut aussi être remplacé par reject s'ils ne doivent pas se connecter du tout.

[maxeur]

Merci, c'était finalement simple et je n'y ai pas pensé.

[maxeur]

Il y à un problème auquel je n'ai pas pensé, c'est que mes certains de mes superutilisateurs font parti du groupe gtf_ldap

[estofilo]

Dans ce cas ils vont devoir saisir un mot de passe, pourquoi serait-ce un problème?

[maxeur]

Nous avons un script php qui permet d'importer des utilisateurs à partir de l'ad.

Donc lors de l'import nous ne pouvons pas importer les mots de passe.

Nous souhaitons donc pouvoir authentifier nos utilisateurs à partir de l'ad (soit .
en code d'où la méthode trust, soit par postgres)
Je pensais sinon faire un truc du genre dans le pg_hba.conf:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

host    all          /^(.*)@domain\.com$   127.0.0.1/32         ldap ...

Mais j'ai testé, l'expression régulière n'a pas l'air de fonctionner dans le pg_hba.conf
Si j'utilise la méthode d'authentification ldap, je suis obligé de passer par cette méthode car je peux avoir potentiellement plusieurs AD.

[maxeur]

J'ai trouvé une solution pour que les administrateurs de l'appli n'aient plus besoin d'être superuser.

Je vais donc garder cette solution.

Merci