Omówienie korzystania z protokołu LDAP z usługą Azure NetApp Files

Artykuł
06/13/2024

Lightweight directory access protocol (LDAP) to standardowy protokół dostępu do katalogów, który został opracowany przez międzynarodowy komitet o nazwie Internet Engineering Task Force (IETF). Protokół LDAP ma na celu zapewnienie usługi katalogowej opartej na sieci ogólnego przeznaczenia, której można używać na różnych platformach heterogenicznych do lokalizowania obiektów sieciowych.

Modele LDAP definiują sposób komunikowania się z magazynem katalogów LDAP, sposób znajdowania obiektu w katalogu, sposobu opisywania obiektów w magazynie oraz zabezpieczeń używanych do uzyskiwania dostępu do katalogu. Protokół LDAP umożliwia dostosowanie i rozszerzenie obiektów opisanych w magazynie. W związku z tym można użyć magazynu LDAP do przechowywania wielu typów różnorodnych informacji. Wiele początkowych wdrożeń LDAP koncentruje się na użyciu protokołu LDAP jako magazynu katalogów dla aplikacji, takich jak poczta e-mail i aplikacje internetowe oraz przechowywanie informacji o pracownikach. Wiele firm zastępuje lub zastąpiło usługę informacji o sieci (NIS) protokołem LDAP jako magazynem katalogów sieciowych.

Serwer LDAP udostępnia tożsamości użytkowników i grup systemu UNIX do użycia z woluminami NAS. W usłudze Azure NetApp Files usługa Active Directory jest jedynym obecnie obsługiwanym serwerem LDAP, którego można użyć. Ta obsługa obejmuje usługi domena usługi Active Directory Services (AD DS) i Microsoft Entra Domain Services.

Żądania LDAP można podzielić na dwie główne operacje.

Powiązania LDAP to identyfikatory logowania do serwera LDAP z klienta LDAP. Powiązanie służy do uwierzytelniania na serwerze LDAP przy użyciu dostępu tylko do odczytu w celu wykonywania wyszukiwania LDAP. Usługa Azure NetApp Files działa jako klient LDAP.
Wyszukiwanie LDAP służy do wykonywania zapytań dotyczących katalogu dla informacji o użytkownikach i grupach, takich jak nazwy, identyfikatory liczbowe, ścieżki katalogu macierzystego, ścieżki powłoki logowania, członkostwa w grupach i nie tylko.

Protokół LDAP może przechowywać następujące informacje, które są używane w dostępie do serwera NAS z podwójnym protokołem:

Nazwy użytkowników
Nazwy grup
Identyfikatory użytkowników liczbowych (UID) i identyfikatory grup (GID)
Katalogi główne
Powłoka logowania
Grupy sieciowe, nazwy DNS i adresy IP
Członkostwo w grupie

Obecnie usługa Azure NetApp Files używa tylko protokołu LDAP dla informacji o użytkownikach i grupach — nie ma informacji o grupie netgroup ani hoście.

Protokół LDAP oferuje różne korzyści dla użytkowników i grup systemu UNIX jako źródła tożsamości.

Protokół LDAP jest przyszłościowy.
W miarę jak więcej klientów NFS dodaje obsługę NFSv4.x, domeny identyfikatorów NFSv4.x zawierające aktualną listę użytkowników i grup dostępnych od klientów i magazynu są potrzebne w celu zapewnienia optymalnego bezpieczeństwa i gwarantowanego dostępu po zdefiniowaniu dostępu. Posiadanie serwera zarządzania tożsamościami, który zapewnia mapowanie nazw jeden do jednego dla użytkowników SMB i NFS znacznie upraszcza życie administratorów magazynu, nie tylko w obecnej, ale przez wiele lat.
Protokół LDAP jest skalowalny.
Serwery LDAP oferują możliwość przechowywania milionów obiektów użytkowników i grup, a w usłudze Microsoft Active Directory wiele serwerów może służyć do replikacji między wieloma lokacjami w celu skalowania wydajności i odporności.
Protokół LDAP jest bezpieczny.
Protokół LDAP zapewnia zabezpieczenia w postaci sposobu, w jaki system magazynu może nawiązać połączenie z serwerem LDAP, aby wysyłać żądania dotyczące informacji o użytkowniku. Serwery LDAP oferują następujące poziomy powiązania:
- Anonimowe (domyślnie wyłączone w usłudze Microsoft Active Directory; nieobsługiwane w usłudze Azure NetApp Files)
- Proste hasło (hasła zwykłego tekstu; nieobsługiwane w usłudze Azure NetApp Files)
- Proste uwierzytelnianie i warstwa zabezpieczeń (SASL) — szyfrowane metody powiązania, takie jak TLS, SSL, Kerberos itd. Usługa Azure NetApp Files obsługuje protokół LDAP za pośrednictwem protokołu TLS, podpisywania LDAP (przy użyciu protokołu Kerberos), protokołu LDAP za pośrednictwem protokołu SSL.
Protokół LDAP jest niezawodny.
Pliki NIS, NIS+ i lokalne oferują podstawowe informacje, takie jak UID, GID, hasło, katalogi domowe itd. Jednak protokół LDAP oferuje te atrybuty i wiele innych. Dodatkowe atrybuty używane przez protokół LDAP znacznie bardziej zintegrowane z protokołem LDAP i NIS. Tylko protokół LDAP jest obsługiwany jako zewnętrzna usługa nazw na potrzeby zarządzania tożsamościami w usłudze Azure NetApp Files.
Usługa Microsoft Active Directory jest oparta na protokole LDAP.
Domyślnie usługa Microsoft Active Directory używa zaplecza LDAP dla swoich wpisów użytkowników i grup. Jednak ta baza danych LDAP nie zawiera atrybutów stylu systemu UNIX. Te atrybuty są dodawane, gdy schemat LDAP jest rozszerzony za pomocą usługi Identity Management dla systemu UNIX (Windows 2003R2 i nowszych), usługi dla systemu UNIX (Windows 2003 i starszych) lub narzędzi LDAP innych firm, takich jak Centrify. Ponieważ firma Microsoft używa protokołu LDAP jako zaplecza, sprawia, że protokół LDAP jest idealnym rozwiązaniem dla środowisk, które zdecydują się korzystać z woluminów z podwójnym protokołem w usłudze Azure NetApp Files.

Uwaga

Usługa Azure NetApp Files obecnie obsługuje tylko natywną usługę Microsoft Active Directory dla usług LDAP.

Podstawy protokołu LDAP w usłudze Azure NetApp Files

W poniższej sekcji omówiono podstawy protokołu LDAP dotyczące usługi Azure NetApp Files.

Informacje LDAP są przechowywane w plikach prostych na serwerze LDAP i są zorganizowane za pomocą schematu LDAP. Należy skonfigurować klientów LDAP w sposób, który koordynuje żądania i wyszukiwania ze schematem na serwerze LDAP.
Klienci LDAP inicjują zapytania za pomocą powiązania LDAP, który jest zasadniczo identyfikatorem logowania do serwera LDAP przy użyciu konta z dostępem do odczytu do schematu LDAP. Konfiguracja powiązania LDAP na klientach jest skonfigurowana do używania mechanizmu zabezpieczeń zdefiniowanego przez serwer LDAP. Czasami są to nazwy użytkownika i wymiany haseł w postaci zwykłego tekstu (proste). W innych przypadkach powiązania są zabezpieczone za pomocą metod uwierzytelniania prostego i warstwy zabezpieczeń (sasl), takich jak Kerberos lub LDAP za pośrednictwem protokołu TLS. Usługa Azure NetApp Files używa konta maszyny SMB do powiązania przy użyciu uwierzytelniania SASL w celu uzyskania najlepszych możliwych zabezpieczeń.
Informacje o użytkownikach i grupach przechowywane w protokole LDAP są wysyłane do klientów przy użyciu standardowych żądań wyszukiwania LDAP zdefiniowanych w dokumencie RFC 2307. Ponadto nowsze mechanizmy, takie jak RFC 2307bis, umożliwiają bardziej usprawnione wyszukiwanie użytkowników i grup. Usługa Azure NetApp Files używa formy RFC 2307bis do wyszukiwania schematów w usłudze Windows Active Directory.
Serwery LDAP mogą przechowywać informacje o użytkownikach i grupach grupowych oraz netgroup. Jednak usługa Azure NetApp Files obecnie nie może używać funkcji netgroup w protokole LDAP w usłudze Windows Active Directory.
Protokół LDAP w usłudze Azure NetApp Files działa na porcie 389. Obecnie nie można zmodyfikować tego portu w celu użycia portu niestandardowego, takiego jak port 636 (LDAP za pośrednictwem protokołu SSL) lub port 3268 (wyszukiwanie w wykazie globalnym usługi Active Directory).
Szyfrowana komunikacja LDAP można osiągnąć przy użyciu protokołu LDAP za pośrednictwem protokołu TLS (który działa za pośrednictwem portu 389) lub podpisywania LDAP, z których oba można skonfigurować w połączeniu usługi Active Directory.
Usługa Azure NetApp Files obsługuje zapytania LDAP, które nie mogą trwać dłużej niż 3 sekundy. Jeśli serwer LDAP ma wiele obiektów, limit czasu może zostać przekroczony, a żądania uwierzytelniania mogą zakończyć się niepowodzeniem. W takich przypadkach rozważ określenie zakresu wyszukiwania LDAP w celu filtrowania zapytań w celu uzyskania lepszej wydajności.
Usługa Azure NetApp Files obsługuje również określanie preferowanych serwerów LDAP w celu przyspieszenia żądań. Użyj tego ustawienia, jeśli chcesz upewnić się, że używany jest serwer LDAP najbliżej regionu usługi Azure NetApp Files.

Jeśli nie ustawiono preferowanego serwera LDAP, nazwa domeny usługi Active Directory jest odpytywany w systemie DNS dla rekordów usługi LDAP, aby wypełnić listę serwerów LDAP dostępnych dla twojego regionu znajdującego się w tym rekordzie SRV. Możesz ręcznie wykonywać zapytania dotyczące rekordów usługi LDAP w systemie DNS z poziomu klienta przy użyciu poleceń nslookup lub dig .

Na przykład:

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

Serwery LDAP mogą również służyć do wykonywania niestandardowego mapowania nazw dla użytkowników. Aby uzyskać więcej informacji, zobacz Mapowanie nazw niestandardowych przy użyciu protokołu LDAP.
Limity czasu zapytania LDAP

Domyślnie limit czasu zapytań LDAP jest przekroczony, jeśli nie mogą one być wykonywane w odpowiednim czasie. Jeśli zapytanie LDAP nie powiedzie się z powodu przekroczenia limitu czasu, wyszukiwanie użytkownika i/lub grupy zakończy się niepowodzeniem i dostęp do woluminu usługi Azure NetApp Files może zostać odrzucony, w zależności od ustawień uprawnień woluminu. Zapoznaj się z artykułem Tworzenie połączeń usługi Active Directory i zarządzanie nimi, aby poznać ustawienia limitu czasu zapytania LDAP usługi Azure NetApp Files.

Typy mapowań nazw

Reguły mapowania nazw można podzielić na dwa główne typy: symetryczne i asymetryczne.

Mapowanie nazw symetrycznych jest niejawne mapowanie nazw między użytkownikami systemu UNIX i Windows, którzy używają tej samej nazwy użytkownika. Na przykład użytkownik systemu CONTOSO\user1 Windows mapuje na użytkownika user1systemu UNIX .
Mapowanie nazw asymetrycznych to mapowanie nazw między użytkownikami systemów UNIX i Windows, którzy używają różnych nazw użytkowników. Na przykład użytkownik systemu CONTOSO\user1 Windows mapuje na użytkownika user2systemu UNIX .

Domyślnie usługa Azure NetApp Files używa reguł mapowania nazw symetrycznych. Jeśli są wymagane reguły mapowania nazw asymetrycznych, rozważ skonfigurowanie obiektów użytkownika LDAP do ich używania.

Mapowanie nazw niestandardowych przy użyciu protokołu LDAP

Protokół LDAP może być zasobem mapowania nazw, jeśli atrybuty schematu LDAP na serwerze LDAP zostały wypełnione. Aby na przykład zamapować użytkowników systemu UNIX na odpowiednie nazwy użytkowników systemu Windows, które nie są zgodne z "jeden do jednego" (czyli asymetryczne), można określić inną wartość dla uid obiektu użytkownika niż to, co jest skonfigurowane dla nazwy użytkownika systemu Windows.

W poniższym przykładzie użytkownik ma nazwę asymmetric systemu Windows i musi mapować na tożsamość systemu UNIX .UNIXuser Aby to osiągnąć w usłudze Azure NetApp Files, otwórz wystąpienie Użytkownicy i komputery usługi Active Directory MMC. Następnie znajdź żądanego użytkownika i otwórz pole właściwości. (Wymaga to włączenia Edytora atrybutów). Przejdź do karty Edytor atrybutów i znajdź pole UID, a następnie wypełnij pole UID odpowiednią nazwą UNIXuser użytkownika systemu UNIX, a następnie kliknij przycisk Dodaj i OK , aby potwierdzić.

Po wykonaniu tej akcji pliki zapisywane z udziałów SMB systemu Windows przez użytkownika asymmetric systemu Windows będą własnością UNIXuser po stronie systemu plików NFS.

W poniższym przykładzie przedstawiono właściciela asymmetricprotokołu SMB systemu Windows:

W poniższym przykładzie pokazano właściciela UNIXuser systemu plików NFS (zamapowanego z użytkownika asymmetric systemu Windows przy użyciu protokołu LDAP):

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

Zezwalaj na lokalnych użytkowników systemu NFS przy użyciu protokołu LDAP

Gdy użytkownik próbuje uzyskać dostęp do woluminu usługi Azure NetApp Files za pośrednictwem systemu plików NFS, żądanie ma identyfikator liczbowy. Domyślnie usługa Azure NetApp Files obsługuje rozszerzone członkostwa w grupach dla użytkowników systemu plików NFS (aby przekraczać standardowy limit 16 grup). W związku z tym pliki usługi Azure NetApp będą próbować podjąć ten identyfikator liczbowy i wyszukać go w protokole LDAP w celu rozwiązania członkostwa w grupach dla użytkownika, a nie przekazania członkostwa w grupach w pakiecie RPC. Ze względu na to zachowanie, jeśli nie można rozpoznać tego identyfikatora liczbowego dla użytkownika w protokole LDAP, wyszukiwanie zakończy się niepowodzeniem i dostęp zostanie odrzucony — nawet jeśli żądający użytkownik ma uprawnienia dostępu do woluminu lub struktury danych. Opcja Zezwalaj lokalnym użytkownikom systemu plików NFS z protokołem LDAP w połączeniach usługi Active Directory ma na celu wyłączenie tych wyszukiwań LDAP dla żądań NFS przez wyłączenie rozszerzonej funkcjonalności grupy. Nie zapewnia ona "tworzenia/zarządzania użytkownikami lokalnymi" w usłudze Azure NetApp Files.

Po włączeniu opcji "Zezwalaj lokalnym użytkownikom systemu plików NFS z protokołem LDAP" identyfikatory liczbowe są przekazywane do usługi Azure NetApp Files i nie są wykonywane żadne wyszukiwanie LDAP. Powoduje to różne zachowanie w różnych scenariuszach, jak opisano poniżej.

NFSv3 z woluminami stylu zabezpieczeń systemu UNIX

Identyfikatory liczbowe nie muszą być tłumaczone na nazwy użytkowników. Opcja "Zezwalaj lokalnym użytkownikom systemu plików NFS z protokołem LDAP" nie będzie miała wpływu na dostęp do woluminu, ale może mieć wpływ na sposób wyświetlania własności użytkownika/grupy (tłumaczenia nazw) na kliencie systemu plików NFS. Jeśli na przykład identyfikator liczbowy 1001 jest użytkownikiem 1 w protokole LDAP, ale użytkownik2 w lokalnym pliku passwd klienta systemu plików NFS, klient wyświetli wartość "user2" jako właściciel pliku, gdy identyfikator liczbowy to 1001.

NFSv4.1 z woluminami stylu zabezpieczeń systemu UNIX

Identyfikatory liczbowe nie muszą być tłumaczone na nazwy użytkowników. Domyślnie NFSv4.1 używa ciągów nazw (user@CONTOSO.COM) do uwierzytelniania. Jednak usługa Azure NetApp Files obsługuje używanie identyfikatorów liczbowych z systemem plików NFSV4.1, co oznacza, że żądania NFSv4.1 będą wysyłane do serwera NFS z identyfikatorem liczbowym. Jeśli w lokalnych plikach lub usługach nazw, takich jak LDAP dla woluminu usługi Azure NetApp Files, nie istnieje żaden identyfikator liczbowy do tłumaczenia nazwy użytkownika, zostanie on przedstawiony klientowi. Jeśli identyfikator liczbowy przekłada się na nazwę użytkownika, zostanie użyty ciąg nazwy. Jeśli ciąg nazwy nie jest zgodny, klient zmieci nazwę anonimowego użytkownika określonego w pliku idmapd.conf klienta. Włączenie opcji "Zezwalaj lokalnym użytkownikom systemu plików NFS z protokołem LDAP" nie będzie miało wpływu na dostęp NFSv4.1, ponieważ powróci do standardowego zachowania NFSv3, chyba że usługa Azure NetApp Files może rozpoznać identyfikator liczbowy do nazwy użytkownika w lokalnej bazie danych użytkowników NFS. Usługa Azure NetApp Files ma zestaw domyślnych użytkowników systemu UNIX, które mogą być problematyczne dla niektórych klientów i squasha do użytkownika "nikt", jeśli ciągi identyfikatorów domeny nie są zgodne.

Użytkownicy lokalni to: root (0), pcuser (65534), nikt (65535).
Grupy lokalne obejmują: root (0), demon (1), pcuser (65534), nikt (65535).

Najczęściej katalog główny może być niepoprawnie wyświetlany w instalacji klienta NFSv4.1, gdy identyfikator domeny NFSv4.1 jest nieprawidłowo skonfigurowany. Aby uzyskać więcej informacji na temat domeny identyfikatora NFSv4.1, zobacz Konfigurowanie domeny identyfikatora NFSv4.1 dla usługi Azure NetApp Files.

Listy ACL NFSv4.1 można skonfigurować przy użyciu ciągu nazwy lub identyfikatora liczbowego. Jeśli są używane identyfikatory liczbowe, tłumaczenie nazw nie jest wymagane. Jeśli jest używany ciąg nazw, tłumaczenie nazw będzie wymagane do prawidłowego rozpoznawania listy ACL. W przypadku korzystania z list ACL NFSv4.1 włączenie opcji "Zezwalaj lokalnym użytkownikom systemu plików NFS z protokołem LDAP" może spowodować nieprawidłowe zachowanie listy ACL NFSv4.1 w zależności od konfiguracji listy ACL.

System plików NFS (w wersji 3 i 4.1) z woluminami stylu zabezpieczeń NTFS w konfiguracjach dwóch protokołów

Woluminy stylu zabezpieczeń systemu UNIX korzystają z uprawnień stylu systemu UNIX (bity trybu i listy ACL NFSv4.1). W przypadku tych typów woluminów system plików NFS korzysta tylko z uwierzytelniania w stylu systemu UNIX, korzystając z identyfikatora liczbowego lub ciągu nazwy, w zależności od scenariuszy wymienionych powyżej. Woluminy stylu zabezpieczeń NTFS używają jednak uprawnień stylu NTFS. Te uprawnienia są przypisywane przy użyciu użytkowników i grup systemu Windows. Gdy użytkownik systemu plików NFS próbuje uzyskać dostęp do woluminu z uprawnieniem w stylu NTFS, mapowanie nazw systemu UNIX na system Windows musi nastąpić w celu zapewnienia odpowiednich kontroli dostępu. W tym scenariuszu identyfikator liczbowy systemu plików NFS jest nadal przekazywany do woluminu NFS usługi Azure NetApp Files, ale istnieje wymóg tłumaczenia identyfikatora liczbowego na nazwę użytkownika systemu UNIX, aby można było go następnie zamapować na nazwę użytkownika systemu Windows na potrzeby uwierzytelniania początkowego. Jeśli na przykład numericzny identyfikator 1001 próbuje uzyskać dostęp do instalacji systemu plików NFS z uprawnieniami stylu zabezpieczeń NTFS, które zezwalają na dostęp do użytkownika systemu Windows "użytkownik1", należy rozpoznać wartość 1001 w protokole LDAP do nazwy użytkownika "user1", aby uzyskać oczekiwany dostęp. Jeśli żaden użytkownik o identyfikatorze liczbowym "1001" nie istnieje w protokole LDAP lub jeśli protokół LDAP jest nieprawidłowo skonfigurowany, mapowanie nazw systemu UNIX na system Windows będzie mieć 1001@contoso.comwartość . W większości przypadków użytkownicy o tej nazwie nie istnieją, więc uwierzytelnianie kończy się niepowodzeniem i odmowa dostępu. Podobnie, jeśli identyfikator liczbowy 1001 zostanie rozpoznany jako nieprawidłowa nazwa użytkownika (na przykład użytkownik2), żądanie systemu plików NFS będzie mapować na nieoczekiwanego użytkownika systemu Windows, a uprawnienia użytkownika będą używać kontroli dostępu "user2".

Włączenie opcji "Zezwalaj lokalnym użytkownikom systemu plików NFS z protokołem LDAP" spowoduje wyłączenie wszystkich tłumaczeń LDAP identyfikatorów liczbowych na nazwy użytkowników, co skutecznie spowoduje przerwanie dostępu do woluminów stylu zabezpieczeń NTFS. W związku z tym użycie tej opcji z woluminami w stylu zabezpieczeń NTFS jest zdecydowanie odradzane.

Schematy LDAP

Schematy LDAP 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 przyspieszenia 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 nie istnieje uidNumber żaden numer 0 UID, żą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.

Udostępnij za pośrednictwem