Grundlegendes zur Verwendung von LDAP mit Azure NetApp Files

  • Artikel

Das Lightweight Directory Access Protocol (LDAP) ist ein Standardverzeichniszugriffsprotokoll, das von einem internationalen Ausschuss namens Internet Engineering Task Force (IETF) entwickelt wurde. LDAP soll einen allgemeinen, netzwerkbasierten Verzeichnisdienst bereitstellen, den Sie auf heterogenen Plattformen verwenden können, um Netzwerkobjekte zu finden.

LDAP-Modelle definieren die Kommunikation mit dem LDAP-Verzeichnisspeicher, das Suchen eines Objekts im Verzeichnis, die Beschreibung der Objekte im Speicher und die Sicherheit, die für den Zugriff auf das Verzeichnis verwendet wird. LDAP ermöglicht die Anpassung und Erweiterung der im Speicher beschriebenen Objekte. Daher können Sie einen LDAP-Speicher verwenden, um viele Arten verschiedener Informationen zu speichern. Viele der anfänglichen LDAP-Bereitstellungen konzentrierten sich auf die Verwendung von LDAP als Verzeichnisspeicher für Anwendungen wie E-Mail und Webanwendungen und zum Speichern von Mitarbeiterinformationen. Viele Unternehmen ersetzen oder haben Network Information Service (NIS) durch LDAP als Netzwerkverzeichnisspeicher ersetzt.

Ein LDAP-Server stellt UNIX-Benutzer- und Gruppenidentitäten für die Verwendung mit NAS-Volumes bereit. In Azure NetApp Files ist Active Directory der einzige derzeit unterstützte LDAP-Server, der verwendet werden kann. Dieser Support umfasst sowohl Active Directory-Domäne Dienste (AD DS) als auch Microsoft Entra Do Standard Services.

LDAP-Anforderungen können in zwei Standard Vorgänge unterteilt werden.

  • LDAP-Bindungen sind Anmeldungen an den LDAP-Server von einem LDAP-Client. Die Bindung wird verwendet, um sich beim LDAP-Server mit schreibgeschütztem Zugriff auf LDAP-Nachschlagevorgänge zu authentifizieren. Azure NetApp Files fungiert als LDAP-Client.
  • LDAP-Nachschlagevorgänge werden verwendet, um das Verzeichnis nach Benutzer- und Gruppeninformationen abzufragen, z. B. Namen, numerische IDs, Heimverzeichnispfade, Anmeldeshellpfade, Gruppenmitgliedschaften und vieles mehr.

LDAP kann die folgenden Informationen speichern, die im Dualprotokoll-NAS-Zugriff verwendet werden:

  • Benutzernamen
  • Gruppennamen
  • Numerische Benutzer-IDs (UIDs) und Gruppen-IDs (GIDs)
  • Basisverzeichnisse
  • Anmeldeshell
  • Netgroups, DNS-Namen und IP-Adressen
  • Gruppenmitgliedschaft

Derzeit verwendet Azure NetApp Files nur LDAP für Benutzer- und Gruppeninformationen – keine Netgroup- oder Hostinformationen.

LDAP bietet verschiedene Vorteile für Ihre UNIX-Benutzer und -Gruppen als Identitätsquelle.

  • LDAP ist zukunftssicher.
    Da weitere NFS-Clients Unterstützung für NFSv4.x hinzufügen, sind NFSv4.x ID do Standard s, die eine aktuelle Liste der Benutzer und Gruppen enthalten, auf die von Clients und Speicher zugegriffen werden kann, erforderlich, um eine optimale Sicherheit und garantierten Zugriff sicherzustellen, wenn der Zugriff definiert ist. Ein Identitätsverwaltungsserver, der 1:1-Namenszuordnungen für SMB- und NFS-Benutzer bereitstellt, vereinfacht die Lebensdauer von Speicheradministratoren erheblich, nicht nur in der Gegenwart, sondern seit Jahren.
  • LDAP ist skalierbar.
    LDAP-Server bieten die Möglichkeit, Millionen von Benutzer- und Gruppenobjekten zu enthalten, und mit Microsoft Active Directory können mehrere Server verwendet werden, um mehrere Standorte für die Leistungs- und Ausfallsicherheitsskala zu replizieren.
  • LDAP ist sicher.
    LDAP bietet Sicherheit in Form, wie ein Speichersystem eine Verbindung mit dem LDAP-Server herstellen kann, um Anforderungen für Benutzerinformationen zu stellen. LDAP-Server bieten die folgenden Bindungsebenen:
    • Anonym (standardmäßig in Microsoft Active Directory deaktiviert; in Azure NetApp-Dateien nicht unterstützt)
    • Einfaches Kennwort (Nur-Text-Kennwörter; in Azure NetApp-Dateien nicht unterstützt)
    • Simple Authentication and Security Layer (SASL) – Verschlüsselte Bindungsmethoden wie TLS, SSL, Kerberos usw. Azure NetApp Files unterstützt LDAP über TLS, LDAP-Signatur (mit Kerberos), LDAP über SSL.
  • LDAP ist robust.
    NIS, NIS+ und lokale Dateien bieten grundlegende Informationen wie UID, GID, Kennwort, Heimverzeichnisse usw. LDAP bietet jedoch diese Attribute und vieles mehr. Die zusätzlichen Attribute, die LDAP verwendet, machen die Dualprotokollverwaltung im Vergleich zu NIS wesentlich stärker in LDAP integriert. Nur LDAP wird als externer Namensdienst für die Identitätsverwaltung mit Azure NetApp Files unterstützt.
  • Microsoft Active Directory basiert auf LDAP.
    Standardmäßig verwendet Microsoft Active Directory ein LDAP-Back-End für seine Benutzer- und Gruppeneinträge. Diese LDAP-Datenbank enthält jedoch keine UNIX-Stilattribute. Diese Attribute werden hinzugefügt, wenn das LDAP-Schema über Identity Management for UNIX (Windows 2003R2 und höher), Service for UNIX (Windows 2003 und früher) oder LDAP-Tools von Drittanbietern wie Centrify erweitert wird. Da Microsoft LDAP als Back-End verwendet, ist LDAP die perfekte Lösung für Umgebungen, die sich für die Nutzung von Dualprotokollvolumes in Azure NetApp Files entscheiden.

    Hinweis

    Azure NetApp Files unterstützt derzeit nur native Microsoft Active Directory für LDAP-Dienste.

LDAP-Grundlagen in Azure NetApp-Dateien

Im folgenden Abschnitt werden die Grundlagen von LDAP im Zusammenhang mit Azure NetApp Files erläutert.

  • LDAP-Informationen werden in Flachdateien auf einem LDAP-Server gespeichert und über ein LDAP-Schema organisiert. Sie sollten LDAP-Clients so konfigurieren, dass sie ihre Anforderungen und Nachschlagevorgänge mit dem Schema auf dem LDAP-Server koordinieren.

  • LDAP-Clients initiieren Abfragen über eine LDAP-Bindung, bei der es sich im Wesentlichen um eine Anmeldung beim LDAP-Server handelt, indem ein Konto verwendet wird, das Lesezugriff auf das LDAP-Schema hat. Die LDAP-Bindungskonfiguration auf den Clients ist so konfiguriert, dass der vom LDAP-Server definierte Sicherheitsmechanismus verwendet wird. Manchmal sind sie Benutzername und Kennwortaustausch in Nur-Text (einfach). In anderen Fällen werden Bindungen über einfache Authentifizierungs- und Sicherheitsschichtmethoden (sasl) wie Kerberos oder LDAP über TLS gesichert. Azure NetApp Files verwendet das SMB-Computerkonto, um die SASL-Authentifizierung für die bestmögliche Sicherheit zu binden.

  • Benutzer- und Gruppeninformationen, die in LDAP gespeichert sind, werden von Clients mithilfe standardmäßiger LDAP-Suchanforderungen abgefragt, wie in RFC 2307 definiert. Darüber hinaus ermöglichen neuere Mechanismen wie RFC 2307bis optimierte Benutzer- und Gruppensuche. Azure NetApp Files verwendet eine Form von RFC 2307bis für seine Schemasuche in Windows Active Directory.

  • LDAP-Server können Benutzer- und Gruppeninformationen und Netgroup speichern. Azure NetApp Files kann jedoch derzeit keine Netgroup-Funktionalität in LDAP unter Windows Active Directory verwenden.

  • LDAP in Azure NetApp Files funktioniert auf Port 389. Dieser Port kann derzeit nicht geändert werden, um einen benutzerdefinierten Port zu verwenden, z. B. Port 636 (LDAP über SSL) oder Port 3268 (Active Directory Global Catalog-Suchvorgänge).

  • Verschlüsselte LDAP-Kommunikationen können mit LDAP über TLS (betrieben über Port 389) oder LDAP-Signierung erreicht werden, die beide für die Active Directory-Verbindung konfiguriert werden können.

  • Azure NetApp Files unterstützt LDAP-Abfragen, die nicht länger als 3 Sekunden dauern. Wenn der LDAP-Server über viele Objekte verfügt, kann dieses Timeout überschritten werden, und Authentifizierungsanforderungen können fehlschlagen. In diesen Fällen sollten Sie einen LDAP-Suchbereich angeben, um Abfragen nach einer besseren Leistung zu filtern.

  • Azure NetApp Files unterstützt auch die Angabe bevorzugter LDAP-Server, um Anforderungen zu beschleunigen. Verwenden Sie diese Einstellung, wenn Sie sicherstellen möchten, dass der LDAP-Server, der Ihrem Azure NetApp Files-Bereich am nächsten ist, verwendet wird.

  • Wenn kein bevorzugter LDAP-Server festgelegt ist, wird der Active Standard Directory-Name in DNS für LDAP-Diensteinträge abgefragt, um die Liste der LDAP-Server aufzufüllen, die für Ihre Region in diesem SRV-Eintrag verfügbar sind. Sie können LDAP-Diensteinträge in DNS manuell mithilfe nslookup oder dig Befehle von einem Client abfragen.

    Beispiel:

    C:\>nslookup
Default Server:  localhost
Address:  ::1

> set type=SRV
> _ldap._tcp.contoso.com.

Server:  localhost
Address:  ::1

_ldap._tcp.contoso.com   SRV service location:
          priority       = 0
          weight         = 0
          port           = 389
          svr hostname   = oneway.contoso.com
_ldap._tcp.contoso.com   SRV service location:
          priority       = 0
          weight         = 100
          port           = 389
          svr hostname   = ONEWAY.Contoso.com
_ldap._tcp.contoso.com   SRV service location:
          priority       = 0
          weight         = 100
          port           = 389
          svr hostname   = oneway.contoso.com
_ldap._tcp.contoso.com   SRV service location:
          priority       = 0
          weight         = 100
          port           = 389
          svr hostname   = parisi-2019dc.contoso.com
_ldap._tcp.contoso.com   SRV service location:
          priority       = 0
          weight         = 100
          port           = 389
          svr hostname   = contoso.com
oneway.contoso.com       internet address = x.x.x.x
ONEWAY.Contoso.com       internet address = x.x.x.x
oneway.contoso.com       internet address = x.x.x.x
parisi-2019dc.contoso.com        internet address = y.y.y.y
contoso.com      internet address = x.x.x.x
contoso.com      internet address = y.y.y.y

  • LDAP-Server können auch zum Ausführen einer benutzerdefinierten Namenszuordnung für Benutzer verwendet werden. Weitere Informationen finden Sie unter Benutzerdefinierte Namenszuordnung mithilfe von LDAP.

  • LDAP-Abfragetimeouts

    Standardmäßig timeouts für LDAP-Abfragen, wenn sie nicht rechtzeitig abgeschlossen werden können. Wenn eine LDAP-Abfrage aufgrund eines Timeouts fehlschlägt, schlägt die Benutzer- und/oder Gruppensuche fehl, und der Zugriff auf das Azure NetApp Files-Volume wird je nach Berechtigungseinstellungen des Volumes möglicherweise verweigert. Informationen zum Erstellen und Verwalten von Active Directory-Verbindungen finden Sie unter Azure NetApp Files LDAP-Abfragetimeouteinstellungen.

Namenszuordnungstypen

Namenzuordnungsregeln können in zwei Standard Typen unterteilt werden: symmetrisch und asymmetrisch.

  • Die symmetrische Namenszuordnung ist die implizite Namenszuordnung zwischen UNIX- und Windows-Benutzern, die denselben Benutzernamen verwenden. Windows-Benutzer CONTOSO\user1 ordnet z. B. UNIX-Benutzer user1zu.
  • Die asymmetrische Namenszuordnung ist die Namenszuordnung zwischen UNIX- und Windows-Benutzern, die unterschiedliche Benutzernamen verwenden. Windows-Benutzer CONTOSO\user1 ordnet z. B. UNIX-Benutzer user2zu.

Standardmäßig verwendet Azure NetApp Files symmetrische Namenszuordnungsregeln. Wenn asymmetrische Namenszuordnungsregeln erforderlich sind, sollten Sie die LDAP-Benutzerobjekte so konfigurieren, dass sie verwendet werden.

Benutzerdefinierte Namenszuordnung mit LDAP

LDAP kann eine Namenszuordnungsressource sein, wenn die LDAP-Schemaattribute auf dem LDAP-Server aufgefüllt wurden. Um z. B. UNIX-Benutzer den entsprechenden Windows-Benutzernamen zuzuordnen, die nicht mit 1:1 übereinstimmen (d. h . asymmetrisch), können Sie einen anderen Wert für uid das Benutzerobjekt angeben als das, was für den Windows-Benutzernamen konfiguriert ist.

Im folgenden Beispiel verfügt ein Benutzer über einen Windows-Namen asymmetric und muss einer UNIX-Identität zugeordnet UNIXuserwerden. Um dies in Azure NetApp Files zu erreichen, öffnen Sie eine Instanz des Active Directory-Benutzer und -Computer MMC. Suchen Sie dann den gewünschten Benutzer, und öffnen Sie das Eigenschaftenfeld. (Dazu ist das Aktivieren des Attribut-Editors erforderlich). Navigieren Sie zur Registerkarte "Attribut-Editor", und suchen Sie das UID-Feld, füllen Sie dann das UID-Feld mit dem gewünschten UNIX-Benutzernamen UNIXuser auf, und klicken Sie auf "Hinzufügen" und "OK", um dies zu bestätigen.

Screenshot that shows the Asymmetric Properties window and Multi-valued String Editor window.

Nach Abschluss dieser Aktion werden Dateien, die von Windows SMB-Freigaben des Windows-Benutzers asymmetric geschrieben wurden, von der NFS-Seite verwaltet UNIXuser .

Das folgende Beispiel zeigt den Windows-SMB-Besitzer asymmetric:

Screenshot that shows Windows SMB owner named Asymmetric.

Das folgende Beispiel zeigt NFS-Besitzer UNIXuser (von Windows-Benutzern asymmetric mithilfe von LDAP zugeordnet):

root@ubuntu:~# su UNIXuser
UNIXuser@ubuntu:/root$ cd /mnt
UNIXuser@ubuntu:/mnt$ ls -la
total 8
drwxrwxrwx  2 root     root   4096 Jul  3 20:09 .
drwxr-xr-x 21 root     root   4096 Jul  3 20:12 ..
-rwxrwxrwx  1 UNIXuser group1   19 Jul  3 20:10 asymmetric-user-file.txt

LDAP-Schemas

LDAP-Schemas sind, wie LDAP-Server Informationen organisieren und sammeln. LDAP-Serverschemas entsprechen in der Regel den gleichen Standards, aber unterschiedliche LDAP-Serveranbieter haben möglicherweise Variationen darüber, wie Schemas dargestellt werden.

Wenn Azure NetApp Files LDAP abfragt, werden Schemas verwendet, um Namenssuche zu beschleunigen, da sie die Verwendung bestimmter Attribute ermöglichen, um Informationen zu einem Benutzer zu finden, z. B. die UID. Die Schemaattribute müssen auf dem LDAP-Server für Azure NetApp Files vorhanden sein, um den Eintrag zu finden. Andernfalls geben LDAP-Abfragen möglicherweise keine Daten- und Authentifizierungsanforderungen zurück.

Wenn beispielsweise eine UID-Nummer (z. B. root=0) von Azure NetApp Files abgefragt werden muss, wird das Schema-Attribut RFC 2307 uidNumber Attribute verwendet. Wenn im Feld keine UID-Nummer 0uidNumber vorhanden ist, schlägt die Nachschlageanforderung fehl.

Der derzeit von Azure NetApp Files verwendete Schematyp ist eine Form des Schemas, das auf RFC 2307bis basiert und nicht geändert werden kann.

RFC 2307bis ist eine Erweiterung von RFC 2307 und fügt Unterstützung hinzu posixGroup, die dynamische Nachschlagevorgänge für Hilfsgruppen mithilfe des uniqueMember Attributs und nicht mithilfe des memberUid Attributs im LDAP-Schema ermöglicht. Anstatt nur den Namen des Benutzers zu verwenden, enthält dieses Attribut den vollständigen Distinguished Name (DN) eines anderen Objekts in der LDAP-Datenbank. Daher können Gruppen andere Gruppen als Mitglieder haben, die das Schachteln von Gruppen ermöglichen. Unterstützung für RFC 2307bis bietet auch Unterstützung für die Objektklasse groupOfUniqueNames.

Diese RFC-Erweiterung passt gut dazu, wie Microsoft Active Directory Benutzer und Gruppen über die üblichen Verwaltungstools verwaltet. Dies liegt daran, dass LDAP-Nachschlagevorgänge die erforderlichen zusätzlichen Gruppeninformationen aus dem üblichen Windows-Attribut aus dem üblichen Windows-Attribut abrufen und die numerischen GIDs automatisch finden, wenn Sie einem Windows-Benutzer einen Windows-Benutzer hinzufügen (und wenn diese Gruppe über eine gültige numerische GID verfügt).

Nächste Schritte