次の方法で共有


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

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

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

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

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

コマンドレットは、次のチェックを順番に実行し、エラーのガイダンスを提供します。

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

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

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

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

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

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

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

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

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

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

ソリューション

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

関連項目

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

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