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

本文列出搭配身分識別型驗證使用 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。 存取遭到拒絕。

原因：共用層級權限不正確

如果使用者使用 Active Directory 網域服務 或 Microsoft Entra Domain Services 驗證來存取 Azure 檔案共用，如果共用層級許可權不正確，則檔案共用的存取會失敗，並出現「拒絕存取」錯誤。

注意

此錯誤可能是因為共用層級權限不正確以外的問題所造成。 如需其他可能原因和解決方案的資訊，請參閱針對 Azure 檔案儲存體連線和存取問題進行疑難排解。

解決方案

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

• 針對 Active Directory Domain Services (AD DS)，請參閱將共用層級權限指派給身分識別 (機器翻譯)。

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

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

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

原因

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

解決方案

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

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

自我診斷步驟

首先，請確定您已遵循步驟，啟用 Azure 檔案儲存體 AD DS 驗證。

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

第三，您可以執行 Debug-AzStorageAccountAuth Cmdlet，以使用登入 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，請執行偵錯 Cmdlet 中傳回的 Set-AD Cmdlet 以設定 SPN。
3. CheckDomainJoined：驗證客戶端電腦是否已加入AD網域。 如果您的電腦未加入AD網域，請參閱 將電腦 加入網域以取得網域加入指示。
4. CheckPort445Connectivity：檢查是否已針對SMB連線開啟埠445。 如果埠 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

無法使用 Microsoft Entra Kerberos 掛接 Azure 檔案共用

自我診斷步驟

首先，請確定您已遵循步驟來 啟用 Microsoft Entra Kerberos 驗證。

其次，您可以執行 Debug-AzStorageAccountAuth Cmdlet 來執行一組基本檢查。 在 AzFilesHybrid v0.3.0+ 版本上，此 Cmdlet 支援針對 Microsoft Entra Kerberos 驗證設定的記憶體帳戶。

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

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

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

1. CheckPort445Connectivity：檢查是否已針對SMB連線開啟埠445。 如果未開啟埠 445，請使用疑難解答工具 AzFileDiagnostics 來取得 Azure 檔案儲存體 的連線問題。
2. CheckAADConnectivity：檢查 Entra 連線能力。 如果客戶端無法連線到 Entra，使用 Kerberos 驗證的 SMB 掛接可能會失敗。 如果這項檢查失敗，表示發生網路錯誤（可能是防火牆或 VPN 問題）。
3. CheckEntraObject：確認 Entra 中有代表記憶體帳戶的物件，且具有正確的服務主體名稱 （SPN）。 如果未正確設定 SPN，請在記憶體帳戶上停用並重新啟用 Entra Kerberos 驗證。
4. CheckRegKey：檢查登錄機碼是否 CloudKerberosTicketRetrieval 已啟用。 Entra Kerberos 驗證需要此登錄機碼。
5. CheckRealmMap：檢查使用者是否已設定將帳戶加入另一個 Kerberos 領域以外的KERBEROS.MICROSOFTONLINE.COM任何領域對應。
6. CheckAdminConsent：檢查 Entra 服務主體 是否已獲得系統管理員同意 ，以取得 Kerberos 票證所需的Microsoft Graph 許可權。
7. CheckWinHttpAutoProxySvc：檢查 Microsoft Entra Kerberos 驗證所需的 WinHTTP Web Proxy 自動探索服務 （WinHttpAutoProxySvc）。 狀態應設定為 Running。
8. CheckIpHlpScv：檢查Microsoft Entra Kerberos 驗證所需的IP協助程式服務 （iphlpsvc）。 狀態應設定為 Running。

如果您只想執行先前檢查的子選取，您可以使用 -Filter 參數，以及要執行的逗號分隔檢查清單。

無法使用 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。

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

Azure 檔案儲存體支援 AES-256 Kerberos 加密，可使用 AzFilesHybrid 模組 v0.2.2 以上版本的 AD DS 驗證。 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 入口網站中，巡覽至需要的儲存體帳戶。 在所需儲存體帳戶的目錄中，選取安全性 + 網路標題下的存取金鑰。 在 [存取金鑰] 窗格中，選取所需金鑰上方的 [輪替金鑰]。

PowerShell

下列指令碼會輪用儲存體帳戶的兩個金鑰。 如果您想在輪替期間交換金鑰，則必須在指令碼中提供其他邏輯以處理此情況。 請記得將 <resource-group> 和 <storage-account> 取代為您環境適用的值。

$resourceGroupName = "<resource-group>"
$storageAccountName = "<storage-account>"

# Rotate primary key (key 1). You should switch to key 2 before rotating key 1.
New-AzStorageAccountKey `
    -ResourceGroupName $resourceGroupName `
    -Name $storageAccountName `
    -KeyName "key1"

# Rotate secondary key (key 2). You should switch to the new key 1 before rotating key 2.
New-AzStorageAccountKey `
    -ResourceGroupName $resourceGroupName `
    -Name $storageAccountName `
    -KeyName "key2"

Azure CLI

下列指令碼會輪用儲存體帳戶的兩個金鑰。 如果您想在輪替期間交換金鑰，則必須在指令碼中提供其他邏輯以處理此情況。 請記得將 <resource-group> 和 <storage-account> 取代為您環境適用的值。

RESOURCE_GROUP_NAME="<resource-group>"
STORAGE_ACCOUNT_NAME="<storage-account>"

# Rotate primary key (key 1). You should switch to key 2 before rotating key 1.
az storage account keys renew \
    --resource-group $RESOURCE_GROUP_NAME \
    --account-name $STORAGE_ACCOUNT_NAME \
    --key "primary"

# Rotate secondary key (key 2). You should switch to the new key 1 before rotating key 2.
az storage account keys renew \
    --resource-group $RESOURCE_GROUP_NAME \
    --account-name $STORAGE_ACCOUNT_NAME \
    --key "secondary"

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

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

1. 開啟 Microsoft Entra ID。
2. 在左窗格中，選取 [應用程式註冊]。
3. 在右窗格中，選取 [所有應用程式]。
4. 選取名稱符合 [Storage Account] $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 識別碼中已過期

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

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

如果您想要使用 Windows 檔案總管 設定目錄和檔案層級許可權，請務必先儲存網域屬性 （domainName 和 domainGUID），再停用 Microsoft Entra Kerberos，因為如果您想要使用 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. 選取名稱符合 [Storage Account] $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 檔案進行疑難排解
• 針對 Azure 檔案儲存體效能進行疑難排解
• 針對 Azure 檔案儲存體連線進行疑難排解 (SMB)
• 針對 Linux 上的 Azure 檔案儲存體一般 SMB 問題進行疑難排解
• 針對 Linux 上的 Azure 檔案儲存體一般 NFS 問題進行疑難排解
• 針對 Azure 檔案同步問題進行移難排解

與我們連絡，以取得說明

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