原著論文
香川大学における多要素認証を用いた有線LANの認証方法に関する開発
2025 年 29 巻 1 号 p. 119-129
詳細
2025 年 29 巻 1 号 p. 119-129
近年，大学における有線LAN接続にはMACアドレス認証が広く用いられているが，MACアドレスの詐称や機器の貸し借りによるセキュリティ上の課題が指摘されている．本研究では，香川大学におけるネットワーク認証のセキュリティ向上を目的として，Microsoft Entra MFAを活用した多要素認証による有線LAN接続方式を提案し，IEEE 802.1X認証とスマートフォンを用いた多要素認証を組み合わせることで，構成員本人を対象とした認証を実現した．提案方式はWindows，macOS，Linuxを含む複数の主要OS上で動作するほか，L2スイッチ配下の端末や音声通話による認証にも対応し，構成員の業務利用に用いる端末で安定した接続を可能とした．さらに，Linux端末における再認証の問題や，多要素認証の通知設定の不整合による接続失敗といった実運用上の課題も分析し，その対策を提示した．本方式は既存の学内基盤を活用しながら，柔軟かつ高セキュリティな有線LAN認証環境の構築が可能である．
近年の大学では学生や教職員がノートPCを持ち込み，授業や研究の一環としてインターネットにアクセスすることが増えている．例えば，授業ではソフトウェアのダウンロードやMicrosoft TeamsなどのWeb会議を用いた画面共有などを実施している．これらを実現するために，大学では構成員に向けてインターネットに接続できる有線LAN環境を提供している．著者等の所属する香川大学では，キャンパスの講義室や演習室に有線LANに用いる情報コンセント（RJ-45）を配置しており，学生や教職員の構成員が自由に端末を接続できる．構成員は事前に接続する端末のMACアドレスを情報メディアセンターの認証システムに登録しておくことで，接続時に端末のMACアドレス認証が行われる．しかし，MACアドレスを詐称した端末の接続や，機器の貸し借りによる他者の端末を用いた接続などの問題がある．著者等は，大学における情報基盤にセキュリティ強化を意識しており[1]，この問題の解決に迫られている．
一方で，アカウントのセキュリティの強化を目的として，IDとパスワードの組み合わせに追加して，スマートフォンアプリやSMSを用いた多要素認証が必須となりつつあり，大学が提供するサービスにおいても多要素認証が求められている[2]．香川大学ではMicrosoft 365（MS365）を包括契約しており，大学が提供するメールサービスのOutlookやTeamsなどのログインには多要素認証が必須であるが，構成員は問題なく多要素認証を使用できている[3]．
そこで我々は，有線LANの認証方法をMACアドレスを用いた端末に対する認証に加え，多要素認証を用いることで構成員に対し認証を行い，問題を解決する．本論では，有線LAN環境における多要素認証を用いた接続方法を提案し，実運用を見据えた評価を行う．
香川大学は全4キャンパスを有しており，うち1つは医学部と附属病院を内包したキャンパスである（以下，医学部C）．医学部C以外のキャンパスでは学生や教職員を問わず構成員に対し，業務や授業に使用のためにMACアドレス認証を用いた有線LANサービスを提供している．講義室などの部屋ごとに，図1に示す情報コンセントを設置しており，持参するLANケーブルを用いて構成員が自由に接続することができる．また利用者数の都合から，L2スイッチ（インテリジェントスイッチ）やスイッチングハブを接続し1つの情報コンセントに対し，複数の端末が接続できるようにしている箇所もある．
当サービスは以下の手順で使用できる．図2に，有線LANサービスを利用するフローを示す．有線LAN接続時のMACアドレス認証のために，認証制御スイッチ（アラクサラネットワークス株式会社のAX-2630など）とMACアドレス認証サーバ（エイチ・シー・ネットワークス株式会社のAccount@Adapter）が設置されている．認証制御スイッチでは，Radiusクライアントが動作する．MACアドレス認証サーバでは，Radiusサーバが動作し，MACアドレスの登録や認証を受け付ける．MACアドレスの認証状況に応じ，端末が接続するIPアドレスの配布を行う．
下記に，構成員の端末のMACアドレス登録作業を示す．図2に示す（1）～（5）は，下記に示す説明の項番と対応する．
（1）． 認証制御スイッチ（L2スイッチ）が端末のMACアドレスを取得し，MACアドレスサーバに転送する．
（2）． 未登録のMACアドレスである場合，MACアドレス認証サーバがインターネット接続が不可能である隔離用のIPアドレスを配布する．
（3）． MACアドレス認証サーバのWebページに自身のIDとパスワードでログインし，端末のMACアドレスを登録する．
（4）． 端末のMACアドレスをMACアドレスサーバに転送する．
（5）． MACアドレス認証サーバの登録に応じて，MACアドレス認証サーバが通常利用IPアドレスを配布する．
登録し通常利用IPを割り当てられた後は，破線に示すように端末からインターネットや学内サーバへのアクセスができる．
このように香川大学の有線LANサービスは，端末のMACアドレスに紐づいた認証方法となっている．しかし，MACアドレスはソフトウェアを用いて偽装し，他人の端末に成りすまして接続することが可能である．佐賀県ではMACアドレスを偽装した端末を用いて校内LANに不正接続され，重要情報が窃盗される事件があった[4]．また，研究室や講義においては機器の貸し借りもあるため，MACアドレスを登録した構成員と実際の端末を使用する人物が異なることがあるという問題がある．
2.2 多要素認証香川大学では，セキュリティ・ポリシーにより，全ての構成員（9000人）が多要素認証を実施することを定めている[5]．MS365アカウントの管理を担う香川大学の教育情報推進支援センター[6]が，多要素認証の導入をサポートしている．
本センターでは，多要素認証の方式にスマートフォンのMicrosoft Authenticatorアプリを用いることを推奨している．構成員がMS365のWebページなどにアクセスするときは，IDとパスワードと，Webページ上に表示されるワンタイムパスワードをアプリに入力する多要素認証を日常的に行っている．
ただし，医学部Cの一部の部署では，カルテなどの特に機微な個人情報を扱うため，業務中のスマートフォンの使用を禁止している．この理由により，当該部署にある内線電話を用いた，音声通話による多要素認証[7]を実施している．WebページにIDとパスワードを入力した後に，内線電話にMicrosoftからサインイン承認を着信し，ガイダンスに従って電話機のキーをダイヤル（#）することで認証する．
学生や教職員などの構成員の管理には，学内に配置したActive Directoryと連携するEntra ID[8]（旧名: Azure Active Directory）を用い，さらにEntra MFAと連携して多要素認証を実施している．構成員の認証の有無や可否は一元的にEntra MFAから確認/管理でき，例えば，スマートフォンを紛失した構成員の認証を停止することができる．
以上により，一部で形態は異なるものの，構成員はMS365アカウントを用いた多要素認証を実施している．
我々は，MACアドレスという端末単位の認証に加え，構成員個人を認証する方式を導入することを目指す．そこで，構成員が日常的に使用しており，強固なセキュリティを確保できる多要素認証を有線LANの接続に用いることを提案する．多要素認証を用いることで，機器の所有者を問わず有線LANの接続時にID/パスワードによる記憶の認証に加え，スマートフォンを用いた所有物による本人確認を行うことができる．これにより，偽装による成りすましや他者が登録した情報によるインターネット接続を防ぐことができ，通信障害や不審なアクセスなどの事象が発生した場合に，接続をした本人に対し追跡調査を実施することができる．
多要素認証の方式には，香川大学で既に導入されているMS365アカウントとMS Entra MFAを用いる．既存の多要素認証の方式を用いることで，構成員に新たな認証方式など求めることなく，慣れ親しんだ手順で利用できる．費用面においても既存の学内ADを使用するため，追加の費用は発生しない．そのため，構成員と管理者にとって，負担の少ない方法であると判断した．
しかし，香川大学では構成員が有線LANに接続する端末はハードウェアやOSが統一されていないため，利用者の接続端末を推定し，多要素認証の実現が求められる．また，香川大学には複数のキャンパスがあり，既に敷設されている有線LANのイーサネットケーブルやスイッチなどを変更しないことが望ましい．
本論では，香川大学における有線LANの多要素認証の実装，多様な構成員の端末への対応，提案方式における運用の実施を課題とする．
3.2 設計図3に実装した多要素認証の有線LAN環境を示す．
本環境では，香川大学の既存のネットワーク設定を踏襲し従来のMACアドレス認証に加え，実線に示すように構成員のMS365アカウントを用いた認証を行う．
本提案では，認証制御スイッチにおいて，ネットワーク環境におけるユーザ認証を行うことができるIEEE 802.1X認証を用いる．香川大学における既設のL2スイッチは，この認証方式をサポートしており本提案の導入に即して交換などを行う必要がない．端末と認証制御スイッチの間ではEAP/EAPOLを用いて認証を行う[9]．これらは多くの端末のOSでサポートされているため，追加ソフトウェアが不要である．
MAC/IPアドレスなどの制御は，認証制御スイッチ，構成員の情報による認証はユーザ認証サーバとEntra MFAにて行うことで取り扱う処理を分離することで，システムの保守性が向上する．
香川大学ではMACアドレス認証を導入しているため，MACアドレス認証済みの端末を用いる．接続時は，端末上のイーサネットのIEEE 802.1X認証を有効化する必要がある．有効後，端末のLANケーブルを接続し，以下の手順を実施することで認証される．図3に示す（1）～（11）は，下記に示す説明の項番と対応する．
（1）．認証制御スイッチ（L2スイッチ）が端末のMACアドレスを取得し，MACアドレス認証サーバにて認証する．
（2）．MACアドレスが登録済みであることを返す．
（3）．サインイン画面が端末上に表示されるため，構成員はMS365のID（メールアドレス）とパスワードを入力する．
（4）．端末から認証制御スイッチを経由して，ユーザ認証サーバ（NPS, RADIUSサーバの機能を持つ）に端末の認証を要求する．
（5）．ユーザ認証サーバは構成員のMS365アカウントを管理している学内ADにユーザ認証を要求する．
（6）．ユーザ認証の結果を応答する．認証に失敗した場合は，接続を終了する．
（7）．認証に成功した場合は，ユーザ認証サーバがクラウド上にあるEntra MFAに多要素認証（MFA）を要求する．
（8）．Entra MFAは，構成員が登録している方法で多要素認証を要求する．
（9）．構成員の持つスマートフォンのアプリや電話機などに多要素認証の通知を着信する．構成員が多要素認証を承認すると，その結果がEntra MFAに送信される．
（10）．Entra MFAはユーザ認証サーバに承認されたことを応答する．
（11）．認証制御スイッチは認証に成功したことを受け，端末のネットワークへの接続を許可する．
認証後は破線に示すように，端末は認証制御スイッチを介してインターネットや学内サーバにアクセスできる．
3.3 実装図3の構成は，認証制御スイッチにおいて IEEE 802.1X 認証を有効化することで実現できる．
ユーザ認証サーバにはMicrosoftのNPS[10]を用い，文献[11]に従ってMFA拡張機能のインストールと，Entra MFAとの連携を行った．具体的な設定は，付録 A.1に示す．
認証制御スイッチに，下記に示す設定を投入する [12]．本論では，学内で用いられている認証制御スイッチであるAX-2630を用いた．なお，具体的な設定コマンドは，付録 A.2に示す．
・IEEE 802.1X認証の有効化．
・IEEE 802.1Xのユーザ認証方法を指定．
・IEEE 802.1Xの認証用のユーザ認証サーバを設定．
また，端末を接続する認証制御スイッチのポート毎に，下記に示す設定を投入する．
・ポートに対して IEEE802.1X 認証を有効化
・1つのポートで複数端末の認証を有効化
・IEEE 802.1X認証の初回成功後，定期的にサプリカントの再認証を有効化
・IEEE802.1X 認証の再認証の有効化
・IEEE802.1X 認証の再認証の周期を設定
・新規端末検出用EAP-Requestの送信処理を抑止し，端末から任意のフレームを受信したことによって個別にEAP-Request / Identityを送信し，認証処理を実施するように設定
・MAC認証の有効化
・マルチステップ認証の有効化
香川大学は上述の通り多要素認証を導入しているため，ユーザ認証サーバは既に多要素認証に対応しており，認証を求められたときに，構成員がスマートフォンアプリなどを用いた多要素認証を実施できる．このようにIEEE 802.1Xを用いた認証では，ユーザ認証サーバの認証プロセスから多要素認証を実施することができ，有線LAN接続時の多要素認証を実現する．
2023年10月段階でベンダーサポートの対象となっているOSに対し，構成員が主に使用している端末に対し提案方式が動作することの評価を行う．本評価は，図4に示す構成で実施する．
Entra MFAによる多要素認証の認証方法については，Microsoft Authenticatorアプリの使用を想定する．しかし，2.2節で述べた医学部Cの多要素認証の方針から，電話を使った認証も想定する．なお，これらの認証方法については，MicrosoftのMSアカウントの設定に関するWebページ（https://mysignins.microsoft.com/security-info）にて切り替えることができる．
実装した環境において，多要素認証を用いて，端末から有線LANに接続できることを下記の項目に基づいて評価する．
（1）．正しい資格情報（MS365のIDとパスワード）を入力した時，AD認証に成功し2段目認証に処理が進む．
（2）．スマートフォンアプリのサインイン承認通知で承認を選択した時，2段目認証に成功しネットワーク接続が成功
（3）．電話のサインイン承認の着信でガイダンスに従い承認をダイヤル（#）をし，多要素認証に成功しネットワーク接続が成功
4.1.2 結果表1に，1台ずつ評価した端末のOSとバージョンの組み合わせを示す．
| OS | Version |
| Windows | 10 Enterprise, 10 Pro, 10 Home, 11 Enterprise 11 Pro, 11 Home |
| macOS | Monterey, Ventrua, Sonoma |
| Linux | RetHat Linux 7, 8, 9 Ubuntu 20.04, 22.04 |
NICは ASIX USB to Gigabit Ethernet Family Adapterを使用
評価した結果を表2に示す．項目1と2は全ての端末で成功し，項目3については医学部Cでスマートフォンの持ち込みが禁止されている部署にて使用されているWindows 10 Enterpriseのみ評価し，成功した．
| 基準 | Windows | macOS | Linux |
|---|---|---|---|
| （1）． | OK | OK | OK |
| （2）． | OK | OK | OK |
| （3）． | （*） | - | - |
2.1節で述べたように，情報コンセントにL2スイッチを用いて1つの情報コンセントに複数の端末が接続できるようにしている箇所もある．そこで，図5に示すように，L2スイッチの配下に2台の端末を接続し，それぞれの端末から多要素認証を用いて有線LANに接続できることを評価する．ポート（1）の端末を認証した状態で，ポート（2）に別の端末を接続し，多要素認証を行う．
認証制御スイッチにはAX-2630を用い，L2スイッチは同社のAX-S2530Eを用いる．配下に接続する端末は，4.1.2節の表1と同様である．
4.2.2 結果ポート（1）にてLinux端末が認証した状態のとき，ポート（2）にて他の端末の認証処理を行うと，その20～30秒後にLinux端末にて再認証が行われる症状が確認された．Linux以外の端末では，確認されなかった．
4.3 運用に関する評価 4.3.1 目的構成員が提案方式を用いて接続した状態で業務が遂行できることを確認するために，香川大学の情報メディアセンターに所属する技術職員を被験者とした評価を行う．
被験者は，2025/03/04～2025/03/27の間，自身が使用するPCを提案方式に有線LAN接続した状態で業務を行う．提案方式を有効化するマニュアル（図6）を作成し，被験者にはマニュアルに従って接続を行うように指示する．
多要素認証に用いるMSアカウントは，その被験者自身のものを使用する．
被験者は8名（9台）で表3に示す端末を用いた． 評価環境については，認証制御スイッチ配下からスイッチングハブを複数台カスケード接続し，スイッチングハブに端末を接続した構成で評価する．
| OS | 認証方式 | ドライバ | |
|---|---|---|---|
| （1） | Windows 11 Enterprise | アプリ | Intel Ethernet Connection (13) I219-V |
| （2） | Windows 11 Pro | アプリ | 〃 |
| （3） | Windows 11 Pro | アプリ | 〃 |
| （4） | Windows 11 Pro | アプリ | 〃 |
| （5） | Windows 11 Pro | アプリ | Realtek PCIe GbE Family Controller |
| （6） | Windows 11 Pro | アプリ | Microsoft Surface Ethernet Adapter |
| （7） | Windows 11 Pro | 電話 | Realtek PCIe GbE Family Controller |
| （8） | Windows 11 Pro | 電話 | Microsoft Surface Ethernet Adapter |
| （9） | Windows 11 Education | アプリ | ASIX USB to Gigabit Ethernet Family Adapter |
（7）と（8）は同一の被験者が使用
被験者のうち7名（8台）は提案方式での接続に成功し，業務に支障は無かった．
表3-（2）に示す端末は，最初の認証は成功し端末がインターネットに接続されるが，20分程度，使用するとMS Authenticatorアプリに多要素認証を求める通知を複数回受信したり，接続中のネットワークが切断されたりするという症状が確認された．
評価の結果，端末にID/パスワードを入力した後に，18秒以内に多要素認証を完了する必要があることが判明した．即ち，3.2節の（7）～（9）を18秒以内に完了する必要がある．
評価基準（2）に示すスマートフォンのアプリを用いた多要素認証は，認証の通知に対し承諾を押下するのみであるため，18秒以内に完了することができた．しかし（3）に示す受話による多要素認証は，構成員が予め受話を待機し速やかにダイヤルしないと18秒を超え，認証に失敗することがあった．
追加の検証により，Outlookなどのログインを行う際も18秒の制限であることを確認できた．従って，医学部Cで普段から受話による多要素認証を行っている構成員は，普段と同等の制限時間内に操作するため，十分慣れていると考えられ，問題ないと考えられる．もし18秒に間に合わず認証に失敗した場合であっても，LANケーブルの再接続やID/パスワードの再入力による再認証が可能であり，これらの手順を適切に周知することで，本論で述べた接続方法における混乱を防ぐことができる．
5.2 Linux端末における再認証の発生Linux端末を収容しているポート（2）の，パケットキャップチャを確認したため，図7に示す．ポート（1）の認証開始時に，L2スイッチに送るためにEAPOL Startフレームを受信したタイミングで再認証を行っていることがわかった．認証開始時のフレームの宛先MACアドレスは，Nearest non-TPMR Bridge group addressであり01-80-C2-00-00-02と定義されている[13]．
そこでLinux端末にインストールされているパケットフィルタツールnftables [14] を用い，端末が受信するフレームのうち宛先が当該MACアドレスとなっているものを破棄するように設定した．ただし，RedHat 7に関してはカーネルのバージョンが古く，nftablesが使用できない．これにより，“nftables”が使用できるLinux端末にて再認証が行われなくなることを確認した．
この挙動の原因を突き止めるために，Linux端末においてIEEE 802.1X認証に関するフレームを処理するソフトウェア“wpa_supplicant”[15]を分析した．ソースコードによると，EAPOLフレームに関する状態は，SUPP_PAEというステートマシン（enum）1）で管理されており関係するフラグの状態に応じて遷移する．認証の状態に関する3つのフラグの値と遷移の状況を表4に示す．
まず，EAPにより認証状態の時はSUPP_PAEは“AUTHENTICATED”の状態にあり，ネットワークに接続しているポートの認証状態を示すportValiedはtrueである（表4-（1））．この状態でEAPOL Startフレームを受信した際，EAPOLフレームの受信を示すeapolEapがtrueに変更される（表4-（2））2）．この両フラグがtrueの状態の時，SUPP_PAEはRESTARTに遷移するように実装されており3），再認証を実行することを示すeapRestartもtrueに変更される（表4-（3））4）．この条件となったとき，EAPの初期化処理を経て，再認証が行われる5）．
| 状態 | portValied | eapolEap | eapRestart |
|---|---|---|---|
| （1）AUTHENTICATED | true | false | false |
| （2）（受信したとき） | true | true | false |
| （3）RESTART | true | true | true |
このように，認証状態であっても，当該フレームを受信したタイミングで再認証が行われることが判明した．そのため上述した対策により，当該フレームの受信を破棄することが有効である．
5.3 接続中の多要素認証の発生症状が発生した端末に対し追加の検証を行い，認証制御スイッチとユーザ認証サーバのログを調査した．認証制御スイッチではユーザ認証サーバ（Radiusサーバ）への接続に失敗した旨，ユーザ認証サーバでは受信したRadius要求を無視するエラーが出力されていた．実際のログは，付録 A.3に示す．なお，類似の事例は，文献[16–18]などがあるが，いずれも解決には至っていない．
このことから，端末の構成員に関する情報が認証制御スイッチからユーザ認証サーバに，正しく送信されていないことが原因であり，これらの連携における相性問題に帰着すると考えられる．今後は，認証制御スイッチとユーザ認証サーバの間で通過するフレームを確認し，ユーザ認証サーバが受信したフレームと付き合わせることで，正しく送信されていない原因を特定し，解決を図る．
5.4 MSアカウントにおける多要素認証の設定評価の過程で，多要素認証の方法として大学への就職前に自身が使っていたGoogle Authenticatorアプリを設定し，MSアカウントの設定ページにおいて既定の認証方法を図8に示すように「アプリベースの認証またはハードウェアトークン- コード」と設定した構成員がいた．この場合，図3に示す（7）の段階で，認証を求める通知がアプリに送信されず，タイムアウトにより認証に失敗し，接続できなかった．
設定ページにて，Microsoft Authenticatorアプリを用いた認証方法を設定し，既定を「Microsoft Authenticatorアプリ - 通知」に変更することで，（7）の段階で通知が送信され，認証に成功した．
一般的なWebサイトにログインする場合を想定し，Google Authenticatorアプリにおけるワンタイムパスワード方式（OTP）による多要素認証時の挙動を示す．まず，WebサイトにアカウントのIDとパスワードを入力すると，ワンタイムパスワードの入力が求められる．次に，Google Authenticatorアプリ内で表示される6桁の数字列のワンタイムパスワードをWebサイトに入力することで，多要素認証が完了する．Microsoftによる，Windows 11のEAPの対応状況[19]によると，提案方式で用いるPEAP方式は対応しているが，OTP方式は対応していないことが示されている．
また接続を行った際は，端末にIDとパスワードの入力画面（図3-（3））は表示されたが，ワンタイムパスワードの入力画面は表示されなかった．そのときのログを確認すると，ユーザ認証サーバは「EAP セッション タイムアウトのため，認証に失敗しました．」，Entra MFAは「OATH verification code」に対し失敗した旨のエラーが提示され，多要素認証に失敗した．
以上より提案方式においては，OTP方式の多要素認証は対応できないため，MS Authenticatorアプリを用いた通知方式や，電話を用いた方式を使用する必要がある．
5.5 提案システムの導入の検討本論で述べた方法は，端末の標準機能を用いてEAP証明書を導入するのみで実現でき，多要素認証はスマートフォンとEntra MFAで行い，有線LANへの接続はRadiusサーバが判断する．MS365を導入している大学も多く，学内の構成員情報と連携した多要素認証を実現していれば，既存のRadiusサーバと組み合わせることで，配線などを変更することなく容易に使用可能である．
また，スマートフォンを使用できない環境においては，受話による多要素認証の方法に変更することができ，有線LAN環境を変更せずとも構成員の属性に応じた柔軟な対応が可能である．実際に運用を行った結果，認証方式に問わず88.9%の端末が提案方式での接続に成功し，業務に支障は無かったことから，提案方式は実用に耐えることが示唆されたといえる．
5.6 対応するセキュリティ脅威提案方式では，MS365アカウントとその多要素認証により構成員を認証するため，1章で述べたMACアドレスの偽装や成りすましによる不正アクセスを防ぐことができる．攻撃者が不正に入手したMACアドレスで構成員の端末を偽装し，ネットワーク接続を試みた場合，正規の構成員のMS365のIDとパスワードが求められる．併せて入手したとしても，構成員のスマートフォンを用いた多要素認証が必要となるため，攻撃者はネットワークに接続できない．
提案方式は，端末の盗難やアカウント盗難にも強い．攻撃者が端末自体を盗難した場合でも，構成員がスマートフォン上に通知される多要素認証を「拒否」する（図3-（9））ことで，不正な接続を防ぐことができる．さらに，盗難されたMS365のアカウントの利用を学内ADやEntra MFAから停止することで，接続を確実に遮断することもできる．
一方で，文献[20]に示すように，構成員がMS365のWebサイトなどにログインしようとしたタイミングを狙って攻撃者が本論の方式を実施することで，構成員が自身の認証だと思い込み多要素認証を承諾する可能性がある．このような攻撃は，「MFA疲労攻撃」と呼ばれ，多要素認証を用いたシステムにおいて発生する可能性があり，提案方式では未対応である．
大平氏は，学生証の非接触ICカードを用いた無線LANに関して検討している[21]．提案方式ではスマートフォンのアプリによる多要素認証に対応しているが，先行研究では認証毎にICカードとカードリーダを必要とし，利便性が低い．
6.2 対応可能な端末の多様性昨今では，MACアドレスを用いた端末の特定を防ぐために，接続毎にランダムなMACアドレスを使用することが推奨されている[22, 23]．提案方式では多要素認証のみでセキュリティを担保できるため，MACアドレスを廃止しランダムMACアドレスを持つ端末に対応できるが，従来のMACアドレス認証ではランダムMACアドレスに対応できない．そのため，山本らによると核融合科学研究所では，ゲスト用としての利用のみに留めている[24]．
6.3 ネットワーク構成の変更の不要性提案方式では認証制御スイッチとユーザ認証サーバに認証の設定を入れるのみで実装でき，認証前は他機器へのアクセスを遮断できるが，先行研究のWeb認証ではWebサーバへのアクセスを許可する必要があり，サーバの配置やFWのルールを変更する必要がある[25–27]．
また，提案方式では，認証制御スイッチと端末の間に，1台のL2スイッチや単純なスイッチングハブを含めた構成で認証を行えているが，先行研究ではハブを間に挟んだ構成では認証に失敗している[28]．
現在広く使われているMACアドレス認証は端末を認証する範囲に留まっており，ネットワークに接続する構成員本人を認証していないため，MACアドレスの偽装や他者への機器の貸し借りが行われた際に実際の利用者の認証が不可能である．そこで，香川大学におけるネットワークをMS365アカウントのID/パスワードによる記憶とスマートフォンアプリなどの所有物の多要素認証に対応させることで，接続する本人を認証することを目指している．
本論では，本学における構成員が広く使用している端末を想定し，有線LANにおける多要素認証のネットワーク環境を構築し，問題なく使用できることを評価した．また，セキュリティポリシーの都合から，電話による多要素認証にも対応できることを確認した．
7.2 今後の展望本論では，1つのネットワークセグメント配下での評価を行った．香川大学では，インシデント発生時に端末の接続箇所を特定しやすくするためにL3スイッチなどによりネットワークセグメントが分割されている．今後は，そのような環境における提案方式の導入を目指し，機器や設定項目の選定を行う．
また，提案方式ではログが各機器に分散しており，接続状況を把握するためには各ログを付き合わせる必要がある．今後は，これらのログを一元にまとめ構成員のアカウントや接続中の認証制御スイッチなどを基準に，認証の成功件数などの情報を抽出できるログ分析基盤の構築を目指す．
提案手法は，端末の接続を起点に，構成員をMS365アカウントで認証して，スマートフォンアプリにて多要素認証を実施する．従って，最低限の構成として，認証制御スイッチ，ユーザ認証サーバ，学内AD，Entra MFA多要素認証機器が必要である．
A.1 ユーザ認証サーバに対する設定提案手法では，Microsoft NPS[11]をユーザ認証サーバとして使用した．以下に，NPSにおけるEntra MFAの設定手順を示す[11]．なお，本設定は，香川大学にて投入した2023年3月時点の物である．
（1）．下記のライブラリを入手し，「管理者として実行」から開き，NPSサーバにインストールする．
・Visual Studio 2015 の Visual C++ 再頒布可能パッケージ
・Visual Studio 2013（X64）の Visual C++ 再頒布可能パッケージ
・Windows PowerShell 用 Microsoft Azure Active Directory モジュール バージョン 1.1.166.0
（2）．Test-NetConnectionコマンドなどで，NPSが下記のポート443/TCPに接続できることを確認する．
・https://strongauthenticationservice.auth.microsoft.com
・https://adnotifications.windowsazure.com
・https://login.microsoftonline.com
・https://credentials.azure.com
・https://provisioningapi.microsoftonline.com
・https://aadcdn.msauth.net
・https://www.powershellgallery.com
・https://go.microsoft.com
・https://aadcdn.msftauthimages.net
（3）．Azure PortalからAzure Active Directoryを開き，Azure AD Connectタブを選択し，NPSと同期状態が有効であることを確認する．
（4）．NPSに対し，MFA拡張機能[29]をインストールする．
（5）．PowerShellを管理者として開き，図A.1に示すコマンドを実行する．
（6）．Azure ADにログインし，テナントIDを入力する．
A.2 認証制御スイッチに対する設定図A.2～図A.3に，提案方式における，認証制御スイッチ（アラクサラネットワークス株式会社のAX-2630）[12]の設定を示す．
4.3.2項で発生した症状におけるログを図A.4に示す．
