802.1xはWindowsクライアントの証明書を自動的に検証します
Windows Server 2008 NACをRADIUSサーバーとして使用してワイヤレスネットワーキングを展開しています。WindowsXPまたは7つのクライアントが接続すると、最初は接続に失敗します。
クライアントが接続できるようにするには、ネットワークを手動で追加し、下のスクリーンショットに示すように「サーバー証明書の検証」のチェックを外す必要があります。
誰かがこれをしなくて済むようにする方法を知っていますか？役立つ場合は、Verisign、Thwarteなどから証明書を購入してもかまいませんが、修正されていないComodoワイルドカードSSL証明書を試しました。
これらのマシンはエンドユーザーに属しているため、グループポリシーやレジストリハックでは設定を簡単に制御できません。
RADIUSサーバーの証明書（自己署名されている場合）またはクライアントに署名した認証局の証明書を配布する必要があります。
現在、クライアント（または802.1X-eseのサプリカント）にRADIUSサーバーの証明書の信頼パスを確認するように指示しています。公開鍵と秘密鍵をどのように生成したかわかりませんRADIUSサーバー用のペアですが、一般的に言えば、自己署名または認証局によって署名されます。次に、署名認証局の公開鍵がGPOを介してクライアントに配布されます。 Active Directory証明書サービス、またはMicrosoftによって信頼されたルート証明機関リポジトリに含まれていました。
誰かがこれをしなくて済むようにする方法を知っていますか？役立つ場合は、Verisign、Thwarteなどから証明書を購入してもかまいませんが、修正されていないComodoワイルドカードSSL証明書を試しました。
RADIUSサーバーの証明書に外部ルートCAに署名させることは推奨構成ではありません。
これはFreeRADIUSのドキュメントによるものですが、Microsoftの実装に対しても同じように有効です。
一般に、802.1x（EAP）には自己署名証明書を使用する必要があります
認証。他の組織のルートCAを
「CA_file」、あなたが彼らにあなたになりすますことを許可し、認証する
ユーザー、およびEAP-TLSのクライアント証明書を発行する。
これらのマシンはエンドユーザーに属しているため、グループポリシーやレジストリハックでは設定を簡単に制御できません。
さてあなたの問題があります！ GPOを使用して証明書を配布するのは簡単です。なぜこれがあなたの場合の選択肢ではないのですか？それを除けば、（ルートCAによって署名された）独自のスター証明書を実行すると、RADIUSサーバーの証明書で署名できますか？
EDIT：残念ながら、BYODとWPA2-Enterpriseは、実際に連携するようには設計されていません。次の3つのオプションがあります。
- RADIUSサーバーの証明書の信頼パスをチェックしないようにクライアントを構成します（つまり、「サーバーの証明書を検証する」というボックスのチェックを外します）。
- 信頼できるルート証明機関リポジトリ（Verisign、Comodoなど）で署名証明書が配布されている「外部」CAによって署名されたRADIUSサーバーの証明書を取得します。
- クライアントに代わってサプリカントとして機能するある種のキャプティブポータルをセットアップします。
最初の2つのオプションの欠点は、802.1XスキームをMiTM攻撃に開放することです。私はおそらく私自身のRADIUSサーバーを構築し、ユーザーのAD資格情報を傍受することができます。理想的な設定ではありませんが、部門はリスク分析を行う必要があります。このルートを使用する場合は、必ず文書化してくださいCYAの目的のため。
セキュリティの観点から、最良のオプションは、キャプティブポータルをセットアップすることです。生徒はBYODデバイスを使用してポータルに接続して到達し、ユーザー認証資格情報をポータルに渡すと、ポータルはRADIUSサーバーと通信できます。
Eduroam は、教育機関にとってもう1つの一般的な選択肢です。
私はこの投稿が本当に古いことを知っていますが、これは私の問題と似ていますが、先週、すべてのクライアントが私のワイヤレスネットワークに接続でき、今週はできません。 8つのアクセスポイントを備えたAruba EOL 3200を使用しています。 Windows/Android/iphoneクライアントは、1つのユーザー名のローカルのArubaベースのデータベースに対して検証する802.1xで接続できました。今週中に入ると、電話がワイヤレスに接続できないことに気づきました。次に、私のWindows 10ラップトップは接続できませんでした（両方とも以前に接続したことがありました）。ネットワークから切断していないクライアントだけが、引き続きネットワークにアクセスできました。これは、802.1x ssid（スタッフ）でのみ発生し、PSK ssid（ゲスト用）では発生しません。次に、Windowsコンピューターがこれに接続する唯一の方法が、プロファイルを手動で追加するときに、[証明書を検証してサーバーのIDを確認する]オプションをオフにすることであることを確認しました。 Androidデバイスはまだ接続できません。
先週とよく似たセットアップを導入して、1週間のキャンプ場イベントへのインターネットアクセスを提供しました。これは私が使用したアプローチであり、いくつかの教訓を学びました：
最初に、複数のSSIDを使用して、WPA2-Enterprise上のプライマリネットワークと、ユーザー登録用のオープンネットワークを提供しました。オープンネットワークは、ユーザーがサインアップして支払い情報を提供するカスタムキャプティブポータル（HTTPSおよびCAが発行した通常の証明書を使用）にリダイレクトします。支払いが完了すると、ユーザーはRADIUSデータベースで有効になり、WPA2-Enterprise SSIDに再接続してオンラインになります。
私はそれを稼働させるのに厳しい期限があったので、それはAndroidとiOSでのみテストされ、どちらにも実際の問題はありませんでした。本番環境では、Windowsがまったく気に入らなかったことがすぐにわかりました。
- Windows XPは、セキュリティで保護されたネットワークを使用するためにSP3を必要としたため、ローカルコピーをキャプティブポータルに直接ダウンロードして保存しました。 1人のユーザーが実際にXP SP2を表示し、更新する必要がありました。
- Windows XP、Vista、および7はユーザー名とパスワードでの接続を拒否しましたが、実際にはサーバー証明書について特に不満を言うことはありませんでした。これが、最初にサインアップしたWindowsユーザーの試行錯誤による原因であることを発見しました。問題が特定されれば、実際に手動でネットワークプロファイルを設定することは非常に簡単でした。
- Windows 8、iOS、およびNetworkManagerのGNOME/Ubuntuバージョンでは、RADIUSサーバー証明書についてプロンプトが表示されましたが、ユーザーは証明書を受け入れて接続できました。
- NetworkManagerのKDEバージョンは、手動設定なしでは接続を試みず、選択したデフォルトが間違っていました。幸い、この特定の構成では、1人のユーザーだけが表示されました。
- Mac OS Xのサポートをリクエストする人はいませんでした。後でMac OS Xクライアントが問題なく接続できることを知りました。
このすべての問題を回避するために、次のイテレーション（つまり翌年）では、サーバー証明書をキャプティブポータルから直接インストールすることを提案します。これにより、ユーザー（主にWindowsユーザー）が安全なネットワークにログインする際に問題が発生しなくなります。