NPS + WiFi + 802.1x 認証 (EAP-TLS) 構築手順（スタンドアロン CA 編）

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

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

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

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

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

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

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

https://qiita.com/carol0226/items/564a21455cd3e5f58906

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

https://qiita.com/carol0226/items/05d8ef17a6d25018cd4e

本構成 (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 章（確認方法）を参考に、ちゃんとしているのかを確認して、漏れがあれば 追加で作業しましょう。

https://qiita.com/carol0226/items/5dde4fe77220f4388945

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

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

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

:::note info
PEAP の デメリットは、クライアント側で ルート証明書 や NT Auth ストア がちゃんと設定されていないと、WiFi 接続時に 以下の "確認" の画面が 2 回出てしまうことくらいです。
ちゃんと構成されていれば、"確認" は、一切出ませんので、影響ありません。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/00f9e456-53de-c158-f711-afb993453d33.png)
※ PEAP の チェック時と、EAP-TLS のチェック時で 2 回分
:::

## 2-1. EAP-TLS の場合
0. NPS サーバー上で「ネットワークポリシー」を 開いて「制約」タブから、赤枠「Microsoft: 保護された EAP (PEAP)」を削除し、緑枠「スマートカードまたはその他の証明書」を追加します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/32294cf6-7ecb-e127-b417-db9c1fa7601f.png)
　<br>
0. 最終的に、以下の設定になっていれば、EAP-TLS への設定変更は完了です。「OK」を押して、設定を保存して終了させます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/479ef33e-565b-920c-f664-0a8eb0482100.png)

## 2-2. PEAP (EAP-TLS) の場合
0. NPS サーバー上で「ネットワークポリシー」を 開いて「制約」タブから、緑枠「Microsoft: 保護された EAP (PEAP)」を選択して、赤枠「編集」を押します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/c79f62f1-1952-6448-da73-4da5263bf555.png)
　<br>
0. 「保護された EAP プロパティの編集」で、赤枠「セキュリティで保護されたパスワード (EAP-MSCHAP v2)」を削除し、緑枠「スマートカードまたはその他の証明書」を追加する
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/74795db4-ef4b-de6f-6e80-1604db2d6062.png)
　<br>
0. 最終的に、以下の設定になっていれば、PEAP (EAP-TLS) への設定変更は完了です。「OK」を押して、設定を保存して終了させます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/d41bdc97-ed4a-5596-67d1-ca777ba8730c.png)

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

https://qiita.com/carol0226/items/5f3a11311dac6efb4d8e

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

https://qiita.com/carol0226/items/ba5c9eb1ff0f27e8be3b

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

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

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

https://www.netattest.com/Windows10-Wireless-CertAuth_2022_tec_sol

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

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

# 7. エラー例
## 7-1. その１
（エラーメッセージ）
"サインインするための証明書が必要なため、接続できません。IT サポート担当者に問い合わせてください。"
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/c47bf7e2-9743-3d9e-d8e8-88e68be26a18.png)

NPS サーバー 側、クライアント 側 の双方で、以下のセットが適切に配置されている必要があります。作業ミスがないかどうか、再度 確認してください。
- "信頼されたルート証明機関" に ルート証明書 が インポートされている
- "NT Auth ストア" に ルート証明書 の 拇印 が登録されている
- WiFi プロファイルで ルート証明書 が 明確に選択されている

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

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/d3632a9f-838f-383b-2517-9aca7d65a14c.png)

## 7-2. その２
（エラーメッセージ）
"このネットワークに接続できません"
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/4cce16c0-7cd6-f147-be42-9fb33d5eed30.png)

イベントログに、以下のエラーが出て 接続できない場合があります。
- ログの種類：セキュリティ
- イベント ID：6273
- キーワード：失敗の監査
- タスクのカテゴリ：Network Policy Server
- 理由コード：259
- 理由：失効サーバーがオフラインだったため、失効関数は失効を確認できませんでした。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/96446e98-8b2c-2717-1d4a-4be2f78f7644.png)

この場合は、NPS サーバー が、証明書 に定義された CRL へアクセスできない状況です。
以下の観点をチェックしてください。
- NPS サーバー 上で、CRL のアドレスへの名前解決に異常が出ていないか？
- NPS サーバー から、CRL のアドレスへの疎通は？
- CRL が ファイル共有 で構成されている場合、アクセス権は 適切に構成されているか？

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

参考：AD CS を既定値で構築した場合は、失効リストが ファイル共有 で構成されている。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/d0622fb3-6333-ef35-20bd-08c997652087.png)

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

https://qiita.com/carol0226/items/333da143c95550412b2b

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

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

https://learn.microsoft.com/ja-jp/windows-server/networking/technologies/nps/network-policy-server-certificate-revocation-list-check-registry-settings?tabs=registry-editor

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

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

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

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

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

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

https://qiita.com/carol0226/items/3f0d77848aed59751d9b