ADFS 2.0 RU1で実装されたアクセス制御

Office365の正式リリースから3ヶ月強、10/12になってようやくADFS 2.0のRU1がリリースされました。いくつかOffice365向けの大きな機能追加がなされておりますが、今回はアクセス制御の機能強化について解説します。

これは、簡単に言うとリッチクライアント(Outlook2010等)でExchange Onlineにアクセスした際、今までは全てExchange OnlineのIP帯からのアクセスとしてADFS Proxyから見えていた物が、更にそのアクセス元のIPやプロトコルなどをHTTPヘッダとして付与して送信してくれるようになった為に付与できるようになった機能です。(平たく言うと敢えて漏れ串になったということ)

今回のRUをインストールし、設定することにより、以下の5つの属性が追加でクレームルールとして利用出来るようになり、主要なケースを元にしたアクセス制御が可能となります。

  • X-MS-Forwarded-Client-IP Exchange Onlineに接続されたIP
  • X-MS-Client-Application Exchange Onlineに接続したプロトコル
  • X-MS-Client-User-Agent Exchange Onlineに接続したクライアント
  • X-MS-Proxy Proxyサーバ経由でのアクセスか否か
  • X-MS-Endpoint-Absolute-Path ActiveフェデレーションかPassiveか

サンプルに載っている物を含め、いくつか動作検証を行った物を紹介します。ちなみに、通常のクレームルールに載っておりますが、簡単にクレーム発行ルールに基づき

  type=deny有り type=deny無し
issue type=permit有り アクセス拒否 アクセス許可
issue type=permit無し アクセス拒否 アクセス拒否

の様な制御マトリックスになります。それでは、いくつかのケースに基づきクレームルールを記載してみます。

①社外からOffice365へのアクセスをすべて拒否する
1.すべてのユーザにアクセスを許可

=> issue(Type = "http://schemas.microsoft.com/authorization/claims/permit", Value = "true");

2.会社のFirewallのIP(123.123.123.123)からのアクセスを除き、ADFS Proxy経由のアクセスを拒否する

exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy"])
&& NOT exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip", Value=~ "123.123.123.123"])
=> issue(Type = "http://schemas.microsoft.com/authorization/claims/deny", Value = "true");

②Exchange ActiveSyncを除き、社外からOffice365へのアクセスをすべて拒否する

 1.すべてのユーザにアクセスを許可

=> issue(Type = "http://schemas.microsoft.com/authorization/claims/permit", Value = "true");

2.ActiveSyncプロトコルまたは会社のFirewallのIP(123.123.123.123)からのアクセスの場合を除き、ADFS Proxy経由のアクセスを拒否する

exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy"])
&& NOT exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application", Value == "Microsoft.Exchange.ActiveSync"])
&& NOT exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip", Value =~ "123.123.123.123"])
=> issue(Type = "http://schemas.microsoft.com/authorization/claims/deny", Value = "true");

③Exchange ActiveSyncならびにブラウザベースのAPを除き、社外からOffice365へのアクセスをすべて拒否する
1.すべてのユーザにアクセスを許可

=> issue(Type = "http://schemas.microsoft.com/authorization/claims/permit", Value = "true");

2.ActiveSyncプロトコルまたはブラウザアクセス、もしくは会社のFirewallのIP(123.123.123.123)からのアクセスの場合を除き、ADFS Proxy経由のアクセスを拒否する

exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy"])
&& NOT exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application", Value == "Microsoft.Exchange.ActiveSync"])
 && NOT exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip", Value =~ "123.123.123.123"])
&& NOT exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path", Value == "/adfs/ls/"])
=> issue(Type = "http://schemas.microsoft.com/authorization/claims/deny", Value = "true");

明示されたADグループを除き、社外からOffice365へのアクセスをすべて拒否する

1.すべてのユーザにアクセスを許可

=> issue(Type = "http://schemas.microsoft.com/authorization/claims/permit", Value = "true");

2.明示されたADグループ(S-1-1-12-1234567890-123456789-123456789-1234)のメンバーもしくは会社のFirewallのIP(123.123.123.123)からのアクセスの場合を除き、ADFS Proxy経由のアクセスを拒否する

exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy"])
&& NOT exists([Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value =~ "S-1-1-12-1234567890-123456789-123456789-1234"])
 && NOT exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip", Value =~ "123.123.123.123"])=> issue(Type = "http://schemas.microsoft.com/authorization/claims/deny", Value = "true");

ExchangeからOffice365移行の際の注意点

オンプレミスのExchange Serverを利用されていて、BCPなどからOffice365への導入を検討される方も多いかと思います。現時点でドキュメント等に載っていない移行を検討する上での留意点がありますので、紹介させて頂きます。

Exchangeをインストールすると、オンプレミスのActive Directoryのスキーマが拡張され、各ユーザのADオブジェクトにExchange関連の属性が設定されます。この中に、アカウントに紐付くメールボックスを指定するmsExchMailboxGuidという属性が有ります。(多分Exchange 2000から利用されていたと思います)

この属性に値が設定されているままでOffice365にディレクトリ同期を実施した場合、『移行ツール以外からメールボックスを有効にできなくなります

試しにダミーの値を入れて検証してみます。adfs serviceというメールボックスの無いアカウントにmsExchMailboxGuidを設定します。

ディレクトリ同期された後、メールボックスを有効化する為にExchange Onlineのサブスクリプションを付与しようとすると、以下のメッセージが表示されます。

この移行バッチ以外からメールボックスが有効化できないということは、以下のような影響があります。

  • メールボックスを「移行しないでMX切り替えのみ」という移行方法の選択肢が取れない
  • オンプレがExchange2000の場合は、移行ツールを動かす為に2003以上にUpgradeが必要
  • Exchange移行ではなくIMAP移行はできない(IMAPは移行ツール実行前にメールボックスを作る必要がある)

では、対策を少しだけ考えてみます。まずは、

①既にオンプレのExchangeを利用していない場合

A.これは単純です。当該属性(msExchMailboxGuid)をオンプレのAD上で削除してしまい、再度同期をすればOKです。

②オンプレのExchangeを移行前にはオフラインにできない場合

B.一番綺麗な方法は、移行(メールボックスを有効にしたいタイミング)時にディレクトリ同期専用のAD DSを一時的に立てて、そこで当該属性の情報をクリーニングしてから同期させることです。msExchMailboxGuidが邪魔なのは、あくまでメールボックスを有効にするタイミングのみです。メールボックスが作成された後は、同期されるオンプレの当該属性に何か値が入っていても特に問題なく動作します。

C.移行が長期に渡る場合や、余分なAD DSを立てられない様な場合ですが、ディレクトリ同期サーバのMAの設定を書き換えて対応する必要があります。

ということで、案Cを実現させる為の設定をなるべく単純な方法で書いてみたいと思います。

①まず、ディレクトリ同期サーバに入って、C:Program FilesMicrosoft Online Directory SyncSYNCBUSUIShellmiisclient.exe を起動します。
②続いて、[Management Agents]-[TargetWebService]を選択し、[Properties]を開きます。
③[Configure Attribute Flow]を選択して、(Data Source Attribute)msExchMailboxGuid←(Metaverse Attribute)msExchMailboxGuidのExport(Direct,Allow Nulls)となっているルールを探します
④これをおもむろにDeleteします。

これで、Metaverseに格納されたmsExchMailboxGuidの属性をOffice365に同期するというデータフローが無くなります。ディレクトリ同期開始前であれば、これが終わってから同期を開始すれば大丈夫です。

ただ、一度でもディレクトリ同期をしてしまった後(msExchMailboxGuidが一度Office365側に同期されている)については、Metaverseのデータ自体が変更になっているわけでは無いので、再度フル同期をかけても当該属性のUpdate処理は走りません。

このため、Office365のディレクトリ同期で特定アカウントを非同期にするで紹介したやり方を使って、一度対象のアカウントのSource AD側をExplicit Disconnectorに設定し、同期することにより一時的にOffice365からアカウントを削除します。そして、それを再び解除(手動でProvisioningするか、通常のDisconectorにしてから再同期)してから同期を行い、Office365にアカウントを作成し直すことにより、msExchMailboxGuidがNullの状態で同期されるようになります。

というわけで、凄く面倒なので早くOffice365側の仕様を変更して欲しいですね…

AD FS環境でログオンユーザ以外でOffice365にログオンする(2)

以前の投稿 で書きましたが、AD FSを利用したシングルサインオン環境だと、強制的にWindowsにログオンしているADのアカウントでOffice365にログインしてしまいます。通常はそれほど問題にならないのですが、

  • 共用で利用しているグループのアカウントが存在する
  • 他人(共用)のコンピュータから自分の権限で利用する
  • 複数のアカウントのメールボックスをOWAから同時に開く

など、限られた環境の中ではありますが、結構ニーズとしてはあるように思えます。

複数のメールボックスを開くというのは、TIPSとして「IEのInPrivateで2つめのウィンドを開き、別のID/PASSで接続する」というのが有りますが、シングルサインオン環境だと両方とも同じアカウントで開いてしまいます。

以前検討した際は、いちいちその都度ゾーンの設定をいじってやりくりする物でしたが、もう少しスマートなやり方を考えてみましたので紹介します。

準備する点は2点。通常通りADFSサーバのアドレスを「イントラネット」サイトに入れますが、ここをhttps://付きで指定すること。もう1点は前の記事で紹介したとおり、httpでもADFSに接続出来るようにすることです。

まずは通常通り一つ目のアカウントを開いてOWAに接続し、そのままInPrivateブラウズでもう一つのウィンドゥを開きます。

 

ここで、2番目に開いた方のウィンドゥで、Exchange OnlineにAD FSを利用して気合いでOWAリダイレクトするで紹介したurlをhttp://に変更したアドレスに接続を試みます。

http://sts.example.com/adfs/ls/?wa=wsignin1.0&wtrealm=urn:federation:MicrosoftOnline&wctx=wa%3Dwsignin1.0%26wreply%3Dhttps:%252F%252Foutlook.com%252Fowa%252F%253Fexsvurl%253D1

すると、上手いことID/PASSの入力画面がポップアップしてくれますので、ここから開きたいユーザのアカウント情報を入力します。

これで、無事testuser oneさんと阿部 太郎さんの2つのOWAを開くことができました。

ADFSをSSLオフロード環境で利用する

AD FSですが、MSの提供しているAD FS 2.0 Capacity Planning Spreadsheetなどを参考にサイジングしてみると、比較的とCPU食わなそうに見えるのですが、実際に動作を見てみると意外に新規トランザクション数が伸びない印象を受けます。

ということで、少しでも負荷を軽減できるようにSSLのオフロード(LBでSSLを終端)をするときの処理を考えてみます。本当はiRulesまで作ろうかと思ったのですが、まだ需要が無かったのでとりあえずサーバ側のみで。

Office365のようなパッシブフェデレーションの場合、https://sts.example.com/adfs/ls…などにリダイレクトされます。AD FSサーバのIISを見てみると同じフォルダツリーの中に入っているので、そのままでも動くかなと思い、とりあえず以前の投稿で書いた無理矢理SSO用のurlをhttps⇒httpに変更してアクセスを試みます。

403エラーが表示されます。何となくIISの設定のみで行けそうなので、サーバマネージャのIISを開き、ADFSの実態で有る/adfs/lsの[SSL設定]を開いて確認してみると、[SSLが必要]にチェックボックスが入っています。

このチェックを外して再度アクセスを試みると、無事アクセスできました。

あと、SSLオフロードをする際は、代理で接続に来るLBなりの仕様に応じて(おそらく対応してないでしょうが)IIS側でWindows認証の拡張保護を無効化する必要があるかもしれません。(この辺を参考に)

OWAにシングルサインオンする(その2)

以前 Exchange OnlineにAD FSを利用して気合いでOWAリダイレクトする の記事でOWAへのシングルサインオンを紹介しましたが、より簡単な方法を見つけましたので紹介します。

やり方は簡単で、ブラウザを立ち上げて https://outlook.com/owa/[ドメイン名] にアクセスするだけです。
または、https://www.outlook.com/[ドメイン名] でも良いらしいです。

ADFSサーバのアドレスがイントラネットサイトに入っていないといけないという条件などは他のシングルサインオンと変わりませんが、これにより自動的にそのドメインがフェデレーションドメインとして構成されていれば、ADFSにリダイレクトされて認証され、最終的にOWAの画面が開きます。

と、これだけだと少しつまらないので、ついでにFidder2で通信のシーケンスを追ってみましょう。

Fiddler2 を使用して Office 365 Id フェデレーション ログオン処理をトレースする方法を参考にしつつ、Fidder2をインストールし、セットアップします。HTTPSの中身を見る場合、ADFSサーバ側のIISの設定変更(拡張保護を使用しないようにする)が必要です。

Fidder2を立ち上げ、Decrypt HTTPS trafficにチェックを入れてアクセスを試行してみます。

outlook.com ⇒ login.microsoftonline.com ⇒ [AD FSサーバ] ⇒ login.microsoftonline.com ⇒ outlook.com ⇒ pod51xxx.outlook.com ⇒sinprdxxxx(or hknprdxxxx).outlook.comの流れてリダイレクトされ、無事シングルサインオン出来ていることが確認できました。

もちろん、ログイン後にホームを押すとOffice365のポータルにも行けますし、そこからチームサイト(SharePoint Online)にもSSOできます。

【動画】 Office365にAD FSでシングルサインオンする

「Office365はIDを入力する必要があるからシングルサインでは無いって聞いたけど、どうなの?」という話をたまに聞くので、意外とAD FSの環境を実際に触って動きを見た人って少ないのかなと思い、適当にキャプってみました。

ブラウザアクセス(Office365ポータル、Outlook Web Access、SharePoint Online)

少し画質が粗いので、まだ少しましなFacebook動画の方も載せておきます

ADFSサーバのIEのゾーンの設定は自動認識される場合が多いですが、環境によって(例えば、example.localがAD名だった場合で、ユーザアカウントにはexample.comのUPN名を割り当てている場合)イントラネットゾーンとして認識されない場合、プロンプトが表示されてしまいシングルサインオンできませんので、https://sts.example.comなど、明示的に指定することをお勧めします。

また、*.outlook.comなどは無くてもログインはできるのですが、ログアウトの処理が実施できない(サインアウトを押しても元の画面に戻ってきてしまうなど)などの不具合がでることがありますので、「このゾーンには全てサーバの確認(https:)を必要とする」のチェックボックスを外した上でhttp、httpsともに設定できるようプロトコル指定無しで記載します。

 

メーラー(Outlook、Thunderbird:IMAP)

Facebook動画

Lyncクライアント

Facebook動画

監査環境下でのExchange Onlineの退職者の処理

Exchangeのプラン2では、長期間に渡るメールの監査・アーカイブへの対応を実施することが可能となっております。これは、「各ユーザのメールボックスの無制限のアーカイブ+削除/変更したアイテムの保全+監査ログ」という要素によって構成されており、情報の分散管理(各ユーザーのメールボックス)とその横断検索がキーとなっています。

ここで1点問題になってくるのが、退職者に関する処理です。ディレクトリ同期下において、退職したからと言ってローカルのAD上でアカウントを削除してしまうと、削除した情報がそのままクラウド側に同期され、ユーザが削除され、メールボックスが一定期間(30日)後にサーバ上から削除されます。

こうしてしまうと、退職前に何か仕掛けてから辞めていった人に対しての、さかのぼっての監査が実施できなくなってしまいます。とはいえ、永久的にメールボックスを残すということは、辞めた人の分も合わせてID単位の課金を続けなくてはいけなくなり、どんどん必要なサブスクリプションを追加していかなくてはならず、非現実的です。

退職者の情報は、ネットワーク管理者が必要な分のみ.PSTファイルに落として一定期間ローカル保存しておくという運用が一般的ですが、横断検索が出来なく無くなるなどの不便が生じますので、一定期間Office365にアカウントを残すという運用を考えます。

  1. 当該ユーザーのログオンを不可にする
  2. 当該ユーザーへのメールの配送を止める
  3. 配布グループから抜いたり、グローバルアドレス一覧の非表示化などの後処理

などが考えられますが、1.に関してはローカルのADでアカウントを無効化すれば、Office365へのアクセスも不可になります。(サブスクリプションは解放されないですし、普通にメールも配送され続けますが)

2.はExchange Online側のアクセス権で普段はメールを送ることが無い管理用アカウントなどだけからのメールを受け取るようにSet-Mailboxコマンドレットで-AcceptMessagesOnlyFromを指定しておくのが楽だと思います。PowerShellからの設定になりますので、Exchange Onlineに接続してから実行します。

3.については、Office365のExchange Onlineサービス説明によりますと、

管理者は、社内の Active Directory でオブジェクトに HideInAddressList 属性を設定して (ディレクトリ同期ツールを使用している場合)、またはリモートPowerShell を使用して、ユーザー、配布グループ、および連絡先をグローバル アドレス一覧で非表示にすることができます。

とあるので、2.でSet-Mailboxコマンドを実行するついでに実施してしまおうと思います。

おろ、ディレクトリ同期環境下ではローカルのみですか…困りましたねぇ。そう、勘の良い人ならお気づきだと思いますが、GALの表示を制御するmsExchHideFromAddressLists属性は、Exchangeをインストールする際のスキーマ拡張で実装される物で、オンプレミスでExchangeがないユーザの環境では設定自体ができません。もちろん、マニュアルに誤記されているHideInAddressListなんてのも有りません。

さて、考えられるのは2つ。ディレクトリ同期(ILM)をいじって、どこか使ってない属性からマッピングしてくるか、スキーマを拡張するかです。ホントは前者で行きたいですが、このmsExchHideFromAddressLists属性はBoolean(TRUEかFALSEを保持する)形式なので、対応した良さそうな物が見つかりませんでした。ということで、不本意ながらExchange2010SP1の評価版をサイトからダウンロードして、中身は使わずセットアップの準備コマンドだけを利用します。

今回はスキーマ拡張だけを行いますので、setup.com /PrepareSchemaを実行します。

完了すると、無事msExchHideFromAddressLists属性が設定できるようになります。Set-ADUserコマンドの場合、拡張属性なので以下のような感じでしょうか

Set-ADUser -replace @{msExchHideFromAddressLists=$True}



う~ん、高々アカウント削除だけの話なんですが、面倒ですね。

ジャーナルアーカイブがOffice365の中で使えればこんなこと考えなくても良いのでしょうけど。(今は他のEnterpriseVaultとかのアーカイブに飛ばして格納しないといけないので、NW帯域考えると現実的では無いですよねぇ…)

ディレクトリ同期で同期されない携帯番号

Office365でディレクトリ同期を行うと、ローカルのActiveDirectoryのオブジェクトならびにその各属性がOffice365側に同期されます。情報の不整合を防ぐ為に、基本的にディレクトリ同期で転送されたオブジェクトの情報はOffice365側では編集できません。

ただ、ユーザーの管理から、よく見ると一カ所だけ編集できるところがあります。それは携帯電話の番号です。ここに番号を入れればひょっとして値を変えられるのでしょうか?

そう、ここに値を入れると、Office365側の属性が書き換わります。ただ、この情報はローカルのActiveDirectoryには反映されません(ディレクトリ同期が一方向同期なので)

また、こちらに一度でも値を入れたユーザは、ディレクトリ同期項目から携帯電話の番号が除外されます。

つまり、今後会社携帯の番号が変わったからといってローカルのADで携帯番号を入れても、それはOffice365側には伝わらず、完全に別々の物として扱われるようになります。(ディレクトリ同期ではエラーも無く更新が成功したように見えるのですが、完全に無視されます)

また、一度もOffice365側で変更されたことのないユーザーについては、他の属性同様通常通り同期されるようになります。どうしてなのかは理由が分からないのですが、途中までは携帯も編集不可項目だったように思えるので、ベータテストの途中からそういった仕様に変更されたのではないでしょうか。

最近の個人情報関係の意識の高まりもありますので、携帯電話の番号をWeb上に載せたくないという要望もあるでしょうから、ユーザーが自信の情報公開範囲を限定したいというニーズに応える為ということであれば考えられなくもないかなとは思いますが、どちらかというとActiveSyncやSMS(まだ使えないですが)とかの機能でどうしてもOffice365側でMobileの番号の編集権限がないと困る物が有るのではないかなと考えてます。

変更処理自体はユーザが勝手に出来てしまう処理なので、管理者側ではどうしようもない事かと思いますが、どうしても管理者が一元的に同期するよう制御したいのであれば、だいぶ力業になりますが、ADならびにOffice365へのPowerShell接続ができる端末から、以下のようなスクリプトを定期的に実行することにより、強制的にローカルのADの情報をOffice365に同期できるようになります。(タスクなどで自動実行にするにはCredentialを保存して自動ログインにするなどの変更が必要です)

$LiveCred = Get-Credential
Connect-MsolService -Credential $LiveCred
$ADUser = $ADUsers = $MSOLUser = $MSOLUsers = $null
$i = 0
$ADUsers = Get-ADUser -properties Mobile -filter * | Select-Object UserPrincipalName,Mobile,SamAccountName
$MSOLUsers = Get-MSOLUser | Select-Object UserPrincipalName,MobilePhone
ForEach($ADUser in $ADUsers) {
  $MSOLUser = $MSOLUsers | Where-Object {$_.UserPrincipalName -eq $ADUser.UserPrincipalName}
  if([string]::isNullOrEmpty($MSOLUser.UserPrincipalName)){
    Write-Host "Skip - Office365に作成されていません: "$ADUser.SamAccountName
  }
  elseif($ADUser.mobile -ne $MSOLUser.MobilePhone ){
    Write-Host "ADの情報でOffice365を上書きします【"$ADUser.UserPrincipalName"】"
    Write-Host " - ActiveDirectory:"$ADUser.mobile" の値でOffice365:"$MSOLUser.MobilePhone"の値を上書きます"
    Set-MsolUser -UserPrincipalName $MSOLUser.UserPrincipalName -MobilePhone $ADUser.mobile
    Write-Host " - 完了しました"
    $i++
  }
}
Write-Host "終了: 計"$i"件の携帯電話番号レコードを同期しました"
Write-Host "(何かキーを押してください)"
[console]::ReadKey()

一元的に情報を扱うというのもなかなか難しいですね。っていうかこういった仕様とか制限とか、変更するのは構わないが、できれば公開情報にして貰いたいなぁ。

こちらですが、恐らく2011.秋に実装された管理者向けパスワードのセルフリセットツールで利用するためにこう言った設定になったと推測されます。

顔写真を登録して少しでもOffice365を華やかにする

Office365では、コミュニケーションの促進のため、それぞれのアプリケーションで各ユーザの顔写真情報を利用することができます。

登録していないデフォルトの状態だと、以下のように人型のアイコンのみ表示されていますが、これでは少し味気ないですよね。今回は、ここに顔写真を登録してみます。

Office365展開ガイドによると、アップロードには2つの方法が記載されてます。

  • エンド ユーザーが Microsoft Online Services ポータルの [ユーザー設定] 画面を使用して、自分の写真を手動でアップロードできます。
  • 管理者は、社内の Active Directory で ThumbnailPhoto ユーザー属性を指定できます。その結果、ディレクトリ同期ツールによって、自動的に、ユーザーの写真が Exchange Online、SharePoint Online、および Lync Online と同期されるようになります。

社員証などの写真を総務から貰って画一的に登録するのもいいですが、別人のようになっている人もいますよね。公開範囲が社内だけとはいえ、そもそも公開するしないか、どんな写真をアップするかまで各ユーザーに任せられるのが一番なので、ユーザーポータルからやってみましょう。

…ってあれ? ディレクトリ同期を利用しているユーザは、パスワードの変更に加えて写真の変更のリンクも無いですね。どうやらローカルのADから同期する方法しかなさそうです。(クラウドIDを利用しているアカウントは以下のようにリンクが出ます)

やり方自体はExchange 2010などと同じで、ローカルのActive DirectoryのThumbnailPhotoにJPEGファイルを入れればいいですが、Binary属性で入れなければならないのでいざ1からやろうとすると結構面倒です。

ということで、今回はブチザッキ様が作成された素晴らしいアプリを利用します。こちらはログインしているユーザーが自身のADのThumbnailPhoto属性をGUIで変更できる物です。実行には.net Framaworkの4が必要になるようなので、早速インストールして利用してみます。

起動すると顔写真が登録されていない旨のメッセージが出ます。ファイルメニューからJPGファイルを選択すると、No Imageだった顔写真が更新されますので、編集メニューの【顔写真を更新】を選択してADに情報を登録します。

登録された情報をディレクトリ同期で即時同期を実施してOffice365に更新させます。念のためILMを起動して確認したところ、以下の通り無事にThumbnailPhotoがBINARYデータで更新されています。

しばらくすると、ポータルのプロフィールの画面が更新され、LyncやExchangeのプレゼンスの横の顔写真が無事更新されました。(Outlookの下の写真は、グローバルアドレス帳から連絡先フォルダに追加したら表示されるようになりました。)


SharePoint Onlineの顔写真だけは、少し時間がたっても更新されなかったので、もう少し様子を見てみようと思います。

Exchange OnlineにAD FSを利用して気合いでOWAリダイレクトする

リクエストを頂いたので、Office365ポータルではなくExchange Online(OWA)もやってみます。

OWAのリダイレクトを設定すると、Office365に移行済みのユーザがオンプレミスのOWAにアクセスした際に、Office365側にリダイレクトをかけることができます。ただ、普通にhttps://outlook.com/owa/example.comなどにリダイレクトをかけても、

って感じで悲しくもサインイン画面に飛んでしまいます。

というわけで、前回同様サインインのURLを適当に解析してみて、一個一個省略可否を探って行きます。

2番煎じでつまらないですが、以下のURLでOWAにSSOできるようになります。

https://sts.example.com/adfs/ls/?wa=wsignin1.0&wtrealm=urn:federation:MicrosoftOnline&wctx=wa%3Dwsignin1.0%26wreply%3Dhttps:%252F%252Foutlook.com%252Fowa%252F%253Fexsvurl%253D1

これをSet-OrganizationRelationshipで設定してあげれば上手くリダイレクトされる環境が作れそうです。