Grundlegendes zur Verwendung des Lightweight Directory Access-Protokolls mit Azure NetApp Files

Artikel
06/14/2024

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

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. Das 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 des LDAP als Verzeichnisspeicher für Anwendungen wie E-Mail-Apps und Webanwendungen sowie zum Speichern von Mitarbeiterinformationen. Viele Unternehmen ersetzen oder haben den Netzwerkinformationsdienst (Network Information Service, NIS) durch das 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. Diese Unterstützung umfasst sowohl Active Directory Domain Services (AD DS) als auch Microsoft Entra Domain Services.

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

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

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

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

Derzeit verwendet Azure NetApp Files das LDAP nur für Benutzer- und Gruppeninformationen und somit nicht für Netzgruppen- oder Hostinformationen.

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

Das LDAP ist zukunftsfähig:
Da weitere NFS-Clients die Unterstützung für NFSv4.x hinzufügen, muss bei NFSv4.x-ID-Domänen, die eine aktuelle Liste der Benutzer und Gruppen enthalten, auf die über Clients und Speicher zugegriffen werden kann, eine optimale Sicherheit und der garantierte Zugriff sichergestellt sein, wenn die Einstellungen für den Zugriff definiert werden. Ein Identitätsverwaltungsserver, der 1:1-Namenszuordnungen für SMB- und NFS-Benutzer bereitstellt, vereinfacht die Arbeit von Speicheradministratoren nicht nur jetzt erheblich, sondern auch in der Zukunft.
Das 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 zur standortübergreifenden Replikation verwendet werden, um die Leistung und Resilienz zu skalieren.
Das LDAP ist sicher:
Das LDAP bietet insofern Sicherheit, dass 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 Files nicht unterstützt)
- Einfaches Kennwort (Nur-Text-Kennwörter; in Azure NetApp Files nicht unterstützt)
- Simple Authentication and Security Layer (SASL) – Es sind verschiedene verschlüsselte Bindungsmethoden verfügbar (z. B. TLS, SSL, Kerberos usw.). Azure NetApp Files unterstützt das LDAP über die TLS, die LDAP-Signatur (mit Kerberos) und das LDAP über SSL.
Das LDAP ist robust:
NIS, NIS+ und lokale Dateien bieten grundlegende Informationen (z. B. UID, GID, Kennwort, Heimverzeichnisse usw.). Das LDAP bietet jedoch diese Attribute und vieles mehr. Die zusätzlichen Attribute, die das LDAP verwendet, vereinfachen die Integration der Dualprotokollverwaltung im LDAP im Vergleich zum NIS. Nur das LDAP wird als externer Namensdienst für die Identitätsverwaltung mit Azure NetApp Files unterstützt.
Microsoft Active Directory basiert auf dem 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 das Identity Management für UNIX (Windows 2003R2 und höher), Service for UNIX (Windows 2003 und früher) oder LDAP-Tools von Drittanbietern (z. B. Centrify) erweitert wird. Da Microsoft das LDAP als Back-End verwendet, ist das 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 for LDAP-Dienste.

LDAP-Grundlagen in Azure NetApp-Dateien

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

LDAP-Informationen werden in Flatfiles auf einem LDAP-Server gespeichert und über ein LDAP-Schema organisiert. Sie sollten LDAP-Clients so konfigurieren, dass die Anforderungen und Suchvorgänge mit dem Schema auf dem LDAP-Server koordiniert werden.
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 für die Clients ist so konfiguriert, dass der vom LDAP-Server definierte Sicherheitsmechanismus verwendet wird. Manchmal stellen diese Bindungen einen Benutzernamen- und Kennwortaustausch in Nur-Text-Elementen (einfach) dar. In anderen Fällen werden Bindungen über Simple Authentication and Security Layer-Methoden (sasl) wie Kerberos oder das LDAP über die TLS geschützt. Azure NetApp Files verwendet das SMB-Computerkonto, um die SASL-Authentifizierung für die Bindung zu verwenden und somit für die bestmögliche Sicherheit zu sorgen.
Benutzer- und Gruppeninformationen, die im LDAP gespeichert sind, werden von Clients mithilfe von LDAP-Standardsuchanforderungen abgefragt (wie in RFC 2307 definiert). Darüber hinaus ermöglichen neuere Mechanismen wie RFC 2307bis optimierte Benutzer- und Gruppensuchvorgänge. Azure NetApp Files verwendet eine Form von RFC 2307bis für Schemasuchvorgänge in Windows Active Directory.
LDAP-Server können Benutzer- und Gruppeninformationen sowie Netzgruppen speichern. Der Dienst kann jedoch derzeit keine Netzgruppenfunktionalität im LDAP unter Windows Active Directory verwenden.
Das LDAP in Azure NetApp Files wird für Port 389 verwendet. Dieser Port kann derzeit nicht geändert werden, um einen benutzerdefinierten Port wie Port 636 (LDAP über SSL) oder Port 3268 (globale Active Directory-Katalogsuche) zu verwenden.
Die verschlüsselte LDAP-Kommunikation kann mit dem LDAP über die TLS (Verwendung über Port 389) oder die 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 drei 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 für eine bessere Leistungsfähigkeit 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 verwendet wird, der Ihrer Azure NetApp Files-Region am nächsten ist.

Wenn kein bevorzugter LDAP-Server festgelegt ist, wird der Name der Active Directory-Domäne im 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 im DNS manuell über einen Client mit den Befehlen nslookup oder dig abfragen.

Zum 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 für eine benutzerdefinierte Namenszuordnung für Benutzer verwendet werden. Weitere Informationen finden Sie unter Benutzerdefinierte Namenszuordnung mithilfe des LDAP.
LDAP-Abfragetimeouts

Standardmäßig tritt bei LDAP-Abfragen ein Timeout auf, wenn sie nicht rechtzeitig abgeschlossen werden können. Wenn eine LDAP-Abfrage aufgrund eines Timeouts Fehler verursacht, 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. Unter Erstellen und Verwalten von Active Directory-Verbindungen werden die LDAP-Abfragetimeouteinstellungen für Azure NetApp Files erläutert.

Namenszuordnungstypen

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

Die symmetrische Namenszuordnung ist die implizite Namenszuordnung zwischen UNIX- und Windows-Benutzern, die denselben Benutzernamen verwenden. Beispielsweise wird Windows-Benutzer CONTOSO\user1 dem UNIX-Benutzer user1 zugeordnet.
Die asymmetrische Namenszuordnung ist die Namenszuordnung zwischen UNIX- und Windows-Benutzern, die unterschiedliche Benutzernamen verwenden. Beispielsweise wird Windows-Benutzer CONTOSO\user1 dem UNIX-Benutzer user2 zugeordnet.

Standardmäßig verwendet Azure NetApp Files Regeln für die symmetrische Namenszuordnung. Wenn Regeln für die asymmetrische Namenszuordnung erforderlich sind, sollten Sie die LDAP-Benutzerobjekte für die Verwendung dieser Regeln konfigurieren.

Benutzerdefinierte Namenszuordnung mithilfe des LDAP

Das LDAP kann eine Namenszuordnungsressource sein, wenn die LDAP-Schemaattribute auf dem LDAP-Server aufgefüllt wurden. Um beispielsweise UNIX-Benutzer den entsprechenden Windows-Benutzernamen zuzuordnen, die nicht 1:1 übereinstimmen (also asymmetrisch sind), können Sie im Benutzerobjekt einen anderen Wert für uid angeben als bei der Konfiguration für den Windows-Benutzernamen.

Im folgenden Beispiel verfügt ein Benutzer über den Windows-Namen asymmetric und muss der UNIX-Identität UNIXuser zugeordnet werden. Um dies in Azure NetApp Files zu erreichen, öffnen Sie eine Instanz der Microsoft Management Console für Active Directory-Benutzer und -Computer. Suchen Sie dann den gewünschten Benutzer, und öffnen Sie das Eigenschaftenfeld. (Hierfür 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.

Nach Abschluss dieser Aktion gehen Dateien, die über Windows-SMB-Freigaben vom Windows-Benutzer asymmetric geschrieben wurden, in den Besitz von UNIXuser auf der NFS-Seite über.

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

Das folgende Beispiel zeigt den NFS-Besitzer UNIXuser (von Windows-Benutzer asymmetric mithilfe des 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

Lokale NFS-Benutzer mit LDAP zulassen

Wenn ein Benutzer versucht, über das NFS auf ein Azure NetApp Files-Volume zuzugreifen, wird die Anforderung in einer numerischen ID übermittelt. Azure NetApp Files unterstützt standardmäßig erweiterte Gruppenmitgliedschaften für NFS-Benutzer (um das Standardgruppenlimit von 16 zu erweitern). Daher versucht Azure NetApp Files, diese numerische ID zu übernehmen und im LDAP nachzuschlagen, um die Gruppenmitgliedschaften für den Benutzer aufzulösen, anstatt die Gruppenmitgliedschaften in einem RPC-Paket zu übergeben. Wenn diese numerische ID nicht in einen Benutzer im LDAP aufgelöst werden kann, schlägt der Suchvorgang aufgrund dieses Verhaltens fehl, und der Zugriff wird auch dann verweigert, wenn der anfordernde Benutzer über Berechtigungen für den Zugriff auf das Volume oder die Datenstruktur verfügt. Mit der Option „Lokale NFS-Benutzer mit LDAP zulassen“ für Active Directory-Verbindungen können diese LDAP-Suchvorgänge für NFS-Anforderungen deaktiviert werden, indem die erweiterte Gruppenfunktionalität deaktiviert wird. Es werden keine Berechtigungen zum Erstellen und Verwalten von lokalen Benutzern in Azure NetApp Files gewährt.

Wenn die Option „Lokale NFS-Benutzer mit LDAP zulassen“ aktiviert ist, werden numerische IDs an Azure NetApp Files übergeben, und es wird kein LDAP-Suchvorgang ausgeführt. Dies führt zu unterschiedlichen Verhaltensweisen in unterschiedlichen Szenarios (siehe unten).

NFSv3 mit UNIX-Sicherheitsstilvolumes

Numerische IDs müssen nicht in Benutzernamen übersetzt werden. Die Option „Lokale NFS-Benutzer mit LDAP zulassen“ wirkt sich nicht auf den Zugriff auf das Volume aus, kann sich aber darauf auswirken, wie der Besitz von Benutzern bzw. Gruppen (Namensübersetzung) für den NFS-Client angezeigt wird. Wenn beispielsweise die numerische ID „1001“ im LDAP „benutzer1“ entspricht, in der lokalen passwd-Datei des NFS-Clients aber „user2“, zeigt der Client „user2“ als Besitzer der Datei an, wenn die numerische ID „1001“ lautet.

NFSv4.1 mit UNIX-Sicherheitsstilvolumes

Numerische IDs müssen nicht in Benutzernamen übersetzt werden. Standardmäßig verwendet NFSv4.1 Namenszeichenfolgen (user@CONTOSO.COM) für die Authentifizierung. Azure NetApp Files unterstützt jedoch die Verwendung numerischer IDs mit NFSV4.1, was bedeutet, dass NFSv4.1-Anforderungen mit einer numerischen ID an den NFS-Server übermittelt werden. Wenn in lokalen Dateien oder Namensdiensten wie dem LDAP für das Azure NetApp Files-Volume keine numerische ID zur Benutzernamensübersetzung vorhanden ist, wird dem Client die numerische ID angezeigt. Wenn eine numerische ID in einen Benutzernamen übersetzt wird, wird die Namenszeichenfolge verwendet. Wenn die Namenszeichenfolge nicht übereinstimmt, wird der Name vom Client an den anonymen Benutzer gesquasht, der in der idmapd.conf-Datei des Clients angegeben ist. Das Aktivieren der Option „Lokale NFS-Benutzer mit LDAP zulassen“ wirkt sich nicht auf den NFSv4.1-Zugriff aus, da die Einstellung wieder auf das NFSv3-Standardverhalten festgelegt wird, es sei denn, Azure NetApp Files kann eine numerische ID in einen Benutzernamen in der lokalen NFS-Benutzerdatenbank auflösen. Azure NetApp Files verfügt über eine Reihe von UNIX-Standardbenutzern, die für einige Clients problematisch sein können und zu einem nobody-Benutzer gesquasht werden, wenn die Domänen-ID-Zeichenfolgen nicht übereinstimmen.

Lokale Benutzer: Root (0), pcuser (65534), nobody (65535).
Lokale Gruppen: root (0), daemon (1), pcuser (65534), nobody (65535).

In den meisten Fällen wird „root“ in NFSv4.1-Clientbindungen möglicherweise falsch angezeigt, wenn die NFSv4.1-Domänen-ID falsch konfiguriert ist. Weitere Informationen zur NFSv4.1-ID-Domäne finden Sie unter Konfigurieren der NFSv4.1-ID-Domäne für Azure NetApp Files.

NFSv4.1-ACLs können entweder mithilfe einer Namenszeichenfolge oder einer numerischen ID konfiguriert werden. Wenn numerische IDs verwendet werden, ist keine Namensübersetzung erforderlich. Wenn eine Namenszeichenfolge verwendet wird, ist für die ordnungsgemäße ACL-Auflösung eine Namensübersetzung erforderlich. Wenn Sie NFSv4.1 verwenden und die Option „Lokale NFS-Benutzer mit LDAP zulassen“ aktivieren, kann dies in Abhängigkeit von der ACL-Konfiguration zu einem falschen NFSv4.1-ACL-Verhalten führen.

NFS (v3 und v4.1) mit NTFS-Sicherheitsstilvolumes in Dualprotokollkonfigurationen

UNIX-Sicherheitsstilvolumes nutzen UNIX-Stilberechtigungen (Modusbits und NFSv4.1-ACLs). Für diese Volumes nutzt das NFS in Abhängigkeit von den zuvor aufgeführten Szenarios nur die UNIX-Stilauthentifizierung mithilfe einer numerischen ID oder einer Namenszeichenfolge. NTFS-Sicherheitsstilvolumes verwenden jedoch NTFS-Stilberechtigungen. Diese Berechtigungen werden mithilfe von Windows-Benutzern und -Gruppen zugewiesen. Wenn ein NFS-Benutzer versucht, auf ein Volume mit einer NTFS-Stilberechtigung zuzugreifen, muss eine UNIX-zu Windows-Namenszuordnung erfolgen, um die richtigen Zugriffssteuerungen sicherzustellen. In diesem Szenario wird die numerische NFS-ID weiterhin an das NFS-Volume von Azure NetApp Files übergeben, aber es gibt eine Anforderung, dass die numerische ID in einen UNIX-Benutzernamen übersetzt werden muss, damit sie dann einem Windows-Benutzernamen für die anfängliche Authentifizierung zugeordnet werden kann. Wenn beispielsweise die numerische ID „1001“ versucht, auf eine NFS-Bindung mit NTFS-Sicherheitsstilberechtigungen zuzugreifen, die dem Windows-Benutzer „user1“ den Zugriff ermöglichen, müsste die numerische ID „1001“ im LDAP in den Benutzernamen „user1“ aufgelöst werden, um den erwarteten Zugriff zu erhalten. Wenn kein Benutzer mit der numerischen ID „1001“ im LDAP vorhanden ist oder das LDAP falsch konfiguriert ist, entspricht 1001@contoso.com der getesteten UNIX-zu-Windows-Namenszuordnung. In den meisten Fällen sind Benutzer mit diesem Namen nicht vorhanden, sodass die Authentifizierung fehlschlägt und der Zugriff verweigert wird. Wenn die numerische ID „1001“ in den falschen Benutzernamen (z. B. „user2“) aufgelöst wird, wird die NFS-Anforderung einem unerwarteten Windows-Benutzer zugeordnet, und die Berechtigungen für den Benutzer verwenden die Zugriffssteuerungen von „user2“.

Wenn Sie die Option „Lokale NFS-Benutzer mit LDAP zulassen“ aktivieren, werden alle LDAP-Übersetzungen von numerischen IDs in Benutzernamen deaktiviert, wodurch der Zugriff auf NTFS-Sicherheitsstilvolumes effektiv eingeschränkt wird. Daher wird dringend von der Verwendung dieser Option mit NTFS-Sicherheitsstilvolumes abgeraten.

LDAP-Schemas

LDAP-Schemas beschreiben, wie LDAP-Server Informationen organisieren und sammeln. LDAP-Serverschemas befolgen in der Regel dieselben Standards, aber verschiedene LDAP-Serveranbieter verfügen möglicherweise über Variationen, wie Schemas dargestellt werden.

Wenn Azure NetApp Files das LDAP abfragt, werden Schemas verwendet, um Namenssuchvorgänge zu beschleunigen, da sie die Verwendung bestimmter Attribute für die Suche nach Informationen zu Benutzern (z. B. UID) ermöglichen. Die Schemaattribute müssen auf dem LDAP-Server für Azure NetApp Files vorhanden sein, um den Eintrag finden zu können. Andernfalls geben LDAP-Abfragen möglicherweise keine Daten zurück, und bei Authentifizierungsanforderungen tritt ein Fehler auf.

Wenn beispielsweise eine UID-Nummer (z. B. root=0) von Azure NetApp Files abgefragt werden muss, wird das Schemaattribut RFC 2307 (uidNumber Attribute) verwendet. Wenn die UID-Nummer 0 im LDAP im uidNumber-Feld nicht vorhanden ist, schlägt die Suchvorgangsanforderung 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 die Unterstützung für posixGroup hinzu, wodurch dynamische Suchvorgänge für Hilfsgruppen mithilfe des uniqueMember-Attributs und nicht mithilfe des memberUid-Attributs im LDAP-Schema ermöglicht werden. 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, was die Schachtelung von Gruppen ermöglicht. Die Unterstützung für RFC 2307bis bietet auch die 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 bei LDAP-Suchvorgängen die erforderlichen zusätzlichen Gruppeninformationen aus dem üblichen Windows-Attribut abgerufen und die numerischen GIDs automatisch gefunden werden, wenn Sie einer Gruppe einen Windows-Benutzer hinzufügen (und diese Gruppe über eine gültige numerische GID verfügt).

Freigeben über