Azure AD には、特定のグループにメンバーを追加するとMicrosoft365やPower Platformのライセンスを自動割り当てする、という機能がある。
Office365ライセンスを自動で割り当て（Formsに書くと、ライセンス割り当てる）でも使ってて、管理負荷を軽減できて、便利。
使えるグループ
セキュリティグループと、メールが可能なセキュリティグループで利用できる。ただし、入れ子になってる場合は利用できない。
ここではセキュリティグループしか書かれていないけど、メールが可能なセキュリティグループでも利用可。
メールが可能なセキュリティグループ(いつも思うけど、長い）だと、一斉の案内先にも使えるし、ユーザーに所有権を与えればメンバーを変更する権限も与えられるので、私はこちらを使うことが多い。
割り当てできるライセンスとアプリ
ライセンスに含まれるアプリをすべて、割り当てることもできる。
たとえば、EMS E3ライセンスに含まれるサービスプランすべて(AZURE AD P1,CLOUD APP SECURITY DISCOVERY,INTUNE,MFA,AZURE AD RIGHTS,AIP P1)を割り当てることもできるし、一部のサービスプランだけを適用することもできるので、必要に応じて組み合わせればいい。
直接付与と継承
ライセンスを直接付与することもできるし、グループベースのライセンス割り当てで付与することも可能。M365管理センターでは何が付与されているかしか確認できないが、Azure Portalからであれば直接なのか継承なのか、また継承の場合は何から継承されているかを確認できる。
Azure Portalでは、同じサービスプランを割り当てる、複数のグループに所属している場合も、その旨表示してくれる。
エラーの話の前の注意点
エラー例のほとんどは、GUIやPowerShellでライセンス割り当てを行っても同じ問題が発生します。グループベースのライセンス割り当ての問題ではないので、Microsoft365 管理センターで割り当てる際であっても注意が必要です。
ライセンス割り当てるときはサービスが使えなくなるわけではないのですが、割り当てを解除するときの運用は十分に設計しましょう。
エラー例:サービスプランが競合
ここからはエラー例。1つ目はサービスプランの競合。たとえば、SharePoint Plan1とPlan2のようなケースはどちらかしか割り当てできない。
M365管理センターでOffice365 E1ユーザーに、Office365E3を割り当てようとすると競合すると表示され、割当できない。
これと同じように、グループベースのライセンス割り当てでも同じことが起こる。エラーが出たら、競合しているサービスプランを削除し、競合がなくなっていれば大丈夫。
エラー例:グループから除外したらいくつかのアプリが消えた
グループから削除したら、SharePointが使えなくなっちゃったんですけど！というケース。ユーザーの申告を受けるか、グループから削除した後で目検するなどしないと気づきようがないんですよね。
たとえば、PROJECT ONLINE PROFESSIONAL にはプロジェクトのサービスプランだけでなく、SharePoint Plan2とOffice Onlineが付与されている。Office365 E1(=SPO Plan1)ユーザーに、このライセンスを付与するとSPO Plan2があるので競合してしまう。
まとめると、こんな感じ。
| Office365 E1だけ | SPO Plan1だけ | |
| Project Proを追加 | SPO Plan1とSPO Plan2で競合 | |
| 競合回避でPlan1を削除 | SPO Plan2だけ | |
| Project Proを削除 | SPO Plan2が消える | SharePointが使えない |
慌てずに必要なサービスプランを追加しましょう。
また、最初から追加となるサービスプランだけをグループベースのライセンス割り当てで設定しておくと回避できる可能性が高くなります。
エラー例:前提となるライセンスが必須
Exchange Online Archivingを割り当てるには、Exchange Plan1あるいは2が割り当て済みであることが必須。たとえばOffice 365 E1 等。
ケースは少ないけど、Phone Systemをわりあてるには、Teamsのサービスプランが割り当たっていることが必要。同じく、Office 365 E1 等。
これらは、前提となるライセンスが割り当たっていない場合は、Microsoft365管理センターのGUIで割り当てようとしても割り当てできない。前提となるライセンスが割り当たっていないユーザーもグループに入れるだけなら可能なので、グループベースのライセンス割り当てを作成しようとするとエラーになり、作成できない。
まとめ
エラーになるケースがあるとはいえ、得られるメリットとデメリットを比較して、メリットが大きいならやってみる価値はありますぜ、です。
追加になるようなライセンス（EMSやPBI、PowerPlatformとか）なら、競合が発生するケースは少ない。
メールが可能なセキュリティグループを使えば、ユーザー目線では一斉通知、アクセス権管理に利用でき、管理者目線ではライセンス割り当て作業の自動化も可能だし、それなりにメリットのほうが大きいんじゃないだろうか。
余談
入れ子になっているグループは、2020年5月10日現在では実装されていない。開発中とのことなので、早く実装されないかな・・・。
参考
Azure Active Directory でのグループ メンバーシップによるユーザーへのライセンスの割り当て
https://docs.microsoft.com/ja-jp/azure/active-directory/users-groups-roles/licensing-groups-assign
Azure Active Directory のライセンス管理にグループを使用する際のシナリオ、制限、および既知の問題
https://docs.microsoft.com/ja-jp/azure/active-directory/users-groups-roles/licensing-group-advanced#limitations-and-known-issues
ライセンスのための製品名とサービス プラン 識別子
https://docs.microsoft.com/ja-jp/azure/active-directory/users-groups-roles/licensing-service-plan-reference
Add support for nested groups in Azure AD (app access and provisioning, group-based licensing)
https://feedback.azure.com/forums/169401-azure-active-directory/suggestions/15718164-add-support-for-nested-groups-in-azure-ad-app-acc