Active Directory – Übersicht

Wählen Sie eine Dokumentationsversion aus:

Auf dieser Seite wird beschrieben, wie PostgreSQL in AlloyDB Omni mithilfe der Generic Security Services Application Programming Interface (GSSAPI) in Active Directory eingebunden wird. Außerdem werden wichtige Kerberos-Konzepte vorgestellt. Kerberos ist das Authentifizierungsprotokoll, das Active Directory zugrunde liegt.

Active Directory ist ein von Microsoft für Windows-Domänennetzwerke entwickelter Verzeichnisdienst. Active Directory ist ein zentralisiertes, standardisiertes System, das die Netzwerkverwaltung von Nutzerdaten, Sicherheit und verteilten Ressourcen automatisiert. Dieser Verzeichnisdienst bietet einen zentralen Verwaltungspunkt für Nutzerkonten, Gruppen und andere Netzwerkobjekte. Eine wichtige Funktion von Active Directory ist die Authentifizierung, bei der die Identität und Autorisierung eines Nutzers bestätigt und dem Nutzer Zugriff auf bestimmte Ressourcen im Netzwerk gewährt wird.

Active Directory-Komponenten

Ein Realm ist die administrative Domain für die Kerberos-Authentifizierung. Im Kontext von Active Directory entspricht ein Realm einer Active Directory-Domain. Realms stellen eine logische Gruppe von Nutzern, Computern und Diensten dar, die eine gemeinsame Authentifizierungsdatenbank verwenden. Wenn Sie Kerberos konfigurieren, müssen Sie die Realm angeben, zu der Ihre Clients und Dienste gehören. Ein Bereich ist eine Version des Domainnamens in Großbuchstaben. Wenn die Domain beispielsweise ad.example.com ist, lautet der Bereich AD.EXAMPLE.COM.

Das Key Distribution Center (KDC) ist ein wichtiger Kerberos-Dienst, der auf jedem Domaincontroller in Active Directory ausgeführt wird. Das KDC hat die folgenden primären Funktionen:

  • Authentifizierungsdienst (Authentication Service, AS): überprüft die Identität eines Nutzers bei der ersten Anmeldung, z. B. wenn Sie sich bei Windows anmelden, und stellt ein Ticket-Granting Ticket (TGT) aus.
  • Ticket-Granting Service (TGS): stellt Diensttickets für authentifizierte Nutzer aus, die ein gültiges TGT vorlegen. Mit diesen Service-Tickets wird der Zugriff auf bestimmte Dienste wie eine PostgreSQL-Datenbank gewährt.

Ein Prinzipal ist eine eindeutige Identität in einem Kerberos-Bereich, dem Tickets zugewiesen werden können. Die wichtigsten Arten von Hauptkonten sind:

  • Nutzer-Principals: stellen menschliche Nutzer dar, z. B. username@REALM.
  • Service-Principals (SPN): Sie stellen einen bestimmten Dienst auf einem bestimmten Host dar, z. B. postgres/db-server.ad.example.com@REALM. Damit ein Kunde ein Serviceticket für Ihre Datenbank anfordern kann, muss für den Datenbankdienst ein SPN registriert sein.

Eine Keytab- oder Schlüsseltabellendatei enthält eine Liste von Principals und den entsprechenden geheimen Schlüsseln, die aus den Passwörtern der Principals abgeleitet werden. Dienste verwenden eine Keytab-Datei, um ihre Identität gegenüber dem KDC nachzuweisen und von Clients präsentierte Diensttickets zu entschlüsseln.

Mit diesem Ansatz kann sich ein Dienst wie PostgreSQL beim Kerberos-System authentifizieren, ohne dass ein menschliches Eingreifen erforderlich ist oder ein Klartextpasswort auf dem Server gespeichert werden muss. Die Keytab-Datei ist sehr sensibel und muss sicher gespeichert und geschützt werden.

PostgreSQL-Integration in Active Directory

Durch die Integration von PostgreSQL in Active Directory erhalten Sie eine zentrale Nutzerverwaltung auf Grundlage von Unternehmensidentitäten, was die Sicherheit Ihrer Datenbank erhöht.

Zur Unterstützung der Authentifizierung bietet PostgreSQL die folgenden Methoden für die Integration in Active Directory:

  • Lightweight Directory Access Protocol (LDAP): Sie können PostgreSQL so konfigurieren, dass Nutzer mithilfe des LDAP-Protokolls auf einem Active Directory-Server authentifiziert werden. Wenn ein Nutzer versucht, eine Verbindung zur Datenbank herzustellen, kommuniziert PostgreSQL über LDAP mit dem Active Directory-Server, um die Anmeldedaten des Nutzers zu überprüfen. Diese bestehen in der Regel aus einem Nutzernamen und einem Passwort. Bei dieser Methode wird Active Directory als externer Authentifizierungsanbieter verwendet.

  • Generic Security Services Application Program Interface (GSSAPI) mit Kerberos: Dies ist eine sicherere und komplexere Methode, bei der das Kerberos-Protokoll verwendet wird. Das Kerberos-Protokoll ist der Standardauthentifizierungsmechanismus in Active Directory. GSSAPI bietet eine Standardschnittstelle für Anwendungen, um auf Sicherheitsdienste zuzugreifen.

Sowohl LDAP als auch GSSAPI ermöglichen die Active Directory-Integration. GSSAPI mit Kerberos ist jedoch aufgrund der starken, ticketbasierten kryptografischen Authentifizierung der sicherere und robustere Ansatz für Unternehmensumgebungen. Auf dieser Seite wird die Implementierung der Active Directory-Integration für AlloyDB Omni mit der GSSAPI-Methode behandelt.

Active Directory-Authentifizierung mit GSSAPI

Mit AlloyDB Omni können Sie sich über Kerberos authentifizieren und Active Directory als Authentifizierungs-Backend verwenden. Die Schritte zur Authentifizierung sind im folgenden Diagramm dargestellt.

Image

  1. Der Client psql initiiert eine Authentifizierungsanfrage über den Authentifizierungsdienst (Authentication Service, AS) im Key Distribution Center (KDC).
  2. Der AS authentifiziert den Client und stellt ihm ein Ticket-Granting-Ticket (TGT) (T1) aus. Das TGT wird dann verwendet, um Diensttickets anzufordern.
  3. Der Client verwendet das TGT, um ein Dienstticket vom Ticket-Granting Service (TGS) im KDC für den PostgreSQL-Dienst anzufordern. Der Client fordert nun Zugriff auf den spezifischen PostgreSQL-Server an.
  4. Der TGS validiert das TGT und stellt dem Client ein Serviceticket (T2) aus. Dieses Ticket enthält einen Sitzungsschlüssel (T3) und wird mit dem geheimen Schlüssel des PostgreSQL-Servers verschlüsselt.
  5. Der Client sendet das verschlüsselte Serviceticket (T2) an den PostgreSQL-Server.
  6. Der PostgreSQL-Server verwendet seinen Schlüssel (aus seiner Keytab-Datei), um das Dienstticket (T2) zu entschlüsseln. Anschließend ruft der Server den Sitzungsschlüssel (T3) ab und überprüft die Authentizität des Tickets. Wenn dieser Vorgang erfolgreich ist, gewährt der Server Zugriff und richtet mit dem Sitzungsschlüssel einen sicheren Kommunikationskanal mit dem Client ein.

Nächste Schritte