次の方法で共有

手順 1 リモート アクセス インフラストラクチャを計画する

注

Windows Server 2016 では、DirectAccess およびルーティングとリモート アクセス サービス (RRAS) は単一のリモート アクセスの役割に統合されています。

このトピックでは、DirectAccess クライアントのリモート管理用に 1 つのリモート アクセス サーバーをセットアップするために使用できるインフラストラクチャを計画するための手順について説明します。 次の表に手順を示しますが、これらの計画タスクを特定の順序で実行する必要はありません。

タスク 説明
ネットワーク トポロジとサーバー設定を計画する リモートアクセスサーバーを配置する場所 (ネットワークアドレス変換 (NAT) デバイスまたはファイアウォールの端または背後) を決定し、IP アドレス指定とルーティングを計画します。
ファイアウォールの要件を計画する エッジ ファイアウォール経由のリモート アクセスの許可を計画します。
証明書の要件を計画する クライアント認証にケルベロス認証プロトコルまたは証明書を使用するかどうかを決定し、Web サイト証明書を計画します。

IP-HTTPS は、IPv4 ネットワーク経由で IPv6 トラフィックをトンネリングするために DirectAccess クライアントによって使用される移行プロトコルです。 証明機関 (CA) によって発行された証明書を使用するか、リモート アクセス サーバーによって自動的に発行された自己署名証明書を使用して、サーバーの IP-HTTPS を認証するかを決定します。
DNS の要件を計画する リモート アクセス サーバーのドメイン ネーム システム (DNS) 設定、インフラストラクチャ サーバー、ローカルでの名前解決オプション、クライアント接続を計画します。
ネットワーク ロケーション サーバーの構成を計画する 組織でのネットワーク ロケーション サーバー Web サイトの配置場所 (リモート アクセス サーバーまたは代替サーバー) を決定し、ネットワーク ロケーション サーバーを リモート アクセス サーバー上に配置する場合の証明書要件を計画します。 ノート:ネットワーク ロケーション サーバーは、DirectAccess クライアントが内部ネットワーク上にあるかどうかを判断するために使用されます。
管理サーバーの構成を計画する リモート クライアント管理時に使用する管理サーバー (更新サーバーなど) を計画します。 ノート:管理者は、インターネットを使用して、企業ネットワークの外部にある DirectAccess クライアント コンピューターをリモートで管理できます。
Active Directory の要件を計画する ドメインコントローラー、Active Directory 要件、クライアント認証、および複数ドメイン構造を計画します。
グループ ポリシー オブジェクトの作成を計画 組織で必要な GPO と、GPO を作成および編集する方法を決定します。

ネットワークのトポロジと設定を計画する

ネットワークを計画するときは、ネットワーク アダプターのトポロジ、IP アドレスの設定、および ISATAP の要件を考慮する必要があります。

ネットワーク アダプターと IP アドレス指定を計画する

  1. 使用するトランスポート アダプター トポロジを特定します。 リモートアクセスは、次のトポロジのいずれかで設定できます。

    • 2 つのネットワーク アダプターがある場合、リモート アクセス サーバーはedgeにインストールされ、一方のネットワーク アダプターはインターネットに接続され、もう一方のネットワーク アダプターは内部ネットワークに接続されます。

    • 2 つのネットワークアダプターがある場合、リモートアクセスサーバーは NAT デバイス、ファイアウォール、またはルーターの背後にインストールされ、一方のネットワークアダプターは境界ネットワークに接続され、もう一方のネットワーク アダプターは内部ネットワークに接続されます。

    • 1 つのネットワーク アダプタを使用すると、リモート アクセス サーバーが NAT デバイスの背後にインストールされ、1 つのネットワーク アダプタが内部ネットワークに接続されます。

  2. IP アドレス指定要件を識別します。

    DirectAccess は、IPv6 と IPsec を組み合わせて、DirectAccess クライアント コンピューターと企業内部ネットワークとの間にセキュリティで保護された接続を確立します。 ただし、DirectAccess は、IPv6 インターネットへの接続または内部ネットワーク上でのネイティブ IPv6 サポートを必ずしも必要とはしません。 代わりに、IPv6 移行テクノロジを自動的に構成および使用して、IPv4 インターネット (6to4、Teredo、または IP-HTTPS) および IPv4 のみのイントラネット (NAT64または ISATAP) を介して IPv6 トラフィックをトンネリングします。 このような移行テクノロジの概要については、次のリソースを参照してください。

  3. 次の表に従って、必要なアダプターとアドレス指定を構成します。 1 つのネットワークアダプターを使用する NAT デバイスの背後にある展開の場合は、内部ネットワーク アダプター列のみを使用して IP アドレスを構成します。

    説明 外部ネットワーク アダプター 内部ネットワーク アダプター1、上記 ルーティングの要件
    IPv4 インターネットと IPv4 イントラネット 次を構成します。

    -適切なサブネット マスクを持つ 2 つの静的な連続したパブリック IPv4 アドレス(Teredoにのみ必要)。
    -インターネット ファイアウォールまたはローカル インターネットサービス プロバイダー (ISP) ルーターのデフォルト ゲートウェイ IPv4 アドレス。 ノート：リモート アクセス サーバーは、Teredo サーバーとして機能し、Windows ベースの Teredo クライアントがリモート アクセス サーバーを使用して NAT デバイスの種類を検出できるよう、2 つの連続するパブリック IPv4 アドレスを必要とします。    		 次を構成します。

    - 適切なサブネット マスクを持つ IPv4 イントラネット アドレス。
    - イントラネット名前空間の接続固有の DNS サフィックス。 DNS サーバーも、内部インターフェイスで構成する必要があります。 注意: イントラネット インターフェイスで、既定のゲートウェイを構成しません。    		 内部 IPv4 ネットワーク上のすべてのサブネットに到達するようにリモート アクセス サーバーを構成するには、次の手順を実行します。

    - イントラネット上のすべての場所の IPv4 アドレス空間を一覧表示します。
    - リモート アクセス サーバーの IPv 4 ルーティング テーブルに静的ルートとして IPv4 アドレス空間を追加するには、route add -pまたはnetsh interface ipv4 add routeコマンドを使用します。
    IPv6 インターネットおよび IPv6 イントラネット 次を構成します。

    - ISP が提供する自動構成されたアドレス構成を使用します。
    - route print コマンドを使って、ISP ルーターを示す既定の IPv6 ルートが IPv6 ルーティング テーブルにあることを確認します。
    -ISP とイントラネットルーターが、RFC 4191 に記載されている既定のルーター設定を使用しているかどうか、およびローカルイントラネットルーターよりも高い既定の設定を使用しているかどうかを確認します。 どちらについても使用している場合は、既定のルートに他の構成は必要ありません。 ISP ルーターの高度な基本設定によって、リモート アクセス サーバーの既定の IPv6 アクティブ ルートが IPv6 インターネットを示すことが保証されます。

    リモート アクセス サーバーは IPv6 ルーターであるため、ネィティブ IPv6 インフラストラクチャがある場合は、インターネット インターフェイスからイントラネット上のドメイン コントローラーに到達することもできます。 この場合は、リモート アクセス サーバーのインターネット インターフェイスの IPv 6 アドレスへの接続を阻止するパケット フィルターを境界ネットワークのドメイン コントローラーに追加します。    		 次を構成します。

    既定の基本設定レベルを使用していない場合は、netsh interface ipv6 set InterfaceIndex ignoredefaultroutes=enabledコマンドを使用して、イントラネット インターフェイスを構成します。 このコマンドにより、イントラネット ルーターをポイントする追加の既定のルートは IPv6 ルーティング テーブルに追加されなくなります。 イントラネット インターフェイスの InterfaceIndex は、netsh interface show interfaceコマンドの表示から取得できます。    		 IPv6 イントラネットがある場合、IPv6 のすべての場所に到達できるようにリモート アクセス サーバーを構成するには、次のようにします。

    - イントラネット上のすべての場所の IPv6 アドレス空間を一覧表示します。
    - netsh interface ipv6 add routeコマンドを使用して、IPv6 アドレス スペースをリモート アクセス サーバーの IPv6 ルーティング テーブルに静的ルートとして追加します。
    IPv4 インターネットおよび IPv6 イントラネット リモート アクセス サーバーは、Microsoft 6 to 4 アダプター インターフェイスを使用して、IPv4 インターネット上の6 to 4リレーにデフォルトのIPv6 ルートトラフィックを転送します。 ネイティブ IPv6 が企業ネットワークに展開されていない場合は、次のコマンドを使用して、IPv4 インターネット上の Microsoft 6to4 リレーの IPv4 アドレス用にリモート アクセス サーバーを構成できますnetsh interface ipv6 6to4 set relay name=<ipaddress> state=enabled。

    注

    • DirectAccess クライアントにパブリック IPv4 アドレスが割り当てられている場合、6 to 4 リレー テクノロジーを使用してイントラネットに接続します。 クライアントにプライベート IPv4 アドレスが割り当てられると、Teredo が使用されます。 DirectAccess クライアントが 6to4 または Teredo を使用して DirectAccess サーバーに接続できない場合は、IP-HTTPS が使用されます。
    • Teredo を使用するには、外部ネットワーク アダプターで連続する 2 つの IP アドレスを構成する必要があります。
    • リモート アクセス サーバーにネットワークアダプターが 1 つしかない場合、Teredo を使用することはできません。
    • ネイティブ IPv6 クライアント コンピューターは、ネイティブ IPv6 経由でリモート アクセス サーバーに接続できます。移行テクノロジを必要としません。

ISATAP 要件を計画する

DirectAccess 管理サーバーがインターネット上にある DirectAccess クライアントに接続できるように、DirectAccessclients のリモート管理には ISATAP が必要です。 ISATAP は、DirectAccess クライアント コンピューターによって開始される企業ネットワーク上の IPv4 リソースへの接続をサポートする必要はありません。 この目的には、NAT64/DNS64 が使用されます。 展開に ISATAP が必要な場合は、次の表を使用して要件を特定します。

ISATAP 展開シナリオ 要件
既存のネイティブ IPv 6 イントラネット (ISATAP は不要) 既存のネイティブ IPv6 インフラストラクチャでは、リモート アクセスの展開中に組織のプレフィックスを指定し、リモート アクセスサーバーはそれ自体を ISATAP ルーターとして構成しません。 次の操作を行います。

1. DirectAccess クライアントがイントラネットからアクセスできるようにするには、既定のルート トラフィックがリモート アクセス サーバーに転送されるように IPv6 ルーティングを変更する必要があります。 イントラネットの IPv6 アドレス空間が、1 つの 48 ビット IPv6 アドレス プレフィックス以外のアドレスを使用している場合は、展開時に関連する組織の IPv6 プレフィックスを指定する必要があります。
2. 現在 IPv 6 インターネットに接続している場合は、既定のルート トラフィックがリモート アクセス サーバーに転送されるように構成し、既定のルート トラフィックが IPv 6 インターネットに接続されているデバイスに転送されるように、リモート アクセス サーバーで適切な接続とルートを構成する必要があります。
既存の ISATAP 展開 既存の ISATAP インフラストラクチャがある場合、展開中に組織の 48 ビットプレフィックスの入力を求められ、リモートアクセスサーバーはそれ自体を ISATAP ルーターとして構成しません。 DirectAccess クライアントがイントラネットからアクセスできるようにするには、既定のルート トラフィックがリモート アクセス サーバーに転送されるように IPv6 ルーティング インフラストラクチャを変更する必要があります。 この変更は、イントラネット クライアントがすでにデフォルトのトラフィックを転送している必要がある既存の ISATAP ルーターで行う必要があります。
既存の IPv6 接続がありません リモート アクセス セットアップ ウィザードは、サーバーにネイティブまたは ISATAP ベースの IPv6 接続がないことを検出すると、イントラネット用の6 to 4ベースの 48 ビットプレフィックスを自動的に取得し、リモート アクセスサーバーを ISATAP ルーターとして構成して、イントラネット上の ISATAP ホストに IPv6 接続を提供します。 (6to4 ベースのプレフィックスは、サーバーにパブリック アドレスがある場合にのみ使用されます。それ以外の場合は、規則的なローカル アドレス範囲からプレフィックスが自動的に生成されます。)

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

1. ISATAP ベースの接続を有効にする各ドメインの ISATAP 名を DNS サーバーに登録します。これにより、ISATAP 名が内部 DNS サーバーによってリモート アクセス サーバーの内部 IPv4 アドレスに解決できるようになります。
2. 既定では、Windows Server 2012、Windows Server 2008 R2、Windows Server 2008、またはWindows Server 2003 を実行している DNS サーバーは、グローバ ルクエリ ブロック リストを使用して ISATAP 名の解決をブロックします。 ISATAP を有効にするには、ブロック リストから ISATAP 名を削除する必要があります。 詳細については、「DNS グローバル クエリ ブロック リストからの ISATAP の削除」を参照してください。

ISATAP 名を解決できる Windows ベースの ISATAP ホストは、リモート アクセス サーバーで次のようにアドレスを自動的に構成します。

1. ISATAP トンネリング インターフェイスの ISATAP ベースの IPv6 アドレス
2. イントラネット上の他の ISATAP ホストへの接続を提供する 64 ビット ルート
3. リモート アクセス サーバーを指す既定の IPv6 ルート。 既定ルートにより、イントラネット ISATAP ホストが DirectAccess クライアントに到達できるようになります

Windows ベースの ISATAP ホストが ISATAP ベースの IPv6 アドレスを取得すると、送信先が ISATAP ホストでもある場合、ISATAP でカプセル化されたトラフィックを使用して通信が開始します。 ISATAP ではイントラネット全体に 1 つの 64 ビットのサブネットが使用されるため、通信はセグメント化された IPv4 モデルの通信から、IPv6 を使用した 1 つのサブネット通信モデル移行します。 これは、Active Directory Domain Services (AD DS) の一部や、Active Directory Domain Servicesの構成に依存するアプリケーションの動作に影響を与える可能性があります。 たとえば、Active Directory サイトとサービス スナップ インを使用して、サイト、IPv4 ベースのサブネット、サイト内のサーバーに要求を転送するサイト間トランスポートを構成した場合、この構成は ISATAP ホストでは使用されません。

  1. ISATAP ホストのサイト内で転送するように Active Directory サイトとサービスを構成するには、各 IPv4 サブネット オブジェクトに対して、同等の IPv6 サブネットオブジェクトを構成する必要があります。このサブネットの IPv6 アドレス プレフィックスは、IPv4 サブネットと同じ範囲の ISATAP ホスト アドレスを表します。 たとえば、IPv4 サブネット 192.168.99.0/24 と 64 ビット ISATAP アドレス プレフィックス 2002: 836b:1:8000::/64 の場合、IPv6 サブネット オブジェクトの同等の IPv6 アドレス プレフィックスは、2002: 836b:1:8000:0:5efe:192.168.99.0/120 になります。 任意の IPv4 プレフィックス長 (例では 24 に設定) の場合、式 96 + IPv4PrefixLength から対応する IPv6 プレフィックス長を決定できます。
  2. DirectAccess クライアントの IPv6 アドレスには、次のものを追加します。

    • Teredo ベースの DirectAccess クライアントの場合 2001:0:WWXX:YYZZ::/64 の範囲の IPv6 サブネット。WWXX:YYZZ は、リモート アクセス サーバーの最初のインターネットに接続された IPv4 アドレスのコロン 16 進数バージョンです。 =
    • IP-HTTPS ベースの DirectAccess クライアントの場合 2002:WWXX:YYZZ:8100::/56 の範囲の IPv6 サブネット。WWXX:YYZZ は、リモートアクセスサーバーの最初のインターネット向け IPv4 アドレス (w.x.y.z) のコロン区切りの 16 進数バージョンです。 =
    • 6to4 ベースの DirectAccess クライアントの場合 2002 で始まる一連の 6to4 ベースの IPv6 プレフィックス。インターネット割り当て番号機関 (IANA) と地域レジストリによって管理される地域のパブリック IPv4 アドレス プレフィックスを表します。 パブリック IPv4 アドレス プレフィックス w.x.y.z/n の 6to4 ベースのプレフィックスは、2002:WWXX:/[16 + n] です。この場合、WWXX:YYZZ は w.x.y.z のコロン 16 進数バージョンです。

      たとえば、7.0.0.0/8という範囲は、北米向けの米国インターネット番号登録 (ARIN) によって管理されています。 このパブリック IPv6 アドレス範囲に対応する 6to4 ベースのプレフィックスは 2002:700::/24 です。 IPv4 パブリック アドレス スペースについては、IANA IPv4 アドレス スペース レジストリを参照してください。 =

重要

DirectAccess サーバーの内部インターフェイスにパブリック IP アドレスがないことを確認してください。 内部インターフェイスにパブリック IP アドレスがある場合、ISATAP 経由の接続に失敗する可能性があります。

ファイアウォールの要件を計画する

エッジ ファイアウォールの背後に設置されたリモート アクセス サーバーが IPv4 インターネット上にあるときは、リモート アクセス トラフィックについて次の例外が必要になります。

  • IP-HTTPS の場合は、伝送制御プロトコル (TCP) 宛先ポート 443、およびTCP送信元ポート443が発信です。

  • Teredo トラフィックの場合は、ユーザー データグラム プロトコル (UDP) 宛先ポート 3544 受信と、UDP 発信元ポート 3544 送信。

  • 6to4 トラフィックの場合は、IP プロトコル 41 の受信と送信。

    注

    Teredo トラフィックと 6to4 トラフィックの場合、これらの例外は、リモート アクセス サーバー上のインターネットに接続された両方の連続するパブリック IPv4 アドレスに適用する必要があります。

    IP-HTTPS では、パブリック DNS サーバーに登録されているアドレスに例外を適用する必要があります。

  • 1 つのネットワーク アダプターで リモート アクセスを展開し、Remote Access サーバーにネットワークロケーションサーバーをインストールする場合は、TCP ポート 62000 です。

    注

    この除外項目はリモート アクセス サーバーにあり、これまでの除外項目はedgeファイアウォールにあります。

リモート アクセス サーバーが IPv6 インターネット上にある場合は、リモート アクセスのトラフィックには以下のような例外が必要です。

  • IP プロトコル 50

  • UDP 宛先ポート 500 の受信と、UDP 発信元ポート 500 の送信。

  • ICMPv6 トラフィックの受信と発信 (Teredo使用時のみ)。

追加のファイアウォールを使用する場合は、リモート アクセス トラフィックに次の内部ネットワーク ファイアウォール例外を適用します。

  • ISATAP の場合は、プロトコル 41 の受信と送信

  • すべての IPv 4/IPv 6 トラフィック、TCP/UD の場合

  • Teredo の場合は、すべての IPv4/IPv6 トラフィックに対して ICMP

証明書の要件を計画する

1 台のリモート アクセス サーバーを導入する際に、証明書が必要となるシナリオは 3 つあります。

  • IPsec 認証IPsecの証明書の要件には、DirectAccessクライアントコンピューターがリモートアクセスサーバーとのIPsec接続を確立するときに使用するコンピューター証明書と、リモート アクセス サーバーがDirectAccessクライアントとのIPsec接続を確立するために使用するコンピューター証明書が含まれます。

    Windows Server 2012 の DirectAccess では IPsec 証明書の使用は必須ではありません。 また、リモート アクセス サーバーは、証明書を必要としない Kerberos 認証のプロキシとして機能することもできます。 Kerberos 認証を使用する場合は、SSL で動作し、Kerberos プロトコルは IP-HTTPS 用に設定された証明書を使用します。 一部の企業のシナリオ (マルチサイトの展開やワンタイムパスワードによるクライアント認証など) では、Kerberos 認証ではなく、証明書認証の使用が必要となります。

  • IP-HTTPS サーバーリモート アクセスを設定すると、リモート アクセス サーバーは IP-HTTPS Web リスナーとして動作するように自動的に設定されます。 IP-HTTPS サイトは Web サイト証明書を要求します。また、クライアント コンピューターは、その証明書の証明書失効リスト (CRL) サイトに接続できる必要があります。

  • ネットワーク ロケーション サーバーは、クライアント コンピューターが企業ネットワーク内にあるかどうかを検出するために使用される Web サイトです。 ネットワーク ロケーション サーバーには、web サイトの証明書が必要です。 DirectAccess クライアントは、その証明書の CRL サイトに接続できる必要があります。

これらの各シナリオにおける認証局(CA)の要件を以下の表にまとめました。

IPsec 認証 IP-HTTPS サーバー ネットワーク ロケーション サーバー
認証に Kerberos プロトコルを使用しない場合、IPsec 認証用のコンピュータ証明書をリモート アクセス サーバーとクライアントに発行するために、内部 CA が必要になります。 内部認証局 (CA) の場合は、内部 CA を使用して IP-HTTPS 証明書を発行できます。ただし、CRL 配布ポイントが外部で使用可能であることを確認する必要があります。 内部 CA は、ネットワーク ロケーション サーバの Web サイト証明書の発行に使用できます。 CRL 配布ポイントが内部ネットワークからいつでも利用できることを確認してください。
自己署名証明書の場合は、IP-HTTPS サーバに自己署名証明書を使用できます。 自己署名証明書はマルチサイト展開で使用できません。 自己署名証明書、ネットワークロケーションサーバ Web サイトに自己署名証明書を使用できます。ただし、マルチサイト展開では自己署名証明書を使用できません。
パブリック CA、CRL 配布ポイントを外部から使用できるようにするため、パブリック CA を使用して IP-HTTPS 証明書を発行することをお勧めします。

IPsec 認証にコンピューター証明書を計画する

証明書に基づく IPsec 認証を使用している場合、リモート アクセス サーバーとクライアントは、コンピューター証明書を入手する必要があります。 証明書をインストールする最も簡単な方法は、グループ ポリシーを使用して、コンピューター証明書の自動登録を構成することです。 こうすることによって、すべてのドメイン メンバーがエンタープライズ CA から証明書を入手します。 エンタープライズ CA を組織内の設定があるない場合は、次を参照してください。Active Directory Certificate Servicesです。

この証明書には、次の要件があります。

  • 証明書には、クライアント認証用の拡張キー使用法 EKU (Extended Key Usage) が含まれている必要があります。

  • クライアント証明書とサーバー証明書は、同じルート証明書に関連付けられている必要があります。 このルート証明書は、DirectAccess 構成設定で選択されている必要があります。

IP-HTTPS の証明書を計画する

リモート アクセス サーバーは IP-HTTPS リスナーとして動作します。HTTPS Web サイト証明書をサーバーに手動でインストールする必要があります。 計画するときは、次の点を考慮してください。

  • CRL がすぐに使用できるように、パブリック CA を使用することをお勧めします。

  • サブジェクト フィールドには、リモート アクセス サーバーのインターネット アダプターの IPv4 アドレスまたは IP-HTTPS URL の FQDN (ConnectTo アドレス) を指定します。 リモート アクセス サーバーが NAT デバイスの内側に存在する場合は、NAT デバイスのパブリック名またはアドレスを指定する必要があります。

  • 証明書の共通名は、IP-HTTPS サイトの名前と一致している必要があります。

  • 拡張キー使用法 フィールドに、サーバー認証オブジェクト識別子 (OID) を使用します。

  • [CRL 配布ポイント] フィールドに、インターネットに接続している DirectAccess クライアントがアクセスできる CRL 配布ポイントを指定します。

    注

    これは Windows 7を使用しているクライアントの場合のみ必要です。

  • IP-HTTPS 証明書には秘密キーが必要です。

  • IP-HTTPS 証明書は、個人用ストアに直接インポートする必要があります。

  • IP-HTTPS 証明書の名前にはワイルドカードを含めることができます。

ネットワーク ロケーション サーバーの Web サイト証明書を計画する

ネットワーク ロケーション サーバーのウェブサイトを企画する際には、以下の点を考慮してください。

  • [サブジェクト] フィールドで、ネットワーク ロケーション サーバーのイントラネット インターフェイスの IP アドレス、またはネットワーク ロケーション URL の FQDN をを指定します。

  • 拡張キー使用法フィールドには、サーバー認証 OID を使用します。

  • CRL 配布ポイントフィールドには、イントラネットに接続されている DirectAccess クライアントからアクセスできる CRL 配布ポイントを使用します。 この CRL 配布ポイントは、内部ネットワークの外側からアクセスできないようにしてください。

注

IP-HTTPS とネットワーク ロケーション サーバーの証明書にサブジェクト名があることを確認してください。 証明書に別の名前が使われていると、リモート アクセス ウィザードでは受け付けられません。

DNS の要件を計画する

このセクションでは、リモート アクセス展開する際のクライアントとサーバーの DNS 要件について説明します。

DirectAccess クライアント要求

内部ネットワークに配置されていない DirectAccess クライアント コンピューターからの要求を解決するためには、DNS が使用されます。 DirectAccess クライアントは、DirectAccess ネットワーク ロケーション サーバーへの接続を試み、インターネット上にあるのか、企業ネットワーク上にあるのかを判断します。

  • 接続に成功した場合、クライアントはイントラネット上にあると判断され、DirectAccess は使用されず、クライアントのリクエストは、クライアント コンピュータのネットワーク アダプターに設定された DNS サーバーを使用して解決されます。

  • 接続に失敗した場合、クライアントはインターネット上にあると見なされます。 DirectAccess クライアントは名前解決ポリシー テーブル (NRPT) を使って、名前の要求を解決するときに使用する DNS サーバーを判断します。 クライアントが名前解決に DirectAccess DNS64 または代替の内部 DNS サーバーを使用するように指定することができます。

名前解決の実行時、NRPT が DirectAccess クライアントによって使用されて、要求の処理方法が特定されます。 クライアントは、FQDN または<https://internal>などの 1 つのラベル名を要求します。 シングルラベル名が要求されると、DNS サフィックスが追加されて FQDN になります。 DNS クエリが NRPT のエントリーにマッチし、そのエントリーに DNS4 またはイントラネットの DNS サーバーが指定されている場合、クエリは指定されたサーバーを使用して名前解決のために送信されます。 一致が存在するが、DNS サーバーが指定されていない場合、これは除外規則が適用され、通常の名前解決が行われます。

リモートアクセス管理コンソールで新しいサフィックスを NRPT に追加した場合、[検出] ボタンをクリックすると、サフィックスの既定の DNS サーバーを自動的に検出できます。 自動検出は以下のように行われます。

  • 企業ネットワークが IPv4 ベースの場合、または IPv4 と IPv6 を使用している場合は、既定のアドレスは、リモート アクセス サーバーの内部アダプターの DNS64 アドレスです。

  • 企業ネットワークが IPv6 ベースである場合、既定のアドレスは、企業ネットワーク内の DNS サーバーの IPv6 アドレスです。

インフラストラクチャ サーバー

  • ネットワーク ロケーション サーバー

    DirectAccess クライアントは、内部ネットワークに配置されているかを判断するために、ネットワーク ロケーション サーバーに接続しようとします。 内部ネットワーク上のクライアントは、ネットワーク ロケーション サーバーの名前解決をしなければなりません。また、それらがインターネット上にある場合は、名前解決できないようにする必要があります。 これが確実に行われるように、既定で、ネットワーク ロケーション サーバーの FQDN が NRPT に対する除外規則として追加されます。 また、リモート アクセスを構成する場合、次の規則が自動的に作成されます。

    • リモート アクセス サーバーのルート ドメインまたはドメイン名の DNS サフィックスルール、およびリモート アクセス サーバーに構成されているイントラネット DNS サーバーに対応する IPv6 アドレス。 たとえば、リモート アクセス サーバーが corp.contoso.com ドメインのメンバーである場合、corp.contoso.com DNS サフィックスについて規則が作成されます。

    • ネットワーク ロケーション サーバーの FQDN の除外規則。 たとえば、ネットワーク ロケーション サーバーの URL がの場合https://nls.corp.contoso.com、FQDN nls.corp.contoso.com に対して除外規則が作成される。

  • IP-HTTPS サーバー

    リモート アクセス サーバーは IP-HTTPS リスナーとして機能し、そのサーバー証明書を使用して IP-HTTPS クライアントを認証します。 IP-HTTPS 名は、パブリック DNS サーバーを使用する DirectAccess クライアントが解決できるものでなければなりません。

接続検証方法

リモート アクセスでは、DirectAccess クライアント コンピューターが内部ネットワークへの接続の検証に使用する既定の Web プローブが作成されます。 プローブを意図したとおりに機能させるには、DNS で次の名前を手動で登録する必要があります。

  • directaccess-webprobehostは、リモートアクセスサーバーの内部 IPv4 アドレス、またはIPv6のみの環境ではIPv6アドレスに解決する必要があります。

  • directaccess-corpconnectivityhostは、ローカル ホスト (ループバック) アドレスに解決する必要があります。 A レコードと AAAA レコードを作成する必要があります。 A レコードの値は 127.0.0.1 で、AAAA レコードの値は、最後の 32 ビットが 127.0.0.1 の NAT64 プレフィックスから構築されます。 NAT 64 プレフィックスは、Get-netnatTransitionConfiguration Windows PowerShell コマンドレットを実行することで取得できます。

    注

    これは IPv4 専用環境でのみ有効です。 IPv4+IPv6または IPv6 のみの環境では、ループバック IP アドレス ::1 を持つ AAAA レコードだけを作成します。

HTTP または PING で他の Web アドレスを使用して、追加の接続検証を作成できます。 接続検証方法ごとに、DNS エントリが存在している必要があります。

DNS サーバーの要件

  • DirectAccess クライアントの場合は、Windows Server 2012、Windows Server 2008 R2、Windows Server 2008、Windows Server 2003、または IPv 6 に対応した DNS サーバーを使用する必要があります。

  • 動的更新をサポートする DNS サーバーを使用します。 動的更新をサポートしていない DNS サーバーを使用することもできますが、その場合は手動でエントリーを更新する必要があります。

  • CRL 配布ポイントの FQDN は、インターネット DNS サーバーを使用して解決する必要があります。 たとえば、URL https://crl.contoso.com/crld/corp-DC1-CA.crl が、リモート アクセス サーバーの IP-HTTPS 証明書の CRL 配布ポイント フィールドにある場合は、FQDN crld.contoso.com がインターネット DNS サーバーを使用して解決可能であることを確認する必要があります。

ローカルでの名前解決を計画

ローカルの名前解決を計画する場合は、次の点を考慮してください。

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 サフィックスが単一ラベル名に追加されます。 たとえば、corp.contoso.com ドメインのメンバーであるコンピューター上のユーザーが Web ブラウザーで<https://paycheck>を入力した場合、名前として構築される FQDN は paycheck.corp.contoso.com です。 既定で、追加されたサフィックスは、クライアント コンピューターのプライマリ DNS サフィックスに基づいています。

注

分離した名前空間のシナリオ (1 台以上のドメインコンピューターに、そのコンピューターがメンバーとなっている Active Directory ドメインと一致しない DNS サフィックスがある場合) では、必要なサフィックスがすべて含まれるように検索一覧をカスタマイズする必要があります。 既定で、リモート アクセス ウィザードはクライアントのプライマリ DNS サフィックスとして、Active Directory DNS 名を構成します。 クライアントによって名前解決に使用される DNS サフィックスを追加していることを確認します。

組織内に複数のドメインと Windows インターネットネームサービス (WINS) が導入されていて、リモートで接続している場合、単一名は以下のように解決できます。

  • DNS に WINS 前方参照ゾーンを展開する。 computername.dns.zone 1.corp.contoso.com を解決しようとすると、そのコンピュータ名だけを使用するWINSサーバーに要求が送信されます。 クライアントは、通常の DNS A レコード要求を発行していると考えますが、実際には NetBIOS の要求です。

    詳細については、「前方参照ゾーンの管理」を参照してください。

  • 既定のドメイン GPO に DNS サフィックス (たとえば、dns.zone1.corp.contoso.com) を追加します。

スプリット ブレイン DNS

スプリット ブレイン DNS とは、インターネットとイントラネットの名前解決に同じ DNS ドメインを使用することです。

スプリット ブレイン DNS 展開では、Fqdn はインターネットとイントラネット上で重複され、対象のリソースを決定を一覧表示する必要があります、DirectAccess クライアントでは、リーチ、イントラネットまたはインターネット バージョンする必要があります。 DirectAccess クライアントがインターネット版に到達するためには、各リソースの NRPT に対応する FQDN を除外規則として追加する必要があります。

スプリットブレイン DNS 環境で、両方のバージョンのリソースを利用したい場合は、イントラネットのリソースを、インターネットで使用されている名前と重複しない名前で構築してください。 そして、ユーザーがイントラネット上のリソースにアクセスする際には、代替名を使用するように指示します。 例えば、www.internal.contoso.com には www.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、Windows 8、Windows Server 2008 R2、Windows 7 の DNS クライアントサービスは、Link-Local Multicast Name Resolution(LLMNR) と NetBIOS over TCP/IP プロトコルを使用して、ローカルサブネット上で名前解決できます。 ローカルの名前解決は、通常、コンピューターが単一サブネットのホーム ネットワークなどのプライベート ネットワークに配置されている場合、ピアツーピア接続に必要です。

DNS クライアント サービスがイントラネット サーバー名のローカル名前解決を実行し、コンピューターがインターネット上の共有サブネットに接続されている場合、悪意のあるユーザーがLLMNRおよびNetBIOS over TCP/IPメッセージを取得して、イントラネットサーバー名を特定する可能性があります。 インフラストラクチャ サーバー セット アップ ウィザードの DNS ページでは、イントラネット DNS サーバーから受信した応答の種類に基づいて、ローカルの名前解決の動作を構成できます。 次のオプションを使用できます。

  • 名前が DNS に存在しない場合、ローカル名前解決を使用する。このオプションは、イントラネットの DNS サーバーで解決できないサーバー名に対してのみ DirectAccess クライアントがローカルの名前解決を行うため、最も安全です。 イントラネット DNS サーバーに到達できれば、イントラネット サーバーの名前が解決されます。 イントラネット DNS サーバーに到達できない場合や、他の種類の DNS エラーがある場合に、イントラネット サーバー名がローカルの名前解決でサブネットに漏洩することはありません。

  • クライアントコンピューターがプライベートネットワーク上にあるときに、DNS に名前が存在しない場合や DNS サーバーにアクセスできない場合は、ローカル名前解決を使用します (推奨) このオプションは、イントラネット DNS サーバーにアクセスできない場合にのみプライベートネットワーク上でローカル名前解決を使用できるので推奨されています。

  • あらゆる種類の DNS 解決エラーにローカルの名前解決を使用する (セキュリティレベルが最も低い) これは、イントラネットネットワークサーバーの名前がローカルの名前解決を介してローカルサブネットに漏れる可能性があるため、セキュリティレベルが最も低いオプションです。

ネットワーク ロケーション サーバーの構成を計画

ネットワーク ロケーション サーバーとは、DirectAccess クライアントが企業ネットワークに置かれているかどうかを検出するために使用する Web サイトです。 企業ネットワーク内のクライアントは、DirectAccess を使って内部リソースにアクセスするのではなく、直接接続します。

ネットワーク ロケーション サーバーの web サイトは、リモート アクセス サーバーまたは組織内の別のサーバーでホストできます。 ネットワーク ロケーション サーバーをリモート アクセスサーバーでホストする場合は、リモート アクセスの展開時に Web サイトが自動的に作成されます。 Windows オペレーティング システムを実行している別のサーバーでネットワーク ロケーション サーバーをホストする場合は、そのサーバーにインターネット インフォメーション サービス (IIS) がインストールされ、Web サイトが作成されていることを確認する必要があります。 リモートアクセスでは、ネットワーク ロケーション サーバーの設定が行われません。

ネットワーク ロケーション サーバー Web サイトが次の要件を満たしていることを確認してください。

  • HTTPS サーバー証明書があります。

  • 内部ネットワーク上のコンピューターに高い可用性を提供します。

  • インターネット上の DirectAccess クライアント コンピューターにはアクセスできません。

また、ネットワーク ロケーション サーバーの Web サイトを設定するときは、クライアントに関する次の要件を考慮してください。

  • DirectAccess クライアント コンピューターがネットワーク ロケーション サーバー Web サイトへのサーバー証明書を発行した CA を信頼している。

  • 内部ネットワーク上の DirectAccess クライアント コンピューターは、ネットワーク ロケーション サーバー サイトの名前を解決できる。

ネットワーク ロケーション サーバーの証明書を計画する

ネットワーク ロケーション サーバーに使用する Web サイト証明書を取得している場合は、次の点を考慮してください。

  • [サブジェクト] フィールドで、ネットワーク ロケーション サーバーのイントラネット インターフェイスの IP アドレス、またはネットワーク ロケーション URL の FQDN を指定します。

  • 拡張キー使用法フィールドには、サーバー認証 OID を使用します。

  • ネットワーク ロケーションサーバ証明書は、証明書失効リスト (CRL) と照合する必要があります。 CRL 配布ポイントフィールドには、イントラネットに接続されている DirectAccess クライアントからアクセスできる CRL 配布ポイントを使用します。 この CRL 配布ポイントは、内部ネットワークの外側からアクセスできないようにしてください。

ネットワーク ロケーション サーバーの DNS を計画する

DirectAccess クライアントは、内部ネットワークに配置されているかを判断するために、ネットワーク ロケーション サーバーに接続しようとします。 内部ネットワーク上のクライアントは、ネットワーク ロケーション サーバーの名前を解決できる必要がありますが、インターネットに配置されているときは名前を解決できないようにする必要があります。 このような処理が行われるように、既定では、ネットワーク ロケーション サーバーの FQDN が除外規則として NRPT に追加されます。

管理サーバーの構成を計画

DirectAccess クライアントは、Windows Updateやウイルス対策更新などのサービスを提供する管理サーバーとの通信を開始します。 また、DirectAccess クライアントは、内部ネットワークにアクセスする前に、Kerberos プロトコルを使用してドメインコントローラを認証します。 DirectAccess クライアントのリモート管理中、管理サーバーはクライアント コンピューターと通信して、ソフトウェアやハードウェアのインベントリ評価などの管理機能を実行します。 リモート アクセスでは、次のような一部の管理サーバーが自動的に検出されます。

  • ドメインコントローラーの自動検出は、クライアント コンピューターを含むドメインおよびリモート アクセス サーバーと同じフォレスト内のすべてのドメインに対して実行されます。

  • Microsoft Endpoint Configuration Manager サーバー

ドメイン コントローラーとConfiguration Manager サーバーは、DirectAccess を初めて構成する際に自動的に検出されます。 検出されたドメインコントローラーは、コンソールには表示されませんが、Windows PowerShellコマンドレットを使って設定を取得することができます。 Domain Controller または　Configuration Manager サーバーが変更された場合、コンソールで [Update Management Servers ]をクリックすると、管理サーバーの一覧が更新されます。

管理サーバーの要件

  • 管理サーバーは、インフラストラクチャーのトンネル経由でアクセスできる必要があります。 リモート アクセスを構成するときに、管理サーバーの一覧にサーバーを追加すると自動的にこのトンネルでアクセスできるようになります。

  • DirectAccess クライアントへの接続を開始する管理サーバーは、ネイティブ IPv6 アドレスまたは ISATAP で割り当てられたアドレスを使用して、IPv6 を完全にサポートする必要があります。

Active Directory の要件を計画する

リモート アクセスでは、次のように Active Directory を使用します。

  • 認証、インフラストラクチャ トンネルは、リモート アクセス サーバーに接続しているコンピューター アカウントの NTLMv2 認証を使用します。アカウントは Active Directory ドメインにある必要があります。 イントラネット トンネルでは、ユーザーに Kerberos 認証を使用して、イントラネット・トンネルを作成します。

  • グループ ポリシー オブジェクト、リモート アクセスは構成設定をグループ ポリシー オブジェクト (GPO) に収集し、リモート アクセス サーバー、クライアント、および内部アプリケーション サーバーに適用します。

  • セキュリティ グループ、リモート アクセスはセキュリティ グループを使用して、DirectAccess クライアント コンピューターを収集および識別します。 GPO は、必要なセキュリティ グループに適用されます。

リモート アクセスの展開のための Active Directory 環境を計画する場合は、次の要件を考慮する必要があります。

  • Windows Server 2012、Windows Server 2008 R2、Windows Server 2008、Windows Server 2003 のいずれかの OS に、少なくとも 1 つのドメイン コントローラーがインストールされていること。

    ドメイン コントローラーが境界ネットワーク上にあり、そのためにリモート アクセス サーバーのインターネット側のネットワーク アダプターから到達できる場合は、リモート アクセス サーバーが境界ネットワークに到達できないようにします。 ドメイン コントローラーにパケット フィルターを追加して、インターネット アダプターの IP アドレスに接続できないようにする必要があります。

  • リモート アクセス サーバーはドメイン メンバーである必要があります。

  • DirectAccess クライアントは、ドメイン メンバーである必要があります。 クライアントは次に所属することができます。

    • リモート アクセス サーバーと同じフォレスト内の任意のドメイン。

    • リモート アクセス サーバー ドメインと双方向の信頼関係がある任意のドメイン。

    • リモートアクセスサーバーのドメインのあるフォレストと双方向の信頼関係を持つフォレスト内の任意のドメイン。

注

  • リモート アクセス サーバーはドメイン コントローラーにできません。
  • リモート アクセスに使用する Active Directory ドメイン コントローラーが、リモート アクセス サーバーの外部インターネット アダプターから到達可能でないこと（アダプターがWindows ファイアウォールのドメイン プロファイルに含まれていないこと）。

クライアント認証を計画する

Windows Server 2012 のリモート アクセスでは、ユーザー名とパスワードを使用する組み込みの Kerberos 認証を使用するか、IPsec コンピューター認証の証明書を使用するかを選択できます。

Kerberos 認証:認証には Active Directory資格情報を使用することを選択した場合、DirectAccess は最初にコンピューターの Kerberos 認証を使用し、次にユーザーも Kerberos 認証を使用します。 この認証モードを使用する場合、DirectAcces sは 1 つのセキュリティ トンネルを使用して、DNS サーバー、ドメイン コントローラー、および内部ネットワーク上のその他のサーバーへのアクセスを提供

IPsec 認証: 2 要素認証またはネットワークアクセス保護を使用する場合、DirectAccess では 2 つのセキュリティ トンネルが使用されます。 リモート アクセス セット アップ ウィザードでは、セキュリティが強化された Windows ファイアウォールの接続セキュリティ規則を構成します。 これらの規則は、リモートアクセスサーバーに IPsec セキュリティをネゴシエートする際に、以下の資格情報を指定します。

  • インフラストラクチャー トンネルでは、1 回目の認証にコンピュータ証明書の資格情報を使用し、2 回目の認証にユーザー (NTLMv2) の資格情報を使用します。 ユーザー資格情報は、強制的に認証インターネット プロトコル (AuthIP) を使用し、DirectAccess クライアントがイントラネット トンネルに Kerberos 資格情報を使用できるようにする前に、DNS サーバーとドメインコントローラーへのアクセスを提供します。

  • イントラネット トンネルでは、最初の認証にコンピューター証明書の資格情報を使用し、2番目の認証にユーザー (Kerberos V5) の資格情報を使用します。

複数ドメインを計画する

管理サーバーの一覧には、DirectAccess クライアント コンピューターが含まれるセキュリティ グループを含むすべてのドメインのドメイン コントローラーが含まれます。 DirectAccess クライアントとして構成されたコンピューターを使用する可能性のあるユーザー アカウントを含むすべてのドメインを含む必要があります。 これにより、使用しているクライアント コンピューターと同じドメインに置かれていないユーザーは、ユーザー ドメインのドメイン コントローラーで認証されます。

この認証は、ドメインが同じフォレスト内にある場合、自動的に行われます。 異なるフォレストに存在するクライアント コンピューターやアプリケーション サーバーを持つセキュリティ グループがある場合、それらのフォレストのドメイン コントローラーは自動的には検出されません。 フォレストも自動的には検出されません。 これらのドメイン コントローラーを検出するには、リモート アクセス管理のタスクUpdate Management サーバーを実行します。

リモート アクセス展開中に、可能な場合は共通のドメイン名サフィックスを NRPT に追加することをお勧めします。 たとえば、domain1.corp.contoso.com と domain2.corp.contoso.com という 2 つのドメインがある場合、2 つのエントリを NRPT に追加する代わりに、corp.contoso.com というドメイン名サフィックスに共通の DNS サフィックス エントリを追加できます。 これは、同じルートのドメインに対して自動的に行われます。 同じルートにないドメインは、手動で追加する必要があります。

グループ ポリシー オブジェクトの作成を計画

リモート アクセスを構成では、DirectAccess の設定をグループ ポリシーオブジェクト (GPO) にまとめます。 2 つの GPO に DirectAccess 設定が設定され、次のように配布されます。

  • DirectAccess クライアント GPO、この GPO には、セキュリティが強化された Windows ファイアウォールの IPv6 移行テクノロジ設定、NRPT エントリ、接続セキュリティ規則などのクライアント設定が含まれています。 GPO は、クライアント コンピューターに指定されたセキュリティ グループに適用されます。

  • DirectAccess サーバー GPO: この GPO には、展開でリモート アクセス サーバーとして構成したすべてのサーバーに適用される DirectAccess 構成設定が含まれています。 また、セキュリティが強化された Windows ファイアウォールの接続セキュリティの規則も含まれます。

注

クライアントは、アプリケーション サーバーが存在する DirectAccess サーバーの内部ネットワークにアクセスできないため、DirectAccess クライアントのリモート管理ではアプリケーション サーバーの構成はサポートされません。 このタイプの設定では、[Remote Access Setup] 設定画面の手順 4 は使用できません。

GPO の構成は、自動または手動で行うことができます。

自動: GPO が自動的に作成されるように指定すると、各 GPO に既定の名前が指定されます。

手動: Active Directory 管理者によって事前定義された GPO を使用できます。

GPO を構成するときは、次の警告について検討してください。

  • 特定の GPO を使用するように DirectAccess が構成された後で、別の GPO を使用するように構成することはできません。

  • 次の手順で、DirectAccess コマンドレットを実行する前に、すべてのリモート アクセス グループ ポリシー オブジェクトをバックアップします。

    Back up and Restore Remote Access Configuration (リモート アクセスの構成のバックアップと復元)

  • GPO を自動で構成しているか、手動で構成しているかにかかわらず、クライアントで 3G ネットワークを使用する場合は、低速リンクの検出のためのポリシーを追加する必要があります。 ポリシー、グループ ポリシーの構成低速リンク検出のパスは次のとおりです。

    コンピューターの構成/ポリシー/管理用テンプレート/システム/グループ ポリシー

  • GPO をリンクするための正しいアクセス許可がない場合は、警告が発行されます。 リモートアクセスの操作は継続されますが、リンクは行われません。 この警告が表示された場合は、後でアクセス許可を追加しても、リンクは自動的には作成されません。 代わりに、管理者がリンクを手動で作成する必要があります。

自動的に作成された GPO

自動作成された GPO を使用する際には、次の点に注意してください。

自動的に作成された GPOS は、ロケーションとリンク先に応じて、以下のように適用されます。

  • DirectAccess サーバーの GPO では、場所とリンク先は、リモート アクセス サーバーを含むドメインを指します。

  • クライアントとアプリケーション サーバー GPO が作成されると、その場所が 1 つのドメインに設定されます。 GPO 名は各ドメインで検索され、ドメインが存在する場合はそのドメインに DirectAccess の設定が使用されます。

  • リンク先は GPO が作成されたドメインのルートに設定されます。 GPO はクライアント コンピューターまたはアプリケーション サーバーを含むドメインごとに作成され、その個々のドメインのルートにリンクされます。

自動作成された GPO を使って DirectAccess の設定を適用する場合、リモート アクセス サーバーの管理者には次のアクセス権限が必要です。

  • 各ドメインの GPO を作成するためのアクセス許可。

  • 選択したすべてのクライアント ドメイン ルートにリンクするためのアクセス許可。

  • サーバー GPO ドメイン ルートのリンクへのアクセス許可。

  • GPO の作成、編集、削除、および修正を行うためのセキュリティ アクセス許可。

  • 必要な各ドメインの GPO 読み取りアクセス許可。 このアクセス許可は必須ではありませんが、GPO の作成時に名前が重複する GPO が存在しないことをリモート アクセスで検証できるようにするため、このアクセス許可を使用することをお勧めします。

手動で作成された GPO

手動で作成した GPO を使用する場合、次の点を考慮してください。

  • GPO はリモート アクセス セットアップ ウィザードを実行する前に存在している必要があります。

  • DirectAccess 設定を適用する場合、リモートアクセス サーバー管理者は、手動で作成した GPO を作成、編集、削除、修正を行うための完全なセキュリティのアクセス許可が必要です。

  • ドメイン全体で GPO へのリンクが検索されます。 GPO がドメインでリンクされていないと、リンクはドメインのルートで自動的に作成されます。 リンクの作成に必要なアクセス許可が使用できない場合、警告が発行されます。

削除された GPO からの回復

リモート アクセス サーバー、クライアント、アプリケーションサーバー上の GPO を誤って削除してしまった場合、次のようなエラーメッセージが表示されます。GPO（GPO名）が見つかりません」と表示されます。

バックアップを使用できる場合は、バックアップから GPO を復元できます。 利用可能なバックアップがない場合は、構成設定を削除して再度構成する必要があります。

構成設定を削除するには

  1. Windows PowerShell コマンドレット RemoteAccess のアンインストールを実行します。

  2. リモート アクセス管理を開きます。

  3. GPO が見つからないというエラー メッセージが表示されます。 [構成設定の削除] をクリックします。 完了すると、サーバーは未設定の状態に戻りますので、再度設定を行ってください。