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アドレスのリストなどが精査されて直ることを期待してますが、動作原理を知っているのといないのでは有事の際に対応にも差が出るかと思いますので、細かいことですがここでご紹介させて頂きました。
なお、この記事は一部検証結果に基づいた個人的な推察を交えて記載しておりますので、もし事実に反することや、既に解消されたということが書かれていた場合は訂正させて頂きますので、連絡を頂ければと思います。
