手順 1: 高度な DirectAccess インフラストラクチャを計画する
適用対象: Windows Server 2022、Windows Server 2019、Windows Server 2016
単一サーバーでの高度な DirectAccess 展開計画の最初の手順は、展開に必要なインフラストラクチャを計画することです。 このトピックでは、インフラストラクチャの計画手順を説明します。 これらの計画タスクを特定の順序で完了する必要はありません。
| タスク | 説明 |
|---|---|
| 1.1ネットワーク トポロジと設定を計画する | DirectAccess サーバーの配置場所 (エッジか、ネットワーク アドレス変換 (NAT) デバイスまたはファイアウォールの内側) を決定し、IP アドレス指定、ルーティング、強制トンネリングを計画します。 |
| 1.2 ファイアウォールの要件を計画する | DirectAccess トラフィックがエッジ ファイアウォールを使用するように計画します。 |
| 1.3 証明書の要件を計画する | クライアント認証に Kerberos を使用するか、証明書を使用するかを決定し、Web サイト証明書を計画します。 IP-HTTPS は、IPv4 ネットワーク経由で IPv6 トラフィックをトンネリングするために DirectAccess クライアントによって使用される移行プロトコルです。 IP-HTTPS サーバーの認証に証明機関 (CA) が発行する証明書を使用するか、DirectAccess サーバーが自動的に発行する自己署名証明書を使用するかを決定します。 |
| 1.4 DNS 要件を計画する | DirectAccess サーバーのドメイン ネーム システム (DNS) 設定、インフラストラクチャ サーバー、ローカルでの名前解決オプション、クライアント接続を計画します。 |
| 1.5 ネットワーク ロケーション サーバーを計画する | ネットワーク ロケーション サーバーは、内部ネットワークに配置されているかどうかを判断するために DirectAccess クライアントによって使用されます。 組織でのネットワーク ロケーション サーバー Web サイトの配置場所 (DirectAccess サーバーまたは代替サーバー) を決定し、ネットワーク ロケーション サーバーを DirectAccess サーバーに配置する場合は、証明書要件を計画します。 |
| 1.6 管理サーバーを計画する | インターネット上で企業ネットワークの外側に配置された DirectAccess クライアント コンピューターはリモートで管理できます。 リモート クライアント管理時に使用する管理サーバー (更新サーバーなど) を計画します。 |
| 1.7 Active Directory ドメイン サービスを計画する | ドメイン コントローラー、Active Directory の要件、クライアント認証、複数ドメインを計画します。 |
| 1.8 グループ ポリシー オブジェクトを計画する | 組織で必要な GPO とその GPO の作成または編集方法を決定します。 |
1.1ネットワーク トポロジと設定を計画する
このセクションでは、次のようなネットワークを計画する方法について説明します。
1.1.1 ネットワーク アダプターと IP アドレス指定を計画する
使用するネットワーク アダプターのトポロジを決定します。 DirectAccess は、次のトポロジのいずれかを使用して設定できます。
2 つのネットワーク アダプター: DirectAccess サーバーは、インターネットに接続されたネットワーク アダプター 1 つと、内部ネットワークに接続されたもう 1 つのネットワーク アダプターを使用してエッジにインストールできます。または、境界ネットワークに接続されたネットワーク アダプター 1 つと、内部ネットワークに接続されたもう 1 つのネットワーク アダプターを使用して NAT、ファイアウォール、またはルーター デバイスの内側にインストールできます。
1 つのネットワーク アダプター: DirectAccess サーバーは、NAT デバイスの内側にインストールされ、単一のネットワーク アダプターが内部ネットワークに接続されます。
IP アドレス指定要件を識別します。
DirectAccess は、IPv6 と IPsec を組み合わせて、DirectAccess クライアント コンピューターと企業内部ネットワークとの間にセキュリティで保護された接続を確立します。 ただし、DirectAccess は、IPv6 インターネットへの接続または内部ネットワーク上でのネイティブ IPv6 サポートを必ずしも必要とはしません。 代わりに、IPv6 移行テクノロジを自動的に構成して使用し、IPv4 インターネット (6to4、Teredo、または IP-HTTPS を使用して)、IPv4 専用のイントラネットで (NAT64 または ISATAP を使用して) IPv6 トラフィックをトンネリングします。 このような移行テクノロジの概要については、次のリソースを参照してください。
次の表に従って、必要なアダプターとアドレスを構成します。 単一のネットワーク アダプターを使用し、NAT デバイスの内側に設定される展開については、「内部ネットワーク アダプター」の列のみを使用して IP アドレスを構成してください。
説明 外部ネットワーク アダプター 内部ネットワーク アダプター ルーティングの要件 IPv4 インターネットと IPv4 イントラネット 適切なサブネット マスクを使用して、連続する 2 つの静的パブリック IPv4 アドレスを構成します (Teredo についてのみ必要)。
また、インターネット ファイアウォール、またはローカルのインターネット サービス プロバイダー (ISP) のルーターのデフォルト ゲートウェイ IPv4 アドレスも構成します。 注: Teredo サーバーとして機能し、Windows ベースのクライアントが DirectAccess サーバーを使用して背後にある NAT デバイスの種類を検出するように、DirectAccess サーバーに 2 つの連続するパブリック IPv4 アドレスが必要です。次を構成します。
- 適切なサブネット マスクを持つ IPv4 イントラネット アドレス。
- イントラネット名前空間の接続固有の DNS サフィックス。 DNS サーバーも、内部インターフェイスで構成する必要があります。 注意: イントラネット インターフェイスで、既定のゲートウェイを構成しません。内部 IPv4 ネットワーク上のすべてのサブネットに到達できるように DirectAccess サーバーを構成するには、次の操作を行います。
- イントラネット上のすべての場所の IPv4 アドレス空間を一覧表示します。
route add -p コマンド、または netsh interface ipv4 add route コマンドを使用して、DirectAccess サーバーの IPv4 ルーティング テーブルに IPv4 アドレス空間を静的ルートとして追加します。IPv6 インターネットおよび IPv6 イントラネット 次を構成します。
- ISP によって提供されたアドレス構成を使用します。
- Route Print コマンドを使用して、既定の IPv6 ルートが存在しており、IPv6 ルーティング テーブルの ISP ルーターをポイントしていることを確認します。
- ISP およびイントラネット ルーターで、RFC 4191 に記述されている既定のルーター基本設定が使用されているかどうか、およびローカルのイントラネット ルーターより高い既定の基本設定が使用されているかどうかを確認します。
どちらについても使用している場合は、既定のルートに他の構成は必要ありません。 ISP ルーターの高度な基本設定によって、DirectAccess サーバーの既定の IPv6 アクティブ ルートが IPv6 インターネットを示すことが保証されます。
DirectAccess サーバーは IPv6 ルーターであるため、ネイティブ IPv6 インフラストラクチャがある場合は、インターネット インターフェイスからイントラネット上のドメイン コントローラーに到達することもできます。 この場合、DirectAccess サーバーのインターネット接続インターフェイスの IPv6 アドレスへの接続を防ぐ境界ネットワークのドメイン コントローラーに、パケット フィルターを追加します。次を構成します。
- 既定の優先レベルを使用していない場合は、netsh interface ipv6 set InterfaceIndex ignoredefaultroutes=enabled コマンドを使用してイントラネット インターフェイスを構成できます。
このコマンドにより、イントラネット ルーターをポイントする追加の既定のルートは IPv6 ルーティング テーブルに追加されなくなります。 イントラネット インターフェイスのインターフェイス インデックスは、次のコマンドを使用して入手できます: netsh interface ipv6 show interface。IPv6 イントラネットがある場合、IPv6 のすべての場所に到達できるように DirectAccess サーバーを構成するには、次のようにします。
- イントラネットのすべての場所の IPv6 アドレス空間を一覧表示します。
- netsh interface ipv6 add route コマンドを使用して、DirectAccess サーバーの IPv6 ルーティング テーブルに IPv6 アドレス空間を静的ルートとして追加します。IPv4 インターネットおよび IPv6 イントラネット DirectAccess サーバーは、既定の IPv6 ルート トラフィックを IPv4 インターネットで、Microsoft 6to4 アダプターから 6to4 リレーに転送します。 netsh interface ipv6 6to4 set relay name=<ipaddress> state=enabledコマンドを使用して、Microsoft 6to4 アダプターの IPv4 アドレスで DirectAccess サーバーを構成できます。注意
- パブリック IPv4 アドレスが割り当てられている DirectAccess クライアントは、6to4 移行テクノロジを使ってイントラネットに接続します。 プライベート IPv4 アドレスが割り当てられると、Teredo が使用されます。 DirectAccess クライアントが 6to4 または Teredo を使用して DirectAccess サーバーに接続できない場合は、IP-HTTPS が使用されます。
- Teredo を使用するには、外部ネットワーク アダプターで連続する 2 つの IP アドレスを構成する必要があります。
- DirectAccess サーバーにネットワーク アダプターが 1 つしかない場合は、Teredo を使用できません。
- ネイティブ IPv6 クライアント コンピューターは、ネイティブ IPv6 経由で DirectAccess サーバーに接続できます。移行テクノロジを必要としません。
1.1.2 IPv6 イントラネット接続を計画する
リモート DirectAccess クライアントを管理するには、IPv6 が必要です。 IPv6 では、DirectAccess 管理サーバーに、リモート管理を目的としてインターネットに配置された DirectAccess クライアントへの接続が許可されます。
注意
- 組織のネットワーク上の IPv4 リソースに対して DirectAccess クライアント コンピューターによって開始された接続をサポートするために、ネットワークで IPv6 を使用する必要はありません。 この目的には、NAT64/DNS64 が使用されます。
- リモート DirectAccess クライアントを管理していない場合は、IPv6 を展開する必要はありません。
- ISATAP (Intra-Site Automatic Tunnel Addressing Protocol) は、DirectAccess 展開ではサポートされていません。
- IPv6 を使用する場合、Windows PowerShell コマンド Set-NetDnsTransitionConfiguration -OnlySendAQuery $false を使用して、DNS64 に対して IPv6 ホスト (AAAA) リソース レコード クエリを有効にできます。
1.1.3 強制トンネリングを計画する
IPv6 と名前解決ポリシー テーブル (NRPT) を使用すると、既定で DirectAccess クライアントは、イントラネット トラフィックとインターネット トラフィックを次のように分割します。
イントラネットの完全修飾ドメイン名 (FQDN) 向けの DNS 名のクエリとすべてのイントラネット トラフィックは、DirectAccess サーバーで作成されたトンネル、またはイントラネット サーバーで直接交換されます。 DirectAccess クライアントからのイントラネット トラフィックは、IPv6 トラフィックです。
除外規則と一致する、またはイントラネット名前空間と一致しない FQDN に対する DNS 名クエリ、およびインターネット サーバーに対するすべてのトラフィックは、インターネットに接続された物理的インターフェイスで交換されます。 DirectAccess クライアントからのインターネット トラフィックは、通常 IPv4 トラフィックです。
これに対して、既定では、一部のリモート アクセス仮想プライベート ネットワーク (VPN) 実装は、VPN クライアントを含めて、すべてのイントラネット トラフィックとインターネット トラフィックをリモート アクセス VPN 接続で送信します。 インターネット向けのトラフィックは、IPv4 インターネット リソースへのアクセスのために、VPN サーバーによって、イントラネット IPv4 Web プロキシ サーバーにルーティングされます。 分割トンネリングを使用して、リモート アクセス VPN クライアント向けにイントラネット トラフィックとインターネット トラフィックを分割できます。 これには、イントラネットの場所へのトラフィックが VPN 接続で送信されるようにし、その他すべての場所へのトラフィックがインターネットに接続された物理的インターフェイスを使用して送信されるようにする、VPN クライアントのインターネット プロトコル (IP) ルーティング テーブルが関係します。
強制トンネリングですべてのトラフィックがトンネルを経由して DirectAccess サーバーに送信されるように、DirectAccess クライアントを構成できます。 強制トンネリングを構成すると、DirectAccess クライアントは、自身がインターネット上に置かれていることを検出し、IPv4 既定のルートを削除します。 ローカル サブネット トラフィックを除き、DirectAccess クライアントによって送信されるすべてのトラフィックは、トンネルを経由して DirectAccess サーバーに送信される IPv6 トラフィックです。
重要
強制トンネリングを使用する計画がある場合、または今後追加する可能性がある場合は、2 つのトンネル構成を展開する必要があります。 セキュリティ上の注意事項により、単一のトンネル構成での強制トンネリングはサポートされていません。
強制トンネリングを有効化すると、次のような影響があります。
DirectAccess クライアントは、Internet Protocol over Secure Hypertext Transfer Protocol (IP-HTTPS) のみを使用して、IPv4 インターネットでの DirectAccess サーバーへの IPv6 接続を取得します。
既定で、IPv4 トラフィックを使用して DirectAccess クライアントが到達できるのは、ローカル サブネット上の場所のみです。 DirectAccess クライアントで実行されているアプリケーションとサービスによって送信されるその他すべてのトラフィックは、DirectAccess 接続で送信される IPv6 トラフィックです。 そのため、ローカル サブネット上のものを除き、DirectAccess クライアント上の IPv4 専用アプリケーションを使用して、インターネット リソースに到達することはできません。
重要
DNS64 と NAT64 による強制トンネリングでは、IPv6 インターネット接続を実装する必要があります。 これを行うには、IP-HTTPS プレフィックスをグローバルにルーティング可能にして、ipv6.msftncsi.com に IPv6 で到達できるようにし、インターネット サーバーから IP-HTTPS クライアントへの応答が DirectAccess サーバーを経由して返されるようにする方法があります。
ほとんどの場合、これは実現できないため、仮想 NCSI サーバーを次のように企業ネットワーク内に作成するのが、最良の選択肢です。
- ipv6.msftncsi.com に NRPT エントリを追加して、DNS64 に対して内部 Web サイトに解決します (これは IPv4 Web サイトにできます)。
- dns.msftncsi.com に NRPT エントリを追加して、企業 DNS サーバーに対して解決し、IPv6 ホスト (AAAA) リソース レコード fd3e:4f5a:5b81::1 に返します。 (IPv4 専用の展開で構成されているため、DNS64 をこの FQDN のホスト (A) リソース レコード クエリ送信のみに使用するとうまく機能しない場合があります。このため、DNS64 は企業 DNS に対して直接解決するように構成する必要があります。)
1.2 ファイアウォールの要件を計画する
DirectAccess サーバーが、エッジ ファイアウォールの内側に配置されている場合、DirectAccess サーバーが IPv4 インターネット上にあるときに、リモート アクセス トラフィックには、次の例外が必要です。
Teredo トラフィック ユーザー データグラム プロトコル (UDP) 宛先ポート 3544 受信と、udp 発信元ポート 3544 の送信します。
6to4 トラフィック IP プロトコル 41 の受信と送信されます。
IP の HTTPS の伝送制御プロトコル (TCP) 宛先ポート 443 と TCP 発信元ポート 443 送信します。
単一のネットワーク アダプターでリモート アクセスを展開していて、DirectAccess サーバーにネットワーク ロケーション サーバーをインストールしている場合、TCP ポート 62000 も除外する必要があります。
注意
この除外は DirectAccess サーバー上、その他すべての除外はエッジ ファイアウォール上になります。
Teredo トラフィックと 6to4 トラフィックの場合、これらの例外は、インターネットに接続された連続する DirectAccess サーバー上のパブリック IPv4 アドレス両方に適用する必要があります。 IP-HTTPS の場合、例外はパブリック DNS サーバーに登録されたアドレスに適用される必要があります。
DirectAccess サーバーが IPv6 インターネット上にある場合は、リモート アクセス トラフィックに次の例外が必要です。
IP プロトコル ID 50
UDP 宛先ポート 500 の受信と、UDP 発信元ポート 500 の送信
ICMPv6 トラフィックの受信と送信 (Teredo のみを使用している場合)
追加のファイアウォールを使用する場合は、次の内部ネットワーク ファイアウォールの例外をリモート アクセス トラフィックに適用します。
ISATAP プロトコル 41 の受信と送信
すべての IPv4 トラフィックと IPv6 トラフィックに対する TCP/UDP
すべての IPv4 トラフィックと IPv6 トラフィックに対する ICMP (Teredo のみを使用している場合)
1.3 証明書の要件を計画する
単一の DirectAccess サーバーを展開する場合、証明書を必要とするシナリオは 3 つあります。
- 手順 1: 高度な DirectAccess インフラストラクチャを計画する
次の表には、それぞれのシナリオに関する証明機関 (CA) の要件がまとめられています。
| IPsec 認証 | IP-HTTPS サーバー | ネットワーク ロケーション サーバー |
|---|---|---|
| 認証に Kerberos プロキシを使用しない場合に、内部 CA が DirectAccess サーバーとの IPsec 認証にクライアントをコンピューター証明書を発行するために必要 | 内部 CA: IP-HTTPS 証明書の発行には、内部 CA を使用できます。ただし、CRL 配布ポイントが外部で使用できることを確認する必要があります。 |
内部 CA: 内部 CA を使用して、ネットワーク ロケーション サーバー Web サイト証明書を発行できます。 CRL 配布ポイントに内部ネットワークからの高可用性があることを確認してください。 |
| 自己署名証明書: IP-HTTPS サーバーには、自己署名証明書を使用できます。ただし、CRL 配布ポイントが外部で使用できることを確認する必要があります。 自己署名証明書をマルチサイト展開に使用することはできません。 |
自己署名証明書: 自己署名証明書は、ネットワーク ロケーション サーバー Web サイトに使用できます。 自己署名証明書をマルチサイト展開に使用することはできません。 |
|
| 推奨 パブリック CA: IP-HTTPS 証明書の発行には、パブリック CA の使用をお勧めします。 こうすることで、CRL 配布ポイントを外部で使用できます。 |
1.3.1 IPsec 認証にコンピューター証明書を計画する
証明書に基づく IPsec 認証を使用している場合、DirectAccess サーバーとクライアントは、コンピューター証明書を入手する必要があります。 証明書をインストールする最も簡単な方法は、コンピューター証明書にグループ ポリシーベースの自動登録を構成することです。 こうすることによって、すべてのドメイン メンバーがエンタープライズ CA から証明書を入手します。 エンタープライズ CA を組織内の設定があるない場合は、次を参照してください。Active Directory Certificate Servicesです。
この証明書には、次の要件があります。
証明書には、クライアント認証拡張キー使用法 (EKU) が必要です。
クライアント証明書とサーバー証明書は、同じルート証明書に結びつけられている必要があります。 このルート証明書は、DirectAccess 構成設定で選択されている必要があります。
1.3.2 IP-HTTPS に証明書を計画する
DirectAccess サーバーは IP-HTTPS リスナーとして機能し、HTTPS Web サイト証明書をサーバーに手動でインストールする必要があります。 計画するときは、次の点を考慮してください。
証明書失効リスト (CRL) がすぐに使用できるように、パブリック CA を使用することをお勧めします。
[サブジェクト] フィールドで、DirectAccess サーバーのインターネット アダプターの IPv4 アドレス、または IP-HTTPS URL (ConnectTo アドレス) の FQDN を指定します。 DirectAccess サーバーが NAT デバイスの内側に置かれている場合、NAT デバイスのパブリック名、またはアドレスを指定する必要があります。
証明書の共通名は、IP-HTTPS サイトの名前と一致している必要があります。
[拡張キー使用法] フィールドに、サーバー認証オブジェクト識別子 (OID) を使用します。
[CRL 配布ポイント] フィールドに、インターネットに接続している DirectAccess クライアントがアクセスできる CRL 配布ポイントを指定します。
IP-HTTPS 証明書には秘密キーが必要です。
IP-HTTPS 証明書は、個人用ストアに直接インポートする必要があります。
IP-HTTPS 証明書の名前にはワイルドカードを含めることができます。
IP-HTTPS を標準以外のポートで使用する計画がある場合は、DirectAccess サーバーで次の手順を実行してください。
0.0.0.0:443 にバインドされた既存の証明書を削除して、選択したポートにバインドされた証明書に置き換えます。 この例の目的には、44500 を使用します。 証明書バインドを削除する前に、appid を表示してコピーします。
証明書バインドを削除するには、次の内容を入力します。
netsh http delete ssl ipport=0.0.0.0:443新しい証明書バインドを追加するには、次の内容を入力します。
netsh http add ssl ipport=0.0.0.0:44500 certhash=<use the thumbprint from the DirectAccess server SSL cert> appid=<use the appid from the binding that was deleted>
サーバーで IP-HTTPS URL を変更するには、次の内容を入力します。
Netsh int http set int url=https://<DirectAccess server name (for example server.contoso.com)>:44500/IPHTTPSNet stop iphlpsvc & net start iphlpsvckdcproxy のURL 予約を変更します。
既存の URL 予約を削除するには、次の内容を入力します。
netsh http del urlacl url=https://+:443/KdcProxy/新しい URL 予約を追加するには、次の内容を入力します。
netsh http add urlacl url=https://+:44500/KdcProxy/ sddl=D:(A;;GX;;;NS)
設定を追加して、kppsvc が標準以外のポートでリッスンするようにします。 レジストリ エントリを追加するには、次の内容を入力します。
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\KPSSVC\Settings /v HttpsUrlGroup /t REG_MULTI_SZ /d +:44500 /fドメイン コントローラーで kdcproxy サービスを再起動するには、次の内容を入力します。
net stop kpssvc & net start kpssvc
標準でないポートで IP-HTTPS を使用するには、ドメイン コントローラーで次の手順を実行します。
クライアント GPO で IP-HTTPS 設定を変更します。
グループ ポリシー エディターを開きます。
[コンピューターの構成] => [ポリシー] => [管理用テンプレート] => [ネットワーク] => [TCPIP 設定] => [IPv6 移行テクノロジ] に移動します。
[IP-HTTPS 状態の設定] を開いて、URL を https://<DirectAccess サーバー名 (例: server.contoso.com)>:44500/IPHTTPS に変更します。
[適用] をクリックします。
クライアント GPO で Kerberos プロキシ クライアント設定を変更します。
グループ ポリシー エディターで、[コンピューターの構成] => [ポリシー] => [管理用テンプレート] => [システム] => [Kerberos] => [Kerberos クライアントの KDC プロキシ サーバーを指定する] に移動します。
[IP-HTTPS 状態の設定] を開いて、URL を https://<DirectAccess サーバー名 (例: server.contoso.com)>:44500/IPHTTPS に変更します。
[適用] をクリックします。
ComputerKerb と UserKerb を使用するように、クライアント IPsec ポリシー設定を変更します。
グループ ポリシー エディターで、[コンピューターの構成] => [ポリシー] => [Windows 設定] => [セキュリティの設定] => [セキュリティが強化された Windows ファイアウォール] に移動します。
[接続セキュリティの規則] をクリックし、[IPsec 規則] をダブルクリックします。
[認証] タブで、[詳細設定] をクリックします。
Auth1 の場合: 既存の認証方法を削除し、ComputerKerb で置き換えます。 Auth2 の場合: 既存の認証方法を削除し、UserKerb で置き換えます。
[適用] をクリックし、[OK] をクリックします。
標準でない IP-HTTPS ポートを使用する手動プロセスを完了するには、クライアント コンピューターと DirectAccess サーバーで、gpupdate /force を実行します。
1.3.3 ネットワーク ロケーション サーバーの Web サイト証明書を計画する
ネットワーク ロケーション サーバーの Web サイトを計画している場合は、次の点を考慮してください。
[サブジェクト] フィールドで、ネットワーク ロケーション サーバーのイントラネット インターフェイスの IP アドレス、またはネットワーク ロケーション URL の FQDN を指定します。
[拡張キー使用法] フィールドに、サーバー認証 OID を使用します。
[CRL 配布ポイント] フィールドに、イントラネットに接続している DirectAccess クライアントがアクセスできる CRL 配布ポイントを使用します。 この CRL 配布ポイントは、内部ネットワークの外側からアクセスできないようにしてください。
後でマルチサイトまたはクラスター展開を計画している場合は、証明書の名前が展開に追加する DirectAccess サーバーの内部名と一致しないようにしてください。
注意
IP-HTTPS の証明書とネットワーク ロケーション サーバーに [サブジェクト名] があることを確認します。 証明書に [サブジェクト名] がなく、[別名] がある場合、リモート アクセス ウィザードでは受け入れされません。
1.4 DNS 要件を計画する
このセクションでは、リモート アクセス展開の DirectAccess クライアント要求とインフラストラクチャ サーバーの DNS 要求について説明します。 このトピックには次のサブセクションが含まれます。
DirectAccess クライアント要求
DNS は、内部 (または企業ネットワーク) に配置されていない DirectAccess クライアント コンピューターからの要求の解決に使用します。 DirectAccess クライアントは、インターネット上に配置されているか、内部ネットワークに配置されているかを判断するために、DirectAccess ネットワーク ロケーション サーバーに接続しようとします。
接続に成功すると、クライアントは内部ネットワークに配置されていると識別され、DirectAccess は使用されず、クライアント要求はクライアント コンピューターのネットワーク アダプターで構成される DNS サーバーを使用して解決されます。
接続に失敗すると、クライアントはインターネットに配置されていると仮定され、DirectAccess クライアントは名前解決ポリシー テーブル (NRPT) を使用して、名前要求を解決するときに使用する DNS サーバーを決定します。
クライアントが名前解決に DirectAccess DNS64 を使用するか、代替内部 DNS サーバーを使用するかを指定できます。 名前解決の実行時、NRPT が DirectAccess クライアントによって使用されて、要求の処理方法が特定されます。 クライアントは、FQDN またはhttps://internalなどの 1 つのラベル名を要求します。 シングルラベル名が要求されると、DNS サフィックスが追加されて FQDN になります。 DNS クエリが NRPT のエントリと一致し、DNS64 または内部ネットワーク上の DNS サーバーがエントリに指定されると、指定したサーバーを使用して、名前解決にクエリが送信されます。 一致が存在するが、DNS サーバーが指定されていない場合、これは除外規則を示し、通常の名前解決が適用されます。
注意
リモート アクセス管理コンソールで新しいサフィックスを NRPT に追加すると、[検出] をクリックしてサフィックスの既定の DNS サーバーを自動的に検出できます。
自動検出のしくみは次のとおりです。
企業ネットワークが IPv4 ベースの場合、または IPv4 と IPv6 を使用している場合、既定のアドレスは DirectAccess サーバーの内部アダプターの DNS64 アドレスです。
企業ネットワークが IPv6 ベースである場合、既定のアドレスは、企業ネットワーク内の DNS サーバーの IPv6 アドレスです。
注意
Windows 10 の 2020 年 5 月の更新プログラム以降、クライアントは名前解決ポリシー テーブル (NRPT) で構成された DNS サーバーに IP アドレスを登録しなくなりました。 DNS の登録が必要な場合 (たとえば、Manage Out など)、クライアントでこのレジストリ キーを使用して明示的に有効にすることができます。
パス: HKLM\System\CurrentControlSet\Services\Dnscache\Parameters
型: DWORD
値の名前: DisableNRPTForAdapterRegistration
値:
1 - DNS 登録が無効 (Windows 10 の 2020 年 5 月の更新プログラム以降は既定値)
0 - DNS 登録が有効
インフラストラクチャ サーバー
ネットワーク ロケーション サーバー
DirectAccess クライアントは、内部ネットワークに配置されているかを判断するために、ネットワーク ロケーション サーバーに接続しようとします。 内部ネットワークのクライアントは、ネットワーク ロケーション サーバーの名前を解決できる必要がありますが、インターネット上に配置されている場合は、名前の解決を防ぐ必要があります。 これが確実に行われるように、既定で、ネットワーク ロケーション サーバーの FQDN が NRPT に対する除外規則として追加されます。 また、リモート アクセスを構成する場合、次の規則が自動的に作成されます。
ルート ドメイン、または DirectAccess サーバーのドメイン名の DNS サフィックス規則と DNS64 アドレスに一致する IPv6 アドレス。 IPv6 専用の企業ネットワークでは、イントラネット DNS サーバーが DirectAccess サーバー上に構成されます。 たとえば、DirectAccess サーバーが corp.contoso.com ドメインのメンバーである場合、corp.contoso.com DNS サフィックスについて規則が作成されます。
ネットワーク ロケーション サーバーの FQDN の除外規則。 たとえば、ネットワーク ロケーション サーバーの URL がの場合https://nls.corp.contoso.com、FQDN nls.corp.contoso.com に対して除外規則が作成される。
IP-HTTPS サーバー
DirectAccess サーバーは IP-HTTPS リスナーとして機能し、サーバー証明書を使用して、IP-HTTPS クライアントを認証します。 IP-HTTPS 名は、パブリック DNS サーバーを使用している DirectAccess クライアントによって解決できる必要があります。
CRL 失効確認
DirectAccess は、DirectAccess クライアントと DirectAccess サーバーの間の IP-HTTPS 接続、DirectAccess クライアントとネットワーク ロケーション サーバーの間の HTTPS ベースの接続に証明書の失効確認を使用します。 どちらの場合も、DirectAccess クライアントは、CRL 配布ポイントの場所の解決とアクセスができる必要があります。
ISATAP
ISATAP は、会社のコンピューターで IPv6 アドレスを取得できるようにし、IPv4 ヘッダー内の IPv6 パケットをカプセル化します。 DirectAccess サーバーによって使用され、イントラネットで ISATAP ホストへの IPv6 接続を提供します。 ネイティブではない IPv6 ネットワーク環境で、DirectAccess サーバーは自身を自動的に ISATAP ルーターとして構成します。
ISATAP は、DirectAccess でサポートされなくなったため、DNS サーバーが ISATAP クエリに応答しないように構成されていることを確認する必要があります。 既定では、ISATAP 名に対する DNS サーバー サービス ブロックの名前解決は、DNS グローバル クエリ禁止リストで行われます。 ISATAP 名をグローバル クエリ禁止リストから削除しないでください。
接続検証方法
リモート アクセスでは、DirectAccess クライアント コンピューターが内部ネットワークへの接続の検証に使用する既定の Web プローブが作成されます。 プローブを意図したとおりに機能させるには、DNS で次の名前を手動で登録する必要があります。
directaccess webprobehost-DirectAccess サーバーの内部 IPv4 アドレスまたは IPv6 専用環境で IPv6 アドレスに解決されます。
directaccess corpconnectivityhost-ローカル ホスト (ループバック) アドレスに解決する必要があります。 次のホスト (A) と (AAAA) リソース レコードが作成される必要があります。値が 127.0.0.1 のホスト (A) リソース レコードと、最後の 32 ビットを 127.0.0.1 として、値が NAT64 プレフィックスから構築されたホスト (AAAA) リソース レコード。 NAT64 プレフィックスは、Windows PowerShell コマンド get-netnattransitionconfiguration を実行して取得できます。
注意
これは IPv4 専用環境でのみ有効です。 IPv4 と IPv6、または IPv6 専用環境では、ホスト (AAAA) リソース レコードのみがループバック IP アドレス ::1 で作成される必要があります。
HTTP でその他の Web アドレスを使用して、または ping を使用して、その他の接続検証方法を作成できます。 接続検証方法ごとに、DNS エントリが存在している必要があります。
1.4.1 DNS サーバー要件を計画する
DirectAccess を展開するときの DNS の要件を次に示します。
DirectAccess クライアントの場合は、Windows Server 2012 R2、Windows Server 2012、Windows Server 2008 R2、Windows Server 2008、または IPv6 をサポートする任意の他の DNS サーバーを実行する DNS サーバーを使用する必要があります。
注意
DirectAccess をデプロイする場合は、Windows Server 2003 を搭載している DNS サーバーは使用しないことをお勧めします。 Windows Server 2003 の DNS サーバーは IPv6 のレコードをサポートしていますが、Microsoft による Windows Server 2003 のサポートは終了しています。 さらに、ファイル レプリケーション サービスでの問題のため、ドメイン コントローラーが Windows Server 2003 を搭載している場合は、DirectAccess をデプロイしないでください。 詳細については、「DirectAccess Unsupported Configurations (DirectAccess のサポートされない構成)」をご覧ください。
動的更新をサポートする DNS サーバーを使用します。 動的更新をサポートしない DNS サーバーも使用できますが、これらのサーバーはエントリを手動で更新する必要があります。
インターネットにアクセスできる CRL 配布ポイントの FQDN fは、インターネット DNS サーバーを使用して解決できる必要があります。 たとえば、URL https://crl.contoso.com/crld/corp-DC1-CA.crl が、DirectAccess サーバーの IP-HTTPS 証明書の CRL 配布ポイント フィールドにある場合は、インターネット DNS サーバーを使用して FQDN crld.contoso.com が解決できることを確認する必要があります。
1.4.2 ローカルでの名前解決を計画する
ローカルでの名前解決を計画している場合、次の問題を考慮してください。
NRPT
次の場合、追加的な NRPT 規則を作成する必要がある可能性があります。
イントラネット名前空間に DNS サフィックスを追加する必要がある場合。
CRL 配布ポイントの完全修飾ドメイン名 (FQDN) がイントラネット名前空間に基づく場合、CRL 配布ポイントの FQDN に除外規則を追加する必要があります。
スプリット ブレイン DNS 環境の場合、インターネットに配置した DirectAccess クライアントにイントラネット バージョンではなく、インターネット バージョンにアクセスさせるリソース名への除外規則を追加する必要があります。
イントラネット Web プロキシ サーバーで外部 Web サイトにトラフィックをリダイレクトしている場合、外部 Web サイトはイントラネットからのみ使用可能で、Web プロキシ サーバーのアドレスを使用して、着信要求を許可します。 この場合、外部 Web サイトの FQDN に除外規則を追加して、その規則がイントラネット DNS サーバーの IPv6 アドレスではなく、イントラネット Web プロキシ サーバーを使用する規則を指定します。
たとえば、test.contoso.com という外部 Web サイトをテストしている場合、この名前は、インターネット DNS サーバーでは解決できませんが、Contoso Web プロキシ サーバーは、名前を解決する方法を認識しており、Web サイトに対する要求を外部 Web サーバーに転送します。 Contoso イントラネット上にいないユーザーがサイトにアクセスするのを防ぐため、外部 Web サイトは Contoso Web プロキシの IPv4 インターネット アドレスからの要求のみを許可します。 このように、イントラネット ユーザーは Contoso Web プロキシを使用しているため、Web サイトにアクセスできますが、DirectAccess ユーザーは Contoso Web プロキシを使用していないため、Web サイトにアクセスできません。 Contoso Web プロキシを使用している test.contoso.com に NRPT 除外規則を構成することで、test.contoso.com に対する Web ページ要求は IPv4 インターネットでイントラネット Web プロキシ サーバーにルーティングされます。
単一ラベル名
https://paycheck などの単一ラベル名は、イントラネット サーバーに使用される場合があります。 単一ラベル名が要求され、DNS サフィックス検索一覧が構成されている場合、その一覧の DNS サフィックスが単一ラベル名に追加されます。 たとえば、Web ブラウザーで corp.contoso.com ドメインの種類 https://paycheck のメンバーであるコンピューターのユーザーの場合、名前として構成される FQDN は、paycheck.corp.contoso.com です。 既定で、追加されたサフィックスは、クライアント コンピューターのプライマリ DNS サフィックスに基づきます。
注意
不整合の名前空間というシナリオ (1 つ以上のドメイン コンピューターにそのコンピューターが属する Active Directory ドメインと一致しない DNS サフィックスがある場合)、検索一覧が要求されたサフィックスをすべて含むようにカスタマイズされていることを確認する必要があります。 既定で、リモート アクセス ウィザードはクライアントのプライマリ DNS サフィックスとして、Active Directory DNS 名を構成します。 クライアントによって名前解決に使用される DNS サフィックスを追加していることを確認します。
複数のドメインと Windows インターネット ネーム サービス (WINS) が組織で展開され、リモートで接続している場合、単一の名前は次のように解決できます。
WINS 前方参照ゾーンを DNS で展開します。 computername.dns.zone1.corp.contoso.com を解決しようとすると、要求はコンピューター名のみを使用している WINS サーバーに転送されます。 クライアントは、通常の DNS ホスト (A) リソース レコードを発行していると考えますが、実際には NetBIOS 要求です。 詳細については、「前方参照ゾーンの管理」を参照してください。
dns.zone1.corp.contoso.com などの DNS サフィックスを既定のドメイン ポリシー GPO に追加します。
スプリット ブレイン DNS
スプリット ブレイン DNS は、インターネットおよびイントラネットの名前解決に同じ DNS ドメインを使用します。
スプリット ブレイン DNS 展開では、Fqdn はインターネットとイントラネット上で重複され、対象のリソースを決定を一覧表示する必要があります、DirectAccess クライアントでは、リーチ、イントラネットまたはインターネット バージョンする必要があります。 DirectAccess クライアントがインターネット バージョンに到達するリソースに一致するそれぞれの名前について、対応する FQDN を DirectAccess クライアントの NRPT に対する除外規則として追加する必要があります。
スプリット ブレイン DNS 環境で、両方のバージョンのリソースを使用可能にする場合は、イントラネット リソースをインターネットで使用する名前の複製ではない代替名で構成し、ユーザーにイントラネットでは代替名を使用するように指示します。 たとえば、内部名 www.contoso.com の代替名 www.internal.contoso.com を構成します。
スプリット ブレインではない DNS 環境で、インターネット名前空間はイントラネット名前空間と異なります。 たとえば、Contoso Corporation はインターネットで contoso.com を使用していますが、イントラネットでは corp.contoso.com を使用しています。 すべてのイントラネット リソースは、corp.contoso.com DNS サフィックスを使用しているため、corp.contoso.com の NRPT 規則は、イントラネット リソースに対するすべての DNS 名クエリをイントラネット DNS サーバーにルーティングします。 contoso.com サフィックスの付いた名前に対する DNS 名クエリは、NRPT の corp.contoso.com イントラネット名前空間規則と一致しないため、インターネット DNS サーバーに送られます。 スプリット ブレインではない DNS 展開では、イントラネット リソースとインターネット リソースに対する FQDN の複製がないため、NRPT に対して追加の構成は必要ありません。 DirectAccess クライアントは、組織に対するインターネット リソースとイントラネット リソースの両方にアクセスできます。
DirectAccess クライアントに対するローカルでの名前解決動作
DNS の名前を解決できない場合、ローカル サブネット上の名前を解決するために、Windows Server 2012 R2、Windows Server 2012、Windows Server 2008 R2、Windows 8、Windows 7 の DNS クライアント サービスでは、リンク ローカル マルチキャスト名前解決 (LLMNR) および NetBIOS over TCP/IP プロトコルでローカルの名前解決を使用できます。
ローカルの名前解決は、通常、コンピューターが単一サブネットのホーム ネットワークなどのプライベート ネットワークに配置されている場合、ピアツーピア接続に必要です。 DNS クライアント サービスがイントラネット サーバー名に対するローカルの名前解決を実行し、コンピューターがインターネットで共有サブネットに接続されていると、悪意あるユーザーは LLMNR メッセージや NetBIOS over TCP/IP メッセージをキャプチャして、イントラネット サーバー名を判断できます。 インフラストラクチャ サーバーのセットアップ ウィザードの DNS ページで、イントラネット DNS サーバーから受け取った応答の種類に基づいて、ローカルの名前解決動作を構成します。 次のオプションを使用できます。
[名前が DNS に存在しない場合は、ローカルでの名前解決を行います]: このオプションは、DirectAccess クライアントがイントラネット DNS サーバーで解決できないサーバー名についてのみローカルの名前解決を実行するため、最も安全です。 イントラネット DNS サーバーに到達できれば、イントラネット サーバーの名前が解決されます。 イントラネット DNS サーバーに到達できない場合や、他の種類の DNS エラーがある場合に、イントラネット サーバー名がローカルの名前解決でサブネットに漏洩することはありません。
[名前が DNS に存在しない場合、またはクライアント コンピューターがプライベート ネットワーク上にあり、DNS サーバーが到達できない場合に、ローカルでの名前解決を行う (推奨)]: イントラネット DNS サーバーに到達できない場合のみ、プライベート ネットワークでローカルの名前解決の使用を許可するため、これは推奨オプションです。
[DNS 解決エラーが発生した場合は、その種類を問わず、ローカルでの名前解決を使用する (低セキュリティ)]: イントラネット ネットワーク サーバーの名前がローカルの名前解決でローカル サブネットに漏洩する可能性があるため、これは低セキュリティのオプションです。
1.5 ネットワーク ロケーション サーバーを計画する
ネットワーク ロケーション サーバーとは、DirectAccess クライアントが企業ネットワークに置かれているかどうかを検出するために使用する Web サイトです。 企業ネットワークのクライアントは、内部リソースに到達するために DirectAccess は使用せず、代わりに直接接続します。
ネットワーク ロケーション サーバー Web サイトは、DirectAccess サーバー、または組織内の別のサーバーでホストできます。 ネットワーク ロケーション サーバーを DirectAccess サーバーでホストすると、リモート アクセス サーバーの役割をインストールするときに、Web サイトが自動的に作成されます。 ネットワーク ロケーション サーバーを Windows オペレーティング システムを実行する組織内の別のサーバーでホストする場合、インターネット インフォメーション サービス (IIS) がそのサーバーにインストールされていて、Web サイトが作成されていることを確認する必要があります。 DirectAccess は、リモート ネットワーク ロケーション サーバー上の設定は構成しません。
ネットワーク ロケーション サーバー Web サイトが次の要件を満たしていることを確認してください。
HTTPS サーバー証明書のある Web サイトである。
DirectAccess クライアント コンピューターがネットワーク ロケーション サーバー Web サイトへのサーバー証明書を発行した CA を信頼している。
内部ネットワーク上の DirectAccess クライアント コンピューターは、ネットワーク ロケーション サーバー サイトの名前を解決できる。
ネットワーク ロケーション サーバー サイトに内部ネットワーク上のコンピューターへの高可用性がある。
ネットワーク ロケーション サーバーは、インターネット上の DirectAccess クライアント コンピューターにアクセス不能である。
サーバー証明書は CRL との一致が検証されている。
1.5.1 ネットワーク ロケーション サーバーの証明書を計画する
ネットワーク ロケーション サーバーに使用する Web サイト証明書を取得している場合は、次の点を考慮してください。
[サブジェクト] フィールドで、ネットワーク ロケーション サーバーのイントラネット インターフェイスの IP アドレス、またはネットワーク ロケーション URL の FQDN をを指定します。
[拡張キー使用法] フィールドに、サーバー認証 OID を使用します。
[CRL 配布ポイント] フィールドに、イントラネットに接続している DirectAccess クライアントがアクセスできる CRL 配布ポイントを使用します。 この CRL 配布ポイントは、内部ネットワークの外側からアクセスできないようにしてください。
1.5.2 ネットワーク ロケーション サーバーの DNS を計画する
DirectAccess クライアントは、内部ネットワークに配置されているかを判断するために、ネットワーク ロケーション サーバーに接続しようとします。 内部ネットワークのクライアントは、ネットワーク ロケーション サーバーの名前を解決できる必要がありますが、インターネット上に配置されている場合は、名前の解決を防ぐ必要があります。 これが確実に行われるように、既定で、ネットワーク ロケーション サーバーの FQDN が NRPT に対する除外規則として追加されます。
1.6 管理サーバーを計画する
DirectAccess クライアントは、Windows Update やウイルス対策の更新などのサービスを提供する管理サーバーとの通信を開始します。 DirectAccess クライアントは、Kerberos プロトコルも使用して、ドメイン コントローラーに接続し、内部ネットワークへのアクセス前に認証します。 DirectAccess クライアントのリモート管理中、管理サーバーはクライアント コンピューターと通信して、ソフトウェアやハードウェアのインベントリ評価などの管理機能を実行します。 リモート アクセスでは、次のような一部の管理サーバーが自動的に検出されます。
ドメイン コント ローラーでの自動検出のドメイン コント ローラーは、DirectAccess サーバーおよびクライアント コンピューターと同じフォレスト内のすべてのドメインに対して実行されます。
Microsoft Endpoint Configuration Manager での Configuration Manager サーバーのサーバー自動検出は、DirectAccess サーバーおよびクライアント コンピューターと同じフォレスト内のすべてのドメインに対して実行されます。
ドメイン コントローラーと Configuration Manager サーバーは、DirectAccess が最初に構成されたときに自動的に検出されます。 検出されたドメイン コント ローラーは、コンソールに表示されませんが、Windows PowerShell コマンドレットを使用して設定を取得することができます Get-damgmtserver-型すべてです。 ドメイン コントローラーまたは Configuration Manager サーバーが変更された場合、リモート アクセス管理コンソールで [管理サーバーの更新] をクリックすると、管理サーバーの一覧が更新されます。
管理サーバーの要件
管理サーバーは、最初の (インフラストラクチャ) トンネルでアクセスできる必要があります。 リモート アクセスを構成するときに、管理サーバーの一覧にサーバーを追加すると自動的にこのトンネルでアクセスできるようになります。
DirectAccess クライアントへの接続を開始する管理サーバーは、ネイティブ IPv6 アドレスによって、または ISATAP によって割り当てられたアドレスを使用して、IPv6 を完全にサポートする必要があります。
1.7 Active Directory ドメイン サービスを計画する
このセクションでは、DirectAccess で Active Directory ドメイン サービス (AD DS) がどのように使用されるかについて説明します。このトピックには次のサブセクションが含まれます。
DirectAccess は、次のような AD DS と Active Directory グループ ポリシー オブジェクト (Gpo) を使用します。
認証
AD DS は認証に使用されます。 インフラストラクチャ トンネルでは、DirectAccess サーバーに接続しているコンピューター アカウントに NTLMv2 認証が使用され、アカウントは Active Directory ドメインに表示されている必要があります。 イントラネット トンネルは、ユーザーが 2 番目のトンネルを作成する際に Kerberos 認証を使用します。
グループ ポリシー オブジェクト
DirectAccess は、構成設定を DirectAccess サーバー、クライアント、内部アプリケーション サーバーに適用される GPO に集めます。
セキュリティ グループ
DirectAccess は、セキュリティ グループを使用して、DirectAccess クライアント コンピューターを集めて識別します。 GPO は、必要なセキュリティ グループに適用されます。
拡張 IPsec ポリシー
DirectAccess では、クライアントと DirectAccess サーバーとの間に IPsec 認証と暗号化を使用できます。 IPsec 認証と暗号化をクライアントから指定した内部アプリケーション サーバーに拡張できます。 このためには、必要なアプリケーション サーバーをセキュリティ グループに追加します。
AD DS の要件
DirectAccess 展開に AD DS を計画している場合は、次の要件を考慮してください。
少なくとも 1 つのドメイン コント ローラーを、Windows Server 2016、Windows Server 2012 R2、Windows Server 2012、Windows Server 2008 R2、または Windows Server 2008 オペレーティング システムと共にインストールする必要があります。
ドメイン コントローラーが境界ネットワーク上にある場合 (そして、DirectAccess サーバーのインターネットに接続するネットワーク アダプターから到達可能な場合)、ドメイン コントローラー上にパケット フィルターを追加して、インターネット アダプターの IP アドレスへの接続を防ぐことで、DirectAccess サーバーによる到達を防止する必要があります。
DirectAccess サーバーはドメイン メンバーである必要があります。
DirectAccess クライアントは、ドメイン メンバーである必要があります。 クライアントは次に所属することができます。
DirectAccess サーバーと同じフォレスト内の任意のドメイン。
DirectAccess サーバー ドメインと双方向の信頼関係がある任意のドメイン。
DirectAccess ドメインが所属するフォレストと双方向の信頼関係があるフォレスト内の任意のドメイン。
注意
- DirectAccess サーバーはドメイン コントローラーになることができません。
- DirectAccess 用に使用される AD DS ドメイン コントローラーは、DirectAccess サーバーの外部インターネット アダプター (アダプターは Windows ファイアウォールのドメイン プロファイルにあってはいけません) からアクセスできてはいけません。
1.7.1 クライアント認証を計画する
DirectAccess では、IPsec コンピューター認証に証明書を使用するか、ユーザー名とパスワードを使用して認証する、組み込みの Kerberos プロキシを使用するかを選択できます。
認証に Ad DS 資格情報の使用を選択すると、DirectAccess はコンピューター Kerberos を使用する 1 つのセキュリティ トンネルを 1 番目の認証に使用し、ユーザー Kerberos を 2 番目の認証に使用します。 このモードを認証に使用する場合、DirectAccess は内部ネットワークで、DNS サーバー、ドメイン コントローラー、その他のサーバーへのアクセスを提供する単一のセキュリティ トンネルを使用します。
2 要素認証、またはネットワーク アクセス保護の使用を選択すると、DirectAccess では 2 つのセキュリティ トンネルが使用されます。 リモート アクセスのセットアップ ウィザードは、セキュリティが強化された Windows ファイアウォールの接続セキュリティ規則を構成します。この規則は、DirectAccess サーバーへのトンネルに関して IPsec セキュリティ アソシエーションとネゴシエートするときに、次の種類の資格情報の使用を指定します。
インフラストラクチャ トンネルは、1 番目の認証にコンピューター Kerberos 資格情報を使用し、2 番目の認証にユーザー Kerberos を使用します。
イントラネット トンネルは、1 番目の認証にコンピューター証明書資格情報を使用し、2 番目の認証にユーザー Kerberos を使用します。
DirectAccess で、Windows 7 を実行しているクライアントへのアクセスを許可することを選択する場合、または DirectAccess がマルチサイト展開内にある場合、2 つのセキュリティ トンネルが使用されます。 リモート アクセスのセットアップ ウィザードは、セキュリティが強化された Windows ファイアウォールの接続セキュリティ規則を構成します。この規則は、DirectAccess サーバーへのトンネルに関して IPsec セキュリティ アソシエーションとネゴシエートするときに、次の種類の資格情報の使用を指定します。
インフラストラクチャ トンネルは、1 番目の認証にコンピューター証明書資格情報を使用し、2 番目の認証に NTLMv2 を使用します。 NTLMv2 資格情報は、認証済みインターネット プロトコル (AuthIP) の使用を強制し、DirectAccess クライアントがイントラネット トンネルに Kerberos 資格認証を使用できるようになる前に、DNS サーバーとドメイン コントローラーへのアクセスを提供します。
イントラネット トンネルは、1 番目の認証にコンピューター証明書資格情報を使用し、2 番目の認証にユーザー Kerberos を使用します。
1.7.2 複数ドメインを計画する
管理サーバーの一覧には、DirectAccess クライアント コンピューターが含まれるセキュリティ グループを含むすべてのドメインのドメイン コントローラーが含まれます。 DirectAccess クライアントとして構成されたコンピューターを使用する可能性のあるユーザー アカウントを含むすべてのドメインを含む必要があります。 これにより、使用しているクライアント コンピューターと同じドメインに置かれていないユーザーは、ユーザー ドメインのドメイン コントローラーで認証されます。 ドメインが同じフォレストにあると、これは自動的に行われます。
注意
別のフォレストのクライアント コンピューター、またはアプリケーション サーバーが使用されているセキュリティ グループにコンピューターがある場合、これらのフォレストのドメイン コントローラーは自動的に検出されません。 リモート アクセス管理コンソールで [管理サーバーの更新] タスクを実行して、これらのドメイン コントローラーを検出できます。
可能な場合、リモート アクセス展開中に、共通のドメイン名サフィックスを名前解決ポリシー テーブル (NRPT) に追加する必要があります。 たとえば、domain1.corp.contoso.com と domain2.corp.contoso.com という 2 つのドメインがある場合、2 つのエントリを NRPT に追加する代わりに、corp.contoso.com というドメイン名サフィックスに共通の DNS サフィックス エントリを追加できます。 これは、同じルートのドメインでは自動的に行われますが、同じルートにないドメインの場合は、手動で追加する必要があります。
IWindows インターネット ネーム サービス (WINS) が複数ドメイン環境で展開されている場合、DNS で、WINS 前方参照ゾーンを展開する必要があります。 詳細については、次を参照してください。 単一ラベル名 で、 1.4.2 がローカルの名前解決を計画 このドキュメントの前半の「します。
1.8 グループ ポリシー オブジェクトを計画する
このセクションでは、リモート アクセス インフラストラクチャのグループ ポリシー オブジェクト (GPO) の役割について説明します。このトピックには次のサブセクションが含まれます。
リモート アクセスを構成するときに構成された DirectAccess 設定は、GPO に収集されます。 次の種類の GPO には、DirectAccess 設定が設定され、次のように分散されます。
DirectAccess クライアント GPO
この GPO には、IPv6 移行テクノロジ設定、NRPT エントリ、セキュリティが強化された Windows ファイアウォール接続セキュリティの規則を含むクライアント設定が含まれます。 GPO は、クライアント コンピューターに指定されたセキュリティ グループに適用されます。
DirectAccess サーバー GPO
この GPO には、展開で DirectAccess サーバーとして構成される任意のサーバーに適用される DirectAccess 構成設定が含まれます。 また、セキュリティが強化された Windows ファイアウォールの接続セキュリティの規則も含まれます。
アプリケーション サーバー GPO
この GPO には、DirectAccess クライアントから認証と暗号化をオプションで拡張した、選択したアプリケーション サーバーの設定が含まれます。 認証と暗号化が拡張されていない場合、この GPO は使用されません。
GPO は 2 つの方法で構成できます。
自動的に-それらが自動的に作成されることを指定することができます。 各 GPO には既定の名前が指定されます。
手動で-Active Directory 管理者によって事前に定義されている Gpo を使用することができます。
注意
特定の GPO を使用するように DirectAccess が構成された後で、別の GPO を使用するように構成することはできません。
GPO を自動で構成しているか、手動で構成しているかにかかわらず、クライアントで 3G ネットワークを使用する場合は、低速リンクの検出のためのポリシーを追加する必要があります。 [ポリシー:グループ ポリシーの低速リンクの検出を構成する] のパスは次のとおりです。コンピューターの構成/ポリシー/管理用テンプレート/システム/グループ ポリシー
注意事項
DirectAccess コマンドレットを実行する前に、すべてのリモート アクセス GPO をバックアップする手順は次のとおりです。Back up and Restore Remote Access Configuration (リモート アクセスの構成のバックアップと復元)
GPO のリンクのための正しいアクセス許可 (次のセクションに記載されているもの) が存在しない場合は、警告が発行されます。 リモート アクセスの操作は続行されますが、リンク処理は行われません。 この警告が発行されると、後でアクセス許可が追加されても、リンクは自動的に作成されなくなります。 代わりに、管理者がリンクを手動で作成する必要があります。
1.8.1 自動的に作成された GPO を構成する
自動的に作成された GPO を使用する場合、次の点を考慮してください。
自動的に作成された GPO は、次に示すように、場所とリンク先のパラメーターに基づいて適用されます。
DirectAccess サーバー GPO の場合、場所パラメーターとリンク パラメーターは、DirectAccess サーバーを含むドメインをポイントします。
クライアントとアプリケーション サーバー GPO が作成されると、場所は GPO が作成される単一のドメインに設定されます。 GPO 名は各ドメインで調べられ、存在する場合は、DirectAccess 設定が使用されます。 リンク先は GPO が作成されたドメインのルートに設定されます。 GPO はクライアント コンピューターまたはアプリケーション サーバーを含むドメインごとに作成され、その個々のドメインのルートにリンクされます。
自動的に作成された GPO を使用して DirectAccess 設定に適用する場合、リモート アクセス管理者には次のアクセス許可が必要です。
各ドメインに関する GPO 作成アクセス許可
選択したクライアント ドメイン ルートすべてに関するリンクするためのアクセス許可
サーバー GPO ドメイン ルートに関するリンクするためのアクセス許可
さらに、次のアクセス許可も必要です。
セキュリティの作成、編集、削除、および変更のアクセス許可が GPO には必要です。
リモート アクセス管理者には、必要なそれぞれのドメインに対する GPO 読み取りアクセス許可をお勧めします。 これによって、GPO の作成時に、重複する名前の GPO が存在しないことをリモート アクセスが確認できるようになります。
1.8.2 手動で作成した GPO を構成する
手動で作成した GPO を使用する場合、次の点を考慮してください。
GPO はリモート アクセス セットアップ ウィザードを実行する前に存在している必要があります。
DirectAccess 設定を適用する場合、リモートアクセス管理者は、手動で作成した GPO で完全な GPO アクセス許可 (編集、削除、変更のセキュリティのアクセス許可) が必要です。
GPO へのリンクについては、ドメイン全体で検索が行われます。 GPO がドメインでリンクされていないと、リンクはドメインのルートで自動的に作成されます。 リンクの作成に必要なアクセス許可が使用できない場合、警告が発行されます。
1.8.3 マルチドメイン コントローラー環境で GPO を管理する
各 GPO は、次のように特定のドメイン コントローラーによって管理されています。
サーバー GPO は、サーバーに関連付けられた Active Directory サイトでドメイン コントローラーのいずれかによって管理されています。 そのサイトのドメイン コントローラーが読み取り専用の場合、サーバー GPO は DirectAccess サーバーに最も近い書き込み可能のドメイン コントローラーによって管理されます。
クライアントとアプリケーション サーバー GPO は、プライマリ ドメイン コントローラー (PDC) として実行されているドメイン コントローラーによって管理されます。
GPO 設定を手動で変更する場合は、次の点を考慮してください。
サーバー GPO の場合、DirectAccess サーバーに関連付けられているドメイン コントローラーを識別するには、管理者特権のコマンド プロンプトから nltest /dsgetdc: /writable を実行します。
既定では、ネットワーキング Windows PowerShell コマンドレットで変更を加えるか、グループ ポリシー管理コンソールから変更を加えると、PDC として機能しているドメイン コントローラーが使用されます。
また、DirectAccess サーバー (サーバー GPO の場合) または PDC (クライアントとアプリケーション サーバー GPO の場合) に関連付けられたドメイン コントローラーではないドメイン コントローラーで設定を変更する場合は、次の点を考慮してください。
設定を変更する前に、ドメイン コントローラーが最新の GPO でレプリケートされ、GPO 設定がバックアップされていることを確認してください。 詳細については、次を参照してください。 をバックアップおよびリモート アクセスの構成を復元します。 GPO が更新されていない場合に、競合をマージすると、レプリケーションが行われている間に、リモート アクセス構成が破損する可能性があります。
設定を変更した後は、GPO に関連付けられたドメイン コントローラーに変更がレプリケートされるまで待つ必要があります。 レプリケーションが完了するまで、リモート アクセス管理コンソール、またはリモート アクセス PowerShell コマンドレットを使用してその他の変更を加えないでください。 レプリケーションが完了する前に、GPO が 2 つのドメイン コントローラーで編集された場合、マージ競合が発生し、リモート アクセス構成が破損する可能性があります。
または、グループ ポリシー管理コンソールの [ドメイン コントローラの変更] ダイアログ ボックス、または Windows PowerShell コマンドレット Open-NetGPO を使用して、変更で指定したドメイン コントローラーが使用されるように既定の設定を変更できます。
グループ ポリシー管理コンソールでこれを実行するには、ドメインまたはサイト コンテナーを右クリックして、[ドメイン コントローラの変更] をクリックします。
Windows PowerShell でこれを実行するには、Open-NetGPO コマンドレットで DomainController パラメーターを指定します。 たとえば、GPO の domain1\DA_Server_GPO _Europe という名前のドメインで、europe-dc.corp.contoso.com という名前のドメイン コントローラーを使用して、Windows ファイアウォールでプライベート プロファイルとパブリック プロファイルを有効にするには、次のように入力します。
$gpoSession = Open-NetGPO -PolicyStore "domain1\DA_Server_GPO _Europe" -DomainController "europe-dc.corp.contoso.com" Set-NetFirewallProfile -GpoSession $gpoSession -Name @("Private","Public") -Enabled True Save-NetGPO -GpoSession $gpoSession
1.8.4 アクセス許可が制限されたリモート アクセス GPO を管理する
リモート アクセス展開を管理するため、リモート アクセス管理者には、展開で使用する GPO に対する完全な GPO アクセス許可 (読み取り、編集、削除、変更のセキュリティのアクセス許可) が必要です。 これは、リモート アクセス管理コンソールとリモート アクセス PowerShell モジュールが構成を読み取って、リモート アクセス GPO (つまり、クライアント、サーバー、アプリケーション サーバー GPO) に書き込むためです。
多くの組織では、GPO 操作を担当するドメイン管理者はリモート アクセス構成を担当するリモート アクセス管理者と同じ人物ではありません。 このような組織には、リモート アクセス管理者がドメインの GPO に対するすべての権限を持つことを制限するポリシーがある可能性があります。 ドメイン管理者は、ドメインのコンピューターに適用する前に、ポリシー構成を確認する必要もある場合があります。
これらの要件に対応するため、ドメイン管理者は各 GPO にステージングと運用という 2 つのコピーを作成する必要があります。 リモート アクセス管理者は、ステージング GPO に対するすべての権限を与えられています。 リモート アクセス管理者は、リモート アクセス管理コンソールと Windows PowerShell コマンドレットで、リモート アクセス展開に使用する GPO としてステージング GPO を指定します。 これにより、リモート アクセス管理者は必要に応じて、リモート アクセス構成を読み取って変更できます。
ドメイン管理者は、ステージング GPO がドメインの管理の対象にリンクされていないこと、リモート アクセス管理者がドメインの GPO にリンクするためのアクセス許可がないことを確認する必要があります。 これにより、リモート アクセス管理者によってステージング GPO に対して行われた変更は、ドメインのコンピューターには影響がなくなります。
ドメイン管理者は、運用 GPO を必要な管理対象にリンクし、適切なセキュリティ フィルター処理を適用します。 これにより、これらの GPO に対する変更はドメインのコンピューター (クライアント コンピューター、DirectAccess サーバー、アプリケーション サーバー) に適用されます。 リモート アクセス管理者には、運用 GPO に対するアクセス許可はありません。
ステージング GPO に変更を加えた場合、ドメイン管理者は GPO でポリシー構成を確認し、組織のセキュリティ要件を満たしていることを確認できます。 その後で、ドメイン管理者はバックアップ機能を使用して、ステージング GPO から設定をエクスポートして、その設定をドメインのコンピューターに割り当てられる対応する運用 GPO にインポートします。
次の図はこの構成を示したものです。
1.8.5 削除された GPO から復元する
クライアント、DirectAccess サーバー、またはアプリケーション サーバー GPO が誤って削除され、使用できるバックアップがない場合、構成設定を削除して再構成する必要があります。 バックアップを使用できる場合は、バックアップから GPO を復元できます。
リモート アクセス管理コンソールに、エラー メッセージ "GPO (GPO 名) が見つかりません" が表示されます。 構成設定を削除するには、次の手順に従います。
Windows PowerShell コマンドレット Uninstall-remoteaccess を実行します。
リモート アクセス管理コンソールを開きます。
GPO が見つからないというエラー メッセージが表示されます。 [構成設定の削除] をクリックします。 完了後、サーバーは構成されていない状態で復元されます。