Azure ADのグループを使用してDynamics 356 Business Centralのアクセス権限を制御できるようになりました。この機能は2023 Release Wave1で追加された新機能です。
公式ドキュメント
セキュリティ グループを使用してユーザー アクセス許可を管理する | Microsoft Learn
目次
1. 事前設定
事前準備としてAuzre ADのグループを作成します。Azure ADのグループにはいくつかの種類がありますが、公式のリリース文書と同様にセキュリティグループを作成します。
作成したセキュリティグループのメンバーにテスト用のユーザーを割り当てます。
テスト用のユーザーには予めBCのライセンスを割り当てておきます。
Feature Managementの一覧画面で”Featrute: Convert user group permissions”をAll Usersに設定します。Version22以降の環境を新規作成した場合は既定でEnabledになっているはずです。
ロールを”Administration of users, security groups and permissions”に切り替えておきます。ユーザーや権限管理のメニューがロールセンターに表示されるのでとても便利です。
ユーザーカード画面を確認すると、ユーザーグループタブが存在しません。従来のユーザーグループの代わりにAzure ADのグループを使用してアクセス権限を制御するためです。
従来通りBCのユーザーグループを使用してアクセス権限を制御したい場合はFeature Managementの一覧画面で” Featrute: Convert user group permissions”をNoneに設定します。
するとユーザーカード画面に”User Group”タブが復活します。
検証を続けるので、 Feature Management の設定をEnabledに戻します。
テスト用のユーザーをM365から取得します。（これは既存機能です。）
テストユーザーがBC上に生成されました。既定の設定ではいろいろと権限セットが付与されています。
この後、アクセス可否の検証を行うので、テストユーザーに割り当たっている権限セットはすべて削除します。
この状態でテストユーザーBCにサインインを試みるとエラーになります。（以後、赤いツールバーのブラウザはテストユーザーのものです。）
ここまでで準備完了です。
2. 新機能による権限割り当て
では、実際に新規機能を使用して権限を割り当ててみましょう。ロールセンターから”Security Groups”を実行します。
Security Groupsの一覧画面です。まだ何も登録されていません。”+New”ボタンをクリックします。
Azure ADのセキュリティーグループを指定する画面が表示されます。”…”をクリックします。
するとAzure ADのセキュリティーグループが一覧表示されました。正確に言うとセキュリティグループ以外のグループ（Micrososoft365グループなど）も表示されており、選択可能です。（後ほど触れます。）ここでは準備段階で登録したセキュリティグループを選択します。
選択したAzure ADのセキュリティーグループにBCのセキュリティーグループの名前を付けます。既定ではAzure ADのセキュリティーグループの名前と同じです。厳密には先頭の20文字までを大文字にしたものがBCのセキュリティグループの名前になります。
セキュリティグループの一覧画面で、いま作成したセキュリティグループを確認します。右側の情報ボックスにはメンバーとしてテストユーザーが割り当たっています。権限セットはまだ何も割り当たっていません。
セキュリティグループに権限セットを割り当てます。
試しに”Super”権限セットを割り当てます。
セキュリティグループの一覧画面に戻ると、Super権限が割り当たっていることが確認できます。
この状態でテストユーザーがサインインを試みるとサインインできます。Azure ADのセキュリティーグループを使用したアクセス権限付与に成功しました！
3. セキュリティグループ以外のAzure ADグループ
先ほど少し触れましたが、Azure ADにはセキュリティグループ以外にもいくつかのタイプのグループが存在します。具体的には”配布リスト”グループ, “メールが有効なセキュリティ”グループ, “Microsoft 365″グループです。これらのグループを使用してアクセス権限制御できるか調べてみます。
BCのセキュリティーグループ一覧画面で新規作成すると、 “配布リスト”グループ, “メールが有効なセキュリティ”グループ, “Microsoft 365″グループ も選択可能です。
それぞれのタイプのAzure ADグループについてBCのセキュリティグループを作成します。最初にAzure ADの”セキュリティー”グループから作成したBCのセキュリティグループについてはPermissionSetを外しておきます。（これが残っていると権限制御の確認ができないので。）
試しに配布リストから作成したBCのセキュリティグループに権限を割り当てます。（事前にこの配布リストにはAzure AD側でテストユーザーをメンバーとして追加しておきます。）
すると、テストユーザーはサインインできました。
実際に試すとわかりますが、”メールが有効なセキュリティ”グループや”Microsoft 365″グループについても同様にアクセス権限を付与することができます。
ちょっと紛らわしいですね。BCのセキュリティグループは”ユーザーグループ”（または”AADベースのユーザーグループ”）とかに名前を変えたほうが良い気がします。
4. 便利機能
便利機能を2つ紹介します。１つ目は権限セットとセキュリティーグループの割り当てをマトリクスで表現する機能です。従来の”ユーザーグループ別権限セット”とほぼ同様の機能です。セキュリティーグループ一覧画面から”Permissions”->”Permisson Set by Security Groups”を選択。
するとマトリクス形式の画面が表示されます。この画面でチェックをOn/Offすることで権限セットとセキュリティグループの割り当てを変更できます。
もう１つの便利機能は、xmlエクスポート/インポート機能です。1つつまたは複数のセキュリティグループを選択してエクスポートすることができます。
このようなファイルがエクスポートされます。
xmlファイルをインポートすることもできます。
xmlファイルにはセキュリティーグループと権限セット、会社コードの割り当てが含まれます。当然ですが、ユーザーID割り当て情報は含れません（それはAzure AD側の仕事）。テスト環境の設定を本番環境に移行するのに便利だと思います。
5. 入れ子のグループによる権限割り当て
実際の運用場面を考えると、Azure ADのグループが入れ子でも使えるかどうかが気になります。試してみましょう。
異なるグループタイプの間で入れ子が可能かどうかは以下のようになります。
| 親＼子 | Microsoft 365 | 配布リスト | メールが有効なセキュリティー | セキュリティー |
| Microsoft 365 | × | × | × | × |
| 配布リスト | × | 〇 | 〇 | × |
| メールが有効なセキュリティー | × | 〇 | 〇 | × |
| セキュリティー | × | 〇 | 〇 | 〇 |
テストケースとして、”配布リスト“グループにユーザーをメンバー追加し、”配布リスト“を”メールが有効なセキュリティー“グループにメンバー追加し、”メールが有効なセキュリティー“グループを”セキュリティー“グループにメンバー追加した例で実験します。
最初に”配布リスト“グループにユーザーをメンバー追加。
次に”配布リスト“を”メールが有効なセキュリティー“グループにメンバー追加。
最後に”メールが有効なセキュリティー“グループを”セキュリティー“グループにメンバー追加。
AzureADの”セキュリティー“グループ に”Super”権限セットを割り当て。
BCのセキュリティグループ一覧ではAzureADのセキュリティグループに”Super”権限セットとテストユーザーが割り当たっており、このテストユーザーはサインインできそうに見えます。
しかし実際にはサインインできません。。
入れ子の真ん中のグループ（”メールが有効なセキュリティー“グループ）に”Super”権限セットを付与します。
それでもサインインはできません。
入れ子の最下層のグループ（”配布リスト”グループ）に”Super”権限セットを割り当てます。
これはさすがにサインインできました。
実際に試すとわかりますが、同じタイプのAzureADグループを入れ子にしてもサインインできませんでした。つまり、グループを入れ子にしてアクセス権限を制御するのは不可能、ということです。
6. まとめ
- 従来のBCユーザーグループに代わってAzure ADのユーザーグループを使用してユーザーにPermission Setを割り当てることができる。
- セキュリティグループ以外のAzure ADグループ（M365グループ、配布リスト、メールが有効なセキュリティ）を使ってアクセス権限を制御することも可能。
- Azure ADのグループを入れ子にしてアクセス権限制御することは不可能。
7. 所感
Azure ADのグループを使用して権限付与することができるので、ユーザー割り当ての手間は減ると思います。実運用を考えたときに、人事異動のたびにAzure ADのグループとBCのユーザーグループの両方をメンテする必要がなくなるわけなので、手間としては減ります。入れ子が不可能の件も、もともとBCのユーザーグループが入れ子にできないので諦めはつくでしょう。入れ子ができたらなおうれしいですが。一方、BC導入ベンダーにとっては少々ややこしいことになります。今まではBCの世界で閉じていたので、好きに設定できていたのですが、M365導入済みでBCを新規導入するようなケースでは顧客のAzureAD担当にユーザー割り当て依頼することになり、BC内で完結できなくなります。設定変更とか、トラブル切り分けがやりにくくなるかな、と思います。とはいえ、全体としては会社のユーザーグループ管理の方針に沿った形で権限制御できるので、コンプライアンス的にも良い方向の改善だと思います。
ぜひ皆さんも使ってみてください。