---
title: 【Okta】1枚の証明書で Windows 端末を自動登録し管理対象にする単一の証明書発行者を試してみた｜Nextmode Blog
description: Okta の単一の証明書発行者を利用して、Windows 端末を1枚の証明書で「登録済み」かつ「管理対象」とする方法を詳しく検証します。
image: https://info.nextmode.co.jp/hubfs/Okta_Blog.png
---

[![nextmode blog](https://info.nextmode.co.jp/hubfs/raw_assets/public/NextMode_Theme/nextmode%20blog.png)](https://info.nextmode.co.jp/blog)

[ホワイトペーパー](https://info.nextmode.co.jp/white-paper/) [資料請求](https://info.nextmode.co.jp/request/) [お問い合わせ](https://nextmode.co.jp/contact/)

- [会社TOP](https://nextmode.co.jp/)
- [生成AIセキュリティ](https://nextmode.co.jp/services/ai/security/)
- [SaaSライセンス＆サポート](https://nextmode.co.jp/services/saas/)
  
    - [Oktaライセンス＆サポート](https://nextmode.co.jp/services/saas/okta/)
    - [Netskopeライセンス＆サポート](https://nextmode.co.jp/services/saas/netskope/)
    - [Notionライセンス＆サポート](https://nextmode.co.jp/services/saas/notion/)
    - [Asanaライセンス＆サポート](https://nextmode.co.jp/services/saas/asana/)
    - [SysCloudライセンス＆サポート](https://nextmode.co.jp/services/saas/syscloud/)
    - [CrowdStrikeライセンス＆サポート](https://nextmode.co.jp/services/saas/crowdstrike/)
- [AWS総合支援](https://nextmode.co.jp/services/aws/)
  
    - [AWS導入コンサル・構築](https://nextmode.co.jp/services/aws_consulting/)
    - [AWS運用・保守代行](https://nextmode.co.jp/services/aws_operation/)
- [導入事例](https://nextmode.co.jp/casestudy/)
- [会社情報](https://nextmode.co.jp/company/)
- [セミナー](https://info.nextmode.co.jp/seminar/)
- [ブログ](https://info.nextmode.co.jp/blog)

[![YouTube](https://nextmode.co.jp/assets/images/common/icon_youtube.svg)](https://www.youtube.com/@nextmode) <https://x.com/Nextmode_Inc>

目次

 2026/11/04 08:00

# 【Okta】1枚の証明書で Windows 端末を自動登録し管理対象にする単一の証明書発行者を試してみた

[» Okta](https://info.nextmode.co.jp/blog/tag/okta) [» 技術](https://info.nextmode.co.jp/blog/tag/技術)

[![yuki](https://info.nextmode.co.jp/hs-fs/hubfs/avator_yukinawa.jpg?width=40&name=avator_yukinawa.jpg) yuki](https://info.nextmode.co.jp/blog/author/yuki)

共有： [facebook-f icon](http://www.facebook.com/share.php?u=https://info.nextmode.co.jp/blog/okta-single-certificate-issuer-sensor-mode-intune) [linkedin-in icon](http://www.linkedin.com/shareArticle?mini=true&url=https://info.nextmode.co.jp/blog/okta-single-certificate-issuer-sensor-mode-intune) [Twitter icon](https://twitter.com/intent/tweet?url=https://info.nextmode.co.jp/blog/okta-single-certificate-issuer-sensor-mode-intune) [pinterest-p icon](http://pinterest.com/pin/create/link/?url=https://info.nextmode.co.jp/blog/okta-single-certificate-issuer-sensor-mode-intune) [envelope icon](mailto:?body=https://info.nextmode.co.jp/blog/okta-single-certificate-issuer-sensor-mode-intune)

## はじめに

こんにちは、ネクストモードのゆきなわです。

本記事では、Okta の早期アクセスの機能である**単一の証明書発行者 (Single Certificate Issuer)**を使い、Microsoft Intune で管理する Windows 端末が1枚の証明書で認証ポリシーの「登録済み」と「管理対象」の両方の条件を満たせるのかを検証します。

※ 本記事は2026年11月時点の情報に基づいています。本記事で使用する機能は早期アクセス (Early Access) の機能のため、画面や仕様は変更される場合があります。

## 単一の証明書発行者の仕組み

Okta Verify の**デバイスポスチャセンサーモード (Device Posture Sensor Mode)**（以下、センサーモード）は、MDM から配布した**デバイス証明書**で端末を Okta に登録し、認証ポリシーの「登録済み (Registered)」の条件を満たす機能です[\[1\]](https://help.okta.com/oie/ja-jp/content/topics/identity-engine/devices/device-posture-sensor-mode-main.htm)。

「管理対象 (Managed)」も条件にするには、デバイス証明書とは別に**管理証明 (Management attestation)**用の管理証明書を配布する必要があります[\[1\]](https://help.okta.com/oie/ja-jp/content/topics/identity-engine/devices/device-posture-sensor-mode-main.htm)。以前の記事では、この2つの証明書を別々の認証局 (CA) から発行しました。

[![【Okta】Okta Verify のデバイスポスチャセンサーモードで共用 Windows 端末を自動登録し管理対象にする](https://info.nextmode.co.jp/hs-fs/hubfs/Okta_Blog.png?width=2762&height=1582&name=Okta_Blog.png)関連記事【Okta】Okta Verify のデバイスポスチャセンサーモードで共用 Windows 端末を自動登録し管理対象にするOkta Verify のデバイスポスチャセンサーモードと Microsoft Intune で、共用 Windows 端末向けに利用者の操作なしで Okta に登録し、認証ポリシーの「登録済み」「管理対象」の条件を満たす手順を詳しく解説します。info.nextmode.co.jp](https://info.nextmode.co.jp/blog/okta-verify-device-posture-sensor-mode-intune)

**単一の証明書発行者**を使うと、1つの CA を登録と管理証明の両方で信頼できます[\[2\]](https://help.okta.com/oie/ja-jp/content/topics/identity-engine/devices/single-cert-issuer-overview.htm)。ただし、Okta のドキュメントにはその CA が発行した1枚のデバイス証明書で「登録済み」と「管理対象」の両方の条件を満たせるのかまでは明記されていません。

そこで**本記事では管理証明書を配布せず、デバイス証明書だけを端末に配布して2つの条件を満たせるのかを実際に確かめました。**

| 認証ポリシーの条件 | 以前の記事 | 本記事 |
| --- | --- | --- |
| 登録済み | デバイス証明書 | デバイス証明書 |
| 管理対象 | 管理証明書 | 同じデバイス証明書 |

検証の結果

1つの CA が発行した1枚の証明書で、Windows 端末が「登録済み」と「管理対象」の両方の条件を満たしました。

端末で Okta FastPass（Okta Verify によるパスワードレス認証）を登録していない利用者のサインインで、「登録済み」と「管理対象」を条件にしたルールが適用されました。

## 前提

本記事の対象は、Microsoft Entra 参加済みで Intune に登録され、利用者が Microsoft Entra ID のアカウントでサインインする Windows 端末です。

### 検証の全体像

[![検証の全体像。Intune が Windows 端末に、Okta の CA が発行する1枚のデバイス証明書と、センサーモードの Okta Verify を配布する。1枚の証明書から、利用者のサインインの前に「センサーモードで登録」、サインインのときに「管理証明」が行われ、Okta のアプリサインインポリシーのルールの「登録済み」と「管理対象」の条件に対応する。利用者は端末の Okta Verify に登録せず、Microsoft Entra ID のアカウントで端末にサインインしてからアプリにサインインし、2つの条件を満たして認証に成功するとアクセスが許可される](https://info.nextmode.co.jp/hs-fs/hubfs/okta-single-certificate-issuer-sensor-mode-intune-1.png?width=2400&height=1200&name=okta-single-certificate-issuer-sensor-mode-intune-1.png)](https://info.nextmode.co.jp/hubfs/okta-single-certificate-issuer-sensor-mode-intune-1.png)

今回の検証の全体像

今回の検証では、Intune が端末に1枚のデバイス証明書と Okta Verify を配布し、そのデバイス証明書がアプリサインインポリシーの「登録済み」と「管理対象」の条件に対応します。

### 検証環境

| 項目 | 内容 |
| --- | --- |
| OS | Windows 11 Pro バージョン 26H2（OS ビルド 26300.9711） |
| 端末の参加形態 | Microsoft Entra 参加、Intune で管理 |
| Okta | Okta Identity Engine（Production の org。検証時のバージョンは 2026.42.1） |
| Okta の機能 | 早期アクセスの機能「Okta Verifyデバイスポスチャセンサーモード」と「デバイス登録、Okta Device Access、管理証明の単一の証明書」 |
| Okta Verify | Okta Verify for Windows 7.2.2.0（「早期アクセスのダウンロード」から取得） |

### 前提条件

センサーモードと単一の証明書発行者は、どちらも Okta Verify for Windows 7.2 以降が必要です[\[1\]](https://help.okta.com/oie/ja-jp/content/topics/identity-engine/devices/device-posture-sensor-mode-main.htm)[\[2\]](https://help.okta.com/oie/ja-jp/content/topics/identity-engine/devices/single-cert-issuer-overview.htm)。検証時点で 7.2 以降は Production の org では一般提供されていないため、Okta Admin Console の「設定」\>「ダウンロード」にある「早期アクセスのダウンロード」から取得しました。

Okta のドキュメントでは、単一の証明書発行者は Preview の org の機能として説明されていますが[\[2\]](https://help.okta.com/oie/ja-jp/content/topics/identity-engine/devices/single-cert-issuer-overview.htm)、検証に使用した Production の org でも「設定」\>「機能」に早期アクセスの機能として表示され、有効にできました。

本記事の手順は、SCEP 構成をまだ作成していない org で単一の証明書発行者を有効にしてから設定する場合のものです。以前の記事の構成で運用している org から移行する手順と既存の証明書の扱いは確認していないため、本記事では扱いません。

### 設定の流れ

手順1から手順5が設定作業です。設定の後、「動作の確認」のセクションで証明書の配置、端末の登録、サインインを確認します。

| 手順 | 作業 | 作業場所 |
| --- | --- | --- |
| 手順1 | アプリの登録 | Microsoft Entra 管理センター |
| 手順2 | 早期アクセスの機能の有効化、SCEP 構成の作成、CA 証明書の取得 | Okta Admin Console |
| 手順3 | 構成プロファイルの作成 | Intune 管理センター |
| 手順4 | Okta Verify の配布 | Okta Admin Console、Intune 管理センター |
| 手順5 | 認証ポリシーの作成 | Okta Admin Console |

## 手順1：Microsoft Entra ID のアプリ登録

委任 SCEP では、Okta が Intune に問い合わせて証明書の要求ごとのチャレンジを確認してから証明書を発行します[\[3\]](https://help.okta.com/oie/ja-jp/content/topics/oda/ca/oda-ca-scep-windows-intune-delegated.htm)。この問い合わせに使う資格情報として、Microsoft Entra ID にアプリを登録します。

1. Microsoft Entra 管理センターの「アプリの登録」で「新規登録」を選択し、シングルテナントのアプリを作成します。
2. アプリの「概要」で、アプリケーション (クライアント) ID とテナントのプライマリドメイン（例：`xxx.onmicrosoft.com`）を控えます。
3. 「証明書とシークレット」でクライアントシークレットを作成し、値を控えます。
4. 「API のアクセス許可」で、Intune の `scep_challenge_provider` と Microsoft Graph の `Application.Read.All` をアプリケーションの許可として追加し、管理者の同意を与えます。

アプリの登録の詳しい手順は、以前の記事で紹介しています。

[![【Okta】Okta Verify のデバイスポスチャセンサーモードで共用 Windows 端末を自動登録し管理対象にする](https://info.nextmode.co.jp/hs-fs/hubfs/Okta_Blog.png?width=2762&height=1582&name=Okta_Blog.png)関連記事のセクション手順1：Microsoft Entra ID のアプリ登録【Okta】Okta Verify のデバイスポスチャセンサーモードで共用 Windows 端末を自動登録し管理対象にするinfo.nextmode.co.jp](https://info.nextmode.co.jp/blog/okta-verify-device-posture-sensor-mode-intune#toc-section-7)

手順2では、ここで控えた3つの値を使用します。

## 手順2：Okta での機能の有効化と SCEP 構成の作成

Okta Admin Console で2つの早期アクセスの機能を有効にしてから SCEP 構成を1つ作成し、Okta の CA 証明書をダウンロードします。ここで生成する SCEP URL は、手順3の SCEP 証明書プロファイルで使用します。

### 早期アクセスの機能の有効化

「設定」\>「機能」で、次の2つの早期アクセスの機能を有効にします。

1. 「Okta Verifyデバイスポスチャセンサーモード」
2. 「デバイス登録、Okta Device Access、管理証明の単一の証明書」（単一の証明書発行者）

[![早期アクセスの機能「Okta Verifyデバイスポスチャセンサーモード」の設定。トグルがオンになっている](https://info.nextmode.co.jp/hs-fs/hubfs/okta-single-certificate-issuer-sensor-mode-intune-2.png?width=1652&height=256&name=okta-single-certificate-issuer-sensor-mode-intune-2.png)](https://info.nextmode.co.jp/hubfs/okta-single-certificate-issuer-sensor-mode-intune-2.png)

早期アクセスの機能「Okta Verifyデバイスポスチャセンサーモード」

[![早期アクセスの機能「デバイス登録、Okta Device Access、管理証明の単一の証明書」の設定。トグルがオンになっている](https://info.nextmode.co.jp/hs-fs/hubfs/okta-single-certificate-issuer-sensor-mode-intune-3.png?width=1664&height=222&name=okta-single-certificate-issuer-sensor-mode-intune-3.png)](https://info.nextmode.co.jp/hubfs/okta-single-certificate-issuer-sensor-mode-intune-3.png)

早期アクセスの機能「デバイス登録、Okta Device Access、管理証明の単一の証明書」。本記事では触れませんが、Okta Device Access のデバイスバウンド SSO (Device-Bound SSO) のための証明書としても利用可能です。

単一の証明書発行者を有効にすると、「セキュリティ」\>「デバイス統合」の画面に「証明書構成」「認証局」「管理証明」「デバイス登録」のタブが表示されます[\[2\]](https://help.okta.com/oie/ja-jp/content/topics/identity-engine/devices/single-cert-issuer-overview.htm)。SCEP 構成は、「証明書構成」タブで作成します。

### SCEP 構成の作成

1. 「セキュリティ」\>「デバイス統合」の「証明書構成」タブで、「SCEP構成を作成」を選択します。
2. 「構成名」に、用途が分かる名前を入力します。入力は任意です。
3. 「Okta認証局」で「デバイスアクセス」を選択します。
4. 「管理証明にこの認証局を信頼しますか？」で「はい、管理証明にこの認証局を信頼します」を選択します。
5. 「デバイス登録にこの認証局を信頼しますか？」で「はい、デバイス登録にこの認証局を信頼します」を選択します。
6. 「SCEP URLチャレンジタイプ」で「動的SCEP URL」を選び、「Microsoft Intune（委任SCEP）」を選択します。
7. 「AADクライアントID」「AADテナント」「AADシークレット」に、手順1で控えた値を入力します。AAD テナントにはプライマリドメインを入力します。
8. 「生成」を選択し、表示された SCEP URL を控えてから「保存」を選択します。

[![「SCEPを構成する」の画面。Okta認証局に「デバイスアクセス」、管理証明とデバイス登録の信頼に「はい」、SCEP URLチャレンジタイプに「動的SCEP URL」の「Microsoft Intune（委任SCEP）」を選択している（AAD の3つの項目と SCEP URL はマスク）](https://info.nextmode.co.jp/hs-fs/hubfs/okta-single-certificate-issuer-sensor-mode-intune-4.png?width=1358&height=1678&name=okta-single-certificate-issuer-sensor-mode-intune-4.png)](https://info.nextmode.co.jp/hubfs/okta-single-certificate-issuer-sensor-mode-intune-4.png)

「証明書構成」タブで作成する SCEP 構成（「生成」を選択した後の画面）

保存すると、「証明書構成」タブの「SCEP構成」に、証明書発行者が「Okta CA（CAタイプ：Device Access）」、タイプが「動的SCEP URL - Microsoft Intune（委任SCEP）」の構成が表示されます。

[![「証明書構成」タブの「SCEP構成」の一覧。構成を展開し、SCEP URL、AADクライアントID、AADテナント、認証局が表示されている（SCEP URL、AADクライアントID、AADテナントはマスク）](https://info.nextmode.co.jp/hs-fs/hubfs/okta-single-certificate-issuer-sensor-mode-intune-5.png?width=2044&height=1074&name=okta-single-certificate-issuer-sensor-mode-intune-5.png)](https://info.nextmode.co.jp/hubfs/okta-single-certificate-issuer-sensor-mode-intune-5.png)

「証明書構成」タブに追加された SCEP 構成

### Okta の CA 証明書のダウンロード

「認証局」タブで、「Okta CA（CAタイプ：Device Access）」の「アクション」列にある x509 証明書のダウンロードアイコンを選択します。ダウンロードしたファイルは、拡張子を `.cer` に変更します。

「認証局」タブには、Okta CA（CAタイプ：Device Access）のほかに Okta CA（CAタイプ：エンドポイント管理）も表示されます。検証では、SCEP 構成を作成したときに追加されました。本記事の構成で証明書を発行するのは、「サポート」列に「管理証明」と「デバイス登録」が表示される Device Access の CA だけです。

[![「認証局」タブ。Okta CA（CAタイプ：Device Access）の「サポート」列に「管理証明」と「デバイス登録」、Okta CA（CAタイプ：エンドポイント管理）の「サポート」列に「管理証明」が表示されている（説明の OU と org の名前はマスク）](https://info.nextmode.co.jp/hs-fs/hubfs/okta-single-certificate-issuer-sensor-mode-intune-6.png?width=2036&height=806&name=okta-single-certificate-issuer-sensor-mode-intune-6.png)](https://info.nextmode.co.jp/hubfs/okta-single-certificate-issuer-sensor-mode-intune-6.png)

「認証局」タブに表示された2つの Okta CA

### 設定の意図

- **Okta認証局**：「デバイスアクセス」を選択します。1つの CA をセンサーモードの登録と管理証明の両方に使用するには、デバイスアクセス用の CA である必要があるためです。Okta のドキュメントでは、デバイス登録で信頼できるのはデバイスアクセス用の CA だけと説明されています[\[2\]](https://help.okta.com/oie/ja-jp/content/topics/identity-engine/devices/single-cert-issuer-overview.htm)。
- **管理証明とデバイス登録の信頼**：両方を「はい」にします。管理証明で信頼すると、この CA が発行した証明書が「管理対象」の判定に使用され、デバイス登録で信頼すると、センサーモードによる端末の登録に使用されます。
- **後で設定する場合**：2つの信頼の質問で「後で」を選んで保存した場合は、「管理証明」タブと「デバイス登録」タブで信頼を設定できます[\[2\]](https://help.okta.com/oie/ja-jp/content/topics/identity-engine/devices/single-cert-issuer-overview.htm)。

## 手順3：Intune の構成プロファイルの作成

Intune では、手順2でダウンロードした CA 証明書の信頼された証明書プロファイルと、SCEP 証明書プロファイルを1つずつ作成します。

### 信頼された証明書プロファイル

Intune 管理センターの「デバイス」\>「デバイスの管理」\>「構成」で「作成」を選択し、プラットフォームに「Windows 10 以降」、プロファイルの種類に「テンプレート」を選択して、テンプレートの「信頼された証明書」を選択します。次の値でプロファイルを作成します。

| 設定項目 | 設定値 |
| --- | --- |
| 名前 | CA と用途が分かる名前（例：Okta CA（デバイスアクセス・管理証明）） |
| 証明書ファイル | 手順2でダウンロードした `.cer` ファイル |
| 保存先ストア | コンピューター証明書ストア - 中間 |
| 割り当て | 対象端末のデバイスグループ |

[![信頼された証明書プロファイルのプロパティ。名前が「Okta CA（デバイスアクセス・管理証明）」、プロファイルの種類が「信頼された証明書」で、割り当てに「すべてのデバイス」が含まれている](https://info.nextmode.co.jp/hs-fs/hubfs/okta-single-certificate-issuer-sensor-mode-intune-7.png?width=1462&height=1663&name=okta-single-certificate-issuer-sensor-mode-intune-7.png)](https://info.nextmode.co.jp/hubfs/okta-single-certificate-issuer-sensor-mode-intune-7.png)

信頼された証明書プロファイル（割り当ては検証用）

作成したプロファイルは、プラットフォームが「Windows 8.1 以降」と表示されます。これは Microsoft のドキュメントに記載された表示上の既知の問題で、プロファイルは Windows 10 と Windows 11 に適用されます[\[4\]](https://learn.microsoft.com/ja-jp/intune/device-configuration/certificates/trusted-root-profiles)。

### SCEP 証明書プロファイル

同じ画面でテンプレートの「SCEP 証明書」を選択し、次の値でプロファイルを作成します。

| 設定項目 | 設定値 |
| --- | --- |
| 証明書の種類 | デバイス |
| サブジェクト名の形式 | `CN=` |
| 証明書の有効期間 | 1年 |
| キー記憶域プロバイダー (KSP) | トラステッド プラットフォーム モジュール (TPM) KSP が存在する場合は TPM KSP に登録する (それ以外はソフトウェア KSP に登録する) |
| キー使用法 | デジタル署名 |
| キー サイズ (ビット) | 2048 |
| ハッシュ アルゴリズム | SHA-256 (SHA-2) |
| ルート証明書 | 手順2の CA の信頼された証明書プロファイル |
| 拡張キー使用法 | クライアント認証 |
| 更新しきい値 (%) | 20 |
| SCEP サーバーの URL | 手順2で控えた SCEP URL |
| 割り当て | 対象端末のデバイスグループ |

[![SCEP 証明書プロファイルの構成設定の画面。証明書の種類が「デバイス」、ルート証明書が「Okta CA（デバイスアクセス・管理証明）」、拡張キー使用法が「クライアント認証」になっている（SCEP サーバーの URL はマスク）](https://info.nextmode.co.jp/hs-fs/hubfs/okta-single-certificate-issuer-sensor-mode-intune-8.png?width=1054&height=1790&name=okta-single-certificate-issuer-sensor-mode-intune-8.png)](https://info.nextmode.co.jp/hubfs/okta-single-certificate-issuer-sensor-mode-intune-8.png)

SCEP 証明書プロファイルの構成設定

### 設定の意図

- **証明書の種類**：「デバイス」にして、ローカルコンピューターの証明書ストアに配置します。センサーモードは利用者のサインインを待たずに端末を登録するため、端末単位の証明書を使用します。管理証明にも、この端末単位の証明書を使用します。
- **ルート証明書**：手順2の CA の信頼された証明書プロファイルを指定します。端末は SCEP サーバーから受け取った CA 証明書をここで指定した証明書と照合し、一致しない場合は証明書の要求が失敗します[\[5\]](https://learn.microsoft.com/ja-jp/windows/client-management/mdm/clientcertificateinstall-csp)。
- **割り当て**：利用者のサインインを待たずに配布されるよう、デバイスグループに割り当てます[\[6\]](https://learn.microsoft.com/ja-jp/intune/device-configuration/certificates/scep-profiles)。
- **キー サイズ**：2048にします。以前の記事の検証では、1024で配布したところ Okta での証明書の発行が失敗しました。

## 手順4：Okta Verify の配布

Okta Verify for Windows 7.2 以降を、センサーモードのオプションを付けて Intune から Win32 アプリとして配布します。インストーラーには、次のオプションを指定します[\[7\]](https://help.okta.com/oie/ja-jp/content/topics/identity-engine/devices/managed-app-configs-win.htm)。

| オプション | 値 | 内容 |
| --- | --- | --- |
| `AutoRegistration` | `DEVICE` | 端末単位でセンサーモードを有効にする |
| `OrgUrl` | org の URL | 端末を登録する org |
| `EnrollmentOptions` | `Disabled` | 認証時に、利用者へ Okta Verify の登録を求めない |

インストールコマンド

```
OktaVerifySetup-x.x.x.x-yyyyyyy.exe /q AutoRegistration=DEVICE OrgUrl=https://<org>.okta.com EnrollmentOptions=Disabled
```

インストーラーは「設定」\>「ダウンロード」から取得し、`.intunewin` 形式に変換して Intune に Win32 アプリとして登録します。インストールの動作は「システム」にし、対象端末のデバイスグループに必須で割り当てます。検出規則などの詳しい設定は、以前の記事で紹介しています。

[![【Okta】Okta Verify のデバイスポスチャセンサーモードで共用 Windows 端末を自動登録し管理対象にする](https://info.nextmode.co.jp/hs-fs/hubfs/Okta_Blog.png?width=2762&height=1582&name=Okta_Blog.png)関連記事のセクション手順4：Okta Verify の配布【Okta】Okta Verify のデバイスポスチャセンサーモードで共用 Windows 端末を自動登録し管理対象にするinfo.nextmode.co.jp](https://info.nextmode.co.jp/blog/okta-verify-device-posture-sensor-mode-intune#toc-section-19)

## 手順5：認証ポリシーの作成

「セキュリティ」\>「認証ポリシー」\>「アプリサインイン」でアプリサインインポリシーを作成し、次の2つのルールを追加して Okta Dashboard に割り当てます[\[8\]](https://help.okta.com/oie/ja-jp/Content/Topics/identity-engine/devices/device-posture-sensor-mode-configure-policy.htm)。

| 優先度 | 条件 | アクセス |
| --- | --- | --- |
| 1 | 検証用のグループ、デバイスが「登録済み」かつ「管理対象」 | 任意の2要素タイプで許可 |
| 2 | 検証用のグループ | 拒否 |

優先度1のルールは、次の値で作成します。

| 設定項目 | 設定値 |
| --- | --- |
| デバイスの状態 (Device state) | 登録済み (Registered) |
| デバイス管理 (Device management) | 管理対象 (Managed) |
| アクセス | 任意の2要素タイプで許可 |
| 所有要素の制約 | ユーザーインタラクションを必須とする |
| 認証方法 | 要件を満たすために使用できるすべての方法を許可する |
| 再認証の頻度 | ユーザーがリソースにサインインするたび |

[![アプリサインインポリシーの2つのルール。優先度1の Test 1103 Rule は、グループ Test1103 とデバイスの「登録済み」「管理対象」を条件に、任意の2要素タイプで許可する。優先度2の Test 1103 Deny は、同じグループのアクセスを拒否する](https://info.nextmode.co.jp/hs-fs/hubfs/okta-single-certificate-issuer-sensor-mode-intune-9.png?width=2524&height=1128&name=okta-single-certificate-issuer-sensor-mode-intune-9.png)](https://info.nextmode.co.jp/hubfs/okta-single-certificate-issuer-sensor-mode-intune-9.png)

アプリサインインポリシーのルール（グループの条件は検証用）

### 設定の意図

- **拒否のルール**：優先度1のルールと同じグループを対象に、優先度2でアクセスを「拒否」にします。どちらのルールも検証用のグループに絞り、影響範囲を限定するためです。検証用の利用者のサインインは優先度1のルールの条件を満たさなければ拒否されるため、サインインの結果から1枚の証明書で2つの条件を満たせたのかが分かります。

認証ポリシーの作成の詳しい手順は、以前の記事で紹介しています。

[![【Okta】Okta Verify のデバイスポスチャセンサーモードで共用 Windows 端末を自動登録し管理対象にする](https://info.nextmode.co.jp/hs-fs/hubfs/Okta_Blog.png?width=2762&height=1582&name=Okta_Blog.png)関連記事のセクション手順5：認証ポリシーの作成【Okta】Okta Verify のデバイスポスチャセンサーモードで共用 Windows 端末を自動登録し管理対象にするinfo.nextmode.co.jp](https://info.nextmode.co.jp/blog/okta-verify-device-posture-sensor-mode-intune#toc-section-22)

## 動作の確認

手順1から手順5の設定の後、端末で証明書の配置、端末の登録、サインインを確認します。

### 証明書の配置

「コンピューター証明書の管理」（certlm.msc）で、次の点を確認します。

- 「中間証明機関」\>「証明書」に、Okta の CA 証明書が1つ配置されています。
- 「個人」\>「証明書」に、発行者が「Organization Intermediate Authority」の証明書が1枚配置されています。検証では個人ストアにある Okta の証明書はこの1枚だけで、ほかは Microsoft Entra 参加と Intune の証明書でした。
- 証明書の「詳細」タブに、`1.3.6.1.4.1.51150.13.1` の拡張があります。この拡張は、センサーモードの登録に使用するデバイス証明書の目印です[\[9\]](https://help.okta.com/oie/ja-jp/content/topics/oda/ca/oda-ca-scep-verify.htm)。検証では、単一の証明書発行者の CA が発行した証明書にもこの拡張がありました。
- 同じタブの「機関キー識別子」は、発行元の CA の鍵を識別する値です。検証では、この値の先頭が手順2で生成した SCEP URL の `/pki/` に続く文字列と一致し、手順2の CA から発行された証明書であることを確認できました。

[![「コンピューター証明書の管理」の「個人」\>「証明書」。発行者が「Organization Intermediate Authority」の証明書は1枚で、ほかは MS-Organization-Access、Microsoft Intune、MS-Organization-P2P-Access の証明書（発行先のデバイス ID はマスク）](https://info.nextmode.co.jp/hs-fs/hubfs/okta-single-certificate-issuer-sensor-mode-intune-10.png?width=1249&height=723&name=okta-single-certificate-issuer-sensor-mode-intune-10.png)](https://info.nextmode.co.jp/hubfs/okta-single-certificate-issuer-sensor-mode-intune-10.png)

certlm.msc の「個人」\>「証明書」

[![証明書の「詳細」タブ。表示を「拡張機能のみ」にすると、拡張キー使用法のクライアント認証と、1.3.6.1.4.1.51150.13.1 の拡張が表示される（サブジェクト キー識別子と機関キー識別子の値はマスク）](https://info.nextmode.co.jp/hs-fs/hubfs/okta-single-certificate-issuer-sensor-mode-intune-11.png?width=703&height=933&name=okta-single-certificate-issuer-sensor-mode-intune-11.png)](https://info.nextmode.co.jp/hubfs/okta-single-certificate-issuer-sensor-mode-intune-11.png)

証明書の「詳細」タブ（表示は「拡張機能のみ」）

証明書の「全般」タブには「情報不足のため、この証明書を検証できません。」と表示されます。これは上位のルート CA の証明書が端末にないためで、検証では登録と「管理対象」の判定に影響しませんでした。秘密鍵の格納先は、管理者権限で `certutil -store My <証明書の拇印>` を実行し、「プロバイダー」の行で確認できます。検証では「Microsoft Platform Crypto Provider」と表示され、秘密鍵はエクスポートできない状態で TPM に格納されていました。

### 端末の登録の確認

端末の登録は、Okta Admin Console の「ディレクトリ」\>「デバイス」とシステムログで確認します[\[10\]](https://help.okta.com/oie/ja-jp/content/topics/identity-engine/devices/device-posture-sensor-mode-check-registration.htm)。検証では、利用者のサインインなしで端末が Okta に登録されました。

システムログには、次のイベントが記録されます。

| 表示名 | eventType | 結果 |
| --- | --- | --- |
| Enroll new device | `device.enrollment.create` | 記録された |
| Activate device | `device.lifecycle.activate` | 記録された |
| Bind client certificate to device | `pki.cert.bind` | 端末の登録時の1回だけ記録された |

### サインインの確認

手順5のポリシーを割り当てた Okta Dashboard に、その端末で FastPass を登録していない利用者で端末のブラウザーからサインインします。システムログのポリシーの評価のイベント（`policy.evaluate_sign_on`）で、どのルールが適用されたのかを確認します。

検証では優先度1のルールが適用され、Okta Dashboard にサインインできました。同じグループを対象にした拒否のルールではなく優先度1のルールが適用されたことから、端末が「登録済み」と「管理対象」の両方の条件を満たしたことが分かります。利用者は、パスワードとスマートフォンの Okta Verify のプッシュ通知で認証しました。

また、証明書を端末に結び付けるイベント（`pki.cert.bind`）は端末の登録時の1回だけ記録され、サインインのときには記録されませんでした。以前の記事の検証では、管理証明書は最初のサインインのときに端末に結び付けられました。本記事の構成では、登録時に端末に結び付けられた証明書がそのまま管理証明にも使用されたと考えられます。

Okta Admin Console の「ディレクトリ」\>「デバイス」でも、「デバイス管理」を「管理対象」に絞り込むと端末が一覧に表示されました。端末の行に「管理対象」とは表示されないため、この絞り込みで確認します。ユーザーの数は「0ユーザー」で、利用者が Okta Verify に登録した端末ではないことも分かります。

[![Okta Admin Console の「ディレクトリ」\>「デバイス」。「デバイス管理」を「管理対象」に絞り込んだ一覧に、SURFACE\_LAPTOP2 が「0ユーザー」、プラットフォームが Windows、ステータスが「アクティブ」で表示されている（SID はマスク）](https://info.nextmode.co.jp/hs-fs/hubfs/okta-single-certificate-issuer-sensor-mode-intune-12.png?width=1924&height=1046&name=okta-single-certificate-issuer-sensor-mode-intune-12.png)](https://info.nextmode.co.jp/hubfs/okta-single-certificate-issuer-sensor-mode-intune-12.png)

「デバイス管理」を「管理対象」に絞り込んだ端末の一覧

### 確認結果

| 確認内容 | 結果 |
| --- | --- |
| Okta の証明書が1枚だけ、ローカルコンピューターの個人ストアに配置されるか | 配置された（ほかは Microsoft Entra 参加と Intune の証明書） |
| 証明書の発行元が、単一の証明書発行者で構成した CA か | 手順2の CA から発行された（機関キー識別子が SCEP URL と一致） |
| 証明書に、センサーモードの登録用の拡張（`1.3.6.1.4.1.51150.13.1`）が含まれるか | 含まれた |
| 秘密鍵が TPM に格納されるか | 格納された（エクスポート不可） |
| 利用者のサインインなしで、端末が Okta に登録されるか | 登録された |
| 端末で FastPass を登録していない利用者のサインインで、「登録済み」と「管理対象」と判定されるか | 判定された（手順5の優先度1のルールで Okta Dashboard にサインイン） |
| 管理証明のために、証明書がサインインのときに改めて端末に結び付けられるか | 結び付けられなかった（`pki.cert.bind` は端末の登録時の1回だけ） |

## 運用上の注意

証明書が1枚になり、運用で扱う CA、SCEP 構成、構成プロファイルも1つずつになります。一方で、1つの CA が2つの用途を担うため、CA の信頼の設定を変更すると両方の条件に影響します。

### CA の信頼の変更

本記事の構成では、1つの CA の2つの信頼の設定が手順5のルールの2つの条件に対応します。検証では、「管理証明」タブで CA の信頼を外すと、管理証明に依存するアクセスポリシーを保存の前に更新するよう求める警告が表示されました。

[![「管理証明設定」の画面。「信頼済みから非信頼への変更」の警告が表示され、「信頼できる認証局」の Okta CA（CAタイプ：Device Access）と Okta CA（CAタイプ：エンドポイント管理）の選択が外れている](https://info.nextmode.co.jp/hs-fs/hubfs/okta-single-certificate-issuer-sensor-mode-intune-13.png?width=421&height=441&name=okta-single-certificate-issuer-sensor-mode-intune-13.png)](https://info.nextmode.co.jp/hubfs/okta-single-certificate-issuer-sensor-mode-intune-13.png)

管理証明の信頼を外すときの警告

信頼を外した後に検証用の利用者でサインインすると、端末は登録されたまま優先度2の拒否のルールが適用され、サインインは拒否されました。「管理対象」の条件だけを満たせなくなったことが分かります。利用者の画面には、要求が拒否されたことを示すエラーが表示されます。

[![Okta のエラー画面。「リソースの所有者または認可サーバーは要求を拒否しました。」と表示されている](https://info.nextmode.co.jp/hs-fs/hubfs/okta-single-certificate-issuer-sensor-mode-intune-14.png?width=283&height=372&name=okta-single-certificate-issuer-sensor-mode-intune-14.png)](https://info.nextmode.co.jp/hubfs/okta-single-certificate-issuer-sensor-mode-intune-14.png)

管理証明の信頼を外した後のサインイン（利用者の画面）

デバイス登録の信頼を外したときの動作は、本記事では確認していません。Okta のドキュメントによると、「デバイス登録」タブで CA の選択を外すと端末を登録できなくなる可能性があるという警告が表示され、保存の前にその CA の信頼を前提とするポリシーを更新するよう案内されます[\[11\]](https://help.okta.com/oie/ja-jp/content/topics/identity-engine/devices/config-device-registration.htm)。

### 証明書の更新

Okta の CA は更新リクエストをサポートしないため、証明書の有効期限が切れる前にプロファイルを再配布して証明書を交換します[\[12\]](https://help.okta.com/oie/ja-jp/content/topics/identity-engine/devices/configure-ca-main.htm)。Intune では SCEP 証明書プロファイルの更新しきい値がこの再配布にあたり、本記事の構成では更新しきい値を設定するプロファイルも1つです。再発行された証明書で「登録済み」と「管理対象」の判定が維持されるかは、本記事では確認していません。

### クライアントシークレットの期限

手順1のクライアントシークレットの期限が切れると、新しい端末への証明書の発行と更新しきい値による再発行が失敗します。期限が切れる前に新しいシークレットを作成し、Okta の SCEP 構成に入力します。本記事の構成では、入力する SCEP 構成は1つです。

### 端末の削除と再利用

端末を廃棄する場合や別の用途で再利用する場合は、管理者が Okta Admin Console で端末を非アクティブ化してから削除します。Okta のドキュメントでは、非アクティブ化するとデスクトップの端末ではデバイス証明書が取り消されると説明されています[\[13\]](https://help.okta.com/oie/ja-jp/Content/Topics/identity-engine/devices/devices-lifecycle.htm)。検証では、端末に結び付いていた証明書が一時停止として記録されました（`pki.cert.lifecycle.suspend`）。

同じ端末を再び使用する場合は、Okta Verify をアンインストールしてから再インストールします。検証では、端末を削除した後も端末の Okta Verify には登録が残ったままで、Okta には自動で登録されませんでした。このとき、Okta Verify の要求は `invalid_token` で失敗し、利用者のサインインも Okta Verify を開く画面から先に進めませんでした。Okta Verify を入れ直すと、端末は新しい端末として登録されました。

証明書は発行し直されず、一時停止されていた同じ証明書が新しい端末に結び付けられました（`pki.cert.bind`）。証明書を配布し直さなくても、Okta Verify を入れ直すだけで登録し直せます。

## おわりに

今回の検証では、単一の証明書発行者を使うと Windows 端末を1枚の証明書で「登録済み」かつ「管理対象」と判定でき、以前の記事の構成で2つずつ必要だった CA、SCEP 構成、構成プロファイルを1つずつにまとめられることを確認しました。

設定するときだけでなく、証明書の更新やクライアントシークレットの入れ替えでも扱う対象が1つで済むため、運用が楽になるとても便利な機能だと感じました。証明書を2つ使う構成も、いずれこちらに一本化されていくことを期待しています。

今後も、Okta で端末を管理するときに役立つ機能を検証して紹介していきますのでお楽しみに！

### 参考資料

1. \[1\][デバイスポスチャセンサーモード](https://help.okta.com/oie/ja-jp/content/topics/identity-engine/devices/device-posture-sensor-mode-main.htm)（Okta）
2. \[2\][単一の証明書発行者](https://help.okta.com/oie/ja-jp/content/topics/identity-engine/devices/single-cert-issuer-overview.htm)（Okta）
3. \[3\][Microsoft IntuneでのWindows向け委任SCEP](https://help.okta.com/oie/ja-jp/content/topics/oda/ca/oda-ca-scep-windows-intune-delegated.htm)（Okta）
4. \[4\][Microsoft Intune で信頼された証明書プロファイルを作成する](https://learn.microsoft.com/ja-jp/intune/device-configuration/certificates/trusted-root-profiles)（Microsoft）
5. \[5\][ClientCertificateInstall CSP](https://learn.microsoft.com/ja-jp/windows/client-management/mdm/clientcertificateinstall-csp)（Microsoft）
6. \[6\][Intune で SCEP 証明書プロファイルを作成して割り当てる](https://learn.microsoft.com/ja-jp/intune/device-configuration/certificates/scep-profiles)（Microsoft）
7. \[7\][Windowsデバイス向けのOkta Verify構成](https://help.okta.com/oie/ja-jp/content/topics/identity-engine/devices/managed-app-configs-win.htm)（Okta）
8. \[8\][登録済みデバイスポリシーを作成して適用する](https://help.okta.com/oie/ja-jp/Content/Topics/identity-engine/devices/device-posture-sensor-mode-configure-policy.htm)（Okta）
9. \[9\][証明書のデプロイメントを検証する](https://help.okta.com/oie/ja-jp/content/topics/oda/ca/oda-ca-scep-verify.htm)（Okta）
10. \[10\][Okta Verifyでデバイス登録を確認する](https://help.okta.com/oie/ja-jp/content/topics/identity-engine/devices/device-posture-sensor-mode-check-registration.htm)（Okta）
11. \[11\][デバイス登録の設定を構成する](https://help.okta.com/oie/ja-jp/content/topics/identity-engine/devices/config-device-registration.htm)（Okta）
12. \[12\][認証局を構成する](https://help.okta.com/oie/ja-jp/content/topics/identity-engine/devices/configure-ca-main.htm)（Okta）
13. \[13\][デバイスライフサイクル](https://help.okta.com/oie/ja-jp/Content/Topics/identity-engine/devices/devices-lifecycle.htm)（Okta）

#### Okta に関するお問い合わせ

ネクストモードでは Okta の導入から運用まで一貫したご支援を提供しております。Okta に関する各種ご相談は、ネクストモードまでお気軽にお問い合わせください。

[![SaaSバナー\_Okta](https://hubspot-no-cache-na2-prod.s3.amazonaws.com/cta/default/20481958/interactive-256988631778.png)](https://info.nextmode.co.jp/hs/cta/wi/redirect?encryptedPayload=AVxigLJ15KNZpew4aGtmvi1rEQ%2B1mdVIaveuWUhqKN%2BXC%2FuKrmp86FPMsl%2BuHfYiFgS1m05Q2PA%2BJhONlAn2aF7Oj3SEBjPGqa8ING879h311eYKeeFt3s%2BPSuqWU2bVtDdZn53V6gOVwqgUj5bF5fgGg%2Bggm%2BdxkrpVM7kJqFsgDgDeZPijKj58S1zJfHeS8%2Fi5HkRv660VprYECK7Fa4pl48L9&webInteractiveContentId=256988631778&portalId=20481958)

### 関連記事

[![私には自由を、不正アクセスには厳しさを｜Notion・Okta・Netskopeと働く話](https://info.nextmode.co.jp/hubfs/okta_netskope_notion.png) 私には自由を、不正アクセスには厳しさを｜Notion・Okta・Netskopeと働く話 ![](https://info.nextmode.co.jp/hubfs/240DA746-DD03-495C-BB72-FF7CF3850C9D.png) よね 2026/11/02](https://info.nextmode.co.jp/blog/notion_okta_netskope_security)

[![【Okta】Org2Org のサインインと再認証を IdP Org に集約する](https://info.nextmode.co.jp/hubfs/%E3%83%96%E3%83%AD%E3%82%B0%EF%BC%BF%E3%82%AD%E3%83%BC%E3%83%93%E3%82%B8%E3%83%A5%E3%82%A2%E3%83%AB/Okta_Blog-1.png) 【Okta】Org2Org のサインインと再認証を IdP Org に集約する テクニカルサポート 2026/11/01](https://info.nextmode.co.jp/blog/okta-org2org-sign-in-reauthentication)

[![【Okta】OAuth 2.0 と鍵の自動ローテーションで構成する Org2Org プロビジョニング設定](https://info.nextmode.co.jp/hubfs/%E3%83%96%E3%83%AD%E3%82%B0%EF%BC%BF%E3%82%AD%E3%83%BC%E3%83%93%E3%82%B8%E3%83%A5%E3%82%A2%E3%83%AB/Okta_Blog-1.png) 【Okta】OAuth 2.0 と鍵の自動ローテーションで構成する Org2Org プロビジョニング設定 テクニカルサポート 2026/11/01](https://info.nextmode.co.jp/blog/okta-org2org-oauth-provisioning)

### Category

[» 技術](https://info.nextmode.co.jp/blog/tag/技術) [» Okta](https://info.nextmode.co.jp/blog/tag/okta) [» Notion](https://info.nextmode.co.jp/blog/tag/notion) [» イベントレポート](https://info.nextmode.co.jp/blog/tag/イベントレポート) [» Netskope](https://info.nextmode.co.jp/blog/tag/netskope) [» CrowdStrike](https://info.nextmode.co.jp/blog/tag/crowdstrike) [» Notion AI](https://info.nextmode.co.jp/blog/tag/notion-ai) [» AWS](https://info.nextmode.co.jp/blog/tag/aws) [» Asana](https://info.nextmode.co.jp/blog/tag/asana) [» カルチャー](https://info.nextmode.co.jp/blog/tag/カルチャー) [» ワーケーション](https://info.nextmode.co.jp/blog/tag/ワーケーション) [» 生成AIセキュリティ対策シリーズ](https://info.nextmode.co.jp/blog/tag/生成aiセキュリティ対策シリーズ) [» Oktane25](https://info.nextmode.co.jp/blog/tag/oktane25) [» SaaS](https://info.nextmode.co.jp/blog/tag/saas) [» リモートワーク](https://info.nextmode.co.jp/blog/tag/リモートワーク) [» AI](https://info.nextmode.co.jp/blog/tag/ai) [» re:Invent](https://info.nextmode.co.jp/blog/tag/reinvent) [» Keeper](https://info.nextmode.co.jp/blog/tag/keeper) [» ネクストモードアドベントカレンダー2024](https://info.nextmode.co.jp/blog/tag/ネクストモードアドベントカレンダー2024) [» Oktane24](https://info.nextmode.co.jp/blog/tag/oktane24) [» Oktane23](https://info.nextmode.co.jp/blog/tag/oktane23) [» Oktane26](https://info.nextmode.co.jp/blog/tag/oktane26) [» Asana AI](https://info.nextmode.co.jp/blog/tag/asana-ai) [» OIGシリーズ](https://info.nextmode.co.jp/blog/tag/oigシリーズ) [» Slack](https://info.nextmode.co.jp/blog/tag/slack) [» その他](https://info.nextmode.co.jp/blog/tag/その他) [» 脱Excelシリーズ](https://info.nextmode.co.jp/blog/tag/脱excelシリーズ) [» SysCloud](https://info.nextmode.co.jp/blog/tag/syscloud) [» Oktane22](https://info.nextmode.co.jp/blog/tag/oktane22) [» Google](https://info.nextmode.co.jp/blog/tag/google) [» HubSpot](https://info.nextmode.co.jp/blog/tag/hubspot) [» Zapier](https://info.nextmode.co.jp/blog/tag/zapier) [» セキュリティ対策](https://info.nextmode.co.jp/blog/tag/セキュリティ対策) [» ゼロトラスト](https://info.nextmode.co.jp/blog/tag/ゼロトラスト) [» Azure AD](https://info.nextmode.co.jp/blog/tag/azure-ad) [» Entra ID](https://info.nextmode.co.jp/blog/tag/entra-id) [» Googleドライブ](https://info.nextmode.co.jp/blog/tag/googleドライブ) [» SentinelOne](https://info.nextmode.co.jp/blog/tag/sentinelone) [» DocuSign](https://info.nextmode.co.jp/blog/tag/docusign) [» Jamf](https://info.nextmode.co.jp/blog/tag/jamf) [» トラブルシューティング](https://info.nextmode.co.jp/blog/tag/トラブルシューティング) [» 利用者目線](https://info.nextmode.co.jp/blog/tag/利用者目線) [» 運用](https://info.nextmode.co.jp/blog/tag/運用) [» GitHub](https://info.nextmode.co.jp/blog/tag/github) [» GitHub Gist](https://info.nextmode.co.jp/blog/tag/github-gist) [» Intune](https://info.nextmode.co.jp/blog/tag/intune) [» JOUG](https://info.nextmode.co.jp/blog/tag/joug) [» Notion Calendar](https://info.nextmode.co.jp/blog/tag/notion-calendar) [» Proflly](https://info.nextmode.co.jp/blog/tag/proflly) [» Windows](https://info.nextmode.co.jp/blog/tag/windows) [» kintone](https://info.nextmode.co.jp/blog/tag/kintone)

[![ネクストモード株式会社](https://nextmode.co.jp/assets/images/common/logo_white.svg)](https://nextmode.co.jp/)

Service

- [生成AIセキュリティ](https://nextmode.co.jp/services/ai/security/)
- [SaaSライセンス＆サポート](https://nextmode.co.jp/services/saas/) 
    - [Oktaライセンス＆サポート](https://nextmode.co.jp/services/saas/okta/)
    - [Netskopeライセンス＆サポート](https://nextmode.co.jp/services/saas/netskope/)
    - [Notionライセンス＆サポート](https://nextmode.co.jp/services/saas/notion/)
    - [Asanaライセンス＆サポート](https://nextmode.co.jp/services/saas/asana/)
    - [SysCloudライセンス＆サポート](https://nextmode.co.jp/services/saas/syscloud/)
    - [CrowdStrikeライセンス＆サポート](https://nextmode.co.jp/services/saas/crowdstrike/)
    - [Keeperライセンス＆サポート](https://nextmode.co.jp/services/saas/keeper/)
- [AWS総合支援](https://nextmode.co.jp/services/aws/) 
    - [AWS導入コンサル・構築](https://nextmode.co.jp/services/aws_consulting/)
    - [AWS運用・保守代行](https://nextmode.co.jp/services/aws_operation/)

Company

- [会社情報](https://nextmode.co.jp/company/)
- [サービス一覧](https://nextmode.co.jp/services/)
- [導入事例](https://nextmode.co.jp/casestudy/)
- [お知らせ](https://nextmode.co.jp/news/)
- [サステナビリティ](https://nextmode.co.jp/sustainability/)
- [採用](https://nextmode.co.jp/recruit/)
- [私たちの働き方](https://nextmode.co.jp/workstyle/)
- [カルチャー](https://nextmode.co.jp/culture/)

Contact

- [お問い合わせ](https://nextmode.co.jp/contact/)
- [資料請求](https://info.nextmode.co.jp/request/)

Media

- [セミナー](https://info.nextmode.co.jp/seminar)
- [ブログ](https://info.nextmode.co.jp/blog)
- [ホワイトペーパー](https://info.nextmode.co.jp/white-paper/)

- [![ネクストモード公式YouTubeチャンネル](https://nextmode.co.jp/assets/images/common/icon_youtube.svg)](https://www.youtube.com/channel/UCeW8ocoe9C3E0GOINh167MA)
- [![ネクストモード公式Xアカウント](https://nextmode.co.jp/assets/images/common/icon_x.svg)](https://twitter.com/Nextmode_Inc)

[English](https://nextmode.co.jp/en/)

- [NTTグループカスタマーハラスメント基本方針](https://group.ntt/jp/group/customer_harassment/)
- [就活ハラスメント防止方針](https://docs.nextmode.co.jp/nextmode_recruit_harassment.pdf)

- 運用アシスタント利用規約([AWS](https://docs.nextmode.co.jp/nextmode-unyo-assistant-aws-terms-of-use.pdf)/[Azure](https://docs.nextmode.co.jp/nextmode-unyo-assistant-azure-terms-of-use.pdf))
- [日中運用支援定型約款](https://docs.nextmode.co.jp/nextmode-nittyu-unyo-shien-terms-of-use.pdf)
- [定型約款](https://docs.nextmode.co.jp/nextmode-standard-contracts.pdf)

[プライバシーポリシー](https://nextmode.co.jp/company/privacy.html)

Copyright(c) Nextmode, Inc.

```json
{
  "@context" : "https://schema.org",
  "@type" : "BlogPosting",
  "author" : {
    "@type" : "Person",
    "name" : "yuki",
    "url" : "https://info.nextmode.co.jp/blog/author/yuki"
  },
  "dateModified" : "2026-11-03T23:00:00.910Z",
  "datePublished" : "2026-11-03T23:00:00.000Z",
  "headline" : "【Okta】1枚の証明書で Windows 端末を自動登録し管理対象にする単一の証明書発行者を試してみた｜Nextmode Blog",
  "image" : [ "https://info.nextmode.co.jp/hubfs/Okta_Blog.png" ],
  "mainEntityOfPage" : {
    "@id" : "https://info.nextmode.co.jp/blog/okta-single-certificate-issuer-sensor-mode-intune",
    "@type" : "WebPage"
  },
  "publisher" : {
    "@type" : "Organization",
    "logo" : {
      "@type" : "ImageObject",
      "url" : "https://info.nextmode.co.jp/hubfs/nm_l_color.png"
    },
    "name" : "ネクストモード株式会社"
  }
}
```

```json
{
  "@context" : "https://schema.org",
  "@id" : "https://nextmode.co.jp/#organization",
  "@type" : "Organization",
  "alternateName" : "Nextmode, Inc.",
  "logo" : "https://nextmode.co.jp/assets/images/common/logo_white.svg",
  "name" : "ネクストモード株式会社",
  "sameAs" : [ "https://www.youtube.com/channel/UCeW8ocoe9C3E0GOINh167MA", "https://twitter.com/Nextmode_Inc", "https://info.nextmode.co.jp/" ],
  "url" : "https://nextmode.co.jp/"
}
```