PostgreSQL supporte une fonctionnalité de Single Sign-On s'appuyant sur l'API SSPI (ce que les autres bases de données appellent “authentification windows intégrée”). Ce n'est possible, cela étant, que si vous travaillez dans un domaine Windows, car cela nécessite un KDC Kerberos.

Nous supposons ici que l'installer windows est utilisé pour installer PostgreSQL sur votre serveur.

NDT: la page originale est ici.

Après l'installation, PostgreSQL est exécuté sous le compte local nommé “postgres”. Il va donc tout d'abord être nécessaire de changer cela, car l'API SSPI nécessite que le service utilise un compte du domaine :

1. Arrêtez le service.
2. Créez un compte d'utilisateur pour le domaine.
3. Modifiez le propriétaire du répertoire des données et tout son contenu avec le nouveau compte, en lui donnant un contrôle total.
4. Modifiez les droits de connexion du service de manière à utiliser votre compte de domaine.
5. Relancez le service pour vérifier que tout fonctionne correctement. Essayez de vous connecter comme auparavant, de créer une base de donnée, de supprimer des tables, d'appeler la fonction pg_switch_xlog(). Si vous pouvez vous connecter, la quasi totalité des problèmes qui pourraient alors survenir seront liés à des permissions oubliées sur les fichiers de données.

A présent, vous devez informer Active Directory que vous compte de domaine fait tourner la base de donnée. A cet effet, vous devez ajouter un “Service Principal Name (SPN)” à votre compte de domaine. Il existe un outil en ligne de commande pour cela, appelé setspn.exe :

setspn -S POSTGRES/fully.qualified.domain.name DOMAIN\service_account_name

Une autre manière de procéder consiste à modifier l'attribut (servicePrincipalName) en utilisant directement tout outil permettant de modifier le répertoire, incluant l'outil MMC “Utilisateurs et Ordinateurs”, ou un outil équivalent dans de plus récentes versions de Microsoft Server, ou encore ADSIedit.

Par expérience (NDT: il s'agit de l'utilisateur Chrullrich de postgresql.org) - qui peut donc être faillible - vous devez aussi vous assurer que l'ensemble de vos clients utilise le nom d'hôte complet, car dans le cas contraire ils n'obtiendront pas le ticket de service. L'ajout d'un second SPN qui ne disposerait pas du nom de domaine (ce qui donnerait “fully” dans l'exemple plus haut) peut aider à résoudre ce problème, mais l'usage du nom complet reste plus sécurisé.

La dernière étape consiste à autoriser la connexion SSPI à la base de donnée. Il s'agit de créer des rôles de connexion qui ont le même nom que vos utilisateurs de domaine, et une entrée dans le fichier pg_hba.conf avec comme méthode d'authentification “sspi”. N'oubliez pas que seule la première entrée de pg_hba.conf qui correspond à la base, l'adresse du client, et les éventuels noms d'utilisateur prétendus est utilisée. Optionnellement, il est possible d'automatiser la création des rôles et groupes de connexion avec pg-ldap-sync.

Dans la version 9.2, l'installer ne crée plus le compte local “postgres”, mais utilise le compte pré-installé “SERVICE RESEAU” à la place. Bien qu'il soit possible de suivre les même instructions que pour PostgreSQL 9.1 ci-dessus, il existe un moyen plus simple, mais moins sécurisé de procéder.

Pour le suivre, ajouter un SPN (Service Principal Name) au compte de l'ordinateur : aucun autre changement n'est nécessaire. Si votre serveur est appelé “dbserver”, vous pouvez utiliser cette commande:

setspn -S POSTGRES/fully.qualified.domain.name dbserver

Soyez conscient qu'exécuter la base de donnée avec un compte partagé autoriser d'autres services utilisant ce même compte à lire et modifier directement les fichiers de cette base de donnée. Si ce n'est pas acceptable pour votre environnement, suivez les instructions de la version 9.1 ci-dessus pour utiliser un compte dédié.