次の方法で共有


Azure Files ID ベースの認証と承認に関する問題のトラブルシューティング (SMB)

この記事では、ID ベースの認証で SMB Azure ファイル共有を使用する場合の一般的な問題について一覧で説明します。 これらの問題の考えられる原因と解決策についても説明します。 現在、NFS Azure ファイル共有では、ID ベースの認証はサポートされていません。

適用対象

ファイル共有の種類 SMB NFS
Standard ファイル共有 (GPv2)、LRS/ZRS
Standard ファイル共有 (GPv2)、GRS/GZRS
Premium ファイル共有 (FileStorage)、LRS/ZRS

AzFilesHybrid モジュールを実行するときのエラー

AzFilesHybrid モジュールを実行しようとすると、次のエラーが表示されることがあります。

クライアントは要求された特権を保有していません。

原因: AD のアクセス許可が不十分である

この問題は、モジュールを実行するために必要な Active Directory (AD) アクセス許可がないために発生します。

解決策

AD 特権を参照するか、AD 管理者に連絡して必要な特権を提供してください。

Azure ファイル共有をマウントするときのエラー 5

ファイル共有をマウントしようとすると、以下のエラーが発生する場合があります。

システム エラー 5 が発生しました。 アクセスが拒否されました。

原因: 共有レベルのアクセス許可が正しくない

エンド ユーザーが Active Directory ドメイン Services (AD DS) または Microsoft Entra Domain Services 認証を使用して Azure ファイル共有にアクセスしている場合、共有レベルのアクセス許可が正しくない場合、ファイル共有へのアクセスは "アクセスが拒否されました" というエラーで失敗します。

Note

このエラーは、正しくない共有レベルのアクセス許可以外の問題によって発生する可能性があります。 その他の考えられる原因と解決策については、「Azure Files の接続とアクセスに関する問題のトラブルシューティング」を参照してください。

解決策

アクセス許可が正しく構成されていることを確認します。

  • Active Directory Domain Services (AD DS): 「共有レベルのアクセス許可を割り当てる」を参照してください。

    共有レベルのアクセス許可の割り当ては、Microsoft Entra Connect Sync または Microsoft Entra Connect クラウド同期を使用して AD DS から Microsoft Entra ID に同期されたグループとユーザーでサポートされています。共有レベルのアクセス許可が割り当てられているグループとユーザーが、サポートされていない "クラウド専用" グループではないことを確認します。

  • Microsoft Entra Domain Services については、「Assign share-level permissions (共有レベルのアクセス許可の割り当て)」を参照してください。

Azure Files に対して Microsoft Entra Domain Services 認証を有効にするときに AadDsTenantNotFound エラーが発生し、"Unable to locate active tenants with tenant ID Microsoft Entra tenant-id" (テナント ID Microsoft Entra tenant-id のアクティブなテナントを見つけることができません) というメッセージが表示される

原因

エラー AadDsTenantNotFound は、関連付けられたサブスクリプションの Microsoft Entra テナントで Microsoft Entra Domain Services が作成されていないストレージ アカウントで Azure Files に対して Microsoft Entra Domain Services 認証を有効にしようとすると発生します。

解決策

ストレージ アカウントがデプロイされているサブスクリプションの Microsoft Entra テナントで Microsoft Entra Domain Services を有効にします。 マネージド ドメインを作成するには、Microsoft Entra テナントの管理者特権が必要です。 Microsoft Entra テナントの管理者でない場合は、管理者に連絡し、手順に従って Microsoft Entra Domain Services マネージド ドメインを 作成して構成します

AD 資格情報を使用して Azure ファイル共有をマウントできない

自己診断の手順

最初に、Azure Files AD DS 認証を有効にするためのステップに従っていることを確認します。

次に、ストレージ アカウント キーを使用して Azure ファイル共有をマウントしてみます。 共有のマウントに失敗した場合は、 AzFileDiagnostics をダウンロードして、クライアント実行中の環境を検証します。 AzFileDiagnostics では、Azure Files のアクセス エラーを引き起こす可能性がある互換性のないクライアント構成を検出し、自己修正に関する規範的なガイダンスを提供し、診断トレースを収集できます。

3 つ目は、 Debug-AzStorageAccountAuth コマンドレットを実行して、ログオンしている AD ユーザーを使用して AD 構成に対して一連の基本的なチェックを行うことができます。 このコマンドレットは、AzFilesHybrid バージョン 0.1.2 以降でサポートされています。 このコマンドレットは、対象のストレージ アカウントに対する所有者アクセス許可を持っている AD ユーザーで実行する必要があります。

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

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

コマンドレットでは、次のチェックが順番に実行され、障害に関するガイダンスが提供されます。

  1. CheckADObjectPasswordIsCorrect: ストレージ アカウントを表す AD ID で構成されたパスワードが、ストレージ アカウント kerb1 または kerb2 キーのパスワードと一致していることを確認します。 パスワードが正しくない場合、Update-AzStorageAccountADObjectPassword を実行してパスワードをリセットできます。
  2. CheckADObject: ストレージ アカウントを表し、正しい SPN (サービス プリンシパル名) を持つオブジェクトが Active Directory にあることを確認します。 SPN が正しくセットアップされていない場合は、デバッグ コマンドレットで返される Set-AD コマンドレットを実行して SPN を構成します。
  3. CheckDomainJoined: クライアント コンピューターが AD にドメイン参加していることを検証します。 コンピューターが AD にドメインに参加していない場合は、「 コンピューターをドメインに参加させる ドメインへの参加の手順」を参照してください。
  4. CheckPort445Connectivity: SMB 接続用にポート 445 が開かれているかどうかを確認します。 ポート 445 が開いていない場合は、Azure Files に関する接続の問題について、トラブルシューティング ツール AzFileDiagnostics を参照してください。
  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 ユーザーのオブジェクト ID を指定する必要があります。
  7. CheckGetKerberosTicket: ストレージ アカウントに接続するための Kerberos チケットの取得を試みます。 有効な Kerberos トークンがない場合は、 klist get cifs/storage-account-name.file.core.windows.net コマンドレットを実行し、エラー コードを調べて、チケット取得エラーの原因を特定します。
  8. CheckStorageAccountDomainJoined: AD 認証が有効になっていて、アカウントの AD プロパティが設定されているかどうかを確認します。 有効でない場合 Azure Files で有効な AD DS 認証
  9. CheckUserRbacAssignment: AD ID に、Azure Files にアクセスするための共有レベルのアクセス許可を提供するための適切な RBAC ロールの割り当てがあるかどうかを確認します。 そうでない場合は、共有レベルのアクセス許可 構成。 (AzFilesHybrid バージョン 0.2.3 以降でサポートされています)
  10. CheckUserFileAccess: AD ID に、Azure Files にアクセスするための適切なディレクトリ/ファイルアクセス許可 (Windows ACL) があるかどうかを確認します。 そうでない場合は、ディレクトリ/ファイル レベルのアクセス許可を構成。 このチェックを実行するには、 -FilePath パラメーターと、アクセスをデバッグするマウントされたファイルのパスを指定する必要があります。 (AzFilesHybrid バージョン 0.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 コマンドレットを使用します。

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

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

ファイル共有が X:にマウントされていて、ファイル レベルのアクセス許可 (Windows ACL) に関連するチェックのみを実行する場合は、次の PowerShell コマンドレットを実行できます。

$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 コマンドレットを実行して、一連の基本的なチェックを実行できます。 このコマンドレットは、 AzFilesHybrid v0.3.0 以降のバージョンで、Microsoft Entra Kerberos 認証用に構成されたストレージ アカウントでサポートされています。

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

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

コマンドレットでは、次のチェックが順番に実行され、障害に関するガイダンスが提供されます。

  1. CheckPort445Connectivity: SMB 接続用にポート 445 が開かれているかどうかを確認します。 ポート 445 が開いていない場合は、Azure Files の接続の問題に関するトラブルシューティング ツール AzFileDiagnostics を使用します。
  2. CheckAADConnectivity: Entra 接続を確認します。 クライアントが Entra にアクセスできない場合、Kerberos 認証を使用した SMB マウントが失敗する可能性があります。 このチェックが失敗した場合は、ネットワーク エラー (ファイアウォールまたは VPN の問題など) があることを示します。
  3. CheckEntraObject: ストレージ アカウントを表し、正しいサービス プリンシパル名 (SPN) を持つオブジェクトが Entra に存在することを確認します。 SPN が正しく設定されていない場合は、ストレージ アカウントで Entra Kerberos 認証を無効にして再度有効にします。
  4. CheckRegKey: CloudKerberosTicketRetrieval レジストリ キーが有効になっているかどうかを確認します。 このレジストリ キーは、Entra Kerberos 認証に必要です。
  5. CheckRealmMap: KERBEROS.MICROSOFTONLINE.COM以外の Kerberos 領域にアカウントを参加させる領域マッピングユーザーが構成されているかどうかを確認します。
  6. CheckAdminConsent: Kerberos チケットを取得するために必要な Microsoft Graph のアクセス許可に対して、Entra サービス プリンシパルが管理者の同意を得ているかどうかを確認します。
  7. CheckWinHttpAutoProxySvc: Microsoft Entra Kerberos 認証に必要な WinHTTP Web プロキシ自動検出サービス (WinHttpAutoProxySvc) を確認します。 その状態は Runningに設定する必要があります。
  8. CheckIpHlpScv: Microsoft Entra Kerberos 認証に必要な IP ヘルパー サービス (iphlpsvc) を確認します。 その状態は Runningに設定する必要があります。

前のチェックのサブ選択を実行するだけの場合は、 -Filter パラメーターと、実行するチェックのコンマ区切りのリストを使用できます。

Windows エクスプローラーでディレクトリまたはファイル レベルのアクセス許可 (Windows ACL) を構成できない

症状

マウントされたファイル共有でエクスプローラーを使用して Windows ACL を構成しようとすると、次に示すいずれかの現象が発生する可能性があります。

  • [セキュリティ] タブの [アクセス許可の編集] をクリックした後、アクセス許可ウィザードが読み込まれない。
  • 新しいユーザーまたはグループを選択しようとすると、ドメインの場所に正しい AD DS ドメインが表示されない。
  • 複数の AD フォレストを使用している場合、次のエラー メッセージが表示される: "The Active Directory domain controllers required to find the selected objects in the following domains are not available." (次のドメインで選択したオブジェクトを見つけるために必要な Active Directory ドメイン コントローラーが使用できません。) "Ensure the Active Directory domain controllers are available, and try to select the objects again." (Active Directory ドメイン コントローラーが使用可能であることを確認し、オブジェクトをもう一度選択してみてください。)

解決策

Windows エクスプローラーではなく、icacls を使用してディレクトリ/ファイル レベルのアクセス許可を構成することをお勧めします。

Join-AzStorageAccountForAuth コマンドレットの実行中にエラーが発生した

エラー:"ディレクトリ サービスは、相対 ID を割り当てられませんでした"

このエラーは、RID マスタ FSMO の役割を保持しているドメイン コントローラーが利用できないか、ドメインから削除され、バックアップから復元された場合に発生する可能性があります。 すべてのドメイン コントローラーが実行されていて、使用可能であることを確認します。

エラー: "名前が指定されていないため、位置指定パラメーターをバインドできません"

このエラーは、ほとんどの場合、 Join-AzStorageAccountforAuth コマンドの構文エラーによってトリガーされます。コマンドのスペルミスや構文エラーを確認し、最新バージョンの AzFilesHybrid モジュール (https://github.com/Azure-Samples/azure-files-samples/releases) がインストールされていることを確認します。

Azure Files オンプレミス AD DS 認証による AES-256 Kerberos 暗号化のサポート

Azure Files は、AzFilesHybrid モジュール v0.2.2 以降で、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

このコマンドレットは、更新プログラムの一環として、AES-256 に切り替えるために必要な Kerberos キーをローテーションします。 両方のパスワードを再生成しない限り、再びローテーションする必要はありません。

以前に所有者または共同作成者のロール割り当てを持っていたユーザー ID にまだストレージ アカウント キーのアクセス権がある

ストレージ アカウントの所有者と共同作成者のロールは、ストレージ アカウント キーを一覧表示する権限を付与します。 ストレージ アカウント キーを使用すると、ファイル共有、BLOB コンテナー、テーブル、キューなどのストレージ アカウントのデータへのフル アクセスと、FileREST API を通じて公開されたレガシ管理 API を使用する Azure Files 管理操作への制限付きアクセスが可能になります。 ロールの割り当てを変更する場合は、所有者または共同作成者のロールから削除されたユーザーが、保存されたストレージ アカウント キーを使用して引き続きストレージ アカウントにアクセスできる可能性があることを考慮する必要があります。

解決策 1

この問題は、ストレージ アカウント キーをローテーションすることで簡単に解決できます。 キーは一度に 1 つずつローテーションし、ローテーションするときにアクセス権を 1 つずつ切り替えることをお勧めします。 ストレージ アカウントで提供される共有キーには 2 つの種類があります。1 つはストレージ アカウント キーで、これはストレージ アカウントのデータへのスーパー管理者アクセス権を提供します。もう 1 つは Kerberos キーで、これは、Windows Server Active Directory のシナリオでストレージ アカウントと Windows Server Active Directory ドメイン コントローラーとの間の共有シークレットとして機能します。

ストレージ アカウントの Kerberos キーをローテーションするには、「AD DS のストレージ アカウント ID のパスワードを更新する」を参照してください。

Azure portal で目的のストレージ アカウントに移動します。 目的のストレージ アカウントの目次で、[セキュリティとネットワーク] という見出しの下の [アクセス キー] を選択します。 [アクセス キー] ウィンドウで、目的のキーの上にある [キーの交換] を選択します。

[アクセス キー] ウィンドウを示すスクリーンショット。

新しく作成されたアプリケーションに対する API アクセス許可を設定する

Microsoft Entra Kerberos 認証を有効にした後、構成を完了するには、Microsoft Entra テナントに登録されている新しい Microsoft Entra アプリケーションに管理者の同意を明示的に付与する必要があります。 これらの手順に従って、Azure portal から 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 portal でどのように表示されるかを示すスクリーンショットを次に示します。

[構成済みのアクセス許可] ブレードを示すスクリーンショット。アクセス許可が原因で一部のアクションが無効になる可能性があることを示す警告が表示されます。

その場合は、Microsoft Entra 管理者に、新しい Microsoft Entra アプリケーションに管理者の同意を付与するよう依頼してください。 管理者を探して表示するには、[ロールと管理者] を選択し、[クラウド アプリケーション管理者] を選択します。

エラー - "Azure AD Graph への要求がコード BadRequest で失敗しました"

原因 1: アプリケーション管理ポリシーが資格情報の作成を妨げている

Microsoft Entra Kerberos 認証を有効にすると、次の条件が満たされると、このエラーが発生する可能性があります。

  1. アプリケーション管理ポリシーのベータ/プレビュー機能を使用しています。
  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 認証を以前に有効にしている場合、ストレージ アカウントのサービス プリンシパルのパスワードは 6 か月ごとに期限切れに設定されます。 パスワードの有効期限が切れると、ユーザーはファイル共有に対する Kerberos チケットを取得できなくなります。

これを軽減するには、2 つのオプションがあります。Microsoft Entra のサービス プリンシパル パスワードを 6 か月ごとにローテーションするか、次の手順に従って Microsoft Entra Kerberos を無効にし、既存のアプリケーションを削除し、Microsoft Entra Kerberos を再構成します。

Windows エクスプローラーを使用してディレクトリとファイル レベルのアクセス許可を構成する場合は、再構成中に必要になるので、Microsoft Entra Kerberos を無効にする前にドメイン プロパティ (domainName と domainGUID) を保存してください。 ドメインのプロパティを保存しなかった場合でも、回避策としてicacls を使用してディレクトリ/ファイル レベルのアクセス許可を構成できます。

  1. Microsoft Entra Kerberos を無効にする
  2. 既存のアプリケーションを削除します
  3. Azure portal を使用して Microsoft Entra Kerberos を再構成する

Microsoft Entra Kerberos を再構成すると、新しく作成されたアプリケーションが自動的に作成および管理されます。

Microsoft Entra Kerberos 認証を使用してプライベート エンドポイントまたはプライベート リンク経由でストレージ アカウントに接続している場合、 net use またはその他の方法でファイル共有をマウントしようとすると、クライアントに資格情報の入力を求められます。 ユーザーはおそらく資格情報を入力しますが、その資格情報が拒否されます。

原因

これは、SMB クライアントで Kerberos の使用を試みたのに失敗したためなので、NTLM 認証の使用してフォールバックします。この認証はドメイン資格情報のNTLM認証を使用して Azure Files ではサポートされていません。 プライベート リンク FQDN は既存の Microsoft Entra アプリケーションに登録されていないため、クライアントはストレージ アカウントへの Kerberos チケットを取得できません。

解決策

解決策は、ファイル共有をマウントする前に、ストレージ アカウントの Microsoft Entra アプリケーションに privateLink FQDN を追加することです。 以下の手順に従って Azure portal を使用すると、アプリケーション オブジェクトに必要な 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 コミュニティ サポートにお問い合わせください。 Azure フィードバック コミュニティに製品フィードバックを送信することもできます。