# Intune 検証 {% hint style="info" %} これらの設定は Certificate Master ではなく、SCEPman App Service にのみ適用してください。こちらを参照してください [SCEPman Settings](https://docs.scepman.com/ja/scepman-no/application-settings). {% 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* **値:** String 使用可能なオプション: * `AAD`\ （SCEPman 2.0 の既定） * `Intune` * `AADAndIntune` * `AADAndIntuneOpportunistic`\ （SCEPman 2.1 以降の既定） * `AADAndIntuneAndEndpointlist`\ （SCEPman 2.2 以降で利用可能） {% hint style="warning" %} 以前のバージョンの SCEPman でインストールされた既存のデプロイでこの設定を変更したい場合は、 [PowerShell 構成スクリプト](https://docs.scepman.com/ja/scepman-depuroi/permissions/post-installation-config#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 参加していないために Intune ID が Entra ID オブジェクト ID の代わりに割り当てられる iOS または Android デバイスに対する回避策としても使用できます。 SCEPman 1.x から SCEPman 2.x にアップグレードしていて、まだ [SCEPman のアクセス許可用の App Registration](https://docs.scepman.com/ja/scepman-depuroi/permissions/azure-app-registration)を使用している場合、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 Device の 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 module バージョン 1.7 以降によって割り当てられます。 SCEPman Enterprise Edition のみ {% endhint %} **値:** ユーザー リスク レベルのコンマ区切りリスト（例: *Low*, *Medium*, *High*. **説明:** この設定は、 [UserRiskCheck](#appconfig-intunevalidation-userriskcheck) から *常に*を設定した場合にのみ有効です。このリスト内のリスク レベルを持つユーザーの証明書は無効と見なされます。 例: この設定に対して `Medium,High` を定義します。あるユーザーのリスク レベルは *Low*です。そのユーザーの証明書は有効であり、その証明書を使用して企業 VPN に接続できます。その後、リスク イベントによりユーザー リスク レベルが *Medium*に上昇します。ユーザーは VPN への接続を試みますが成功しません。これは、VPN Gateway が証明書の有効性をリアルタイムで確認し、SCEPman がそれは失効されていると応答するためです。 ## AppConfig:IntuneValidation:UserRiskCheck *Linux: AppConfig\_\_IntuneValidation\_\_UserRiskCheck* {% hint style="warning" %} **実験的な設定** - バージョン 2.2 以降に適用されます。アクセス許可 *IdentityRiskyUser.Read.All* が必要で、SCEPman PS module バージョン 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 はユーザーのリスク状態を照会し、ユーザーのリスクが [UntoleratedUserRisks](#appconfig-intunevalidation-untolerateduserrisks). これを次のように設定すると **しない** のリストに含まれていない場合にのみ、OCSP の結果を GOOD にできます。これに設定すると、ユーザー リスク チェックは無効になります。 ## 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 エンドポイント経由で証明書を要求する場合、これが *true*に設定されていると、SCEPman は要求された証明書を Azure の Storage Account に保存します。これにより、発行された証明書が SCEPman Certificate Master に表示され、そこで表示および手動で失効できます。さらに、関連付けられた Entra または Intune オブジェクトが、他の設定で指定された無効な状態（無効化または削除など）になると、証明書は自動的に失効されます。 *false*に設定されている場合、SCEPman は発行済み証明書を保存せず、証明書はログ内、または Certificate Master もしくは Intune portal のクラシック Intune ビューでのみ表示されます。これが設定されていない場合、動作はグローバル設定 [AppConfig:EnableCertificateStorage](https://docs.scepman.com/ja/scepman-no/basics#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 の真正性を確認しない](https://docs.scepman.com/ja/sono/troubleshooting/sid-spoofing-vulnerability) ようであるため、要求された SID 拡張機能を許可するとセキュリティ脆弱性をもたらす可能性があります。 によって追加された SID 拡張機能は [AppConfig:AddSidExtension](https://docs.scepman.com/ja/scepman-no/certificates#appconfig-addsidextension) この設定の影響を受けません。さらに、SID を含む SAN URI として追加された SID も、SCEPman のバージョンが 2.11.1460 以降であれば影響を受けません — それ以前のバージョンの SCEPman では、この *true*の場合にのみ SAN URI SID をコピーしますが、それらの既定値は *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 %}