> For the complete documentation index, see [llms.txt](https://docs.scepman.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.scepman.com/ja/scepman-gou-cheng/application-settings/scep-endpoints/intune-validation.md). # Intune 検証 {% hint style="info" %} これらの設定は SCEPman App Service にのみ適用し、Certificate Master には適用しないでください。以下を参照してください [SCEPman 設定](/ja/scepman-gou-cheng/application-settings.md). {% endhint %} ## AppConfig:IntuneValidation:ComplianceCheck *Linux: AppConfig\_\_IntuneValidation\_\_ComplianceCheck* {% hint style="warning" %} **実験的設定** SCEPman Enterprise Edition のみ バージョン 1.9 より前では、登録中のコンプライアンス状態の評価が遅れるため、この機能は Windows Autopilot の登録を妨げます。証明書の配布後、直後に行われる OCSP チェックは「**無効**」が登録中に返され、Autopilot プロセスは成功しません。 バージョン 1.9 以降では、クライアントは登録フェーズ中に「Ephemeral Bootstrap Certificate」を受け取り、クライアントがコンプライアンス準拠になるとすぐに通常のクライアント証明書に置き換えられます。 バージョン 2.5 以降では、代わりに ComplianceGracePeriodMinutes 設定を使って、デバイスが常に準拠していると見なされる猶予期間を構成できます。 {% endhint %} **値:** *常に* または *なし* (既定) **説明:** SCEPman が OCSP リクエストを受信すると、SCEPman は任意でデバイスのコンプライアンス状態を確認できます。これを **常に** に設定すると、SCEPman はデバイスのコンプライアンス状態を照会し、デバイスが Azure AD でも準拠としてマークされている場合にのみ OCSP の結果は GOOD になります。 これを **なし** に設定すると、コンプライアンス チェックは無効になります。 ## AppConfig:IntuneValidation:ComplianceGracePeriodMinutes *Linux: AppConfig\_\_IntuneValidation\_\_ComplianceGracePeriodMinutes* {% hint style="warning" %} SCEPman Enterprise Edition のみ バージョン 2.5 以降に適用 {% endhint %} **値:** *整数* （既定値: 0） **説明:** 登録直後、デバイスは Intune でまだ準拠していないことがよくあります。この設定は、デバイスがまだ準拠していなくても準拠していると見なされる猶予期間を分単位で定義します。猶予期間後もデバイスが準拠していない場合、証明書は失効します。これにより、ちょうど登録中の Windows デバイスが Windows Autopilot の登録を完了するために SCEP プロファイルを正常に完了する必要があるにもかかわらず、Intune で準拠になるのがしばらく後になる、という問題を防げます。 この設定では Intune の EnrolledDateTime プロパティを確認し、その時点からカウントを開始します。 これは Ephemeral Bootstrap Certificates を使用する代替手段です。0 より大きい値を設定すると、SCEPman は Ephemeral Bootstrap Certificates を発行しなくなります。 この設定が有効なのは、次の場合のみです [ComplianceCheck](#appconfig-intunevalidation-compliancecheck) が *常に*. ## AppConfig:IntuneValidation:DeviceDirectory *Linux: AppConfig\_\_IntuneValidation\_\_DeviceDirectory* **値:** 文字列 利用可能なオプション: * `AAD`\ （SCEPman 2.0 の既定値） * `Intune` * `AADAndIntune` * `AADAndIntuneOpportunistic`\ （SCEPman 2.1 以降の既定値） * `AADAndIntuneAndEndpointlist`\ （SCEPman 2.2 以降で利用可能） {% hint style="warning" %} 以前のバージョンの SCEPman でインストールされた既存のデプロイメントでこの設定を変更したい場合は、 [PowerShell 構成スクリプト](/ja/scepman-nodepuroi/permissions/post-installation-config.md#acquire-and-run-the-scepman-installation-powershell-module) をもう一度実行して、SCEPman が対応するデバイス ディレクトリにアクセスするための最新の権限を持っていることを確認してください。 {% endhint %} **説明:** デバイス証明書に対する OCSP リクエストで、どこを参照してデバイスを検索するかを決定します。対応するディレクトリでは、証明書のサブジェクト CN フィールドに書かれたデバイス ID に一致するデバイスが照会されます。証明書はデバイスが存在する場合にのみ有効です。次の場合は **`AAD`**、それも有効になっていなければなりません（Intune ではデバイスの無効化はサポートされません）。ComplianceCheck が有効化されている場合、デバイスも準拠していなければなりません。何も構成されておらず、SCEPman 1.9 以前では、 `AAD` が使用されます。 したがって、デバイス向けの Intune 構成プロファイルをそれに応じて設定する必要があります。 `{{AAD_Device_ID}}` は Entra/AAD デバイス ID です。一方で `{{DeviceID}}` は Intune デバイス ID です。 次の場合は **`AADAndIntune`**、両方のディレクトリが並列に照会されます。この場合、デバイスが 2 つのディレクトリのいずれか一方に存在すれば十分です。この設定により、両方の種類のディレクトリでまだ有効な証明書がある場合に、ある設定から別の設定へ移行できます。また、プラットフォームごとに異なる構成を行う場合にも対応します。証明書の登録時点ではまだ完全に Entra 結合されていないため、Entra ID のオブジェクト ID ではなく Intune ID を受け取る iOS または Android デバイスの回避策としても使用できます。 SCEPman 1.x から SCEPman 2.x にアップグレードしており、まだ [SCEPman の権限用の App Registration](/ja/scepman-nodepuroi/permissions/azure-app-registration.md)を引き続き使用している場合、SCEPman には Intune でデバイスを照会する権限がありません。そのため、使用できるのは `AAD` オプションです。オプション **`AADAndIntuneOpportunistic`** は、Intune を照会する権限が SCEPman に付与されているかを確認します。権限がある場合、これは次のように動作します。 `AADAndIntune`。権限がない場合、これは次のように動作します。 `AAD`. 値 **`AADAndIntuneAndEndpointlist`** は、次のように動作します `AADAndIntune`が、さらに次を照会します [Intune の発行済み証明書一覧](https://endpoint.microsoft.com/#view/Microsoft_Intune_DeviceSettings/DevicesMonitorMenu/~/certificateReport)。Intune が [証明書の失効をトリガーした場合](https://learn.microsoft.com/en-us/mem/intune/protect/remove-certificates#scep-certificates)、その証明書は SCEPman で失効済みになります。 {% embed url="" %} SCEPman 2.0: 証明書の検証 {% endembed %} ## AppConfig:IntuneValidation:RevokeCertificatesOnWipe *Linux: AppConfig\_\_IntuneValidation\_\_RevokeCertificatesOnWipe* {% hint style="info" %} バージョン 2.1 以降に適用。 {% endhint %} **値:** *true* (既定) または *false* **説明:** この設定は、Intune Device ID を使用する場合にデバイスの検証を拡張します。Entra/AAD Device ID を使用する場合は動作しません。有効にすると、SCEPman はデバイス証明書の検証時に Intune デバイスの Management State プロパティを評価します。状態が次のいずれかを示す場合、証明書は失効します: * RetirePending * RetireFailed * WipePending * WipeFailed * Unhealthy * DeletePending * RetireIssued * WipeIssued 特に、これは管理者がデバイスに対して Wipe または Retire を実行すると、証明書は直ちに失効することを意味します。デバイスがシャットダウンされているかオフラインで、したがってその操作をデバイス上で実行できない場合でも、証明書はもはや有効ではありません。 ## AppConfig:IntuneValidation:UntoleratedUserRisks *Linux: AppConfig\_\_IntuneValidation\_\_UntoleratedUserRisks* {% hint style="warning" %} **実験的設定** - バージョン 2.2 以降に適用。権限が必要です *IdentityRiskyUser.Read.All* SCEPman PS モジュール バージョン 1.7 以降によって付与されます。 SCEPman Enterprise Edition のみ {% endhint %} **値:** カンマ区切りの User Risk Levels の一覧。例: *Low*, *Medium*, *High*. **説明:** この設定が有効なのは、次を設定した場合のみです [UserRiskCheck](#appconfig-intunevalidation-userriskcheck) を *常に*。この一覧にあるリスク レベルのユーザーの証明書は無効と見なされます。 例: 次を定義します `Medium,High` をこの設定に指定します。あるユーザーの Risk Level が *Low*であるとします。ユーザーの証明書は有効であり、その証明書を使用して社内 VPN に接続できます。すると、リスク イベントによって User Risk Level が *Medium*に上がります。ユーザーは VPN に接続しようとしますが、VPN Gateway が証明書の有効性をリアルタイムで確認し、SCEPman が失効済みであると応答するため、接続に失敗します。 ## AppConfig:IntuneValidation:UserRiskCheck *Linux: AppConfig\_\_IntuneValidation\_\_UserRiskCheck* {% hint style="warning" %} **実験的設定** - バージョン 2.2 以降に適用。権限が必要です *IdentityRiskyUser.Read.All* SCEPman PS モジュール バージョン 1.7 以降によって付与されます。 SCEPman Enterprise Edition のみ {% endhint %} **値:** *常に* または *なし* (既定) **説明:** SCEPman が Intune ユーザーに発行された証明書に対する OCSP リクエストを受信すると、SCEPman は任意で次を確認できます [ユーザー リスク レベル](https://docs.microsoft.com/en-us/azure/active-directory/identity-protection/concept-identity-protection-risks#user-linked-detections)。これを **常に** に設定すると、SCEPman はユーザーのリスク状態を照会し、ユーザーのリスクが次の一覧に含まれていない場合にのみ OCSP の結果は GOOD になります [UntoleratedUserRisks](#appconfig-intunevalidation-untolerateduserrisks). これを **なし** に設定すると、ユーザー リスク チェックは無効になります。 ## AppConfig:IntuneValidation:WaitForSuccessNotificationResponse *Linux: AppConfig\_\_IntuneValidation\_\_WaitForSuccessNotificationResponse* **値:** *true* (既定) または *false* **説明:** 証明書が正常に発行された後、SCEPman はその証明書について Intune に通知を送信します。Microsoft は仕様上、その応答を待つことを推奨しています。ただし、環境によっては大きな遅延が発生し、時折タイムアウトにつながることがあります。そのため **True** が既定値です。 これを **False** にすると、SCEPman は Intune から通知への応答が返る前に発行済み証明書を返します。これは仕様の文言には反しますが、性能を向上させ、この問題が発生する環境でのタイムアウトを回避できます。 ## AppConfig:IntuneValidation:ValidityPeriodDays *Linux: AppConfig\_\_IntuneValidation\_\_ValidityPeriodDays* **値:** 正の *整数* **説明:** この設定は、Intune エンドポイントのグローバル ValidityPeriodDays をさらに短縮します。 ## AppConfig:IntuneValidation:EnableCertificateStorage *Linux: AppConfig\_\_IntuneValidation\_\_EnableCertificateStorage* {% hint style="info" %} バージョン 2.7 以降に適用 SCEPman Enterprise Edition のみ {% endhint %} **値:** *true* または *false* (既定) **説明:** Intune エンドポイント経由で証明書を要求すると、SCEPman はその要求された証明書を Azure の Storage Account に保存します。これを *true*に設定すると、発行された証明書が SCEPman Certificate Master に表示され、そこから手動で確認および失効できます。さらに、関連する Entra または Intune オブジェクトが、他の設定で指定されているような無効な状態（無効化や削除など）になると、証明書は自動的に失効します。これを *false*に設定すると、SCEPman は発行済み証明書を保存せず、証明書はログ、または Certificate Master の従来の Intune 表示や Intune ポータルでのみ確認できます。これを設定しない場合、動作はグローバル設定 [AppConfig:EnableCertificateStorage](/ja/scepman-gou-cheng/application-settings/basics.md#appconfig-enablecertificatestorage). ## AppConfig:IntuneValidation:AllowRenewals **値:** *true* または *false* (既定) **説明:** これにより、次の *RenewalReq* 操作をこの SCEP エンドポイントで使用できます。これは、次に追加された証明書タイプに対してのみ機能します *AppConfig:*IntuneValidation*:ReenrollmentAllowedCertificateTypes*. この操作は、次と [SCEPmanClient ](https://github.com/scepman/scepmanclient)PowerShell モジュールと組み合わせて使用できます。 {% hint style="warning" %} Intune は次の機能を使用しないことにご注意ください *RenewalReq* 操作のため、この設定は通常の運用では不要です。 {% endhint %} ## AppConfig:IntuneValidation:AllowRequestedSidExtension {% hint style="info" %} バージョン 2.11.1460 以降に適用。以前のバージョンでは、この設定を変更すると説明とは異なる動作をするため、これらの旧バージョンではこの設定を構成しないことを推奨します。 {% endhint %} **値:** *true* または *false* (既定) **説明:** 証明書要求に SID 拡張 (OID 1.3.6.1.4.1.311.25.2) がある場合、この設定が true ならそれは発行された証明書にコピーされます。false なら除外されます。SID は、オンプレミス AD 認証シナリオで証明書を強固にマッピングするうえで重要です。ただし、Intune はどうやら [要求された SID の真正性を確認していない](/ja/sono/troubleshooting/sid-spoofing-vulnerability.md) ようなので、要求された SID 拡張を許可するとセキュリティ上の脆弱性になる可能性があります。 を介して追加された SID 拡張は [AppConfig:AddSidExtension](/ja/scepman-gou-cheng/application-settings/certificates.md#appconfig-addsidextension) この設定の影響を受けません。さらに、SID を含む SAN URI として追加された SID も、SCEPman のバージョンが 2.11.1460 以降であれば影響を受けません。古いバージョンの SCEPman では、SAN URI の SID はこれが *true*の場合にのみコピーされますが、それらには *true* が既定値として設定されています。 ## AppConfig:IntuneValidation:ReenrollmentAllowedCertificateTypes **値:** 次の一覧にある証明書タイプのカンマ区切りリスト: * DomainController * Static * IntuneUser * IntuneDevice * JamfUser * JamfUserWithDevice * JamfUserWithComputer * JamfDevice * JamfComputer **説明:** この設定で指定されたタイプの証明書の更新に SCEP エンドポイントを使用できます。値を指定しない場合、既定では対象タイプはありません。 たとえば、Certificate Master を使用して手動で発行された証明書を更新したい場合は、次を指定します `Static`. さらに Domain Controller 証明書も更新したい場合は、次を指定します `DomainController,Static`. {% hint style="warning" %} Intune は次の機能を使用しないことにご注意ください *RenewalReq* 操作のため、この設定は通常の運用では不要です。 {% endhint %} --- # 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 dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.scepman.com/ja/scepman-gou-cheng/application-settings/scep-endpoints/intune-validation.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. 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.