共用方式為

了解搭配 Azure NetApp Files 使用 LDAP 的方法

  • 發行項

輕量型目錄存取協定 (LDAP) 是由名為 Internet Engineering Task Force (IETF) 的國際委員會制定的標準目錄存取協定。 LDAP 旨在提供一般用途的網路型目錄服務，可供您跨異質平台使用來找到網路物件。

LDAP 模型會定義如何與 LDAP 目錄存放區通訊、如何在目錄中尋找物件、如何描述存放區中的物件，以及用來存取目錄的安全性。 LDAP 允許對存放區中所描述的物件進行自訂和擴充。 因此，您可以使用 LDAP 存放區來儲存多種類型的資訊。 許多初始 LDAP 部署著重於使用 LDAP 作為應用程式目錄存放區，例如電子郵件和 Web 應用程式，以及儲存員工資訊。 許多公司正在取代或已取代網路資訊服務 (NIS)，以 LDAP 作為網路目錄存放區。

LDAP 伺服器提供 UNIX 使用者和群組身分識別，以搭配 NAS 磁碟區使用。 在 Azure NetApp Files 中，Active Directory 是目前唯一可使用的 LDAP 伺服器。 此支援包括 Active Directory Domain Services (AD DS) 和 Microsoft Entra Domain Services。

LDAP 要求可以細分成兩個主要作業。

  • LDAP 繫結是從 LDAP 用戶端登入 LDAP 伺服器的程序。 繫結可用來向具有唯讀存取權的 LDAP 伺服器進行驗證，以執行 LDAP 查閱。 Azure NetApp Files 會扮演 LDAP 用戶端的角色。
  • LDAP 查閱可用來查詢目錄以取得使用者和群組資訊，例如名稱、數值識別碼、主目錄路徑、登入殼層路徑、群組成員資格等等。

LDAP 可以儲存用於雙重通訊協定 NAS 存取中的下列資訊：

  • 使用者名稱
  • 群組名稱
  • 數值使用者識別碼 (UID) 和群組識別碼 (GID)
  • 主目錄
  • 登入殼層
  • Netgroups、DNS 名稱和 IP 位址
  • 群組成員資格

目前，Azure NetApp Files 只會對使用者和群組資訊使用 LDAP，沒有 netgroup 或主機資訊。

LDAP 作為身分識別來源，為您的 UNIX 使用者和群組提供了各項優點。

  • LDAP 具有未來發展潛力。
    隨著越來越多 NFS 用戶端新增對 NFSv4.x 的支援，NFSv4.x 識別碼網域必須包含可從用戶端和儲存體存取的使用者和群組最新清單，以確保定義存取時，獲得最佳安全性和保證存取。 擁有身分識別管理伺服器，可為 SMB 和 NFS 使用者提供一對一的名稱對應，對儲存體系統管理員而言，不僅現在可大大地簡化生活中的工作，而且在未來幾年也是如此。
  • LDAP 可調整。
    LDAP 伺服器可讓您包含數百萬個使用者和群組物件，而且使用 Microsoft Active Directory，多部伺服器可用來跨多個網站複寫，以提高性能和復原規模。
  • LDAP 是安全的。
    LDAP 提供安全性，讓儲存體系統能連線到 LDAP 伺服器，以取得使用者資訊。 LDAP 伺服器提供下列繫結層級：
    • 匿名 (在 Microsoft Active Directory 中預設為停用；Azure NetApp Files 中不支援)
    • 簡單密碼 (純文字密碼；Azure NetApp Files 中不支援)
    • 簡單驗證及安全性階層 (SASL) – 加密的繫結方法，包括 TLS、SSL、Kerberos 等等。 Azure NetApp Files 支援 LDAP over TLS、LDAP 簽署 (使用 Kerberos)、LDAP over SSL。
  • LDAP 穩定可靠。
    NIS、NIS+ 和本機檔案提供 UID、GID、密碼、主目錄等基本資訊。 不過，LDAP 不僅提供這些屬性，更包含許多其他屬性。 LDAP 使用的其他屬性可讓雙重通訊協定管理與 LDAP 與 NIS 更加整合。 僅支援 LDAP 作為外部名稱服務，以便使用 Azure NetApp Files 進行身分識別管理。
  • Microsoft Active Directory 是以 LDAP 為基礎所建置。
    根據預設，Microsoft Active Directory 會對其使用者和群組項目使用 LDAP 後端服務。 不過，此 LDAP 資料庫並不包含 UNIX 樣式屬性。 在 LDAP 結構描述透過 UNIX 的身分識別管理 (Windows 2003R2 和更新版本)、UNIX 服務 (Windows 2003 和更早版本) 或 Centrify 等第三方 LDAP 工具擴充時，就會新增這些屬性。 因為 Microsoft 使用 LDAP 作為後端服務，因此對於選擇在 Azure NetApp Files 中使用雙重通訊協定磁碟區的使用者而言，LDAP 是完美的解決方案。

    注意

    Azure NetApp Files 目前僅支援適用於 LDAP 服務的原生 Microsoft Active Directory。

Azure NetApp Files 中的 LDAP 基本概念

下一節將討論 LDAP 的基本概念，因為它與 Azure NetApp Files 相關。

  • LDAP 資訊會儲存在 LDAP 伺服器的一般檔案中，並透過 LDAP 結構描述進行整理。 您應該設定 LDAP 用戶端，以協調其要求和查閱與 LDAP 伺服器上的結構描述保持一致。

  • LDAP 用戶端會透過 LDAP 繫結來起始查詢，這基本上是使用具有 LDAP 結構描述讀取存取的帳戶登入 LDAP 伺服器。 用戶端上的 LDAP 繫結組態已設定為使用 LDAP 伺服器所定義的安全性機制。 有時候，它們是純文字的使用者名稱和密碼交換 (簡單)。 在其他情況下，繫結會透過簡單驗證及安全性階層的方法 (sasl) 來加以保護，例如 Kerberos 或 LDAP over TLS，。 Azure NetApp Files 會使用 SMB 電腦帳戶來繫結使用 SASL 驗證，以獲得最佳安全性。

  • 用戶端會使用 RFC 2307 中所定義的標準 LDAP 搜尋要求來查詢儲存在 LDAP 中的使用者和群組資訊。 此外，如 RFC 2307bis 的較新機制，允許更加精簡的使用者和群組查閱。 Azure NetApp Files 會使用 RFC 2307bis 的形式，在 Windows Active Directory 中查閱結構描述。

  • LDAP 伺服器可以儲存使用者和群組資訊以及 netgroup。 不過，Azure NetApp Files 目前無法在 Windows Active Directory 上的 LDAP 中使用 netgroup 功能。

  • Azure NetApp Files 中的 LDAP 會在連接埠 389 上運作。 此埠目前無法修改為使用自定義埠，例如埠 636 （LDAP over SSL） 或埠 3268 （Active Directory 全域編錄搜尋）。

  • 加密 LDAP 通訊可以使用 LDAP over TLS 來達成 (透過連接埠 389 運作) 或 LDAP 簽署，這兩者都可以在 Active Directory 連線上設定。

  • Azure NetApp Files 支援的 LDAP 查詢完成時間不超過 3 秒。 如果 LDAP 伺服器有許多物件，可能會超過該逾時，而且驗證要求可能會失敗。 在這些情況下，請考慮指定 LDAP 搜尋範圍來篩選查詢以提升效能。

  • Azure NetApp Files 也支援指定慣用的 LDAP 伺服器，以協助加速要求。 若要確保使用最接近 Azure NetApp Files 區域的 LDAP 伺服器，請使用此設定。

  • 如果未設定慣用 LDAP 伺服器，則會在 DNS 中查詢 Active Directory 網域名稱，以取得 LDAP 服務記錄，以填入位於該 SRV 記錄內所在區域可用的 LDAP 伺服器清單。 您可以使用 nslookup 或 dig 命令，從用戶端手動查詢 DNS 中的 LDAP 服務記錄。

    例如：

    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

  • LDAP 伺服器也可以用來為使用者執行自訂名稱對應。 如需詳細資訊，請參閱使用 LDAP 的自訂名稱對應 (部分機器翻譯)。

  • LDAP 查詢等候逾時

    根據預設，如果LDAP查詢無法及時完成，就會逾時。 如果 LDAP 查詢因逾時而失敗，使用者和/或群組查閱將會失敗，而且視磁碟區的權限設定而定，可能會拒絕存取 Azure NetApp Files 磁碟區。 請參閱建立和管理 Active Directory 連線 (部分機器翻譯)，了解 Azure NetApp Files LDAP 查詢逾時設定。

名稱對應類型

名稱對應規則可以細分為兩種主要類型：對稱和非對稱。

  • 對稱名稱對應是指 UNIX 與 Windows 使用者之間，使用相同使用者名稱的隱含名稱對應。 例如，Windows 使用者 CONTOSO\user1 會對應至 UNIX 使用者 user1。
  • 非對稱名稱對應是指 UNIX 與 Windows 使用者之間，使用不同使用者名稱的名稱對應。 例如，Windows 使用者 CONTOSO\user1 會對應至 UNIX 使用者 user2。

根據預設，Azure NetApp Files 會使用對稱的名稱對應規則。 如果需要非對稱的名稱對應規則，請考慮設定 LDAP 使用者物件來使用它們。

使用 LDAP 的自訂名稱對應

如果 LDAP 伺服器上的 LDAP 結構描述屬性已填入，LDAP 可以作為名稱對應資源。 例如，若要將 UNIX 使用者對應至不符合一對一的相對 Windows 使用者名稱 (也就是非對稱)，您可以在使用者物件中指定與 Windows 使用者名稱所設定不同的 uid 值。

在下列範例中，使用者具有 Windows 名稱 asymmetric，且必須對應至的 UNIXuser 的UNIX 身分識別。 若要在 Azure NetApp Files 中達到此目的，請開啟 Active Directory 使用者和電腦 MMC 的執行個體。 然後，尋找所需的使用者並開啟屬性方塊。 (這樣做需要啟用屬性編輯器)。 瀏覽至 [屬性編輯器] 索引標籤並尋找 UID 欄位，然後使用所需的 UNIX 使用者名稱 UNIXuser 填入 UID 欄位，並按一下 [新增] 和 [確定] 進行確認。

顯示非對稱 屬性視窗和多重值字串編輯器視窗的螢幕快照。

完成此動作之後，Windows 使用者 asymmetric 從 Windows SMB 共用寫入的檔案將會由 NFS 端的 UNIXuser 擁有。

下列範例顯示 Windows SMB 擁有者 asymmetric：

顯示名為非對稱 Windows SMB 擁有者的螢幕快照。

下列範例顯示 NFS 擁有者 UNIXuser (使用 LDAP 從 Windows 使用者 asymmetric 對應)：

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

允許具有 LDAP 的本機 NFS 使用者

使用者嘗試透過 NFS 來存取 Azure NetApp Files 磁碟區時，要求會以數值識別碼表示。 根據預設，Azure NetApp Files 支援 NFS 用戶的擴充群組成員資格（超出標準 16 個群組限制）。 因此，Azure NetApp 檔案會嘗試取得該數值標識碼，並在LDAP中查閱它，以嘗試解析使用者的群組成員資格，而不是在 RPC 封包中傳遞群組成員資格。 由於此行為，如果該數值標識符無法解析為LDAP中的使用者，查閱將會失敗，而且存取將會遭到拒絕，即使要求的使用者有權存取磁碟區或數據結構也一樣。 Active Directory 連線中的允許具有 LDAP 的本機 NFS 使用者選項旨在停用擴充群組功能，以停用 NFS 要求的這些 LDAP 查閱。 其不會在 Azure NetApp Files 內提供「本機使用者建立/管理」。

啟用 [允許具有LDAP的本機 NFS 使用者] 選項時，數值標識符會傳遞至 Azure NetApp Files，而且不會執行 LDAP 查閱。 這會為不同的案例建立不同的行為，如下所述。

具有 UNIX 安全性樣式磁碟區的 NFSv3

數值標識碼不需要轉譯為用戶名稱。 [允許具有LDAP 的本機 NFS 使用者] 選項不會影響磁碟區的存取，但可能會影響 NFS 用戶端上顯示使用者/群組擁有權（名稱轉譯）的方式。 例如，如果 1001 的數值標識碼是 LDAP 中的 user1，但在 NFS 用戶端的本機 passwd 檔案上是 user2，則當數值標識符為 1001 時，用戶端將會將 “user2” 顯示為檔案的擁有者。

具有 UNIX 安全性樣式磁碟區的 NFSv4.1

數值標識碼不需要轉譯為用戶名稱。 根據預設，NFSv4.1 會使用名稱字串 （user@CONTOSO.COM） 進行驗證。 不過，Azure NetApp Files 支援搭配 NFSV4.1 使用數值識別碼，這表示 NFSv4.1 要求會抵達具有數值標識碼的 NFS 伺服器。 如果 Azure NetApp Files 磁碟區的 LDAP 之類的本機檔案或名稱服務中沒有使用者名稱轉譯的數位識別碼，則會向客戶端顯示數值。 如果數值標識碼轉譯為用戶名稱，則會使用名稱字串。 如果名稱字串不相符，用戶端會將名稱壓縮至用戶端 idmapd.conf 檔案中指定的匿名使用者。 啟用 [允許具有LDAP的本機 NFS 使用者] 選項不會影響 NFSv4.1 存取，因為除非 Azure NetApp Files 可以將數值標識符解析為其本機 NFS 使用者資料庫中的使用者名稱，否則它會回復為標準 NFSv3 行為。 Azure NetApp Files 有一組預設的 UNIX 使用者，如果網域標識符字串不相符，某些用戶端可能會有問題，並壓縮成「沒有人」使用者。

  • 當地使用者包括：root （0），pcuser （65534），沒有人（65535）。
  • 本地組包括：根（0），精靈（1），pcuser（65534），沒有人（65535）。

最常見的是，當 NFSv4.1 網域標識符設定錯誤時，NFSv4.1 用戶端掛接的根可能會不正確。 如需 NFSv4.1 標識符網域的詳細資訊，請參閱 設定 Azure NetApp Files 的 NFSv4.1 標識符網域。

您可以使用名稱字串或數值識別碼來設定 NFSv4.1 ACL。 如果使用數值標識碼，則不需要名稱轉譯。 如果使用名稱字串，則需要名稱轉譯才能進行適當的 ACL 解析。 使用 NFSv4.1 ACL 時，啟用「允許具有LDAP的本機 NFS使用者」，可能會根據 ACL 設定造成不正確的 NFSv4.1 ACL 行為。

NFS （v3 和 v4.1） 在雙重通訊協議設定中具有NTFS安全性樣式磁碟區

UNIX 安全性樣式磁碟區會利用 UNIX 樣式許可權（模式位和 NFSv4.1 ACL）。 針對這些類型的磁碟區，NFS 只會利用利用數值標識碼或名稱字串的 UNIX 樣式驗證，視上述案例而定。 不過，NTFS 安全性樣式磁碟區會使用NTFS樣式許可權。 這些許可權是使用 Windows 使用者和群組來指派。 當 NFS 使用者嘗試存取具有 NTFS 樣式許可權的磁碟區時，必須發生 UNIX 到 Windows 名稱對應，以確保適當的訪問控制。 在此案例中，NFS 數值標識符仍會傳遞至 Azure NetApp Files NFS 磁碟區，但需要將數值標識符轉譯為 UNIX 用戶名稱，以便接著對應至 Windows 用戶名稱以進行初始驗證。 例如，如果數值標識碼 1001 嘗試使用允許存取 Windows 使用者 “user1” 的 NTFS 安全性樣式許可權來存取 NFS 掛接，則必須在 LDAP 中解析為 “user1” 使用者名稱，才能取得預期的存取權。 如果 LDAP 中沒有數位識別碼為 「1001」 的使用者存在，或 LDAP 設定錯誤，則嘗試的 UNIX 與 Windows 名稱對應將會是 1001@contoso.com。 在大部分情況下，具有該名稱的使用者不存在，因此驗證失敗並拒絕存取。 同樣地，如果數值標識碼 1001 解析為錯誤的用戶名稱（例如 user2），則 NFS 要求會對應至非預期的 Windows 使用者，而使用者的許可權將會使用 “user2” 訪問控制。

啟用「允許具有LDAP的本機 NFS使用者」將會停用使用者名稱的所有LDAP轉譯，這會有效地中斷對NTFS安全性樣式磁碟區的存取。 因此，強烈建議不要搭配NTFS安全性樣式磁碟區使用此選項。

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。

下一步