ディレクトリ同期のオブジェクト上限値

Office365のディレクトリ同期ツールを利用すると、社内のActiveDirectoryの以下のオブジェクトをOffice365に(使用するしないに関わらず)同期してくれます。

こちらのMicrosoftのドキュメントをチェックすると、この同期のオブジェクト数には上限値が定められていて、それ以上はSRを上げて上限値を引き上げないといけないとあります。この閾値は20000と定められており、こちらはオンプレミスのAD上で「展開準備ツール(Deployment Rediness Tool)」を実行することにより、おおよその数値を知ることが可能です。

カウント対象となるのは以下のオブジェクトです。

  • ユーザー
  • グループ(配布グループ、セキュリティグループ)
  • 外部連絡先
【参考】ディレクトリ同期を準備する
http://onlinehelp.microsoft.com/ja-jp/Office365-enterprises/ff652544.aspx
社内ドメインのオブジェクトの合計数が 20,000 個を超えると、ディレクトリ同期をアクティブ化する前に Office 365 サポートに連絡する必要があります。

殆どのオブジェクトがオンプレミスで同期して利用している場合は問題にならないのですが、例えばExchangeの配布グループはOffice365側で作成(※セルフサービス型で利用したい為)など、ディレクトリ同期するオブジェクトの他に相当数のオブジェクトがクラウドID(非同期オブジェクト)で存在する場合、20000には達していないのに、以下の様なアラートが発生する場合があります。

Unable to add this user because the total number of allowed objects has already been reached.
 + FullyQualifiedErrorId : Microsoft.Online.Administration.Automation.Quota  
ExceededExcption.Microsoft.Online.ADministration.Automation.NewUser

試しに、数十個のオブジェクトだけディレクトリ同期した環境にひたすらオブジェクト(ユーザー)を作っていくと、確かに20000弱(今回の場合は19960個目)のオブジェクトで上記のエラーが出ます。

また、これが発生するとディレクトリ同期ツールからオンプレミスで新規でできたオブジェクトを追加することはできません。どうやら、20000というクォータは同期したオブジェクトの数ではなく、Office365上で作成したオブジェクトも含む数値のようです。

参考までに、これは一時的にではありますが突破することは可能です。

Exchange OnlineからGUIやCSV経由でユーザーを新規作成し、後からOffice365ポータルに同期してサブスクリプション割り当てなどという事を行うことができるのですが、こちらは上記の影響は受けないので作成→ポータルに同期が可能です。

新規で作成したオンプレミスのオブジェクトと同じメールアドレスを持たせて作成すれば、ソフトマッチで同期オブジェクトとすることも可能です。

皆様におかれましてはこうならないように、大規模環境の場合は、上記条件を考慮の上計画的にオブジェクト数を監視して、クォータ上限の引き上げを行って頂ければと思います。

[自習書] ADFSによるSSO環境構築で気になる点

人気の日本オリジナルコンテンツ、「AD FS によるシングルサインオン環境構築のステップバイステップガイド」の第2版が公開されました。いつもこの自習書シリーズは色々と参考にさせて頂いていて大変良いコンテンツです。

今回、ADFSの自習書の中で、いくつか自分で誤記であったり、自分で書くのであればこういった書き方ではなくこうするといったポイントがいくつかあるので、この中で簡単に纏めさせて頂きます。

「どっちが正しい」というよりは、あくまでそういった見方も有るという形でごらんを頂けると幸いです。

項番 自習書原文 気になるポイント
4.1 SQL Server 2005 Express Editionにて対応する手順を記載しております。 ※多分今はSQL Server 2008/2008R2 Express Editionに変更されているかと
4.2 Active Directory Federation Services 2.0 は、Windows Server 2008 または Windows
Server 2008 R2 で展開します。
※ADFS(非Proxy)の方は接続用のPowerShellの要件があるので余程の事情が無い限りはR2の方が良いと思います。
5.1 Microsoft Online Servicesディレクトリ同期ツール:
SQL Server 2005 Express
Identity Lifecycle Manager 2007
SQL Server 2008 ExpressまたはSQL Server 2008R2 Express
Identity Lifecycle Manager 2007またはForefront Identity Manager 2010
同期頻度:
初回の同期後は、3時間ごとに同期が行われます。またレプリケーション期間は構成できません。
レプリケーション間隔の変更はサポートされませんが、管理者が手動で同期することは可能です。
5.2 AD FSプロキシの展開:
ユーザーが会社のネットワークの外部から接続している場合に展開する必要があります。
ユーザーが会社のネットワークの外部から接続している場合、もしくはOWA以外からのメールクライアントからExchange Onlineに接続する必要がある場合に展開する必要があります。
8 各ツールの用意
ADFS01
 .NET Framework 3.5 SP1
 Microsoft Online Services Sign-In Assistantツール 不可 ※3

.NET Framework 3.5.1
※事前ダウンロード可能になりました。
Microsoft Online Services サインイン アシスタント (IDCRL7) – 32 ビット版
Microsoft Online Services サインイン アシスタント (IDCRL7) – 64 ビット版
9.2 ドメイン登録情報の変更
外部DNS上に以下のTXTレコードを追加しています。
“mskkonline.com MS=ms12345678”  ※数字部分はドメインによって異なります。
レコードということであれば、 “MS=ms12345678” か、あえて丁寧に言うのであれば “@ MS=ms12345678”
9.3 ドメインの所有確認
7. 再び、[ドメイン]に戻り、追加したドメインの状態が”アクティブ”になっていることを確認します。
7. 再び、[ドメイン]に戻り、追加したドメインの状態が”確認済み”になっていることを確認します。
表4下
SIPレコード(Lync Online)
SIPレコード、_sipfederationtls._tcpレコード(Lync Online)
10.1 UPNサフィックスの追加
AD と SMTP のドメイン名が異なる場合、UPNの設定が必要となります
ADのUPN名が自社が所有していないドメイン名やインターネットから引けないアドレス(????.localなど)の場合、代替UPNサフィックスの設定が必要となります
10.6 ディレクトリ同期の確認
“Microsoft Identity Integration Server”サービスの状態が以下のようになっていることを確認して下さい。
“Microsoft Identity Integration Server”サービスまたは”Forefront Identity Manager Syncronization Service”の状態が以下のようになっていることを確認して下さい。
11.1.3 SSL証明書の発行
また証明書の有効期間は1年間となりますので、必要に応じて、更新をご検討下さい。
また証明書には有効期間(例えば1年など)が定められておりますますので、必要に応じて、複数年度購入や更新をご検討下さい。
11.7 AD FSの冗長化
また、2台以上で構成する場合は、冗長化構成の為NLBの設定が必要です。
また、2台以上で構成する場合は、冗長化構成のためNLBの設定もしくはハードウェアLBが必要です。
11.9 Microsoft Online Services ID フェデレーション管理ツールのインストール Windows PowerShell 用 Microsoft Online Services モジュールに名称が変更されてます。
12.2 Hostsファイルの編集
※AD FSを複数台構成し、NLB(ネットワーク負荷分散)による冗長化を行った場合は、…
※ADFS ProxyはDMZに配置しますので、普通はNLBではなくHLB(ハードウェアLB)で冗長化します。
12.9 ポート要件
TCP 443
Outlook Web App
Lync 2010 client
※参照元のMSのドキュメントも誤ってますが、独自ドメインの場合はSSLによるAutodiscoverのプロセスがSSL証明書のCNの不一致で失敗し、HTTPにフェールオーバーして行われますので、TCP 80&443です。
13.3 アクセス制御
(表)
社内
デバイス OWA/Outlook
IP制限 ○
IP制限は社内でもOWA以外へのExchange Onlineからの要求のみしか行えません(たとえば、社内の特定の拠点のIPからのみOWAを利用させたいなど)
表で言うなら、社内は以下の通り。ただ、普通ActiveSyncはモバイルアクセスになるので、アクセス元のIP制御は実効上出来ないと思いますが…デバイス  OWA/SharePointOnline/LyncOnline    Outlook、ActiveSync、POP/IMAP
IP制限   △(ADFS Proxy経由かそうでないかのみ制御可能)  ○
14.1 認証失敗ログ(AD FS によって制御されたログ)
・アクセス元の IP アドレス
・アクセス プロトコル (RPC/HTTPS, POP/IMAP, ActiveSync など)
・アクセス アプリケーション (Outlook であればバージョンやエディション)
前の章でもそうですが、IP,Protocol,Agentを付与してくるのはExchange Onlineのみです。
Exchange Onlineの場合アクセス元の IP アドレス
Exchange Onlineの場合アクセス プロトコル (RPC/HTTPS, POP/IMAP, ActiveSync など)
Exchange Onlineの場合アクセス アプリケーション (Outlook であればバージョンやエディション)
14.2 認証成功ログ(AD FS によって認証されたログ) ※そもそも、14.3の工程を行い、「成功の監査」を記録できるようにしないとこのログは記録されません。

私自身の認識が間違っているなど有れば、コメントなどで連絡を頂ければ確認して適宜訂正をさせて頂きます。

ADFSで監査ログを取得する

Office365のシングルサインオンの為に利用されるADFSは、既定ではクレームルールでアクセスが拒否された場合、アプリケーションとサービスログ-ADFS2.0-Adminのイベントログにエラーレベルで「いつ・誰がアクセス拒否されたか」に続き、情報レベルで「そのユーザーの制御に用いた情報」が記録されます。(クレームのサイズに応じて複数に分割して表示されます)

これにより、不正なアクセス要求が無いかどうか、ならびに既存のクレームルールの不備は無いかということが判別することができます。クレームルールの検証・新規作成や監査目的など、要求が成功した場合でもこの記録を取りたいというケースが有りますので、今回はその取得方法について紹介します。

これを行うには、ADFSで監査ログを有効にする必要があります。

  1. まず、監査ログを生成できる権限をADFSのサービスアカウントが有しているかどうかを確認します。通常通りのウィザードで展開した場合は、有効になっているはずです。
  2. 次に、auditpol.exeで成功・失敗の監査を有効にします。ただし、KBなどに記載のコマンドをそのまま実行してもエラーが出ます。原因は、サブカテゴリ名が日本語になっているので、そこをコマンド内でも日本語にする必要があるからです。
    auditpol.exe /set /subcategory:”Application Generated” /failure:enable /success:enable

    auditpol.exe /set /subcategory:”生成されたアプリケーション” /failure:enable /success:enable
    参考:サブカテゴリ一覧の出力
    auditpol.exe /list /subcategory:*
  3. 最後に、ADFSの管理で取得するログの種類で成功の監査、失敗の監査を選択します。

これで、イベントログにADFS監査ログが記録されるようになります。

一件のアクセスで大量のログが吐かれますので、適宜ログサイズの確認ならびに最大ログサイズの設定などを行なってください。

ディレクトリ同期のセットアップエラー

最近、環境によってディレクトリ同期のセットアップが「Microsoft Online ServicesサインインアシスタントサービスのインストールによりFAILが返されました」というエラーで失敗するようになりました。

1638のエラーコードで調べても詳細が分からなかったので、状況から考えまてみます。

  • 2ヶ月前に同じ手順でインストールした際は出なかった。
  • サインインアシスタントは既にADFSのセットアップ時にインストールしている。

…バージョンがクサいですかね?

他のサーバからディレクトリ同意ツールのセットアップ時に自動インストールあれるバージョンは7250.4285.0ということがわかります。

対して、現在インストールされていたサインインアシスタントのバージョンを確認したところ7250.4287.0と少し新しい状態でした。というわけで、一度Micrsoft Online Services Sign-in Assistantをアンインストールしてから、再度ディレクトリ同期ツールをセットアップしたところ、無事インストール完了できました。

と言うわけで、Windows PowerShell 用 Microsoft Online Services モジュールやADFSなど、先にサインインアシスタントをインストールした場合はご注意頂ければと思います。(ちなみに、4285から4287はWindows Updateで表示されますが、インストール不要と出ます。)

ADFSアクセス制御でのOR条件

Office365のアクセス制御を行なうクレームルールですが、サンプルで記載されているルールを参考に実装をしていくと、少し記載が難しいルールがあることに気がつきます。

それは、ルールの中に「OR条件」を入れられないことです。

例えば、許可する条件が

  • ADFS Proxy経由ではない
  • Active Syncプロトコルによるアクセス
  • Exchange Onlineに接続するグローバルIPが①

を記載する場合、サンプルでは

  • 全てのユーザーを許可
  • 「Proxy経由のアクセス」かつ「プロトコルがActiveSync以外」かつ「Exchange Onlineへの接続元が①以外」のアクセスを拒否

という記述方法を取っています。

ここで、企業内で拠点ごとにインターネットを利用している場合など、IPアドレスの接続元が複数あることはよくあることです。

また、POP/IMAPのプロトコルをアクセス制御する場合、特定条件のユーザにおいて、IPアドレスの送信元がユーザのIP帯ではなくExchange OnlineのIP帯になってくるので、そちらも許可しないといけないという仕様もございます(当該ユーザのCAS/MBX収容のDCロケーションが分かれてしまった場合に発生するらしいです)。

この場合、上記例でいう許可したいIPが追加されて、「①」から「①または②」に変更しようとして

  • 全てのユーザーを許可
  • 「Proxy経由のアクセス」かつ「プロトコルがActiveSync以外」かつ「Exchange Onlineへの接続元が①または②以外を拒否」

という正規表現内でOR条件を記載した場合、エラーが出てしまい記述できません。

また、例えば許可ルールが

  • 社内からは許可
  • ActiveSyncの外部アクセスはActiveSync_External_Accessグループのメンバのみ許可
  • Outlookの外部アクセスはMAPI_External_Accessグループのメンバのみ許可

を記載しようとした場合、

  • 全てのユーザーを許可
  • 「ActiveSync」かつ「ActiveSync_External_Accessグループ以外のアクセス」または「プロトコルがMAPI」かつ「MAPI_External_Accessグループ以外のアクセス」は拒否

などを記載できれば良いのですが、「&&」は記載できますが「||」という条件のOR記述はできません。

ということで、こういった場合は最初の全許可のルールを削除して、複数個の許可ルールを記載することにより対応できます。今回は、例として以下のサンプルをADFSに登録してみたいと思います。

  1. イントラネットからのADFS Proxyを利用しないアクセスは許可
  2. ActiveSyncは許可
  3. xxx.xxx.xxx.xxxまたはyyy.yyy.yyy.yyyのIPからのアクセスは許可
  4. MAPI_External_Accessグループの外部からのOutlookアクセスは許可
  5. それ以外のアクセスは拒否

承認する為の条件はpermitのクレームが発行され、かつdenyのクレームが発行されていないということになります。また、permitのクレームが複数発行されても動作上は問題ありませんので、デフォルトのルール(全てのユーザーを許可)を削除し、新しく個別に特定条件下にのみpermitのクレームを発行するルールを作成してみることにします。

まず、4)の準備として既存のクレームルールをバックアップしておきます。また、セキュリティグループの制御用に渡されてくる情報はグループ名ではなくSIDなので、そちらも事前に調べておきます。

【ADFSサーバ:PowerShellから実行】

Add-PSSnapin Microsoft.Adfs.PowerShell
(Get-ADFSRelyingPartyTrust -Name "Microsoft Office 365 Identity Platform").IssuanceAuthorizationRules > c:adfs_claim.bak

【ドメインコントローラ:Windows PowerShell用のActive Directoryモジュールから実行】

(Get-ADGroup "MAPI_External_Access").SID.Value

-> S1-2-34-1234567890-1234567890-1234567890-123 であったと仮定します。

そして、ADFSサーバで、PowerShellで以下のコマンドを実行して

$NewRule = @"
@RuleName = "1) accept Internal access to Office365"
NOT exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy"])
 => issue(Type = "http://schemas.microsoft.com/authorization/claims/permit", Value = "true");

@RuleName = "2) accept Exchange ActiveSync access to Office365"
exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application", Value == "Microsoft.Exchange.ActiveSync"])
 => issue(Type = "http://schemas.microsoft.com/authorization/claims/permit", Value = "true");

@RuleName = "3) accept customer specified IP address to Office365 #1"
exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip", Value =~ "xxx.xxx.xxx.xxx"])
 => issue(Type = "http://schemas.microsoft.com/authorization/claims/permit", Value = "true");

@RuleName = "3) accept customer specified IP address to Office365 #2"
exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip", Value =~ "yyy.yyy.yyy.yyy"])
 => issue(Type = "http://schemas.microsoft.com/authorization/claims/permit", Value = "true");

@RuleName = "4) accept customer specified member to Office365 by MAPI#1"
exists([Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value =~ "S-1-2-34-1234567890-1234567890-1234567890-1234"])
&& exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application", Value == "Microsoft.Exchange.Autodiscover"])
 => issue(Type = "http://schemas.microsoft.com/authorization/claims/permit", Value = "true");

@RuleName = "4) accept customer specified member to Office365 by MAPI#2"
exists([Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value =~ "S-1-2-34-1234567890-1234567890-1234567890-1234"])
&& exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application", Value == "Microsoft.Exchange.OfflineAddressBook"])
 => issue(Type = "http://schemas.microsoft.com/authorization/claims/permit", Value = "true");

@RuleName = "4) accept customer specified member to Office365 by MAPI#3"
exists([Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value =~ "S-1-2-34-1234567890-1234567890-1234567890-1234"])
&& exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application", Value == "Microsoft.Exchange.RPC"])
 => issue(Type = "http://schemas.microsoft.com/authorization/claims/permit", Value = "true");

@RuleName = "4) accept customer specified member to Office365 by MAPI#4"
exists([Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value =~ "S-1-2-34-1234567890-1234567890-1234567890-1234"])
&& exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application", Value == "Microsoft.Exchange.WebServices"])
 => issue(Type = "http://schemas.microsoft.com/authorization/claims/permit", Value = "true");
"@

Set-ADFSRelyingPartyTrust -TargetName "Microsoft Office 365 Identity Platform" -IssuanceAuthorizationRules $NewRule

※Rule3 IPアドレスのマッチングは==ではなく、=~で記載します。(同じIPアドレスが複数個渡されてくる場合がある。)
※Rule4 OutlookはMAPI(=RPC)だけではなく、4種類のプロトコルで動作するため、全て記載する必要があります。

また、前提条件の解釈によりますが、本ルールで許容されない通信があります。それは、ホワイトリストのIP帯からのWebによるアクセスになります。これは、例えば「物理的にyyy.yyy.yyy.yyyが別AD組織である場合」「クライアントPCのDNSが外部DNSを参照している場合」などで、ADFS Proxyに対してPassiveフェデレーションを行なう場合に発生します。

この際、ADFS ProxyからADFSサーバにx-ms-proxyの属性は付与されますが、x-ms-forwarded-client-ipの値は渡されてきません。(同値は、あくまでExchange Onlineから折り返してアクセスする際の元のIPアドレスなので) このため、もしこのアクセス制御を実装しようとすると、クレームルールだけでは実装できず、IISのIP制限を組み合わせて実装する必要があります。

  1. ADFS ProxyサーバのIISで、指定IP以外は拒否するIP制限を実装。この際、Exchange OnlineのIP帯を許可リストに加えることを忘れないこと。
  2. ADFSサーバでADFS Proxy経由のWebアクセスを許容するクレームルール作成
@RuleName = "accept Web access to Office365"
exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path"])
=> issue(Type = "http://schemas.microsoft.com/authorization/claims/permit", Value = "true");

色々あって面倒かもしれませんが、アクセス必要なパターン数はそれほど多くないと思いますので、検証しながら進めていこうかなと思ってます。

「ADFSでこんなアクセス制御はできる?」とかリクエストがあったらコメント頂ければ頑張ってみます。

Office365自習書(ADFS)が公開されました

今年に入ってから、Microsoftより人気の自習書コンテンツとして、 Office365自習書AD FS によるシングルサインオン環境構築ステップバイステップガイド が公開されました。早速拝見させて頂きましたが、非常に参考になりました。

これからOffice365のシングルサインオン環境を構築しようという方には、是非ご覧頂いて一度実際に触ってみて頂くのが良いかなと思うのですが、少しだけOffice365側の仕様変更に伴ってこの手順からの差分が出てしまっているところがあり、躓いてしまう可能性がありますので、簡単に纏めさせて頂きたいと思います。

  1. ADFSのWindows Server 2008(無印)上でのセットアップが難しくなりました。
    • 特に事情が無い場合、Windows Server 2008 R2上へのセットアップを推奨します。
    • AD FSサーバのインストール時のフェデレーションドメインの設定に必要なツールが「フェデレーション構成ツール」から「Office 365 用 Windows PowerShell コマンドレット」に統合されました。
    • 上記コマンドレットの要件がWin7/2008R2のため、シングルサインオン用にドメインを構成する工程を別のコンピュータから実行する必要があります。
    • AD FS ProxyならびにAD FSファームの2台目以降などのインストールには影響有りません。
  2. [5.1]ディレクトリ同期のデフォルト時のオブジェクト数制限が10000から20000に緩和されました。
    • 20000を越える場合は解除する数を指定の上、サービスリクエストを上げて数を緩和する必要があります。
    • サービスリクエストの処理には時間が掛かりますので、ディレクトリ同期ツールのインストールする1週間前にはOffice365を開通させ、リクエストを出しましょう。
  3. [9.3]ドメインの所有確認 で独自ドメイン追加後の表示が”確認済み”に変更になりました。
    • 7で「追加したドメインの状態が”アクティブ”になっていることを確認します」となってますが、いつまで待ってもアクティブにはなりません。(昨年途中から表示が「確認済み」に変わってます。)

説明の記述が誤っていて訂正したいなと思っているところが有ったり、企業向けに必須な機能である「アクセス制御」の機能を実現するために必要なAD FS 2.0 RU1についても是非取り込んだ形で、何か簡単な物でも作って公開していきたいと思います。

#今の自習書ベースに直すなら簡単ですが、MSさんの著作物なので勝手に改変する訳にもいかないですしね…

Office365シングルサインオン設定手順(RU1対応)

AD FS 2.0 Rollup1の設定について、あまり詳しく説明しているドキュメントが見つからなかったので自分で手順を作成してみました。

なお、AD FS2.0のインストールならびにOffice365の設定はすでに完了しているものとして作成をしております。

Webのガイドに記載されているGUIでの手順は、プルダウンで選ぶメニューのところに直接値を入力するという物で、確かに登録はできるのですが、手順上も最終的な見た目もあまり綺麗ではないので、今回は別の方法を取ることにしたいと思います。
 

少し設定項目が多く、GUIからの設定は面倒なのでPowerShellから実施したいと思います。AD FSがセットアップされたマシンでPowerShellスナップインを自動的に読み込むようにプロファイルを作成します(安納さんのblogで丁寧に説明してます:【IDM】AD FS 2.0 PowerShell コマンドレットを使用する~1 基礎編)。

if ((Test-Path (Split-Path $Profile)) -eq $False) { md (Split-Path $Profile) }
Echo "Add-PSSnapin Microsoft.Adfs.PowerShell" >> $Profile
Set-ExecutionPolicy RemoteSigned

再度PowerShellを起動すると、AD FS関係のコマンドレットが利用できるようになります。

まずは、手順では必須とされておりませんが、要求記述に名前を登録します。ここで登録した名前を、クレームルールのテンプレートなどで利用することができますので、可読性が向上するかもしれません。

Add-ADFSClaimDescription -Name "Exchange送信元IP" -IsAccepted $True -IsOffered $True -IsRequired $False -Notes "Exchange Onlineへの接続元グローバルIP" -ClaimType "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip"
Add-ADFSClaimDescription -Name "Exchangeクライアントプロトコル" -IsAccepted $True -IsOffered $True -IsRequired $False -Notes "Exchange Onlineへの接続プロトコル" -ClaimType "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application"
Add-ADFSClaimDescription -Name "ExchangeクライアントUserAgent" -IsAccepted $True -IsOffered $True -IsRequired $False -Notes "Exchange Onlineへの接続エージェント" -ClaimType "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-user-agent"
Add-ADFSClaimDescription -Name "ADFS Proxy利用" -IsAccepted $True -IsOffered $True -IsRequired $False -Notes "ADFS Proxyの利用有無の判定" -ClaimType "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy"
Add-ADFSClaimDescription -Name "ADFS Proxy絶対パス" -IsAccepted $True -IsOffered $True -IsRequired $False -Notes "ADFS Proxyの絶対パス(Active/Passive)" -ClaimType "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path"

これで要求記述に以下のように登録されます。

続いて、要求プロバイダー信頼から受け付け変換規則を作成します。とはいっても、単にパススルーするだけの簡単なルールです。

$NewRule = (Get-ADFSClaimsProviderTrust).AcceptanceTransformRules
$NewRule = $NewRule + @"
@RuleTemplete = "PassThroughClaims"
@RuleName = "[ADFS2.0 RU1] すべての Exchange送信元IP 要求のパス スルー"
c:[Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip"]
 => issue(claim = c);
`r
@RuleTemplete = "PassThroughClaims"
@RuleName = "[ADFS2.0 RU1] すべての Exchangeクライアントプロトコル 要求のパス スルー"
c:[Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application"]
 => issue(claim = c);
`r
@RuleTemplete = "PassThroughClaims"
@RuleName = "[ADFS2.0 RU1] すべての ExchangeクライアントUserAgent 要求のパス スルー"
c:[Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-user-agent"]
 => issue(claim = c);
`r
@RuleTemplete = "PassThroughClaims"
@RuleName = "[ADFS2.0 RU1] すべての ADFS Proxy利用 要求のパス スルー"
c:[Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy"]
 => issue(claim = c);
`r
@RuleTemplete = "PassThroughClaims"
@RuleName = "[ADFS2.0 RU1] すべての ADFS Proxy絶対パス 要求のパス スルー"
c:[Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path"]
 => issue(claim = c);
`r
"@

Set-ADFSClaimsProviderTrust -TargetName "Active Directory" -AcceptanceTransformRules $NewRule

これで、受け付け変換規則に、必要な属性のパススルーするルールが作成されました。(発行済み要求のところには、先ほど登録した名称が記載されています。)

最後に、発行承認規則を作成します。これは、ADFS 2.0 RU1で実装されたアクセス制御にて紹介させて頂いたとおり、各組織ごとにポリシーを決める必要がありますので、それに従って設定をします。今回は、例②の指定IP(123.123.123.123)もしくはActiveSync以外からのProxyアクセスを拒否するルールを作成してみます。

$NewRule2 = (Get-ADFSRelyingPartyTrust).IssuanceAuthorizationRules
$NewRule2 = $NewRule2 + @"
@RuleName = "block all external access to Office365, except Exchange ActiveSync"
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");
"@

Set-ADFSRelyingPartyTrust -TargetName "Microsoft Office 365 Identity Platform" -IssuanceAuthorizationRules $NewRule2

これで、Office365へのチケットの発行を制御する発行承認規則ができます。

このルールをカスタマイズすることにより、AD FSにてExchange Onlineのリッチクライアントからのアクセスを制御できるようになります。

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

「ソフトマッチ」と聞いても、なかなかピンとこない方も多いのでは無いかと思います。これは、
先に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版ディレクトリ同期ツールを触ってみた

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版ディレクトリ同期ツール

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