技術記事・調査 2025/10/30

オンプレRADIUSレスでEAP-TLSを構築してみた──Soliton OneGate × Cisco Meraki Access Managerで実現するクラウド認証基盤

はじめに

企業ネットワークにおいて、セキュリティと運用効率の両立は年々重要性を増してきています。特に、データセンターの縮小やゼロトラストネットワークアクセスの導入が進む中で、従来のオンプレミスRADIUSサーバーに依存した認証基盤は、柔軟性や拡張性の面で限界を迎えつつあります。

Ciscoが提供するMeraki Access ManagerはMerakiデバイス（MRシリーズのアクセスポイントやMSシリーズのスイッチ）に対して、クラウドネイティブなネットワーク制御を提供する新しい選択肢として登場しました。

Access Managerは従来のオンプレミスのRADIUSサーバーを必要とせず、クラウド上で認証・認可を完結できる点が大きな特徴です。これにより、ユーザーやグループ、接続先のMerakiデバイス単位での詳細なアクセス制御が可能になります。

そこで本記事ではMicrosoft Entra IDをユーザー源泉として、Soliton OneGateのCA機能とAccess Managerを組み合わせて、クラウド完結でEAP-TLS認証を構成する方法を検証しました。

Access Managerの詳細な機能紹介は割愛しますが、ポイントは以下の通りです。

OneGateで発行した証明書を使ってWi-Fi認証を行う
Entra IDとアカウント、グループの同期を行い、ユーザー属性に基づく認可制御を実現
オンプレRADIUSレスで構成できるため、機器構成がシンプル

本記事では、構成の全体像から設定手順、運用の注意点までを実際の検証結果に基づいて紹介いたします。

2025年10月現在、日本ではAccess ManagerをEarly Access版として無償で利用可能でした（General Availabiltyは2025年11月頃に予定されているようです）。そこで今回はMeraki MRを使用して、Access Managerの使い勝手などを検証してみました。

Access ManagerでEAP-TLS認証をするために

今回の検証では、下記の構成でEAP-TLS認証環境を構築していこうと思います。

Wi-Fi認証基盤：Meraki Access Manager
クライアント証明書発行などの証明書管理（CA）：Soliton OneGate
ユーザー情報源泉：Entra ID
アクセスポイント：Meraki MR
端末：Windows 11 24H2

機器の構成イメージは次の通りとなります。

Access Managerを設定する前に、まずはRADIUS認証についておさらいしましょう。RADIUS認証は「認証（Authentication）」、「認可（Authorization）」、「課金（Accounting）」の3つの要素から構成されており、これらの頭文字を取って「AAA（トリプルエー）フレームワーク」と呼ばれます。

クライアント証明書を用いるEAP-TLS認証はAAAフレームワークにおいて主に以下の2つの役割を担います。

認証（Authentication）
「あなたは誰？」の検証を行います。
具体的にはクライアント証明書が信頼されたCA（認証局）から発行されているか、有効期限内か、失効していないかなどの確認します。
認可（Authorization）
「あなたに何を許可する」を決定します。
ユーザー名、グループ名などの情報や、接続元のSSID、MerakiデバイスのIPアドレスといった属性に基づいて、ネットワークへのアクセスを「許可」、「制限付きで許可（ネットワークの制限あり）」、「拒否」を判断します。

これらの処理を経て、クライアントのネットワーク接続可否が決定されます。
なお課金（Accounting）は接続時間や通信量を記録するフェーズであり、EAP-TLS認証の可否判断に直接は関与しません。

補足となりますが、FreeRADIUSのような一般的なRADIUSサーバーでは、EAP-TLS認証でCN(Common Name)やSAN(Subject Alternative Name)の値が認可フェーズで使用されるわけではありません。多くの場合、サプリカント（クライアント端末）が送信する「EAP-Identity」の値をRADIUSクライアント（アクセスポイントなど）が「User-Name」属性に格納してRADIUSサーバーへ送信し、この「User-Name」を元に認可処理が行われます。

少々話が逸れましたが、本題に戻ります。

Access ManagerもこのAAAフレームワークに沿って動作します。
認証フェーズ用に信頼する外部CAを登録、認可フェーズ用にユーザーやグループをMicrosoft Entra IDから同期して、それらを使ってアクセスルールを設定していきます。

信頼するCAを設定する

今回はSoliton OneGate（以下、OneGate）のCAを信頼するCAに登録し、OneGateのクライアント証明書を使ってEAP-TLS認証できるよう設定します。

CA証明書のダウンロード

OneGateの管理ページにログインして、[証明書管理]-[CA情報]をクリックします。
ページ下部の「CA証明書ファイルのダウンロード」欄の「PEM形式」をクリックして、CA証明書をダウンロードして保存しておきます。

Access Managerにアップロードする

Merakiダッシュボードにて[アクセスマネージャ]-[証明書]をクリックします。
「EAP-TLS」タブの「＋ Upload CA certificaties」をクリックします。
「Upload full trusted certifate chain within a single file」にダウンロードしておいたOneGateの証明書ファイルをドラックアンドドロップして「次へ」をクリックします。
トラストアンカー（上位のCAを信頼したら、その下位の中間CAも信頼する）の設定画表示されます。OneGateの場合には階層構造になっていませんので、表示されているCAにチェックをいれて「完了」をクリックします。
しばらくすると「カスタム証明機関」にインポートしたCA証明書が表示されます。状態が無効になっていると認証に使用することができませんので、ミートボールメニューから「編集」をクリックします。
「状態」のスイッチを「有効」にして、画面下部の「保存」をクリックします。

Access Managerにユーザー、グループを登録する

Access Managerにユーザーやグループを登録し、認可フェーズで使用できるようにします。

ユーザーの登録はMerakiダッシュボードで手動にて登録か、Entra IDから同期する方法の2つがありますので、今回はEntra IDから同期させます。Entra IDのライセンスは特に制限は無いようで、手元ではFree、P2の２つで利用できることを確認しています。

Entra IDにアプリを登録

Entra IDにAccess Managerへユーザー、グループ情報を同期するためのアプリケーションを作成します。

Microsoft Entra管理センターにサインインして[Entra ID]-[概要]を開き、「テナントID」をコピーしてメモ帳などに貼り付けておきます。
[Entra ID]-[アプリの登録]を開き「＋新規登録」をクリックします。
名前を入力して、サポートされているアカウントの種類では「この組織ディレクトリティ含まれるアカウント（規定のディレクトリのみ -シングルテナント）」を選択して「登録」をクリックします。
アプリが登録されたら「概要」を開いて「アプリケーション（クライアント）ID」の値をコピーしてメモ帳などに貼り付けておきます。
[管理]-[証明書とシークレット]の「クライアントシークレット」タブを開き「新しいクライアントシークレット」をクリックします。
説明欄、有効期限を設定して「追加」をクリックします。
シークレットが生成されるので「値」欄のコピーをクリックしてシークレットをコピーしてメモ帳などに貼り付けておきます。
[管理]-[APIのアクセス許可]を開き「アクセス許可の追加」をクリックします。
「Microsoft API」タブの「Microsoft Graph」をクリックします。
「アプリケーションの許可」をクリックし、「Group.Read.All」と「User.Read.All」にチェックを入れて「アクセス許可の追加」をクリックします。
「規定のディレクトリに管理者の同意を与えます」をクリックします。
「はい」をクリックします。
「状態」欄が「既定のディレクトリに付与されました」となっていることを確認ます。

Access ManagerにIdPを登録する

作成したEntra IDのアプリをAccess Managerに登録して、ユーザー並びにグループを同期させます。

Merakiダッシュボードで[アクセスマネージャ]-[ユーザ]を開いて「IdP作成」をクリックします。
「名前」を入力し（今回は「Entra ID」としました）、「ディレクトリ（テナント）ID」、「アプリケーション（クライアント）ID」、「クライアントシークレット値」欄にEntra IDで生成してコピーしておいた値を入力して「接続テスト」をクリックします。「Connection valid」と表示されたら「保存」をクリックします。
[アクセスマネージャ]-[ユーザ」を開くと「ユーザー」タブにはEntra IDのユーザーが、「ユーザーグループ」タブにはEntra IDのグループが表示されています。

Entra IDからユーザー、グループを同期してみたところ、下記のような多少のクセがあることがわかりました。

Entra IDの全ユーザー、全グループが同期されます
- 特定のユーザーグループだけ同期させたいということはできません。
ネストの概念がないので、アクセスルールに設定することができるグループはユーザーが直に所属しているものだけになります
- 上記画像の「Meraki利用者」グループにはEntra ID上では「社員」と「アルバイト」の2つのグループが所属されていますが、Access Manager上では社員グループとアルバイトグループに所属しているユーザーはMeraki利用者グループのメンバーになっていませんでした。
Merakiダッシュボードに表示されるユーザー名はEntra IDのメールアドレス属性になります
- メールアドレス属性がないユーザーは表示名属性がユーザー名になります。
EAP-TLS認証の認可処理でのユーザー名のマッピングはクライアント証明書のCNの値とEntra IDのuserPrincipalName属性を紐づけますので、クライアント証明書の発行を発行する際にCNがuserPrincipalNameとなるようにしてください
- FreeRADIUSと異なりEAP-Identity値は使いません。
- Entra IDからSoliton OneGateにユーザー同期している場合には、利用者名がデフォルトでuserPrincipalName属性になり、OneGateからクライアント証明書を発行した場合にはCNにUserPrincipalNameが入ります。

アクセスルールを設定する

アクセスルールは、Access ManagerでどのようにRADIUS認証を行うかを設定する項目です。これまでにCAの信頼と、ユーザー・グループの同期を設定しましたので、これらを組み合わせて認可フェーズのルールを設定します。

この設定は例えば、信頼するCAから発行されたクライアント証明書を持った端末が〇〇拠点のMerakiデバイスに接続した場合

Entra ID上で「社員」グループに所属しているユーザーであれば接続を可する
Entra ID上で「アルバイト」グループに所属しているユーザーであれば接続を可として、VLAN10にする

など、ユーザーとグループを使ったネットワーク制御も行うことができます。

今回は、「信頼されたCAから発行したクライアント証明書を持った端末からのEAP-TLS認証が行われた場合、Entra ID上で社員グループであれば接続可」と言う設定を行うことにします。

なお、この設定は解像度が低いディスプレイを使用している場合はプルダウンメニューが表示しきれないケースがあることを確認しておりますので、表示しきれない場合にはブラウザの表示をズームアウトするか、もしくは4Kモニターなど解像度が大きいディスプレイをご利用ください。解像度が低いディスプレイで表示したためにプルダウンメニューの一部がバナーに隠される例

Merakiダッシュボードにて[アクセスマネージャ]-[アクセスルール]にて「ルールを追加」をクリックします。
ルール設定画面が表示されるので「名前」を入力し、状態を「有効」にします。
「何が一致しているのか」欄で、属性ソース１のプルダウンメニューを開き「Endpoint Certificate」を選択します。
「グループまたは属性」欄が追加されますので、下記のように設定し、「属性ソース追加」をクリックします。
- 属性選択：Issuer - Common Name
- Operator：任意（厳密性を求めるならEquals）
- Type value：CA証明書のCA名
「属性ソース2」が追加されますので「Network Access」を選択し、下記のように設定して「属性ソース追加」をクリックします、。
- 属性選択：EAP Protocol
- Type value：EAP-TLS
「属性ソース3」が追加されますのでをAccess Managerに登録したIdPディレクトリ名（今回は「Entra ID」と言う名前で登録されています）を選択し、下記のように設定します。
- 属性選択：Access Managerに登録したIdPディレクトリ名（今回はEntra ID）
- Operator：Match allかMatch Anyのどちらか。
  Type valueが複数ある場合、Match allだと全部グループに所属している（AND条件）、Match anyだと選択されたどれかのグループに所属している（OR条件）となります
- Type value：社員
認可項目でアクセス許可を「アクセス許可」にして「保存」をクリックします。（「条件付きアクセス許可」にすると、VLANを切り替える、ポリシーをつけるなどの制御を行うこともできます）
「アクセス拒否」より上にルールが追加されました。
このアクセスルールは上から順に評価されますので、アクセス拒否より下に作られてしまった場合には、ドラックしてアクセス拒否より上にもってきます。

Merakiデバイスの認証先をアクセスマネージャにしてEAP-TLS認証をテストする

Access Mangerが有効になると、Merakiデバイスの認証先をアクセスマネージャにすることができますので、実際にEAP-TLS認証ができるのかを確認してみます。

Merakiデバイスの認証先をアクセスマネージャに設定する

手元のMeraki MRで新規にSSIDを設定して、認証先をアクセスマネージャにします。

Merakiダッシュボードにて[ワイヤレス]-[アクセス制御]をクリックします。
SSID欄のプルダウンメニューから未設定のSSIDを選択して、SSID名（今回はAccessManagerTestにしました）を入力してSSIDステータスを「有効」にします。
セキュリティ欄にて「エンタープライズ認証」を選択してプルダウンメニューより「アクセスマネージャ」を選択します。
その他WPA暗号化（※2025年9月現在、Access Managerで使用されるサーバー証明書およびサーバー証明書発行元のCAの証明書がCNSA Suiteを満たしておらず、WAP3 Enterprise 192-bit modeの要件を満たしていませんでした）などを適宜設定して「保存」をクリックします。

Windows 11からMerakiにWi-Fi接続をしてEAP-TLS認証を行ってみる

Windows 11端末にて、OneGateから発行されたクライアント証明書をインポートして、サプリカントの設定を行ってMerakiでEAP-TLS認証するように設定します。

クライアント証明書のインポート

OneGateで招待コードを発行してSoliton KeyManagerでクライアント証明書をユーザー証明書ストアにインポートします。（詳細な手順は割愛）Entra IDからSoliton OneGateに同期したユーザーに対して証明書発行のための招待コード発行

Soliton KeyManagerを使って証明書を取得

Access Managerのサーバー証明書発行元とRADIUSサーバーホスト名の確認

サプリカントでRADIUSサーバーのサーバー証明書の検証を行うことも可能です。

Wi-Fiの認証先をAccess ManagerをAccess Managerにしている場合、Merakiダッシュボードの[アクセスマネージャ]-[証明書]を開いて「RADIUS CA証明書ダウンロード」をクリックすると、CA証明書と説明ファイルのテキストがZIPになったファイルをダウンロードすることができます。

2025年9月現在、Access Managerで使用されているサーバー証明書の発行元CAのCA証明書はMicrosoft の信頼できるルートプログラムに登録されているIndenTrust Commercial Root CA 1となっていました。Windows Updateが行えないようなクローズド環境等で、端末にIdenTrust Commercial Root CA 1が　入っていない場合は、ZIPファイル内のCA証明書を信頼されたルート証明機関のストアにインポートしておいてください。Windows 11 24H2へのCA証明書インポート例
またこのZIPファイルにはReadme.txtも含まれており、その中にサーバー証明書のCNチェックの値の記載があります。この値はサプリカントの設定を行う時に利用します。ZIPファイルに含まれていたReadme.txtの内容
赤枠で囲ったところが、サプリカントの設定で使用するサーバー証明書のCNチェックの値

サプリカントの設定

Windows 11 24H2でEAP-TLS認証のWi-Fi設定を行います。

WindowsボタンをクリックしてWi-Fi設定を開きます。
「既知のネットワーク管理」をクリックします。
「ネットワークを追加」をクリックします。

MRにしたWi-Fi設定に基づいて設定を行い「保存」をクリックします。

項目	値
ネットワーク名	MRに設定したSSID名です。今回はSSIDをAccessManagerTestとしましたので、その値を入れます。
セキュリティの種類	MRに設定した「WPA暗号化」の設定になります。今回は「WPA3のみ」としましたので、「WPA3-エンタープライズ AES」を選択します。
EAPメソッド	「スマートカードまたはその他証明書（EAP-TLS）」を選択します。

追加されたSSIDの「＞」をクリックします。
高度なWi-Fiネットワークプロパティの「編集」をクリックします。
「セキュリティ」タブの「設定」をクリックします。

次のように設定して、「OK」をクリックします。

項目	値
接続のための認証方法	このコンピューターの証明書を使う
単純な証明書の選択を使う	チェックあり
証明書を検証してサーバーのIDを検証する	チェックあり（グレーアウトしています）
次のサーバーに接続する	チェックを入れて、MerakiダッシュボードからダウンロードしたZIPファイルに含まれていたReadme.txtに記載されていた値をExtensible Authentication Protocol (EAP) for network accessのServer certificate validationに記載されている「Connect to these servers」に従って記述します。例）Readme.txtに下記の記載が 1. .123456.radius.meraki.direct 2. eap.meraki.com の場合には .\.123456\.radius\.meraki\.direct;eap.meraki.comと入力します。 ※記載の仕方が難しいと感じられる場合には「次のサーバーに接続する」のチェックを外すことも可能です。
信頼されたルート証明機関	IndenTrust Commercial Root CA 1にチェック

「セキュリティ」タブの「詳細設定」をクリックします。
「認証モードを指定する」にチェックを入れて、「ユーザー認証」を選択して「OK」をクリックします。

これでサプリカントの設定が完了しましたので、実際にWi-Fiに接続してみます。うまく接続ができない場合には、設定を見直してみましょう。

なお、Access Managerの認証の結果についてはMerakiダッシュボードの[アクセスマネージャ]-[セッションログ]にてログが記録されています。内容を確認したい行をクリックすると詳細なログ情報が表示されます。

認証に失敗した場合などは、こちらの情報を元に設定を見直しをしてみてはいかがでしょうか。

クライアント証明書の失効

EAP-TLSなど電子証明書を用いた認証のメリットの一つは、端末の盗難・紛失時にその証明書を失効させることで、他の正常な端末に影響を与えることなく、不正なアクセスを防止できる点です。
証明書を失効させるには、主に2つの方法があります。一つは、発行元CAがCRL（証明書失効リスト）を公開し、RADIUSサーバーなどの認証サーバーがそれを取得して検証する方法です。もう一つは、認証サーバーがOCSP（Online Certificate Status Protocol）を利用して、都度CAに証明書の有効性を問い合わせる方法です。

Access Managerについては、CRLやOCSPを用いた失効確認についての記載を検証中に確認できなかったため、別の方法を使って特定のクライアント証明書を拒否させてみました。

アクセスルールにシリアル番号を記載する

Access Managerでは認可処理に証明書のシリアル番号を使用することができますので、これを使ってCRLやOCSPに変わってアクセスを拒否させてみます。

CA側で該当のクライアント証明書を失効し、必要に応じてCRLを更新します。
OneGateでは毎日CRLは更新されますが、他の証明書認証を行っているサービスで即時アクセスを拒否させる場合は手動でCRL更新を行ってください。OneGate以外のCAを利用している場合であっても、同様に失効の処理を行ってください。
OneGateでの証明書失効
Merakiダッシュボードにて[アクセスマネージャ]-[アクセスルール]を開き、「ルールを追加」をクリックします。

下記のように設定して保存をクリックします。

項目	値
名前	ルール名を記載します例）接続拒否するシリアル番号
状態	有効
属性ソース	Endpoint certificate
属性選択	シリアルナンバー
Operator	Equals
Type value	接続拒否するクライアント証明書のシリアル番号を記載します
アクセス許可	アクセスを拒否

接続拒否するシリル番号ルールが追加されました。このルールが認可がアクセス許可となっているルールより上になっていること確認し、なってない場合にはドラッグハンドルで順番を入れ替えてください。（この画像の場合、認可が「アクセス許可」となっている「社員接続」ルールよりも上に「接続拒否するシリアル番号」ルールがあるので、該当のシリアル番号は接続が拒否されて、それ以外の証明書であればEntra ID上で社員グループに所属しているユーザーであれば接続が許可される）

この設定を行うことで、失効した証明書が入った端末がWi-Fi接続すると認可が拒否されて、Wi-Fiに接続されなくなります。接続拒否のシリアル番号を持つ証明書でWi-Fi接続

またMerakiダッシュボードの[アクセスマネージャ]-[セッションログ]にも、該当した認可ルールに従って接続が拒否されたことが記録されます。「接続拒否するシリアル番号」ルールに該当したセッションログ

なお、アクセスルールの1つの属性ルールに記載できる「グループまたは属性」は10個までになっているため、1つのアクセスルールには10個のシリアル番号までしか記載できません。

接続を拒否したいシリアル番号が10個以上になる場合には、アクセス拒否となるとアクセスルールを新たに作ってシリアル番号を記載する必要がありそうです。

また一般的なCAではCRLには有効期限内の証明書のシリアル番号のみが記載されるため、通常の運用ではCRLのリストが肥大化することはありませんが、Access Managerの接続拒否のシリアル番号の管理には証明書の有効期限の要素がなく、有効期限が切れたシリアル番号をアクセスルールから削除するような機能ががないため、運用を続けるとアクセスルールが肥大化していく可能性があります。それを避けるためにクライアント証明書の有効期限を1日など極端に短くしておき、端末の紛失や盗難にあってもアクセスルールには記載しなくても次の日にはWi-Fiに接続できないようにするという考え方もあるかもしれませんが、短い期間のクライアント証明書を使用するとなると端末へのインポート作業を頻繁に行う必要があり、利用者の負担がまします。

そのため、CRLやOCSPを利用しないシステムの場合には、クライアント証明書をインポートした端末の盗難や紛失には細心の注意を払って、なるべく失効運用しないで済むようにする必要があります。

ただ、なるべく失効運用しないで済む端末管理というのも、端末所有者任せでありあまり現実的ではないため、端末台数が多い環境であればAccess Managerではなく、CRLやOCSPなどCAの失効管理に任せられる外部のRADIUSサーバーを利用した方が良いかもしれませんね。

運用上の考慮点

改めて考慮点をまとめると次の通りです。

証明書の失効管理
現時点（2025年9月）ではCRLやOCSPに標準対応しておらず、失効した証明書を持つ端末のアクセス拒否は、アクセスルールで手動設定する必要があります。
管理の煩雑化
上記の理由から、端末台数が多い大規模環境では、失効ルールの管理が煩雑になる可能性があります。

まとめ

本記事では、Cisco Merakiの新たなクラウド認証基盤「Access Manager」の概要から、Soliton OneGateから発行した証明書とEntra IDと連携したEAP-TLS認証の具体的な設定方法までを解説しました。

Access Managerの主なポイント

RADIUSサーバー不要
オンプレミスにサーバーを構築することなく、クラウドでエンタープライズ認証を完結できます。
Soliton OneGateから発行した証明書を使ってEAP-TLS認証を行うことが可能
Entra ID連携
ユーザーやグループ情報をEntra IDから同期できるため、効率的なID管理が可能です。
柔軟なアクセス制御
アクセスルールにより、ユーザーの所属グループなどに応じてVLANやポリシーを割り当てる柔軟な認可制御が実現します。

Access Managerは、特に中小規模のネットワークにおいて、セキュリティと運用効率を両立させる非常に強力な選択肢です。導入を検討する際は、本記事で解説した証明書失効の運用方法も踏まえて計画することをおすすめします。

Soliton OneGate × Cisco Meraki Access Manager の組み合わせによるメリット

最後に総括として、OneGateとAccess Managerの組み合わせによるメリットを紹介させていただきます。

証明書発行から認証までをクラウドで一気通貫
OneGateはCA（認証局）として機能し、クライアント証明書の発行・管理をクラウド上で完結できます。Access Managerはその証明書を使ってEAP-TLS認証を行うため、オンプレミスのRADIUSやCAサーバーが不要になります。これにより、ネットワーク認証基盤の構築が非常にシンプルになります。
ユーザー属性と証明書の紐付けが自動化される
OneGateはEntra IDと連携してユーザー情報を同期できるため、証明書発行時にuserPrincipalNameをCNにすることが可能です。Access Manager側ではこのCNとEntra IDの属性を照合して認可処理を行うため、ユーザー管理と証明書管理が自然に連携します。
証明書の失効管理がOneGateで一元化できる
Access ManagerではCRLやOCSPによる失効確認が未対応ですが、OneGate側で証明書の失効処理を行い、CRLを更新することで、他のシステムとの整合性を保った失効管理が可能です。Access Managerではシリアル番号による拒否設定もできるため、OneGateで失効した証明書を即座に遮断する運用も実現できます。
招待コードによる安全な証明書配布
OneGateではユーザーごとに招待コードを発行し、Soliton KeyManagerを使って証明書を安全にインポートできます。これにより、証明書の配布・インストールがセキュアかつユーザーフレンドリーに行えます。
証明書ベースの認証でパスワードレスを実現
OneGate発行の証明書を使ったEAP-TLS認証により、パスワード不要のセキュアなWi-Fi接続が可能になります。これは、フィッシングやパスワード漏洩のリスクを大幅に低減する効果があります。
中小規模環境でも導入しやすい構成
OneGateとAccess Managerの組み合わせは、クラウドベースでありながら高度な認証・認可制御が可能なため、オンプレ機器の導入が難しい中小規模の環境でもスムーズに導入可能です。

また、今回は外部RADIUSによる認証連携には触れませんでしたが、ソリトンシステムズが開発する NetAttest EPS は、2002年より提供開始し国内シェアNo.1※の導入実績を誇る、信頼性と実績のあるRADIUS認証アプライアンスです。近年では Microsoft Azure などのIaaS環境にも対応し、クラウド中心のシステム構築に最適な認証基盤を提供します。大手企業、官公庁、大学など、業種や規模を問わず幅広く導入されており、安定稼働の実績を重視される場合には、ぜひ NetAttest EPS の採用をご検討ください。

※株式会社富士キメラ総研「2024コミュニケーション関連マーケティング調査総覧」RADIUSサーバー市場

参考記事

記事を書いた人

ソリトンシステムズソリューションアーキテクト小林

ソリトンシステムズで20年以上エンジニア職についておりベテランの域に着きつつありますが、IT業界は目まぐるしく進歩しており、まだまだ修行中です。うなぎ職人の「串打ち3年、裂き8年、焼き一生」と同じで、IT技術もまた奥深く、一生探求し続ける必要を感じています。本サイトでは弊社製品の話題を中心にしていますが、弊社製品に限らず色々なことにトライして、皆様の業務、もしくは個人的な興味にちょっとしたヒントをお届けできればと思います。よろしくお願いいたします。