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 ファイル共有にアクセスしている場合、共有レベルのアクセス許可が正しくない場合、ファイル共有へのアクセスは "アクセスが拒否されました" というエラーで失敗します。

解決策

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

• 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に設定する必要があります。
9. CheckFiddlerProxy: Microsoft Entra Kerberos 認証を妨げる Fiddler プロキシが存在するかどうかを確認します。
10. CheckEntraJoinType: マシンが Entra ドメインに参加しているか、ハイブリッド Entra ドメインに参加しているかどうかを確認します。 これは、Microsoft Entra Kerberos 認証の前提条件です。

前のチェックのサブ選択を実行するだけの場合は、 -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 を使用してディレクトリ/ファイル レベルのアクセス許可を構成することをお勧めします。

エクスプローラーでファイル/ディレクトリ所有者の UserPrincipalName (UPN) を表示できない

症状

エクスプローラーは、UPN ではなく、ファイル/ディレクトリ所有者のセキュリティ識別子 (SID) を表示します。

原因

エクスプローラーを使用すると、サーバーに対して RPC API が直接呼び出され、SID が UPN に移動します。 Azure Files はこの API をサポートしていないため、UPN は表示されません。

ソリューション

ドメインに参加しているクライアントで、次の PowerShell コマンドを使用して、ディレクトリ内のすべてのアイテムとその所有者 (UPN を含む) を表示します。

Get-ChildItem <Path> | Get-ACL | Select Path, Owner

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 認証をまだ有効にしていない場合は、こちらのガイダンスに従います。

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

Update-AzStorageAccountAuthForAES256 -ResourceGroupName $ResourceGroupName -StorageAccountName $StorageAccountName

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

以前に所有者または共同作成者のロール割り当てを持っていたユーザー 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 のパスワードを更新する」を参照してください。

$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"

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 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 を再構成すると、新しく作成されたアプリケーションが自動的に作成および管理されます。

エラー 1326 - プライベート リンク使用時のユーザー名またはパスワードが正しくありません

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 Files のトラブルシューティング
• Azure Files のパフォーマンスに関するトラブルシューティング
• Azure Files の接続のトラブルシューティング (SMB)
• Linux での SMB に関する Azure Files の一般的な問題のトラブルシューティング
• Linux での NFS に関する Azure Files の一般的な問題のトラブルシューティング
• Azure File Sync の問題のトラブルシューティング

お問い合わせはこちらから

質問がある場合やヘルプが必要な場合は、サポート要求を作成するか、Azure コミュニティ サポートにお問い合わせください。 Azure フィードバック コミュニティに製品フィードバックを送信することもできます。