Entra ID 自動化 #2 ユーザーライフサイクル — 作成、無効化、ライフサイクルワークフロー

ツール Microsoft Graph Entra ID
読了 6分

JML の 3 つの流れの中で最も頻繁なのが、ユーザーアカウントそのもののライフサイクルです。今回はアカウントの誕生から整理までを Graph API で処理する方法と、この流れを製品機能として提供するライフサイクルワークフローを扱います。コードは REST の形で表記します。SDK への置き換えは Graph 実務入門 #3 で扱いました。

作成 — 属性が自動化の燃料です #

ユーザー作成は POST /users ひとつです。重要なのは呼び出し自体ではなく、何を埋めるかです。

ユーザー作成リクエスト 
POST https://graph.microsoft.com/v1.0/users
Content-Type: application/json

{
  "accountEnabled": true,
  "displayName": "佐藤 新",
  "userPrincipalName": "arata.sato@contoso.com",
  "mailNickname": "arata.sato",
  "employeeId": "E12345",
  "department": "Engineering",
  "jobTitle": "Backend Engineer",
  "employeeHireDate": "2026-09-15T00:00:00Z",
  "passwordProfile": {
    "password": "一時的な強力パスワード",
    "forceChangePasswordNextSignIn": true
  }
}

employeeId、department、employeeHireDate といった属性を「あとで埋めよう」と考えてはいけません。次回の動的グループは department の値でメンバーシップを計算し、後述のライフサイクルワークフローは employeeHireDate をトリガーに使います。属性が不正確なら、その上のすべての自動化が不正確になります。 属性の情報源(HR システム)と表記ルール(部署名の標準リスト)を決めることが、自動化設計の半分です。

初期資格情報の受け渡しには、一時パスワードより良い方法があります。一時アクセスパス(TAP, Temporary Access Pass)は時間制限付きの使い捨てコードで、新入社員がこれで初回ログインし、すぐにパスワードレス認証(Authenticator、パスキー)を登録する流れを作れます。パスワードをメールで送る慣行をなくせる経路です。

退職 — 削除ではなく遮断から #

退職処理の順序は、セキュリティの観点から決まっています。

  1. 即時遮断: accountEnabled を false にします(PATCH /users/{id})。ログインが止まります。
  2. セッション無効化: POST /users/{id}/revokeSignInSessions で発行済みのリフレッシュトークンを無効化します。無効化だけでは、すでにログイン済みのセッションがトークン失効まで生きていることがあります。
  3. アクセス回収: グループメンバーシップの削除、ライセンス回収、アプリ割り当ての解除。
  4. データ処理: メールボックスと OneDrive の保持・移管ポリシーの適用。
  5. 削除は最後に: DELETE /users/{id} はソフトデリートで、30 日間は復元可能な状態でごみ箱に入り、その後完全に削除されます。急いで消す理由はありません。遮断済みのアカウントを猶予期間の後に消すのが標準です。

この順序の覚え方は簡単です。退職処理の目標はアカウントを消すことではなく、アクセスを終わらせることです。 アクセスの終了(1〜3)は分単位で急ぎ、アカウントの整理(4〜5)はプロセスどおりゆっくりで構いません。

ライセンス — 個別割り当ては最後の手段です #

Graph にはユーザーに直接ライセンスを付ける assignLicense API がありますが、個人別の割り当てを自動化ループに入れた瞬間、「誰がどのライセンスをなぜ持っているのか」がコードの中に散らばります。基本戦略はグループベースライセンスです。ライセンスをグループに付けておけば、グループに入ったユーザーには自動で割り当てられ、出れば自動で回収されます。するとユーザー自動化の仕事は「正しいグループに入れること」に縮小し、ライセンスはグループ構造が管理します。詳しい構成は次回(グループ)で扱います。

ライフサイクルワークフロー — JML を製品機能として #

ここまでの流れを自前のスクリプトで書くこともできますが、Entra にはこれを製品化した機能があります。ライフサイクルワークフロー(Lifecycle Workflows)です。Entra ID Governance(または Entra Suite)ライセンスが必要です。

構造はシンプルです。トリガー(いつ)+ スコープ(誰に)+ タスク(何を)。

  • Joiner の例: employeeHireDate の 7 日前に → 営業部の新入社員に → グループ配置、上司へ TAP 送付、ウェルカムメール。
  • Leaver の例: employeeLeaveDateTime の当日に → 全従業員対象 → アカウント無効化、グループ・ライセンス削除、数日後にアカウント削除。
  • 非アクティブアカウントの整理: 一定期間ログインのないユーザーを自動で無効化・削除するトリガーもサポートされています。放置アカウントの監査を常設プロセスに変えてくれます。

組み込みタスクで足りない部分は、カスタム拡張で Logic Apps を呼び出して外部システム(社内ポータル、チケットシステム、Slack 通知)と連携できます。ワークフロー自体も Graph API(identityGovernance 名前空間)で作成・管理できるので、ワークフロー定義をコードとして持ちデプロイする構成が可能です。

自前実装との使い分けはこうです。標準的な JML の流れはワークフロー(ライセンスがあれば)のほうが運用負担が少なく、組織固有の複雑なロジックやライセンスの制約があるなら Graph の直接実装が答えです。両方を混ぜて、骨格はワークフローに任せ、特殊なステップだけカスタム拡張で足す構成が実務ではよくあります。

情報源との接続 — HR 主導プロビジョニング #

最後のピースは「誰がこの自動化を発火させるのか」です。理想の答えは人ではなく HR システムです。Entra の HR 主導プロビジョニングは Workday、SuccessFactors のような HR 製品と連携し、入社・異動・退職のイベントが HR に記録された瞬間に Entra ID のアカウントと属性が追従するようにします。HR 連携のない組織でも原則は同じです。人の情報の単一の情報源を決め、ディレクトリはその情報源に従わせること。 情報源がスプレッドシートなら、そのスプレッドシートを読むスクリプトがプロビジョニングエンジンになるわけで、出発点としてはそれでも十分です。

まとめ #

  • ユーザー作成の核心は属性の標準化です。department、employeeId、入社・退職日が動的グループとワークフローの入力値になります。
  • 初期資格情報は一時パスワードの代わりに一時アクセスパス(TAP)で渡す経路を検討します。
  • 退職処理は遮断(accountEnabled)→ セッション無効化 → アクセス回収 → データ処理 → 削除の順です。削除は 30 日のソフトデリートなので急ぐ理由がありません。
  • ライセンスはグループベースが基本戦略で、個別割り当て API は例外処理用です。
  • 標準的な JML はライフサイクルワークフロー(Governance ライセンス)で、固有ロジックは Graph の直接実装で。そして可能なら、トリガーは人ではなく HR システムであるべきです。
X