はじめに

この記事は、NPS + WiFi を使って、クライアント証明書による 802.1x 認証を行いたい人のための記事です。

Windows で、NPS + WiFi + 802.1x 認証を行う場合は、２種類の認証方式が代表的なものになります。
① ユーザーID とパスワードによる認証： PEAP (MS-CHAPv2)
② クライアント証明書による認証： EAP-TLS または PEAP (EAP-TLS)

この記事では、「② クライアント証明書による認証」を扱います。

スタンドアロン CA とエンタープライズ CA の違い
AD CS で証明書を発行する場合、スタンドアロン CA とエンタープライズ CA の２通りの方法があります。本記事では、スタンドアロン CA の手順を紹介ししてます。

スタンドアロンCA で構成する場合は、各 PC 毎に固有のクライアント証明書を独自に配布する必要がありますが、その配布をすべて手動で行う必要があります。

エンタープライズ CA を使うと、WiFi の認証に必要なルート証明書・PC ごとに固有のクライアント証明書を自動的に配布する事が出来るため、運用を考えた場合は、エンタープライズ CA の方が有利な選択肢となります。

エンタープライズ CA の手順は、以下の記事を参照してください。

1. 前提事項

1-1. PEAP (MS-CHAPv2) の構成を完成させる

本構成 (EAP-TLS) を行う前に、まずは以下の記事を参考に PEAP (MS-CHAPv2) の構成を完成させてください。

本構成 (EAP-TLS) は、クライアント証明書を扱う事もあり構成が非常に複雑です。
クライアント証明書以外の観点でも、構成ミスなどでうまく完成できない可能性が高いため、一気に環境を作り上げても、問題点を絞り込むことが難しくなります。

そのため、まずは難易度が低い PEAP (MS-CHAPv2) の環境を完成させて、NPS や RADIUS、WiFi-AP、サーバー証明書が正常に動作していることを確認した上で、その環境からの構成変更によってクライアント証明書に対応させていくことを考えましょう。

この記事で紹介している手順も、PEAP (MS-CHAPv2) の構成からの変更点という形で記載しています。

1-2. NPS サーバーの NT Auth ストアの状態を確認する

クライアント証明書を扱う場合は、NPS サーバーの "信頼されたルート証明機関" と "NT Auth ストア" にルート証明書のインポートが必要です。

PEAP (MS-CHAPv2) の場合は、クライアント側の要件（しかも任意）でしたので、NPS サーバー側へのアップロードは、意識してやっていない人も居ると思います。

私の PEAP (MS-CHAPv2) の記事の通りに作業をおこない、ドメインコントローラーで NT Auth ストアを展開していれば、結果的に NPS サーバーにも展開されているハズです。

念のため、以下の記事の 3 章（確認方法）を参考に、ちゃんとしているのかを確認して、漏れがあれば追加で作業しましょう。

2. NPS サーバーの構成変更

この作業で、PEAP (MS-CHAPv2) のための構成から、"EAP-TLS" または "PEAP (EAP-TLS)" のいずれかの構成に変更します。（後述する手順 2-1. または 2-2. を選択して実施）

ここで選択した構成は、クライアント PC 側の WiFi プロファイルで選択する "EAP の種類" と一致している必要があります。

EAP-TLS と PEAP (EAP-TLS) のどちらが良いのか・・・ですが、PEAP の方が EAP-TLS をさらにカプセル化で保護しているので、セキュリティが高い分、良いのではないかと思います。
※ EAP-TLS がダメという事ではなくて、ちゃんと TLS で保護されています。

PEAP のデメリットは、クライアント側でルート証明書や NT Auth ストアがちゃんと設定されていないと、WiFi 接続時に以下の "確認" の画面が 2 回出てしまうことくらいです。
ちゃんと構成されていれば、"確認" は、一切出ませんので、影響ありません。

※ PEAP のチェック時と、EAP-TLS のチェック時で 2 回分

2-1. EAP-TLS の場合

2-2. PEAP (EAP-TLS) の場合

3. クライアント PC 側共通の構成

以下の記事を参考に、クライアント PC が接続する際の全台共通の構成を行います。

4. クライアント証明書の作成

作業用マシンを用意して、以下の手順にてクライアント証明書を作成します。
PC 台数分、ユーザー数分を作成します。

5. クライアント証明書の配布

前章でエクスポートした pfx 形式のファイルを、目的のクライアント PC へ配布してインポートします。
インポートする際には、認証の目的に合わせて、保存するストアを選択してください。

コンピューター認証の場合は、ローカルコンピューターストアへ
ユーザー認証の場合は、ユーザーストアへ

クライアント証明書のインポート手順は以下の記事が参考になります。

6. テスト

上記までの手順が完了すると、クライアント PC から WiFi へクライアント証明書の認証を使って接続することが可能になっています。

クライアント証明書がインポートされた PC から接続できること
クライアント証明書が存在しない PC からの接続ができないこと
失効したクライアント証明書がインポートされた PC から接続できないこと

7. エラー例

7-1. その１

（エラーメッセージ）
"サインインするための証明書が必要なため、接続できません。IT サポート担当者に問い合わせてください。"

NPS サーバー側、クライアント側の双方で、以下のセットが適切に配置されている必要があります。作業ミスがないかどうか、再度確認してください。

"信頼されたルート証明機関" にルート証明書がインポートされている
"NT Auth ストア" にルート証明書の拇印が登録されている
WiFi プロファイルでルート証明書が明確に選択されている

証明書関連で接続できない場合のイベントログの一例

ログの種類：セキュリティ
イベント ID：6273
キーワード：失敗の監査
タスクのカテゴリ：Network Policy Server
理由コード：295
理由：証明書チェーンは正しく処理されましたが、証明機関の証明書の１つがポリシープロバイダーによって信頼されていません。

7-2. その２

（エラーメッセージ）
"このネットワークに接続できません"

イベントログに、以下のエラーが出て接続できない場合があります。

ログの種類：セキュリティ
イベント ID：6273
キーワード：失敗の監査
タスクのカテゴリ：Network Policy Server
理由コード：259
理由：失効サーバーがオフラインだったため、失効関数は失効を確認できませんでした。

この場合は、NPS サーバーが、証明書に定義された CRL へアクセスできない状況です。
以下の観点をチェックしてください。

NPS サーバー上で、CRL のアドレスへの名前解決に異常が出ていないか？
NPS サーバーから、CRL のアドレスへの疎通は？
CRL がファイル共有で構成されている場合、アクセス権は適切に構成されているか？

一例として、 AD CS のサーバーを WORKGROUP のサーバーで構築した場合、既定値ではファイル共有で CRL が構成されているのですが、そのフォルダに、NPS サーバーからアクセスできない状況に陥るかもしれません。
※NPS サーバー上のエクスプローラーから CRL にはアクセスできても、それは、たまたま AD CS サーバーと、NPS サーバーのローカル管理者アカウントの ID とパスワードが一緒だからアクセスできているだけです。しかし、NPS サーバーのプロセスは別のアカウントで動作しているので、ファイル共有の CRL に対してアクセス権が無い・・・という事が起こりえます。

参考：AD CS を既定値で構築した場合は、失効リストがファイル共有で構成されている。

この場合の対処策を以下の記事にまとめたので、この手順を実施してください。

なお、問題の切り分けの一助として、NPS サーバーがクライアント証明書の失効確認を無効化することもできるので、これを試して接続が可能になるかどうか様子を見ることもできます。

NPS サーバー上で、以下の公開情報に記載されているレジストリ（NoRevocationCheck）キーに、値 "1" を設定してください。サーバーを再起動することで設定が反映されます。

上記は、あくまで証明書の失効確認のエラーを回避できない場合の一時的な回避策なので、証明書の失効を運用に組み込む際には、NoRevocationCheck キーを削除して、適切な CRL の構成を行うようにしてください。

8. 証明書失効の実施手順

クライアント証明書が PC やユーザー事に配布されていれば、 PC 紛失時やユーザーの離職にともなって、証明書失効の運用が可能になります。
クライアント証明書を発行する目的の一つは、これをやりたい・・って事だと思います。

NPS サーバーは、802.1x認証時にクライアント PC から提示されたクライアント証明書が、サーバーの "信頼されたルート証明機関" 内にあるルート証明書と "証明書ペア" を構成できるのかをチェックしています。"ペア" でなければ認証エラー、 "ペア" であれば、認証成功となります。

その際に、NPS サーバーがクライアント証明書に記載されている CRL (失効リスト) へアクセスして、証明書が失効されていないかどうかも評価します。

そのため、運用管理者が失効リストに、クライアント証明書の拇印を登録することで、紛失したクライアントPC からのアクセスをブロックすることも可能になるという仕組みです。

以下の手順にて、証明書を失効できます。