瞭解 Azure NetApp Files 中的 LDAP 架構
輕量型目錄存取通訊協定 (LDAP) 架構是LDAP伺服器組織和收集資訊的方式。 LDAP 伺服器結構描述通常會遵循相同的標準,但不同的 LDAP 伺服器供應商在結構描述的呈現上可能會有所不同。
當 Azure NetApp Files 查詢 LDAP 時,架構會用來協助加速名稱查閱,因為它們能夠使用特定屬性來尋找使用者的相關信息,例如 UID。 結構描述屬性必須存在於 LDAP 伺服器中,Azure NetApp Files 才能找到項目。 否則,LDAP 查詢可能不會傳回任何資料,而且驗證要求可能會失敗。
例如,如果 Azure NetApp Files 必須查詢 UID 號碼 (如 root=0) ,則會使用結構描述屬性 RFC 2307 uidNumber Attribute
。 如果 uidNumber
欄位中的 LDAP 中沒有 UID 號碼 0
,查閱要求便會失敗。
Azure NetApp Files 目前使用的結構描述類型是以 RFC 2307bis 為基礎的結構描述形式,無法修改。
RFC 2307bis 是 RFC 2307 的擴充功能,並新增對 posixGroup
的支援,其會使用 uniqueMember
屬性來啟用輔助群組的動態查閱,而不是使用 LDAP 結構描述中的 memberUid
屬性。 此屬性不僅運用使用者名稱,還包含 LDAP 資料庫中另一個物件的完整辨別名稱 (DN)。 因此,群組可以有其他群組作為成員,這樣便可使用巢狀群組。 RFC 2307bis 的支援也新增了對物件類別 groupOfUniqueNames
的支援。
此 RFC 擴充功能非常適合 Microsoft Active Directory 透過一般管理工具來管理使用者和群組的方式。 這是因為使用標準 Windows 管理方法將 Windows 使用者新增至群組時 (且該群組具有有效的數值 GID),LDAP 查閱會從一般 Windows 屬性提取必要的補充群組資訊,並自動尋找數值 GID。
當 Azure NetApp Files 磁碟區需要針對 NFS 使用者身分識別執行 LDAP 查閱時,LDAP 架構會根據 RFC-2307bis 定義的一系列屬性。 下表顯示LDAP查閱所使用的屬性,這是使用UNIX屬性時,Microsoft Active Directory 中定義的預設值。 如需適當的功能,請確定這些屬性已正確填入 LDAP 中的使用者和組帳戶。
UNIX 屬性 | LDAP 架構值 |
---|---|
UNIX 用戶名稱 | uid* |
UNIX 用戶數值識別碼 | uidNumber* |
UNIX 組名 | 快遞 之 家* |
UNIX 群組數值標識碼 | gidNumber* |
UNIX 群組成員資格 | 成員** |
UNIX 用戶物件類別 | 使用者** |
UNIX 主目錄 | unixHomeDirectory |
UNIX 顯示名稱 | gecos |
UNIX 用戶密碼 | unixUserPassword |
UNIX 登入殼層 | LoginShell |
用於名稱對應的 Windows 帳戶 | sAMAccountName** |
UNIX 群組物件類別 | 群** |
UNIX成員UID | memberUid*** |
唯一名稱物件類別的 UNIX 群組 | 群** |
* 適當 LDAP 功能的必要屬性
** 預設會在 Active Directory 中填入
不需要
瞭解LDAP屬性索引編製
Active Directory LDAP 提供 屬性的 索引方法,可協助加速查閱要求。 這在大型目錄環境中特別有用,其中LDAP搜尋可能會超過 Azure NetApp Files 中查閱的 10 秒逾時值。 如果搜尋超過逾時值,LDAP 查閱會失敗,而且存取將無法正常運作,因為服務無法驗證要求存取的使用者或群組身分識別。
根據預設,Microsoft Active Directory LDAP 會為 Azure NetApp Files 用於 LDAP 查閱的下列 UNIX 屬性編製索引:
uid 屬性預設不會編製索引。 因此,UID 的LDAP查詢比索引屬性的查詢花費更多時間。
例如,在下列 Active Directory 環境中的查詢測試中,有超過 20,000 個使用者和群組,搜尋具有索引屬性 CN 的用戶大約需要 0.015 秒,而搜尋具有 UID 屬性的相同使用者(預設未編製索引)則較慢 40 倍。
在較小的環境中,這不會造成問題。 但在較大的環境中(或 Active Directory 環境位於內部部署環境或具有高網路等待時間的環境),差異可能足以造成存取問題,讓使用者存取 Azure NetApp Files 磁碟區。 因此,最佳做法是將LDAP中的UID屬性設定為Active Directory 編製索引。
設定要由 Active Directory 編製索引的 UID 屬性
屬性是透過searchFlags
屬性物件的值編製索引,其可透過架構命名內容中的 ADSI Edit 進行設定。 應謹慎使用 ADSI 編輯的存取權,並至少 需要架構管理員 許可權。
根據預設,uid 屬性物件的 searchFlags
會設定為 0x8 (PRESERVE_ON_DELETE)。 此預設設定可確保即使刪除 Active Directory 中的物件,屬性值仍會儲存在目錄中,做為使用者屬性的歷程記錄。
相較之下,在 Active Directory 中針對 LDAP 搜尋編製索引的屬性會有 0x1 的值(或包含該值的一些組合),例如 uidNumber:
因此,uidNumber 的查詢會傳回比 uid 查詢更快。 為了保持一致性和效能,您可以藉由新增 0x1 以及現有的 0x8 值來調整 searchFlags
uid 的值,也就是 (INDEX |PRESERVE_ON_DELETE)。 此新增會在將屬性索引新增至目錄時維護預設行為。
使用索引編製時,使用 uid 搜尋使用者屬性的速度就和搜尋其他索引屬性一樣快。