Présentation d'Active Directory

Sélectionnez une version de la documentation :

Cette page explique comment PostgreSQL s'intègre à Active Directory dans AlloyDB Omni à l'aide de l'interface de programmation d'application Generic Security Services (GSSAPI). Elle présente également les principaux concepts Kerberos. Kerberos est le protocole d'authentification qui alimente Active Directory.

Active Directory est un service d'annuaire développé par Microsoft pour les réseaux de domaine Windows. Active Directory est un système centralisé et standardisé qui automatise la gestion réseau des données utilisateur, de la sécurité et des ressources distribuées. Ce service d'annuaire fournit un point d'administration unique pour les comptes utilisateur, les groupes et les autres objets réseau. L'authentification est une fonction clé d'Active Directory. Elle confirme l'identité et l'autorisation d'un utilisateur, et lui accorde l'accès à des ressources spécifiques sur le réseau.

Composants Active Directory

Un royaume est le domaine administratif pour l'authentification Kerberos. Dans le contexte d'Active Directory, un domaine est équivalent à un domaine Active Directory. Les domaines représentent un groupe logique d'utilisateurs, d'ordinateurs et de services qui partagent une base de données d'authentification commune. Lorsque vous configurez Kerberos, vous devez spécifier le domaine auquel appartiennent vos clients et services. Un domaine est une version en majuscules du nom de domaine. Par exemple, si le domaine est ad.example.com, le domaine est AD.EXAMPLE.COM.

Le centre de distribution de clés (KDC, Key Distribution Center) est un service Kerberos essentiel qui s'exécute sur chaque contrôleur de domaine dans Active Directory. Le KDC a les fonctions principales suivantes :

  • Service d'authentification (AS) : vérifie l'identité d'un utilisateur lors de la connexion initiale (par exemple, lorsque vous vous connectez à Windows) et émet un ticket d'octroi de ticket (TGT).
  • Service d'octroi de tickets (TGS, Ticket-Granting Service) : émet des tickets de service pour les utilisateurs authentifiés qui présentent un TGT valide. Ces demandes d'assistance permettent d'accéder à des services spécifiques, comme une base de données PostgreSQL.

Un principal est une identité unique dans un domaine Kerberos auquel des tickets peuvent être attribués. Voici les principaux types de comptes principaux :

  • Principaux d'utilisateur : représentent des utilisateurs humains (par exemple, username@REALM).
  • Les comptes principaux de service (SPN) représentent un service spécifique sur un hôte spécifique (par exemple, postgres/db-server.ad.example.com@REALM). Pour qu'un client puisse demander un ticket de service pour votre base de données, le service de base de données doit disposer d'un SPN enregistré.

Un fichier keytab ou table clé contient une liste de comptes principaux et de leurs clés secrètes correspondantes, qui sont dérivées des mots de passe des comptes principaux. Les services utilisent un fichier keytab pour prouver leur identité au KDC et pour déchiffrer les tickets de service présentés par les clients.

Cette approche permet à un service tel que PostgreSQL de s'authentifier auprès du système Kerberos sans nécessiter d'interaction humaine ni stocker de mot de passe en texte brut sur le serveur. Le fichier keytab est très sensible et doit être stocké et protégé de manière sécurisée.

Intégration de PostgreSQL à Active Directory

L'intégration de PostgreSQL à Active Directory vous permet de centraliser la gestion des utilisateurs en fonction des identités d'entreprise, ce qui renforce la sécurité de votre base de données.

Pour prendre en charge l'authentification, PostgreSQL propose les méthodes suivantes pour l'intégration à Active Directory :

  • LDAP (Lightweight Directory Access Protocol) : vous pouvez configurer PostgreSQL pour authentifier les utilisateurs sur un serveur Active Directory à l'aide du protocole LDAP. Lorsqu'un utilisateur tente de se connecter à la base de données, PostgreSQL communique avec le serveur Active Directory via LDAP pour valider les identifiants de l'utilisateur, qui sont généralement un nom d'utilisateur et un mot de passe. Cette méthode utilise Active Directory comme fournisseur d'authentification externe.

  • Generic Security Services Application Program Interface (GSSAPI) avec Kerberos : il s'agit d'une méthode plus sécurisée et complexe qui utilise le protocole Kerberos, qui est le mécanisme d'authentification par défaut dans Active Directory. GSSAPI fournit une interface standard permettant aux applications d'accéder aux services de sécurité.

Bien que LDAP et GSSAPI permettent tous deux d'intégrer Active Directory, GSSAPI avec Kerberos est l'approche la plus sécurisée et la plus robuste pour les environnements d'entreprise en raison de son authentification cryptographique forte basée sur des tickets. Cette page explique comment implémenter l'intégration Active Directory pour AlloyDB Omni à l'aide de la méthode GSSAPI.

Authentification Active Directory avec GSSAPI

AlloyDB Omni vous permet de vous authentifier via Kerberos à l'aide d'Active Directory comme backend d'authentification. Les étapes à suivre pour l'authentification sont illustrées dans le schéma suivant.

image

  1. Le client psql lance une demande d'authentification à l'aide du service d'authentification (AS) dans le centre de distribution de clés (KDC).
  2. L'AS authentifie le client et lui émet un ticket d'octroi de droits (TGT) (T1). Le TGT est ensuite utilisé pour demander des tickets de service.
  3. Le client utilise le TGT pour demander un ticket de service au service d'octroi de tickets (TGS) du KDC pour le service PostgreSQL. Le client demande désormais l'accès au serveur PostgreSQL spécifique.
  4. Le TGS valide le TGT et émet un ticket de service (T2) pour le client. Ce ticket contient une clé de session (T3) et est chiffré à l'aide de la clé secrète du serveur PostgreSQL.
  5. Le client envoie le ticket de service chiffré (T2) au serveur PostgreSQL.
  6. Le serveur PostgreSQL utilise sa clé (à partir de son fichier keytab) pour déchiffrer le ticket de service (T2). Il récupère ensuite la clé de session (T3) et vérifie l'authenticité du ticket. Si cette opération réussit, le serveur accorde l'accès et établit un canal de communication sécurisé avec le client à l'aide de la clé de session.

Étapes suivantes