Oracle Cloud Infrastructure - Dokumentation

LDAP für die Autorisierung verwenden

Erfahren Sie, wie Sie LDAP zur Autorisierung mit File Storage verwenden.

Sie können Lightweight Directory Access Protocol (LDAP) als Netzwerkinformationsservice verwenden, um Autorisierungsinformationen für den File Storage Service bereitzustellen. Die Verwendung von LDAP zur Bereitstellung von Autorisierungsinformationen bietet die folgenden Vorteile:

  • Zentrale Verwaltung von UNIX-Benutzern und -Gruppen.
  • Unterstützung für bis zu 256 UNIX-Gruppen. Wenn Sie LDAP für sekundäre UNIX-Gruppen aktivieren, anstatt die Gruppenliste zu verwenden, die im RPC-Header einer NFS-Anforderung bereitgestellt wird, unterliegt die Einschränkung AUTH_SYS auf 16 Gruppen nicht.
  • LDAP-Infrastruktur ist für die pro Benutzerauthentifizierung bei Verwendung von Kerberos erforderlich. LDAP ist nicht für alle Kerberos-Szenarios erforderlich, z.B. wenn der Export alle komprimiert.

Sekundärgruppensuche

File Storage-Dateisysteme autorisieren den Zugriff mit der UID/GID des NFS-Vorgangs und der Liste der sekundären UNIX-Gruppen. Standardmäßig verwendet AUTH_SYS die Gruppenliste, die im RPC-Header der NFS-Anforderung enthalten ist.

Wenn die LDAP-Autorisierung aktiviert ist, verwendet File Storage die UNIX-UID aus dem RPC-Header der NFS-Anforderung, um die Liste der sekundären UNIX-Gruppen für den AUTH_SYS-Zugriff vom LDAP-Server abzurufen. Die vorhandene GIDLIST im RPC-Header wird mit der GIDLIST vom LDAP-Server überschrieben. Durch das Abrufen sekundärer UNIX-Gruppen von einem LDAP-Server kann die Autorisierungsanforderung bis zu 256 Gruppen verwenden.

Wenn der sekundäre Gruppen-Lookup mit ID-Zuordnung aktiviert, aber nicht konfiguriert, falsch konfiguriert oder der LDAP-Service nicht verfügbar ist, kann File Storage die in der Anforderung verwendete sekundäre Gruppenliste nicht aktualisieren. Dies kann zu Berechtigungsfehlern führen.

NFS-Anforderungsszenarios für AUTH_SYS
LDAP für Gruppenliste aktiviert? LDAP-Response Squash exportieren aktiviert? NFS-Anforderung
Jeder Jeder Ja (alle)

Wenn Sie alle Elemente komprimieren, wird die Squash-UID und die Squash-GID in den Exportoptionen festgelegt.

Keine sekundäre Gruppenliste.
Jeder Jeder Ja (Wurzel)

Wenn Root gequetscht wird, wird die Squash-UID und die Squash-GID in den Exportoptionen nur dann festgelegt, wenn die UID 0 ist.

Keine sekundäre Gruppenliste.
Nein Nicht anwendbar Nein Erfolgt mit UID/GIDs aus RPC-Header.
Ja UID-Übereinstimmung Nein Verwendet die vom LDAP-Server abgerufene sekundäre Gruppenliste.
Ja Keine UID-Übereinstimmung oder LDAP-Fehler Nein Erfolgt mit UID/GIDs aus RPC-Header. Keine sekundäre Gruppenliste.
Wichtig

Um LDAP zur Autorisierung zu verwenden, müssen Sie LDAP aktivieren für das Mountziel und beim Export aktivieren.

Wenn Sie die Kerberos-Authentifizierung zusammen mit LDAP verwenden, ist das Verhalten etwas anders. Weitere Informationen finden Sie unter LDAP-Lookups und anonymer Zugriff.

Caching

File Storage verwendet ein speicherresidentes On-Demand-Caching-Modell, um Autorisierungsinformationen zu speichern, um die Performance zu erhöhen und die Last auf Ihrem LDAP-Server zu reduzieren.

Wenn eine NFS-Anforderung gestellt wird, wendet sich File Storage an den LDAP-Server, um Autorisierungsinformationen zu erhalten. File Storage speichert die Autorisierungsinformationen (positiv oder negativ) zur Verwendung in nachfolgenden NFS-Vorgängen im Cache.

Sie können mit den folgenden Optionen konfigurieren, wie lange File Storage diese Informationen cacht, wenn Sie ein Mountziel für LDAP konfigurieren:

  • Cacheaktualisierungsintervall in Sekunden: Gibt an, wie lange das Mountziel zulassen soll, dass ein Eintrag im Cache bleibt, bevor versucht wird, den Eintrag zu aktualisieren. Wählen Sie einen Wert, der die Auswirkungen auf die Sicherheit und eine akzeptable Last auf den LDAP-Server ausgleicht.
  • Cachelaufzeit in Sekunden: Die maximale Zeit, die das Mountziel für die Verwendung eines gecachten Eintrags verwenden darf. Wenn Cacheeinträge aufgrund von Last oder Fehlern in der Kundeninfrastruktur nicht rechtzeitig aktualisiert werden können, ist es sinnvoll, alte Einträge zu verwenden, bis die Konnektivität wiederhergestellt ist. Setzen Sie den Wert auf den längsten Zeitraum, den Sie bereit sind, einen veralteten Eintrag im LDAP-Cache zu haben, einschließlich Fällen, in denen der LDAP-Server aus irgendeinem Grund nicht verfügbar ist.
  • Lebensdauer des negativen Caches in Sekunden: Die Zeit, die ein Mountziel Informationen verwaltet, die ein Benutzer nicht in der ID-Zuordnungskonfiguration gefunden hat. Wenn ein Benutzer nicht in der LDAP-Datenbank gefunden wird, platziert das Mountziel einen Eintrag im Cache, der feststellt, dass der Benutzer nicht vorhanden ist. Wählen Sie einen Wert, der die Auswirkungen auf die Sicherheit und eine akzeptable Last auf den LDAP-Server ausgleicht.

Voraussetzungen

Anforderungen:

  • Vom Kunden verwaltete LDAP-Infrastruktur, einschließlich eines LDAP-Servers, der ein POSIX-Schema RFC2307 unterstützt. Die LDAP-Server können auf OpenLDAP oder Microsoft Active Directory basieren. Für die File Storage-Unterstützung des LDAP-Verzeichnisses ist möglicherweise eine benutzerdefinierte Konfiguration erforderlich.

  • Ein Anmeldekonto für den LDAP-Server, mit dem ein File Storage-Mountziel RFC2307-konforme Benutzer- und Gruppeninformationen suchen kann.

    • Der LDAP-Server muss die folgenden Benutzerattribute aufweisen:
      • ObjectClass: posixAccount - Diese Objektklasse stellt die folgenden Attribute für den Benutzer bereit.
      • uidNumber: UNIX-Benutzer-ID.
      • gidNumber: UNIX-Gruppen-ID der primären Gruppe des Benutzers.
      • uid - Der Benutzername für den Benutzer
    • Der LDAP-Server muss die folgenden Gruppenattribute aufweisen:
      • ObjectClass: posixGroup - Diese Objektklasse stellt die folgenden Attribute für die Gruppe bereit.
      • gidNumber - UNIX-Gruppen-ID für die Gruppe
      • memberUid: Das uid-Attribut der Benutzer, die Mitglieder dieser Gruppe sind. Dieses Attribut kann mehrmals hinzugefügt werden, um mehrere Benutzer in der Gruppe zu haben.
    Tipp

    Sie können auf LDAP-Schemaunterstützung testen.
  • Ein DNS-Server, mit dem das Mountziel Hostnamen einschließlich LDAP-Server suchen kann.
Diese Abbildung zeigt die vom Kunden verwaltete und von OCI verwaltete Infrastruktur, die für die LDAP-Autorisierung erforderlich ist.
  1. Kommunikation mit dem DNS-Service über TCP/UDP-Port 53.
  2. Kommunikation mit dem vom Kunden verwalteten LDAP-Service über den im ausgehenden Connector konfigurierten TCP-Port. Der Standardwert ist TCP-Port 636.
  3. Daten im Ruhezustand in File Storage verschlüsselt.

LDAP-Infrastruktur

File Storage erfordert einen ausgehenden Connector, damit Mountziele mit einem LDAP-Server auf seinem LDAPS-Port kommunizieren können. Für den ausgehenden Connector müssen Sie den vollqualifizierten Domainnamen (FQDN) des LDAP-Servers, einen Bind-Benutzernamen und ein Kennwort für den LDAP-Server sowie die Suchbasis für Benutzer und Gruppen angeben.

Damit File Storage den LDAP-Server erreichen kann, stellen Sie Folgendes sicher:

  • Die Firewall des LDAP-Servers muss eingehenden Datenverkehr vom File Storage-Mountziel mit TCP 636 zulassen (Standard).
  • Alle verwendeten Sicherheitslisten und NSGs müssen das Mountziel und den LDAP-Servertraffic zulassen.
  • DNS ist für das Mountziel und die Clients zum Auflösen des Hostnamens konfiguriert. Zu den DNS-Konfigurationsoptionen zählen:
    • OCI-DNS mit Standardauflösung und Hostnamen in Ihrem VCN verwenden - Diese Option bietet nicht die Flexibilität benutzerdefinierter DNS-Namen. Hostnamen enden mit oraclevcn.com mit Subdomains für VCN und Subnetz. Weitere Informationen finden Sie unter DNS im virtuellen Cloud-Netzwerk.
    • OCI Private DNS mit privaten Zonen verwenden - DNS-Zonen für eine benutzerdefinierte Domain werden in OCI DNS gehostet. Mit dieser Option ist es nicht erforderlich, Ihren eigenen DNS-Server zu verwalten, da OCI DNS vollständig verwaltet. Sie müssen die Zonen und Datensätze verwalten. Weitere Informationen finden Sie unter Privates DNS.
    • Vom Kunden verwalteten DNS-Server verwenden - Wählen Sie beim Erstellen eines VCN nicht die Option DNS-Hostnamen in diesem VCN verwenden aus. Konfigurieren Sie stattdessen das VCN so, dass Ihr eigener DNS-Server mit einer der folgenden Methoden verwendet wird:
      1. Konfigurieren Sie die DHCP-Optionen im Subnetz so, dass ein vom Kunden verwalteter DNS-Server verwendet wird.
      2. Verwenden Sie den VCN-Resolver mit einem Weiterleitungsendpunkt und einer Weiterleitungsregel, damit DNS-Abfragen im VCN an einen vom Kunden verwalteten DNS-Server weitergeleitet werden.

File Storage unterstützt SSLv2-, SSLv3-, TLSv1- oder TLSv1.1-Autorisierung nicht. File Storage unterstützt die folgenden OpenSSL-Cipher Suites für die LDAPS-Autorisierung:

  • DHE-DSS-AES128-GCM-SHA256
  • DHE-DSS-AES256-GCM-SHA384
  • DHE-RSA-AES128-GCM-SHA256
  • DHE-RSA-AES256-GCM-SHA384
  • ECDHE-ECDSA-AES128-GCM-SHA256
  • ECDHE-ECDSA-AES256-GCM-SHA384
  • ECDHE-RSA-AES128-GCM-SHA256
  • ECDHE-RSA-AES256-GCM-SHA384
  • TLS_AES_128_CCM_SHA256
  • TLS_AES_128_GCM_SHA256
  • TLS_AES_256_GCM_SHA384

Unterstützung für LDAP-Schema testen

Mit den folgenden Beispielabfragen können Sie sicherstellen, dass File Storage RFC2307-konforme Benutzer- und Gruppeninformationen von einem LDAP-Server mit einer unterstützten Konfiguration suchen kann.

ldapsearch -b <user_searchbase> -H ldaps://<ldaps_server_fqdn>:<ldaps_port> -D <bind_DN> -W -s sub '(&(objectClass=posixAccount)(uid=<username>))' uidNumber gidNumber
Beispiel für eine Abfrageausgabe
$ ldapsearch -b 'ou=Users,dc=nfs_kerberos,dc=fss_test,dc=com' -H 'ldaps://example.com:636' -D 'cn=admin,dc=fss_test,dc=com' -W -s sub '(&(objectClass=posixAccount)(uid=root))' uidNumber gidNumber
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base <ou=Users,dc=nfs_kerberos,dc=fss_test,dc=com> with scope subtree
# filter: (&(objectClass=posixAccount)(uid=root))
# requesting: uidNumber gidNumber
#

# root, Users, nfs_kerberos.fss_test.com
dn: uid=root,ou=Users,dc=nfs_kerberos,dc=fss_test,dc=com
gidNumber: 0
uidNumber: 0

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1
ldapsearch -b <user_searchbase> -H ldaps://<ldaps_server_fqdn>:<ldaps_port> -D <bind_DN> -W -s sub '(&(objectClass=posixAccount)(uidNumber=<user_uid>))' uid gidNumber
Beispiel für eine Abfrageausgabe
$ ldapsearch -b 'ou=Users,dc=nfs_kerberos,dc=fss_test,dc=com' -H 'ldaps://example.com:636' -D 'cn=admin,dc=fss_test,dc=com' -W -s sub '(&(objectClass=posixAccount)(uidNumber=0))' uid gidNumber
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base <ou=Users,dc=nfs_kerberos,dc=fss_test,dc=com> with scope subtree
# filter: (&(objectClass=posixAccount)(uidNumber=0))
# requesting: uid gidNumber
#
# root, Users, nfs_kerberos.fss_test.com
dn: uid=root,ou=Users,dc=nfs_kerberos,dc=fss_test,dc=com
gidNumber: 0
uid: root
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
ldapsearch -b <group_searchbase> -H ldaps://<ldaps_server_fqdn>:<ldaps_port> -D <bind_DN> -W -s sub '(&(objectClass=posixGroup)(memberuid=<username>))' gidNumber
Beispiel für eine Abfrageausgabe
$ ldapsearch -b 'ou=Groups,dc=nfs_kerberos,dc=fss_test,dc=com' -H 'ldaps://example.com:636' -D 'cn=admin,dc=fss_test,dc=com' -W -s sub '(&(objectClass=posixGroup)(memberuid=root))' gidNumber
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base <ou=Groups,dc=nfs_kerberos,dc=fss_test,dc=com> with scope subtree
# filter: (&(objectClass=posixGroup)(memberuid=root))
# requesting: gidNumber
#
# root, Groups, nfs_kerberos.fss_test.com
dn: cn=root,ou=Groups,dc=nfs_kerberos,dc=fss_test,dc=com
gidNumber: 0
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
Tipp

Sie können Alarme basierend auf Dateisystemmetriken erstellen, mit denen Sie LDAP-Konnektivitätsprobleme schnell erkennen und diagnostizieren können.

Überwachung und Alarme

Bei der Verwendung von LDAP ist es wichtig, schnell auf ein Problem aufmerksam zu werden. Wenn die LDAP-Infrastruktur nicht ordnungsgemäß funktioniert, können NFS-Clients den Zugriff auf File Storage-Dateisysteme verlieren, die über ihre Exporte verfügbar gemacht werden. Um solche Probleme zu erkennen, wird empfohlen, Alarme für Metriken des Mountziels festzulegen. Alarme können Sie innerhalb weniger Minuten auf Infrastrukturprobleme aufmerksam machen.

Alarme, die auf LDAP-Verbindungsfehler und LDAP-Anforderungsfehler basieren, erkennen Konnektivitätsprobleme zwischen Mountzielen, ausgehenden Connectors und der vom Kunden verwalteten LDAP-Infrastruktur.

Mit der folgenden Beispielabfrage können Sie einen Alarm für die LDAP-Konnektivität erstellen:

LdapConnectionErrors[1m]{resourceType = "outboundconnector", mtResourceName = "<mount_target_name>", errorType != "success"}.max() >= 1

Weitere Informationen zu Monitoringmetriken und zur Verwendung von Alarmen finden Sie in Überblick über Monitoring. Informationen zu Benachrichtigungen für Alarme finden Sie unter Überblick über Benachrichtigungen.

Erforderliche IAM-Policy

File Storage muss auf Vault Secrets mit LDAP-Serverkennwort zugreifen. Sowohl der Benutzer, der das Mountziel konfiguriert, als auch das Mountziel selbst benötigen Lesezugriff.

Wichtig

Diese Policys müssen erstellt werden, bevor Sie Mountziele für die Verwendung von LDAP zur Autorisierung konfigurieren können.

Policy zum Verwalten von Vault Secrets

Erteilen Sie dem Benutzer oder der Gruppe, der die Vault Secret-Berechtigungen erstellt. Weitere Informationen finden Sie unter Vault-Secrets verwalten.

Policy zum Aktivieren der Mountzielkonfiguration

Erteilen Sie dem Benutzer oder der Gruppe, der LDAP auf einem Mountziel konfiguriert, Berechtigungen mit einer Policy wie der folgenden:

allow <user|group> to read secret-family in compartment <Compartment_ID> where any { target.secret.id = <LDAP_Password_Secret_ID> }

Auf diese Weise kann der Benutzer File Storage-Befehle absetzen, die Vault Secrets lesen und Teile des Secrets zur Validierung während der Konfiguration anzeigen.

Policy, mit der ein Mountziel Secrets abrufen kann

Der File Storage-Service erfordert die Möglichkeit, die Secrets zu lesen. File Storage verwendet Resource Principals, um einem bestimmten Set von Mountzielen Zugriff auf das Vault Secret zu erteilen. Dies ist ein zweistufiger Prozess. Zuerst müssen die Mountziele, die Zugriff benötigen, in eine dynamische Gruppe gestellt werden, und dann erhält die dynamische Gruppe Zugriff auf das Lesen der Secrets.

  1. Erstellen Sie eine dynamische Gruppe für die Mountziele mit einer Policy wie der folgenden:

    ALL { resource.type='mounttarget', resource.compartment.id = '<mount_target_compartment_id>' }
    Hinweis

    Wenn die dynamische Gruppe mehrere Regeln enthält, müssen Sie die Option Match any rules defined below verwenden.

  2. Erstellen Sie eine IAM-Policy, die der dynamischen Gruppe von Mountzielen Lesezugriff auf Vault Secrets erteilt:

     allow dynamic-group <dynamic_group_name> to read secret-family in compartment <secret_compartment_name>