Managed Service for Microsoft Active Directoryによって運営されるドメインコントローラは、LDAP、DNS、Kerberos、RPCなどの多数のサービスを公開します。 使用例によっては、Google Cloudにデプロイされた仮想マシン(Vm)や社内で実行されているマシンが、ActiveDirectoryを利用するためにこれらのサービスにアクセスする必要が
ドメインコントローラとVmの攻撃対象を減らすには、厳密には必要ではないネットワーク通信を禁止するためにfirewallsを使用する必要があります。この資料では、他のネットワーク通信を禁止しながら、一般的なActiveDirectoryのユースケースに対応するようにファイアウォールを構成する方法について説明します。
ログオンと認証
ログオンと認証という用語はしばしば同じ意味で使用されますが、Windowsセキュリティの文脈では異なる意味を持ちます。 Logondescribesユーザーがアクセス権を取得しているシステム上で発生するプロセスto.In 対照的に、認証は、user’saccountが存在するコンピュータによって実行されます。
ローカルアカウントを使用してマシンにログオンすると、ログオンと認証の両方がターゲットマシンによって処理されます。 アクティブなDirectoryenvironmentでは、ドメインユーザーを使用してログオンする方が一般的です。 その場合、ログオンはターゲットマシンによって処理され、認証はドメインコントローラによって実行されます。
認証には、クライアントはどちらかを使用できます。クライアントが認証されると、ターゲットマシンはログオンを処理する必要があります。クライアントが要求したログオンタイプによっては、Kerberos、NTLM、LDAP、RPC、SMBなどのプロトコルを使用するドメインコントローラとのadditionalinteractionが必要な場合があります。
ログオンの認証と処理には異なるプロトコルが必要なため、rightfirewall構成を識別する際には、二つの概念を区別するのに役立ちます。
一般的なユースケース
次のセクションでは、accessingManaged Microsoft ADの一般的なユースケースについて説明し、各ユースケースを構成するために必要なファイアウォールルール
managed Microsoft ADをon-premisesActiveディレクトリと統合する予定がない場合は、この記事の最初のセクション”VPC内からManaged Microsoft ADにアクセスする”を読むだけで済みます。 Managed Microsoft ADとオンプレミスのActiveDirectoryとの間の信頼関係を作成する場合は、この記事全体が適用されます。
追加のポートが必要な場合は、ファイアウォールルールログを使用して分析できます。 入力拒否ルールは無効になっているため、最初に、すべての入力トラフィックを拒否しますが、ファイアウォールログが有効になっているカスタムの優先度の低いファイアウォールルールを作成する必要があります。 Thisruleが設定されていると、接続の試行に失敗すると、ログエントリがStackdriverに公開されます。 ファイアウォールルールは重要なログ量を生成する可能性があるため、分析が完了したら、ファイアウォールロギングを再度無効にすることを検討してく
VPC内から管理対象Microsoft ADにアクセスする
デフォルトのネットワークを使用して管理対象Microsoft ADをデプロイする場合、Vpc内のVmがActive Directoryにアクセ
VPC設定またはファイアウォールルールをカスタマイズした場合は、ファイアウォール設定で管理されたMicrosoft ADとの通信を許可する必要があります。 次のセクションでは、作成が必要なファイアウォールルールについて説明します。
ドメイン名解決
VMがDNS名を解決しようとすると、domaincontrollerを直接照会しません。 代わりに、DnsクエリはCompute Engine Vm用に構成されたデフォルトのDNSサーバーであるメタデータサーバーに送信されます。 メタデータサーバーは、microsoft ADによって作成されたクラウドDNS privateDNS転送ゾーンへのクエリをforwardsします。 この転送ゾーンは、クエリを適切なドメインコントローラに転送します。
このユースケースを有効にするためにファイアウォールルールを設定する必要はありません。クラウドDNS(1)への通信は、VPC内のVmに対して常に許可され、マネージドMicrosoft ADでは、デフォルトでクラウドDNSクラウドDNS(2)からのDNS要求を許可します。
Kerberosを使用したVMへの認証
あるVMにログインしているユーザーは、別のVMによって提供されるサービスへのアクセスが必要な場合があります。 たとえば、ユーザーがrdp接続を開いたり、ファイル共有にアクセスしたり、認証を必要とするHTTPリソースにアクセスしようとする場合があります。
ユーザーがKerberosを使用してサーバー VMに対して認証できるようにするには、クライアントVMhasは最初に管理されているMicrosoft ADコントローラのいずれかから適切なKerberosチ
VmがKerberosを使用して別のVmへの認証を有効にするには、ファイアウォールルールで次の通信を許可する必要:
| Action | From | To | Protocols | |
|---|---|---|---|---|
| 1 | Allow | Client VM | Managed Microsoft AD subnet | Kerberos (UDP/88, TCP/88) LDAP (UDP/389, TCP/389) |
| 2 | Allow | Client VM | Server VM | Protocol used to access VM, such as HTTP (TCP/80, TCP/443) or RDP (TCP/3389) |
| 3 | Allow | Server VM | Managed Microsoft AD subnet | See processing logons. |
NTLMを使用したVMへの認証
ほとんどの場合、WINDOWSPREFERSはNtlmを介してKerberosを参照しますが、クライアントはntlm forauthenticationを使用するようにフォールバックす NTLMはonpass-through認証に依存するため、サーバーはユーザーを認証するために管理されたMicrosoft ADドメインコントローラーのいずれかと通信する必要があります。
VMがNTLMを使用して他のVmを認証できるようにするには、ファイアウォールルールで次の通信を許可する必要があ:Th>
ドメイン参加とログオン処理
ドメインメンバーとして動作し、ユーザーからのログオンを処理するには、マシンがActive Directoryと対話できる必 使用されるプロトコルの正確なセット個々のクライアントが要求するログオンの種類に依存します。 すべてのcommonscenariosをサポートするには、次のプロトコルの組み合わせを許可する必要があります。
| Action | From | To | Protocols | |
|---|---|---|---|---|
| 1 | Allow | Server VM | Managed Microsoft AD subnet | 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) |
Additionally, depending on your exact use case, you might also want to permitthe 次のプロトコル:
| アクション | から | プロトコル | ||
|---|---|---|---|---|
| 1 | 許可 | サーバー VM | マネージマイクロソフトADサブネット | Kerberosパスワード変更(UDP/464、TCP/UDP/464、TCP/UDP/464、TCP/UDP/464、TCP/UDP/464、TCP/UDP/464、TCP/UDP/464、TCP/UDP/464、TCP/UDP/464、TCP/UDP/464、TCP/UDP/464、TCP/UDP/464、TCP/UDP/464、TCP/UDP/464、TCP/UDP//464) セキュアldap(tcp/636,tcp/3269) |
マネージドmicrosoft adの管理
マネージドmicrosoft adを管理するには、adomainに参加したvmを使用する必要があります。 このVMでActive DirectoryAdministrative Centerなどのツールを使用するには、管理対象のMicrosoft AD domaincontrollersによって公開されているactive Directory WebサービスにもVMがアクセスできる必要があります。Th>
マネージドmicrosoft adをオンプレミスのactive directoryに接続する
マネージドmicrosoft adをオンプレミスのactive directoryに接続するには、フォレスト間の信頼関係を作 さらに、Google Cloudとオンプレミス環境の間でdnsの名前解決を有効にする必要があります。
信頼の作成と検証
フォレストの信頼を作成して検証するには、マネージドMicrosoft ADdomainコントローラーとオンプレミスのforestmustのルートドメインコントロー
信頼の作成と検証を有効にするには、オンプレミスのファイアウォールを構成して、これらの特性に一致する入:
| Action | From | To | Protocols | |
|---|---|---|---|---|
| 1 | Allow | On-premises AD | Managed Microsoft AD | DNS (UDP/53, TCP/53) Kerberos (UDP/88, TCP/88) Kerberos password change (UDP/464, TCP/464) RPC (TCP/135, TCP/49152-65535) LDAP (UDP/389, TCP/389) SMB (UDP/445, TCP/445) |
| 2 | Allow | Managed Microsoft AD | On-premises AD | DNS (UDP/53, TCP/53) Kerberos (UDP/88, TCP/88) Kerberos password change (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名の解決
オンプレミスマシンが管理されたMicrosoft ADでDNS名を解決できるようにするには、DNS委任と条件付きDNS転送
DNS委任
マネージドMicrosoft ADで使用されるDNSドメインは、オンプレミスで使用されるdnsドメインのサブドメインである可能性があります。 たとえば、次のようにしますcloud.example.com microsoft ADを使用している間にforManaged example.com オンプレミス。 On-premisesclientsがGoogle CloudリソースのDNS名を解決できるようにするには、upDNS委任を設定できます。
DNS委任を使用する場合、aGoogle CloudリソースのDNS名を解決しようとすると、まずオンプレミスのDNSサーバーにクエリが実行されます。 その後、DNSserverはクライアントをCloud DNSにリダイレクトし、Cloud DNSはTherequestを管理対象のMicrosoft ADドメインコントローラのいずれかに転送します。
クラウドDNSをオンプレミスネットワークに公開するには、作成および受信サーバーポリシーが必要です。これにより、vpcの一部であるインバウンドフォワーダー IPアドレスが作成されます。
オンプレミスのフォワーダアドレスを使用するには、以下の特性に一致する出力トラフィックを許可するようにon-premisesfirewallを設定します。
| Action | From | To | Protocols | |
|---|---|---|---|---|
| 1 | Allow | On-premises AD | Managed Microsoft AD | DNS (UDP/53, TCP/53) Kerberos (UDP/88, TCP/88) Kerberos password change (UDP/464, TCP/464) RPC (TCP/135, TCP/49152-65535) LDAP (UDP/389, TCP/389) SMB (UDP/445, TCP/445) |
| 2 | Allow | Managed Microsoft AD | On-premises AD | DNS (UDP/53, TCP/53) Kerberos (UDP/88, TCP/88) Kerberos password change (UDP/464, TCP/464) RPC (TCP/135,TCP/49152-65535) LDAP(UDP/389,TCP/389) SMB(UDP/445,TCP/445) |
条件付きDNS転送
マネージドMicrosoft ADが使用するDNSドメインは、オンプレミスで使用されるdnsドメインのサブドメインではない可能性があります。 たとえば、オンプレミスでcorp.example.localcloud.example.comforManaged Microsoft ADを使用することができます。
DNSドメインが無関係なシナリオでは、オンプレミスのActive Directory DNSで条件付きDNSforwardingを設定できます。 Managed Microsoft ADで使用されるDNS名と一致するすべてのクエリは、Cloud DNSに転送されます。
条件付きDNS転送を使用するには、受信DNS転送を有効にするaDNSポリシーを設定する必要があります。 オンプレミスから生成されたフォワーダアドレスを使用するには、特性に一致する出力トラフィックを許可するように、オンプレミスのファイアウォールを構成します。Th>
googleクラウド側で、これらの条件に一致する入力トラフィックにファイアウォールルールを作成します。
dnsフォワーダからCloud DNS(2)への通信を有効にするためにファイアウォールルールを設定する必要はありません。
google CloudからのオンプレミスDNS名の解決
Managed Microsoft ADは、条件付きDNS転送を使用して、オンプレミスフォレスト内のDNS名を解決します。 また、オンプレミスのActive Directoryで管理されているGoogle Cloud toresolve DNS名で実行されているクライアントを許可するには、オンプレミスのドメインコントローラにクエリを転送するdns DNSを含むプライベート転送ゾーンを作成します。
Google CloudからオンプレミスDNS名の解決を有効にするには、次の表に従ってオンプレミスのファイアウォールTh>
Google Cloudは、デフォルトで対応する出力トラフィックを許可します。
オンプレミスからマネージMicrosoft ADリソースにアクセスする
マネージMicrosoft ADフォレストがオンプレミスのフォレストを信頼するように設定されている場合は、オンプレミスのユーザーとマシンがマネージMicrosoft ADフォレスト内のリソースにアクセスできるようにすることができます。
Kerberosを使用したオンプレミスからVMへの認証
オンプレミスのマシンにログインしているユーザーは、Google Cloud上で実行され、aManaged Microsoft AD forestのメンバーであるVM たとえば、ユーザーがRDPconnectionを開いたり、ファイル共有にアクセスしたり、authenticationを必要とするHTTPリソースにアクセスしようとする場合があります。
ユーザーがKerberosを使用してサーバー VMに対して認証できるようにするには、clientmachineが適切なKerberosチケットを取得する必要があります。 これには、オンプレミスドメインコントローラーのいずれかと、マネージドMicrosoft ADドメインコントローラーのいずれかとの通信が必要です。
オンプレミスのVmがKerberosを使用して認証できるようにするには、次の出力トラフ
| Action | From | To | Protocols | |
|---|---|---|---|---|
| 1 | Allow | Client machine (on-premises) | Managed Microsoft AD subnet | LDAP (UDP/389, TCP/389) Kerberos (UDP/88, TCP/88) |
| 2 | Allow | Client machine (on-premises) | Server VM (GCP) | Protocol used by application, such as HTTP (TCP/80, TCP/443) or RDP (TCP/3389) |
| 3 | Allow | Server VM | Managed Microsoft AD subnet | See processing logons. |
Googleクラウド側で、(1)と(2)の入力トラフィックにファイアウォールルールを作成します。 管理対象Microsoft AD(3)への出力トラフィックは、既定で許可されています。
NTLMを使用したオンプレミスからのVMへの認証
NTLMを使用してオンプレミスのアクティブなDirectoryforestから、管理対象Microsoft ADフォレストに参加してい
オンプレミスのVmがNTLMを使用して認証できるようにするには、次のように入Th>
SMB(UDP/445,TCP/445)
Googleクラウド側で、ファイアウォールルール(1)のための入力トラフィック。 (2)および(3)の出力トラフィックは、デフォルトでallowedbyです。
オンプレミスフォレストのユーザーのログオンの処理
オンプレミスフォレストのユーザーのログオンを処理するには、VMがオンプレミスActive Directoryと対話できるようにする必要があります。 使用されるプロトコルの正確なセットは、クライアントが要求したlogonタイプに依存します。 すべての一般的なシナリオをサポートするには、これらの特性に一致する侵入トラフィックを許可するように社内ファイアウォールを構成します。Th>
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)
マネージドMicrosoft AD側では、対応する出力トラフィックはデフォルトで許可されます。
管理用Vmでは、オンプレミスフォレストのユーザーからのログオンを許可しない場合があります。 ただし、管理Vmで実行する必要がある可能性のあるアクティビティの1つは、グループメンバーシップの管理です。 オブジェクトピッカーを使用してオンプレミスフォレストからユーザーまたはグループを参照する場合、オブジェクトピッカーにはオンプレミスドメインコントローラへのアクセスが必要になります。 これを機能させるには、管理用VMは、オンプレミスフォレストのユーザーのログオンを処理する場合と同じように、オンプレミスアクティブディレクトリドメインコントローラーへのアクセスを必要とします。
google CloudからオンプレミスActive Directoryリソースにアクセスする
オンプレミスフォレストが管理対象MICROSOFT ADフォレストを信頼するように設定されて
Kerberosを使用したオンプレミスVMへの認証
Google Cloudで実行されているVMにログインしており、管理対象Microsoft ADフォレストのメンバーであるユーザーは、オンプレミスフォレストのメンバーであるオンプレミスマシンによって提供されるserviceprovidedへのアクセスが必要になる場合があります。たとえば、ユーザーがrdp接続を開いたり、ファイル共有にアクセスしたり、認証を必要とするHTTPリソースにアクセスしようとする場合があります。
ユーザーがKerberosを使用してオンプレミスマシンに対して認証できるようにするには、vmは適切なKerberosチケットを取得する必要があります。 これには、まずマネージドMicrosoft ADコントローラーのいずれかと通信し、次にオンプレミスドメインコントローラーと通信する必要があります。
オンプレミスVmがKerberosを使用して認証できるようにするには、characteristicsbelowに一致する入
| Action | From | To | Protocols | |
|---|---|---|---|---|
| 1 | Allow | Client VM (Google Cloud) | Managed Microsoft AD subnet | Kerberos (UDP/88, TCP/88) LDAP (UDP/389, TCP/389) Implied by processing logons |
| 2 | Allow | Client VM (Google Cloud) | On-premises AD | Kerberos (UDP/88, TCP/88) LDAP (UDP/389, TCP/389) |
| 3 | Allow | Client VM (Google Cloud) | Server machine (on-premises) | Protocol used by HTTP(TCP/80,TCP/443)やRDP(TCP/3389)などのアプリケーション |
Googleクラウド側では、対応する出力トラフィックがデフォルトで許可されています。
NTLMを使用したオンプレミスVMへの認証
NTLMを使用して、オンプレミスフォレストに参加している管理対象Microsoft ADフォレストtoaサーバーマシンからユーザーを認証する場合、オンプレミスドメインコントローラは、管理対象Microsoft ADドメインコントローラと通信できる必要があります:
オンプレミスVmがKerberosを使用して認証できるようにするには、これらの特性に一致する入Th>
SMB(Udp/445,tcp/445)
googleクラウド側では、(1)の出力トラフィックと(2)の入力トラフィックは次のように許可されています デフォルト。
マネージドMicrosoft ADフォレストのユーザーのログオンの処理
マネージドMicrosoft ADフォレストのユーザーのログオンを処理するには、オンプレミスのmachinerunningがManaged Microsoft ADdomain 使用されるプロトコルの正確なセットは、クライアントが要求したlogonタイプに依存します。 すべての一般的なシナリオをサポートするには、次のプロトコルの組み合わせ。Th>
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)
- Secure LDAP(TCP/636、TCP/3269)
オンプレミスのファイアウォールが、これらの特性に一致する出力トラフィックを許可しているこ Microsoft ADに対応する入力トラフィックを有効にするために、google Cloud内のファイアウォールルールを構成する必要はありません。
管理用コンピューターでは、管理されたMicrosoft ADフォレストのユーザーからのログオンを許可しない場合があります。 管理者のマシンで実行する必要がある可能性のあるアクティビティの1つは、グループメンバーシップの管理です。 オブジェクトピッカーを使用してManaged Microsoft ADforestからユーザーまたはグループを参照する場合、オブジェクトピッカーはManaged Microsoft ADdomainコントローラーへのアクセスを必要とします。 これを機能させるには、管理マシンは、管理対象Microsoft ADフォレストのユーザーのログオンを処理する場合と同様に、管理対象Microsoft ADドメインコントローラーへの同