Microsoft Entra のユーザーとグループ

Azure を触りはじめた人がまず混乱するのが、「サブスクリプションを作ったのに、ユーザーはどこにいるのか」という点だ。答えは、ユーザーはサブスクリプションの中にはいない。

Azure には性格の違う 2 つの階層がある。ひとつは Microsoft Entra ID のテナントで、ここには人・グループ・アプリといった「誰か」が入る。もうひとつは管理グループ → サブスクリプション → リソースグループ → リソースという入れ子で、こちらには仮想マシンやストレージといった「物」が入り、課金もこちら側で起きる。

2 つの階層は信頼関係でつながっている。サブスクリプションは必ずどれか 1 つのテナントを信頼し、そのテナントにいる ID にだけ権限を渡せる。逆に 1 つのテナントは複数のサブスクリプションを束ねられる。だから「本番用」「検証用」とサブスクリプションを分けても、ユーザーは 1 か所で管理できる。

旧称が Azure Active Directory だったせいで、「オンプレミスの Active Directory（AD DS）をクラウドに持っていったもの」と誤解されやすい。実際には別物で、提供している機能が重なっていない。

AD DS は社内ネットワークの中で、PC をドメインに参加させ、グループポリシーで設定を配り、Kerberos や LDAP で認証する仕組みだった。Entra ID はインターネット越しに使う前提なので、認証は HTTP ベース（OAuth 2.0 / OpenID Connect / SAML）で、ドメイン参加もグループポリシーも持たない。

ユーザーを作る操作そのものは難しくない。試験で問われるのは「どこで作られた ID か」で、それによってどこで編集するかが変わるからだ。出自は 3 つしかない。

クラウド ID

Entra ID の中だけで生まれたユーザー。対応するオンプレミスのアカウントを持たない。作成も編集も削除もクラウド側（ポータル・CLI・PowerShell）で完結する。

ディレクトリ同期 ID（ハイブリッド ID）

オンプレミスの AD DS にいるユーザーを、Microsoft Entra Connect または Connect cloud sync でクラウドへ写したもの。写し元はあくまでオンプレ側にあるので、氏名や部署といった属性の編集は原則オンプレ側で行う。クラウド側で変えても、次の同期で上書きされるか、そもそも編集が拒否される。

ゲストユーザー（外部 ID / B2B）

他のテナントのアカウントや個人の Microsoft アカウントを招待して、自分の組織のリソースを使わせる仕組み。招待されたユーザーは自分のテナントのまま認証し、こちらのディレクトリには「ゲスト」として登録される。UPN に #EXT# が入るので一目で見分けられる。

# ユーザーを作る （PowerShell: New-AzADUser）
az ad user create --display-name "山田 太郎" \
  --user-principal-name [email protected] \
  --password <パスワード>
# 属性で絞って一覧する
az ad user list --filter "department eq '営業'"
# 削除する。削除後 30 日は復元できる
az ad user delete --id [email protected]

ユーザーのプロパティは数が多いが、AZ-104 で狙われるのは実質 2 つに絞られる。

使用場所（Usage location）

ライセンスを割り当てるために必要な属性。国によって提供できないサービスがあるため、Microsoft 側が配信可否を判断するのに使う。ここが空のままだとライセンス割り当てが失敗する。一括でライセンスを配ったのに一部のユーザーだけ失敗した、という場面の原因は大半がこれ。

管理単位（Administrative Unit）

ディレクトリの一部分だけを切り出して、そこに対する管理権限を限定するための入れ物。「大阪支社の管理者には、大阪支社のユーザーだけパスワードリセットさせたい」といった要件はこれで実現する。テナント全体の管理者ロールを渡さずに済む。

グループは 1 つの軸で覚えようとすると混乱する。独立した 2 つの軸がある。種類（何のためのグループか）と、メンバーシップ（メンバーがどう入るか）だ。この 2 つは自由に組み合わせられる。

もう一方の軸がメンバーシップだ。割り当て済みは管理者が手で出し入れする。動的は「department が営業」のようなルールを書いておき、属性が一致したユーザーやデバイスが自動で出入りする。人事異動のたびに手で直す必要がなくなるかわりに、ライセンスの条件が付く。

# グループを作る （PowerShell: New-AzADGroup）
az ad group create --display-name "営業部" \
  --mail-nickname eigyo
# メンバーを足す（割り当て済みの場合）
az ad group member add --group "営業部" \
  --member-id <オブジェクトID>

ライセンスはユーザー 1 人ずつにも付けられるが、実務でも試験でも主役はグループベースのライセンス割り当てだ。グループにライセンスを割り当てておくと、そのグループのメンバーになった時点で自動的にライセンスが付き、抜ければ外れる。

これを動的メンバーシップと組み合わせると、「営業部に配属されたら自動でグループに入り、自動でライセンスが付く」という流れになる。試験で「入社や異動のたびの手作業をなくしたい」と書かれていたら、この組み合わせが答えになる。

取引先や業務委託先にリソースを使わせたいとき、自分のテナントにアカウントを作るのではなく、相手のアカウントのまま招待する。これが B2B コラボレーション、画面上は「外部 ID」や「ゲストユーザーの招待」として現れる。

1. 招待を送る（メールアドレスを指定する。招待メールが届く）
2. 相手が承諾すると、自分のテナントにゲストとして登録される
3. ゲストをグループに入れたり、RBAC でロールを割り当てたりして権限を渡す

ゲストは既定ではディレクトリの情報をごく一部しか読めない。どこまで見せるかは「外部コラボレーション設定」で調整でき、「誰がゲストを招待できるか」もここで制限できる。

セルフサービスパスワードリセット（SSPR）は、ユーザーが管理者に頼まずに自分でパスワードを再設定できるようにする機能だ。ヘルプデスクの問い合わせで最も多いのがパスワードリセットなので、効果が大きい。

構成項目は多く見えるが、「誰に」「何個で」「どこへ返すか」の 3 つに整理できる。

最後のパスワードライトバックが、ハイブリッド環境での要になる。オンプレの AD DS と同期している環境で SSPR を使うと、既定ではクラウド側のパスワードだけが変わる。ライトバックを構成して初めて、新しいパスワードがオンプレの AD DS に書き戻され、社内 PC へのサインインにも反映される。