Aller au contenu

GSSAPI : Authentification avec Kerberos ou Active Directory

Introduction

La méthode d’authentification gss permet de déléguer l’authentification à un serveur Kerberos ou à un serveur Active Directory. Cela permet au niveau de la sécurité :

  • d’utiliser les utilisateurs déclarés dans Active Directory ou Kerberos ;
  • de bénéficier de la politique de changement de mots de passe de ces services ;
  • d’avoir du SSO (Single Sign-On) pour les clients comme pgAdmin III.

Comme pour les autres méthodes d’authentification externe, il est nécessaire de configurer un mapping entre utilisateur externe (ici AD ou Kerberos) et utilisateur PostgreSQL, pour la configuration des droits (GRANT) et la propriété des objets. Cela permet de limiter les utilisateurs qui peuvent se logguer sur l’instance via ce service.

Cette documentation permet de configurer cette méthode pour une instance PostgreSQL sur un serveur Linux.

Configuration de Active Directory

Les opérations suivantes doivent être exécutées en ligne de commande avec les droits d’administrateur sur le serveur AD primaire ou non.

Il est nécessaire de créer un compte de machine pour le serveur qui héberge PostgreSQL, dans le domaine AD cible, par exemple pgsrv.

Ensuite, il faut créer un principal pour le service PostgreSQL associé au compte de la machine dans le domaine AD cible :

ktpass -out postgres.pgsrv.keytab -mapuser pgsrv -pass <password> -princ postgres/pgsrv.example.com@DOMAIN.AD -ptype KRB5_NT_PRINCIPAL

La machine (qui est un serveur Linux) doit pouvoir s’authentifier auprès de AD. Il faut qu’elle dispose d’un principal host, pour que AD la considère comme faisant partie du domaine :

setspn -A host/pgsrv.example.com pgsrv

Le fichier keytab postgres.pgsrv.keytab doit être copié sur le serveur PostgreSQL.

Configuration de Kerberos

Sur le serveur Kerberos, il faut créer un principal pour la machine PostgreSQL si ce n’est pas fait :

# kadmin -r EXAMPLE.COM
kadmin:  ank -randkey host/pgsrv
kadmin:  quit

Il faut créer un principal pour l’instance PostgreSQL :

# kadmin -r EXAMPLE.COM
kadmin:  ank -randkey postgres/pgsrv
kadmin:  quit

On peut alors créer un fichier keytab avec les deux entrées :

# kadmin -r EXAMPLE.COM
kadmin:  ktadd -k postgres.pgsrv.keytab host/pgsrv
kadmin:  ktadd -k postgres.pgsrv.keytab postgres/pgsrv
kadmin:  quit

Le fichier keytab postgres.pgsrv.keytab doit être copié sur le serveur PostgreSQL.

Configuration de PostgreSQL

Pré-requis

PostgreSQL doit être compilé avec le support de GSSAPIce qiu se fait en activant l’option --with-gssapi à la compilation. C’est le cas des paquets RPM et Debian du PGDG. La commande pg_config permet de le vérifier :

$ pg_config --configure

postgresql.conf

Le fichier keytab créé sur le serveur AD ou Kerberos doit être disponible en local sur le serveur PostgreSQL. L’utilisateur système qui lance l’instance (généralement postgres) doit avoir les droits de lecture sur ce fichier.

Le chemin peut être configuré dans la variable krb_server_keyfile du fichier postgresql.conf, par exemple :

krb_server_keyfile = '/var/lib/pgsql/9.4/data/postgres.pgsrv.keytab'

La valeur par défaut de krb_server_keyfile dépend de l’emplacement de sysconfdir (voir pg_config) :

  • sur Debian : /etc/postgresql-common/krb5.keytab ;
  • sur Red Hat (paquets PGDG) :/etc/sysconfig/pgsqlkrb5.keytab.

Il est recommandé de placer le fichier dans $PGDATA pour faciliter sa sauvegarde, par exemple, et empêcher l’accès aux autres utilisateurs que postgres.

pg_hba.conf

Le fichier pg_hba.conf doit être modifié pour indiquer quels clients devront s’authentifier avec un ticket kerberos, par exemple :

host   all    all    0.0.0.0/0    gss include_realm=1 map=ad

La méthode à utiliser est gss, les options sont les suivantes :

  • include_realm. À la valeur 1, le royaume (realm ou domaine AD) est passé au mapping configuré dans pg_ident.conf. Cela permet de faire une authentification multi domaine/royaume ;
  • krb_realm permet de forcer le domaine/royaume accepté ;
  • map indique le nom du mapping de pg_ident.conf à utiliser pour la correspondance des noms d’utilisateur AD/Kerberos et PostgreSQL.

Correspondance des noms d’utilisateur

Pour la gestion des propriétaires d’objets et des droits (GRANT), PostgreSQL doit disposer d’un utilisateur dans l’instance. En effet, il n’est pas relié à la source d’authentification externe, qui ne sert qu’à déléguer l’authentification.

Le fichier pg_ident.conf, permet de configurer des mappings ou correspondances entre utilisateur donné à l’authentification (compte AD ou Kerberos) et rôle de l’instance.

On créé pour cela le mapping suivant, il est possible de mettre des expressions régulières :

# L'utilisateur toto du domaine EXAMPLE.COM sera connecté en tant que postgres
ad    toto@EXAMPLE.COM       postgres

# Les utilisateurs du domaine EXAMPLE.COM seront connectés avec le même username
# Si le role correspondant n'existe pas, la connexion échoue
ad    /^(.*)@EXAMPLE\.COM$   \1

# Tous les utilisateurs du domaine EXAMPLE.COM seront connectés en tant que toto
#ad    /^(.*)@EXAMPLE\.COM$   toto

Connexion

Depuis un poste Windows dont l’utilisateur est loggué dans le domaine AD, l’authentification est transparente avec PgAdmin III.

Depuis une console Linux, il faut obtenir un ticket Kerberos, en utilisant l’outil kinit.

Conclusion

La configuration de l’authentification GSS est une méthode puissante et très sécurisée. Il faut cependant faire attention à plusieurs points :

  • Dans pg_hba.conf, il faut garder des authentifications avec des méthodes internes au cas où le service AD/Kerberos soit indisponible ;
  • Dans pg_ident.conf, les mappings associés aux rôles, bien configurés permettent de n’autoriser que certains utilisateurs à se connecter à l’instance.