8/31に開催されるOffice365勉強会に登壇させて頂く事になりました。
今回話すテーマとしては、ここ半年で出てきたディレクトリ同期によるパスワード同期や、二要素認証、Windows Server 2012 R2での新しいADFSなどの新しい技術要素を踏まえた上で、今、企業でOffice365を利用する際のIDやパスワード管理はどうするのが良いのかについて少し話したいと思います。
名称：第6回 Office365勉強会
日時：2013/8/31 13:00～18:00
場所：品川グランドセントラルタワー 31F セミナールームA
詳細：http://www.office365room.com/o365-meeting/o365meeting-6/
登録は こちら から。
土曜日の午後ですが、お時間の許す方は是非ご参加頂ければと思います。
Office365のアクセス制御の実装方式としまして、一番一般的なのはADFSを利用したクレームルールによるアクセス制御になります。クレームにはExchangeにアクセスしてくるクライアントのIPやプロトコルなどの情報がOffice365側で付与されて伝送されてきますので、それとユーザーの所属するグループなどの情報を合わせてアクセス制御を実装します。
ここ1～2年の間で、（非常に細かいことですが）少しここの仕組みでOffice365側で変更になった部分があるので紹介します。
まず、従来のアクセス方式について説明します。Office365のExchange Onlineは、メールボックスがシンガポールか香港のどちらかがプライマリとして設定されています。また、ユーザーがアクセスするCASサーバはどちらのデータセンタも同じURLでのアクセスとなるため、1/2の確立で自分のメールボックスが無いCASにアクセスされます。
この際、Outlook（Outlook Anywhere）やActiveSyncなど、HTTPSによる通信でリダイレクトがサポートされているプロトコルについては、メールボックスがこのサイトに無い旨クライアント側に通知され、メールボックスの存在するサイト（下の図で言えばシンガポール）のCASサーバにリダイレクトされます。
この結果、ADFS（ADFS Proxy経由）に渡されてくる送信元IPは、元のグローバルIP：Aが渡されてきます。
次に、POPやIMAPなど、プロトコル的に「リダイレクト」の処理がサポートされていない場合です。この場合、CASサーバは適切なサイトへの接続（下の図で言うと香港→シンガポール）を「Proxy」処理します。
これが行われると、ADFSには送信元IPとしてグローバルIP：AならびにグローバルIP：Cの両方が渡されます。
この原理により、POP/IMAPのプロトコルをADFSで送信元IP制限を掛ける場合、Exchange OnlineのIP帯についても許可IPリストに入れておく必要がありました。
変更点
①クライアントのIPアドレスとしてIPv6がサポートされました。
Exchange Onlineの接続ポイントとしてIPv6がサポートされました。合わせて、クライアントのIPv6アドレスについても問題なくADFSサーバ側に情報として渡されるようになりました。
ADFSのクレームルールでは、文字列の正規表現でのマッチングで判定をします。「IPv6でもアクセスできるように許可する」「既存の許可ルールが、別のIPv6アドレスにマッチングしないようにする」などの確認が必要になります。
②MicrosoftデータセンタのIP帯のアドレスがマスクされてADFS側に渡されなくなりました。
これは、上記POP/IMAPアクセスの際に従来「グローバルIP：AならびにグローバルIP：C」が渡されてきた物から香港DCのIP帯であるCの方がマスクされて「グローバルIP：A」のみADFSに渡されてくる形になります。
http://community.office365.com/ja-jp/wikis/sso/927.aspx にも、以下のように記載があります。
・クライアント IP アドレスおよび要求を渡した各プロキシのアドレスを示す複数の IP アドレスは、 コンマで区切って指定されます。 ・Exchange Online インフラストラクチャに関連する IP アドレスは一覧に表示されません。
これにより、ADFSのクレームルールを作成する場合に、プロトコルの挙動（リダイレクトかProxyか）の差について作成者は意識せずに作れるようになりました。
ただし、現時点で1つ問題点というか、制限事項が確認されています。このマスクされるIPアドレスについては別途Microsoft側で定められているようなのですが、それにシンガポールDC、香港DCなど【同一DCで動作しているWindows AzureサービスのIP帯】も一部含まれているようです。
この為、Windows Azure上で展開されているExchange Online対応のサービスについて、適切なIPアドレスが渡されてこない可能性があります。IntuneのクライアントアクセスのIPアドレス帯については未確認ですが、同じ原理でいけば可能性はあると思います。
いずれIPアドレスのリストなどが精査されて直ることを期待してますが、動作原理を知っているのといないのでは有事の際に対応にも差が出るかと思いますので、細かいことですがここでご紹介させて頂きました。
なお、この記事は一部検証結果に基づいた個人的な推察を交えて記載しておりますので、もし事実に反することや、既に解消されたということが書かれていた場合は訂正させて頂きますので、連絡を頂ければと思います。
Office365にサインアップを行う際、最初に作成されるアカウントは（その時点で）唯一の全体管理者として作成されます。
通常は、このアカウントを利用して色々Exchange OnlineやSharePoint Onlineの設定を行うことができるのですが、テナントによっては希に以下の様な事象になり、Exchangeの管理ができなくなることがあります。
①管理者メニューのExchangeを開くと、組織では無く個人のExchangeの設定が出てしまう。
②Office365管理センターのサービス設定からExchange関係の設定をしようとすると403アクセス拒否のエラーが出る
どういうメカニズムで発生しているのか、少し中を見てみたいと思います。まず、新しい全体管理者のアカウント（今回はadmin02という名前）を作成します。この新規で作成したユーザーはExchangeの管理画面（Exchange管理センター）に接続できるので、接続後に[アクセス許可][管理者の役割]を見てみます。
TenantAdmins_xxxxxという名前のグループがありますが、ここに通常は全体管理者のユーザーがコピーされてきます。このグループがOrganization Managementのメンバーなので、全体管理者がExchangeの管理権限を持つという仕組みです。ここで、メンバーがadmin02という新規で作ったユーザーしかいないことが分かります。
よって、この事象は恐らく全体管理者のメンバー情報がOffice365ポータルからExchangeにコピーされる際に、タイミングや不可の問題等で欠落してしまったと推測されます。また、最初のユーザーでのみ発生することから、テナントのプロビジョニングの問題と考えられます。
よって、最初のユーザーから一回全体管理者の管理権限を外し、再度付け直すことによって解決を試みます。
反映までに若干時間が掛かりましたが、これでTenantAdmins_xxxxxのメンバーに最初の管理者が追加されました。後は、必要に応じて一時的に作成した全体管理者アカウントを削除するなりすれば問題なく利用できます。
先月より本格的に日本でも開始されたOffice365のバージョンアップですが、その裏側でどんなことが行われているかについて少し調べてみたいと思います。
ご存じの通り、Exchangeは管理者のコマンド（参照以外）実施は「管理者監査ログ」を見ることにより調べることができますので、早速バージョンアップしたテナントの管理者監査ログを取り寄せてみます。
管理者監査ログは、Exchange管理センターの[コンプライアンス管理][監査]のメニューから[管理者監査ログのエクスポート]を選択します。アップグレードを含む適切な期間と、結果を受領するメールボックスを選択して[エクスポートを]選択します。通常、数時間待つとメールで管理者監査ログが届きます。
管理者監査ログは、XMLファイルの形式です。1つ1つのイベントは、<Event Caller=…>で始まり、</Event>で終わります。
アップグレードが実施された時間帯を元に探すと、”NT AUTHORITYSYSTEM (Microsoft.Exchange.ServiceHost)”からの命令で実施されている一連のコマンドが表示されます。ほとんどが、Set-MailboxPlan、Set-CASMailboxPlanなどのユーザーに開放されていないコマンドレットやInstall-GlobalSettingsContainer、Install-DataClassificationConfigなどのアップグレード用に作成されたであろう特別なコマンドレットになっています。
ここで、以前の投稿で紹介したアップグレードコマンドの実行により一部の設定がデフォルト値に戻ってしまうという現象が再現していないかについて検証してみたいと思います。以前の物はマイナーバージョンアップによる物で、その後の更新によりこちらは設定が保持されるようになりました。が、今回は残念ながら以前紹介した3つのパラメータ
| Set-RemoteDomain | AutoForwardEnabled | True |
| AutoReplyEnabled | True | |
| Set-OrganizationConfig | MailTipsLargeAudienceThreshold | 25 |
については元に戻ってしまうようです。
また、当然と言えば当然なのですが、このタイミングでSet-OwaMailboxPolicyでPublicFoldersEnabledがTrueになってたりなどもしてます。
Exchangeをお分かりの方で、何かUpgrade後に挙動がおかしいと思った場合には管理者監査ログを調べられるのも良いかもしれませんね。