Jamf Connectと内製IdP連携の全記録 - 2,100台のMacをOktaから移行して得た教訓

はじめに

DeNA IT本部 IT戦略部 エンプロイーエクスペリエンスグループの佐藤元気です。

従業員が Mac をより安全かつシームレスに利用できるよう、日々、端末管理の最適化に取り組んでいます。

今回は、Jamf Connect の認証基盤を従来の Okta から 内製 IdP へ移行したプロジェクトで設定方法や展開方法を紹介します。

ネット上に情報が少ないなかでの設定の試行錯誤や、展開手法における「思わぬ落とし穴」との戦いもありました。

同じように Jamf Connect のカスタム IdP 連携に挑む情シス担当者のみなさまの参考になれば幸いです。

Jamf Connect とは？

Jamf Connect は、Mac のローカルアカウントと Okta や Google Cloud Identity、あるいは今回のような「内製 IdP 」といったクラウド認証基盤（IdP）を安全に連携・同期させるためのソリューションです。

通常、Mac へのサインインは端末内のローカルパスワードで行われますが、Jamf Connect を導入することで、従業員は常に最新の「社内共通アカウント」を使用して Mac へログインできるようになります。

ゼロタッチキッティングにおける役割

「箱から出してすぐに業務を開始できる」ゼロタッチキッティングにおいて、Jamf Connect はセットアップの起点となる重要な役割を担います。

初期設定の自動化: Mac をネットワークに接続した直後、IdP のログイン画面を表示させ、初回サインインと同時にローカルアカウントを自動生成します。

アカウント権限の柔軟な制御: ローカルアカウントの生成時に、「標準ユーザー」として作成するか「管理者」として作成するかを、Jamf Connect 側の設定で容易に調整することが可能です。

権限の動的割り当て: IdP 側のユーザー属性（所属グループなど）に基づき、その場で権限を判断してアカウントを作成できるため、IT 部門が端末に一切触れることなく、ユーザーに合わせた最適な状態で配布が可能になります。

具体的な利用シーン

パスワード同期によるストレス軽減

社内システムのパスワードを更新した際、Jamf Connect のメニューバーアプリが変更を検知し、Mac 本体のログインパスワードも自動的に同期します。これにより「Mac のパスワードだけ古いまま」といった混乱を防ぎます。

ブランディングされたログイン体験

ログイン画面に自社のロゴやカスタムメッセージを表示させることができ、シームレスな業務開始をサポートします

セルフサービスによる利便性向上

Jamf Connect のメニューバーから IdP への接続状況をリアルタイムで確認でき、パスワードリセットなどもユーザー自身でスムーズに行えるようになります。

参考資料：

Jamf Connect - セキュアなMac認証

なぜ内製IdPへ移行したのか

DeNA では現在、全社的なセキュリティ強化と利便性向上を目的に、認証基盤を Okta から 内製 IdP へ集約するプロジェクトを推進しています。

この大規模な移行プロジェクトの全体像については、先行して公開されたテックブログ「

Oktaから内製IdPへの認証基盤移行（第1回）

」「

Oktaから内製IdPへの認証基盤移行（第2回）

」で詳しく紹介されています。

私たちもこの戦略に歩調を合わせ、Jamf Connect の認証基盤を 内製 IdP に切り替えるプロジェクトを開始しました。

DeNAのMac利用環境

今回の移行対象は、大きく分けて以下の2パターンです。

既存端末： すでに従業員に貸与されているすべてのMac（約2,100台）

新規端末： 在庫から新たにキッティングを行う端末

これほどの台数の環境で、業務を止めることなく認証基盤を切り替えるには、非常に緻密な戦略と検証が必要でした。

内製 IdP を連携するための要件

Jamf Connectを内製IdPと連携させるためには、以下の要件を満たす必要があります。

認証プロトコルとして OIDC（OpenID Connect）に対応している

Discovery URLのエンドポイント公開

IdP側の構成情報（エンドポイントや対応スコープなど）を外部から参照できる「/.well-known/openid-configuration」が正しく提供されていること

適切なGrant Type（認可タイプ）のサポート

通常のブラウザベースの認証に加え、メニューバーアプリでのパスワード同期等を実現するために「ROPC（Resource Owner Password Credentials）」が利用可能であること

リダイレクトURIの整合性

認証完了後にIdPからローカルホスト（https://127.0.0.1/jamfconnect）へ正しくトークンを戻せるよう、IdP側でリダイレクトURIが許可されていること

IDトークンへの必須クレームの包含

Macのローカルアカウント作成や照合に必要なユーザー情報（sub や email 、あるいはカスタムで指定する一意識別子）がIDトークンに含まれていること

参考資料：

Jamf Learning Hub

Okta などの大手 SaaS は Jamf 側で「型」が決まっており、多くの設定が自動化されていますが、内製 IdP の場合はいわば「フルオーダーメイド」の連携になります。

IdP 側が発行する URL や認可の仕組みを一つひとつ正確にはめ込んでいく必要がありますが、この「当たり前だと思っていた設定」を自分たちで紐解く作業が、後のプロジェクト展開で大きな意味を持つことになりました。（詳しくは、この後出てくる苦労話に記載します。）

Jamf Connectの設定方法

内製 IdP 連携を実現するために、

専用ツールでの設定値の書き出し

Jamf Pro を用いた構成プロファイルの作成

という 2 段階の作業を行いました。

1. Jamf Connect Configuration アプリでの設定作成

まず、管理者用の専用ツール「Jamf Connect Configuration」を使用して、設定ファイル（.plist）を作成します。

IdP情報の入力：「Identity Provider」セクションで、前述のDiscovery URLやクライアントIDなどを入力します。

※ 本画像は Jamf Connect Configuration app より抜粋した構成サンプルです。

機能のカスタマイズ： ログイン画面のロゴ（ブランディング）や、パスワード同期の挙動、ローカルアカウント作成時の権限（管理者/標準ユーザー）などをGUI上で定義します。

※ 本画像は Jamf Connect Configuration app より抜粋した構成サンプルです。

検証： アプリ内の「Test」機能を使って、設定した内容で実際にIdPと通信し、トークンが取得できるかをその場で確認をします。

※ 本画像は Jamf Connect Configuration app より抜粋した構成サンプルです。

書き出し： 問題がなければ、構成プロファイル（.mobileconfig）またはplist形式で保存します。

1. Jamf Pro を使用した構成プロファイルを作成

つづいて、作成した設定値をもとに Jamf Pro で構成プロファイルを作成します。

プロファイルの作成： Jamf Proの管理画面から「コンピューター」＞「構成プロファイル」を選択し、新規作成します。

ペイロードの設定：「アプリケーションとカスタム設定」ペイロード（旧：カスタム設定）を使用します。

外部ドメインの指定： ドメイン名に com.jamf.connect（メニューバー用）や com.jamf.connect.login（ログイン画面用）を指定し、先ほどツールで作成したplistの内容をアップロードします。

あとは、構成プロファイルのScopeを割り当てて、挙動の検証を実施したり、機能の微調整を繰り返しました。

全社展開のプロセス

約2,100台という大規模な環境において、業務への影響を最小限に抑えつつ、確実に認証基盤を 内製 IdP へ切り替えるため、まずはリスクの少ない新規・在庫端末から段階的に展開を開始し、その後既存端末へ拡大する2パターンの展開方法を採用しました。

1. 新規キッティング端末への適用

新しく貸与される端末については、最初から 内製 IdP を認証先とする状態で配布しました。

新規PreStage Enrollmentを作成

Apple Business Manager（ABM）に登録された端末は、シリアル番号単位で紐づける管理サーバー（Jamf Pro）を指定できます。

Jamf Pro 側では、それらの端末が最初に起動した際の挙動を「PreStage Enrollment」という設定で制御します。

今回、ABM と連携する PreStage Enrollment を既存の設定変更ではなく「新しく」作成することを選んだ理由は、以下の通りです。

検証環境の確保

既存端末の移行作業で発生し得る問題の切り出しや検証を、安全かつ独立した環境で行うためです。

構成の簡素化

既存の設定はスコープや構成プロファイルなどが複雑に入り組んでいました 。新しい IdP への移行を機に、構成を改めてクリーンに整理したいと考えました。

トラブルシューティングの迅速化

登録状況を明確に分けることで、万が一トラブルが発生した際に「どの経路で設定が適用されたか」の切り分けを容易にするためです。

スモールスタートによる早期の問題発見

管理下にある在庫 PC を先行して「内製 IdP 仕様」に切り替えて展開することで、実際のキッティングフローに潜む細かな挙動の不具合や設定漏れを、従業員への配布前にいち早く発見・修正することが可能になりました。

1. 既存PC（Okta利用中）の切り替え展開

既存端末の切り替えには、複数の Jamf Pro ポリシー をリカーリングチェックインのタイミングで数珠つなぎに実行する仕組みを構築しました。

各ポリシーの処理完了時に /var/tmp 配下へtxtファイルを作成し、それを拡張属性で検知、スマートコンピュータグループで検知して次のポリシーを実行する、という方式です。

【構築したポリシーの連鎖フロー】

参考資料：

ログインウィンドウ無効化ポリシーを作成した時に利用した資料

Disabling_Jamf_Connect_on_Locked_Computers

ログインウィンドウ初期化ポリシーを作成した時に利用した資料

Change_Identity_Providers_in_Menu_Bar_App

ログインウィンドウ再有効化ポリシーを作成した時に利用した資料

Re-configuring_the_Jamf_Connect_login_window_with_a_new_identity_provider

認証トラブルによりログインできなくなるリスクも想定していたため、ローカルログインが可能な状態を維持する点も考慮しました。

展開完了までの苦労話

緻密に計画した移行プロジェクトでしたが、一筋縄ではいきませんでした。実際には複数の技術的な壁に直面しました。

1.「Oktaなら当たり前」が通じない、ROPC設定の盲点

「Jamf Connectに内製IdPを連携するための要件」のセクションでも触れた通り、大手SaaSでは自動構成されていた「当たり前の設定」を自分たちで紐解く作業が、思わぬ壁となって立ちはだかりました。

Macへのログイン自体は成功しているのに、Jamf Connect のメニューバーから「接続」を押すと 403 エラー が表示される事象に遭遇しました。

原因を調査したところ、Okta 連携では自動構成されていたROPC エンドポイント（OIDCROPCServer）の設定が、内製 IdP では明示的な指定を必要としていたことが判明しました。

1. 展開フェーズでの最大の失敗：/var/tmpディレクトリの罠

約 2,100 台という大規模な展開を安全に進めるため、複数のポリシーを /var/tmp に置かれたtxtファイルをフラグにして数珠つなぎに実行するフローを構築しましたが、/var/tmp は、一定期間アクセスがない場合にシステムが自動でクリーンアップする場所 でした。

フラグとしていたtxtファイルが消失し、構成プロファイルが意図せず旧来の Okta 設定に切り戻ってしまう という事象が発生しました。

本件への対応として、展開プロセスの根本的なロジック改修（スクリプトの書き換えや再配布）は実施しませんでした。

すでに大規模な展開が進行しており、仕組みそのものを修正してやり直すことが難しいためです。

以下の回避策を講じることで、展開作業を中断させることなく完遂させました。

インベントリによる特定とグループ作成： すでに内製 IdP に切り替わった端末をインベントリ情報から即座に洗い出し、それらの「スタティックコンピューターグループ」を作成。

プロファイルの固定： 作成したグループに対して直接内製 IdP の構成プロファイルを割り当てることで、フラグファイルの消失に関わらず、旧来の Okta 設定に切り戻らないよう制御を固めました。

1. ポリシーが走らない端末などの切り替え追い込み

サブ端末として利用されている Mac、ポリシーのタイムアウトエラーが発生した端末、ログアウト・ログインを実施していないユーザーの端末など、約 500 台については、状態に応じて個別に連絡し、一台ずつ切り替えの追い込み対応を行いました。

とくに課題となったのが、 内製 IdP への切り替えを完了させるために必要な「ログアウト → ログイン」というユーザーアクションが行われないケースが多く、以下の手法で対応をしました。

macOS の自動化スクリプト言語（AppleScript をコマンドラインから実行するツール）を利用した通知の自動化: ログアウト・ログインが完了していないユーザーを拡張属性で正確に検知していたので、それをフラグに、画面上に「ログアウトを促すポップアップ」を直接表示させるポリシーを配信しました。

これにより、メールやチャットでの一斉連絡だけでは届かなかった層へのアプローチが可能になり、1台ずつ着実に切り替えの追い込みをかけることができました。

まとめ

今回のプロジェクトを通じて、約2,100台のMacをOktaから 内製 IdP へ移行したプロセスは、単なる設定変更の枠を超え、認証プロトコルやOSの仕様を深く掘り下げる貴重な学びの連続でした。

本記事で共有した展開手法や失敗の教訓が、情シス担当者の皆さまにとって、スムーズな移行への確かな道標となれば幸いです。