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

[アーティクル]
04/10/2024

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

適用対象

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

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

AzFilesHybrid モジュールを実行しようとすると、次のエラーが発生する可能性があります。

必要な特権は、クライアントによって保持されません。

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

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

ソリューション

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

ファイル共有をマウントしようとすると、次のエラーが表示される場合があります。

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

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

注:

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

ソリューション

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

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

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

Azure FilesのMicrosoft Entra Domain Services認証を有効にする際のエラー AadDsTenantNotFound "テナント 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 ファイル共有をマウントできない

自己診断手順

まず、AD DS 認証Azure Files有効にする手順に従っていることを確認します。

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

3 つ目は、コマンドレットを Debug-AzStorageAccountAuth 実行して、ログオンしている AD ユーザーを使用して、AD 構成に関する基本的なチェックのセットを実行することです。このコマンドレットは、 AzFilesHybrid v0.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に同期されているかどうかを調べる場合は、入力パラメーターでと -Domain を指定-UserNameできます。特定の SID について、Microsoft Entra ユーザーが関連付けられているかどうかを確認します。
CheckAadUserHasSid: ログオンしている AD ユーザーがMicrosoft Entra IDに同期されていることを確認します。特定の AD ユーザーがMicrosoft Entra IDに同期されているかどうかを調べる場合は、入力パラメーターでと -Domain を指定-UserNameできます。特定のMicrosoft Entra ユーザーに対して、SID を確認します。このチェックを実行するには、パラメーターと、Microsoft Entra ユーザーのオブジェクト ID を指定-ObjectIdする必要があります。
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 v0.2.3 以降のバージョンでサポート)
CheckUserFileAccess: AD ID に、Azure Filesにアクセスするための適切なディレクトリ/ファイルアクセス許可 (Windows ACL) があるかどうかを確認します。そうでない場合は、ディレクトリ/ファイルレベルのアクセス許可を構成します。このチェックを実行するには、パラメーターと、アクセスをデバッグするマウントされたファイルのパスを指定-FilePathする必要があります。 (AzFilesHybrid v0.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

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

現象

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

[セキュリティ] タブの [ 編集] アクセス許可 をクリックすると、アクセス許可ウィザードは読み込まれません。
新しいユーザーまたはグループを選択しようとすると、ドメインの場所に適切な AD DS ドメインが表示されません。
複数の AD フォレストを使用していて、次のエラーメッセージが表示されます。"次のドメインで選択したオブジェクトを見つけるために必要な Active Directory ドメインコントローラーは使用できません。 Active Directory ドメインコントローラーが使用可能であることを確認し、オブジェクトをもう一度選択してください。

ソリューション

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

コマンドレットを実行するときのエラー Join-AzStorageAccountForAuth

エラー: "ディレクトリサービスで相対識別子を割り当てることができませんでした"

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

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

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

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

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 つから他方に切り替えることをお勧めします。ストレージアカウントが提供する共有キーには、ストレージアカウントキー (ストレージアカウントのデータへのスーパー管理者アクセスを提供する) と、ストレージアカウントと Windows Server Active Directory ドメインコントローラー間の共有シークレットとして機能する Kerberos キーの 2 種類がありますWindows Server Active Directoryシナリオ。

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

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

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

次のスクリプトは、ストレージアカウントの両方のキーをローテーションします。ローテーション中にキーを交換する場合は、このシナリオを処理するためにスクリプトに追加のロジックを指定する必要があります。と <storage-account> は、環境に適した値に置き換えてください<resource-group>。

$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 アクセス許可を設定する

Kerberos 認証Microsoft Entra有効にした後、構成を完了するには、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: アプリケーション管理ポリシーが資格情報の作成を妨げている

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

アプリケーション管理ポリシーのベータ/プレビュー機能を使用しています。
ユーザー (または管理者) は、次のようなテナント全体のポリシーを設定しています。
- 開始日がないか、2019 年 1 月 1 日より前に開始日が設定されている。
- カスタムパスワードを禁止するか、最大パスワードの有効期間を 365.5 日未満に設定する、サービスプリンシパルパスワードに制限を設定します。

現在、このエラーの回避策はありません。

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

また、手動の制限付きプレビュー手順で Kerberos 認証Microsoft Entra以前に有効にした場合にも、このエラーが発生する可能性があります。既存のアプリケーションを削除するには、顧客または 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 チケットをファイル共有に取得できなくなります。

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

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

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

エラー 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サインインログにエラーが表示されます。

ソリューション

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

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

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

Share via

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

適用対象

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

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

ソリューション

ソリューション

Azure FilesのMicrosoft Entra Domain Services認証を有効にする際のエラー AadDsTenantNotFound "テナント ID Microsoft Entra tenant-id を持つアクティブなテナントを見つけることができません"

原因

ソリューション

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

自己診断手順

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

現象

ソリューション

コマンドレットを実行するときのエラー Join-AzStorageAccountForAuth

エラー: "ディレクトリサービスで相対識別子を割り当てることができませんでした"

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

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

以前は所有者ロールまたは共同作成者ロールの割り当てを持つユーザー ID にストレージアカウントキーアクセス権が引き続き付与されている

解決策 1

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

ハイブリッドユーザーのMicrosoft Entra Kerberos 認証を有効にするときの潜在的なエラー

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

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

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

エラー - サービスプリンシパルのパスワードが Microsoft Entra ID で期限切れになりました

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

原因

ソリューション

エラー AADSTS50105

原因

ソリューション

関連項目

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

フィードバック

フィードバック

その他のリソース

Share via

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

適用対象

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

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

ソリューション

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

原因: 共有レベルのアクセス許可が正しくありません

ソリューション

Azure FilesのMicrosoft Entra Domain Services認証を有効にする際のエラー AadDsTenantNotFound "テナント ID Microsoft Entra tenant-id を持つアクティブなテナントを見つけることができません"

原因

ソリューション

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

自己診断手順

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

現象

ソリューション

コマンドレットを実行するときのエラー Join-AzStorageAccountForAuth

エラー: "ディレクトリ サービスで相対識別子を割り当てることができませんでした"

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

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

以前は所有者ロールまたは共同作成者ロールの割り当てを持つユーザー ID にストレージ アカウント キーアクセス権が引き続き付与されている

解決策 1

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

ハイブリッド ユーザーのMicrosoft Entra Kerberos 認証を有効にするときの潜在的なエラー

エラー - 管理者の同意を無効にする

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

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

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

エラー - サービス プリンシパルのパスワードが Microsoft Entra ID で期限切れになりました

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

原因

ソリューション

エラー AADSTS50105

原因

ソリューション

関連項目

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

フィードバック

フィードバック

その他のリソース

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

エラー: "ディレクトリサービスで相対識別子を割り当てることができませんでした"

以前は所有者ロールまたは共同作成者ロールの割り当てを持つユーザー ID にストレージアカウントキーアクセス権が引き続き付与されている

ハイブリッドユーザーのMicrosoft Entra Kerberos 認証を有効にするときの潜在的なエラー

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

エラー - サービスプリンシパルのパスワードが Microsoft Entra ID で期限切れになりました

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