Office365で階層型アドレス帳が利用可能に②

前回の投稿では、Office365で利用可能になった階層化アドレス帳のさわりをご紹介しました。

今回は、実際に利用していく上でいくつか考えていく必要のあることを中心にお話したいと思います。

1.階層として利用できるグループの種類について

Office365では、①メールが有効なセキュリティグループ ②配布グループ ③動的配布グループ という3つの種類のグループを利用する事ができます。

 

20140325_01

テストというグループの下にそれぞれの種類のグループを入れて、アドレス帳に表示しないオプションを入れてない物-1(デフォルト値)と入れていない物-2を作成しました。

動的配布グループはアドレス帳に表示しないオプションの選択や階層化アドレス帳として利用する為に必要な Set-Group -IsHierarchicalGroup $true 自体が入れられませんでしたが、とりあえずはグループメンバーに入れたままテストしてみます。
20140325_03

結論)階層化アドレス帳の階層グループには「メールが有効なセキュリティグループ」「配布グループ」が利用できる。利用する場合はPowerShellのSet-Groupコマンドレットで -IsHierarchicalGroup を $true に設定し、アドレス帳非表示の属性は有効化してはいけない。

2.複数組織にまたがるユーザー(兼務者)の扱いについて

階層化アドレス帳はグループ内のメンバーであるユーザーを再帰的な展開はせずにそのまま表示します。この為、例えば「Contosoグループ会長 兼 Fabrikam株式会社社長」などのユーザーを表現したい場合は、「Contosoグループ」「Fabrikam株式会社」の両方のグループのメンバとして登録すれば両方に表示されます。
20140325_04

ただし、注意が必要なのは右側の一覧画面の中で表示される「役職」についてはグループの情報では無く、各ユーザーに静的に設定された値が表示されますので、一般的には本務の方を役職欄に入れる形が多いかと思います。

3.同一グループ内の並び順について

ここが階層化アドレス帳の最大の特徴にして、日本から要望が上がって機能化したんだなとしみじみ思う点の1つです。日本人は、社員の一覧を表示する際に50音順では無く役職順に並ぶ事を美学としています。

この為、
20140325_05
こーんな並び方をしてた日には、酒井総務課長からけしからんというメールを頂く事にもなりかねません。

このため、階層化アドレス帳で表示させるユーザーやグループには、SeniorityIndex というパラメータを設定して明示的に偉さの順番を表現することができます。

例えば、社長440 常務430 部長320 課長 310 係長220 社員210 などと定めて、それを各社員にSet-User -SeniorityIndex で設定をしておけば、
20140325_06

といった表示となり、酒井総務課長も満足してくれます。また、複数の同一階層の組織の並び順(例えば営業部が前なのか総務部が前なのかなど)を行う際にも利用できます。

元から会社の人事システムなどでコードがあればそれで良いですし、なければ後から間に役職を足せるように適宜間を開けた数を振りましょう。(え?担当部長代理と担当課長とどっちが偉いかって? そんな事は人事の人にでも聞いて下さいw)

4.同一階層内での並び順について

同一階層で、同一SeniorityIndexの場合、もしくはその設定が無い場合、並び順はフリガナが設定してあればその順に、無ければASCIIコード順になります。

こちらもASCIIコード順だと特に日本語の環境の場合は視認性が悪くなりますので、フリガナを設定しておきましょう。コマンドはSet-User [ユーザー名] -PhoneticDisplayName [フリガナ]です。

5.その他

  • Outlook Web App(OWA) からは利用できません。Outlook 2010/2013のみです。OWAからも利用したい場合は、BBSさんのAddressLookなどのアドインを活用しましょう。
  • 階層型アドレス帳関連の設定は基本的にPowerShellからコマンドラインベースで行います。組織改編や人事異動は気合いで乗り切りましょう。(昔は管理ツールとかも出てたのですが
  • アドレス帳ポリシー(ABP)と併用することはサポートされていません(参考)。(※試した限りでは上手く階層が作れれば動きます。アドレス帳非表示設定になってると階層型アドレス帳に表示されないのと同じ理屈で、トップから表示させたい各階層のグループ&メンバーまで上手くアドレス帳ポリシーに則って分割できれば…。)

 

ADFSでの所属ADグループによる制御について

Office 365でADFSを利用するとActive Directoryのグループをベースとしたアクセス制御を実装することができます。

Microsoftのサイトなどに設定例などがいくつか記載されておりますが、今回、主に大規模な組織でこのルールを運用する場合、こちらのサンプルをそのまま利用すると一部書式の問題でセキュリティリスクに繋がると考えられる物があるためこちらで共有します。

クライアントの場所に基づいた Office 365 サービスに対するアクセスの制限
An ADFS Claims Rules Adventure

書式のサンプルは以下の通りです。グループ名ではなくSIDを利用するというのはActive Directoryなどでの管理と同じで、グループの名称を変更しても不変な値をベースとして制御しています。

exists([Type == ”http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value =~ "Group SID value of allowed AD group"])

例えば、以下のSG1というセキュリティグループでアクセス拒否の制御をする場合は、
20140323_01

exists([Type == ”http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value =~ "S-1-5-21-589771422-1504810464-123969929-1223"])
=> issue(Type = "http://schemas.microsoft.com/authorization/claims/deny", Value = "true");

などとします。

ところが、ここで1点問題と考えられるのが、上記赤字で書いた部分の書式です。==は「等しい」ですが、=~は「含む」です。また、SIDはGUIDなどとは違い可変長で、末尾の数字はグループが作成される度にインクリメントされてどんどん数字が増えていきます。

つまり、グループの数がどんどん増えて行った場合、いずれはSIDが一桁上がって制御すべきグループのSIDを「含む」グループが作成される可能性があるということです。
20140323_02

これにより、特定グループのメンバーを拒否しようとしたら別のグループのメンバーが意図せず拒否されてしまったり、特定グループのみアクセス許可していたサービスが意図せず許可されてしまうということが起こる可能性があります。

もっとも、ユーザーが作成するグループのSIDは基本的に4桁(1100番台?)から作成されるので、これが問題になるのは5桁のSIDが作成されるような10000以上のグループがある大きな組織になりますが。

exists([Type == ”http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value == "S-1-5-21-589771422-1504810464-123969929-1223"])
 => issue(Type = "http://schemas.microsoft.com/authorization/claims/deny", Value = "true");

とすることにより、意図した挙動とすることができます。