> For the complete documentation index, see [llms.txt](https://docs.radiusaas.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.radiusaas.com/ja/sono/troubleshooting.md). # トラブルシューティング ## 接続の問題 ### クライアント表示 #### XML が正しくない {% hint style="warning" %} サインインに証明書が必要なため接続できません。IT サポート担当者に連絡してください。 {% endhint %} ![](https://content.gitbook.com/content/SWU1DQ4UGkqER7uGNUOm/blobs/k8FhkMHpqVOne7UXpLzC/image.png) クライアントに認証用の証明書があること、および正しい [WiFi 構成プロファイル](/ja/purofairuno/microsoft-intune/wifi-profile.md) または [XML](/ja/ptaru/settings/trusted-roots.md#xml). #### 信頼されたルートの問題 {% hint style="warning" %} このネットワークに接続できません。 {% endhint %} ![](https://content.gitbook.com/content/SWU1DQ4UGkqER7uGNUOm/blobs/g3XbpcPNSLDJPrr96nYr/image.png) 次のことを実施済みであることを確認してください: * 記載どおり、接続を許可する証明書を RADIUS Server に通知した [こちら](/ja/ptaru/settings/trusted-roots.md#add) * 記載どおり、アクティブな RADIUS Server 証明書をクライアントの信頼されたルートとしてインポートした [こちら](/ja/purofairuno/microsoft-intune/trusted-root.md#to-add-a-trusted-root-profile-for-your-clients) * 次を確認してください: [ログ](/ja/ptaru/insights/log.md#logs)。エラーの詳細な説明があります。おそらく [これ](/ja/sono/troubleshooting.md#fatal-decrypt-error) の問題です。 #### 接続を続行しますか? {% hint style="warning" %} 接続を続行しますか? \ この場所で Corporate WiFi が見つかるはずであれば、そのまま接続してください。そうでない場合は、同じ名前の別のネットワークかもしれません。 証明書の詳細を表示します。 {% endhint %} クライアントが初回接続時に検証を必要としており、このダイアログが表示される場合は: ![](https://content.gitbook.com/content/SWU1DQ4UGkqER7uGNUOm/blobs/8uYG1oXtvKS2IJkLbQyL/image.png) WiFi プロファイルで RADIUS server 証明書を参照し、サーバー証明書の SAN 属性 (FQDN) と共通名 (CN) を指定していることを確認してください:

サーバー証明書の SAN 属性 (FQDN) と共通名 (CN) を表示しています

### サーバー表示 #### 不明な CA もしあなたの [ログ](/ja/ptaru/insights/log.md#logs) 以下に示すものと似たエラーメッセージが含まれている場合 ``` ERROR: (14872) eap_tls: ERROR: SSL によるエラー 20 : ローカルの発行者証明書を取得できません ERROR: (14872) eap_tls: ERROR: TLS Alert write:fatal:不明な CA エラー: tls: TLS_accept: エラーの発生 Auth: (14872) ログインが正しくありません (eap_tls: SSL によるエラー 20 : ローカルの発行者証明書を取得できません): [host/8dc38402-20fb-41db-a8f3-4e4e95637173/] (from client contoso port 1 cli 18-9K-EA-0H-7F-C5) ``` 次のような根本原因が考えられます: * クライアントがエラーを返す `TLS Alert read:fatal:不明な CA` * お使いのクライアントは次を認識していません: **サーバー証明書** を認識できないため接続を拒否します。次を追加したことを確認してください: **サーバー証明書** 記載どおり [こちら](/ja/purofairuno/microsoft-intune/trusted-root.md#adding-a-trusted-root-profile-for-your-clients). * 新しい **サーバー証明書** を変更/追加しましたが、クライアント上の XML プロファイルは古いものを使用しています。その場合は、WiFi/Wired プロファイルを更新したか、または再生成したことを再確認してください: [XML](/ja/ptaru/settings/trusted-roots.md#xml) 証明書を追加した後、それをクライアントにプッシュしました。 * サーバーがエラーを返す `TLS Alert write:fatal:不明な CA` * RADIUS server は認証に使用された証明書の発行者を認識していません。記載どおり CA を追加してください [こちら](/ja/ptaru/settings/trusted-roots.md#add). #### 証明書が不明 macOS (および他の Apple プラットフォームの可能性もあります) を使用しており、あなたの [ログ](/ja/ptaru/insights/log.md#logs) 以下に示すものに似たエラーメッセージが含まれている場合 ``` eap_tls: (TLS) TLS - Alert read:fatal:certificate unknown ``` 次のような根本原因が考えられます: * どこかにスペース文字が含まれています: **証明書サーバー名** あなたの [WiFi](/ja/purofairuno/microsoft-intune/wifi-profile/apple-devices.md) または [有線](/ja/purofairuno/microsoft-intune/wired-profile/mac.md) 構成プロファイル内に #### 復号エラー | アクセスが拒否されました もしあなたの [ログ](/ja/ptaru/insights/log.md#logs) 以下に示すものと似たエラーメッセージが含まれている場合 ``` Auth: (312) ログインが正しくありません (eap_tls: TLS Alert write:fatal:復号エラー): [host/00128t09-cbna-469c-9768-2783d28eikl9/] (from client contoso port 1 cli 84-FD-D1-8C-0E-33) ERROR: (320) eap_tls: ERROR: TLS Alert write:fatal:復号エラー エラー: tls: TLS_accept: エラーの発生 ``` ... その場合は、Windows マシン上の TPM ソフトウェアのバグである可能性が高いです。詳細は [SCEPman のドキュメント](https://docs.scepman.com/certificate-deployment/microsoft-intune/windows-10#key-storage-provider-ksp-enroll-to-trusted-platform-module-tpm-ksp-otherwise-fail). ログに次のようなものが表示される場合は [ログ](/ja/ptaru/insights/log.md#logs) ``` ERROR: (95878) eap_tls: ERROR: (TLS) Alert read:fatal:アクセスが拒否されました Auth: (95878) ログインが正しくありません (eap_tls: (TLS) Alert read:fatal:アクセスが拒否されました): [host/kad933-161d-4aa8-aeaa-b5a4d3d53b12] ERROR: (95717) eap_tls: ERROR: (TLS) Alert read:fatal:アクセスが拒否されました ``` ... 2 つの理由が考えられます。1 つは、WiFi プロファイルがサーバー検証用に誤ったルート証明書を参照していることです。プロファイルが正しく設定されていることを確認してください。そうであり、それでもこの問題が続く場合は、KSP を [**ソフトウェア KSP**](https://docs.scepman.com/certificate-deployment/microsoft-intune/windows-10#key-storage-provider-ksp-enroll-to-trusted-platform-module-tpm-ksp-otherwise-fail). {% hint style="warning" %} 設定 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: バージョン 3.19 / 仕様 1.2 このファームウェアで TPM を使用する場合は、ファームウェアを新しいバージョンに更新するか、キー ストレージ プロバイダーとして「ソフトウェア KSP」を選択してください。 {% endhint %} #### ピアの動作に問題があるため続行できません ログに次のエラーを含む拒否がある場合: *「ピアの動作に問題があるため続行できません」* これは、信頼設定が正しくないことが主な原因で、クライアントが RADIUS サービスとの通信を停止したことを示します。この場合、影響を受けるデバイスの証明書を確認してください。 #### 共有 RADIUS シークレットが正しくない お使いの (プロキシ) が [ログ](/ja/ptaru/insights/log.md#logs) 以下に示すものと似たエラーメッセージが含まれている場合 ``` - メッセージ認証子、値が誤っている - buf2radmsg: メッセージ認証に失敗しました - radsrv: default (8.222.246.231) からの要求を無視しています。検証に失敗しました ``` その場合、RADIUSaaS インスタンスに RADIUS Proxy を介して接続しようとしているアクセスポイントまたはスイッチのいずれかが [RADIUS Proxy](/ja/ptaru/settings/settings-proxy.md) 不一致の [Shared Secret](/ja/ptaru/settings/settings-server.md#properties-1). 影響を受けているアクセスポイントまたはスイッチを特定するには、まずエラーメッセージを展開して次を検索し、RADIUS プロキシを特定します: `proxyip` プロパティ。プロキシがわかったら、在庫情報と、ネットワークに接続できない特定の場所やデバイスグループに関する知識を使って、設定ミスのあるネットワークデバイスを特定してください。最後に、そのプロキシに対して RADIUSaaS インスタンスで設定されている値に一致するよう共有シークレットを更新します。 ### CAPI2 ログによる接続問題のトラブルシューティング Windows クライアントは **Cryptographic API (CAPI2)** サブシステムを使用して、EAP-TLS 認証中の証明書操作を処理します。接続に失敗し、クライアント UI と RADIUSaaS サーバーのログのどちらにも根本原因が明確に示されない場合、影響を受けるデバイスで CAPI2 ログを有効にすると、証明書検証の失敗、証明書チェーン構築エラー、または秘密鍵へのアクセス問題など、通常は見えない情報を明らかにできます。 *** #### **手順 1: CAPI2 ログを有効にする** CAPI2 ログは既定で無効です。有効にするには: 1. 開く **イベント ビューアー**: を押して **Win + R**、次を入力し `eventvwr.exe`、次に押します **Enter**. 2. 左側のツリーで、次を展開します **アプリケーションとサービス ログ**. 3. 展開 **Microsoft → Windows → CAPI2**. 4. 右クリックして **運用** を選択します **ログを有効にする**. 有効にすると、Windows はすべての CAPI2 イベントの記録を開始します。接続失敗を再現してください。次に Wi-Fi または有線ネットワークへの接続を試し、次の手順に進みます。 > **ヒント:** データ収集後にログを再度無効にします (**運用 を右クリック → ログを無効にする**) 不要なディスク使用を避けるためです。 *** #### **手順 2: 関連するイベントを見つける** 問題を再現した後、次のログソースでイベントを探してください: | ログソース | イベント ビューアー内のパス | | ------------------- | ------------------------------------------------------------- | | **CAPI2** | アプリケーションとサービス ログ → Microsoft → Windows → CAPI2 → 運用 | | **WLAN AutoConfig** | アプリケーションとサービス ログ → Microsoft → Windows → WLAN-AutoConfig → 運用 | 記録されたイベントに注目してください **接続失敗の試行時に**。有用な指標には次が含まれます: * **CAPI2** — 証明書チェーンの構築、失効確認、または秘密鍵アクセスに関連するエラー (例: イベント ID 11、70、90)。 * **WLAN-AutoConfig** — 802.1X ネゴシエーションの結果を示すイベント (例: イベント ID 8001、8002、12013)。 *** #### **手順 3: ログをエクスポートして送信する** 確認用にログを送信するには: 1. イベント ビューアーで、次を右クリックします **運用** の下のログ **CAPI2** を選択します **すべてのイベントを名前を付けて保存...** 2. ファイルを次の形式で保存します: **イベント ログ (\*.evtx)** ファイルとして、わかりやすい名前を付けます。例: `CAPI2__.evtx`. 3. 同じ手順を **WLAN-AutoConfig → 運用** ログについて繰り返します。 4. 両方の `.evtx` ファイルをサポートチーム宛てに次の 影響を受けるデバイス、OS のバージョン、および問題が発生するタイミングの簡単な説明も添えてください。 ## 証明書の問題 ### 証明書チェーンを検証できませんでした
独自のサーバー証明書を使用したい場合、RADIUS server は、他の参加者 (Proxy、RadSec クライアント、接続を試みるエンドポイント) がサーバーの ID を検証できるように、完全な証明書チェーンを必要とします。 \ このメッセージが表示された場合は、テキストフィールド内のサーバー証明書の下に CA 証明書をコピーして貼り付けるか、先頭からルートまでのすべての証明書を含む PCKS8 証明書バンドルを作成してください。 ## Admin Portal の問題 ### ログイン RADIUSaaS Web ポータル (「RADIUSaas Admin Portal」) にログインするには、次の要件を満たす必要があります: * 技術管理者として指定した UPN/メールアドレスは、次に対して認証可能である必要があります: **いずれかの** Microsoft Entra ID (Azure AD) (RADIUSaaS をネットワーク認証に利用するユーザーが属する Tenant の ID である必要はありません)。 * 技術管理者として指定した UPN/メールアドレスは、記載どおり RADIUSaaS インスタンスに登録されている必要があります [こちら](/ja/ptaru/akusesutorru/permissions.md)。初期管理者である場合は、 [お問い合わせください](https://www.radius-as-a-service.com/help/) もし当社が誤ったユーザーを登録したと思われる場合は。 * UPN/メールアドレスの背後にある Microsoft Entra ID (Azure AD) ユーザー オブジェクトは、RADIUSaaS Enterprise Application に次の権限を付与できる必要があります (下のスクリーンショットを参照): * **読み取り** Basic User Profile * **維持** アクセスを許可したデータへのアクセス (リフレッシュ トークン要求を許可)\ ![](https://content.gitbook.com/content/SWU1DQ4UGkqER7uGNUOm/blobs/zBRh87CJ75R1N8hz7mZF/Screenshot_2022-04-11_at_09_31_26.png) * Microsoft Entra ID (Azure AD) ユーザーに必要な権限を付与する権限がない場合、対応する **Enterprise Application** は Microsoft Entra ID (Azure AD) に自動作成されません。これを回避するには、IT 部門に依頼して必要な権限をユーザーに付与してもらってください。 ## Intune 構成の問題 ### プロファイルの割り当て Wi-Fi、SCEP、および Trusted certificate プロファイルが異なるグループに割り当てられていると、Wi-Fi 構成は展開されません。「Pending」と表示されるか、あるいはステータスがまったく表示されない場合があります。次を使用してください: **同じグループ、または「All devices」もしくは「All users」** に **すべての関連プロファイル**. デバイス証明書 (「All devices」に割り当て) とユーザー証明書 (「All users」に割り当て) の両方を使用している場合は、SCEP Root certificate プロファイルを「All users」と「All devices」の両方に割り当てることができます。 ### SCEP 証明書 #### Android Android は新しいバージョンでは、Subject alternative name に UPN が必要なようです (デバイス証明書でも)。SCEP プロファイルにこれを追加してください (例: {{DeviceId}}@contoso.com):
### Wi-Fi プロファイル #### Android よくあるエラーコード: 0xc7d24fc5 または -942518331 要点は次のとおりです: * 次を選択します: **ルート CA 証明書** に **サーバー検証** (重要: RADIUSaaS のサーバー証明書をアップロードしないでください)\ **- と -** * 次を定義します: **RADIUS server 名** * 注: このフィールドには文字数制限があるようです。問題を解決するには、サブドメインなしのドメイン部分、たとえば "radius-as-a-service.com" を使用するとよいでしょう ( "contoso.radius-as-a-service.com" の代わりに)。 * [Android 開発者](https://developer.android.com/guide/topics/connectivity/wifi-enterprise) 「\[...] を構成する必要があります」と述べています: **Root CA certificate の両方を**、および次のいずれかを **domain suffix match** または alternate subject match」と述べています。そのため、MDM は Wi-Fi 構成にルート証明書を追加した後、"setAltSubjectMatch" または "setDomainSuffixMatch" を使用できます。Intune では "setDomainSuffixMatch" を使用しているようで、"radius-as-a-service.com" だけで十分です。 * 場合によっては **アイデンティティ プライバシー** が必要です (例: Android キオスク デバイス / Android Enterprise 専用で見られます) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.radiusaas.com/ja/sono/troubleshooting.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.