針對SMB) (Azure 檔案儲存體 身分識別型驗證和授權問題進行疑難解答

  • 發行項

本文列出搭配身分識別型驗證使用SMB Azure檔案共用時的常見問題。 它也提供這些問題的可能原因和解決方法。 NFS Azure 檔案共用目前不支援身分識別型驗證。

適用於

檔案共享類型 SMB Nfs
GPv2) 、LRS/ZRS (標準檔案共用
GPv2) 、GRS/GZRS (標準檔案共用
FileStorage) 、LRS/ZRS (進階檔案共用

執行 AzFilesHybrid 模組時發生錯誤

當您試著執行 AzFilesHybrid 模組時，可能會收到下列錯誤：

用戶端不會持有必要的許可權。

原因：AD 許可權不足

發生此問題的原因是您沒有必要的 Active Directory (AD) 執行模組的許可權。

解決方案

請參閱 AD 許可權，或連絡您的 AD 系統管理員以提供必要的許可權。

掛接 Azure 檔案共享時發生錯誤 5

當您嘗試掛接檔案共享時，可能會收到下列錯誤：

發生系統錯誤 5。 拒絕存取。

原因：共用層級許可權不正確

如果終端使用者使用 #D8FD6B1AFA1764A5FA55201F9C0CE3F61 (AD DS) 或 Microsoft Entra Domain Services 驗證來存取 Azure 檔案共用，如果共用層級許可權不正確，則檔案共用的存取會失敗，並出現「拒絕存取」錯誤。

注意事項

此錯誤可能是由不正確的共享層級許可權以外的問題所造成。 如需其他可能原因和解決方案的相關信息，請參閱針對 Azure 檔案儲存體 連線能力和存取問題進行疑難解答。

解決方案

驗證是否已正確設定權限：

  • Active Directory 網域服務 (AD DS) 請參閱指派共用層級許可權。

    已使用 Microsoft Entra Connect Sync 或 Microsoft Entra Connect 雲端同步處理，從 AD DS 同步至 Microsoft Entra ID 的群組和使用者支援共用層級許可權指派。確認獲指派共用層級許可權的群組和使用者不支援「僅限雲端」群組。

  • Microsoft Entra Domain Services請參閱指派共用層級許可權。

AadDsTenantNotFound 在為 Azure 檔案儲存體 啟用 Microsoft Entra Domain Services 驗證時發生錯誤「找不到租使用者標識碼 Microsoft Entra tenant-id 的作用中租使用者」

原因

當您嘗試在未在記憶體帳戶上建立 Microsoft Entra Domain Services 的記憶體帳戶上啟用 Microsoft Entra Domain Services 驗證 Azure 檔案儲存體 時，就會發生錯誤 AadDsTenantNotFound Microsoft Entra相關聯訂用帳戶的租使用者。

解決方案

在記憶體帳戶部署至的訂用帳戶 Microsoft Entra 租用戶上啟用 Microsoft Entra Domain Services。 您需要 Microsoft Entra 租用戶的系統管理員許可權，才能建立受控網域。 如果您不是 Microsoft Entra 租用戶的系統管理員，請連絡系統管理員，並遵循逐步指引來建立和設定 Microsoft Entra Domain Services 受控網域。

無法使用 AD 認證掛接 Azure 檔案共用

自我診斷步驟

首先，請確定您已遵循啟用 #D133D70365F3445AD84F100AB4580C81D AD DS 驗證的步驟。

第二，嘗試 使用記憶體帳戶密鑰掛接 Azure 檔案共用。 如果共用無法掛接，請下載 AzFileDiagnostics 以協助您驗證客戶端執行環境。 AzFileDiagnostics 可以偵測可能造成 Azure 檔案儲存體 存取失敗的不相容客戶端設定、提供自我修正的規範指引，以及收集診斷追蹤。

第三，您可以執行 Cmdlet Debug-AzStorageAccountAuth ，以使用已登入的 AD 使用者對您的 AD 設定進行一組基本檢查。 AzFilesHybrid v0.1.2+ 版支援此 Cmdlet。 您必須以具有目標記憶體帳戶擁有者許可權的 AD 使用者執行此 Cmdlet。

$ResourceGroupName = "<resource-group-name-here>"
$StorageAccountName = "<storage-account-name-here>"

Debug-AzStorageAccountAuth `
    -StorageAccountName $StorageAccountName `
    -ResourceGroupName $ResourceGroupName `
    -Verbose

Cmdlet 會依序執行這些檢查，並提供失敗指引：

  1. CheckADObjectPasswordIsCorrect：確定在代表記憶體帳戶的AD身分識別上設定的密碼符合記憶體帳戶 kerb1 或 kerb2 金鑰的密碼。 如果密碼不正確，您可以執行 Update-AzStorageAccountADObjectPassword 來重設密碼。
  2. CheckADObject：確認 Active Directory 中有一個物件代表記憶體帳戶，且具有正確的 SPN (服務主體名稱) 。 如果未正確設定 SPN，請執行 Set-AD 偵錯 Cmdlet 中傳回的 Cmdlet 來設定 SPN。
  3. CheckDomainJoined：驗證客戶端電腦是否已加入AD網域。 如果您的電腦未加入AD網域，請參閱將 電腦加入網域以 取得網域加入指示。
  4. CheckPort445Connectivity：檢查是否已開啟埠 445 以進行SMB連線。 如果埠 445 未開啟，請參閱疑難解答工具 AzFileDiagnostics 以瞭解 Azure 檔案儲存體 的連線問題。
  5. CheckSidHasAadUser：檢查登入的 AD 使用者是否已同步至 Microsoft Entra ID。 如果您要查詢特定 AD 使用者是否已同步至 Microsoft Entra ID，您可以在輸入參數中指定 -UserName 和 -Domain 。 針對指定的 SID，它會檢查是否有 Microsoft Entra 相關聯的使用者。
  6. CheckAadUserHasSid：檢查登入的 AD 使用者是否已同步至 Microsoft Entra ID。 如果您要查詢特定 AD 使用者是否已同步至 Microsoft Entra ID，您可以在輸入參數中指定 -UserName 和 -Domain 。 針對指定的 Microsoft Entra 使用者，它會檢查其 SID。 若要執行這項檢查，您必須提供 -ObjectId 參數，以及 Microsoft Entra 使用者的物件標識符。
  7. CheckGetKerberosTicket：嘗試取得 Kerberos 票證以連線到記憶體帳戶。 如果沒有有效的 Kerberos 令牌，請執行 klist get cifs/storage-account-name.file.core.windows.net Cmdlet 並檢查錯誤碼，以判斷票證擷取失敗的原因。
  8. CheckStorageAccountDomainJoined：檢查是否已啟用AD驗證，並填入帳戶的AD屬性。 如果沒有，請在 Azure 檔案儲存體 上啟用AD DS驗證。
  9. CheckUserRbacAssignment：檢查 AD 身分識別是否具有適當的 RBAC 角色指派，以提供存取 Azure 檔案儲存體 的共享層級許可權。 如果沒有， 請設定共用層級許可權。 (AzFilesHybrid v0.2.3+ 版本)
  10. CheckUserFileAccess：檢查 AD 身分識別是否具有適當的目錄/檔案許可權， (Windows ACL) 存取 Azure 檔案儲存體。 如果沒有， 請設定目錄/檔案層級許可權。 若要執行這項檢查，您必須提供 -FilePath 參數，以及您要對存取進行偵錯之掛接檔案的路徑。 (AzFilesHybrid v0.2.3+ 版本)
  11. CheckAadKerberosRegistryKeyIsOff：檢查 Microsoft Entra Kerberos 登錄機碼是否關閉。 如果金鑰已開啟，請 reg add HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters /v CloudKerberosTicketRetrievalEnabled /t REG_DWORD /d 0 從提升許可權的命令提示字元執行 以將其關閉，然後重新啟動您的計算機。 AzFilesHybrid v0.2.9+ 版本 (支援)

如果您只想要執行先前檢查的子選取，您可以使用 -Filter 參數，以及要執行的逗號分隔檢查清單。 例如，若要 (RBAC) 執行與共用層級許可權相關的所有檢查，請使用下列 PowerShell Cmdlet：

$ResourceGroupName = "<resource-group-name-here>"
$StorageAccountName = "<storage-account-name-here>"

Debug-AzStorageAccountAuth `
    -Filter CheckSidHasAadUser,CheckUserRbacAssignment `
    -StorageAccountName $StorageAccountName `
    -ResourceGroupName $ResourceGroupName `
    -Verbose

如果您已在 上 X:掛接檔案共用，而且如果您只想要執行與 Windows ACL) (檔案層級許可權相關的檢查，您可以執行下列 PowerShell Cmdlet：

$ResourceGroupName = "<resource-group-name-here>"
$StorageAccountName = "<storage-account-name-here>"
$FilePath = "X:\example.txt"

Debug-AzStorageAccountAuth `
    -Filter CheckUserFileAccess `
    -StorageAccountName $StorageAccountName `
    -ResourceGroupName $ResourceGroupName `
    -FilePath $FilePath `
    -Verbose

無法使用 Windows 檔案總管 設定 Windows ACL) (目錄/檔案層級許可權

徵兆

嘗試在掛接的檔案共享上設定具有 檔案總管 的 Windows ACL 時，您可能會遇到以下所述的其中一個徵兆：

  • 按兩下 [安全性] 索引標籤下的 [ 編輯 許可權] 之後，不會載入 [許可權精靈]。
  • 當您嘗試選取新的使用者或群組時，網域位置不會顯示正確的 AD DS 網域。
  • 您正在使用多個 AD 樹系，並收到下列錯誤訊息：「在下列網域中尋找所選物件所需的 Active Directory 域控制器無法使用。 請確定 Active Directory 域控制器可供使用，並嘗試再次選取物件。」

解決方案

建議您使用 icacls 來設定目錄/檔案層級許可權，而不是使用 Windows 檔案總管。

執行 Join-AzStorageAccountForAuth Cmdlet 時發生錯誤

錯誤：「目錄服務無法配置相對識別碼」

如果保留 RID 主要 FSMO 角色的域控制器無法使用或已從網域中移除並從備份還原，可能會發生此錯誤。 確認所有域控制器都正在執行且可供使用。

錯誤：「無法系結位置參數，因為未指定任何名稱」

此錯誤很可能是由 命令中的 Join-AzStorageAccountforAuth 語法錯誤所觸發。檢查 命令中是否有拼字錯誤或語法錯誤，並確認已安裝最新版的 AzFilesHybrid 模組 (https://github.com/Azure-Samples/azure-files-samples/releases) 。

Azure 檔案儲存體 AES-256 Kerberos 加密的內部部署 AD DS 驗證支援

從 AzFilesHybrid 模組 v0.2.2 開始，Azure 檔案儲存體 支援 AD DS 驗證的 AES-256 Kerberos 加密。 AES-256 是建議的加密方法，它是從 AzFilesHybrid 模組 v0.2.5 開始的預設加密方法。 如果您已使用低於 v0.2.2 的模組版本來啟用 AD DS 驗證，則必須 下載最新的 AzFilesHybrid 模組 ，並執行下列 PowerShell。 如果您尚未在記憶體帳戶上啟用 AD DS 驗證，請遵循此 指引。

重要事項

如果您先前使用 RC4 加密，並將記憶體帳戶更新為使用 AES-256，您應該 klist purge 在用戶端上執行，然後重新掛接檔案共用，以使用 AES-256 取得新的 Kerberos 票證。

$ResourceGroupName = "<resource-group-name-here>"
$StorageAccountName = "<storage-account-name-here>"

Update-AzStorageAccountAuthForAES256 -ResourceGroupName $ResourceGroupName -StorageAccountName $StorageAccountName

在更新過程中，Cmdlet 會輪替 Kerberos 金鑰，這是切換至 AES-256 的必要專案。 除非您想要重新產生這兩個密碼，否則不需要輪替。

先前具有擁有者或參與者角色指派的使用者身分識別仍具有記憶體帳戶密鑰存取權

記憶體帳戶擁有者和參與者角色授與列出記憶體帳戶密鑰的能力。 儲存器帳戶密鑰可讓您完整存取記憶體帳戶的數據，包括檔案共用、Blob 容器、數據表和佇列，以及透過透過 FileREST API 公開的舊版管理 API 對 Azure 檔案儲存體 管理作業的有限存取權。 如果您要變更角色指派，您應該考慮從擁有者或參與者角色中移除的使用者，可能會繼續透過儲存的記憶體帳戶密鑰來維持對記憶體帳戶的存取權。

解決方案 1

您可以藉由輪替記憶體帳戶密鑰，輕鬆地解決此問題。 建議您一次輪替一個密鑰，在輪替時將存取從一個切換為另一個。 儲存體帳戶提供兩種類型的共用密鑰：記憶體帳戶金鑰，可提供記憶體帳戶數據的超級管理員存取權，以及 Kerberos 金鑰，可作為記憶體帳戶與 Windows Server Active Directory 域控制器之間的共用密碼，以 Windows Server Active Directory場景。

若要輪替記憶體帳戶的 Kerberos 金鑰，請參閱 在 AD DS 中更新記憶體帳戶身分識別的密碼。

流覽至 Azure 入口網站 中所需的記憶體帳戶。 在所需記憶體帳戶的目錄中，選取 [安全性 + 網络] 標題下的 [存取金鑰]。 在 [ 存取金鑰 ] 窗格中，選取所需 金鑰上方的 [旋轉金 鑰]。

顯示 [存取金鑰] 窗格的螢幕快照。

在新建立的應用程式上設定 API 許可權

啟用 Microsoft Entra Kerberos 驗證之後，您必須明確地將系統管理員同意授與在 Microsoft Entra 租用戶中註冊的新 Microsoft Entra 應用程式，以完成您的設定。 您可以遵循下列步驟，從 Azure 入口網站 設定 API 許可權。

  1. 開啟 Microsoft Entra ID。
  2. 選取左窗格中的 [應用程式註冊]。
  3. 選取右窗格中的 [ 所有應用程式 ]。
  4. 選取名稱符合 [記憶體帳戶] $storageAccountName.file.core.windows.net 的應用程式。
  5. 在左窗格中選取 [API 許可權]。
  6. 選取頁面底部的 [ 新增 許可權]。
  7. 選 取 [授與系統管理員同意“DirectoryName]。

為混合式使用者啟用 Microsoft Entra Kerberos 驗證時可能發生的錯誤

針對混合式使用者帳戶啟用 Microsoft Entra Kerberos 驗證時，您可能會遇到下列錯誤。

錯誤 - 授與管理員同意已停用

在某些情況下，Microsoft Entra 系統管理員可能會停用將系統管理員同意授與 Microsoft Entra 應用程式的能力。 以下是此功能在 Azure 入口網站 中的螢幕快照。

顯示 [已設定的許可權] 刀鋒視窗的螢幕快照，其中顯示某些動作可能因為您的許可權而停用的警告。

如果是這種情況，請要求 Microsoft Entra 系統管理員將系統管理員同意授與新的 Microsoft Entra 應用程式。 若要尋找並檢視您的系統管理員，請選取 角色和系統管理員，然後選取 [雲端應用程式管理員]。

錯誤 - 「對 Azure AD Graph 的要求失敗，程式代碼為 BadRequest」

原因 1：應用程式管理原則防止建立認證

啟用 Microsoft Entra Kerberos 驗證時，如果符合下列條件，您可能會遇到此錯誤：

  1. 您使用的是應用程式 管理原則的 Beta/預覽功能。
  2. 您 (或系統管理員) 已設定 租使用者範圍的原則 ：
    • 沒有開始日期，或在 2019 年 1 月 1 日之前有開始日期。
    • 設定服務主體密碼的限制，不允許自定義密碼，或設定最少於 365.5 天的密碼存留期上限。

此錯誤目前沒有因應措施。

原因 2：記憶體帳戶的應用程式已經存在

如果您先前已透過手動有限預覽步驟啟用 Microsoft Entra Kerberos 驗證，您也可能會遇到此錯誤。 若要刪除現有的應用程式，客戶或其IT系統管理員可以執行下列腳本。 執行此文稿會移除舊手動建立的應用程式，並允許新體驗自動建立和管理新建立的應用程式。 起始與 Microsoft Graph 的連線之後，請登入您裝置上的 Microsoft Graph 命令行工具應用程式，並將許可權授與應用程式。

$storageAccount = "exampleStorageAccountName"
$tenantId = "aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee"
Install-Module Microsoft.Graph
Import-Module Microsoft.Graph
Connect-MgGraph -TenantId $tenantId -Scopes "User.Read","Application.Read.All"

$application = Get-MgApplication -Filter "DisplayName eq '${storageAccount}'"
if ($null -ne $application) {
   Remove-MgApplication -ObjectId $application.ObjectId
}

錯誤 - 服務主體密碼在 Microsoft Entra ID 中已過期

如果您先前已透過手動有限預覽步驟啟用 Microsoft Entra Kerberos 驗證，則記憶體帳戶服務主體的密碼會設定為每六個月到期一次。 密碼到期后，用戶將無法取得檔案共用的 Kerberos 票證。

若要減輕此問題，您有兩個選項：每隔六個月輪替 Microsoft Entra 一次服務主體密碼，或遵循下列步驟停用 Microsoft Entra Kerberos、刪除現有的應用程式，以及重新設定 Microsoft Entra Kerberos。

在停用 Microsoft Entra Kerberos 之前，請務必先將網域屬性儲存 (domainName 和 domainGUID) ，因為如果您想要使用 Windows 檔案總管 設定目錄和檔案層級許可權，則在重新設定期間需要這些屬性。 如果您未儲存網域屬性，您仍然可以 使用 icacls 設定目錄/檔案層級 許可權作為因應措施。

  1. 停用 Microsoft Entra Kerberos
  2. 刪除現有的應用程式
  3. 透過 Azure 入口網站 重新設定 Microsoft Entra Kerberos

重新設定 Microsoft Entra Kerberos 之後，新的體驗將會自動建立和管理新建立的應用程式。

錯誤 1326 - 使用私人連結時的使用者名稱或密碼不正確

如果您使用 Microsoft Entra Kerberos 驗證透過私人端點/私人連結連線到記憶體帳戶，則嘗試透過 net use 或其他方法掛接檔案共享時，會提示用戶端輸入認證。 使用者可能會在 中輸入其認證，但認證會遭到拒絕。

原因

這是因為SMB客戶端嘗試使用 Kerberos 但失敗，因此會回復為使用NTLM驗證，Azure 檔案儲存體 不支援針對網域認證使用NTLM驗證。 客戶端無法取得記憶體帳戶的 Kerberos 票證，因為私人連結 FQDN 未向任何現有的 Microsoft Entra 應用程式註冊。

解決方案

解決方案是在掛接檔案共用之前，將 privateLink FQDN 新增至記憶體帳戶的 Microsoft Entra 應用程式。 您可以依照下列步驟，使用 Azure 入口網站 將必要的 identifierUris 新增至應用程式物件。

  1. 開啟 Microsoft Entra ID。

  2. 選取左窗格中的 [應用程式註冊]。

  3. 選取 [所有應用程式]。

  4. 選取名稱符合 [記憶體帳戶] $storageAccountName.file.core.windows.net 的應用程式。

  5. 選取左窗格中的 [指令清單]。

  6. 複製並貼上現有的內容，讓您有重複的複本。

  7. 編輯 JSON 指令清單。 針對每個 <storageAccount>.file.core.windows.net 專案，新增對應 <storageAccount>.privatelink.file.core.windows.net 的專案。 例如，如果您的指令清單具有的下列值 identifierUris：

    "identifierUris": [
    "api://<tenantId>/HOST/<storageaccount>.file.core.windows.net",
    "api://<tenantId>/CIFS/<storageaccount>.file.core.windows.net",
    "api://<tenantId>/HTTP/<storageaccount>.file.core.windows.net",
    "HOST/<storageaccount>.file.core.windows.net",
    "CIFS/<storageaccount>.file.core.windows.net",
    "HTTP/<storageaccount>.file.core.windows.net"
],

    然後，您應該將欄 identifierUris 位編輯為下列內容：

    "identifierUris": [
    "api://<tenantId>/HOST/<storageaccount>.file.core.windows.net",
    "api://<tenantId>/CIFS/<storageaccount>.file.core.windows.net",
    "api://<tenantId>/HTTP/<storageaccount>.file.core.windows.net",
    "HOST/<storageaccount>.file.core.windows.net",
    "CIFS/<storageaccount>.file.core.windows.net",
    "HTTP/<storageaccount>.file.core.windows.net",

    "api://<tenantId>/HOST/<storageaccount>.privatelink.file.core.windows.net",
    "api://<tenantId>/CIFS/<storageaccount>.privatelink.file.core.windows.net",
    "api://<tenantId>/HTTP/<storageaccount>.privatelink.file.core.windows.net",
    "HOST/<storageaccount>.privatelink.file.core.windows.net",
    "CIFS/<storageaccount>.privatelink.file.core.windows.net",
    "HTTP/<storageaccount>.privatelink.file.core.windows.net"
],

  8. 檢閱內容，然後選取 [儲存] 以使用新的 identifierUris 更新應用程式物件。

  9. 更新任何內部 DNS 參考以指向私人連結。

  10. 重試掛接共用。

錯誤AADSTS50105

下列錯誤AADSTS50105中斷要求：

您的系統管理員已設定應用程式「企業應用程式名稱」來封鎖使用者，除非他們特別獲授與 (指派) 應用程式的存取權。 已登入的使用者 『{EmailHidden}』 遭到封鎖，因為他們不是具有存取權的群組直接成員，也沒有系統管理員直接指派的存取權。 請連絡您的系統管理員以指派此應用程式的存取權。

原因

如果您為對應的企業應用程式設定「需要指派」，您將無法取得 Kerberos 票證，Microsoft Entra 登入記錄會顯示錯誤，即使使用者或群組已指派給應用程式。

解決方案

請勿針對記憶體帳戶選取 Microsoft Entra 應用程式所需的指派，因為我們不會在傳回給要求者的 Kerberos 票證中填入權利。 如需詳細資訊，請 參閱錯誤AADSTS50105 - 登入的使用者未指派給應用程式的角色。

另請參閱

與我們連絡，以取得說明

如果您有問題或需要相關協助，請建立支援要求，或詢問 Azure community 支援。 您也可以將產品意見反應提交給 Azure 意應見反社群。