マネージド Microsoft AD のファイアウォールを構成する

Microsoft Active Directory のマネージド サービスによって運用されるドメイン コントローラは、LDAP、DNS、Kerberos、RPC などさまざまなサービスを公開します。ユースケースによっては、Google Cloud にデプロイされた仮想マシン(VM)とオンプレミスで実行されるマシンは、Active Directory を利用するためにこれらのサービスへのアクセスを必要とする場合があります。

ドメイン コントローラと VM の攻撃対象を減らすには、ファイアウォールを使用して、必須ではないネットワーク通信を禁止する必要があります。この記事では、他のネットワーク通信を禁止しながら、ファイアウォールを構成して一般的な Active Directory のユースケースに対応する方法について説明します。

ログオンと認証

ログオンと認証は同じ意味で使用されることがよくありますが、Windows セキュリティの文脈では異なる意味を持ちます。ログオン は、ユーザーがアクセスする先のシステムで発生するプロセスを表します。これに対して、認証は、ユーザーのアカウントが存在するコンピュータにより実行されます。

ローカル アカウントを使用してマシンにログオンすると、ログオンと認証の両方がターゲット マシンによって処理されます。Active Directory 環境では、ドメイン ユーザーを使用してログオンする方が一般的です。その場合、ログオンはターゲット マシンによって処理され、認証はドメイン コントローラによって実行されます。

認証には、クライアントは、Kerberos または NTLM のいずれかを使用できます。クライアントが認証を行うと、ターゲット マシンによりログオンが処理される必要があります。クライアントが要求したログオンタイプによっては、Kerberos、NTLM、LDAPRPCSMB などのプロトコルを使用してドメイン コントローラとの追加のやりとりが必要になる場合があります。

ログオンの認証と処理には異なるプロトコルが必要なため、適切なファイアウォール構成を識別する際にこの 2 つの概念を区別しておくと便利です。

一般的なユースケース

次のセクションでは、Managed Microsoft AD にアクセスするための一般的なユースケースについて説明し、各ユースケースで構成する必要があるファイアウォール ルールを示します。

Managed Microsoft AD をオンプレミスの Active Directory と統合する予定がない場合は、この記事の最初のセクション、VPC 内から Managed Microsoft AD にアクセスするのみを読む必要があります。Managed Microsoft AD とオンプレミスの Active Directory の間に信頼関係を作成する場合は、すべての記事をお読みください。

ファイアウォール ルールのログを使用して、追加のポートが必要かどうかを分析できます。暗黙の上り(内向き)拒否ルールではロギングが無効になっているため、最初にすべての上り(内向き)トラフィックを拒否する優先度の低いカスタムのファイアウォール ルールを作成する必要がありますが、ファイアウォール ログは有効になっています。このルールを設定すると、接続に失敗した場合にログエントリが Stackdriver に公開されます。ファイアウォール ルールにより大量のログが生成される可能性があるため、分析が完了したらファイアウォールのロギングを再度無効にすることを検討します。

VPC 内から Managed Microsoft AD にアクセスする

デフォルト ネットワークを使用して Managed Microsoft AD をデプロイする場合、VPC内の VM が Active Directory にアクセスできるようにするための追加の設定は必要ありません。

VPC 構成またはファイアウォール ルールをカスタマイズした場合は、ファイアウォール構成が Managed Microsoft AD との通信を許可していることを確認する必要があります。次のセクションでは、作成する必要があるファイアウォール ルールについて説明します。

ドメイン名の解決

VM は DNS 名を解決しようとする際、ドメイン コントローラに直接クエリを実行しません。代わりに、DNS クエリは、Compute Engine VM 用に構成されたデフォルトの DNS サーバーであるメタデータ サーバーに送信されます。メタデータ サーバーは、Managed Microsoft AD によって作成された Cloud DNS プライベート DNS 転送ゾーンにクエリを転送します。この転送ゾーンは、クエリを適切なドメイン コントローラに転送します。

このユースケースを有効にするためにファイアウォール ルールを構成する必要はありません。Cloud DNS への通信は VPC 内の VM に対して常に許可されており、Managed Microsoft AD はデフォルトで Cloud DNS Cloud DNS から転送された DNS リクエストを許可します

Kerberos を使用して VM に認証する

1 つの VM にログインしたユーザーが、別の VM によって提供されるサービスへのアクセスを必要とする場合があります。たとえば、ユーザーは RDP 接続を開こうとしたり、ファイル共有にアクセスしようとしたり、認証が必要な HTTP リソースにアクセスしようとしたりする可能性があります。

ユーザーがサーバーの VM への認証に Kerberos を使用できるようにするには、クライアントの VM が最初にいずれかの Managed Microsoft AD コントローラから適切な Kerberos チケットを取得する必要があります。

VM が Kerberos を使用して別の VM を認証できるようにするには、ファイアウォール ルールによって次の通信を許可する必要があります。

操作 開始 終了 プロトコル
1 許可 クライアント VM Managed Microsoft AD サブネット Kerberos(UDP/88、TCP/88)
LDAP(UDP/389、TCP/389)
2 許可 クライアント VM サーバー VM HTTP(TCP/80、TCP/443)や RDP(TCP/3389)など、VM へのアクセスに使用されるプロトコル
3 許可 サーバー VM Managed Microsoft AD サブネット ログオンの処理をご覧ください。

NTLM を使用した VM への認証

Windows はほとんどの場合 NTLM よりも Kerberos を優先しますが、クライアントは認証に NTLM を使用するようにフォールバックする必要がある場合があります。NTLM はパススルー認証に依存しているため、サーバーは Managed Microsoft AD ドメイン コントローラの 1 つと通信してユーザーを認証する必要があります。

VM が NTLM を使用して他の VM を認証できるようにするには、ファイアウォール ルールによって次の通信を許可する必要があります。

操作 開始 終了 プロトコル
1 許可 クライアント VM サーバー VM HTTP(TCP/80、TCP/443)や RDP(TCP/3389)など、VM へのアクセスに使用されるプロトコル
2 許可 クライアント VM Managed Microsoft AD サブネット ログオンの処理をご覧ください。

ドメイン参加とログオンの処理

マシンをドメイン メンバーとして操作し、ユーザーからのログオンを処理するには、マシンが Active Directory とやりとりできる必要があります。使用されるプロトコルの厳密なセットは、個々のお客様がリクエストするログオンの種類によって異なります。一般的なシナリオすべてをサポートするには、次のプロトコルの組み合わせを許可する必要があります。

操作 開始 終了 プロトコル
1 許可 サーバー VM Managed Microsoft AD サブネット Kerberos(UDP/88、TCP/88)
NTP(UDP/123)
RPC(TCP/135、TCP/49152-65535)
LDAP(UDP/389、TCP/389)
SMB(UDP/445、TCP/445)
LDAP GC(TCP/3268)

また、実際のユースケースによっては、次のプロトコルも許可できます。

操作 開始 終了 プロトコル
1 許可 サーバー VM Managed Microsoft AD サブネット Kerberos パスワードの変更(UDP/464、TCP/464)
セキュア LDAP(TCP/636、TCP/3269)

Managed Microsoft AD の管理

マネージド Microsoft AD を管理するには、ドメインに参加している VM を使用する必要があります。この VM で Active Directory 管理センターなどのツールを使用するには、マネージド Microsoft AD のドメイン コントローラによって公開される Active Directory ウェブサービスにも VM がアクセスできる必要があります。

操作 開始 終了 プロトコル
1 許可 管理 VM Managed Microsoft AD サブネット AD Web Services(TCP/9389)

Managed Microsoft AD をオンプレミスの Active Directory に接続する

オンプレミスの Active Directory に Managed Microsoft AD を接続するには、フォレスト間に信頼関係を作成する必要があります。さらに、Google Cloud とオンプレミス環境の間で DNS 名前解決を有効にする必要があります。

信頼の作成と検証

フォレストの信頼を作成および検証するには、オンプレミス フォレストの Managed Microsoft AD ドメイン コントローラとルートドメイン コントローラが双方向で通信できる必要があります。

信頼の作成と検証を有効にするには、オンプレミスのファイアウォールを構成して、次の特性に一致する上り(内向き)と下り(外向き)のトラフィックを許可します。

操作 開始 終了 プロトコル
1 許可 オンプレミス AD マネージド Microsoft AD DNS(UDP/53、TCP/53)
Kerberos(UDP/88、TCP/88)
Kerberos パスワード変更(UDP/464、TCP/464)
RPC(TCP/135、TCP/49152-65535)
LDAP(UDP/389、TCP/389)
SMB(UDP/445、TCP/445)
2 許可 マネージド Microsoft AD オンプレミス AD DNS(UDP/53、TCP/53)
Kerberos(UDP/88、TCP/88)
Kerberos パスワード変更(UDP/464、TCP/464)
RPC(TCP/135、TCP/49152-65535)
LDAP(UDP/389、TCP/389)
SMB(UDP/445、TCP/445)

Managed Microsoft AD は、これらの特性に一致するトラフィックを許可するように事前構成されているため、Google Cloud で追加のファイアウォール ルールを構成する必要はありません。

オンプレミスからの Google Cloud DNS 名を解決する

オンプレミス マシンが Managed Microsoft AD で DNS 名を解決できるようにする方法は 2 つあります。DNS 委任と条件付き DNS 転送です。

DNS 委任

Managed Microsoft AD で使用される DNS ドメインは、オンプレミスで使用される DNS ドメインのサブドメインになっていることがあります。たとえば、オンプレミスで example.com を使用しながら、Managed Microsoft AD に cloud.example.com を使用する場合です。オンプレミス クライアントが Google Cloud リソースの DNS 名を解決できるようにするために、DNS 委任を設定できます。

DNS 委任を使用する場合は、まず Google Cloud リソースの DNS 名を解決しようとすると、最初にオンプレミスの DNS サーバーが照会されます。次に、DNS サーバーはクライアントを Cloud DNS にリダイレクトし、Cloud DNS はそのリクエストを Managed Microsoft AD ドメイン コントローラの 1 つに転送します。

Cloud DNS をオンプレミスネットワークに公開するには、受信サーバー ポリシーの作成が必要です。これにより、VPC の一部である受信フォワーダ IP アドレスが作成されます。

オンプレミスからのフォワーダ アドレスを使用するには、以下の特性に一致する下りトラフィックを許可するようにオンプレミスのファイアウォールを構成します。

操作 開始 終了 プロトコル
1 許可 オンプレミス AD マネージド Microsoft AD DNS(UDP/53、TCP/53)
Kerberos(UDP/88、TCP/88)
Kerberos パスワード変更(UDP/464、TCP/464)
RPC(TCP/135、TCP/49152-65535)
LDAP(UDP/389、TCP/389)
SMB(UDP/445、TCP/445)
2 許可 マネージド Microsoft AD オンプレミス AD DNS(UDP/53、TCP/53)
Kerberos(UDP/88、TCP/88)
Kerberos パスワード変更(UDP/464、TCP/464)
RPC(TCP/135、TCP/49152-65535)
LDAP(UDP/389、TCP/389)
SMB(UDP/445、TCP/445)

条件付きの DNS 転送

Managed Microsoft AD が使用する DNS ドメインは、オンプレミスで使用される DNS ドメインのサブドメインではない可能性があります。たとえば、オンプレミスで corp.example.local を使用しながら Managed Microsoft AD に cloud.example.com を使用する場合です。

DNS ドメインが無関係なシナリオでは、オンプレミスの Active Directory DNS で条件付き DNS 転送を設定できます。マネージド Microsoft AD が使用する DNS 名に一致するすべてのクエリは、Cloud DNS に転送されます。

条件付き DNS 転送を使用するには、まず受信 DNS 転送を有効にする DNS ポリシーを設定する必要があります。設定によって取得したオンプレミスからのフォワーダ アドレスを使用するには、以下の特性に一致する下りトラフィックを許可するようにオンプレミスのファイアウォールを構成します。

操作 開始 終了 プロトコル
1 許可 オンプレミス AD DNS 転送 IP アドレス DNS(UDP/53、TCP/53)

Google Cloud 側で、これらの基準に一致する上りトラフィックを許可するファイアウォール ルールを作成します。

DNS Forwarder から Cloud DNS への通信を有効にするファイアウォール ルールを構成する必要はありません(2)。

Google Cloud からのオンプレミス DNS 名を解決する

Managed Microsoft AD は、条件付き DNS 転送を使用して、オンプレミス フォレストの DNS 名を解決します。Google Cloud で実行中のクライアントが、オンプレミスの Active Directory によって管理されている DNS 名を解決できるようにするために、クエリをオンプレミスのドメイン コントローラに転送する Cloud DNS DNS にプライベート転送ゾーンを作成できます。

Google Cloud からのオンプレミス DNS 名の解決を有効にするには、次の表に従って入力トラフィックを許可するようにオンプレミスのファイアウォールを構成します。

アクション 開始 終了 プロトコル
1 許可 マネージド Microsoft AD オンプレミス AD DNS(UDP/53、TCP/53)
2 許可 Cloud DNS(35.199.192.0/19) オンプレミス AD DNS(UDP/53、TCP/53)

Google Cloud では、デフォルトで対応する下り(外向き)トラフィックが許可されます。

オンプレミスからの Managed Microsoft AD リソースへのアクセス

Managed Microsoft AD のフォレストがオンプレミス フォレストを信頼するように設定されている場合、オンプレミスのユーザーとマシンが管理された Microsoft AD フォレスト内のリソースにアクセスできるようにする必要があります。

Kerberos を使用してオンプレミスから VM に認証する

オンプレミス マシンにログインしたユーザーは、Google Cloud で実行され、Managed Microsoft AD フォレストのメンバーである VM によって提供されるサービスへのアクセスを必要とする場合があります。たとえば、ユーザーは RDP 接続を開こうとしたり、ファイル共有にアクセスしようとしたり、認証が必要な HTTP リソースにアクセスしようとしたりする可能性があります。

ユーザーがサーバーの VM への認証に Kerberos を使用できるようにするには、クライアント マシンで適切な Kerberos チケットを取得する必要があります。これには、オンプレミス ドメイン コントローラの 1 つと、Managed Microsoft AD ドメイン コントローラの 1 つとの通信が必要です。

オンプレミス VM が Kerberos を使用して認証できるようにするには、以下の下りトラフィックを許可するようにオンプレミスのファイアウォールを構成します。

操作 開始 終了 プロトコル
1 許可 クライアント マシン(オンプレミス) Managed Microsoft AD サブネット LDAP(UDP/389、TCP/389)
Kerberos(UDP/88、TCP/88)
2 許可 クライアント マシン(オンプレミス) サーバー VM(Google Cloud) HTTP(TCP/80、TCP/443)や RDP(TCP/3389)などのアプリケーションで使用されるプロトコル
3 許可 サーバー VM Managed Microsoft AD サブネット ログオンの処理をご覧ください。

Google Cloud 側で、(1)と(2)の上り(内向き)トラフィックを許可するファイアウォール ルールを作成します。Managed Microsoft AD(3)への下り(外向き)トラフィックは、デフォルトで許可されます。

NTLM を使用してオンプレミスから VM に認証する

NTLM を使用して、オンプレミスの Active Directory フォレストから、Managed Microsoft AD フォレストに参加しているサーバー VM に対してユーザーを認証する場合、Managed Microsoft AD ドメイン コントローラは、オンプレミス ドメイン コントローラと通信する必要があります。

オンプレミス VM が NTLM を使用して認証できるようにするには、以下に従って入力トラフィックと出力トラフィックを許可するようにオンプレミスのファイアウォールを構成します。

操作 開始 終了 プロトコル
1 許可 クライアント マシン(オンプレミス) サーバー VM(Google Cloud) HTTP(TCP/80、TCP/443)や RDP(TCP/3389)などのアプリケーションで使用されるプロトコル
2 許可 サーバー VM Managed Microsoft AD サブネット ログオンの処理をご覧ください。
3 許可 Managed Microsoft AD サブネット オンプレミス AD LDAP(UDP/389、TCP/389)
SMB(UDP/445、TCP/445)

Google Cloud 側で、(1)の上り(内向き)トラフィックを許可するファイアウォール ルールを作成します。(2)と(3)の下り(外向き)トラフィックは、デフォルトで許可されます。

オンプレミス フォレストのユーザーのログオンの処理

オンプレミス フォレストのユーザーのログオンを処理するには、VM がオンプレミスの Active Directory とやりとりできる必要があります。使用されるプロトコルの厳密なセットは、クライアントがリクエストしたログオンタイプによって異なります。一般的なシナリオをすべてサポートするには、以下の特性に一致する上り(内向き)トラフィックを許可するようにオンプレミス ファイアウォールを構成します。

操作 開始 終了 プロトコル
1 許可 サーバー VM(Google Cloud) オンプレミス AD サブネット Kerberos(UDP/88、TCP/88)
NTP(UDP/123)
RPC(TCP/135、TCP/49152-65535)
LDAP(UDP/389、TCP/389)
SMB(UDP/445、TCP/445)
LDAP GC(TCP/3268)

実際のユースケースによっては、次のプロトコルも許可できます。

  • Kerberos パスワード変更(UDP/464、TCP/464)
  • セキュア LDAP(TCP/636、TCP/3269)

Managed Microsoft AD 側では、対応する下りトラフィックがデフォルトで許可されています。

管理 VM では、オンプレミス フォレストのユーザーによるログオンを許可する予定がない場合があります。ただし、管理 VM で行う必要があると考えられるアクティビティの 1 つは、グループ メンバーシップの管理です。オブジェクト選択ツールを使用してオンプレミス フォレストからユーザーまたはグループを参照している場合、オブジェクト選択ツールは、オンプレミスのドメイン コントローラへのアクセスを必要とします。これを行うには、管理 VM はオンプレミスの Active Directory ドメイン コントローラに対して、オンプレミス フォレストのユーザーによるログオンを処理する場合と同じアクセス権を必要とします。

オンプレミスの Active Directory リソースに Google Cloud からアクセスする

オンプレミス フォレストが Managed Microsoft AD フォレストを信頼するように設定されている場合、Managed Microsoft AD フォレストのユーザーがオンプレミス リソースにアクセスできるようにする必要があります。

Kerberos を使用してオンプレミス VM に認証する

Google Cloud で実行中の VM にログインし、Managed Microsoft AD フォレストのメンバーであるユーザーは、オンプレミス フォレストのメンバーであるオンプレミス マシンによって提供されるサービスへのアクセスを必要とする場合があります。たとえば、ユーザーは RDP 接続を開こうとしたり、ファイル共有にアクセスしようとしたり、認証が必要な HTTP リソースにアクセスしようとしたりする可能性があります。

ユーザーがオンプレミス マシンへの認証に Kerberos を使用できるようにするには、VM で適切な Kerberos チケットを取得する必要があります。これには、最初に Managed Microsoft AD コントローラの 1 つと通信してから、オンプレミス ドメイン コントローラと通信する必要があります。

オンプレミス VM が Kerberos を使用して認証できるようにするには、以下の特性に一致する上り(内向き)トラフィックを許可するようにオンプレミス ファイアウォールを構成します。

操作 開始 終了 プロトコル
1 許可 クライアント VM(Google Cloud) Managed Microsoft AD サブネット Kerberos(UDP/88、TCP/88)
LDAP(UDP/389、TCP/389)
ログオン処理によって暗黙に定義される
2 許可 クライアント VM(Google Cloud) オンプレミス ADKerberos(UDP/88、TCP/88)
LDAP(UDP/389、TCP/389)
3 許可 クライアント VM(Google Cloud) サーバーマシン(オンプレミス) HTTP(TCP/80、TCP/443)や RDP(TCP/3389)などのアプリケーションで使用されるプロトコル

Google Cloud 側では、対応する下り(外向き)トラフィックがデフォルトで許可されます。

NTLM を使用してオンプレミス VM に認証する

NTLM を使用して、Managed Microsoft AD フォレストから、オンプレミス フォレストに参加しているサーバーマシンに対してユーザーを認証する場合、オンプレミス ドメイン コントローラは、Managed Microsoft AD ドメイン コントローラと通信できる必要があります。

オンプレミス VM が Kerberos を使用して認証できるようにするには、以下の特性に一致する入力トラフィックと出力トラフィックを許可するようにオンプレミスのファイアウォールを構成します。

操作 開始 終了 プロトコル
1 許可 クライアント VM(Google Cloud) サーバーマシン(オンプレミス) HTTP(TCP/80、TCP/443)や RDP(TCP/3389)などのアプリケーションで使用されるプロトコル
2 許可 オンプレミス AD Managed Microsoft AD サブネット LDAP(UDP/389、TCP/389)
SMB(UDP/445、TCP/445)

Google Cloud 側では、(1)の下り(外向き)トラフィックと(2)の上り(内向き)トラフィックがデフォルトで許可されます。

Managed Microsoft AD フォレストのユーザー ログオンの処理

マネージド Microsoft AD フォレストのユーザーのログオンを処理するには、オンプレミスで実行されているマシンがマネージド Microsoft AD ドメイン コントローラと通信できる必要があります。使用されるプロトコルの厳密な組み合わせは、クライアントがリクエストしたログオンタイプによって異なります。一般的なシナリオすべてをサポートするには、次のプロトコルの組み合わせを許可する必要があります。

操作 開始 終了 プロトコル
1 許可 サーバーマシン(オンプレミス) Managed Microsoft AD サブネット Kerberos(UDP/88、TCP/88)
NTP(UDP/123)
RPC(TCP/135、TCP/49152-65535)
LDAP(UDP/389、TCP/389)
SMB(UDP/445、TCP/445)
LDAP GC(TCP/3268)

実際のユースケースによっては、次のプロトコルも許可できます。

  • Kerberos パスワード変更(UDP/464、TCP/464)
  • セキュア LDAP(TCP/636、TCP/3269)

オンプレミスのファイアウォールで、これらの特性に一致する下り(外向き)トラフィックが許可されていることを確認してください。Managed Microsoft AD への対応する上り(内向き)トラフィックを有効にするために、Google Cloud でファイアウォール ルールを構成する必要はありません。

管理マシンでは、Managed Microsoft AD フォレストのユーザーからのログオンを許可する予定がない場合があります。管理マシンで実行する必要があると思われるアクティビティの 1 つは、グループ メンバーシップの管理です。オブジェクト ピッカーを使用して Managed Microsoft AD フォレストからユーザーまたはグループを参照する場合、オブジェクト ピッカーは Managed Microsoft AD ドメイン コントローラへのアクセスを必要とします。これが機能するためには、管理マシンは、Managed Microsoft AD フォレストのユーザーのログオンを処理する場合と同じように、Managed Microsoft AD ドメイン コントローラにアクセスする必要があります。