Exchangeの一部設定は定期的に見直しましょう

※2013.1追記 Office365のUpgradeプロセス見直しにより、各テナントのパラメータが保持されるようになったようです。よって、以下の問題は発生しないものと思われます。

Office365は、Exchange2010をベースとして開発されておりますが、クラウドサービス向けにデフォルトの設定値とは少しパラメータを変更して提供されております。

ところが、クラウドサービスの性質上、定期的にバージョンアップや仕様変更(例えば、メールボックス容量の増加)などを実装する場合があり、この際にExchangeデフォルト値→Office365デフォルト値に変更をするというスクリプトが実行されています(サーバの設定値がソフトウェアデフォルトに戻ってしまわないようにだと思われますが、)。

通常であればあまり問題は無いのですが、ユーザー側でも設定変更が可能なパラメーターが少数ながら存在し、その値をユーザーサイドでカスタマイズして利用している場合は、定期的に変更していないか確認をして設定変更する必要があります。

私の確認した範囲で、上書きされる可能性の有るパラメータは以下2コマンドの3パラメータです。

Set-RemoteDomain AutoForwardEnabled True
AutoReplyEnabled True
Set-OrganizationConfig MailTipsLargeAudienceThreshold 25

特に、前者はセキュリティ上の理由で外部転送を拒否していると思われますので、定期的に確認をして設定が戻っていないかを調査するのが望ましいと思われます。

なお、この変更は私のテナントだと2011/8、2011/11、2012/6の3回実施されております。実施されたかどうか、どういったコマンドが実行されたかは管理者監査ログを取得することにより、確認をすることができます。通常は利用することができない Administrator w3wp などの特権アカウントでメンテナンスは実行されますので、それと合わせることにより確認がしやすいかと思います。

実行されている詳細なコマンドは以下の通りです。

Set-OrganizationFlags 影響なし
Set-TenantObjectVersion 影響なし
Set-PerimeterConfig DomainController “” 影響なし
Identity apcprd03.prod.outlook.com
/Microsoft Exchange Hosted
Organizations/contoso.onmicrosoft.com
EhfConfigSyncEnabled True
RouteOutboundViaEhfEnabled True
SyncToHotmailEnabled False
EhfAdminAccountSyncEnabled False
HygieneSuite Standard
Set-TransportConfig DomainController “” 影響なし
Identity contoso.onmicrosoft.com
UseServicePlanAsCounterInstanceName True
OrganizationFederatedMailbox FederatedEmail.xxxxxx
@contoso.onmicrosoft.com
SupervisionTags Reject;Allow
Set-MailboxPlan DomainController “” 影響なし
Identity apcprd03.prod.outlook.com/
Microsoft Exchange Hosted
Organizations/contoso.onmicrosoft.com
/Default-xxxxx
QueryBaseDNRestrictionEnabled False
RecipientLimits 500
MaxSendSize 35 MB (36,700,160 bytes)
MaxReceiveSize 36 MB (37,748,736 bytes)
ResetPasswordOnNextLogon False
SingleItemRecoveryEnabled True
EwsEnabled True
ActiveSyncEnabled True
MAPIEnabled True
MAPIBlockOutlookNonCachedMode True
HiddenFromAddressListsEnabled False
UseDatabaseRetentionDefaults False
RecoverableItemsQuota 30 GB (32,212,254,720 bytes)
RecoverableItemsWarningQuota 20 GB (21,474,836,480 bytes)
Set-CASMailboxPlan 影響なし
Set-RemoteDomain Identity contoso.onmicrosoft.com 影響あり
AutoForwardEnabled True
AutoReplyEnabled True
Set-OrganizationConfig DomainController “” 影響あり
Identity contoso.onmicrosoft.com
MailTipsGroupMetricsEnabled True
MailTipsMailboxSourcedTipsEnabled True
MailTipsAllTipsEnabled True
MailTipsLargeAudienceThreshold 25
Set-Mailbox Identity apcprd03.prod.outlook.com
/Microsoft Exchange Hosted
Organizations/contoso.
onmicrosoft.com/FederatedEmail.xxxxx
影響なし
SCLQuarantineEnabled False
Force True
Arbitration True
ProhibitSendQuota 10 GB (10,737,418,240 bytes)
RecoverableItemsQuota 30 GB (32,212,254,720 bytes)
SCLDeleteEnabled False
UseDatabaseQuotaDefaults False
SCLRejectEnabled False
DisplayName Microsoft Exchange
RecoverableItemsWarningQuota 20 GB (21,474,836,480 bytes)
IssueWarningQuota 9 GB (9,663,676,416 bytes)
ProhibitSendReceiveQuota 10 GB (10,737,418,240 bytes)
HiddenFromAddressListsEnabled True
SCLJunkEnabled False
New-ApprovalApplication 影響なし
New-ApprovalApplicationContainer 影響なし
install-Container 影響なし
Install-ActiveSyncDeviceClassContainer 影響なし
Set-MServSyncConfigFlags 影響なし
Set-Organization 影響なし
Install-FederationContainer 影響なし
New-MicrosoftExchangeRecipient 影響なし
Install-InternetMessageFormat 影響なし
Install-GlobalSettingsContainer 影響なし
Install-EmailAddressPolicy 影響なし
install-PerimeterConfigContainer 影響なし
install-TransportConfigContainer 影響なし
Install-GlobalAddressLists 影響なし
Set-ManagementSiteLink 影響なし

期間限定訴訟ホールドをPowerShellから設定

期間限定訴訟ホールドとは、単一アイテムの回復期限(各メールボックスの削除済みアイテムを復活できる期間:デフォルト14日)を延長することにより、特定のメールボックスにおいて一定期間情報を保全する機能です。

こちらの期限の延長は、30日までであれば通常のExchange Onlineプラン1などでも実施することはできたのですが、利用しようと思うと従来は都度サービスリクエスト(SR)を上げて設定して貰う必要があり、かつメールボックス単位で設定を入れる必要があるので、全メールボックスで期間を30日にするなどの処理は非常に大変でした。

今年に入ってからのサービスの改善で、30日以内の変更であれば、この処理をPowerShellから管理者が実行できるようになりました。コマンドは、PowerShellでExchange Onlineに接続した後に、

 Set-Mailbox -Identity [対象] -RetainDeletedItemsFor [保存期間]

です。例によって、-Identityは省略不可です。また、保存期間は DD.HH:MM:SS形式(例えば30日は30.00:00:00)ですが、省略してDDのみ(30とだけ入力すれば30日と解釈)でも可能です。また、この-RetainDeletedItemsForはTab補完ができませんが、パラメーターとしては存在するので頑張って入力しましょう。

また、31日以上にする場合は、Exchange Onlineのプラン2以上のライセンスが必要になり、かつコマンドからも設定はできませんので、従来通りSRを上げて対応しましょう。

こちらは、特に追加費用無く設定することができますので、標準でデプロイする際に設定しても損は無いかもしれません。

Windows8 RPからOffice365に接続する

Windows 8 Release PreviewとWindows Server 2012 Release Candidateが出ました。世間では皆さんインストールして色々試されているみたいですので、私も少し触ってみます。

Windows 8から大きく変わった点としては、スマホやタブレットなどの環境を意識した作りになっており、メール・カレンダーが標準で入っていてActive Syncに対応しているという点になります。

スタートメニューでメールを選択します。

Exchange Onlineのアカウント(メールアドレスとパスワード)を入力すると、Autodiscoverで自動的に接続されます。メールアドレスとログオンユーザ名が違う場合は、ログオンユーザ名が聞かれます。

ちなみにADFSのシングルサインオン環境のアカウントでも特に問題なく利用できます(ActiveSyncの場合はクライアントから見た場合の差は無いですから当然と言えば当然ですが)

アカウントが追加され、Active Syncポリシーに従ってセキュリティ保護を強化するかどうかのダイアログが表示されますので、「これらのポリシーを適用する」を選択します。

以上の作業で、メール・予定表・連絡先が同期されるようになります。デフォルトでは、過去2週間分のデータがプッシュ通知で受信されますので、設定を変更したい場合は「設定」の「アカウント」から変更します。

ちなみに、Exchangeから見た場合は、以下の様なActiveSyncデバイスからアクセスが来たと認識されております。「デバイス名:WIN8RP」「デバイスのモデル:Windows PC」「デバイスの種類:WindowsMail」

Exchange ActiveSyncですので、リモートワイプを行うこともできます。スマートフォンとは違い、Exchangeから同期したアカウントの設定・コンテンツのみが消されるという形になりますので、運用上は比較的使いやすいかもしれません。

また、ADFS環境の場合、Exchange OnlineからADFS(ADFS Proxy)に渡されてくるクレーム情報は以下の感じです。プロトコルはMicrosoft.Exchange.ActiveSync、User AgentはWindowsMail/16.4.3364.0511です。

IPアドレスが、アクセス元のIPではなくExchange OnlineになっているのはCASとMBXのDCが分かれた場合に出るという症状でしょうか? POP/IMAPではたまに出るアカウントとかありましたが、ActiveSyncで出たのは始めてなのでちょっと調べてます。

ただ、あくまでActiveSyncプロトコルを利用しておりますので、余りに長い期間のコンテンツを同期対象としてしまうと動作が非常に遅くなってしまいますので、メインで利用するのはOutlookもしくはOWAとして、モバイル端末に設定して補完するような用途とした方が好ましいかと思います。

ただ、OWAと違ってわざわざブラウザのウィンドゥを立ち上げておかなくても、バックグラウンドでプッシュ通知で自動的に更新が反映されますし、モバイル用途には非常に向いているように見えます。上手く使い分けできると良いかもしれませんね。

【参照】
Windows 8 での Office 365 ベース電子メール アカウントの構成(公式Wiki)
Windows 8 Consumer Preview + Exchange Online を使用したデバイスの管理(SEの雑記さん)

Exchange OnlineへのSP2適用

昨年末から6ヶ月間かけて展開が計画されていたExchange Onlineサービスですが、概ねゴールデンウィーク前後に終了したようです。(OWAの接続先がsin,hknではなくsix,hkxで始まるサイト名になっていることで確認ができます。)

大々的には出してはいませんが、この更新によってSP1ベースがSP2ベースに変わっているようです。これに伴い、一部挙動が変更されている機能がありますので紹介します。

  1. メールボックスの自動マッピング機能の制御が可能に
    • 従来は、Outlookから接続した場合、Full Controlアクセス権限を有する全てのメールボックスに対しても自動的に接続されておりました。多くのメールボックスにFull Control権限を持つユーザの場合、処理に時間が掛かることがありましたが、Add-MailboxPermissionコマンドレットに新しく追加されたAutoMappingオプションによりこれを制御することができるようになりました。
  2. 訴訟ホールド対象のメールボックスに対する操作の扱いが変更に
    • 訴訟ホールドが有効化されているメールボックスは、普通の操作では無効化/削除ができなくなりました。これを回避するには、事前に訴訟ホールドを無効化するか、Remove-Mailboxコマンドレットなどに追加されたIgnoreLegalHoldオプションを利用する必要があります。

フューチャーフォンからのアクセスが可能になるOWA mini(OwaMailboxPolicy上は一応有効化されてますけど)とかGAL分割とかに活用できそうなアドレス帳ポリシーとかは残念ながら提供されていないのですかね。

Exchange 2010 SP2 の新機能

Exchange OnlineのGALに何も表示されない

Office365のExchange Onlineを利用する場合、ネットワーク的に離れているということもあり、キャッシュモードでの利用が推奨され、アドレス帳もオフラインアドレス帳を利用するのが一般的かと思います。ただし、オフラインアドレス帳の更新は1日1回であり、その時間もサービス仕様としては定められておりませんので、環境によってはグローバルアドレス一覧を直接利用したいというニーズもあるかと思います。

今回は、グローバルアドレス一覧を開いた際に発生する事象について紹介したいと思います。まず、アドレス帳を開いて、「グローバルアドレス一覧」をリストから選びます。

すると、通常はアドレス一覧が表示されているはずなのに何も表示されていない状態となります。

一見すると、グローバルアドレス一覧に接続できていないように見えますが、実際は「その他のフィールド」のラジオボタンにチェックを入れて検索を行うと、検索することが可能です。

この事象ですが、MicrosoftのKBも出ており対策用のFixITも出ているのですが、要約しますと『日本語版のOutlook2007/2010はふりがなによるソートがデフォルトの「名前のみ」の状態で有効になっているが、接続先のExchangeのCASが日本語で無い場合、ふりがなによるインデックス化が行われない為、何も表示されない』ということのようです。(「名前のみ」を解除し、ふりがな以外で検索することは可能)

Outlook 2007 または Outlook 2010 で、Exchange Server 2007 または Exchange Server 2010 の GAL の検索結果が正しく表示されない

オンプレミスの環境であればいかようにでも対策は取れますが、残念ながらOffice365はマルチテナントのサーバであり、かつ日本語以外の環境のテナントも数多く収容されているマルチリンガルなサーバーですので、改修(システム言語を日本語に…)というのは難しい気がします。

という訳で、解決法は大きく2つ

  1. オフラインアドレス帳を普段は利用し、グローバルアドレス一覧は最新の情報を検索する場合にのみ利用する
  2. Outlookを英語版と同じ環境(ふりがなが有効化されていない設定)に変える

という形となります。後者に関しては、Fix ITが出てます。手動でやる場合は、HKEY_CURRENT_USERSoftwareMicrosoftExchangeExchange Provider に DisableGALPhoneticをDWORDで作成し「1」を設定します。

これにより、グローバルアドレス一覧を開いた際にもデフォルトでユーザー一覧が表示されるようになります。(ふりがなの欄は消えてしまいますが)

 

P.S.ちなみに、ふりがな自体はPowerShellのSet-Userコマンドレットで投入することは可能です。

Exchange Online送信時のアドレス表記について

Exchange Onlineでは、Fromのメールアドレスが 表示名 <username@domain.name> の形式でアドレスが表示され、これを自由に変更することはできません。(※SMTP接続で送信している場合のみ、メーラーで設定された形式で表示されます。)

グローバルに展開する企業など、Fromに日本語の文字が混じってしまうことを好ましく思われない場合もございますので、今回はこれをカスタマイズする方法を紹介します。

Exchangeには、マルチバイトが格納可能な表示名(DisplayName)の他に、ASCII文字しか入力できない簡易表示名(SimpleDisplayName)という領域が用意されています。ここに適切な値を入力し、外部送出時にこの値をセットするように設定することで、要件を満たすことができます。

こちらの処理は、GUIでは用意されていませんので、PowerShellから実施する必要があります。Exchange Onlineに接続後にSet-UserコマンドとSet-RemoteDomainコマンドで設定を行ないます。今回は、以下の条件を設定してみます。

  1. admin(表示名は管理者)に「administrator」という簡易表示名を設定する
  2. 外部の全ドメインに送信する際に簡易表示名を利用する
Set-User admin -SimpleDisplayName administrator
Set-RemoteDomain default -UseSimpleDisplayName $true

以前は 管理者 <admin@xxxx.onmicrosoft.com> と表示されていた物が、無事 administrator <admin@xxxxx.onmicrosoft.com> と表示されるようになりました。

ちなみに、この設定の影響を受けるのは外部への配信のみになりますので、内部での配送は今までどおりの 表示名 <username@domain.name>  の形式で行なわれます。

Exchange Onlineで転送専用のエイリアスを作成する

Office365で、メールボックスは持たないけど、あるメールアドレス宛のメールを受信したい場合があります。

例えば、

  • ある商品キャンペーンの受付専用でアドレスを持ちたい
  • 問い合わせ窓口などで利用する共有のアドレスを持ちたい
  • 普段はOffice365のメールボックスは利用していないユーザーが、Office365に登録しているメールドメインのアドレスを利用したい

などの場合です。この場合、それを割り当てる先のユーザに応じて、

  • 内部の特定ユーザの場合 ⇒ そのユーザーの電子セカンダリアドレスとして追加する
  • 内部(外部を含めることも可)の複数ユーザーの場合 ⇒ 配布グループを利用する、外部のユーザーに対しては外部の連絡先に追加する

などを利用することもできますが、今回はメールユーザー(メールが有効なユーザー)を作成して、外部からのメールを受け付けて外部に転送することができるアカウントを作成してみたいと思います。

受信するアドレス:forward@example.com
ユーザー名   :forward
パスワード   :P@ssw0rd
転送するアドレス:user01@contoso.com

メールユーザーの作成は、PowerShellからのみ実施することができます。

$LiveCred = Get-Credential (管理者IDとパスワードを入力)
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell/ -Credential $LiveCred -Authentication Basic -AllowRedirection
Import-PSSession $Session

として、Exchange Onlineに接続して以下のコマンドを実行します。

New-MailUser -Name forward -MicrosoftOnlineServicesID forward@example.com -Password (ConvertTo-SecureString -String 'P@ssw0rd' -AsPlainText -Force) -ExternalEmailAddress user01@contoso.com

これで、forward@example.com宛に来たメールはuser01@contoso.comに転送されるようになります。

更に、管理者が、Office365ポータルからforward@example.comにサブスクリプションを与えれば、今回指定したID/PASSを利用してSharePoint Onlineに接続することができるようになります。

残念ながら、ポータルで作成した既存のメールボックスが有効で無いユーザの外部メールを有効化するという-UseExistingMicrosoftOnlineServicesIDというコマンドのオプションは現在実装されていないようですので、上記のような利用法をされたいユーザはポータルからではなく、Exchange Online側から作成をする必要があるようです。

また、1点注意事項ですが、今回のメールユーザーでは、外部のアドレス(今回の場合はuser01@contoso.com)を受信可能なアドレスであるProxyAddressesとして保持をしますので、他のキャンペーンのアドレス、例えばcampaign@example.comのアドレスもuser01@contoso.comに転送を行いたいという場合は、新たにメールユーザを作成するのではなく、既存のメールユーザーに内部アドレスを追加するというオペレーションになります。以下、コマンド例です。

Set-MailUser -Identity forward -EmailAddresses "SMTP:user01@contoso.com","smtp:forward@example.com","smtp:campaign@example.com"

(参考)メール ユーザーの作成
http://technet.microsoft.com/ja-jp/exchangelabshelp/dd207277

BlackBerry Business Cloud Servicesリリース

正式リリースから少し時間が経ってしまいましたが、BlackBerryでOffice365を利用するためのRIM社のサービスが、ようやく正式リリースされましたので、早速設定してみました。

まず、管理者権限でOffice365のポータルにログインし、右側のリソースメニュー中の【携帯電話の電子メールを設定する】を選択し、【BlackBerry Business Cloud servicesの有効化】をクリックします。
 

その後、サービスに関する情報が表示されますので、確認後「はい」にチェックを入れ、OKをクリックすると、管理者トップメニューが変更になり、下部にBlackBerry Business Cloud Servicesのメニューが表示されるようになります。【管理】をクリックして、BlackBerry Business Cloud Servicesのセットアップに移ります。
 

【今すぐサインアップ】を選択し、言語を選択すると、ソフトウェア使用許諾が表示されますので、最後まで確認した後に、同意するにチェックを入れ【続行】をクリックします。
   

これで、BlackBerry Administration Serviceにログインできるようになります。

※この時点で、自動的にBlackBerryを利用するユーザのグループと、システムアカウントへのExchange管理権限が設定されるとのことですが、うまく動作していないように見える場合は、KB28963(RIM)を参照頂き、手動で設定を確認ください。私の検証環境だと試験したタイミングが早すぎたのかもしれませんが、New-ManagementRoleAssignmentの手動実施が必要でした。

ユーザがBlackBerryを利用するには、①ユーザの登録 ②アクティベーション(端末への紐付け)が必要です。設定方法は、上記の管理画面から、【ユーザーを作成】で実施します。Exchange OnlineのGALに対して検索をかけて、そこから登録が可能です。
 

通常、ユーザーは、ユーザIDとアクティベーションパスワードを利用して端末を紐付けします。ここでは、「①管理者が指定したパスワードを設定」「②ランダムパスワードを設定し、メールで送信」「③パスワードなしで作成」が有ります。セキュリティの問題から①か②が、良いと思われます。

検証したところ、作成されたアクティベーションパスワードを利用して実際にアクティベーションができるようになるまで15~30分程度かかることがございました。また、5回失敗するとそのアカウントはロックされます。

このため、上記②でユーザに直接パスワードを飛ばしてしまうと、ユーザが届いたメールを見てすぐに登録を試行→アカウントロック→管理者がパスワードリセットが必要という流れになる可能性がございます。
→可能であれば①で管理者が指定し、1時間程度待ってからユーザに告知というのを推奨します。

小規模な組織であればパスワードを利用するのではなく、この管理画面を表示させているシステム管理者のPCにUSBでBlackBerryを接続してアクティベーションするというのが確実かもしれません。

この作業により、BlackbBerry端末からメール・予定表・連絡帳について利用出来るようになります。また、管理者サイトからExchange ActiveSyncのデバイス(Android等)同様にパスワード強制などのポリシー、リモートワイプがかけられます。その他には、「パスワードを変更してロック」「会社用のデータのみリモートワイプ」という細かい選択が可能です。

また、手順を見てお気づきの方もいらっしゃるかもしれませんが、端末はOffice365に接続するのにID/PASSは必要としません。細かい仕組みについては開示されてませんが、設定内容を見る限り、以下の様な流れで管理アカウントで代行取得をしている物と推察されます。

これに関しては善し悪しだと思うのですが、例えばADFS環境で利用している際に、ADFSやADの障害があってOutlookやOWAの認証が出来なくなったとしても、BlackBerry端末からはその影響を受けずに利用の継続が可能となっているという事かと認識してます。

ということで、他のスマートフォンとは認証プロセスと利用アカウントの運用の部分が異なるという特性を活かしつつ、上手く利用するのが良いかなと思います。

ExchangeOnlineの最大送受信サイズ

Exchange Onlineですが、サービス説明書によると送受信するメールの最大サイズは現在25MBとなっています。

ちなみに、この値ですが、βテストが終わってGAを迎える際、英語版のドキュメントのみ一時的に35MBに変わっておりました。(現在は25MBに戻っています)

ただ、PowerShellで調べてみると、現在最大送信サイズ=35MB、最大受信サイズ=36MBと設定されています。(以下でadminとtestuseroneが送受信20MBな理由は後述します。)

MicrosoftにSRで確認したところ、サービス説明書の値が正しく、誤っている物は今後(時期は未定だが)修正していく予定とのこと。

今回、送受信できるサイズについて色々調べていく中で、設定されている値について何となく自分的に納得できる理由が見つかりましたので紹介します。

まず、このサイズ通りに本当に送受信が可能かどうかを見てみます。Outlook2010を利用して、①自分宛 ②同テナント内の別ユーザ宛 ③他テナント宛てのユーザに送ってみます。

①自分 ②テナント内 ③テナント外
Outlook2010 25MB添付
Outlook2010 34.5MB添付 ×(FOPEでNDR)
Thunderbird 34.5MB添付 ×(送信エラー) ×(送信エラー) ×(送信エラー)

Outlook2010(MAPI)では、添付ファイルをエンコーディングしない形で送信をするので、34.5MBの添付ファイルを付けても送受信が可能です。

ただし、自テナント外に送信をしようとした場合、Exchange外部のFOPE(アンチスパム)に送信されますが、ここでエンコードされて35MBを突破してNGになるようです。

Thunderbird(IMAP/SMTP)の場合は、そもそもExchangeに接続しに行く際に自力でエンコーディングして飛ばしてきます(というか、MUAとしてはこちらの動作の方が一般的)ので、送信を試行した段階でエラーが出ます。

エンコード後35MBなので、エンコードで増える分(約+35%)を考えると、25.9MBくらいが閾値になりそうです。試しに30MBから1MBずつ添付ファイルのサイズを減らして行ったところ、26MBの添付ファイルは送信できず、25MBのファイルは送信できました。

という訳で、きっとサービス仕様としては明示してないですが、エンコード後でも25MBを確保できるように今の設定にしているのだと思われます。

ちなみに、受信サイズが+1MBされているのは、送信不可の際のエラーを受信できるようにするためでしょう。

さて、一番最初に出ていたadminとかtestuseroneというユーザーがなぜか送受信サイズが20MBになっています。これはどんなアカウントかというと、
 「βテスト当初からメールボックスが作成されていたアカウント」
言わば率先して人柱になってくれていたユーザーであり、通常は情報システム部などのアカウントがこれになっている事が多いと思います。

メールボックスを消して再作成(削除済みメールボックスの復活)すれば、新しい送受信サイズでデプロイされますが、半年分のメールを一度消すという行為と作成・再作成の間の受信のタイムラグでメールロストしてしまう可能性を考えると結構しびれますよね。

また、フェデレーションアカウントの場合は通常だとメールボックスの復活の対応も出来ないので、八方ふさがりになってしまいます。(SRを上げても送受信サイズの変更はサービスに至っていないと言われます。)

ということで、フェデレーションアカウントの場合の対応は次回以降の宿題ということで…

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");