【Okta】 Jamf Pro から プラットフォームシングルサインオン (PSSO) を展開する
Jamf Pro + Microsoft Entra ID でプラットフォーム シングル サインオンを展開する記事がありますが、今回は Okta の Platform Single Sign-On for macOS を展開する例をご紹介します。
今回は Iru (旧Kandji) から展開してみようかな・・と思いましたが、Iru ユーザなら Passport を使用するだろうと思い、やはり今回も Jamf Pro から展開する例を書きたいと思います。
1. はじめに macOS プラットフォーム シングル サインオン (PSSO) とは
プラットフォームシングルサインオン（プラットフォームSSO）で、デベロッパは macOS のログインウインドウにまでおよぶ SSO機能拡張を構築して、ユーザがローカルアカウントの資格情報をIDプロバイダ（IdP）と同期できるようにできます。ローカルアカウントのパスワードが自動的に同期された状態で保存されるため、クラウドのパスワードとローカルパスワードが一致します。
Apple プラットフォーム導入：macOS のプラットフォームシングルサインオン
簡単に言うと、macOS の機能拡張によりIDプロバイダのアカウントを使って以下のことをできるようにします。
- Mac にローカルアカウントを作成する
- Mac のローカルアカウントとパスワードを同期する
展開の要件は以下のとおりです。
展開の要件
- Okta Identity Engine org を利用できる。
- Okta Device Access ライセンスの契約。
- macOS 14 Sonoma 以上の Mac （サポートは macOS 13 Ventura 以上）
- Okta Verify Authenticator がセットアップされている。
- ユーザーにパスワードが構成されていること。
2. Jamf Connect との違い
※ Entra ID版とほぼ同じ内容です
（「わかってます。」という人は読み飛ばしてください）
ローカルアカウントの作成やローカルパスワード同期といった、似た機能をもつ Jamf Connect と比較されることが多いと思いますが、
PSSO と Jamf Connect の最も大きな違いは、Okta 資格情報の利用前に端末を Okta に登録する必要があるか否かです。
- Jamf Connect では、Okta に端末を登録することなく Okta 資格情報を利用できます。
- PSSO では、Okta に端末を登録した後から Okta 資格情報が利用できるようになります。
つまり、Jamf Connect は自動デバイス登録からのユーザ作成に使用することができ、PSSO はあらかじめ作成したローカルアカウントに対して Okta のアカウントを紐づける動作になります。
この違いは、Mac の自動デバイス登録からのキッティングプロセスに利用者自身のアカウント作成と IDプロバイダ へのログインのプロセスを違和感なく組み込めるか？
という点に影響します。
今回はできるだけこの違いを意識せずに PSSO を使えるよう、登録カスタマイゼーションの機能を活用した導入のフローをご紹介しようと思います。
MDM への登録の過程では、Jamf Connect っぽくIDプロバイダ への認証をしつつ、PSSO 設定は MDM 登録後に行ってパスワードの同期をとるようにします。
今回ご紹介するフロー
2024年の秋頃から Okta ではジャストインタイムローカルアカウント作成の仕組みに対応するようになり、ローカルアカウントの作成から Okta の認証資格情報を使用することができるようになりました。
ただ、キッティングのフロー次第だと思いますが、利用者がはじめから電源をONしてセットアップする上記のようなフローでは、あまりその機能自体が必要に感じることは少ないかもしれません。
3. 設定開始
早速実践してみましょう！
今回ご紹介するフローは以下の設定が必要です。
3-1. シングルサインオン設定【 Okta・Jamf Pro 】
3-2. 登録カスタマイゼーション構成【 Jamf Pro 】
3-3. 事前登録へ登録カスタマイゼーション構成を追加【 Jamf Pro 】
3-4. LDAP設定【 Jamf Pro 】
3-5. Platform Single Sign On アプリのセットアップ【 Okta 】
3-6. 構成プロファイルの作成（動的SCEPプロファイル）【Okta・Jamf Pro】
3-7. 構成プロファイルの作成（デバイス管理プロファイル）【 Jamf Pro 】
3-8. Okta Verify App の展開【 Okta・Jamf Pro 】
それぞれのポイントを説明していきます。
3-1. シングルサインオン設定 【 Okta・Jamf Pro 】
Okta SSO と Jamf Pro を統合し、登録カスタマイゼーション構成にて使用します。実施手順はこちらをご覧ください。
＜ナビゲーション＞
Jamf Pro の［設定］＞ [システム] ＞ [シングルサインオン]
※登録カスタマイゼーションにて「LDAP認証」する場合は、こちらは設定せずLDAP設定をしていただければ OK です。
3-2. 登録カスタマイゼーション構成 【 Jamf Pro 】
登録時に Okta への認証要求をするために登録カスタマイゼーション設定をしておきます。「シングルサインオン」もしくは「LDAP認証」が使用できます。今回は「シングルサインオン」で設定します。
＜ナビゲーション＞
Jamf Pro の［設定］＞ [グローバル] ＞ [登録カスタマイゼーション]
3-2. 登録カスタマイゼーション構成
3-3. 事前登録へ登録カスタマイゼーション構成を追加 【 Jamf Pro 】
Jamf Pro の［コンピュータ］＞ 事前登録から、自動デバイス登録時に 3−2. で作成した登録カスタマイゼーション設定を使用して Okta への認証を行うように設定しておきます。
＜ナビゲーション＞
Jamf Pro の[コンピュータ]＞ [事前登録]
3-3. 事前登録へ登録カスタマイゼーション構成を追加
ポイントは、[アカウント設定] セクションにて 、下記画像のように「プライマリアカウント情報の事前入力」を行うようにして、その値の編集を可能にしておく点です。
プライマリアカウント情報の事前入力設定
値の編集を可能にしておく理由は、作成されるアカウントのユーザ名が メールアドレス形式で設定されてしまうためです。
そのため、任意の表示へ変更できるようにしています。
プライマリアカウント情報のロックについて
ホームディレクトリやユーザ名がメールアドレス形式で問題なければ、値の編集を可能にしなくても結構です。
3-4. LDAP設定 【 Jamf Pro 】
※この設定はなくても動作します
※長くなってしまうので、Okta のLDAPインターフェース設定は実施済の前提で Jamf での操作のみ記述します。
Jamf Pro の インベントリ情報に利用ユーザの情報を表示するためにLDAP連携設定を実施します。
設定内容は、Okta のこちらのページを参考にしてください。
ご参考までに、弊社で検証した際の設定スクリーンショットを載せておきます。
＜ナビゲーション＞
Jamf Pro の［設定］＞ [システム ]＞ [LDAPサーバ]
3-4. LDAP設定の例
3-5. Platform Single Sign On アプリの登録 【Okta】
Okta Admin Console で Platform Single Sign On アプリを登録します。
＜ナビゲーション＞
Okta Admin Console の［アプリケーション］>［アプリケーション］
3.5.1 ［アプリカタログを参照］ボタンを押下します。
3.5.2 検索窓に「Platform Single Sign On」と入力して表示される Okta のアプリを選択します。
3.5.3 [サインオン]タブを選択して「クライアントID」をコピーします。
※後ほど使用します。
3.5.4 [割り当て]タブを選択して、利用者グループ もしくは ユーザを指定します。
3-5. Platform Single Sign On アプリの登録
3-6. 構成プロファイルの作成（動的SCEPプロファイル）【Okta・Jamf Pro】
ここでは、デバイスアクセスのSCEP証明書を配布するための設定を実施します。
まず、Okta でデバイス統合設定を作成します。
参考サイト：
＜ナビゲーション＞
Okta Admin Console の［セキュリティ］>［デバイス統合］
3.6.1 ［デバイスアクセス］タブを選択して、［SCEP構成を追加］
3.6.2 SCEP URLチャレンジタイプのラジオボタンは「動的SCEP URL」＞「汎用」を選択します
3.6.3 SCEP URLの［生成］ボタンでURLやユーザ名など、後続のプロファイルで使用する値を生成します。
3-6. Okta のデバイス統合設定(赤文字は構成プロファイル上の項目とのマッピング)
「デバイスアクセス」タブを選択することを忘れずに・・・私はここをミスってハマりました。
次に、Jamf Pro 側でSCEP証明書配布用のプロファイルを作成します。
設定例を参考に設定してください。
＜ナビゲーション＞
Jamf Pro の［コンピュータ］>［構成プロファイル］
設定例
3-6. Jamf Pro 側のSCEP証明書 配布設定
3-7. 構成プロファイルの作成（デバイス管理プロファイル） 【 Jamf Pro 】
Platform Single Sign-On の機能を使用するためのプロファイルを作成します。
参考サイト：
このプロファイルには、以下３つのペイロードを構成する必要があります。
3-7-1. シングルサインオン機能拡張
3-7-1. シングルサインオン機能拡張
＜設定値＞
ペイロードタイプ：SSO
拡張識別子：com.okta.mobile.auth-service-extension
チーム識別子：B7F62B65BN
サインオンのタイプ：リダイレクト
URL：以下 2つを入力
https://お客様組織.okta.com/device-access/api/v1/nonce
https://お客様組織.okta.com/oauth2/v1/token
プラットフォーム SSO を使用する：有効
認証方式：パスワード
登録トークン：任意の文字列（何でもOK。例では oktapsso と入力しました）
共有デバイスキーを使用：有効
ログイン時に新しいユーザを作成：有効
アイデンティティプロバイダの認証：有効
ユーザマッピング氏名：macOSAccountFullName
ユーザマッピングアカウント名：macOSAccountUsername
アカウント認証タイプ：Admin
新しいユーザアカウントタイプ：Admin
3-7-2. 関連するドメイン
3-7-2. 関連するドメイン
＜設定値＞
アプリ識別子①：B7F62B65BN.com.okta.mobile
関連するドメイン①：authsrv:お客様組織.okta.com
アプリ識別子②：B7F62B65BN.com.okta.mobile.auth-service-extension
関連するドメイン②：authsrv:お客様組織.okta.com
3-7-3. アプリケーションとカスタム設定
3つの設定をアップロードします。
3-7-3. アプリケーションとカスタム設定
環境設定ドメイン：com.okta.mobile.auth-service-extension
<plist version="1.0">
<dict>
<key>OktaVerify.OrgUrl</key>
<string>https://お客様組織.okta.com</string>
<key>OktaVerify.UserPrincipalName</key>
<string>$USERNAME</string>
<key>OktaVerify.PasswordSyncClientID</key>
<string> 3−5.で作成した Platform Single Sign On アプリのクライアントID </string>
<key>PlatformSSO.ProtocolVersion</key>
<string>2.0</string>
</dict>
</plist>
環境設定ドメイン：com.okta.mobile
<plist version="1.0">
<dict>
<key>OktaVerify.OrgUrl</key>
<string>https://お客様組織.okta.com</string>
<key>OktaVerify.UserPrincipalName</key>
<string>$USERNAME</string>
<key>OktaVerify.PasswordSyncClientID</key>
<string> 3−5.で作成した Platform Single Sign On アプリのクライアントID </string>
</dict>
</plist>
環境設定ドメイン：com.apple.preference.security
<plist version="1.0">
<dict>
<key>dontAllowPasswordResetUI</key>
<true/>
</dict>
</plist>
3-8. Okta Verify App の展開 【 Okta・Jamf Pro 】
内容重複するので、下記リンク先にある
＞3-4. Okta Verify 配布 (Okta・MDM)
を参考にしてください。
3-9. (オプション) Desktop MFA for MacOS の設定を展開する
必要に応じて、上記リンクの内容もあわせて実施してください。
この設定を実施すると、パスワード入力後に本人確認の多要素認証画面に遷移します。
4. 動作確認
4-1. 自動デバイス登録からの展開
準備ができたら、対象の Mac を 3-3. で構成した事前登録のSCOPEに割当を行ってから、初期化してください。
4-1-1. リモートマネジメント画面の表示。［登録］ボタンを押下
4-1-2. 登録カスタマイゼーション画面の表示
4-1-3. Okta アカウント入力
4-1-4. Okta パスワード入力
4-1-5 多要素認証・確認画面等
4-1-6. コンピュータアカウント作成
初期状態では Okta から取得されたアカウント名（@マーク以下があるメールアドレス形式）が表示されています。
アカウント名を編集し、@以下は削除することをおすすめします。
登録完了後、少し待つと登録の通知が表示さます。
4-1-7. 登録通知の表示。
4-1-8. プラットフォームSSOのダイアログ表示
ローカル管理者アカウントで認証する必要があります。
4-1-9. Okta のアカウント/パスワードを入力して認証
4-1-10. 登録完了の画面が表示される
ここまでの作業で Mac は Okta へ登録されます。
（まだパスワードは同期されていません。）
ここからの作業で、ログインアカウントとサインインする Okta のアカウントを紐付けて同期します。
4-1-11. 紐づけ対象の Okta アカウントへのサインイン
4-1-12. パスワードがアップデートされた旨の通知
4-2. 利用中端末へ展開する場合
上記 4-1-7. 以降の動作と同じになります。
5. 気づいたこと・注意点
① パスワード変更時の動作
macOS 15 から、PSSO 認証が FileVault に拡張されました。
（FileVault プラットフォームSSOは、Apple シリコン搭載の Macコ ンピューターでのみサポートされます。）
ただ、個人的にはそのことでどの様な影響があるのかがよくわかりませんでした。いろいろとパスワード変更のオペレーションを試しているうちに、Okta でパスワードリセットをしてから、パスワード同期のパターンが 2通りあることに気がついたので以下にまとめます。
当たり前なことなのかもしれませんが、私は動作の違いを理解するのに時間がかかりました。
操作マニュアルの作成時など、必要に応じて参考にしてください。
パスワード同期のパターン
・パターン1：IDプロバイダへのサインインを求められるパターン
・パターン2：パスワード同期画面が表示され、ローカルアカウント
（旧パスワード）を入力してパスワード同期をするパターン
パターン1：IDプロバイダへのサインインを求められるパターン
通常はこの画面が表示されることが多いと思います。
IDプロバイダへのサインインを求められる
Okta でのパスワードリセット後、以下のいずれかの動作をした場合、上の画像の画面が表示されました。
- 端末のロック解除等のタイミングで Okta 側でローカルパスワードとIDプロバイダのパスワード差異を検知した場合
- 1. が発生する前に再起動し、FileVault の解除パスワードとして ローカルパスワード（旧パスワード）を入力してホーム画面でまで遷移した場合
表示されるポップアップに従い、IDプロバイダへのサインインをするとローカルアカウントのパスワードが Okta のパスワードで同期されます。
パターン2：パスワード同期画面が表示され、ローカルアカウント（旧パスワード）を入力してパスワード同期をするパターン
この様なパスワード同期画面が表示されます
「以前のパスワードを入力」でパスワード同期される
Okta でパスワードリセット後、パターン１の IDプロバイダへのサインイン画面が表示される前に再起動して、FileVault の解除パスワードとして変更後の IDプロバイダのパスワード（新パスワード）を入力してホーム画面まで遷移すると macOS 側の Platform SSO が Okta での変更を検知し、 上の画像の画面を表示します。
パスワード同期するには「以前のパスワードを入力」を選択し、ローカルアカウントのパスワード（Okta の旧パスワード ）を入力してください。
認証に成功すると、macOS は現在の Okta のパスワードとローカルアカウントのパスワードが一致しているかを確認し、不一致の場合はローカルアカウントのパスワードも Okta の新しいパスワードに更新します。
上記から分かる通り、
FileVault が有効な場合、Okta パスワード変更後すぐに（＝ローカルアカウントのパスワード同期をする前に）再起動すると、入力パスワードによって動作が変わります。
簡単なフローにすると以下のとおりです。
Okta パスワード変更後、すぐに再起動した場合の 入力パスワードによる動作の違い
② FileVault ネットワークの要件
リンク先に、FileVault で機能する Wi-Fi 接続のネットワークタイプは、Openまたは WPA2 Personal のみとあるのですが、私が試した際は WPA3 Personal で問題なく利用できました。
導入を検討される場合は、実際の環境で十分テストをしてください。
③今後の変化
先日の WWDC 2025 にて、PSSO が macOS の設定アシスタントに完全統合されることで、認証プロセスが大幅にスムーズになると紹介されています。具体的な変化点としては、自動デバイス登録（ Automated Device Enrollment : ADE）時に、ユーザが IDプロバイダ での認証をセットアップ中に実施できるようになり、ローカルアカウントを予め作成する必要がなくなります。
だいぶ便利になるので、インパクト大きいですね！
6. おわりに
PSSO と Okta Desktop MFA for MacOS を組み合わせることで、以下を実現することができました。
・キッティング時の IDプロバイダ認証（多要素認証）
・ローカルアカウントと IDプロバイダとのパスワード同期
・Mac ログイン時の多要素認証
今後、使いやすく変化していく見通しもあるため、端末へのアクセスセキュリティを強化する際の選択肢として、ご検討いただくとよいと思います。（特に Okta ユーザの会社様）
近い内にこの 記事の内容も古くなってしまうので、必要に応じてリライトするつもりです。。。なかなか筆が進まず、新 OS の公開直前になってしまいました。
最後まで読んでいただき、ありがとうございました。
以上、 エンジニアの中峯が担当いたしました。