Microsoft Intune の「Set up local admin account creation and password management for macOS devices」は、macOS の自動デバイス登録（ADE）時にローカル管理者アカウントを作成し、そのパスワードを Intune の LAPS で管理するための公式ガイドです。結論から言うと、この設定は既存の登録済み Mac に後からそのまま適用するものではなく、Apple Business Manager または Apple School Manager から同期された Mac を、LAPS 対応の ADE 登録ポリシーで新規登録または再登録するための機能です。既存端末を対象にする場合は、初期化と再登録の計画が必要です。(Microsoft Learn)
なお、GitHub 上の公式ドキュメント履歴では 2026年7月1日に「Metadata updates」のコミットが確認できます。一方、Microsoft Learn のページ表示では最終更新日が 2026年4月15日となっており、7月1日の変更は機能追加というよりドキュメント管理上の更新として扱うのが安全です。この記事では、現時点の公式情報をもとに、Microsoft Intune 管理者が確認すべき影響範囲、設定変更、移行時の注意点を実務目線で整理します。(GitHub)
Microsoft Intune の macOS LAPS で何ができるのか
Microsoft Intune の macOS LAPS は、ADE で登録される macOS デバイスに対して、ローカル管理者アカウントを作成し、その管理者パスワードを Intune 側で暗号化して保管・ローテーションする仕組みです。Intune が生成する管理者パスワードは 15 文字で、大文字・小文字・数字・記号を含むランダムなパスワードとして作成されます。登録後は、LAPS 管理対象の管理者パスワードが既定で 6 か月ごとに自動ローテーションされます。(Microsoft Learn)
この機能の実務上の価値は、ユーザーを日常利用では標準ユーザーにしながら、IT 管理者だけが必要時にローカル管理者パスワードを取得できる点にあります。従来のように全端末で共通のローカル管理者パスワードを使ったり、ユーザーに管理者権限を持たせ続けたりする運用は、パスワード漏えい時の横展開リスクが高くなります。macOS LAPS を使うと、デバイスごとに異なる管理者パスワードを Intune で管理できるため、ゼロトラスト寄りの Mac 管理に近づけやすくなります。
今回の更新ポイントで管理者が最初に見るべきこと
今回の公式情報で重要なのは、「macOS LAPS が便利になった」という一般論ではなく、適用条件がかなり限定されている点です。とくに、登録済みの Mac にポリシーを割り当てれば自動的にローカル管理者アカウントが LAPS 管理になる、と誤解しないことが重要です。
| 確認項目 | 管理者が押さえるべきポイント |
|---|---|
| 対象デバイス | macOS 12 以降、Apple Business Manager または Apple School Manager から Intune に同期された Mac |
| 登録方式 | macOS ADE 登録プロファイルを使った自動デバイス登録 |
| 既存端末への適用 | 既存登録済み端末は、そのままでは対象にならない。LAPS 有効の ADE プロファイルで再登録が必要 |
| パスワード管理 | Intune が 15 文字のランダムな管理者パスワードを生成・暗号化保存 |
| ローテーション | 既定で 6 か月ごとに自動ローテーション。必要に応じて手動ローテーションも可能 |
| RBAC | パスワード表示・ローテーションには専用の Intune RBAC 権限が必要 |
| 注意点 | macOS 26.4 未満とパスコードプロファイルの組み合わせに既知の注意点あり |
特に見落としやすいのは、LAPS によるローカルアカウント構成が ADE の初回セットアップ中に実行される点です。公式情報では、ファクトリーリセット後に ADE 登録プロファイルで Intune に登録される必要があると説明されています。また、既存の macOS インストール上で profiles renew コマンドなどにより ADE を再開始するシナリオはサポート対象外です。(Microsoft Learn)
影響範囲：新規導入の Mac と既存 Mac で対応が変わる
macOS LAPS の影響範囲は、端末の状態によって大きく異なります。新規導入端末であれば、ADE 登録ポリシーに設定を追加しておくことで、初回セットアップ時に管理者アカウントと標準ユーザーアカウントの構成を進められます。一方、すでに Intune 管理下にある Mac は、既存状態のままではこのローカル管理者アカウント構成の対象になりません。(Microsoft Learn)
| 端末の状態 | macOS LAPS の適用可否 | 実務上の対応 |
|---|---|---|
| 新規購入し、ABM/ASM から Intune に同期された Mac | 適用しやすい | ADE 登録ポリシーを事前に作成・割り当てる |
| 初期化済みで ADE 登録前の Mac | 適用可能 | LAPS 有効の登録ポリシーを割り当ててからセットアップする |
| すでに Intune 登録済みの Mac | そのままでは不可 | 初期化・再登録を伴う移行計画が必要 |
| BYOD 的に手動登録された Mac | 想定外 | ADE 管理対象に寄せるか、別の管理方針を検討する |
| 共有端末・キオスク的な Mac | 条件付きで有効 | ユーザーなし ADE とアカウント命名ルールを設計する |
グローバル企業では、国・地域・拠点ごとに Mac の調達経路や登録方法が異なることがあります。Apple Business Manager に正しく紐づいていない端末、販売店経由で ADE 対応になっていない端末、すでにユーザーが使い始めている端末は、同じ Intune テナント内でも対応方針が分かれます。まずは「新規展開から適用する」「既存端末は更新・返却・再キッティングのタイミングで順次移行する」と分けて考えると、現場の混乱を避けやすくなります。
設定変更の流れ：ADE 登録ポリシーの Account settings が中心
macOS LAPS の設定は、Intune 管理センターの macOS ADE 登録ポリシー内で行います。公式の ADE 手順では、Devices から Enrollment に進み、macOS タブの Enrollment program tokens でトークンを選択し、Enrollment policies から macOS 用の登録ポリシーを作成します。Account settings でローカル管理者アカウントとローカルユーザーアカウントを構成する流れです。(Microsoft Learn)
実務では、次の順序で確認すると設定ミスを減らせます。
| 手順 | 作業内容 | 確認ポイント |
|---|---|---|
| 事前準備 | Apple Business Manager / Apple School Manager と Intune の同期を確認 | 対象 Mac が Intune 側に表示されているか |
| ADE ポリシー作成 | Enrollment policies から macOS 用ポリシーを作成 | 古い Profiles ではなく新しい Enrollment policies を使う |
| Account settings 設定 | ローカル管理者アカウントとローカルユーザーアカウントを構成 | どちらを作成するか、命名規則を決める |
| RBAC 設定 | パスワード表示・ローテーション用のカスタムロールを作成 | 権限をヘルプデスク全員に広げすぎない |
| 割り当て | 登録ポリシーを対象デバイスへ割り当て | 端末がアクティブになる前に割り当てる |
| 検証 | 登録後に Passwords and keys で確認 | パスワード取得・手動ローテーション・監査ログを確認 |
ADE 登録ポリシーは、デバイスが実際にセットアップされる前に割り当てておく必要があります。公式手順でも、同期されたデバイスに登録ポリシーが割り当てられていない状態で電源を入れてセットアップを始めると、登録が失敗する可能性があるため、早めに既定の登録ポリシーを設定することが推奨されています。(Microsoft Learn)
ローカル管理者アカウントの設計で失敗しやすいポイント
ローカル管理者アカウント名は、単に Admin のままにすることもできます。しかし、グローバル運用や共有端末運用では、端末識別と監査のしやすさを考えて命名規則を決めるべきです。公式情報では、ユーザーなし ADE 登録ポリシーの場合、{{serialNumber}}-admin や {{serialNumber}}-user のようにシリアル番号を含める例が示されています。これにより、ユーザーに紐づかない端末でもアカウント名の重複や識別不能を避けやすくなります。(Microsoft Learn)
利用できる主な変数には、{{serialNumber}}、{{partialupn}}、{{managedDeviceName}}、{{onPremisesSamAccountName}} などがあります。ユーザー紐づきの Mac では {{partialupn}} を使うと利用者名に近い形式になりますが、共有端末やキッティング端末では利用者が変わる可能性があります。そのため、端末固定の管理者アカウントにはシリアル番号ベースの命名を使い、ユーザー用アカウントには UPN 系の変数を使う、といった切り分けが現実的です。
管理者アカウント名の判断基準
| 運用パターン | 推奨例 | 理由 |
|---|---|---|
| 1人1台の業務用 Mac | mac-admin または標準化した管理者名 | ヘルプデスクが案内しやすい |
| 共有端末・ユーザーなし ADE | {{serialNumber}}-admin | 端末単位で一意にしやすい |
| 拠点ごとに管理する Mac | jp-{{serialNumber}}-admin など | 地域・拠点別の識別に使いやすい |
| 監査を重視する環境 | 個人名を避けた端末ベース名 | 退職・異動時のアカウント名問題を避けやすい |
ローカル管理者アカウントを Users & Groups やサインイン画面で非表示にする設定も用意されています。一般ユーザーに管理者アカウントの存在を意識させたくない場合は有効ですが、現地サポートや貸出端末の復旧手順でアカウント名を入力する運用がある場合、非表示にしたことでヘルプデスク対応が複雑になることがあります。セキュリティだけでなく、障害時の復旧手順まで含めて判断するのが実務的です。
パスワードポリシーとの組み合わせに注意する
macOS LAPS を設定した端末では、パスワードポリシーの割り当て方が重要です。公式情報では、LAPS アカウントが構成されたデバイスに対しては、パスワードポリシーを Settings catalog 経由でターゲットし、Change at next authentication を無効にするよう案内されています。Compliance policies や device restriction templates で構成されたパスワード設定は Change at next authentication を既定で有効にするため、新しく作成された LAPS アカウントでサインイン問題を起こす可能性があります。(Microsoft Learn)
この点は、既存の macOS セキュリティポリシーを流用する組織ほど注意が必要です。Windows や iOS と同じ感覚で「既存の準拠ポリシーを Mac にも割り当てる」と、ADE 中に作成された管理者アカウントとパスワードポリシーの挙動が噛み合わず、現場で「Intune に表示されるパスワードでは入れない」「初回利用時にパスワード変更を求められる」といったトラブルにつながります。
パスワード関連で確認すべき設定
| 確認項目 | 推奨対応 |
|---|---|
| LAPS 対象 Mac へのパスワードポリシー | Settings catalog を優先する |
| Change at next authentication | 無効化する |
| Compliance policy のパスワード設定 | LAPS 対象端末に不用意に重ねない |
| Device restriction template | 既存テンプレートの流用前に影響を確認する |
| 登録直後の検証 | 実機で管理者パスワード取得とサインインを確認する |
RBAC：パスワードを見られる人を最小限にする
macOS LAPS では、Intune 管理センターからデバイスのローカル管理者パスワードを確認したり、手動でローテーションしたりできます。ただし、これらの操作には専用の Intune RBAC 権限が必要です。公式情報では、Enrollment programs カテゴリの「View macOS admin password」と「Rotate macOS admin password」を Yes にする必要があると説明されています。さらに、この 2 つの権限は Intune の組み込みロールや Microsoft Entra の Intune Administrator 組み込みロールには含まれないため、カスタム Intune ロールで割り当てる必要があります。(Microsoft Learn)
ここはセキュリティ設計上の要点です。Intune 管理者であれば誰でも Mac のローカル管理者パスワードを見られる、という設計にすると、LAPS を導入しても権限集中のリスクが残ります。実務では、次のように役割を分けると管理しやすくなります。
| 役割 | 権限設計の例 |
|---|---|
| 端末設計者 | ADE ポリシーの作成・変更権限 |
| ヘルプデスク一次対応 | 原則としてパスワード表示権限なし。必要時は申請制 |
| ヘルプデスク二次対応 | View macOS admin password を限定付与 |
| セキュリティ管理者 | Rotate macOS admin password と監査ログ確認 |
| 監査担当 | Audit logs の参照を中心に設計 |
パスワードの表示とローテーションは、Intune の監査イベントとして記録されます。公式情報では、管理者パスワードの表示は Get AdminAccountDto、ローテーションは rotateLocalAdminPassword ManagedDevice として監査ログで確認できるとされています。運用開始前に、Tenant administration > Audit logs で実際にイベントが記録されることを確認しておきましょう。(Microsoft Learn)
既知の注意点：macOS 26.4 未満とパスコードプロファイル
公式情報では、macOS 26.4 より前のバージョンを実行するデバイスに既知の問題があると説明されています。ADE 登録時にローカル管理者アカウントを構成し、さらにパスコードプロファイルをターゲットしている場合、Change at next auth が無効でも、また Max Age が設定されていても、管理者パスワードのリセットを求められることがあります。この問題は標準アカウントには影響しないとされています。回避策として、端末上でリセット後に管理者パスワードを手動ローテーションし、Intune とデバイス側のパスワード状態を同期させること、根本対応として macOS 26.4 へのアップグレードが案内されています。(Microsoft Learn)
この注意点は、パイロット展開で必ず確認すべきです。特に、Mac の OS バージョンが拠点や購入時期によってばらついている組織では、「LAPS 設定が悪い」のではなく「OS バージョンとパスコードプロファイルの組み合わせ」が原因で初期設定中に問題化する可能性があります。展開前に対象 Mac の OS バージョンを棚卸しし、macOS 26.4 未満が残っている場合は、LAPS 展開と OS 更新計画をセットで考えるべきです。
Secure Token の制約も理解しておく
もう一つ重要なのが、macOS の Secure Token に関する制約です。公式情報では、プラットフォーム上の制限により、ローカル管理者アカウントは Secure Token を受け取らないとされています。登録後に最初にサインインしたアカウントが Secure Token を受け取り、現時点ではそれはローカルユーザーアカウントになると説明されています。(Microsoft Learn)
これは、FileVault や一部の管理操作を考えるうえで重要です。ローカル管理者アカウントを作成できるからといって、そのアカウントが macOS 上のすべての復旧・暗号化関連操作で期待通りに使えるとは限りません。FileVault、Platform SSO、ローカルユーザー作成、標準ユーザー化を組み合わせる場合は、実機で「誰が最初にサインインするか」「FileVault 有効化後に復旧キーが回収されるか」「管理者アカウントでどの操作ができるか」を確認してから本番展開する必要があります。
移行期限はあるのか
この macOS LAPS 設定そのものについて、公式ドキュメント上で「いつまでに移行しなければならない」という明確な移行期限は確認できません。ただし、macOS ADE の登録ポリシー作成体験については、古い Enrollment program tokens > Profiles の体験は将来的に廃止される予定であり、新機能は古い体験には追加されないと案内されています。新規設計や見直しを行う場合は、Enrollment policies 側でポリシーを作成する前提に寄せるべきです。(Microsoft Learn)
移行計画としては、全既存 Mac を一斉に初期化するよりも、次のような段階展開が現実的です。
| フェーズ | 対応内容 |
|---|---|
| パイロット | IT 部門や一部ユーザーの新規 Mac で ADE + LAPS を検証 |
| 新規展開 | これから配布する Mac は LAPS 有効の ADE ポリシーを標準にする |
| 既存端末 | 端末交換、再キッティング、故障交換、返却時に順次再登録 |
| 例外管理 | 初期化できない Mac は別のローカル管理者パスワード管理手順を維持 |
| 監査 | パスワード表示・ローテーション履歴を定期確認 |
Intune のサービス更新は、Microsoft 内部で検証された後に一部データセンターから段階的に展開され、世界中に広がるまで数日から 1 週間、機能によっては数週間かかる場合があります。グローバルテナントでは、地域やテナントによって UI 表示や利用可能タイミングに差が出る可能性もあるため、本番展開前に対象テナントで実際の画面を確認することが大切です。(Microsoft Learn)
管理者がすぐ確認すべきチェックリスト
Microsoft Intune で macOS LAPS を導入する前に、次の項目を確認してください。チェックの目的は、設定漏れを防ぐことだけではありません。初期化が必要な既存端末を誤って「ポリシー割り当てだけで対応済み」と判断しないためでもあります。
| チェック項目 | 確認内容 |
|---|---|
| ABM/ASM 連携 | 対象 Mac が Apple Business Manager または Apple School Manager から Intune に同期されている |
| OS バージョン | macOS 12 以降である。パスコードプロファイルを使う場合は macOS 26.4 未満の既知問題も確認する |
| 登録方式 | ADE 登録ポリシーを使う。手動登録や既存登録のままでは対象外 |
| ポリシー作成場所 | 古い Profiles ではなく Enrollment policies を使う |
| Account settings | ローカル管理者アカウントとローカルユーザーアカウントの作成方針を決める |
| 命名規則 | ユーザーあり・ユーザーなしでアカウント名のルールを分ける |
| パスワードポリシー | Settings catalog を使い、Change at next authentication を無効化する |
| RBAC | View / Rotate macOS admin password をカスタムロールで最小権限付与する |
| 監査ログ | パスワード表示・ローテーションの監査イベントを確認できる |
| 既存端末移行 | 初期化・再登録が必要な端末数とタイミングを把握する |
実務でおすすめの導入パターン
最初から全社展開するより、まずは新規配布 Mac に限定して始めるのがおすすめです。ADE は初回セットアップ体験に強く関わるため、ポリシーの組み合わせや Company Portal、Platform SSO、FileVault、パスワードポリシー、アプリ配布の量によって、ユーザーがセットアップ完了まで待つ時間が変わります。公式 ADE 手順でも、Await final configuration は Setup Assistant の最後で重要なポリシーをインストールするためにユーザー体験をロックする設定であり、割り当てるポリシーやアプリが多いほど待機時間が長くなると説明されています。(Microsoft Learn)
最小構成のパイロットでは、次のように段階を分けると原因切り分けがしやすくなります。
| 検証段階 | 検証内容 |
|---|---|
| 第1段階 | ADE 登録だけを確認し、端末が Intune に正しく登録されるかを見る |
| 第2段階 | ローカル管理者アカウント作成と LAPS パスワード取得を確認する |
| 第3段階 | 標準ユーザーアカウント作成、命名規則、編集制限を確認する |
| 第4段階 | パスワードポリシー、FileVault、Platform SSO との組み合わせを確認する |
| 第5段階 | ヘルプデスク手順、監査ログ、手動ローテーションを確認する |
この順番にすると、サインイン問題が起きた場合に、ADE 設定、LAPS 設定、パスワードポリシー、アプリ配布、認証方式のどこに原因があるかを切り分けやすくなります。
まとめ：macOS LAPS は「新規 ADE 標準化」とセットで考える
Microsoft Intune の macOS LAPS は、Mac のローカル管理者パスワードをデバイスごとにランダム化し、Intune で安全に管理するための有力な機能です。ただし、効果を発揮するのは ADE による新規登録または初期化後の再登録時です。既存の Intune 登録済み Mac に対して、ポリシー割り当てだけで自動的に LAPS 管理が始まるわけではありません。
管理者が次に行うべきことは、まず対象 Mac を「新規展開」「再登録可能な既存端末」「当面例外運用する端末」に分類することです。そのうえで、Enrollment policies を使った ADE 登録ポリシー、Account settings、RBAC、パスワードポリシー、監査ログ確認を小規模に検証し、問題がなければ新規配布 Mac の標準構成に組み込むのが現実的です。
コメント