
企業ネットワークにおけるWi-Fiセキュリティといえば、いまでもPre-Shared Key、いわゆるPSK方式を利用しているケースは少なくありません。
「キーが外部に漏れなければ問題ないのでは?」
「設定も簡単で、運用もしやすいのでは?」
このように考えられることも多いと思います。
もちろん、PSK方式はシンプルで導入しやすい認証方式です。
一方で、ビジネス用途で利用する場合には、共有キーの管理、退職者や異動者への対応、端末紛失時のリスク、キー変更時の再展開など、運用面での課題も見えてきます。
そこで今回は、証明書を利用したWi-Fi認証方式である EAP-TLS に注目し、実際に検証した構成と動作の流れをご紹介します。
特に今回お伝えしたいポイントは、単に「EAP-TLSで認証を強化できる」という話だけではありません。
Intuneを利用することで、証明書の配布からWi-Fiプロファイルの展開までを自動化でき、クライアント展開が非常に楽になる という点です。
EAP-TLSというと、証明書の準備やクライアント設定が大変そう、という印象を持たれる方もいるかもしれません。しかし、Entra ID、Soliton OneGate、Intuneを組み合わせることで、ユーザーに複雑な設定作業を依頼することなく、Wi-Fi接続に必要な設定を端末へ配布できます。
EAP-TLSによるWi-Fi認証強化
EAP-TLSを利用したWi-Fi認証は、企業ネットワークにおける認証強化の定番ともいえる構成です。
IDとパスワードだけではなく、端末やユーザーに配布された証明書を用いて認証を行うため、PSK方式と比較して、より厳密なアクセス制御が可能になります。
ただし、EAP-TLSを実際に運用するうえでは、証明書をどのように発行するか、どのように端末へ配布するか、Wi-Fi設定をどのようにユーザーへ展開するかが重要になります。
ここが手作業になってしまうと、せっかく認証を強化しても、管理者側の負担が大きくなってしまいます。
そこで今回は、以下のような構成で動作検証を行いました。

今回の検証構成
今回の検証では、以下の製品・サービスを組み合わせました。
- Microsoft Entra ID
- Microsoft Intune
- Soliton OneGate
- Soliton EPS-edge
- Cisco Meraki MR
この構成を見て、「なぜこの組み合わせなのか?」と思われた方もいるかもしれません。
それぞれの採用理由を整理すると、次のようになります。
Entra IDをユーザー基盤として利用
Microsoft 365を利用している企業は非常に多く、すでにEntra ID上にユーザー情報が集約されているケースも多いと思います。
せっかく既存のユーザー基盤があるのであれば、それをWi-Fi認証にも活用しない手はありません。
今回は、Entra IDをユーザー情報の基盤として利用し、Soliton OneGateと連携させる構成としました。
ユーザー情報を既存のID基盤と連携できることで、Wi-Fi認証用に別途ユーザー管理を行う必要がなくなります。
証明書の発行・管理にはSoliton OneGateを利用
EAP-TLSを利用する場合、証明書の発行や管理をどのように行うかが重要になります。
証明書ベースの認証は強力ですが、運用が複雑になってしまうと、現場での負担が大きくなります。
そこで今回は、証明書の発行・管理をスムーズに行える構成として、Soliton OneGateを利用しました。
Entra IDとのユーザー連携が可能である点も、この構成を採用した理由のひとつです。
Intuneでクライアント設定をまとめて配布
今回の構成で特に大きなポイントになるのが、Intuneによるクライアント展開です。
近年、ランサムウェア対策や各種セキュリティ評価制度への対応を背景に、Microsoft 365 Business Premium以上のプランを検討・導入する企業も増えています。
Business PremiumにはIntuneが含まれるため、端末管理や構成プロファイルの配布に活用できます。
今回の構成では、Wi-Fi接続に必要な以下の情報をIntuneから配布することを想定しました。
- CA証明書
- ユーザー証明書
- Wi-Fiプロファイル
これらをIntuneから配布できるため、ユーザーに対して「この証明書をインストールしてください」「このSSIDに接続してください」「認証方式はこれを選んでください」といった案内を行う必要がありません。
端末がIntune管理下に入っていれば、必要な証明書とWi-Fi設定が自動的に配布され、ユーザーは意識せずにEAP-TLS認証のWi-Fiへ接続できるようになります。
この クライアント側の設定作業を大幅に減らせる点 が、今回の構成で特に強調したいポイントです。
EPS-edge構成を採用
証明書を配布するのであれば、Wi-Fi認証だけでなく、将来的にはVPNなど他の用途でも活用できる構成にしておきたいところです。
そのため今回は敢えて、EPS-edgeを含めた構成で検証を行いました。
検証した連携内容
ここからは、今回の検証で確認した主な連携内容を紹介します。
Soliton OneGateのCA再構築設定
Soliton OneGate側でCA再構築に関する設定を行いました。
こちらも基本的にはマニュアルに沿って設定を進めることで対応可能です。
設定後、CA証明書を取得し、Intune側に登録します。これにより、端末側でWi-Fi認証時に必要となる信頼済み証明書を配布できるようになります。
Entra IDとSoliton OneGateのユーザー連携
次に、Entra IDとSoliton OneGateのユーザー連携を行いました。
この連携については、Soliton OneGateのマニュアルに設定手順が記載されており、手順に沿って設定することで、スムーズにユーザー連携を行うことができました。

Soliton OneGateとIntuneのSCEP連携
次に、Intuneを利用してユーザー証明書を配布するため、SCEP連携を設定しました。
この構成では、ユーザー証明書をSoliton OneGateで発行し、その証明書をIntune経由で端末へ配布します。
こちらもSoliton OneGateのマニュアルに設定手順が記載されているため、手順に沿って設定することで連携を行うことができました。
Entra ID側へのアプリ登録、Intune-OneGate連携設定、IntuneのCA証明書配布、IntuneのSCEP証明書配布 すべてマニュアルに記載されています。
Intuneを利用して証明書を自動配布できるため、ユーザーごとに証明書を手動で発行・配布する運用と比べて、管理者の負担を大きく削減できます。
ユーザー数や端末台数が増えた場合、手作業による証明書配布では、配布漏れや設定ミスが発生しやすくなりますが、Intuneを利用することで標準化された設定をまとめて展開できます。
※Soliton OneGateとしては、Entra ID連携の有無に関わらず、Intune連携は可能です。
Intune Wi-Fiプロファイル設定
次に、Intuneで配布する Wi-Fiプロファイルを作成します。
ここでは、EAP-TLSを利用してWi-Fi接続するための設定を行います。
以下が、今回設定したものとなります。
Intune>デバイス>デバイス管理>構成>ポリシー>作成>新しいポリシー
・プラットフォーム:Windows10以降
・プロファイルの種類:テンプレートーWi-Fi を選択 >作成
・基本情報 名前:わかりやすい名前を設定 次へ
・構成設定 Wi-Fiの種類:Enterprise
・Wi-Fi名(SSID):設定したSSID
・接続名: SSIDと同じに設定
・範囲内にある場合は自動的に接続する:はい
・可能であれば、より優先されるネットワークに接続する:はい
・認証モード:ユーザー
・EAPの種類:EAP-TLS
・サーバー検証に使用するルート証明書:Intuneで設定したCA証明書設定を選択
・クライアント認証 認証方式:SCEP証明書
・クライアント認証に使用するクライアント証明書:Intuneで設定したSCEPの設定を選択
・割り当て: 該当するデバイスグループを選択
・適用性ルール: 設定なし > レビュー後、作成
Wi-FiプロファイルをIntuneから配布することで、ユーザーはSSIDや認証方式を手動で設定する必要がなくなります。
特にEAP-TLSのような証明書認証では、クライアント側の設定項目が多くなりがちです。SSID、証明書、認証方式、信頼するCA証明書などをユーザー自身に設定してもらうのは、現実的にはなかなか大変です。
IntuneでWi-Fiプロファイルを配布すれば、これらの設定を管理者側で定義し、対象端末へまとめて展開できます。
つまり、ユーザーは細かい設定を意識することなく、端末に必要な設定が入った状態でWi-Fiを利用できるようになります。
Soliton OneGate EPS-edge連携設定
こちらも、EPS-edge管理ガイドというマニュアルを見ながら、OneGateとEPS-edgeの連携を進めていきます。
DHCPでインターネットに出られる状況があれば、EPS-edgeの登録コードをOneGateの管理画面に入力するだけで、OneGate側に登録が可能です。
その後はOneGate側管理画面のアプライアンス設定から、IPアドレスやネームサーバー、NTPサーバーなどを設定した後、RADIUS設定として EAP-TLSで認証できるように設定しておきます。
今回の検証では、PAP認証は想定していない為、PAPの設定は外しておくことにしました。

Cisco Meraki MR EAP-TLS設定
最後に、Cisco Meraki MR側でSSIDの認証方式をEAP-TLS用に設定します。
検証時には、対象SSIDに対してEAP-TLS認証を利用するように設定しました。
・SSID名: 任意のSSID名を設定
・SSIDステータス: 有効に設定
・セキュリティ: エンタープライズ認証ーRADIUSサーバ を選択
・WPA暗号化: WPA3のみ
・RADIUS RADIUS Servers:
Host IP or FQDN:EPS-edgeに設定したIPアドレス
Auth Port:1812
Secret:EPS-edgeに設定しているRADIUSクライアントシークレットを設定
Merakiを利用する場合、クラウド管理画面からSSIDや認証設定を変更できるため、アクセスポイント側の設定もわかりやすく管理できます。
クライアント端末での動作確認
すべての設定が完了した後、実際にPCを利用してWi-Fi接続までの動作を確認しました。
検証時の流れは、以下のようになります。
- PCをゲストWi-Fiに接続する
- Entra IDにログインする
- PCを再起動する
- Entra IDアカウントでWindowsにログインする
- 数分後、Intuneから以下の設定が配布される
- CA証明書
- ユーザー証明書
- Wi-Fiプロファイル
- EAP-TLSを利用したWi-Fi接続が自動的に行われる
実際の動作としては、Intuneから必要なプロファイルが配布された後、気が付くとEAP-TLS認証でWi-Fiに接続できている、という流れでした。
この「気が付くと接続できている」という点が、今回の検証で特に印象的でした。
EAP-TLSと聞くと、クライアント側の設定が複雑になりそうなイメージがあります。しかし、Intuneを組み合わせることで、ユーザーに証明書を配布したり、Wi-Fi設定を手順書どおりに入力してもらったりする必要がありません。
管理者があらかじめ必要なプロファイルを用意しておけば、端末側には自動的に設定が展開されます。
ユーザーから見ると、特別な作業をしなくても業務用Wi-Fiに接続できる状態になります。管理者から見ると、設定作業の案内や問い合わせ対応を減らせるため、展開時の負担を大きく抑えられます。
この構成のメリット
今回の構成では、いくつかの運用上のメリットがあります。
まず、ユーザー証明書を発行するために個別の招待コードを案内したり、ユーザーに証明書取得手順を説明したりする必要がありません。
また、Wi-Fi設定そのものもIntuneから配布できるため、SSID、認証方式、証明書の選択などをユーザーに手動で設定してもらう必要がありません。
特に大きいのは、クライアント展開時の手間を大幅に削減できる点です。
従来のように、ユーザーへ手順書を配布し、証明書のインストール方法やWi-Fiの設定方法を案内し、うまく接続できない端末を個別にサポートする、という運用はどうしても負担が大きくなります。
今回のようにIntuneを活用すれば、管理者が定義した設定を端末へまとめて配布できます。
そのため、以下のような効果が期待できます。
- ユーザーによる設定ミスを減らせる
- 証明書配布の手間を削減できる
- Wi-Fi設定手順の案内を簡略化できる
- 端末ごとの設定ばらつきを抑えられる
- 展開後の問い合わせ対応を減らしやすい
すでにIntuneで端末を管理している環境であれば、Wi-Fi認証の強化とクライアント設定の自動化を組み合わせることで、運用負荷を抑えながらセキュリティを高めることができます。
PSK方式では、共有キーが知られてしまった場合にキー変更や再展開が必要になります。一方、EAP-TLSではユーザーや端末単位で証明書を管理できるため、アクセス制御の粒度を高めやすい点もメリットです。
セキュリティを強化しながら、展開や運用をできるだけ簡単にしたい場合には、非常に相性のよい構成だと感じました。
一言でまとめると、「Wi-Fiパスワードを配らない、ユーザーに設定させない、正規端末だけが自動接続する社内Wi-Fi」 という感じでしょうか。
Cisco Merakiを利用したフルクラウド構成も選択肢に
Cisco Merakiを利用する場合、ローカル環境には無線LANアクセスポイントのみを設置し、管理や認証関連の仕組みをクラウド側に寄せる構成も考えられます。
このような構成については、Soliton社の情報サイト「ネットアテスト」にも構成例が紹介されていますので、MerakiとOneGateを組み合わせた構成を検討される場合は、そちらも参考になると思います。
オンプレRADIUSレスでEAP-TLSを構築してみた──Soliton OneGate × Cisco Meraki Access Managerで実現するクラウド認証基盤
まとめ
今回は、Wi-Fiセキュリティの見直しという観点で、EAP-TLSを利用した認証構成を検証しました。
PSK方式は手軽に利用できる一方で、企業利用においては共有キー管理の課題が残ります。特に、利用者や端末が増えるほど、キーの管理や設定変更時の負担は大きくなります。
一方、EAP-TLSを利用すれば、証明書を用いたより強固な認証が可能になります。
さらに、Entra ID、Soliton OneGate、Intune、Cisco Meraki MRを組み合わせることで、ユーザー情報の連携、証明書の発行、端末への設定配布、Wi-Fi接続までを一連の流れとして構成できます。
今回の検証で特にメリットを感じたのは、クライアント展開のしやすさ です。
証明書の配布やWi-Fiプロファイルの設定をIntuneからまとめて展開できるため、ユーザーに複雑な作業を依頼する必要がありません。管理者側も、個別対応や設定ミスのフォローを減らしやすくなります。
EAP-TLSは「セキュリティは強いが、展開が大変そう」と思われがちな構成かもしれません。しかし、Intuneなどの管理基盤と組み合わせることで、認証強化と展開のしやすさを両立できます。
すでにMicrosoft 365やIntuneを活用している環境であれば、企業Wi-Fiのセキュリティを見直す際の選択肢として、EAP-TLS構成を検討してみてはいかがでしょうか。
WPA3ブログ 第四回~設定やクライアント接続結果の紹介 Meraki編~
