見出し画像

管理対象Apple ID（Managed Apple ID）を導入する上での確認ポイント

くろひつじ

Apple Business Managerで管理するApple IDこと管理対象Apple IDを導入したのでいくつかまとめておこうと思います。
管理対象Apple IDに関する情報は本当に検索では見つけづらく、私が観測した範囲でも実際に導入して困る部分などをまとめている人を見つけられなかったので、試しに有料設定してみます。
最後まで無料で読めますが、よければ投げ銭感覚で応援をお願い致します。

なお、フェデレーション先はMacrosoft Entra ID（旧Azure AD）を利用しました。
Google Workspaceでのフェデレーションを検討している人はkazeさんの記事を参考にしてください。（こちらの記事も非常に有用です！）


はじめに

この記事はApple Business Manager（ABM）の設定でMacrosoft Entra ID（旧Azure AD）とのフェデレーションを有効にして、会社のメールアドレスを利用して作られた個人作成のApple IDを全て管理対象Apple IDに置き換えた際に検討したり実際に起こった内容をまとめた話です。

なぜEntra IDを選択したのか

ABMのフェデレーションは2種類あります。
・Google Workspace
・Entra ID

弊社でEntra IDを選択したのはGoogle Workspaceでは全てをカバーできなかったからですね。

海外の子会社とそれ以外とで扱っているテナントが異なるのですが、ABMに登録できるGoogle Workspaceは1つだけ。
また、OneLoginアカウントは払い出しているがGoogleアカウントは払い出していないユーザーもいたためGoogle Workspaceでは対応できませんでした。
逆にEntra IDは1つで全従業員を管理しているので、こちらの方が都合が良かったです。

すぐに管理対象Apple IDを導入しない、IdPとしてOktaを導入している企業であれば、もう少し待つとフェデレーションの選択肢にOIDCが追加されるはずなので、あえて「見」に回るのもありですね。

ちなみに弊社はIdPはOneLoginを使用しています。
Entra IDと連携した場合認証ってどうなるのかなと思ったんですが、しっかり連携していたOneLoginの認証が走りました。
なので、正直そこまでIDaaSと無理に連携させようとしなくていいかもです。網羅性が大事。

どのタイミングから戻れなくなるか

すいません、この辺り若干記憶が曖昧です。。。

Apple Business ManagerのFederated Authenticationですが、一度設定すると元に戻せません。
気軽に検証できない原因の9割はこれですね。

具体的にはApple Business Managerの管理コンソールから環境設定＞アカウントを選択し、Federated Authenticationの接続を行ったタイミングで戻れなくなる（最初にGoogle Workspaceに接続した後、うまく行かなかったからとEntra IDに変更が出来ない）とのことです。
加えてドメインの連携したタイミングで競合チェックが走ります。
競合チェックが走ると個人用Apple IDを新たに作成することができなくなります。

既に連携したドメインのメールアドレスでApple IDを作成しようとした場合
既に管理対象Apple IDが存在するメールアドレスにエイリアスをつけて
Apple IDを作成しようとした場合

現在会社のメールアドレスでApple ID作っていいよって言ってる企業は連携のタイミングでエンドユーザーに影響があるので注意してください。
連携後は個人のApple IDを作成していた人にアカウント移行のメールが移行完了まで週1回届く形になります。

こういうメールが届きます

サブドメインで管理対象Apple IDの管理ができるか？

会社ドメインのメールアドレスで既に個人Apple IDを作成されているので、影響がないようにサブドメインのメールアドレスで管理対象Apple IDを作成できるようにならないか、というのは誰しも考えることだと思います。

結論からいうと多少大変な部分はあるものの、出来なくはないと思います。

ポイントとしては以下ですね。

  • Google Workspaceの場合はApple IDにメールアドレスを利用するため、基本的にサブドメインの活用は現実的ではないです

  • Macrosoft Entra IDの場合はApple IDにuserPrincipalNameを利用するため、厳密にはメールアドレスとは別物ということでやってやれなくはないですが、既存の構成に山程影響があると思います

  • そもそも従業員が使いこなせるかどうかが微妙なので、競合による影響への対応のほうがトータルで楽です

  • サブドメインの作成や連携自体は問題ありませんので、検証用としてtest.example.comみたいなサブドメインを用意するのはかなりアリです

アカウント駆動型ユーザー登録に使用する場合は別途ホスティング用のwebサーバーをサブドメインで作成する必要があるのですが、AWSを利用していたらそこまで手間ではないですね。

完全移行までの期間について

移行までは60日の猶予があります。

移行期間の大まかな流れ

移行の間も地味に動きが変わってくるので注意です。

移行作業のスキップが途中で出来なくなる

30日を過ぎるとhttps://appleid.apple.com/ にサインイン時にスキップできた移行作業がスキップ出来なくなります。
Apple IDを移行しないと画面が先に進まないため、実質締め出しをくらう状態になります。

これと次のApple Developer Programアカウントの組み合わせが合わさるとかなり詰みます。

移行期間中の通知

管理者アカウントには毎日Federatedしたアカウント数が通知されます。

競合が解消されるとaddされ、退職などで情報が更新されるとupdateされる
管理コンソールのアクティビティでも確認可能です

当初未対応者（Federated出来ていない人）の一覧は手に入らないと言われていましたが、ログをダウンロードすると普通にエラーメッセージ付きで見えました。

移行最終日の前日には強制的に変更される一時的なApple IDを案内してくれます。

移行期間が過ぎるとApple側から強制的にApple IDを変更させられます。
変更後は <ユーザー名>-<ドメイン名>@temporary.appleid.com となります。
例えば kurohitsuji@exmple@com であれば、kurohitsuji-example.com@temporary.appleid.com という感じですね。

設定完了のメール

一時的なApple IDなので変更をしないといけないのですが、こちらはサインイン後通常のプロファイル画面から変更出来るようにになるので、移行作業時のように何も出来ない状態ではなくなります。
移行期間が終わってもメールアドレスを移行しないと何も出来ない状態でした。Appleさん問い合わせの回答と挙動が違うよぉー(´・ω・｀)

Apple Developer Programへの影響

アプリ開発している企業なら必ずた立ちはだかる壁ですね。
影響範囲としては以下2点が特に注意が必要です。

Account Holderの移行について

参加しているアカウントについては別途管理対象Apple IDを改めて参加させれば良いのですが、問題がAccount Holderです。

Account Holderのアカウントは通常の方法でアカウント移行が出来ません。
これはそもそもAccount Holderの役割が簡単に移せないことが起因しています。

なぜか私がお借りした検証用の環境では出来てしまったのですが、マジで開発に多大な影響を与えるので事前に根回しすることを強くオススメします。

対策としては、新規に個人Apple IDを作成してAccount Holderに参加させるのが一番安全かなと思います。
Apple Developer Enterprise Programの場合はDeveloperサポートに連絡するよう案内してください。（登録している本人しか対応できない）

TestFlightのテスターについて

管理対象Apple IDではTestFlightでテスターができないので注意です。

Developer側のサポートページにしか書いてないのは初見殺しなんよ

そのため開発者は管理対象Apple IDを業務で使うことはあまりないかもしれないですね。しらんけど。

会社のアカウントだけど会社のドメインじゃない場合

何を言っているか分からねーと思うが以下略

協業会社の方にアカウントを払い出すが、わざわざGoogleアカウントはいらない（IdPのアカウントがあればいい）、当人も会社のアカウントと切り替えたり別途覚えるのが手間、などで例外的にメールアドレスは払い出していないが管理対象Apple IDな必要な人がいます。

Entra IDの場合、userPrincipalNameが管理対象Apple IDになるため、userPrincipalNameのドメインをABMに登録・認証し、その管理対象Apple IDでログインしてもらう（実際の認証時はIdPのログイン画面が表示されるのでいつも通りログインするだけ）ようにしました。

これは、IdP側はメールアドレスでプロビジョニングを行っているがuserPrincipalNameはサブドメインで管理していた弊社の構成が噛み合った結果なので、自社の構成をしっかり理解した上で検討することをオススメします。

OktaなどIDaaSとの連携であればこの辺りは気にしなくて良さそうと思いきや、メールアドレスが自由気ままだとドメインの指定が地獄なのでどちらにせよ対応は必要そうです。

ディレクトリ同期機能について

基本的に有効にしておくとかなり便利だと思います。
もちろん使わないアカウントも大量に作成されるのですが、個人的に気に入ったのは削除機能があることです。

退職などでEntra IDがなくなった場合（厳密にはEntra IDのABMアプリに設定している対象グループから外れた場合）、次の同期処理で管理対象Apple IDは無効になります。
更に30日経過すると無効となっている管理対象Apple IDを削除してくれるため、棚卸しなどを行う必要がありません。

AppleCareは入っておきたい

導入しようとするとその他色々と疑問点が出てくると思います。
ただ、経験から言えばネットで検索したり通常のAppleのサポート窓口や並走してくれるベンダーに問い合わせても解決することは少なく、時間がかかる事が多い印象です。

AppleCareに入っておくと電話対応ですがABMに関する疑問はほぼ即答してくれますし、即答できない場合でもメールで後日（大体1〜2営業日）回答してくれるなどしっかり最後までフォローしてくれます。
今回の件で2,30回は問い合わせしていたので、あるとないとじゃ進捗に大きく影響します。
10万/年もしないのでサクッと入っておくのをオススメします。
管理対象Apple IDの導入が終わった後でも、macOSやiOSに関する問い合わせも受け付けているので、OSすぐアップデートしたいけどレアなバグ踏み抜きやすい人は引き続き入っておくのもアリですね。

その他

Jamf Proをお使いの方はおそらくPCやスマホの所有者をLDAPから引っ張ってきている人が多いかと思います。
そのユーザー情報と管理対象Apple IDとして作成したユーザー情報は統合されません。（メールアドレスの末尾にランダムな文字列がつく）
これは既知の問題としてJamfも認識しているとのことだったので、早めの対応を期待してます。

まぁ運用としてはスマートユーザーグループで「管理対象Apple IDのユーザー」でグループ作れるので、そこまで問題ではないですね。

公開後の反応

公開後の反応で有用なものを追加しておきます。

MDMプッシュ証明書への影響

弊社はグループメールながらABMの管理者アカウントだったので問題なかったのですが、これは確かに影響が大きい！

MDMプッシュ証明書は同じアカウントで発行・更新を行う必要があるため、アカウントが変わると証明書の作り直し＝既存の環境に影響が出まくりという流れですね。

Federated Authentication実は切れる説

これは検証できないのですが、Appleに問い合わせた時には切れないって言われたので、Apple内でも情報が更新されていない可能性がありますねー。

おわりに

かなり大変な作業ではあるものの、全社展開することで以下の恩恵が受けられます。

  • アカウント駆動型ユーザー登録で簡単にBYODを会社のMDMに登録できる

  • App Configを活用した機能（Slack for EMM、Box for EMMなど）を配布出来るようになる

  • パスワードの初期化など会社側で一括管理できるので従業員のリテラシーに左右されない

アカウント駆動型ユーザー登録で簡単にBYODを会社のMDMに登録できる

最近実装されたアカウント駆動型ユーザー登録、従来のプロファイル駆動型に比べてURLを入力させる必要がないため、エンドユーザーに優しいです。

また要件によりiOSのバージョンも自然と上がるため、個人のスマホでも古すぎるバージョンは登録出来ないようになります。

App Configを活用した機能（Slack for EMM、Box for EMMなど）を配布出来るようになる

こちら指摘いただいたので一旦上の項目では打ち消しましたが、詳細としては以下の通りです。

特にSlack for EMMなどエンタープライズの機能を使いたい場合はApp Configで設定を行う必要があります。
その関係でEMM関係の機能を利用する場合はMDMからアプリを配布＝デバイスを登録してもらう必要がある、という感じですね。

とはいえ、会社貸与の端末であればそもそも登録済みなのでこのあたりはクリアされるかと思います。

将来BYODも導入するかもしれない場合はこの辺りの仕込みが必須になってくると思うので、従業員が少ないうちにやっておくことで未来の自分を助けることになるでしょう。

パスワードの初期化など会社側で一括管理できるので従業員のリテラシーに左右されない

管理対象ということで当然ながらアカウントの管理は会社が行うことが出来ます。

そのため、パスワードの初期化は勿論サインインしているデバイスからの一斉サインアウトも可能です。
とはいえ、管理者やマネージャー権限を付与すると従来のパスワード＋SMSの方式に戻るため、管理者は引き続きパスワードの管理をしっかりしましょうー。

英語にアレルギーのない方であれば、ある程度は上で既に紹介済みですがJamfの中の人がまとめた内容が現時点で一番詳しいと思っているので是非。


ここから先は

0字

¥ 500

この記事が気に入ったらサポートをしてみませんか？