Principy schémat LDAP ve službě Azure NetApp Files
Schémata protokolu LDAP (Lightweight Directory Access Protocol) jsou způsob, jakým servery LDAP organizují 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.
Při dotazování služby Azure NetApp Files LDAP se schémata používají ke zrychlení 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.
Pokud svazky Azure NetApp Files potřebují pro identity uživatelů NFS provádět vyhledávání protokolu LDAP, řada atributů definovaných schématem LDAP na základě RFC-2307bis. V následující tabulce jsou uvedeny atributy používané vyhledáváním LDAP, což jsou výchozí hodnoty definované v Microsoft Active Directory při použití atributů systému UNIX. Pro správné funkce se ujistěte, že jsou tyto atributy správně vyplněné u uživatelských a skupinových účtů v LDAP.
| Atribut UNIX | Hodnota schématu LDAP |
|---|---|
| Uživatelské jméno systému UNIX | Uid* |
| ČÍSELNÉ ID uživatele systému UNIX | uidNumber* |
| Název skupiny systému UNIX | Kn* |
| Číselné ID skupiny systému UNIX | gidNumber* |
| Členství ve skupinách UNIX | člen** |
| Třída objektu uživatele systému UNIX | Uživatel** |
| Domovský adresář systému UNIX | unixHomeDirectory |
| Zobrazovaný název systému UNIX | gecos |
| Heslo uživatele systému UNIX | unixUserPassword |
| Přihlašovací prostředí systému UNIX | LoginShell |
| Účet Systému Windows používaný pro mapování názvů | sAMAccountName** |
| Třída objektu skupiny SYSTÉMU UNIX | Skupina** |
| UID člena SYSTÉMU UNIX | memberUid*** |
| Skupina UNIX s jedinečnými názvy – třída objektu | Skupina** |
* Povinný atribut pro správné funkce LDAP
** Ve výchozím nastavení naplněno ve službě Active Directory
Nepožaduje se
Principy indexování atributů LDAP
Active Directory LDAP poskytuje metodu indexování atributů , která pomáhá urychlit požadavky vyhledávání. To je zvlášť užitečné v prostředích s velkými adresáři, kde hledání LDAP může potenciálně překročit hodnotu 10sekundového časového limitu pro vyhledávání ve službě Azure NetApp Files. Pokud hledání překročí hodnotu časového limitu, vyhledávání LDAP selže a přístup nebude správně fungovat, protože služba nemůže ověřit identitu uživatele nebo skupiny, která požaduje přístup.
Ve výchozím nastavení bude protokol LDAP služby Microsoft Active Directory indexovat následující atributy UNIX používané službou Azure NetApp Files pro vyhledávání LDAP:
Atribut uid není ve výchozím nastavení indexován. V důsledku toho dotazy LDAP na UID zabírají více času než dotazy na indexované atributy.
Například v následujícím testu dotazu v prostředí Active Directory s více než 20 000 uživateli a skupinami trvalo hledání uživatele s indexovaným atributem CN přibližně 0,015 sekund, zatímco hledání stejného uživatele s atributem UID (které není ve výchozím nastavení indexováno) trvalo přibližně 0,6 sekundy – 40krát pomalejší.
V menšíchprostředích Ale ve větších prostředích (nebo prostředích, kde je prostředí Active Directory místní nebo má vysokou latenci sítě), může být rozdíl dostatečně velký, aby způsoboval problémy s přístupem pro uživatele, kteří přistupují ke svazkům Azure NetApp Files. Proto je osvědčeným postupem nakonfigurovat atribut UID v protokolu LDAP tak, aby se indexoval službou Active Directory.
Konfigurace atributu UID, který má být indexován službou Active Directory
Atributy se indexují prostřednictvím searchFlags hodnoty objektu atributu, který je konfigurovatelný prostřednictvím adsI Edit v kontextu pojmenování schématu. Přístup k úpravám ADSI by měl být přístupný s opatrností a vyžaduje minimální oprávnění správce schématu.
Ve výchozím nastavení je objekt atributu searchFlags uid nastaven na 0x8 (PRESERVE_ON_DELETE). Toto výchozí nastavení zajistí, že i když se objekt ve službě Active Directory odstraní, hodnota atributu zůstane uložená v adresáři jako historický záznam atributu uživatele.
Ve srovnání by atribut indexovaný ve službě Active Directory pro vyhledávání LDAP měl hodnotu 0x1 (nebo některé kombinace, včetně této hodnoty), například uidNumber:
Z tohoto důvodu dotazy na uidNumber vrací rychleji než dotazy uid. Pro konzistenci a výkon můžete upravit searchFlags hodnotu uid na hodnotu 9 přidáním 0x1 spolu s existující hodnotou 0x8, což je (INDEX | PRESERVE_ON_DELETE). Tento doplněk zachovává výchozí chování při přidávání indexování atributů do adresáře.
Při indexování jsou vyhledávání atributů uživatele s uid stejně rychlé jako hledání dalších indexovaných atributů.