Vysvětlení použití protokolu LDAP se službou Azure NetApp Files

Článek
06/13/2024

Protokol LDAP (Lightweight Directory Access Protocol) je standardní přístupový protokol adresáře, který vyvinul mezinárodní výbor s názvem IETF (Internet Engineering Task Force). Protokol LDAP je určen k poskytování adresářové služby založené na obecném účelu, kterou můžete použít napříč heterogenními platformami k vyhledání síťových objektů.

Modely LDAP definují, jak komunikovat s úložištěm adresářů LDAP, jak najít objekt v adresáři, jak popsat objekty v úložišti a zabezpečení, které se používá pro přístup k adresáři. LDAP umožňuje přizpůsobení a rozšíření objektů popsaných v úložišti. Úložiště LDAP proto můžete použít k ukládání mnoha typů různorodých informací. Mnoho počátečních nasazení LDAP se zaměřilo na použití PROTOKOLU LDAP jako úložiště adresářů pro aplikace, jako jsou e-maily a webové aplikace a ukládání informací o zaměstnancích. Řada společností nahrazuje službu NIS (Network Information Service) protokolem LDAP jako síťové úložiště adresářů.

Server LDAP poskytuje identity uživatelů a skupin systému UNIX pro použití se svazky NAS. Ve službě Azure NetApp Files je Active Directory jediným aktuálně podporovaným serverem LDAP, který je možné použít. Tato podpora zahrnuje Doména služby Active Directory Services (AD DS) i službu Microsoft Entra Domain Services.

Požadavky LDAP je možné rozdělit do dvou hlavních operací.

Vazby LDAP jsou přihlášení k serveru LDAP z klienta LDAP. Vazba se používá k ověření na serveru LDAP s přístupem jen pro čtení k provádění vyhledávání PROTOKOLU LDAP. Azure NetApp Files funguje jako klient LDAP.
Vyhledávání LDAP slouží k dotazování adresáře na informace o uživatelích a skupinách, jako jsou jména, číselná ID, cesty k domovskému adresáři, cesty k přihlašovacím prostředím, členství ve skupinách a další.

Protokol LDAP může ukládat následující informace, které se používají v přístupu k NAS se dvěma protokoly:

Uživatelská jména
Názvy skupin
ID čísel (UID) a ID skupin (GID)
Domovské adresáře
Přihlašovací prostředí
Netgroups, názvy DNS a IP adresy
Členství ve skupině

Azure NetApp Files v současné době používá protokol LDAP jenom pro informace o uživatelích a skupinách – žádné informace o netgroup ani hostitelích.

Ldap nabízí uživatelům a skupinám UNIX různé výhody jako zdroj identity.

Ldap je důkazem o budoucnosti.
Vzhledem k tomu, že více klientů NFS přidává podporu pro NFSv4.x, NFSv4.x ID domény, které obsahují aktuální seznam uživatelů a skupin přístupných z klientů a úložiště, jsou potřeba k zajištění optimálního zabezpečení a zaručeného přístupu při definování přístupu. Když máte server pro správu identit, který poskytuje mapování názvů 1:1 pro uživatele SMB a NFS, výrazně zjednodušuje život správcům úložiště, nejen v současnosti, ale i po letech.
LDAP je škálovatelný.
Servery LDAP nabízejí možnost obsahovat miliony objektů uživatelů a skupin a s Microsoft Active Directory je možné použít k replikaci více serverů napříč několika lokalitami pro zajištění výkonu i odolnosti.
Protokol LDAP je zabezpečený.
LDAP nabízí zabezpečení ve formě způsobu, jakým se systém úložiště může připojit k serveru LDAP, aby mohl vyhovět žádostem o informace o uživateli. Servery LDAP nabízejí následující úrovně vazby:
- Anonymní (ve výchozím nastavení zakázáno v Microsoft Active Directory, nepodporuje se ve službě Azure NetApp Files)
- Jednoduché heslo (hesla ve formátu prostého textu, nepodporuje se v Azure NetApp Files)
- Simple Authentication and Security Layer (SASL) – šifrované metody vazby, včetně TLS, SSL, Kerberos atd. Azure NetApp Files podporuje protokol LDAP přes PROTOKOL TLS, podepisování LDAP (pomocí protokolu Kerberos), LDAP přes PROTOKOL SSL.
LDAP je robustní.
Nis, NIS+ a místní soubory nabízejí základní informace, jako jsou UID, GID, heslo, domovské adresáře atd. Ldap ale nabízí tyto atributy a mnoho dalších. Další atributy, které ldap používá, činí správu duálních protokolů mnohem integrovanější s protokolem LDAP a NIS. Jako externí názvovou službu pro správu identit pomocí služby Azure NetApp Files se podporuje jenom LDAP.
Služba Microsoft Active Directory je založená na protokolu LDAP.
Služba Microsoft Active Directory ve výchozím nastavení používá back-end LDAP pro své položky uživatele a skupiny. Tato databáze LDAP však neobsahuje atributy stylu systému UNIX. Tyto atributy se přidají při rozšíření schématu LDAP prostřednictvím správy identit pro UNIX (Windows 2003R2 a novější), služby pro UNIX (Windows 2003 a starší) nebo nástrojů LDAP třetích stran, jako je Centrify. Vzhledem k tomu, že Microsoft používá protokol LDAP jako back-end, představuje protokol LDAP ideální řešení pro prostředí, která se rozhodnou využívat svazky se dvěma protokoly v Azure NetApp Files.

Poznámka:

Služba Azure NetApp Files v současné době podporuje pouze nativní službu Microsoft Active Directory pro služby LDAP.

Základy PROTOKOLU LDAP ve službě Azure NetApp Files

Následující část popisuje základy PROTOKOLU LDAP, které se týkají služby Azure NetApp Files.

Informace LDAP jsou uloženy v plochých souborech na serveru LDAP a jsou uspořádány pomocí schématu LDAP. Klienti LDAP byste měli nakonfigurovat způsobem, který koordinuje jejich požadavky a vyhledávání se schématem na serveru LDAP.
Klienti LDAP iniciují dotazy prostřednictvím vazby protokolu LDAP, což je v podstatě přihlášení k serveru LDAP pomocí účtu, který má ke schématu LDAP přístup pro čtení. Konfigurace vazby protokolu LDAP na klientech je nakonfigurována tak, aby používala mechanismus zabezpečení definovaný serverem LDAP. Někdy se jedná o výměnu uživatelských jmen a hesel v prostém textu (jednoduchém). V jiných případech jsou vazby zabezpečené prostřednictvím metod jednoduchého ověřování a vrstvy zabezpečení (sasl), jako je Kerberos nebo LDAP přes PROTOKOL TLS. Azure NetApp Files používá účet počítače SMB k vytvoření vazby pomocí ověřování SASL za účelem co nejlepšího možného zabezpečení.
Informace o uživatelích a skupinách uložené v protokolu LDAP se dotazují klienty pomocí standardních požadavků vyhledávání LDAP definovaných v dokumentu RFC 2307. Kromě toho novější mechanismy, jako je RFC 2307bis, umožňují efektivnější vyhledávání uživatelů a skupin. Azure NetApp Files používá pro vyhledávání schématu ve Windows Active Directory formu RFC 2307bis.
Servery LDAP mohou ukládat informace o uživateli a skupinách a netgroup. Služba Azure NetApp Files ale v současné době nemůže používat funkce netgroup v protokolu LDAP ve Službě Windows Active Directory.
LDAP v Azure NetApp Files funguje na portu 389. Tento port se momentálně nedá upravit tak, aby používal vlastní port, například port 636 (LDAP přes SSL) nebo port 3268 (vyhledávání globálního katalogu služby Active Directory).
Šifrované komunikace LDAP lze dosáhnout pomocí protokolu LDAP přes protokol TLS (který funguje přes port 389) nebo podepisování protokolu LDAP, z nichž obě je možné nakonfigurovat pro připojení služby Active Directory.
Azure NetApp Files podporuje dotazy LDAP, které dokončení trvá déle než 3 sekundy. Pokud má server LDAP mnoho objektů, může dojít k překročení časového limitu a žádosti o ověření můžou selhat. V takových případech zvažte zadání oboru vyhledávání LDAP pro filtrování dotazů pro zajištění lepšího výkonu.
Azure NetApp Files také podporuje zadávání upřednostňovaných serverů LDAP, které pomáhají urychlit požadavky. Toto nastavení použijte, pokud chcete zajistit, aby se server LDAP nejblíže vaší oblasti Azure NetApp Files používal.

Pokud není nastavený žádný upřednostňovaný server LDAP, je název domény služby Active Directory dotazován v DNS pro záznamy služby LDAP, aby se naplnil seznam serverů LDAP dostupných pro vaši oblast umístěnou v tomto záznamu SRV. Záznamy služby LDAP v DNS můžete ručně dotazovat z klienta pomocí nslookup nebo dig příkazů.

Příklad:

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

Servery LDAP lze také použít k provádění mapování vlastních názvů pro uživatele. Další informace naleznete v tématu Mapování vlastních názvů pomocí protokolu LDAP.
Vypršení časových limitů dotazů LDAP

Ve výchozím nastavení vyprší časový limit dotazů LDAP, pokud se včas nedokončí. Pokud dotaz LDAP selže kvůli vypršení časového limitu, vyhledávání uživatele nebo skupiny selže a v závislosti na nastavení oprávnění svazku může být odepřen přístup ke svazku Azure NetApp Files. Informace o nastavení časového limitu dotazů LDAP služby Azure NetApp Files najdete v tématu Vytvoření a správa připojení Active Directory.

Typy mapování názvů

Pravidla mapování názvů je možné rozdělit do dvou hlavních typů: symetrické a asymetrické.

Mapování symetrických názvů je implicitní mapování názvů mezi uživateli systému UNIX a Windows, kteří používají stejné uživatelské jméno. Například uživatel CONTOSO\user1 systému Windows se mapuje na uživatele user1systému UNIX .
Asymetrické mapování názvů je mapování názvů mezi uživateli systému UNIX a Windows, kteří používají různá uživatelská jména. Například uživatel CONTOSO\user1 systému Windows se mapuje na uživatele user2systému UNIX .

Služba Azure NetApp Files ve výchozím nastavení používá pravidla mapování symetrických názvů. Pokud jsou vyžadována pravidla mapování asymetrických názvů, zvažte konfiguraci objektů uživatele LDAP tak, aby je používaly.

Mapování vlastních názvů pomocí protokolu LDAP

Ldap může být prostředek mapování názvů, pokud byly vyplněny atributy schématu LDAP na serveru LDAP. Chcete-li například namapovat uživatele systému UNIX na odpovídající uživatelská jména systému Windows, která neodpovídají jednomu k jednomu druhému (tj . asymetricky), můžete v uid objektu uživatele zadat jinou hodnotu, než je nakonfigurované pro uživatelské jméno systému Windows.

V následujícím příkladu má uživatel název asymmetric systému Windows a musí namapovat na identitu systému UNIX .UNIXuser Pokud toho chcete dosáhnout v Azure NetApp Files, otevřete instanci Uživatelé a počítače služby Active Directory MMC. Pak vyhledejte požadovaného uživatele a otevřete pole vlastností. (To vyžaduje povolení editoru atributů). Přejděte na kartu Editor atributů a vyhledejte pole UID a potom vyplňte pole UID požadovaným uživatelským jménem UNIXuser systému UNIX a potvrďte akci kliknutím na tlačítko Přidat a OK .

Po dokončení této akce budou soubory zapsané ze sdílených složek SMB systému Windows uživatelem asymmetric systému Windows vlastněny UNIXuser ze strany SYSTÉMU SOUBORŮ NFS.

Následující příklad ukazuje vlastníka asymmetricprotokolu SMB systému Windows:

Následující příklad ukazuje vlastníka UNIXuser systému souborů NFS (namapovaný od uživatele asymmetric Windows pomocí PROTOKOLU 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

Povolit místní uživatele systému souborů NFS s protokolem LDAP

Když se uživatel pokusí získat přístup ke svazku Azure NetApp Files přes systém souborů NFS, žádost se zobrazí v číselném ID. Azure NetApp Files ve výchozím nastavení podporuje rozšířená členství ve skupinách pro uživatele systému souborů NFS (pokud chcete překročit standardní limit 16 skupin). V důsledku toho se azure NetApp files pokusí vzít toto číselné ID a vyhledat ho v protokolu LDAP při pokusu o vyřešení členství ve skupinách pro uživatele, a ne předání členství ve skupinách v paketu RPC. Vzhledem k tomuto chování, pokud toto číselné ID nelze přeložit na uživatele v protokolu LDAP, vyhledávání selže a přístup bude odepřen – i když má žádající uživatel oprávnění pro přístup ke svazku nebo datové struktuře. Možnost Povolit místním uživatelům systému souborů NFS s možností LDAP v připojeních služby Active Directory je určena k zakázání těchto vyhledávání PROTOKOLU LDAP pro požadavky NFS zakázáním rozšířených funkcí skupiny. V Azure NetApp Files neposkytuje místní vytváření a správu uživatelů.

Pokud je povolená možnost Povolit místním uživatelům NFS s protokolem LDAP, předají se do služby Azure NetApp Files číselná ID a neprovádí se žádné vyhledávání PROTOKOLU LDAP. To vytváří různá chování pro různé scénáře, jak je popsáno níže.

NFSv3 se svazky se stylem zabezpečení systému UNIX

Číselná ID se nemusí překládat na uživatelská jména. Možnost Povolit místním uživatelům NFS s protokolem LDAP nebude mít vliv na přístup ke svazku, ale může mít vliv na to, jak se v klientovi NFS zobrazí vlastnictví uživatele nebo skupiny (překlad názvů). Pokud je například číselné ID 1001 uživatelem 1 v protokolu LDAP, ale je uživatelem 2 v místním souboru passwd klienta SYSTÉMU SOUBORŮ NFS, zobrazí se jako vlastník souboru uživatel2, pokud je číselné ID 1001.

NFSv4.1 se svazky stylů zabezpečení UNIX

Číselná ID se nemusí překládat na uživatelská jména. Ve výchozím nastavení používá NFSv4.1 pro ověřování řetězce názvů (user@CONTOSO.COM). Azure NetApp Files ale podporuje použití číselných ID se systémem souborů NFSV4.1, což znamená, že požadavky NFSv4.1 dorazí na server NFS s číselným ID. Pokud v místních souborech nebo názvových službách, jako je LDAP pro svazek Azure NetApp Files, neexistuje žádné číselné ID pro překlad uživatelského jména, zobrazí se klientovi číslo. Pokud se číselné ID přeloží na uživatelské jméno, použije se řetězec s názvem. Pokud se řetězec názvu neshoduje, klient zmáčkne jméno anonymnímu uživateli zadanému v souboru idmapd.conf klienta. Povolení možnosti Povolit místním uživatelům NFS s protokolem LDAP nebude mít vliv na přístup NFSv4.1, protože se vrátí ke standardnímu chování NFSv3, pokud Azure NetApp Files nedokáže přeložit číselné ID na uživatelské jméno v místní uživatelské databázi NFS. Služba Azure NetApp Files má sadu výchozích uživatelů systému UNIX, kteří můžou být pro některé klienty problematické, a pokud se řetězce ID domény neshodují, může být pro některé klienty problematické.

Mezi místní uživatele patří: root (0), pcuser (65534), nikdo (65535).
Mezi místní skupiny patří: root (0), démon (1), pcuser (65534), nikdo (65535).

Nejčastěji se v připojení klienta NFSv4.1 může nesprávně zobrazovat kořen, když je ID domény NFSv4.1 chybně nakonfigurované. Další informace o doméně ID NFSv4.1 najdete v tématu Konfigurace domény ID NFSv4.1 pro Azure NetApp Files.

Seznamy ACL NFSv4.1 je možné nakonfigurovat pomocí řetězce názvu nebo číselného ID. Pokud se použijí číselná ID, nevyžaduje se překlad názvů. Pokud se použije řetězec názvu, bude se pro správné rozlišení seznamu ACL vyžadovat překlad názvů. Při použití seznamů ACL NFSv4.1 může povolení možnosti Povolit místním uživatelům NFS s protokolem LDAP způsobit nesprávné chování seznamu ACL NFSv4.1 v závislosti na konfiguraci seznamu ACL.

NFS (v3 a v4.1) se svazky se stylem zabezpečení NTFS v konfiguracích se dvěma protokoly

Svazky stylů zabezpečení systému UNIX využívají oprávnění pro styl UNIX (bity režimu a seznamy ACL NFSv4.1). Pro tyto typy svazků využívá systém NFS pouze ověřování ve stylu UNIX s využitím číselného ID nebo řetězce názvu v závislosti na výše uvedených scénářích. Svazky se stylem zabezpečení NTFS ale používají oprávnění ke stylu SYSTÉMU SOUBORŮ NTFS. Tato oprávnění se přiřazují pomocí uživatelů a skupin Windows. Když se uživatel systému souborů NFS pokusí získat přístup ke svazku s oprávněním stylu NTFS, musí dojít k mapování názvů systému UNIX na Systém Windows, aby se zajistilo správné řízení přístupu. V tomto scénáři je číselné ID systému souborů NFS stále předáno svazku NFS služby Azure NetApp Files, ale existuje požadavek na překlad číselného ID na uživatelské jméno systému UNIX, aby bylo možné ho pak namapovat na uživatelské jméno systému Windows pro počáteční ověření. Pokud se například číselné ID 1001 pokusí o přístup k připojení systému souborů NFS s oprávněními typu zabezpečení NTFS, které umožňují přístup k uživateli Windows user1, bude potřeba přeložit číslo 1001 v protokolu LDAP na uživatelské jméno "user1", aby bylo možné získat očekávaný přístup. Pokud v protokolu LDAP neexistuje žádný uživatel s číselným ID "1001" nebo pokud je ldap chybně nakonfigurovaný, bude mapování názvů systému UNIX na windows, které se pokusíte.1001@contoso.com Ve většině případů neexistují uživatelé s tímto názvem, takže ověřování selže a přístup se odepře. Podobně platí, že pokud se číselné ID 1001 přeloží na nesprávné uživatelské jméno (například user2), požadavek NFS se namapuje na neočekávaný uživatel Windows a oprávnění pro uživatele budou používat řízení přístupu "user2".

Povolením možnosti Povolit místním uživatelům NFS s protokolem LDAP zakážete všechny překlady číselNÝCH ID na uživatelská jména, což efektivně přeruší přístup ke svazkům se stylem zabezpečení NTFS. Použití této možnosti u svazků se stylem zabezpečení NTFS se proto důrazně nedoporučuje.

Schémata LDAP

Schémata LDAP jsou způsob, jakým servery LDAP uspořádávají a shromažďují informace. Schémata serveru LDAP obecně odpovídají stejným standardům, ale různí poskytovatelé serveru LDAP můžou mít různé varianty způsobu zobrazení schémat.

Když Služba Azure NetApp Files dotazuje LDAP, používají se schémata, která pomáhají zrychlit vyhledávání názvů, protože umožňují použití konkrétních atributů k vyhledání informací o uživateli, jako je například UID. Atributy schématu musí existovat na serveru LDAP, aby služba Azure NetApp Files mohla položku najít. V opačném případě můžou dotazy LDAP vracet žádná data a žádosti o ověření nemusí selhat.

Pokud například musí azure NetApp Files dotazovat číslo UID (například root=0), použije se atribut schématu RFC 2307 uidNumber Attribute . Pokud v poli není v uidNumber protokolu LDAP žádné číslo 0 UID, požadavek vyhledávání selže.

Typ schématu aktuálně používaný službou Azure NetApp Files je forma schématu založená na dokumentu RFC 2307bis a nedá se upravit.

RFC 2307bis je rozšíření RFC 2307 a přidává podporu pro posixGroup, což umožňuje dynamické vyhledávání pomocných skupin pomocí uniqueMember atributu, nikoli pomocí memberUid atributu ve schématu LDAP. Místo použití pouze názvu uživatele tento atribut obsahuje úplný rozlišující název (DN) jiného objektu v databázi LDAP. Proto mohou mít skupiny jiné skupiny jako členy, což umožňuje vnořování skupin. Podpora RFC 2307bis také přidává podporu pro třídu groupOfUniqueNamesobjektů .

Toto rozšíření RFC pěkně zapadá do toho, jak Microsoft Active Directory spravuje uživatele a skupiny prostřednictvím obvyklých nástrojů pro správu. Důvodem je to, že když přidáte uživatele systému Windows do skupiny (a pokud má tato skupina platné číselné GID) pomocí standardních metod správy systému Windows, vyhledávání LDAP načte potřebné doplňující informace o skupině z obvyklého atributu Systému Windows a automaticky vyhledá číselné IDENTIFIKÁTORy GID.

Sdílet prostřednictvím