0

Windows Server 2012 R2 を使用した DirectAccess の実装に取り​​組んでいます。

DA サーバーは、ファイアウォールの背後にある単一の NIC であり、TCP/443 が IPHTTPS 用に転送されます。

最初のテスト/セットアップ中に、認証にユーザー名/パスワード (コンピューター アカウント) を使用して、Windows 8.1 クライアント用に厳密にセットアップしました。すべてが美しく機能しました。

テストを Windows 7 クライアントに拡張するために、認証に証明書を使用するように DA を構成しました。過去 2 年間に必要だった他のすべての機能に対して適切に機能する内部 PKI インフラストラクチャがあります。

Windows 7 クライアントは、DirectAccess Connectivity Assistant を使用して接続し、美しく動作します。ただし、Windows 8.1 クライアントはできません。

証明書を確認しましたが、すべて問題ないようです。DirectAccess Troubleshooter を使用すると、DA IPHTTPS URL に正常に接続されていることがわかりますが、内部リソースにはアクセスできません。内部 DCE アドレス x:y:z::1 および x:y:z::2 に ping を実行できます。私の理解では、ネットワーク内の DA サーバーです。

これをトラブルシューティングするための追加のツールはありますか? Win8クライアントだけが証明書に接続しない理由を判断するために、誰かが私を正しい方向に向けることができますか?

4

2 に答える 2

0

DA の最初の開始ウィザードでは、Windows 8 / 8.1 が Kerberos プロキシ (証明書なし) を使用して接続できます。PKI を使用した本格的なインストールでは、すべてのクライアントが証明書を使用する必要があります。コンピューター証明書を Windows 8 / 8.1 に展開すれば問題ありません。

参照 - http://technet.microsoft.com/en-gb/windows/dn197886.aspx

Windows 8 および Windows Server 2012 の DirectAccess はどのように展開を簡素化しますか? 以前のバージョンの Windows Server では、DirectAccess を展開するために PKI が必要でした。DirectAccess は、サーバーとクライアントの証明書ベースの認証に PKI を使用しました。現在、Windows 8 は、DirectAccess サーバーで実行されている Kerberos プロキシ サービスを使用して、クライアント認証要求を送信します。Kerberos プロキシ サービスは、クライアントに代わってドメイン コントローラに要求を送信します。その結果、単純な展開の場合、DirectAccess を展開するために PKI は必要ありません。IT 管理者は、はじめにウィザードを使用して、いくつかの簡単な手順で DirectAccess を構成できます。より複雑な展開シナリオでは、PKI が引き続き必要です。

于 2014-07-31T14:43:11.500 に答える