見出し画像

AzureADグループの動的ユーザを使ってみる（条件に使うプロファイル編）

いとぅ

前回、AzureADグループの動的ユーザの作成方法と注意するポイントについてまとめましたが、今回は条件作成にあたり自分が留意した事項について簡単にまとめてみようかと思います。

動的ユーザに使いやすいプロファイル

もちろん会社によって色々な運用がありますので一概にこれ！とはいかないのが事実ではありますが一般的に条件として使いやすいのは

  • 従業員ID、社員No（user.employeeid）

  • 部署（user.department）

  • アカウント有効状況（user.accountEnabled）

  • 番外編：ホスト名（device.displayname）※動的デバイスで利用

大まかにはこの辺になるでしょうか？
グローバルな会社だとCountryなんかも条件になるケースがありますね。
今回はプロファイルの設定方法と、この内2つについて自分の方で取り組んだことを書いてみようかと思います。

そもそもプロファイルは何処で設定するの？

ADConnectを利用している場合はActiveDirectryサーバ側でユーザ設定する際に各項目に入力＆連携させる事でAzureAD側に反映されます。

ActiveDirectryのユーザ登録画面
基本は各タブで登録→連携が可能ですが
一部属性エディタからしか登録できない項目があるので注意！

ADConnectを利用していない場合はAzureADから直で更新可能です。

ADConnectしてなければ編集を押せば自由に修正可能


従業員ID・社員No（employeeid）で留意したこと

社内にアクセスするAD、AzureADユーザに対しては基本的に全て社員Noを付番する運用が出来ると非常に運用が楽になります。
会社によって違いはあると思いますが、大まかに社内にアクセスするユーザはこんな分類ができるのではないかと思います。

  1. 正社員（役員・契約社員含む）

  2. 派遣社員

  3. パート・アルバイト

  4. 業務委託（協力会社）

多分大半の会社では1～3は人事系の部署で管理されている事が多いですが、これらの社員Noはちゃんと頭文字を別文字（数字）を付番するなど分類できる状態になっているでしょうか？
例えば、正社員はAxxx、派遣はBxxx、アルバイトはCxxx等々…。
もしそうなっていれば契約種別でのコントロールも

正社員のグループの条件
(user.employeeId -startsWith "A")

派遣社員のグループの条件
(user.employeeId -startsWith "B")

このような形で実現できるので非常に楽です。
もし、分割されていないよ…ってケースの場合は後程記述する部門コードの予約番号などを使って処理する形になるので少し面倒です…。

また、4については人事管轄外のケースが多いかと思います。
※ユーザ管理している情シスが一番知ってるまであったり…。
もしAzureAD上にこれらのユーザを組み込んでいるのであれば人事系部署のメンバーとも会話の上でルールに則った付番をし、情報共有を行っておけば色々な面で制御が効くようになるのでオススメです。
※業務委託や協力会社は1～3の社員区分よりも特に制限をかけるシチュエーションが多い筈ですので是非認識を共有してユーザ作成時に付番出来るようにしておくと良いのではないかと思います。

部署コード（department）で留意したこと

前回でも少しお話した部署コードの付番についてですが
いとぅの場合コードの命名ルールを以下の様にしています。

多少違いますが考え方は変えていません

日本の場合組織がどうしてもツリー構造な会社が多いので

  • 本部レベル（内包する部、課、係は全て）

  • 部レベル（内包する課、係は全て）

  • 課～係レベル

こんな形で構成プロファイルを分けたり、アクセス制御をかけるケースが多いのかなと思います。
この部門コードの組み方であれば

■本部レベルの動的ユーザ管理
(user.department -startsWith "VWW")

■部レベルの動的ユーザ管理
(user.department -startsWith "VWWXX")

■課～係レベルの動的ユーザ管理
(user.department -startsWith "VWWXXYY")
もしくは
(user.department -equal "VWWXXYYZ")

こんな感じに動的ユーザのプロファイルが設定できるので、とても管理しやすくなり良いのではないかと思います。

頭にある例外コードを追加した理由としては

  • 主務と兼務で制御を分けたいケース

  • 社員区分によって同部署でも別制御にしたいケース

このような形で同じ部署でも制御が異なる場合に例外コード部分を変更する事で対処する…なんて使い方をしています（例外コード部分を変えるのは基本情シス内だけでの運用にしてます）
※そもそも後者（社員区分分離）については社員No側で分離できていればAND条件で分岐できる訳ですが…。

余談ですが…

WW、XX、YY部分の付番も単純な通し番号でやるのではなく、ある程度ルール性を持たせて付番するとさらに制御が楽になるケースもあります。

例えば

  • 課～係レベルの分類時
    営業部門は数字、生産部門はA～I、管理部門はI～Zで分ける

  • 拠点は部レベルで別れていれば
    部番号の2桁の内、頭の1桁は拠点番号にする

等々、各社の事情を見ながら応用することも出来るのではないかと。

最後に

今回の例はあくまでいとぅが自社内で取り組んでいる例でありベストエフォートな内容では無い事はご留意下さい。当然会社によって部署の考え方、構成は様々なので必ずしもコレがフィットするとも限りません。

しかしながら単なる通し番号的なコード体系にするよりは拡張性も考え、しっかりとした部署マスタ構成を取る事で動的ユーザの制御もしやすくなりますので、一度関連部署としっかり話してみる事も良いかもしれません。

この記事が気に入ったらサポートをしてみませんか？