Author Archives: genkiw

ソフトマッチについて試してみた

Posted on by • Posted in Office365, Work, シングルサインオンとディレクトリ同期 • 1 Comment

「ソフトマッチ」と聞いても、なかなかピンとこない方も多いのでは無いかと思います。これは、
先にOffice365にメールボックスが作成されているクラウドIDのアカウントに対して、後からオンプレミスのActive Directoryの同期アカウントとして紐付ける
手法です。

非サポートの手法と言われていて、仕様がいつ変わるかも分からない物だったのですが、どうやらそろそろ正式にサポートされるかも…という話を聞いたので少し検証してみます。

まず、ディレクトリ同期について、通常のフローで言うと以下の様なデータの流れになります。

  1. オンプレミスのActive Directoryのアカウント情報がディレクトリ同期によってOffice365のADに同期アカウントとして作成される。同期アカウントはOffice365側では編集不可。
  2. Office365側では、独自に作成したオンプレとは非同期のアカウントも作成可能。
  3. Exchange Onlineのサブスクリプションを付与することにより、メールボックスが作成される。
    ※Exchange Online側で先に作成されてOffice365に同期されるパターンも有り

この時、Office365上では同期アカウントと非同期アカウントがありますが、それぞれの区分を変更したりすることはできません。同期アカウントに対してはSourceAnchor（オンプレのオブジェクトのGUIDから生成）という値が保持され、これがあるかどうかで同期アカウントか判断されます。またこれにより、ディレクトリ同期サーバを再インストールしても連携が保持されます。

ここで、ケースによっては、ディレクトリ同期ツールでアカウントを作成するのが難しいことがあります。例えば、

  • 移行に合わせてフォレスト統合を行う必要があるが、Office365の利用希望日に間に合わなく先にクラウドIDを利用して開通させたい。また、統合後はメールボックスは保持したまま移行したい。
  • Office365を利用開始後、パスワード管理やアクセス制御などの問題でADFS導入を行いたい。
  • ディレクトリ同期されたアカウントのメールボックスの復活を行い、再び同期アカウントに紐付けたい。（削除済みメールボックスの回復は、非同期アカウントの新規作成と合わせた紐付けとなる）
  • BPOSの移行されてきたメールボックスをADFS環境で利用したい。

などです。最後の項目があるのでサポートせざるを得ないだろうという話なんでしょうね。ここで解決法として登場してくるのがソフトマッチです。（※ちなみに、上記で記載したSourceAnchorによるマッチングは「ハードマッチ」と呼ばれます。）

ディレクトリ同期ツールからしてみると、新規でアカウントを作成しようとしますが、Office365側のアカウント作成プロセスにおいて条件をチェックし、「新規作成」から「変更（SourceAnchor含む）」に勝手に変更してくれるという形になります。

つまり、先にディレクトリ同期されてOffice365側に対応する同期アカウントが出来ていて、後から属性の変更などで条件を満たすようになったとしても、このマッチングは行われません。（というか、属性の一意性エラーで同期ツールによる変更が実施されません。）

ここでの特定条件のマッチングですが、以前はUPNとメールアドレスの完全一致とか言われてましたが、どうやら今はメールアドレスだけで判定されているという話なので、いくつかパターン見て調べてみます。

  1. UserPrincipalName、mail、ProxyAddresses（SMTP:で始まるプライマリ）が完全一致…OK
  2. UserPrincipalName、ProxyAddresses（SMTP）が完全一致…OK
  3. mail、ProxyAddresses（SMTP）が完全一致…OK
  4. ProxyAddresses（SMTP）が完全一致…OK
  5. ProxyAddresses（smtp）がOffice365側の追加アドレスに一致（smtp:で始まる）…OK
  6. mailがOffice365側のプライマリアドレスに一致…OK
  7. mailがOffice365側の追加アドレスに一致…OK
  8. 一度同期されたオブジェクトを Explicit Disconnector にする手法を使ってOffice365から消して、mail属性を追加アドレスと一致させてから再同期…OK

Office365側に作成済みのアカウントのメールアドレス（mail、ProxyAddresses(SMTP:)、ProxyAddresses(smtp:)）のいずれか1つでも等しいADのオブジェクトが、ディレクトリ同期でOffice365側に同期され、アカウントの新規作成が実施されようとした際にソフトマッチが行われるようです。

ただ、1点注意事項。8番で実験しましたが、一度ソフトマッチに失敗しても、オンプレ側のADを削除することなくリカバリをすることは可能です。逆に、一度でもソフトマッチで同期オブジェクトになってしまった場合は元には戻せません。Office365側にオンプレと同じsourceAnchorが付与されて、ハードマッチの状態になってしまうからです。（まあ、SR上げて気長に1週間くらい待てば可能かもですが）

一度同期されればハードマッチ状態になりますので、気を遣わなくてはいけないのは一度だけです。また、現時点ではいつ仕様が変わるか分からないので、直前に検証（仕様が変わっていないか）は必要かと思いますが、上手く使いこなせれば展開方法の柔軟性が格段に増すかと思います。

簡単に手順を記載します。同期アカウント（contoso-jp.com）と非同期アカウント（fabrikam-jp.com）の混在環境が合ったとします。

ここで、fabrikam-jp.comのユーザがcontoso-jp.comへのフォレスト統合が完了したとして、contoso-jpのアカウントを保持したと仮定します。

ここで、ディレクトリ同期が走る前に電子メール（mail）属性をマッチングさせたいOffice365側のメールアドレスと一致させます。

手動同期を実施すると、

ソフトマッチによりfabrikam01のアカウントが同期アカウントに変更されます。

ここで注意点ですが、シングルサインオン（ADFS）として構成している場合は問題ないのですが、ディレクトリ同期のみで実装している場合、ユーザのログオンアカウント名（UserPrincipalName）についてはオンプレミスでの変更はOffice365側に同期されません。整合性を取るため、mail属性だけではなく、UPN名についても一致した状態でソフトマッチさせることを推奨いたします。

上記例の場合は、先にOffice365側でfabrikam01@fabrikam-jp.comからfabrikam01@contoso-jp.comにユーザ名を変更してからソフトマッチするということになります。。

今後のMicrosoft側の発表についても、ウォッチしたいと思います。

64bit版ディレクトリ同期ツールを触ってみた

Posted on by • Posted in Office365, Work, シングルサインオンとディレクトリ同期 • 1 Comment

64bit版のディレクトリ同期ツールを軽く触ってみました。

まず、一番試したかったこと、ADFS2.0との同居です。今までは、32bit版の動作環境を確保するために3時間に1回しか動作しないOSを1個立てなければならなかったですが、可能なら構成する台数が1台減ります。

結論から言うと、ディレクトリ同期ツールインストール→ADFS2.0インストール、ならびにADFS2.0インストール→ディレクトリ同期ツールインストールのどちらの順番でも共存可能でした。

ADFS自身もかなり負荷は少ないので、数百人クラスのユーザーであれば、MSの推奨構成とは異なりますが

①(新規)ADFS 2.0+ディレクトリ同期を追加する。
②(既存)ドメインコントローラの1台にADFS2.0を追加する。
③(新設)ADFS Proxy。※外部からのアクセスまたはOutlookなどのOWA以外のメーラーを利用する場合

辺りで十分でしょうか。

続いて、同期間隔の調整について。こちらは同じ設定ファイルが有るので、同じように書き換えたところ問題なく動作しました。

C:Program FilesMicrosoft Online Directory SyncMicrosoft.Online.DirSync.Scheduler.exe.Config

PowerShellが2.0になったので、リモートから接続して手動同期掛けられるようにしたいと思います。

ディレクトリ同期サーバ側

Enable-PSRemoting

操作サーバ側（同一ドメインから、ログインしてる管理者アカウントで接続）

Enter-PSSession -Computername servername.contoso.com
Add-PSSnapin Coexistence-Configuration
Start-OnlineCoexistenceSync

その他の操作感とかもほぼ一緒ですね。折角なのでPowerShell使ったり色々といじってみたいです。

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

Posted on by • Posted in Office365, Work, シングルサインオンとディレクトリ同期 • 1 Comment

待望の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版の時にできていた各種オペレーションやカスタマイズ可否を確認してみたいと思います。

デバイスの「場所」情報に基づくNICのリネーム

Posted on by • Posted in Windows 2008 R2 • Leave a comment

Windowsは、接続されているNICに「ローカル エリア接続 xx」という名前を付けて管理をしますが、この名前付けはランダムであり、同じ構成のマシンを同時にインストールしてても違う名前が付いたりします。

　

通常は、インストール中に接続されている物理ポートに応じて名前を付けたり並び替えたりするのですが、複数のNICを有しているサーバ機では結構その作業が面倒です。Linuxの様にMACアドレスで特定するにも、インストール前に特定するのは難しいです。そこで、PCIバスの番号や機能などによりポートを特定して並び替えるPowerShellスクリプトを作ってみました。（実行には管理者権限で実行する必要があります）

function rename-nic($i, $j ,$k ,$x) {
    $newname = "$x"
    $location = "PCI bus $i, device $j, function $k"
    $location_jp = "PCI バス $i, デバイス $j, 機能 $k"
    $drvinfo = (Get-WmiObject Win32_PnPSignedDriver | Where-Object {$_.Location -eq $location -or $_.Location -eq $location_jp}).DeviceID
    $nic = Get-WmiObject Win32_NetworkAdapter | Where-Object {$_.PNPDeviceID -eq $drvinfo}
    $oldname = $nic.NetConnectionID
    if ($oldname -eq "$newname") {
        write-host "既に指定された名前になっています"
    }
    elseif ($newname -eq '') {
        write-host "新しい名前を指定して下さい"
    }
    elseif ($oldname -eq '') {
        write-host "指定されたバスにNICが見つかりません"
    }
    else {
        write-host "NIC名変更: $oldname => $newname"
        $nic.NetConnectionID = $newname
        $nic.Put()
    }
}

$model = (Get-WmiObject Win32_ComputerSystem).Model

if ($model -eq "PRIMERGY RX200 S6             ") {
    write-host "Fujitsu PRIMERGY RX200 S6のNIC名を変更を実行します"
    rename-nic "1" "0" "0" "ローカルエリア接続1"
    rename-nic "1" "0" "1" "ローカルエリア接続2"
    rename-nic "4" "0" "0" "ローカルエリア接続3"
    rename-nic "4" "0" "1" "ローカルエリア接続4"
    rename-nic "4" "0" "2" "ローカルエリア接続5"
    rename-nic "4" "0" "3" "ローカルエリア接続6"
    rename-nic "3" "0" "3" "ローカルエリア接続7"
    rename-nic "3" "0" "2" "ローカルエリア接続8"
    rename-nic "3" "0" "1" "ローカルエリア接続9"
    rename-nic "3" "0" "0" "ローカルエリア接続10"
}

サンプルとして、富士通の1UサーバにQUADポートの増設NICを2枚刺した物をベースに作りました。（PCIバスの3番と4番は片方がLPになっていて指す方向が逆なので機能番号が逆順になっています）

各マシンやNICごとに、rename-nic関数の引数を変えて行けば使い回しできそうですね。

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

Posted on by • Posted in Exchange Online, Work, シングルサインオンとディレクトリ同期 • 1 Comment

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移行の際の注意点

Posted on by • Posted in Exchange Online, シングルサインオンとディレクトリ同期 • Leave a comment

オンプレミスの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)

Posted on by • Posted in Exchange Online, シングルサインオンとディレクトリ同期 • Leave a comment

以前の投稿 で書きましたが、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オフロード環境で利用する

Posted on by • Posted in Office365, Work, シングルサインオンとディレクトリ同期 • Leave a comment

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でのメール転送

Posted on by • Posted in Exchange Online, Work • Tagged • Leave a comment

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）

Posted on by • Posted in Exchange Online, Work, シングルサインオンとディレクトリ同期 • Leave a comment

以前 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できます。