Office365の64bit版ディレクトリ同期ツール

待望のOffice365のディレクトリ同期ツールの64bit版が11/17にリリースされましたので、早速試してみました。

Windows 2008R2へのインストール手順

1.準備

  • ドメインのメンバサーバとして所属させます
  • .NET Framework 3.5.1の機能を追加します

2.ディレクトリ同期ツールのダウンロード

管理メニューのユーザーから、Active Directory同期のセットアップをクリックします。

4番目の項目で、Windows 64bit版を選択し、ダウンロードをクリック

3.ディレクトリ同期ツールのインストール

ダウンロードしたdirsync-ja.exeをダブルクリックし、インストーラーを起動します。

特にここで気にしなければならないことは無いので、指示に従って進めます。
      

4.ディレクトリ同期ツールの構成

インストールに引き続き、ディレクトリ同期構成ウィザードで設定を行います。

インストールに必要なのは、①Office365の管理者のID、PASS ②Active Directoryの管理者(フォレスト全体を同期するのでEnterprise Admins)のID、PASS ③Exchange2010の高度な共存環境(ディレクトリの書き戻しの有効化)の有無です。
  

必要項目を入力し、インストールを完了させます。
  

5.ディレクトリ同期ツールの追加設定

以上で、ディレクトリ同期ツールの設定は基本的に完了です。特に何も設定すること無く、3時間に1回ずつディレクトリ情報の同期を行ってくれます。

ここでは、もう少し便利に使うために追加設定を行います。

①ディレクトリ同期ツールの権限の設定

ディレクトリ同期ツールをインストールすると、ローカルにMIIS_Serviceというサービス用のアカウントと、FIMならびにSQL関係のグループがいくつか作成されます。このうち、MIISAdminsというグループが、ディレクトリ管理ツールの管理権限を持つユーザとなります。

デフォルトでは、インストールしたユーザならびにMIIS_Serviceしか入っていませんので、ここに管理上必要なアカウントやグループを登録します。Office365ならびにフォレスト全体の情報が登録されてますので、厳密に管理を行う必要があります。今回はEnterprise Adminsを登録しておきます。

②手動同期PowerShell実行用のショートカットの設定

ディレクトリ同期は、標準で3時間毎に同期されておりますが、ユーザを登録した直後など、手動で同期を実行することがサポートされております。C:Program FilesMicrosoft Online Directory SyncDirSyncConfigShell.psc1からPowerShellコンソールを開くので、こちらのショートカットをデスクトップに作成します。

手動同期を実施したい場合は、PowerShellからStart-OnlineCoexistenceSyncコマンドレットを実行します。

③ディレクトリ同期ツールの管理コンソールのショートカットの作成

②の手動同期の結果の確認や、細かい操作はディレクトリ同期ツールのコンソールから実施することができます。ILM 2007ベースの32bit版とは少し違う場所ですが、C:Program FilesMicrosoft Online Directory SyncSYNCBUSSynchronization ServiceUIShellmiisclient.exe にあるので、ショートカットを作成します。

ここで、一度資格情報をリセットするために一度ログアウトする必要があります。そのまま起動しようとするとエラーが表示されます。

再度ログインしてmiisclientを起動すると、無事管理コンソールが起動できます。

次回以降、32bit版の時にできていた各種オペレーションやカスタマイズ可否を確認してみたいと思います。

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認証の拡張保護を無効化する必要があるかもしれません。(この辺を参考に)

Exchange Onlineでのメール転送

Office365で利用されているExchange Onlineは、いくつかの方法で着信したメールを他のアドレスに転送をすることができます。

大きく分けて、転送を設定出来るポイントは4つ有ります。

  1. Forefront Online Protection for Exchangeのポリシールール
  2. Exchange Onlineのトランスポートルール
  3. Exchange Onlineのメール転送
  4. Exchange Onlineの受信トレイルール

今回は、これらの4つをいくつかのポイントに焦点を合わせて比較してみたいと思います。

①FOPE Policy ②Transport ③MailForward ④Inbox-Rule
設定可能な人 管理者 管理者(代理設定)
ユーザー
ジャーナルアーカイブ 対象外 対象
受信トレイに残さず転送 可能 不可
Envelope From書き換え 無し 有り
転送系ヘッダ付与 無し 有り(※1) 有り(※2) 有り(※3)
表示名への書き換え 無し 有り(※4)
受信トレイルールの影響 受けない 有り(※5)
※1: X-OriginatorOrg、X-MS-Exchange-Transport-Rules-Loop
※2: X-OriginatorOrg、X-MS-Exchange-Inbox-Rules-Loop
※3: X-OriginatorOrg、X-MS-Exchange-Inbox-Rules-Loop、Recent-From
※4: Exchangeが自動的に行う変更username@example.com⇒山田太郎<username@example.com>など
※5: ルールの順序により、転送より優先度が高いルールの方が先に処理される

以上のことから、通常は3をベースに条件に応じて使い分けるのが良いかと思われます。

  1. Exchangeに影響無しにメールを転送したい場合
  2. 管理者が保全などの目的で(特定条件を満たす)メールを転送する場合
  3. ユーザ自身が(また、管理者が代理で)携帯などに転送を設定する場合
  4. ユーザが特定の条件に合うメールのみ、条件付き転送を行う場合

設定方法といくつかの注意点をメモ書き程度に

①Forefront Online Protection for Exchangeのメニューから【ポリシールール】でBCCで配信ルールを作成する。

②Exchangeコントロールパネル(組織の管理)の【メールの制御】-【ルール】から新規作成を行う。

③Exchangeコントロールパネルを開き、【アカウント】-【接続されているアカウント】から【電子メールの転送先】を設定する

④Exchangeコントロールパネルを開き、【電子メールの整理】-【受信トレイのルール】でリダイレクトのルールを作成する

  • プランEではなく、プランPの場合はFOPEの管理メニューにアクセス出来ないので①の方式は利用不可
  • Exchange Onlineのみでメール監査を行う場合、①~③でメールボックスに配送せず転送した場合は、対象外となる
  • ①②の「リダイレクト」は④のリダイレクトとは意味が異なり、メールボックスには配送されない。④のリダイレクトを行う場合は「Bccで送信」を利用する。

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プラン2を(ちゃんと)活用する

Office365で利用できるExchange Onlineには、プラン1とプラン2が有ります。大きく言うと、メールボックス容量が無制限で監査アーカイブ機能に対応した物がプラン2という括りになります。

プラン1とプラン2は、定価ベースで倍値段が違く、一般的な利用であればプラン1のメールボック容量の制限25GBを越えるというのは難しい為、プラン1で良いように思えますが、

「30日以上の期間を遡ってメールボックスの監査を運用上(もしくは法令上)実施する必要のある」ユーザーにとっては、プラン2を契約するのが一番の(というか唯一の)選択肢になります。もう少しクラウドサービスが出そろえば、プラン1+クラウドのジャーナルアーカイブなども考えられますが。

というのも、Office365で謳っている「アーカイブ機能」というのは、一般的に言う「ジャーナルアーカイブ」ではなく「個人のメールボックスアーカイブ」になります。つまり、ユーザは自由にメールボックス上にある過去のメールを削除したり変更したりでき、かつ削除したアイテムは14日後にクラウド上から消え去ります。通常メールの監査を行う場合は、短くて半年なり長い場合は3年、5年間にわたり全社員の送受信したメールの記録を取る必要がございますので、ここの保全の機能でプラン2が必要になる訳です。

「高い金出してうちはプラン2を契約しているから監査対応はバッチリです。」

いえいえ、単に契約しただけでは、実際にはプラン1と変わらない状態でデプロイされてますので、プラン2向けの設定をちゃんと入れてあげる必要があります。(デフォルトのポリシー変えてくれれば良いのに…)

とりあえず、やる必要のある工程は、デフォルトの設定を考えると通常の企業だと

  1. 訴訟ホールドもしくは期間限定訴訟ホールドの有効化
  2. アーカイブメールボックスの有効化
  3. メールボックス監査ログの有効化
  4. メールボックス監査ログの有効期限の設定(任意)
  5. 必要なプロトコル以外の無効化(任意)

あたりでしょうか? このうち1番と2番のみ(2番が容量無制限)はプラン2の機能、3~5はプラン1でもできる物です。また、1番で期間限定訴訟ホールドを実装するには、SRベースで対応をして貰う必要があります。SRだと時間が掛かるのと、ユーザの追加の度に実施するのは少し面倒なので、今回は訴訟ホールドのONでPowerShellで実装します。(1,2はECPからGUIでも実施できます)

$TarMBX = Get-Mailbox -identity user1
$Name = $TarMBX.DisplayName
Enable-Mailbox -identity user1 -Archive
Set-Mailbox -identity user1 -LitigationHoldEnabled $true -AuditEnabled $true -AuditLogAgeLimit 183.00:00:00 -ArchiveName "アーカイブ メールボックス - $Name"
Set-CASMailbox -identity user1 -ActiveSyncEnabled $false -ImapEnabled $false -PopEnabled $false -EwsEnabled $false

実施するコマンドは3つで、それぞれ以下のような感じでやってるサンプルです。

  • Enable-Mailbox…②アーカイブメールボックスの作成
  • Set-Mailbox…①訴訟ホールド有効化、③メールボックス監査ログ有効化、④メールボックス監査ログ期間半年に設定、②アーカイブメールボックス名変更(GUIのデフォルト値に)
  • Set-CASMailbox…⑤MAPI(Outlook)とOWA以外での接続のプロトコルの無効化

とりあえずこの状態にしておけば、あれば何か有っても大丈夫な気がします。強いて言うなら以下の辺を注意でしょうか

  1. ユーザーを削除すると過去のメールボックスごと30日後にクラウド上から情報が消え去る
    ※必要な期間消さないで下さい。もしくは.PSTにダウンロードしてから消して下さい
  2. 管理者監査ログの保持期限が90日なので、それより前の特権利用アクセスの有無の調査ができない
     ※Set-AdminAuditLogConfigコマンドで設定変更できるとマニュアルには記載がありますが、実装されていません

SRVレコード無しの環境でのLyncの利用

Office365のLync Onlineでは、DNSのSRVレコードを利用して接続先サーバの情報などをLyncクライアントに渡しています。

この為、Office365を独自ドメインで利用する(プランP)で紹介したようなDNSを外部ホスティングなどの環境を利用して、SRVレコードが設定できない様な場合、以下のようなエラーが出てLyncが使用できません。

心配はいりません。自動ログインができないだけなので、一度だけ手動で設定を入れてあげれば解決します。メニューのツールオプションを開き、個人 – アカウントの詳細設定を開きます。

そこで設定を手動構成として、内部サーバならびに外部サーバの欄に共にsipdir.online.lync.comを入力します。

これで再度サインインを試みると、ユーザ名とパスワードを入力する欄が出ますので、ユーザ名にサインインアドレスと同じ値を、パスワード欄にパスワードを入力します。

これで無事にサインインが完了します。上記設定は保存されてますので、一度設定さえすれば次回以降は問題なく利用出来ます。

【参考】
Lync Online で発生する認証と接続に関する問題のトラブルシューティング