複数の Active Directory フォレストで Azure Files を使用する

多くの組織では、複数のオンプレミスの Active Directory Domain Services (AD DS) フォレストを持つ環境で SMB Azure ファイル共有用に ID ベースの認証を使用したいと考えています。 これは、特に合併と買収後の一般的な IT シナリオであり、こうした場合、買収された会社の AD フォレストが親会社の AD フォレストから分離されています。 この記事では、フォレストの信頼関係のしくみについて説明し、複数フォレストのセットアップと検証の手順を紹介します。

適用対象

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

前提条件

• それぞれ異なるフォレストを持ち、異なる仮想ネットワーク (VNET) 上にある 2 つの AD DS ドメイン コントローラー
• 管理タスクを実行するための十分な AD アクセス許可 (ドメイン管理者など)
• Azure RBAC を使用するには、1 つの Microsoft Entra Connect Sync サーバーから両方のフォレストへのアクセスを可能にする必要があります

フォレストの信頼関係のしくみ

Azure Files オンプレミスの AD DS 認証は、ストレージ アカウントが登録されているドメイン サービスの AD フォレストに対してのみサポートされます。 既定では、単一のフォレストからのみ、AD DS 資格情報を使用して Azure ファイル共有にアクセスできます。 別のフォレストから Azure ファイル共有にアクセスする必要がある場合は、フォレストの信頼を構成する必要があります。

フォレストの信頼は 2 つの AD フォレスト間の推移的な信頼であり、あるフォレストの任意のドメインのユーザーを、もう一方のフォレストの任意のドメインで認証できます。

複数フォレストのセットアップ

複数フォレストのセットアップを構成するには、次の手順を実行します。

• ドメイン情報とドメイン間の VNET 接続を収集する
• フォレストの信頼を確立して構成する
• ID ベースの認証とハイブリッド ユーザー アカウントを設定する

ドメイン情報を収集する

この演習には、2 つのオンプレミスの AD DS ドメイン コントローラーがありますが、2 つの異なるフォレストを持っていて、異なる VNET 内にあります。

信頼を確立して構成する

フォレスト 1 のクライアントがフォレスト 2 の Azure Files ドメイン リソースにアクセスできるようにするには、2 つのフォレスト間に信頼を確立する必要があります。 信頼を確立するには、次の手順に従います。

1. フォレスト 2 にドメイン参加済みのマシンにログオンし、[Active Directory のドメインと信頼] コンソールを開きます。

2. ローカル ドメイン onpremad2.com を右クリックし、[Trusts] (信頼) タブを選択します。

3. [New Trusts] (新しい信頼) を選択して、[New Trust Wizard] (新しい信頼ウィザード) を起動します。

4. 信頼を構築する相手のドメイン名 (この例では onpremad1.com) を指定し、[次へ] を選択します。

5. [信頼の種類] で、[Forest trust] (フォレストの信頼) を選択し、[次へ] を選択します。

6. [Direction of Trust] (信頼の方向) で [双方向] を選択し、[次へ] を選択します。

   

7. [Sides of Trust] (信頼のサイド) で、[This domain only] (このドメインのみ) を選択し、[次へ] を選択します。

8. 指定したフォレスト内のユーザーを、ローカル フォレスト内のすべてのリソースを使用できる (フォレスト全体の認証)、または選択したリソースのみを使用できる (選択的認証) ように認証できます。 [Outgoing Trust Authentication Level] (出力方向の信頼認証レベル) で、[Forest-wide authentication] (フォレスト全体の認証) を選択します。これは、両方のフォレストが同じ組織に属している場合の推奨オプションです。 [次へ] を選択します。

9. 信頼のパスワードを入力し、[次へ] を選択します。 指定したドメインでこの信頼関係を作成する場合は、同じパスワードを使用する必要があります。

   

10. 信頼関係が正常に作成されたことを示すメッセージが表示されます。 信頼を構成するには、[次へ] を選択します。

11. 出力方向の信頼を確認し、[次へ] を選択します。

12. もう一方のドメインの管理者特権を持つユーザーのユーザー名とパスワードを入力します。

認証に合格すると、信頼が確立され、指定したドメイン onpremad1.com が [Trusts] (信頼) タブの一覧に表示されます。

ID ベースの認証とハイブリッド ユーザー アカウントを設定する

信頼を確立させた後、以下の手順に従って、各ドメインのストレージ アカウントと SMB ファイル共有の作成、それらのストレージ アカウントに対する AD DS 認証の有効化、Microsoft Entra ID に同期されるハイブリッド ユーザー アカウントの作成を行います。

1. Azure portal にログインし、2 つのストレージ アカウント (onprem1sa と onprem2sa など) を作成します。 最適なパフォーマンスが得られるように、共有にアクセスする予定のクライアントと同じリージョンに、ストレージ アカウントをデプロイすることをお勧めします。

   注意

   2 つ目のストレージ アカウントを作成する必要はありません。 これらの手順は、異なるフォレストに属するストレージ アカウントにアクセスする方法の例を示すためのものです。 ストレージ アカウントが 1 つしかない場合は、2 つ目のストレージ アカウントのセットアップ手順を無視できます。

2. 各ストレージ アカウント上で SMB Azure ファイル共有を作成し、共有レベルのアクセス許可を割り当てます。

3. Microsoft Entra Connect Sync アプリケーションを使用して、オンプレミスの AD を Microsoft Entra ID に同期します。

4. フォレスト 1 の Azure VM をオンプレミスの AD DS にドメイン参加させます。 ドメインに参加させる方法については、「コンピューターをドメインに参加させる」を参照してください。

5. フォレスト 1 に関連するストレージ アカウント (onprem1sa など) で AD DS 認証を有効にします。 これにより、オンプレミスの AD に、Azure ストレージ アカウントを表す onprem1sa という名前のコンピューター アカウントが作成され、このストレージ アカウントが onpremad1.com ドメインに参加します。 ストレージ アカウントを表す AD ID が作成されたことを確認するには、[Active Directory Users and Computers] (Active Directory ユーザーとコンピューター) に onpremad1.com があるか調べます。 この例では、onprem1sa というコンピューター アカウントが表示されます。

6. [Active Directory] > [onpremad1.com] に移動してユーザー アカウントを作成します。 [ユーザー] を右クリックし、[作成] を選択してユーザー名 (「onprem1user」 など) を入力し、[パスワードを無期限にする] ボックス (オプション) をオンにします。

7. オプション: Azure RBAC で共有レベルのアクセス許可を割り当てる場合は、該当するユーザーを Microsoft Entra Connect で Microsoft Entra ID に同期する必要があります。 通常、Microsoft Entra Connect Sync は 30 分ごとに更新されます。 ただし、管理者特権の PowerShell セッションを開いて Start-ADSyncSyncCycle -PolicyType Delta を実行すると、強制的に即時同期できます。 場合によっては、最初に Import-Module ADSync を実行して ADSync モジュールをインストールする必要があります。 そのユーザーが Microsoft Entra ID に同期されていることを確認するには、マルチ フォレスト テナントに関連付けられている Azure サブスクリプションを使用して Azure portal にサインインし、[Microsoft Entra ID] を選択します。 [管理] > [ユーザー] を選択し、追加したユーザー (onprem1user など) を検索します。 [オンプレミスの同期が有効] は [はい] になっている必要があります。

8. Azure RBAC ロールまたは既定の共有レベルのアクセス許可を使用して、共有レベルのアクセス許可を設定します。

   • ユーザーが Microsoft Entra ID に同期されている場合は、ストレージ アカウント onprem1sa のユーザー onprem1user に共有レベルのアクセス許可 (Azure RBAC ロール) を付与することで、そのユーザーにファイル共有のマウントを許可できます。 これを行うには、onprem1sa 内に作成したファイル共有に移動し、特定の Microsoft Entra ユーザーまたはグループに共有レベルのアクセス許可を割り当てる方法のページで説明されている手順に従います。
   • これ以外の場合は、すべての認証済み ID に適用される既定の共有レベルのアクセス許可を使用できます。

Forest2 ドメイン onpremad2.com (ストレージ アカウント onprem2sa/ユーザー onprem2user) に対して手順 4 から 8 を繰り返します。 フォレストが 2 つより多い場合は、フォレストごとに手順を繰り返します。

ディレクトリとファイル レベルのアクセス許可を構成する (省略可能)

マルチフォレスト環境では、icacls コマンド ライン ユーティリティを使用して、両方のフォレストのユーザーのディレクトリとファイル レベルのアクセス許可を構成します。 「icacls で Windows ACL を構成する」を参照してください。

「アクセスが拒否されました」というエラーで icacls が失敗した場合は、次の手順に従って、ストレージ アカウント キーを使用して共有をマウントしてディレクトリとファイル レベルのアクセス許可を構成します。

1. 既存の共有マウントを削除します: net use * /delete /y

2. ストレージ アカウント キーを使用して共有を再マウントします。

   net use <driveletter> \\storageaccount.file.core.windows.net\sharename /user:AZURE\<storageaccountname> <storageaccountkey>
   

3. Forest2 のユーザーに対して、Forest1 のクライアントから Forest1 に参加しているストレージ アカウントに対する icacls アクセス許可を設定 します。

ドメイン サフィックスを構成する

上記で説明したように、Azure Files の AD DS への登録方法は通常のファイル サーバーとほとんど同じです。この場合、認証用に AD DS 内のストレージ アカウントを表す ID (既定ではコンピューター アカウントですが、サービス ログオン アカウントの場合もあります) が作成されます。 唯一の違いは、ストレージ アカウントの登録済みサービス プリンシパル名 (SPN) が、ドメイン サフィックスと一致しない file.core.windows.net で終わることです。 ドメイン サフィックスが異なるため、複数フォレスト認証を有効にするようにサフィックスのルーティング ポリシーを構成する必要があります。

サフィックス file.core.windows.net は特定の AD ドメインのサフィックスではなく、すべての Azure Files リソースのサフィックスであるため、クライアントのドメイン コントローラーでは要求の転送先のドメインがわからないので、リソースがそれ自身のドメインに見つからないすべての要求を失敗とします。

たとえば、フォレスト 1 のドメインのユーザーが、フォレスト 2 のドメインに対して登録されたストレージ アカウントを使用してファイル共有にアクセスしようとする場合、これは自動的に行われません。ストレージ アカウントのサービス プリンシパルに、フォレスト 1 内のドメインのサフィックスと一致するサフィックスがないためです。

ドメイン サフィックスは、次のいずれかの方法を使って構成できます。

• ストレージ アカウントのサフィックスを変更し、CNAME レコードを追加します (推奨 - 2 つ以上のフォレストがある場合に機能します)
• カスタム名のサフィックスとルーティング規則を追加します (2 つより多くのフォレストがある場合は機能しません)

ストレージ アカウント名のサフィックスを変更して CNAME レコードを追加する

ドメイン ルーティングの問題を解決するには、Azure ファイル共有に関連するストレージ アカウント名のサフィックスを変更し、その新しいサフィックスをストレージ アカウントのエンドポイントにルーティングする CNAME レコードを追加します。 この構成では、ドメイン参加済みのクライアントは、どのフォレストに参加しているストレージ アカウントにもアクセスできます。 これは、2 つ以上のフォレストを持つ環境で機能します。

この例では、ドメイン onpremad1.com と onpremad2.com があり、それぞれのドメインで SMB Azure ファイル共有に関連するストレージ アカウントとして onprem1sa と onprem2sa があります。 これらのドメインは、相互のフォレスト内のリソースにアクセスするように相互に信頼している、別々のフォレスト内にあります。 各フォレストに属するクライアントから両方のストレージ アカウントにアクセスできるようにする必要があります。 これを行うには、ストレージ アカウントの SPN サフィックスを変更する必要があります。

onprem1sa.onpremad1.com -> onprem1sa.file.core.windows.net

onprem2sa.onpremad2.com -> onprem2sa.file.core.windows.net

これにより、クライアントは net use \\onprem1sa.onpremad1.com を使用して共有をマウントできます。onpremad1 または onpremad2 のクライアントが、そのストレージ アカウントに適したリソースを見つけるために onpremad1.com を検索すべきことを認識するからです。

この方法を使用するには、次の手順を実行します。

1. 前のセクションで説明したように、2 つのフォレスト間に信頼を確立していることを確認し、ID ベースの認証とハイブリッド ユーザー アカウントを設定します。

2. setspn ツールを使用して、ストレージ アカウントの SPN を変更します。 <DomainDnsRoot> を見つけるには、Active Directory PowerShell コマンド (Get-AdDomain).DnsRoot を実行します。

   setspn -s cifs/<storage-account-name>.<DomainDnsRoot> <storage-account-name>
   

3. Active Directory DNS マネージャーを使用して CNAME エントリを追加し、ストレージ アカウントが参加しているドメイン内のストレージ アカウントごとに、次の手順を実行します。 プライベート エンドポイントを使用している場合は、プライベート エンドポイント名にマップする CNAME エントリを追加します。

   1. Active Directory DNS マネージャーを開きます。

   2. ご自分のドメイン (たとえば、onpremad1.com) に移動します。

   3. [Forward Lookup Zones] (前方参照ゾーン) に移動します。

   4. ドメインの名前が付いたノード (onpremad1.com など) を選択し、[New Alias (CNAME)] (新しい別名 (CNAME)) を右クリックします。

   5. 別名には、ストレージ アカウント名を入力します。

   6. 完全修飾ドメイン名 (FQDN) には、「<storage-account-name>.<domain-name>」 (例: mystorageaccount.onpremad1.com) を入力します。

   7. ターゲット ホスト FQDN には、「<storage-account-name>.file.core.windows.net」と入力します

   8. [OK] を選択します。

      

これで、ドメイン参加済みのクライアントから、どのフォレストに参加しているストレージ アカウントでも使用できます。

カスタム名のサフィックスとルーティング規則を追加する

前のセクションで説明したように、既にストレージ アカウント名のサフィックスを変更していて、CNAME レコードを追加している場合は、この手順をスキップできます。 DNS の変更やストレージ アカウント名のサフィックスの変更を行わない場合は、file.core.windows.net のカスタム サフィックスに対して、フォレスト 1 からフォレスト 2 へのサフィックスのルーティング規則を構成できます。

まず、フォレスト 2 で新しいカスタム サフィックスを追加します。 構成を変更するための適切な管理アクセス許可があること、および 2 つのフォレスト間の信頼を確立していることを確認します。 その後、次の手順に従います。

1. フォレスト 2 のドメインに参加しているマシンまたは VM にログオンします。
2. [Active Directory のドメインと信頼] コンソールを開きます。
3. [Active Directory ドメインと信頼関係] を右クリックします
4. [プロパティ] を選択し、[追加] を選択します。
5. UPN サフィックスとして "file.core.windows.net" を追加します。
6. [適用]、[OK] の順に選択してウィザードを閉じます。

次に、フォレスト 1 にサフィックスのルーティング規則を追加して、フォレスト 2 にリダイレクトされるようにします。

1. フォレスト 1 のドメインに参加しているマシンまたは VM にログオンします。
2. [Active Directory のドメインと信頼] コンソールを開きます。
3. ファイル共有にアクセスするドメインを右クリックし、[Trusts] (信頼) タブを選択し、出力方向の信頼からフォレスト 2 のドメインを選択します。
4. [プロパティ]、[Name Suffix Routing] (名前サフィックスのルーティング) の順に選択します。
5. "*.file.core.windows.net" サフィックスが表示されるかどうかを確認します。 そうでない場合は、[最新の情報に更新] を選択します。
6. "*.file.core.windows.net" を選択し、[有効] と [適用] をクリックします。

信頼が機能していることを検証する

次に、klist コマンドを実行して Kerberos 資格情報キャッシュとキー テーブルの内容を表示することで、信頼が機能しているか検証します。

1. フォレスト 1 のドメインに参加しているマシンまたは VM にログオンし、Windows コマンド プロンプトを開きます。
2. フォレスト 2 のドメイン参加済みのストレージ アカウントに対する資格情報キャッシュを表示するには、次のいずれかのコマンドを実行します。
   • ストレージ アカウント名のサフィックスを変更して CNAME レコードを追加する方法を使用した場合は、klist get cifs/onprem2sa.onpremad2.com を実行します。
   • カスタム名のサフィックスとルーティング規則を追加する方法を使用した場合は、klist get cifs/onprem2sa.file.core.windows.net を実行します。
3. 次のような出力が表示されます。 klist の出力は、ドメイン サフィックスの構成にどの方法を使用したかによって若干異なります。

Client: onprem1user @ ONPREMAD1.COM
Server: cifs/onprem2sa.file.core.windows.net @ ONPREMAD2.COM
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
Ticket Flags 0x40a10000 -> forwardable renewable pre_authent name_canonicalize
Start Time: 11/22/2022 18:45:02 (local)
End Time: 11/23/2022 4:45:02 (local)
Renew Time: 11/29/2022 18:45:02 (local)
Session Key Type: AES-256-CTS-HMAC-SHA1-96
Cache Flags: 0x200 -> DISABLE-TGT-DELEGATION
Kdc Called: onprem2.onpremad2.com

4. フォレスト 2 のドメインに参加しているマシンまたは VM にログオンし、Windows コマンド プロンプトを開きます。
5. フォレスト 1 のドメイン参加済みのストレージ アカウントに対する資格情報キャッシュを表示するには、次のいずれかのコマンドを実行します。
   • ストレージ アカウント名のサフィックスを変更して CNAME レコードを追加する方法を使用した場合は、klist get cifs/onprem1sa.onpremad1.com を実行します。
   • カスタム名のサフィックスとルーティング規則を追加する方法を使用した場合は、klist get cifs/onprem1sa.file.core.windows.net を実行します。
6. 次のような出力が表示されます。 klist の出力は、ドメイン サフィックスの構成にどの方法を使用したかによって若干異なります。

Client: onprem2user @ ONPREMAD2.COM
Server: krbtgt/ONPREMAD2.COM @ ONPREMAD2.COM
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
Ticket Flags 0x40e10000 -> forwardable renewable pre_authent name_canonicalize
Start Time: 11/22/2022 18:46:35 (local)
End Time: 11/23/2022 4:46:35 (local)
Renew Time: 11/29/2022 18:46:35 (local)
Session Key Type: AES-256-CTS-HMAC-SHA1-96
Cache Flags: 0x1 -> PRIMARY
Kdc Called: onprem2

Client: onprem2user @ ONPREMAD2.COM    
Server: cifs/onprem1sa.file.core.windows.net @ ONPREMAD1.COM
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
Ticket Flags 0x40a10000 -> forwardable renewable pre_authent name_canonicalize
Start Time: 11/22/2022 18:46:35 (local)
End Time: 11/23/2022 4:46:35 (local)
Renew Time: 11/29/2022 18:46:35 (local)
Session Key Type: AES-256-CTS-HMAC-SHA1-96
Cache Flags: 0x200 -> DISABLE-TGT-DELEGATION
Kdc Called: onpremad1.onpremad1.com

上記の出力が表示されたら、それで完了です。 そうでない場合は、これらの手順に従って、複数フォレスト認証が機能するように別の UPN サフィックスを指定します。

まず、フォレスト 1 で新しいカスタム サフィックスを追加します。

1. フォレスト 1 のドメインに参加しているマシンまたは VM にログオンします。
2. [Active Directory のドメインと信頼] コンソールを開きます。
3. [Active Directory ドメインと信頼関係] を右クリックします
4. [プロパティ] を選択し、[追加] を選択します。
5. "onprem1sa.file.core.windows.net" などの別の UPN サフィックスを追加します。
6. [適用]、[OK] の順に選択してウィザードを閉じます。

次に、フォレスト 2 にサフィックスのルーティング規則を追加します。

1. フォレスト 2 のドメインに参加しているマシンまたは VM にログオンします。
2. [Active Directory のドメインと信頼] コンソールを開きます。
3. ファイル共有にアクセスするドメインを右クリックし、[Trusts] (信頼) タブを選択し、サフィックスのルーティング名が追加されたフォレスト 2 の出力方向の信頼を選択します。
4. [プロパティ]、[Name Suffix Routing] (名前サフィックスのルーティング) の順に選択します。
5. "onprem1sa.file.core.windows.net" サフィックスが表示されるかどうかを確認します。 そうでない場合は、[最新の情報に更新] を選択します。
6. "onprem1sa.file.core.windows.net" を選択し、[有効] と [適用] を選択します。

次のステップ

詳細については、次のリソースを参照してください。

• Azure Files ID ベース認証サポートの概要 (SMB のみ)
• Azure Files に関する FAQ