サーバー設定
サーバー設定は https://YOURNAME.radius-as-a-service.com/settings/server で利用できます
ポートとIPアドレス
概要
RADIUSaaS は、ユーザーに安全なクラウドベース認証を提供するために RadSec サービスを運用しています。さらに、ハードウェアやソフトウェアの制約などによりネットワーク環境で RadSec を利用できないお客様向けに、RADIUSaaS は RADIUS から RadSec へのプロトコル変換を処理する RADIUS プロキシを提供しています。
RadSec サービスと RADIUS サービスはいずれも、インターネット経由でどこからでもお客様のネットワーク機器やサービスが当社のサービスと通信できるようにするパブリック IP アドレスを提供します。これらのサービスは、それぞれ固有の登録ポートで動作します。
RadSec / TCP

RadSec DNS
RadSec サービスに到達するための DNS エントリです。
サーバー IP アドレス
これは RadSec サービスのパブリック IP アドレスです。
RadSec ポート
これは RadSec の登録ポートです: 2083
フェイルオーバーと冗長性
より高いレベルの冗長性が必要な場合は、お客様のインスタンスに対して複数の RadSec エンドポイントを設定し、追加の IP アドレスを提供できます。このサービスには追加費用が発生することにご注意ください。

重要な点として、RADIUSaaS は フェイルオーバーを提供しません RadSec エンドポイント間では。代わりに、このフェイルオーバーは通常、以下の Meraki を使用した例のように、お客様のネットワーク機器側で実装されます。
可視性を高め、追加サービス(DNS)への依存を減らすため、フェイルオーバーのシナリオは DNS ではなく IP アドレスを使用して構成することを推奨します。
この構成では、2 つの RadSec IP アドレスが優先順に一覧表示されます。Meraki がいずれかの IP アドレスに到達できない場合、通常はさらに 2 回試行した後、次のアドレスに進みます。Meraki(または他の)システムのフェイルオーバー機能の詳細については、お使いのリソースをご確認ください。

RadSec 設定
以下の設定は、お客様の RADIUSaaS インスタンスへの RadSec 接続の特定の側面を制御します。
最大 TLS バージョン
この設定は、RadSec インターフェースの最大 TLS バージョンを制御します。最小バージョンは 1.2 に固定されており、デフォルトの最大値は 1.3 に設定されています。
TLS 1.3 には、ハンドシェイク完了前に追加の資格情報を要求できるポストハンドシェイク認証メカニズムなど、1.2 に対するいくつかの利点があります。これは、次に説明する RadSec 証明書の検証チェック設定にとって重要です。
RadSec 証明書の失効チェック
この設定は、すべての RadSec 接続に対して失効チェックを実行するかどうかを決定します。失効チェックの検証方法は、クライアント認証証明書に使用される方法とはわずかに異なります。
RadSec を適切に動作させるために、アクセスポイント、スイッチ、VPN サーバーなどのネットワークデバイスは、RadSec サーバーへの TLS で保護された接続を確立します。RadSec の展開では通常、相互 TLS(mTLS)が使用され、TLS ハンドシェイク中に両方のピアが X.509 証明書を使用して相互に認証します。RADIUSaaS の実装では mTLS が強制されます。
RadSec クライアント証明書の有効性と失効状態を判断するには、TLS 認証プロセスの一部としてクライアントが証明書を提示する必要があります。証明書を受信して初めて、失効チェック(たとえば CRL や OCSP 経由)を実行できます。
TLS 1.2
TLS 1.2 は、初期ハンドシェイク中の相互 TLS 認証を、 CertificateRequest, Certificate、および CertificateVerify メッセージを使用してサポートします。クライアント認証が必要で正しく強制されている場合、TLS セッションが確立される前、そして RADIUS トラフィックが交換される前に、RadSec クライアント証明書が提示、検証され、失効チェックが行われます。
ただし、TLS 1.2 ではオプションのクライアント認証も許可されており、再ネゴシエーションもサポートされています。その結果、一部の RadSec クライアント実装では、クライアント証明書を提示せずに初期ハンドシェイクを完了する場合があります。この動作は 実装固有のものであり、TLS 1.2 プロトコル自体の制限ではありません。
上記の動作を軽減するため、 RadSec 証明書の失効チェック 設定は最大 TLS バージョンが 1.2 に設定されている場合は無効化されます。なお、後で手動で再有効化できます。
TLS 1.3
TLS 1.3 は、相互 TLS 認証のためのより決定的で簡素化されたモデルを提供します。クライアント認証が要求されると、RadSec クライアント証明書は初期ハンドシェイクの一部として交換され、TLS 接続が確立される前に検証されます。 これにより、RadSec サーバーは失効状態を含めてクライアント証明書を即座に検証し、証明書が無効または失効している場合はハンドシェイクを失敗させることができます。その結果、TLS 1.3 では、RadSec 接続に対してより厳格で予測可能な相互 TLS 認証の適用が可能になります。
この RadSec 証明書の失効チェック 設定は最大 TLS バージョンが 1.3 に設定されている場合、自動的に有効になります。

RADIUS / UDP
このセクションは、少なくとも 1 つの RADIUS プロキシを設定している場合に利用できます。各プロキシには個別のパブリック IP アドレスが用意されます。このセクションのパブリック IP アドレスは RADIUS プロトコルのみをサポートし、そのためポート 1812/1813 で待ち受けます。

サーバー IP アドレスと場所
これらの IP アドレスは、 RADIUS を UDP ポート 1812/1813 上でのみ待ち受けます。
RADIUS プロキシの地理的位置、およびそれぞれのパブリック IP アドレス。
共有シークレット
各 RADIUS プロキシ用の共有シークレットです。デフォルトでは、すべての RADIUS プロキシは同じ共有シークレットで初期化されます。

ポート
このセクションには、RADIUS 認証(1812)および RADIUS アカウンティング(1813)サービスの標準ポートが表示されます。
フェイルオーバーと冗長性
プロキシ冗長性
単一の RADIUSaaS プロキシでは冗長性は提供されない点にご注意ください。冗長性を確保するには、説明されているとおりに複数の RADIUSaaS プロキシを設定してください こちら.
プロキシ用 RadSec サービス冗長性
複数の RadSec インスタンスで RADIUSaaS を使用する場合、プロキシは利用可能なすべての RadSec インスタンスに接続するよう自動的に設定されます。RADIUSaaS プロキシは、最寄りの地域の RadSec サービスへの接続を優先します。そのサービスが利用できない場合、別の利用可能な RadSec サービスに切り替わります。
サーバー証明書
Customer-CA
デフォルトでは、RADIUSaaS は RADIUS サーバー証明書 を生成します。これは、この目的のためだけに当社サービス上で利用可能な認証局(CA)によって署名されています。これを Customer-CAと呼びます。Customer-CA はお客様ごとに一意です。
Customer-CA を作成するには、次の簡単な手順に従ってください:
次へ移動します 設定 > サーバー設定
クリック 追加
選択 RaaS に CA を作成させる
クリック 保存
作成後、Server Certificates の下に新しい証明書が表示されます

独自の証明書を持ち込む
もし Customer CAを使用したくない場合は、独自の証明書を最大 2 つまでアップロードできます。
SCEPman 発行のサーバー証明書
SCEPman Certificate Master を活用して新しいサーバー証明書を生成するには、次の手順に従ってください:
SCEPman Certificate Master の Web ポータルに移動します。
左側の Request Certificate を選択します
選択 (Web) Server 上部の
選択 フォーム
証明書を有効にしたいすべての Subject Alternative Names(SAN)を、カンマ、セミコロン、または改行で区切って入力します。説明されているとおりにサーバー証明書を生成し、 こちら 任意の FQDN を指定してください。デフォルトのサーバー証明書の SAN を調整することを推奨します。例:
radsec-<your RADIUSaaS instance name>.radius-as-a-service.com.次を設定します ダウンロードファイル形式 を PEM
選択 証明書チェーンを含める にして、証明書をダウンロードします。
EKU には必ず Server Authentication と Client Authentication の両方 を含めてください。
送信 して、新しいサーバー証明書をダウンロードします。
重要:パスワードは Certificate Master から復元できないため、一時的に控えておいてください。

新しいサーバー証明書を RADIUSaaS
にアップロードします。上記の手順で作成したサーバー証明書を追加するには、次へ移動します RADIUSaaS インスタンス > 設定 > サーバー設定 > 追加、 次に
選択 PEM または PKCS#12 エンコード証明書 (手順 5 で PKCS#12 を選択した場合、これには公開鍵と秘密鍵の両方が含まれます)
証明書ファイルをドラッグ&ドロップするか、クリックして参照してください
お使いの 秘密鍵
クリック 保存

のパスワードを入力してください。注意:デフォルトでは、SCEPman Certificate Master は 730 日間有効な証明書を発行します。これを変更したい場合は、SCEPman の ドキュメント.
証明書の有効化
サービス中断を防ぐため、サーバー証明書の有効期限を監視し、適時更新してください。
証明書は時々期限切れになったり、使用したい証明書の好みが変わったりするため、サーバーが使用する証明書を管理できることが重要です。 アクティブ 列には、現在サーバーが使用している証明書が表示されます。サーバーが使用する証明書を変更するには、選択したい証明書の行を展開して 有効化.
ダウンロード
お客様の サーバー証明書 をダウンロードするには、2 つの方法があります:
クリック CA 証明書をダウンロード を上部でクリックします。これにより、現在 信頼されているルート CA の アクティブな サーバー証明書が直接ダウンロードされます。
該当する行の ダウンロード アイコンをクリックします。

オプション 2 では、完全な証明書パスを表示するダイアログが開きます。 ルート証明書 は常に緑色でマークされます。

どちらの方法でも、ダウンロードされるルート証明書は base64(PEM)でエンコードされています。お使いのデバイス(例:WiFi コントローラー)がバイナリエンコード(DER)を必要とする場合は、 OpenSSL:
削除
証明書を削除するには、該当する行を展開してクリックし、 削除 選択を確認してください。
証明書の有効期限
RADIUS サーバー証明書を期限切れにしないでください。認証が機能しなくなります。
証明書は時々期限切れになります。証明書の有効期限の 5 か月前になると、ダッシュボード上でその横に警告サインが表示され、通知されます。

アクティブな RADIUS サーバー証明書の横に三角形が表示されている場合は、このガイドに従って更新してください:
サーバー証明書の更新SCEPman 接続
SCEPman Enterprise Edition のみ
バージョン 3.0 以上に適用
SCEPman 接続設定は、RaaS インスタンスをお客様の SCEPman インスタンスに直接接続するために設計されています。この接続を構成すると、RaaS は次のタスクを実行します:
新しいサーバー証明書を作成して有効化する
更新プロセスを含め、このサーバー証明書を管理します。

この接続を確立するには、次の手順に従ってください:
表示されている API トークンをコピーします。
この ガイド に従って SCEPman App Service に移動し、 AppConfig:RADIUSaaSValidation:Token という新しい環境変数を作成し、先ほどコピーしたトークンを値として使用します。
設定を適用して App Service を再起動します。
SCEPman URL フィールドに SCEPman インスタンスの URL を入力します。

クリック 接続をセットアップ。この操作により現在のサーバー証明書は無効化され、新しく作成された証明書を管理できるようになります。
セットアップが完了すると、2 つの新しいボタンが表示され、以前のボタンに置き換わります。

証明書をローテーション。このボタンは、利用可能な 2 つのスロット間でサーバー証明書をローテーションして有効化します。 Servercertificate-upload0 および Servercertificate-upload1.
接続を削除。 このボタンは、以前に構成した接続を削除します。この操作は元に戻せない点にご注意ください。接続を削除すると、トークンも削除されます。後で接続を再設定したい場合は、上記の手順を再度実行する必要があります。
最終更新
役に立ちましたか?