了解 Azure NetApp Files 中的 Kerberos

發行項
02/04/2025

Kerberos 是一種驗證通訊協定，會使用秘密密鑰來驗證主體的身分識別。秘密金鑰是藉由取得主體的密碼，並使用用戶端和伺服器（例如 AES）同意的加密方法，將它轉換成哈希密碼編譯密鑰格式來產生。請參閱 Kerberos 術語一節，以瞭解本檔中使用的詞彙。

Windows Active Directory 等密鑰發佈中心（KDC）會維護 Kerberos 主體的資料庫及其哈希密碼。在 Kerberos 中，秘密密鑰是唯一身分識別的證明。因此，可以信任 KDC 向任何其他主體驗證任何主體，例如在掛接時向 NFS 伺服器 SPN 驗證 NFS 用戶端服務主體名稱（SPN）。您也可以信任向 NFS 伺服器 SPN 驗證用戶主體，以存取 NAS 裝入點。作為額外的安全性措施，Kerberos 不會透過網路傳送明文密碼進行驗證。

Azure NetApp Files 支援使用 Kerberos 為 SMB 和 NFS 通訊協定提供即時安全性。

支援的加密類型

Azure NetApp Files 根據您使用的作業模式和版本，支援具有特定加密類型的 NFS Kerberos。

若要確保用戶端使用適當的加密類型，您可以限制位於 KDC 的對象主體上的有效加密類型（例如，計算機帳戶）或用戶端手動建立的 keytab 檔案中，而不是全域在 /etc/krb5.conf 檔案中，如果可能的話，因為管理許多用戶端 krb5.conf 檔案可能是管理難題。從 KDC 集中管理 Kerberos 在大型企業環境中更容易調整、更容易自動化，並強制客戶端在支援時使用更強的加密類型。

注意

建議在用戶端的 krb5.conf 檔案中將選項 allow_weak_crypto 設定為 false。此設定可防止 Kerberos 通訊較不安全 enctypes （例如 DES 或 3DES）。

下表顯示 Azure NetApp Files 支援的 Kerberos 加密類型（SMB 和 NFS）。

通訊協定	支援的加密類型
SMB	RC4-HMAC AES-128 AES-256
NFS	AES-256

支援的 NFS Kerberos 安全性模式

除了加密類型的概念之外，Kerberos 中也有安全性與完整性檢查層級。根據使用中的安全性模式，這些安全性模式可藉由提供 NFS 流量的端對端加密，協助防止中間人攻擊。

在 Azure NetApp Files 中，這些安全性模式會在針對 NFS 設定的磁碟區匯出原則規則上指定，並透過 sec 掛接選項在初始 NFS 掛接期間定義。

例如： # mount -o sec=krb5p

注意

針對SMB Kerberos，Kerberos 的安全性模式是透過共用上的SMB加密設定、 UNC強化，以及域控制器上的SMB簽署/密封原則來控制。

Azure NetApp Files 支援下列安全性模式，以搭配 NFS Kerberos 使用：

安全性模式	描述
krb5	僅限驗證加密。使用 Kerberos V5 名稱字串和用戶主體名稱，而不是本機 UNIX 使用者識別碼（UID）和群組識別碼來驗證使用者。
krb5i	驗證加密和加密完整性檢查。使用 Kerberos V5 進行使用者驗證，並使用安全總和檢查碼來執行 NFS 作業的完整性檢查，以防止數據竄改和中間人攻擊。
krb5p	加密整個 NFS 交談。使用 Kerberos V5 進行使用者驗證和完整性檢查，並加密所有 NFS 流量，以防止封包探查。此設定最安全，但也會產生最高的效能負荷。

Kerberos 術語

本節會定義描述 Kerberos 程式時所使用的重要術語。本節旨在協助釐清可能不熟悉記憶體系統管理員的條款。

詞彙	定義
金鑰配送中心（KDC）	KDC 是驗證伺服器，其中包含票證授與服務（TGS）和驗證服務（AS）。 KDC、AS 和 TGS 詞彙會交替使用。在Microsoft環境中，Active Directory 域控制器是 KDC。
領域（或 Kerberos 領域）	領域（或 Kerberos 領域）可以使用任何 ASCII 字串。標準是使用大寫的功能變數名稱;例如，contoso.com 會成為領域 CONTOSO.COM。 Kerberos 領域通常是在客戶端和伺服器上的 krb5.conf 檔案中設定。系統管理上，每個principal@REALM都必須是唯一的。為了避免單一失敗點，每個領域可以有多個 KDC 共用相同的資料庫（主體及其密碼），並具有相同的 KDC 主要密鑰。 Microsoft Windows Active Directory 會透過 Active Directory 複寫以原生方式執行這項作業，預設會每隔 15 分鐘執行一次。
主體	主體一詞是指 Kerberos 資料庫中的每一個實體。用戶、計算機和服務全都會指派 Kerberos 驗證的主體。每個主體在 Kerberos 資料庫中都必須是唯一的，而且是由其辨別名稱所定義。主體可以是用戶主體名稱（UPN）或服務主體名稱（SPN）。主體名稱有三個部分：主要 - 主要元件可以是使用者或服務，例如 NFS 服務。它也可以是特殊的服務「主機」，這表示此服務主體已設定為提供多個各種網路服務。實例 - 在用戶的情況下，這個部分是選擇性的。用戶可以有多個主體，但每個主體在 KDC 中都必須是唯一的。例如，Fred 可能有一個主體適用於日常使用（fred@contoso.com）和允許特殊許可權使用的主體，例如系統管理員帳戶（admin-fred@contoso.com）。服務主體需要實例，並指定提供服務之主機的完整功能變數名稱（FQDN）。領域 - Kerberos 領域是 Kerberos 伺服器內註冊的一組 Kerberos 主體。依照慣例，領域名稱通常與 DNS 名稱相同，但會轉換成大寫字母。大寫字母不是強制性的，但慣例提供 DNS 名稱和領域名稱之間的簡單區別。
罰單	票證是一組暫時的認證，可驗證服務的主體身分識別，並包含會話密鑰。票證可以是服務、應用程式票證或票證授與票證（TGT）。票證會在客戶端、伺服器和 KDC 之間交換，以進行 Kerberos 驗證。
秘密金鑰	Kerberos 會使用對稱密鑰系統，其中秘密金鑰用於加密和解密。秘密金鑰是從主體的 Kerberos 密碼產生，並具有單向哈希函式。 KDC 會儲存每個主體的密碼，因此可以產生主體的秘密密鑰。對於要求 Kerberos 服務的使用者，秘密金鑰通常衍生自提供給 kinit 程式的密碼。服務和精靈主體通常不會使用密碼;相反地，單向哈希函式的結果會儲存在keytab中。
Keytab	keytab 包含主體及其秘密密鑰的清單。 keytab 中的秘密密鑰通常會使用隨機密碼來建立，而且主要用於服務或精靈主體。

網路埠資訊

下表涵蓋哪些網路埠用於 Kerberos 通訊。如果已備妥網路防火牆，則應該開啟這些埠，以允許適當的 Kerberos 功能。您可以在 IANA 服務名稱和傳輸通訊協定連接埠號碼登錄中找到這些埠的詳細資訊。

服務	連接埠
Kerberos	88 (TCP/UDP)
kpasswd	464 （TCP/UDP）
輕量型目錄存取通訊協定（LDAP）（適用於名稱對應）	389 (TCP/UDP)
管理伺服器	749 （TCP/UDP）
全域編錄（Windows 用戶查閱）	3268 （TCP/UDP）

在 Azure NetApp Files 中快取存留期值

下表顯示快取專案存留在 Azure NetApp Files 磁碟區的時間量。

Cache	快取存留期
閑置名稱伺服器連線	60 秒
LDAP 查詢逾時	10 秒
KDC TTL 的本機 DNS 主機專案	24 小時
Kerberos 票證年齡	由 KDC* 和/或用戶端指定 * Windows Active Directory KDC 的預設值為 10 小時
使用者認證	24 小時
Kerberos 時間扭曲	5 分鐘

Azure NetApp Files 中正常運作 Kerberos 環境的需求

Kerberos 驗證高度相依於外部服務，以取得適當的功能。在 Microsoft Active Directory 中，大部分的服務會合併成單一伺服器，在許多情況下。例如，Active Directory 域控制器可以服務下列 Kerberos 相依性：

時間同步處理服務
DNS
Kerberos 金鑰散發
密碼服務/單一登錄
身分識別服務（例如LDAP）

使用原生Microsoft Active Directory 時（Azure NetApp Files 目前唯一支援的 KDC 類型），則涵蓋 Azure NetApp Files 中 Kerberos 的大部分外部相依性，例如 DNS、KDC 和密碼服務。在某些情況下，必要的服務可能會裝載於 Active Directory 網域外部（例如 DNS）。在這些情況下，請務必確保已正確設定必要的服務。

Azure NetApp Files 有特定相依性，可用於正常運作的 NFS Kerberos。繼續閱讀以取得詳細資訊。

時間同步處理服務

使用 Kerberos 進行驗證時，時間同步處理服務是必要的，因為 Kerberos 票證機制取決於客戶端與伺服器之間的時間誤差，在預設的 5 分鐘範圍內。如果客戶端或伺服器上的時間設定超過五分鐘範圍，Kerberos 驗證會失敗，並出現時間扭曲錯誤（KRB_AP_ERR_SKEW），且存取 NAS 共用遭到拒絕。這次逾時是一項安全性功能，可協助防止「重新執行攻擊」，攻擊者可以攔截 KDC 與客戶端之間的訊息，然後在稍後重新執行這些訊息，以模擬已驗證的使用者。時間扭曲限制有助於將這些攻擊類型的風險降到最低。

時間同步問題的重要考慮：

外部時間伺服器（例如在 NIST 中找到的伺服器）應設定為與 Active Directory 網域搭配使用，以提供精確的一致時間服務。
KDC 上的事件查看器中可以看到時間扭曲錯誤，錯誤KRB_AP_ERR_SKEW，以及在封包擷取中。
重新執行攻擊嘗試會以KRB_AP_ERR_REPEAT記錄在事件查看器中。

如需詳細資訊，請參閱計算機時鐘同步處理的最大容錯度

網域名稱系統（DNS）

功能變數名稱系統（DNS）是 Kerberos 作為安全性功能的必要專案。主機名解析可用來制定用於驗證的 Kerberos 服務主體。在此程式中，會使用主機名（A/AAAA 記錄）的向前查閱來連線到利用 Kerberos 驗證的共用。然後，該向前查閱會用來制定 Kerberos 驗證要求中使用的服務主體名稱（SPN）。如果 KDC 中找不到現有的 SPN，則 Kerberos 驗證會失敗。

在 Windows SMB 環境中，可能會嘗試備份驗證方法（例如 NTLM）。不過，在許多情況下，NTLM 會因為安全性原因而停用，這會導致 Kerberos 驗證失敗時共用的存取失敗。 Windows 事件查看器通常會記錄失敗的根本原因（例如重複/遺漏 SPN、DNS 查閱失敗、NTLM 失敗等等）。

除了SPN解析之外，DNS還大量用來透過SRV記錄解析網域服務的主機名和IP位址，例如LDAP、Kerberos KDC等。如需 Azure NetApp Files 中 DNS 的詳細資訊（包括需要哪些 SRV 記錄），請參閱關於 Azure NetApp Files 中的 DNS。

注意

如果使用IP位址進行 Kerberos 存取，則行為取決於使用的NAS通訊協定（NFS 或 SMB）。如需詳細資訊，請參閱使用 Kerberos 存取的 IP 位址。

LDAP

輕量型目錄存取通訊協定（LDAP）利用後端身分識別資料庫，為 NAS 用戶端和伺服器提供統一的名稱服務來源，讓所有參與的裝置都同意用戶真實性、群組成員資格和數值標識符，然後用於檔案許可權。

針對 Kerberos，使用者和服務主體會以 LDAP 資料庫中的專案儲存為主體帳戶上的屬性。 Windows Active Directory 預設支援此專案。在某些情況下（例如建立別名或服務主體時），用戶和計算機需要新增或修改服務主體名稱。您可以使用 Active Directory 使用者和電腦 Microsoft Management Console （MMC）或 PowerShell 來滿足這項需求。如需管理服務主體名稱的詳細資訊，請參閱管理服務主體名稱。

除了用於 Kerberos 驗證的服務主體名稱和數值識別碼之外，LDAP 也可用於 UNIX 使用者和群組身分識別，用於 Azure NetApp Files 中身分識別的名稱對應，以及透過 SPN -> UNIX 使用者名稱對應來掛接 NFS Kerberos 的初始驗證。如需詳細資訊，請參閱 NFS Kerberos 如何在 Azure NetApp Files 中使用 Kerberos 和 LDAP 在 Azure NetApp Files 中使用 Kerberos 的角色。

SMB Kerberos 如何在 Azure NetApp Files 中運作

SMB Kerberos 與 NFS Kerberos 服務分開運作，因為針對每個通訊協定建立的計算機帳戶無法共用密鑰表，因為其中一個密鑰索引卷標中可能會變更密鑰版本號碼（kvno），而影響另一個服務的 keytab。因此，以及 NAS 通訊協定的自然差異，Kerberos 的 SMB 服務工作流程和 Kerberos 的 NFS 工作流程在某些領域的功能有所不同。

SMB 服務的初始設定

Azure NetApp Files 中的 SMB 服務最初是藉由設定 Active Directory 連線來設定，這會定義數個重要部分來與網域服務互動，包括：

主要 DNS 伺服器（必要）
次要 DNS
Active Directory DNS 名稱*
Active Directory 網站名稱（適用於 DC 探索）（必要）
SMB 伺服器前置詞名稱
組織單位（應在 Azure AD 網域中儲存電腦帳戶的位置）
AES 加密啟用/停用
LDAP 簽署啟用/停用
LDAP 組態
SMB 加密至 DC
具權限的使用者
具有 OU 許可權之使用者的使用者名稱/密碼認證

注意

每個帳戶只允許一個 Azure Active Directory （AD）連線。建立 Azure AD 連線之後，任何新的 Azure NetApp Files SMB 磁碟區都會使用 Azure AD 連線設定。

SMB Kerberos 計算機帳戶

Active Directory 中的計算機帳戶包含驗證要求中使用的相關信息，包括服務主體名稱（SPN）。當您在 Azure NetApp Files 中建立 SMB 磁碟區時，Active Directory 連線設定會用來在建立電腦帳戶時進行互動，以透過 Kerberos （或 NTLM，如果已啟用）驗證來安全地存取 SMB 共用。

在服務中的特定後端資源上布建 Azure NetApp Files SMB 磁碟區時，會建立新的電腦帳戶。以下顯示可在 Azure NetApp Files 磁碟區設定中建立或重複使用 SMB 計算機帳戶的不同案例。

案例	結果
第一個新的SMB磁碟區	新的SMB電腦帳戶/DNS 名稱
後續從第一個SMB磁碟區連續建立的SMB磁碟區	重複使用的SMB電腦帳戶/DNS名稱（在大多數情況下）。
後續建立的SMB磁碟區比第一個SMB磁碟區晚得多	服務會判斷是否需要新的電腦帳戶。您可以建立多個電腦帳戶，以建立多個IP位址端點。
第一個雙重通訊協定磁碟區	新的SMB電腦帳戶/DNS 名稱
後續從第一個雙重通訊協定磁碟區連續建立的雙重通訊協定磁碟區	重複使用的 SMB 計算機帳戶/DNS 名稱（在大多數情況下）
後續的雙重通訊協定磁碟區比第一個雙重通訊協定磁碟區更晚建立	服務會判斷是否需要新的電腦帳戶。您可以建立多個電腦帳戶，以建立多個IP位址端點
在雙重通訊協定磁碟區之後建立的第一個SMB磁碟區	新的SMB電腦帳戶/DNS 名稱
SMB 磁碟區之後建立的第一個雙重通訊協定磁碟區	新的SMB電腦帳戶/DNS 名稱

針對 Azure NetApp Files SMB（或雙重通訊協定）磁碟區建立的 SMB 計算機帳戶會使用遵循 Active Directory 所強制執行的 15 個字元上限的命名慣例。此名稱會使用 [Azure AD 聯機組態中指定的 SMB 伺服器前置詞]-[唯一數值標識符] 的結構。

例如，如果您已將 Azure AD 連線設定為使用 SMB 伺服器前置詞 “AZURE”，則 Azure NetApp Files 所建立的 SMB 機器帳戶類似 “AZURE-7806”。SMB 共用的 UNC 路徑會使用相同的名稱（例如 \AZURE-7806），而且是動態 DNS 服務用來建立 A/AAAA 記錄的名稱。

注意

因為「AZURE-7806」之類的名稱很難記住，因此最好建立 CNAME 記錄作為 Azure NetApp Files 磁碟區的 DNS 別名。如需詳細資訊，請參閱建立SMB伺服器別名。

在某些情況下，建立多個SMB和/或雙重通訊協定磁碟區時，設定最後可能會有多個不同的SMB計算機帳戶和 DNS 名稱。

如果想要跨磁碟區進行使用者存取的單一命名空間，這可能會在設定中帶來挑戰，因為單一 CNAME 別名只能指向單一 A/AAAA 主機記錄，而使用多個相同的 A/AAAA 記錄別名，可能會導致數據存取無法預測跨不同 SMB 計算機帳戶存取磁碟區，因為無法保證用戶端在 DNS 查閱中選取的端點包含預期的磁碟區，因為這些設定中 DNS 記錄選取的迴圈配置本質。

為了解決這項限制，Azure NetApp Files 磁碟區可以參與為Microsoft分散式文件系統（DFS）組態的目標，這可以提供將多個 SMB 磁碟區與單一命名空間進入點產生關聯的方式。

SMB Kerberos SPN 建立工作流程

下圖說明如何在建立 Azure NetApp Files SMB 或雙重通訊協定磁碟區時建立 SMB Kerberos SPN。 SMB SPN 與網域中的SMB計算機帳戶對象相關聯。您可以使用 [進階] 檢視中的屬性編輯器，透過計算機帳戶屬性來檢視及管理 SPN。

您也可以使用 setspn 命令來檢視和管理屬性。

'setpn' 命令的螢幕快照。

此程式遵循與一般 Windows 用戶端加入網域時相同的步驟（DNS、LDAP、Kerberos、RPC 查詢透過命名管道）。

在大部分情況下，瞭解日常管理工作不需要詳細步驟，但在嘗試在 Azure NetApp Files 中建立 SMB 磁碟區時，針對任何失敗進行疑難解答很有用。

詳細步驟

如需如何在 Azure NetApp Files 中建立 SMB 計算機帳戶的詳細步驟，請展開清單。

DNS 查閱是使用 Kerberos KDC SRV 記錄的 DNS 設定來執行。 Azure NetApp Files 在其要求中使用下列 SRV 記錄。
- _kerberos._tcp.dc._msdcs.CONTOSO.COM
- _kerberos._tcp.CONTOSO.COM （如果先前的查詢未傳回任何結果）
DNS 查閱是使用 SRV 查詢中針對 KDC 的 A/AAAA 記錄所傳回的主機名來執行。
- LDAP ping（LDAP 系結和 RootDSE 查詢）會執行，以使用查詢（&(DnsDomain=CONTOSO.COM)(NtVer=0x00000016)）搭配 NetLogon 的屬性篩選來搜尋可用的舊版 NetLogon 伺服器。較新的 Windows 域控制器版本（大於 2008）沒有 NtVer 存在的值。
Azure NetApp Files 會執行 DNS 查詢，以使用下列 SRV 記錄在網域中尋找 LDAP 伺服器：
- _ldap._tcp.CONTOSO.COM
- _kerberos._tcp.CONTOSO.COM
注意

這些查詢會在同一個處理程式的不同部分呼叫中多次發生。 DNS 問題可能會在這些呼叫中造成緩慢，或發生逾時、完成失敗。 - 如果查詢找不到專案，或找不到的項目無法連絡，則 SMB 磁碟區建立會失敗。 - 如果 DNS 查詢成功，則會處理後續步驟。
ICMP （ping）會傳送來檢查從 DNS 傳回的 IP 位址是否可連線。
如果防火牆原則封鎖網路上的 ping，ICMP 要求就會失敗。相反地，會使用LDAP Ping。
執行另一個LDAP Ping，以使用查詢（&(&(DnsDomain=CONTOSO.COM)(Host=KDChostname.contoso.com))(NtVer=0x00000006)）搭配屬性篩選 NetLogon 來搜尋可用的舊版 NetLogon 伺服器。較新的 Windows 域控制器版本（大於 2008）沒有 NtVer 值存在。
使用以 Active Directory 連線設定的使用者名稱，從 Azure NetApp Files 服務傳送 AS-REQ 驗證。
DC 會回應 KRB5KDC_ERR_PREAUTH_REQUIRED，要求服務安全地傳送用戶的密碼。
第二個 AS-REQ 會以向 KDC 進行驗證所需的預先驗證數據來傳送，以便存取以繼續建立電腦帳戶。如果成功，就會將票證授與票證（TGT）傳送至服務。
如果成功，服務會傳送 TGS-REQ，以使用 AS-REP 中收到的 TGT 向 KDC 要求 CIFS 服務票證（cifs/kdc.contoso.com）。

會執行使用 CIFS 服務票證的新 LDAP 系結。查詢會從 Azure NetApp Files 傳送：

RootDSE 基底搜尋網域的 ConfigurationNamingContext DN
針對 ConfigurationNamingContext 擷取之 DN 中的 CN=partitions，使用 NETBIOSname 屬性的 filter （&(&(objectClass=crossRef)(nETBIOSName=*))(dnsRoot=CONTOSO.COM)）進行 OneLevel 搜尋。
使用篩選條件的基底搜尋會在|(objectClass=organizationalUnit)(objectClass=container) Active Directory 聯機組態中指定的 OU 上執行。如果未指定，則會使用預設值 OU=Computers 。這會驗證容器是否存在。
子樹搜尋會在網域的基底 DN 上執行，並使用篩選條件（sAMAccountName=ANF-XXXX$）來檢查帳戶是否存在。
- 如果帳戶存在，則會重複使用它。
如果帳戶不存在，則會建立帳戶，前提是使用者有權使用 addRequest LDAP命令在容器中建立和修改物件。下列屬性會在帳戶上設定：

屬性	值
CN	ANF-XXXX
`sAMAccountName`	ANF-XXXX$
`objectClass`	前幾個個人 OrganizationalPerson User 電腦
`servicePrincipalName`	HOST/ANF-XXXX HOST/anf-xxxx.contoso.com CIFS/anf-xxxx.contoso.com
`userAccountControl`	4096
operatingSystem	NetApp 版本
`dnsHostName`	ANF-XXXX.CONTOSO.COM

addRequest如果失敗，磁碟區建立就會失敗。 addRequest可能會因為容器對象的許可權不正確而失敗。
addRequest如果成功，則會執行使用篩選器（sAMAccountName=ANF-XXXX$）的LDAP搜尋來擷取 objectSid 屬性。
SMB2「交涉通訊協定」交談會執行，以從 KDC 擷取支援的 Kerberos mechTypes 。
使用 CIFS SPN 和最高支援的 mechType SMB2「會話設定」，並執行 IPC$ 的「樹狀結構連線」。
SMB2 lsarpc 檔案會在 IPC$ 共用中建立。
會執行系結至 DCERPC 。接著會寫入檔案 lsarpc 。
接著會執行下列 LSA 要求：
- Lsa_openpolicy2
- Lsa_lookupsids2

系統會使用 TGT 執行 TGS-REQ 來擷 kadmin/changepw 取與 krbtgt 帳戶相關聯之 SPN 的票證。
KPASSWD 要求會從服務對 KDC 提出，以變更電腦帳戶密碼。
LDAP 查詢會針對屬性distinguishedName和 isCriticalSystemObject執行篩選條件（sAMAccountName=ANF-XXXX）。
如果帳戶的 isCriticalSystemObject 為 false （預設值），則會使用擷取的 DN 來制定 modifyRequest 屬性 msDs-SupportedEncryptionTypes的。此值設定為 30，相當於 DES_CBC_MD5 (2) + RC4 (4) + AES 128 (8) + AES 256 (16)。
執行第二個「交涉通訊協定」/Kerberos 票證交換/「會話設定」/「樹狀連線」至 IPC$。 SMB 伺服器的機器帳戶（ANF-XXXX$）會做為 Kerberos 主體。
NetLogon、NetrServer ReqChallenge /Authenticate2 通訊已完成。
執行第三個「交涉通訊協定：/Kerberos 票證交換/「會話設定」/「樹狀連線」至 IPC$;SMB 伺服器的機器帳戶（ANF-XXXX$）會作為 Kerberos 主體使用。
和 lsarpc NetLogon 連線都會做為帳戶的最終檢查。

使用 Kerberos 掛接 Azure NetApp Files 磁碟區時，會在多個會話設定要求期間使用 Kerberos 票證交換，以提供對共用的安全存取。在大部分情況下，瞭解日常管理工作不需要詳細步驟。在嘗試存取 Azure NetApp Files 中的 SMB 磁碟區時，這項知識有助於針對失敗進行疑難解答。

如需詳細說明如何在 Azure NetApp Files 中存取 SMB 共用的步驟，請展開清單。

用戶端會嘗試使用 Azure NetApp Files 中顯示的 UNC 路徑來存取 SMB 共用。根據預設，UNC 路徑會包含 SMB 伺服器名稱（例如 ANF-XXXX）
查詢 DNS 以將主機名對應至 IP 位址
進行初始SMB2 「交涉通訊協定」交談
- 要求會從用戶端傳送，以探索伺服器支援哪些SMB方言，並包含要求客戶端支援的內容
- 伺服器會以它支援的內容回應，包括：
  - 安全性模式（簽署或未簽署）
  - SMB 版本
  - 伺服器 GUID
  - 支援的功能（DFS、租用、大型 MTU、多重通道、永續性句柄、目錄租用、加密）
  - 交易大小上限
  - 讀取/寫入大小上限
  - 安全性 Blob （Kerberos 或 NTLM）
第二個SMB2「交涉通訊協定」交談會以「預先授權」/登入的形式進行
- 來自用戶端的要求包括：
  - 預先授權哈希
  - 支援的安全性模式（簽署或未簽署）
  - 支援的功能（DFS、租用、大型 MTU、多重通道、永續性句柄、目錄租用、加密）
  - 用戶端 GUID
  - 支援的SMB方言
- 如果接受預先授權哈希，伺服器會以下列項目回應：
  - 安全性模式（簽署或未簽署）
  - 支援的功能（DFS、租用、大型 MTU、多重通道、永續性句柄、目錄租用、加密）
  - 交易大小上限
  - 讀取/寫入大小上限
  - 安全性 Blob （Kerberos 或 NTLM）
  - SMB 預先授權完整性和加密功能
如果通訊協定交涉成功，則會提出「會話設定」要求。
- 安裝程式會使用通訊協定交涉中的預先授權哈希。
- 安裝程式會通知SMB伺服器要求客戶端支援的內容，包括：
  - StructureSize
  - 會話系結旗標
  - 安全性模式（已啟用/需要簽署）
  - Capabilities
  - 支援的 Kerberos 加密類型
傳送「會話設定」回應。
- 已授與SMB點數。
- 已建立會話標識碼。
- 會話旗標已設定（來賓、Null、加密）。
- 已定義 Kerberos 加密類型。
樹狀結構連線要求是由用戶端傳送，以聯機至SMB共用。
- 共用旗標/功能是從伺服器傳送，以及共享許可權。
命令ioctlFSCTL_QUERY_NETWORK_INTERFACE_INFO會傳送來取得SMB伺服器的IP位址。
Azure NetApp Files 中的 SMB 伺服器會回報網路資訊，包括：* IP 位址 * 介面功能（RSS 開啟或關閉） * RSS 佇列計數 * 連結速度
用戶端會傳送樹狀結構連線要求，以連線到 IPC$ 系統管理共用。
- IPC$ 共用是共用命名管道的資源，這些管道對於程式之間的通訊至關重要。 IPC$ 共用會在遠端管理計算機期間以及檢視電腦的共享資源時使用。您無法變更 IPC$ 共用的共享設定、共用屬性或 ACL。您也無法重新命名或刪除 IPC$ 共用。
- 名為 srvsvc 的檔案會在共用中建立為服務句柄。
DCERPC 系結會系結至 srvsvc 檔案，以建立安全的連線。
- 檔案會以先前擷取的資訊寫入。
Kerberos TGS-REQ 是由 Windows 用戶端發行給 KDC，以取得 SMB 服務的服務票證（ST）。
SMB NetShareGetInfo 用戶端會執行命令至伺服器，並傳送回應。
SMB 服務票證是從 KDC 擷取。
Azure NetApp Files 會嘗試將要求存取共用的 Windows 用戶對應至有效的 UNIX 使用者。
- Kerberos TGS 要求是使用 SMB 伺服器 Kerberos 認證，從初始 SMB 伺服器建立到用於 LDAP 伺服器系結的 SMB 伺服器密鑰表儲存。
- LDAP 會搜尋對應至要求共用存取之 SMB 使用者的 UNIX 使用者。如果 LDAP 中沒有任何 UNIX 使用者存在，則 Azure NetApp Files 會使用預設 UNIX 使用者 pcuser 進行名稱對應（以雙重通訊協定磁碟區寫入的檔案/資料夾會使用對應的 UNIX 使用者作為 UNIX 擁有者）。
執行另一個交涉通訊協定/會話要求/樹狀結構連線，這次會使用SMB伺服器的 Kerberos SPN 到 Active Directory DC 的 IPC$ 共用。
- 命名管道會透過 srvsvc建立至共用。
- NETLOGON 工作階段會建立至共用，並驗證 Windows 使用者。
如果許可權允許使用者使用，共用會列出磁碟區中包含的檔案和資料夾。

注意

Azure NetApp Files 會將專案新增至用戶端的 Kerberos 內容快取。這些專案會在 Kerberos 票證存留期間位於快取中（由 KDC 設定，並由 Kerberos 原則控制。

建立SMB伺服器別名

當 Azure NetApp Files 使用 [Azure AD 聯機組態中指定的 SMB 伺服器前置詞] -[唯一數值標識符] 的命名慣例來建立 SMB 伺服器時。（如需唯一數值標識符的詳細資訊，請參閱 SMB Kerberos 計算機帳戶）。此格式設定表示SMB伺服器名稱不是以使用者易記的方式建構。例如，“SMB-7806” 的名稱比類似 “AZURE-FILESHARE” 更難記住。

由於此行為，系統管理員可能會想要建立 Azure NetApp Files 磁碟區的使用者易記別名名稱。這樣做需要將 DNS 標準名稱（CNAME）指向伺服器中現有的 DNS A/AAAA 記錄。

在 UNC 路徑要求中建立並使用 CNAME 時， \\AZURE-FILESHARE\\SMB-7806DNS 會將 CNAME 要求（AZURE-FILESHARE.contoso.com）重新導向至適當的 A/AAAA 記錄（SMB-7806.contoso.com），用於 Kerberos SPN 擷取（cifs/SMB-7806）。這可讓 Kerberos 在使用別名名稱時存取 SMB 共用。

如果已建立 DNS A/AAAA 記錄（例如，AZURE-FILESHARE.contoso.com），並嘗試作為別名使用，Kerberos 要求就會失敗。失敗是用來向共用進行驗證的建構 SPN 的結果（cifs/AZURE-FILESHARE）不符合 SMB 伺服器 Kerberos SPN 的內容（cifs/SMB-7806）。如果建立另一個SPN並附加至SMB伺服器電腦帳戶（例如 cifs/AZURE-FILESHARE），可能會減輕失敗。

Azure NetApp Files 中支援的 SMB 伺服器功能

提出SMB「交涉通訊協定」要求時，會查詢 Azure NetApp Files SMB 伺服器以支援特定功能。下表顯示執行會話設定/樹狀結構連線時，查詢的功能，以及從 Azure NetApp Files SMB 磁碟區傳回的回應。

SMB 功能	Azure NetApp Files 支援？
DFS 目標	Yes
租賃	Yes
大型 MTU	Yes
SMB 多通道	Yes
SMB 持續性句柄	Yes
目錄租用	No
SMB 加密	是（如果已啟用）

在SMB共用存取期間，會執行「樹狀連線」要求，且客戶端會查詢支援的SMB共用功能和屬性至 Azure NetApp Files 伺服器。下表顯示查詢的共用功能，以及從 Azure NetApp Files SMB 磁碟區傳回的回應，如封包擷取中所見。

SMB 共用功能	Azure NetApp Files 支援？
持續可用（CA）	是，針對特定工作負載* （如果已啟用）
向外延展	No
Cluster	No
非對稱	No
重新導向至擁有者	No

* 如需支援的工作負載，請參閱在現有的SMB磁碟區上啟用持續可用性。

下表顯示查詢的共享屬性，以及從 Azure NetApp Files SMB 磁碟區傳回的回應。

SMB 共用功能	Azure NetApp Files 支援？
DFS 目標	Yes
DFS 根目錄	No
限制獨佔開啟	No
強制共享刪除	No
允許命名空間快取	No
存取型列舉	是（如果已啟用）
強制層級 II oplock	No
啟用哈希 V1	No
啟用哈希 v2	No
需要加密	是（如果已啟用）
身分識別遠程處理	No
壓縮的 I/O	No
隔離傳輸	No

NFS Kerberos 如何在 Azure NetApp Files 中運作

NFS Kerberos 與 SMB 服務分開運作，因為針對每個通訊協定建立的電腦帳戶無法分享 keytab，因為其中一個密鑰索引標籤可能會變更影響另一個服務的密鑰版本號碼（kvno）。因此，Kerberos 的 SMB 服務工作流程和 Kerberos 的 NFS 工作流程在某些領域的功能有所不同。

Kerberos 領域的初始設定

當 Kerberos 領域資訊填入 Azure NetApp Files 入口網站的 [Active Directory 連線] 頁面底下時，就會設定 NFS Kerberos 領域。

Azure AD 伺服器名稱和 KDC IP 可用來連線到初始電腦帳戶建立上的 Azure AD KDC 服務。 Azure NetApp Files 服務會利用現有的網域資訊來填寫其他領域組態。例如：

Kerberos Realm: CONTOSO.COM
KDC Vendor: Microsoft
KDC IP Address: x.x.x.x 
KDC Port: 88
Clock Skew: 5
Active Directory Server Name: dc1.contoso.com
Active Directory Server IP Address: x.x.x.x
Comment: -
Admin Server IP Address: x.x.x.x
Admin Server Port: 749
Password Server IP Address: x.x.x.x
Password Server Port: 464
Permitted Encryption Types: aes-256
-    Configured by Azure NetApp Files administrator in the portal
-    Automatically configured by the service using Active Directory connection information/system defaults

設定 NFS Kerberos 領域時，會在服務中新增本機主機專案，並在設定中指定的 KDC。修改領域時，本機主機專案也會在服務中修改。

如果 KDC 在領域設定中指定的 KDC 發生中斷，且無法透過 DNS 查詢備援 KDC，則此本機主機專案會作為「最後手段」。

注意

如果 Kerberos 領域中的 KDC 需要關閉以進行維護（例如升級或解除委任伺服器），建議將領域設定為使用未進行維護的 KDC，以避免中斷。

初始建立電腦帳戶/SPN

在 Azure NetApp Files 磁碟區上啟用 Kerberos 時，會在 Active Directory 連線中指定 OU 的網域中建立名為 NFS-{SMB-server-name} 的電腦帳戶/主體。計算機帳戶名稱會在15個字元之後截斷。

注意

將主機名大於 15 個字元的 Linux 用戶端新增至 Active Directory 網域時，會截斷其 Kerberos 計算機帳戶 SPN。例如，名稱為的 MORE-THAN-FIFTEEN Linux 用戶端具有的電腦帳戶名稱 MORE-THAN-FIFT$，這會變成的 MORE-THAN-FIFT$@CONTOSO.COMSPN。當 DNS 查閱用戶端主機名稱時，它會尋找較長的名稱，並嘗試在 SPN 要求中使用該名稱（ MORE-THAN-FIFTEEN@CONTOSO.COM)。由於SPN不存在，客戶端會嘗試在要求中的keytab中使用下一個SPN（通常是主機/主機名）。只有機器帳戶名稱 SPN 原生使用 Azure NetApp Files NFS Kerberos。因此，請確定搭配 Azure NetApp Files 用於 NFS Kerberos 的 Linux 用戶端主機名不超過 15 個字元。或者，如果您想要使用主機名SPN，請使用使用者名稱「host」在LDAP中設定 UNIX 使用者。此設定提供SPN的 krb-unix 名稱對應。

在 Azure NetApp Files 中，Kerberos keyblocks（或 keytab 專案）會新增至具有 NFS 服務 SPN （nfs/nfs-server-name.contoso.com@CONTOSO.COM）的服務。系統會建立多個專案：每個支援的加密類型各一個專案。在 Azure NetApp Files 中，NFS Kerberos 僅支援 AES-256 加密類型。

在大部分情況下，瞭解這些步驟對於日常管理工作而言並不需要，但在嘗試在 Azure NetApp Files 中建立 NFS Kerberos 磁碟區時，針對任何失敗進行疑難解答會很有用。

NFS Kerberos SPN 建立工作流程

下圖顯示當已啟用 Kerberos 的 Azure NetApp Files NFS 或雙重通訊協定磁碟區時，如何建立 NFS SPN。在大部分情況下，瞭解日常管理工作不需要詳細步驟，但在嘗試在 Azure NetApp Files 中建立 SMB 磁碟區時，針對任何失敗進行疑難解答很有用。

如需如何使用 Azure NetApp Files 建立 NFS Kerberos SPN 的詳細步驟，請展開清單。

使用 Active Directory 連線中提供的使用者名稱，傳遞至領域組態中指定的 KDC 系統管理員認證 – 使用者必須具有檢視/建立指定 OU 中對象的許可權。
Azure NetApp Files Active Directory 聯機組態中指定的 DNS 伺服器會以下列格式查詢 Azure NetApp Files 以取得 Kerberos 服務記錄（SRV）：
- _kerberos.CONTOSO.COM 的 URI 查詢
- _kerberos master._udp的 SRV 查詢。 CONTOSO.COM
- _kerberos master._tcp的 SRV 查詢。 CONTOSO.COM

注意

這些查詢會在同一個處理程式的不同部分呼叫中多次發生。 DNS 問題可能會在這些呼叫中造成緩慢或完成失敗。根據預設，這些記錄不會出現在 Active Directory 部署中，而且必須手動建立。

如果查詢找不到專案，或找不到的專案無法連絡或作為主要 KDC 使用，則會使用在 NFS Kerberos 領域設定中找到的領域名稱來使用 A 記錄查詢，作為透過埠 88 連接到 KDC 的最後手段。
在設定 NFS Kerberos 期間，如果 DNS 查閱失敗，指定 KDC 的靜態主機專案會新增至本機主機檔案作為備份。
如果領域有快取的 DNS 專案，則會使用它。如果沒有，則會使用本機檔案專案。只要已針對 DNS 記錄設定存留時間（TTL），快取的 DNS 專案即會存回。本機檔案項目設定為 86,400 秒 TTL （24 小時）。 Azure NetApp Files 中主機查閱的 ns 參陣列態會先使用檔案，然後再使用 DNS。找到本機專案時，不會再執行任何查詢。
建立 Active Directory 連線時所建立的 SMB 計算機帳戶會使用 SASL/GSS 透過埠 389 使用 Active Directory LDAP 系結的認證，以搜尋所需的 SPN 或電腦帳戶名稱的任何現有專案。如果SPN或電腦帳戶名稱已經存在，則會傳送錯誤。如果LDAP查詢中沒有SPN，則會在指定的OU中執行電腦帳戶建立，其中包含 Azure NetApp Files 所設定下列屬性的專案：
- cn （NFS-MACHINE）
- sAMAccountName （NFS-MACHINE$）
- objectClass （top， person， organizationalPerson， user， computer）
- servicePrincipalName （host/NFS-MACHINE， host/NFS-MACHINE.CONTOSO.COM、nfs/NFS-MACHINE、nfs/NFS-MACHINE。CONTOSO.COM）
- userAccountControl （4096）
- msDs-SupportedEncryptionTypes （AES-256_CTS_HMAC_SHA1_96）
- dnsHostName （NFS-MACHINE.CONTOSO.COM）
NFS kerberos 計算機帳戶密碼是針對透過埠 464 設定的 NFS-MACHINE 帳戶。
NFS SPN 的 Kerberos 金鑰區塊（keytabs）會儲存在 Azure NetApp Files 服務上。
Azure NetApp Files 服務上會建立靜態名稱對應規則，以確保使用 Kerberos 時，每個 NFS Kerberos 用戶端的根用戶都會對應至根使用者。
krb5.conf 檔案會新增至具有 NFS 領域資訊的服務內部系統。

NFS Kerberos 掛接

使用 Kerberos 安全性類別透過 NFS 掛接 Azure NetApp Files 磁碟區時，會執行下列工作流程。如需 Kerberos 的更詳細帳戶，請參閱 Kerberos 網路驗證服務（V5） Synopsis。

如需如何使用 Azure NetApp Files 掛接 NFS Kerberos 磁碟區的詳細步驟，請展開清單。

用戶端會嘗試掛接至 Azure NetApp Files 中的 NFS 匯出路徑，並指定 -okrb5 （或 krb5i 或 krb5p）安全性類別。
DNS 是用來透過 A/AAAA 記錄或 PTR，針對 Azure NetApp Files 的 NFS 服務主體提出要求（視掛接命令的發出方式而定）。
用戶端會使用用戶端密鑰表中找到的 CLIENT 主體名稱，透過 AS-REQ 呼叫從 KDC 擷取 TGT。
系統會檢查匯出路徑，以確保它存在於文件系統中。
已檢查匯出原則規則，以確保允許 Kerberos 存取匯出路徑。<
用戶端會透過 AP-REQ呼叫向 KDC 要求 NFS 服務票證。 Azure NetApp Files 會使用從 KDC 取得之用戶端的 TGT，檢查密鑰表是否有有效的加密類型有效專案。
如果 TGT 有效，則會發出服務票證。
用戶端 SPN （例如，CLIENT$@CONTOSO.COM）會透過 Azure NetApp Files 中的名稱對應規則對應至根使用者。
根使用者會在名稱服務資料庫（檔案和LDAP）中查詢是否存在/群組成員資格。
使用SMB伺服器電腦帳戶執行LDAP系結，以允許LDAP搜尋根使用者。
由於根目錄一律存在於 Azure NetApp Files 中，因此這不應該造成任何問題，但根目錄的 LDAP 查詢可能會失敗。您可以忽略這些失敗。
NFS 服務票證會傳回至用戶端，且掛接成功。根用戶可透過用戶端的計算機帳戶主體存取 Kerberos 掛接的根存取權（可從 klist -e 客戶端檢視命令）。
Azure NetApp Files 會將專案新增至用戶端的 Kerberos 內容快取。這些專案將會在 KDC 所設定且由 Kerberos 原則控制的 Kerberos 票證存留期期間位於快取中。
NFSv4.1 會定期傳送 Kerberos 票證重新整理更新為「keepalives」。

具有用戶主體的 NFS Kerberos 掛接存取權

當使用者存取 Azure NetApp Files NFS Kerberos 掛接時（除了使用電腦帳戶 SPN 的根使用者以外），則會執行下列工作流程。

如需如何使用具有 Azure NetApp Files 的非根使用者存取 NFS Kerberos 磁碟區的詳細步驟，請展開清單。

使用者使用使用者名稱/密碼交換或透過keytab檔案登入 KDC，透過 AS-REQ 呼叫取得 TGT，以用來從 Azure NetApp Files 磁碟區收集服務票證。
已檢查匯出原則規則，以確保允許 Kerberos 存取用戶端電腦的匯出路徑
Azure NetApp Files 會檢查快取的 NFS 服務票證。如果沒有，則會透過AP-REQ呼叫要求NFS服務票證，而服務會使用從 KDC 取得之用戶端取得的 TGT，檢查密鑰表是否有有效的加密類型有效專案
如果 TGT 有效，則會發出服務票證
用戶的用戶主體名稱（UPN）會透過隱含對應來對應。例如，如果 UPN 為 user1@CONTOSO.COM，則服務會查詢名為 user1 的 UNIX 使用者。因為該 UNIX 使用者不存在於 Azure NetApp Files 的本機檔案資料庫中，因此會使用 LDAP。
嘗試使用SMB伺服器電腦帳戶的LDAP系結，允許LDAP搜尋對應的使用者。 DNS SRV 查詢是針對 Kerberos DNS 記錄完成的（_kerberos和_kerberos master）。如果無法使用有效的記錄，則設定會回復到領域設定。這些 KDC DNS SRV 查詢不是網站範圍。
LDAP SRV 記錄會針對有效的LDAP伺服器進行查詢。這些是網站範圍。
如果LDAP或LDAP中沒有使用者無法查詢（伺服器關閉、DNS查閱失敗、系結失敗、LDAP 搜尋逾時、使用者不存在），則對應失敗並拒絕存取。
如果使用者存在，則會收集群組成員資格。
對應成功，且 NFS 服務票證會發給用戶端（如命令所示 klist -e ）。根據匯出路徑上的檔案許可權，允許存取。

LDAP 在 Azure NetApp Files 中使用 Kerberos 的角色

Azure NetApp Files 依賴 LDAP for NFS Kerberos。 Azure NetApp Files 中的 NFS Kerberos 需要 Kerberos 進行傳入使用者 SPN 的 UNIX 名稱對應。因為 Azure NetApp Files 不支援建立本機 UNIX 使用者，因此需要 LDAP 才能在要求名稱對應時執行 UNIX 使用者的查閱。

建立 Azure AD 連線時，會使用 Active Directory 功能變數名稱來指定查閱 LDAP 伺服器的程式。
需要LDAP伺服器時， _ldap.domain.com 會用於LDAP伺服器的SRV查閱。
探索到伺服器清單之後，最佳可用伺服器（根據 Ping 回應時間）會作為透過埠 389 連線的 LDAP 伺服器。
透過 GSS/Kerberos 嘗試使用 SMB 計算機帳戶進行 LDAP 系結。
如果沒有快取的連線或 Kerberos 認證，則會發出 Kerberos 票證的新要求。 Azure NetApp Files 中名稱伺服器的快取連線即時 60 秒。如果閑置超過 60 秒，則會清除連線快取。
DNS 是用來透過 SRV 記錄尋找適當的 Kerberos KDC。
如果無法透過 DNS 查詢找到任何 KDC，則會使用 SMB 服務的 krb5.conf 檔案中指定的 KDC。
- 如果該 KDC 無法連線或無法處理 Kerberos 要求，LDAP 系結就會失敗。名稱查閱也會失敗。由於沒有進行有效的驗證，因此無法存取掛接。
- 如果系結成功，則會針對使用者及其認證執行LDAP查詢。如果搜尋時間超過 10 秒，搜尋就會失敗。
如果查閱找到用戶，對應會成功，並透過 Kerberos 授與存取權（前提是票證有效/尚未過期）。

使用 Kerberos 存取的 IP 位址

根據預設，Kerberos 驗證會利用主機名對 IP 位址解析來制定用來擷取 Kerberos 票證的服務主體名稱（SPN）。例如，使用 \SMBVOLUME.CONTOSO.COM 等通用命名慣例路徑存取 SMB 共用時，會針對完整域名 SMBVOLUME.CONTOSO.COM 發出 DNS 要求，並擷取 Azure NetApp Files 磁碟區的 IP 位址。如果沒有 DNS 項目存在 (或目前的項目與所要求的項目不同，例如別名/CNAME)，則無法擷取適當的 SPN，且 Kerberos 要求失敗。因此，如果停用後援驗證方法 (例如 New Technology LAN Manager)，則不允許存取磁碟區。

Azure NetApp Files 中的 DNS 專案會使用動態 DNS 自動建立，並使用 SMB 伺服器的名稱來制定。對於所定義名稱的任何變化/別名，應該建立手動 DNS CNAME 記錄，並指向動態 DNS 專案。如需詳細資訊，請參閱瞭解 Azure NetApp Files 中的 DNS。

NFSv4.1 Kerberos 的運作方式類似 SPN 擷取，其中 DNS 查閱是驗證程序不可或缺的一部分，也可用於 Kerberos 領域探索。

如果在 Azure NetApp Files 磁碟區的存取要求中使用 IP 位址（而非主機名），則 Kerberos 要求會根據使用的通訊協定以不同的方式運作。

具有IP位址和 DNS 名稱的SMB Kerberos行為

使用 SMB 時，使用 IP 位址的 UNC 路徑要求預設 \\x.x.x.x會嘗試使用 NTLM 進行驗證。基於安全性考慮，不允許NTLM的環境中，使用IP位址的SMB要求預設無法使用 Kerberos 或NTLM進行驗證。因此，拒絕存取 Azure NetApp Files 磁碟區。在更新的 Windows 版本中（從 Windows 10 版本 1507 和 Windows Server 2016 開始）， Kerberos 用戶端可以設定為支援 SPN 中的 IPv4 和 IPv6 主機名，以便 SMB 通訊解決此問題。

具有IP位址和 DNS 名稱的 NFSv4.1 Kerberos 行為

使用 NFSv4.1 時，使用其中 sec=[krb5/krb5i/krb5p] 一個選項將掛接要求掛接至 IP 位址會透過 PTR 使用反向 DNS 查閱，將 IP 位址解析為主機名。然後，該主機名會用來制定SPN以進行 Kerberos 票證擷取。如果您使用 NFSv4.1 搭配 Kerberos，則 Azure NetApp Files 磁碟區應該有 A/AAAA 和 PTR，以涵蓋裝載的主機名稱和 IP 位址存取。 Azure NetApp Files 會建立動態 DNS A/AAAA 記錄。如果該子網存在反向 DNS 區域，也會自動建立 PTR 記錄。如需與標準 Azure NetApp Files 主機名慣例的偏差，請使用 CNAME 記錄進行 DNS 別名。

如需詳細資訊，請參閱瞭解 Azure NetApp Files 中的 DNS

共用方式為

了解 Azure NetApp Files 中的 Kerberos