Nuta
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować się zalogować lub zmienić katalog.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Schematy protokołu LDAP (Lightweight Directory Access Protocol) to sposób organizowania i zbierania informacji przez serwery LDAP. Schematy serwerów LDAP zwykle są zgodne z tymi samymi standardami, ale różni dostawcy serwerów LDAP mogą mieć odmiany dotyczące sposobu prezentowania schematów.
Gdy usługa Azure NetApp Files wysyła zapytania LDAP, schematy są używane do przyspieszania wyszukiwania nazw, ponieważ umożliwiają używanie określonych atrybutów do znajdowania informacji o użytkowniku, takich jak identyfikator UID. Atrybuty schematu muszą istnieć na serwerze LDAP dla usługi Azure NetApp Files, aby można było znaleźć wpis. W przeciwnym razie zapytania LDAP mogą nie zwracać żadnych danych, a żądania uwierzytelniania mogą zakończyć się niepowodzeniem.
Jeśli na przykład numer UID (taki jak root=0) musi być odpytywane przez usługę Azure NetApp Files, używany jest atrybut schematu RFC 2307 uidNumber Attribute . Jeśli w polu 0 w LDAP nie istnieje żaden numer UID uidNumber, wtedy żądanie wyszukiwania zakończy się niepowodzeniem.
Typ schematu używany obecnie przez usługę Azure NetApp Files jest formą schematu opartą na standardzie RFC 2307bis i nie można jej modyfikować.
RFC 2307bis jest rozszerzeniem RFC 2307 i dodaje obsługę posixGroup, która umożliwia dynamiczne wyszukiwanie dla grup pomocniczych przy użyciu atrybutu uniqueMember , a nie przy użyciu memberUid atrybutu w schemacie LDAP. Zamiast używać tylko nazwy użytkownika, ten atrybut zawiera pełną nazwę wyróżniającą innego obiektu w bazie danych LDAP. W związku z tym grupy mogą mieć inne grupy jako elementy członkowskie, co umożliwia zagnieżdżanie grup. Obsługa RFC 2307bis dodaje również obsługę klasy groupOfUniqueNamesobiektów .
To rozszerzenie RFC pasuje ładnie do sposobu, w jaki usługa Microsoft Active Directory zarządza użytkownikami i grupami za pomocą zwykłych narzędzi do zarządzania. Dzieje się tak dlatego, że po dodaniu użytkownika systemu Windows do grupy (a jeśli ta grupa ma prawidłową liczbę GID) przy użyciu standardowych metod zarządzania systemem Windows, wyszukiwanie LDAP ściągnie niezbędne informacje o grupie uzupełniającej ze zwykłego atrybutu systemu Windows i automatycznie znajdzie numeryczne identyfikatory GID.
Kiedy woluminy usługi Azure NetApp Files muszą przeprowadzać wyszukiwania LDAP dla tożsamości użytkowników NFS, korzystają z szeregu atrybutów zdefiniowanych w schemacie LDAP opartym na standardzie RFC-2307bis. W poniższej tabeli przedstawiono atrybuty używane przez wyszukiwania LDAP, które są wartościami domyślnymi zdefiniowanymi w usłudze Microsoft Active Directory, gdy są używane atrybuty systemu UNIX. Aby zapewnić odpowiednią funkcjonalność, upewnij się, że te atrybuty są poprawnie wypełniane na kontach użytkowników i grup w protokole LDAP.
| Atrybut UNIX | Wartość schematu LDAP |
|---|---|
| Nazwa użytkownika systemu UNIX | UID* |
| Identyfikator liczbowy użytkownika systemu UNIX | uidNumber* |
| Nazwa grupy systemu UNIX | Cn* |
| Identyfikator liczbowy grupy systemu UNIX | Numer identyfikacyjny (gidNumber)* |
| Członkostwo w grupie systemu UNIX | członek** |
| Klasa obiektów użytkownika systemu UNIX | Użytkownik** |
| Katalog główny systemu UNIX | unixHomeDirectory |
| Nazwa wyświetlana systemu UNIX | gecos |
| Hasło użytkownika systemu UNIX | HasłoUżytkownikaUnix |
| Powłoka logowania systemu UNIX | LoginShell |
| Konto systemu Windows używane do mapowania nazw | sAMAccountName** |
| Klasa obiektów grupy systemu UNIX | Grupa** |
| Identyfikator UID użytkownika UNIX | memberUid*** |
| Grupa obiektów unikatowych nazw systemu UNIX | Grupa** |
* Wymagany atrybut dla prawidłowej funkcjonalności LDAP
** Domyślnie wypełnione w usłudze Active Directory
Niewymagane
Omówienie indeksowania atrybutów LDAP
Usługa Active Directory LDAP udostępnia metodę indeksowania atrybutów , która ułatwia przyspieszenie żądań wyszukiwania. Jest to szczególnie przydatne w dużych środowiskach katalogu, w których wyszukiwanie LDAP może potencjalnie przekroczyć 10-sekundową wartość limitu czasu dla wyszukiwań w usłudze Azure NetApp Files. Jeśli wyszukiwanie przekroczy wartość limitu czasu, wyszukiwanie LDAP zakończy się niepowodzeniem i dostęp nie będzie działać prawidłowo, ponieważ usługa nie może zweryfikować tożsamości użytkownika lub grupy żądającej dostępu.
Domyślnie protokół LDAP usługi Microsoft Active Directory indeksuje następujące atrybuty systemu UNIX używane przez usługę Azure NetApp Files do wyszukiwania LDAP:
Atrybut uid nie jest domyślnie indeksowany. W związku z tym zapytania LDAP dla identyfikatora UID zajmują więcej czasu niż zapytania dotyczące atrybutów indeksowanych.
Na przykład w poniższym teście zapytania w środowisku usługi Active Directory z ponad 20 000 użytkowników i grup wyszukiwanie użytkownika z indeksowanym atrybutem CN trwało około 0,015 sekund, podczas gdy wyszukiwanie tego samego użytkownika z atrybutem UID (który nie jest indeksowany domyślnie) trwało bliżej 0,6 sekundy — 40 razy wolniej.
W mniejszych środowiskach nie powoduje to problemów. Jednak w większych środowiskach (lub środowiskach, w których środowisko usługi Active Directory znajduje się lokalnie lub ma duże opóźnienie sieci), różnica może być na tyle drastyczna, aby spowodować problemy z dostępem użytkowników do woluminów usługi Azure NetApp Files. W związku z tym najlepszym rozwiązaniem jest skonfigurowanie atrybutu UID w protokole LDAP do indeksowania przez usługę Active Directory.
Konfigurowanie atrybutu UID do indeksowania przez usługę Active Directory
Atrybuty są indeksowane za pośrednictwem searchFlags wartości obiektu atrybutu, który można skonfigurować za pośrednictwem funkcji ADSI Edit w kontekście nazewnictwa schematu. Dostęp do edycji ADSI należy zachować ostrożność i wymagać co najmniej uprawnień administratora schematu.
Domyślnie obiekt searchFlags atrybutu uid jest ustawiony na 0x8 (PRESERVE_ON_DELETE). To ustawienie domyślne gwarantuje, że nawet jeśli obiekt w usłudze Active Directory zostanie usunięty, wartość atrybutu pozostaje przechowywana w katalogu jako rekord historyczny atrybutu użytkownika.
Dla porównania atrybut indeksowany w usłudze Active Directory dla wyszukiwań LDAP będzie miał wartość 0x1 (lub kilka kombinacji, w tym tej wartości), takich jak uidNumber:
W związku z tym zapytania dotyczące identyfikatora uidNumber zwracają się szybciej niż zapytania dotyczące identyfikatora UID. Aby uzyskać spójność i wydajność, można dostosować wartość searchFlags uid do 9, dodając 0x1 do istniejącej wartości 0x8, czyli (INDEX | PRESERVE_ON_DELETE). Ten dodatek zachowuje domyślne zachowanie podczas dodawania indeksowania atrybutów do katalogu.
W przypadku indeksowania wyszukiwanie atrybutów użytkownika z identyfikatorem uid jest tak szybkie, jak wyszukiwanie innych indeksowanych atrybutów.