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

[アーティクル]
11/15/2024

この記事では、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 管理者に連絡して必要な特権を提供してください。

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

システムエラー 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

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

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

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

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

重要

以前に RC4 暗号化を使用していて、AES-256 を使用するようにストレージアカウントを更新する場合は、クライアントで klist purge を実行してからファイル共有を再マウントして、AES-256 を使用した新しい Kerberos チケットを取得する必要があります。

$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 のパスワードを更新する」を参照してください。

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

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

次のスクリプトは、ストレージアカウントの両方のキーをローテーションします。ローテーションの間にキーを交換する場合は、このシナリオを処理するためのロジックをスクリプトに追加する必要があります。忘れずに、<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"

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 のアクセス許可を構成できます。

Microsoft Entra ID を開きます。
左ウィンドウで [アプリの登録] を選択します。
右ウィンドウで [すべてのアプリケーション] を選択します。
[ストレージアカウント] $storageAccountName.file.core.windows.net に一致する名前のアプリケーションを選びます。
左ウィンドウで [API のアクセス許可] を選択します。
ページの下部にある [アクセス許可の追加] を選択します。
["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 認証を有効にすると、次の条件が満たされると、このエラーが発生する可能性があります。

アプリケーション管理ポリシーのベータ/プレビュー機能を使用しています。
ユーザー (または管理者) は、次のテナント全体のポリシーを設定。
- 開始日がないか、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 を使用してディレクトリ/ファイルレベルのアクセス許可を構成できます。

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 を追加できます。

Microsoft Entra ID を開きます。
左ウィンドウで [アプリの登録] を選択します。
[すべてのアプリケーション] を選択します。
[ストレージアカウント] $storageAccountName.file.core.windows.net に一致する名前のアプリケーションを選びます。
左側のペインで [マニフェスト] を選択します。
既存のコンテンツをコピーして貼り付けて、複製したコピーを用意します。

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"
],

コンテンツを確認し、[保存] を選択して、新しい identifierUris でアプリケーションオブジェクトを更新します。
プライベートリンクを指す内部 DNS 参照を更新します。
共有のマウントを再試行します。

エラー AADSTS50105

要求は、次のエラー AADSTS50105によって中断されました。

管理者は、アプリケーションへのアクセス権が明示的に付与 (割り当てられている) 場合を除き、ユーザーをブロックするようにアプリケーション "エンタープライズアプリケーション名" を構成しました。サインインしているユーザー '{EmailHidden}' は、アクセス権を持つグループの直接メンバーではなく、管理者によって直接割り当てられたアクセス権も持っていないため、ブロックされます。このアプリケーションへのアクセス権を割り当てるには、管理者に問い合わせてください。

原因

対応するエンタープライズアプリケーションに "割り当てが必要" を設定した場合、Kerberos チケットを取得することはできません。ユーザーまたはグループがアプリケーションに割り当てられている場合でも、Microsoft Entra サインインログにエラーが表示されます。

ソリューション

Microsoft Entra アプリケーションに必要な割り当て要求元に返される Kerberos チケットに権利が設定されないため、ストレージアカウントに必要な割り当てを選択しないでください。詳細については、「エラー AADSTS50105 - サインインしているユーザーがアプリケーションのロールに割り当てられないを参照してください。

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

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

次の方法で共有

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

適用対象

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

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

ソリューション

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

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

解決策

原因

ソリューション

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

自己診断の手順

Microsoft Entra Kerberos で Azure ファイル共有をマウントできない

自己診断の手順

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

症状

解決策

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

症状

原因

ソリューション

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

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

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

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

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

解決策 1

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

ハイブリッド ユーザーに対して Microsoft Entra Kerberos 認証を有効にした場合に発生する可能性があるエラー

エラー - 管理者の同意の付与が無効になっています

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

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

原因 2: ストレージ アカウントのアプリケーションが既に存在する

エラー - Microsoft Entra ID でサービス プリンシパルのパスワードの有効期限が切れています

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

原因

ソリューション

エラー AADSTS50105

原因

ソリューション

関連項目

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

フィードバック

その他のリソース

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

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

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

ハイブリッドユーザーに対して Microsoft Entra Kerberos 認証を有効にした場合に発生する可能性があるエラー

原因 2: ストレージアカウントのアプリケーションが既に存在する

エラー - Microsoft Entra ID でサービスプリンシパルのパスワードの有効期限が切れています

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