Anmerkung
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
LDAP-Schemas (Schemas für das Lightweight Directory Access-Protokoll) 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).
Wenn Azure NetApp Files-Volumes LDAP-Nachschlagevorgänge für NFS-Benutzeridentitäten durchführen müssen, wird eine Reihe von Attributen, die von einem LDAP-Schema basierend auf RFC-2307bis definiert sind. In der folgenden Tabelle sind die Attribute aufgeführt, die von LDAP-Nachschlagevorgängen verwendet werden. Dabei handelt es sich um die Standardwerte, die in Microsoft Active Directory definiert sind, wenn UNIX-Attribute verwendet werden. Um eine ordnungsgemäße Funktionalität zu gewährleisten, stellen Sie sicher, dass diese Attribute in den Benutzer- und Gruppenkonten in LDAP ordnungsgemäß ausgefüllt sind.
| UNIX-Attribut | LDAP-Schemawert |
|---|---|
| UNIX-Benutzername | uid* |
| NUMERISCHE ID des UNIX-Benutzers | uidNumber* |
| UNIX-Gruppenname | cn* |
| NUMERISCHE ID der UNIX-Gruppe | gidNumber* |
| UNIX-Gruppenmitgliedschaft | Mitglied** |
| UNIX-Benutzerobjektklasse | Benutzer** |
| UNIX-Basisverzeichnis | unixHomeDirectory |
| UNIX-Anzeigename | Gecos |
| UNIX-Benutzerkennwort | Unix-Benutzerpasswort |
| UNIX-Anmeldeshell | LoginShell |
| Windows-Konto, das für die Namenszuordnung verwendet wird | sAMAccountName** |
| UNIX-Gruppenobjektklasse | Gruppe** |
| UNIX-Mitglied UID | memberUid*** |
| Objektklasse der UNIX-Gruppe eindeutiger Namen | Gruppe** |
* Erforderliches Attribut für die ordnungsgemäße LDAP-Funktionalität
** Standardmäßig in Active Directory ausgefüllt
*** Nicht erforderlich
Grundlegendes zur LDAP-Attributindizierung
Active Directory LDAP stellt eine Indizierungsmethode für Attribute bereit, mit denen Nachschlageanforderungen beschleunigt werden können. Dies ist besonders in großen Verzeichnisumgebungen nützlich, in denen eine LDAP-Suche möglicherweise den 10-Sekunden-Timeoutwert für Suchvorgänge in Azure NetApp Files überschreiten kann. Wenn eine Suche den Timeoutwert überschreitet, schlägt die LDAP-Suche fehl und der Zugriff funktioniert nicht ordnungsgemäß, da der Dienst die Identität des Benutzers oder der Gruppe, die den Zugriff anfordert, nicht überprüfen kann.
Standardmäßig indiziert Microsoft Active Directory LDAP die folgenden UNIX-Attribute, die von Azure NetApp Files für LDAP-Suchvorgänge verwendet werden:
Das UID-Attribut ist standardmäßig nicht indiziert. Daher nehmen LDAP-Abfragen für die UID mehr Zeit in Anspruch als Abfragen für indizierte Attribute.
So dauerte beispielsweise bei dem folgenden Test einer Abfrage in einer Active Directory-Umgebung mit mehr als 20 000 Benutzenden und Gruppen die Suche nach einer benutzenden Person mit dem indizierten Attribut CN etwa 0,015 Sekunden, während die Suche nach derselben Person mit dem UID-Attribut (das standardmäßig nicht indiziert ist) etwa 0,6 Sekunden dauerte – also 40-mal langsamer.
In kleineren Umgebungen verursacht dies keine Probleme. In größeren Umgebungen (oder Umgebungen, in denen die Active Directory-Umgebung lokal ist oder eine hohe Netzwerklatenz aufweist) kann der Unterschied jedoch so drastisch sein, dass es zu Zugriffsproblemen für Benutzende kommt, die auf Azure NetApp Files-Volumes zugreifen. Daher empfiehlt es sich, das UID-Attribut in LDAP so zu konfigurieren, dass es von Active Directory indiziert wird.
Konfigurieren des UID-Attributs, das von Active Directory indiziert werden soll
Attribute werden über den searchFlags-Wert für das Attributobjekt indiziert, der über ADSI Edit im Schemabenennungskontext konfiguriert werden kann. Der Zugriff auf ADSI Edit sollte mit Vorsicht erfolgen und erfordert mindestens die Rolle Schema Admin.
Standardmäßig sind die searchFlags des UID-Attributobjekts auf 0x8 (PRESERVE_ON_DELETE) festgelegt. Diese Standardeinstellung stellt sicher, dass auch dann, wenn das Objekt in Active Directory gelöscht wird, der Attributwert im Verzeichnis als historischer Datensatz des Attributs der benutzenden Person gespeichert bleibt.
Im Vergleich dazu hätte ein Attribut, das in Active Directory für LDAP-Suchvorgänge indiziert ist, den Wert 0x1 (oder eine Kombination einschließlich dieses Werts), z. B. die uidNumber:
Aus diesem Grund werden Abfragen für „uidNumber“ schneller zurückgegeben als Abfragen für „uid“. Für Konsistenz und Leistung können Sie den searchFlags-Wert für „uid“ auf 9 anpassen, indem Sie 0x1 zusammen mit dem vorhandenen Wert von 0x8 hinzufügen, der (INDEX | PRESERVE_ON_DELETE). Diese Ergänzung behält das Standardverhalten beim Hinzufügen von Attributindizierung zum Verzeichnis bei.
Bei der Indizierung sind Suchvorgänge nach Benutzerattributen mit UID so schnell wie Suchvorgänge nach anderen indizierten Attributen.