トラブルシューティング
接続の問題
クライアント表示
XML の誤り
サインインするには証明書が必要なため、接続できません。IT サポート担当者に連絡してください。
クライアントに認証用の証明書があり、正しい WiFi 構成プロファイル または XML.
信頼されたルートの問題
このネットワークに接続できません。
次のことを行ったことを確認してください:
RADIUS Server に、接続を許可する証明書を説明どおりに通知した こちら
アクティブな RADIUS Server 証明書を、説明どおりにクライアント上の信頼されたルートとしてインポートした こちら
接続を続けますか？
接続を続けますか？ この場所で Corporate WiFi が見つかるはずなら、そのまま接続してください。そうでない場合は、同じ名前の別のネットワークである可能性があります。
証明書の詳細を表示します。
クライアントが初回接続時に検証を必要としていて、このダイアログが表示されている場合:
WiFi プロファイルで RADIUS server certificate を参照し、サーバー証明書の SAN 属性 (FQDN) と共通名 (CN) を指定していることを確認してください:
サーバー側の表示
不明な CA
もしあなたの ログ 次のようなエラーメッセージが含まれている
原因としては次のものが考えられます:
サーバーでエラーが発生する
TLS Alert write:fatal:不明な CARADIUS サーバーは、認証に使用された証明書の発行者を認識していません。説明どおりに CA を追加してください こちら.
証明書が不明
macOS（および場合によっては他の Apple プラットフォーム）を使用していて、さらにあなたの ログ 次のようなエラーメッセージが含まれている
原因としては次のものが考えられます:
復号エラー | アクセス拒否
もしあなたの ログ 次のようなエラーメッセージが含まれている
…その場合は、Windows マシン上の TPM ソフトウェアの不具合である可能性が高いです。詳細は次にあります。 SCEPman ドキュメント.
もしあなたの ログ
…原因は 2 つ考えられます。1 つは、WiFi プロファイルがサーバー検証用の誤ったルート証明書を参照していることです。プロファイルが正しく設定されていることを確認してください。それでもこの問題が続く場合は、KSP を次に設定してみてください ソフトウェア KSP.
Key Storage Provider (KSP) の設定は、エンドユーザー証明書の秘密鍵の保存場所を決定します。TPM に保存する方がソフトウェア保存よりも安全です。TPM は鍵の盗難を防ぐ追加のセキュリティ層を提供するためです。ただし、 一部の古い TPM ファームウェア バージョンにバグがあり TPM ベースの秘密鍵で作成された一部の署名を無効にしてしまいます。そのような場合、この証明書は、Wi-Fi 接続や VPN 接続で一般的な EAP 認証には使用できません。影響を受ける TPM ファームウェアのバージョンは次のとおりです:
STMicroelectronics: 71.12, 73.4.17568.4452, 71.12.17568.4100
Intel: 11.8.50.3399, 2.0.0.2060
Infineon: 7.63.3353.0
IFX: Version 3.19 / Specification 1.2
このファームウェアで TPM を使用する場合は、ファームウェアを新しいバージョンに更新するか、鍵ストレージ プロバイダーとして「Software KSP」を選択してください。
相手側の動作が異常なため続行できません
ログに次のエラーを含む拒否がある場合 「相手側の動作が異常なため続行できません」 これは、主に信頼設定が正しくないために、クライアントが RADIUS サービスとの通信を停止したことを示しています。この場合、影響を受けているデバイス上の証明書を確認してください。
共有 RADIUS シークレットが間違っている
もしあなたの（プロキシ）の ログ 次のようなエラーメッセージが含まれている
その場合、a 経由で RADIUSaaS インスタンスに接続しようとしているアクセスポイントまたはスイッチのいずれかが RADIUS Proxy 不一致の 共有シークレット.
影響を受けているアクセスポイントまたはスイッチを特定するには、まずエラーメッセージを展開し、次を検索して RADIUS proxy を特定してください proxyip プロパティ。プロキシが分かったら、在庫情報と、ネットワークに接続できない特定の場所やデバイス グループに関する知識を使って、設定ミスのあるネットワーク デバイスを特定します。最後に、そのプロキシについて RADIUSaaS インスタンスで構成された値に一致するように共有シークレットを更新します。
CAPI2 ログを使用した接続問題のトラブルシューティング
Windows クライアントは Cryptographic API (CAPI2) サブシステムを使用して、EAP-TLS 認証中の証明書操作を処理します。接続が失敗し、クライアント UI と RADIUSaaS サーバー ログのどちらにも原因が明確に示されない場合、影響を受けるデバイスで CAPI2 ログを有効にすると、証明書検証の失敗、チェーン構築エラー、または秘密鍵アクセスの問題が明らかになることがあります。これらは通常は見えません。
手順 1: CAPI2 ログを有効にする
CAPI2 ログは既定で無効です。有効にするには:
開く イベント ビューアー: を押し Win + R、次を入力し
eventvwr.exe、次を押します Enter.左側のツリーで アプリケーションとサービス ログ.
展開します Microsoft → Windows → CAPI2.
右クリックして Operational を選択し ログを有効にする.
有効にすると、Windows はすべての CAPI2 イベントの記録を開始します。接続失敗を再現してください。次に Wi-Fi または有線ネットワークへの接続を試し、次の手順に進みます。
ヒント: データ収集後は、不要なディスク使用を避けるためにログを再度無効にしてください（Operational を右クリック → ログを無効にする）。
手順 2: 関連するイベントを見つける
問題を再現した後、次のログ ソースのイベントを探してください:
CAPI2
アプリケーションとサービス ログ → Microsoft → Windows → CAPI2 → Operational
WLAN AutoConfig
アプリケーションとサービス ログ → Microsoft → Windows → WLAN-AutoConfig → Operational
記録されたイベントに注目してください 接続失敗の試行時刻に。有用な指標には次のものがあります:
CAPI2 — 証明書チェーンの構築、失効確認、または秘密鍵アクセスに関連するエラー（例: イベント ID 11、70、90）。
WLAN-AutoConfig — 802.1X ネゴシエーションの結果を示すイベント（例: イベント ID 8001、8002、12013）。
手順 3: ログを書き出して送信する
確認用にログを送信するには:
イベント ビューアーで、次の場所のログを右クリックし、 Operational 下の CAPI2 を選択し すべてのイベントを名前を付けて保存…
ファイルを次の形式で保存し イベント ログ (*.evtx) 、たとえば次のような分かりやすい名前を付けます。
CAPI2_<device-name>_<date>.evtx.同じ手順を WLAN-AutoConfig → Operational ログに対して繰り返します。
両方の
.evtxファイルを https://www.radius-as-a-service.com/help/ まで送信してください。あわせて、影響を受けているデバイス、OS バージョン、問題が発生するタイミングを簡単に説明してください。
証明書の問題
証明書チェーンを検証できませんでした
独自のサーバー証明書を使用する場合、RADIUS サーバーは、他の参加者（Proxy、RadSec クライアント、接続を試みるエンドポイント）がサーバーの ID を検証できるように、完全な証明書チェーンを必要とします。 このメッセージが表示された場合は、CA 証明書をサーバー証明書の下のテキスト欄にコピー＆ペーストするか、リーフからルートまでのすべての証明書を含む PCKS8 証明書バンドルを作成してください。
管理ポータルの問題
ログイン
RADIUSaaS Web ポータル（"RADIUSaas Admin Portal"）にログインするには、次の要件を満たす必要があります:
技術管理者として指定した UPN/メールアドレスは、次のいずれかに対して認証可能である必要があります いずれかの Microsoft Entra ID (Azure AD)（ユーザーがネットワーク認証に RADIUSaaS を利用するテナントの ID である必要はありません）。
技術管理者として指定した UPN/メールアドレスは、説明どおりに RADIUSaaS インスタンスに登録されている必要があります こちら。それが初期管理者である場合は、 お問い合わせください 登録したユーザーが間違っていると思われる場合。
UPN/メールアドレスの背後にある Microsoft Entra ID (Azure AD) ユーザー オブジェクトには、RADIUSaaS Enterprise Application に次の権限を付与する権限が必要です（下のスクリーンショットを参照）:
読み取り 基本ユーザー プロファイル
維持 アクセス権を付与したデータへのアクセスを維持する（リフレッシュ トークン要求を許可）
Microsoft Entra ID (Azure AD) ユーザーに必要な権限を付与する権限がない場合、対応する Enterprise Application は Microsoft Entra ID (Azure AD) に自動作成されません。これを回避するには、IT 部門に依頼して必要な権限をユーザーに付与してもらってください。
Intune 構成の問題
プロファイルの割り当て
Wi-Fi、SCEP、および信頼された証明書のプロファイルが異なるグループに割り当てられていると、Wi-Fi 構成は展開されません。状態が「Pending」と表示されることもあれば、まったく状態が表示されないこともあります。次のいずれかを使用してください 同じグループ、または必要に応じて「All devices」/「All users」 を リンクされたすべてのプロファイル.
デバイス（"All devices" に割り当て）とユーザー証明書（"All users" に割り当て）を使用している場合は、SCEP ルート証明書プロファイルを "All users" と "All devices" の両方に割り当てることができます。
SCEP 証明書
Android
Android の新しいバージョンでは、Subject alternative name に UPN が必要なようです（デバイス証明書の場合も含む）。SCEP プロファイルにこれを追加してください（例: {{DeviceId}}@contoso.com）：
Wi-Fi プロファイル
Android
一般的なエラーコード: 0xc7d24fc5 または -942518331
重要なポイントは次のとおりです:
次を選択します Root CA 証明書 を サーバー検証 （重要: RADIUSaaS のサーバー証明書をアップロードしないでください） — および —
次を定義します RADIUS サーバー名
注: このフィールドには文字数制限があるようです。問題を解決するには、サブドメインを含めずに "radius-as-a-service.com" のようにドメイン部分だけを使うとよいでしょう（"contoso.radius-as-a-service.com" の代わりに）。
Android の開発者は 次を構成する必要があると述べています: Root CA 証明書の両方と、および次のいずれか: ドメイン接尾辞の一致 または代替サブジェクトの一致」. そのため、MDM は Wi-Fi 構成にルート証明書を追加した後で、「setAltSubjectMatch」または「setDomainSuffixMatch」を使用できます。Intune では「setDomainSuffixMatch」が使われているようで、「radius-as-a-service.com」だけで十分です。
場合によっては アイデンティティ プライバシー が必要です（例: Android キオスク デバイス / Android Enterprise 専用で見られます）
最終更新
役に立ちましたか？