Microsoftからアナウンスが有りましたが、ディレクトリ同期ツールの32bit版がサポート切れになるとのこと。年内に64bit版にアップグレードする必要が出て参りましたので、ここでは、簡単にディレクトリ同期ツールのアップグレードについてお話をさせて頂きたいと思います。

まず、基本的な説明から。ディレクトリ同期の32bit版を利用されている場合は、通常Windows Server 2008を利用されており、64bit版の導入に当たってはWindows Server 2008R2になる形となるかと思いますので、基本的にはOSごと入れ替えるという形になります。

詳細は以下の図で軽く説明をしておりますが、この入れ替えに際して、旧サーバで最後に行った同期から、新しいサーバで最初に同期を実施するまでの間にActive Directory上でオブジェクトの「削除」が行われると、Office365（Windows Azure Active Directory）上にゴミのオブジェクトが残ってしまいます。このオブジェクトはディレクトリ同期されている物と認識されてますので、ポータル等から削除できないオブジェクトとして残ってしまって消すのは結構大変です。※1

そこで、このリスクの生じる時間に関してはなるべく短くなるように計画し、かつドメインコントローラー間の同期間隔を考慮して、その周辺の時間はメンテナンス時間として確保してActive Directoryへの変更は行われないように運用対処するのが望ましいと思われます。

作業自体は簡単で、新規でのインストールとあまり変わりません。移行先として別の筐体という前提で簡単に手順を書きますと、

1. 新しいWindows Server 2008R2の環境上でディレクトリ同期ツールをインストール
2. 古いディレクトリ同期ツールが前回参照したドメインコントローラに、他のドメインコントローラの情報を手動同期
3. 古いディレクトリ同期ツールで最後の手動同期を実行
4. 新しいディレクトリ同期ツールで構成ウィザードを走らせ、初回の同期を実施する
5. 旧サーバを撤去（必要に応じてディレクトリ同期ツールのアンインストールを行う）する

この工程の中で、ディレクトリ同期で利用する「MSOL_AD_Sync」アカウントのリセットが行われ、AD内でディレクトリ同期を行うことができるサーバが新サーバに切り替わります。また、終了後に再度Active DirectoryのオブジェクトとOffice365のオブジェクトのマッチングが実施されます。マッチングは、基本的には既に同期済みであり、キーとなるSourceAnchorが設定されていますので、特にこの間に変更が行われていない限りはハードマッチして元の状態になります。

同じ筐体を利用するということであれば、3番の後にOSをクリーンインストールして、ディレクトリ同期ツールをインストールするという形になるかと思います。

また、前に紹介したようなディレクトリ同期対象のフィルタなど、個別のカスタマイズ設定や、ローカルのMIIS_Adminsグループに追加したユーザは、当然新しいサーバになると全てクリアされますので、再設定が必要な場合は忘れずに実施するようにしましょう。

※1　ゴミが残ってしまった場合、放置しておくとそのオブジェクトで利用していたUPN、Emailアドレスなどの属性が再利用できなくなってしまうなどの弊害が残りますので、以下のいずれかの方法で削除する形となります。

1. Active Directoryゴミ箱などから削除したオブジェクトが復活できる場合は、一度復活させて同期を行った後に、再度削除した後に再同期する（このタイミングでOffice365側からも削除される）
2. そのテナントのディレクトリ同期を無効化する。この時点でオブジェクトの操作ができるようになるのでOffice365に残ったオブジェクトを削除し、Office365の削除済みユーザーからも削除する。その後、ディレクトリ同期を再度有効化する。ただし、この方法は有効化～無効化で2-3日以上掛かる場合が有り、かつその間にオブジェクトが更に削除された場合、今度はそのオブジェクトがゴミとして残ってしまう形となるので注意が必要。

【参考】
サービスに関する通知：【重要】32 ビットのディレクトリ同期ツールは 2013 年 1 月 1 日までに 64 ビット版に切り替えてください
ディレクトリ同期ツールをアップグレードする

9月に入って、ディレクトリ同期ツールからのメールが少し変わりました。とはいえ、内容自体に変わりは無く、送り元の署名が「Microsoft Online Servicesチーム」から「Windows Azure Active Directoryチーム」に変わりました。

特にサービスとしても差は無いように見えますので、Office365で利用していた基盤を共通化してWindows Azure Active Directoryというサービス名称で切り出したということでしょうか。

（前）

（後）

ちなみに、このチームからのメールは、

1. ディレクトリ同期が24時間実施されなかった場合【日時で送信】
2. ディレクトリ同期の際にオブジェクトが作成または更新できなかった場合
3. シングルサインオンで利用している証明書の期日が近づいてきた場合（約1～2ヶ月前）

などに送信されてきます。オブジェクトの重複チェックで引っかかって更新できなかった場合など、障害内容の特定に非常に役に立つ内容になってますので、会社の設定の欄の技術担当者の電子メールアドレスは、随時受け取りが可能なアドレスをちゃんと記載しておくと良いかと思います。

9/22に実施される.NETラボさんの勉強会に、MVP for Directory Servicesである国井さんと一緒に「ADFS/Office365連携の紹介」のタイトルで登壇させて頂くことになりました。

内容の詳細はこれから詰めるのですが、私のパートの方はOffice365のADFSの運用やトラブルシュート関係（おそらく、今であれば証明書周りになると思いますが）にしようかなと思ってます。

FIMのハンズオン（GoogleAppsとのシングルサインオン環境構築）も有りますし、凄い豪華な内容になっています。まだ申込みは始まってないようですが、興味のある方は是非参加頂けると幸いです。

ディレクトリ同期ツールは、デフォルトでいくつかのフィルタルール（例えば、isSystemCriticalObject属性の物は同期しない）などが設定されており、それらを除いて同期オブジェクトのフィルタリングはMicrosoftの正式なサポートとしては提供されておりません。

ただ、用途によっては特定のOUのみ同期させたい、特定のドメインのオブジェクトのみ同期させたいということがあるかと思います。（テストで実施をする場合や、オンプレミスのシステムで利用しているサービスアカウント群を同期したくない、など）

英語版のコミュニティのWikiに Configure Filtering for Directory Synchronization というカスタムのフィルタを設定する方法が公開されておりますので、ここではその内容を一部抜粋して紹介したいと思います。

【前提】以下で紹介する手順は、いずれもディレクトリ同期ツールに含まれるdentity ManagerもしくはSyncronization Service Managerという管理コンソールからMIISAdminsグループに所属するユーザーアカウントで実行します。（ディレクトリ同期ツールは32bit版はILM2007、64bit版はFIM2010をベースにしていますので、インストールされている場所が異なりますが、見た目含め中身はほぼ一緒です）

• 32bit版：C:Program FilesMicrosoft Online Directory SyncSYNCBUSUIShellmiisclient.exe
• 64bit版：C:Program FilesMicrosoft Online Directory SyncSYNCBUSSynchronization ServiceUIShellmiisclient.exe

（参考：64bit版のツールを起動した画面）

①OUベースのフィルタリング

• 「Management Agents」を開き、「SourceAD」をダブルクリックする
  
• 「Configure Directory Partitions」をクリックし、「Containers」を開く
  
• ADのログオン情報を求められるので、ADへの読み取りアクセス権を持つユーザーのID、PASSを入力する
• ドメインのツリーが表示されますので、同期したくないOU、コンテナのチェックを外す
  
• SourceADを右クリックして「Run」「Full Import Full Sync」を選択する

②ドメインベースのフィルタリング

• 「Management Agents」を開き、「SourceAD」をダブルクリックする
• 「Configure Directory Partitions」をクリックする
• 「Select Directory Partitions」から、同期したくないドメインのチェックを外す
  
• SourceADを右クリックして「Run」「Full Import Full Sync」を選択する

③ユーザー属性ベースのフィルタリング

例として、extensionAttribute15属性にNoSyncが設定されているユーザーを同期対象外とするように構成したいと思います。
※ここで紹介するフィルタリングはユーザーオブジェクトのみに適用可能です。（グループならびに連絡先は、より複雑なフィルタリングが施されております。）

• 「Management Agents」を開き、「SourceAD」をダブルクリックする
• 「Configure Connector Filter」をクリックする
• Data Source Object Typeに「user」を選択して「New」をクリックする
  
• Data source attributeに「extensionAttribute15」、Operatorに「Equals」、Valueに「NoSync」を入力し、「Add Condition」「OK」の順にクリックする
  
• Configure Connector Filterの画面でOKをクリックする
  
• SourceADを右クリックして「Run」「Full Import Full Sync」を選択する

この辺りの概要については、ILM 2007 を使用して Active Directory ユーザーを管理する などのTechnet記事などに紹介がありますので、それぞれの項目についてもう少し理解をしたい場合には参考になさってください。

Office365でシングルサインオンを運用してしばらく経つと、以下の様なメールを受け取ることがあります（テナントの設定で技術担当者のメールアドレスをきちんと登録しておく必要があります。）

普段、ディレクトリ同期したオブジェクトに禁則文字があったり他のオブジェクトと重複があった場合のエラーや、24時間のうちに1度もディレクトリ同期が行われなかった場合などにメールは飛びますが、こちらは証明書の有効期限切れの1~2ヶ月前あたりに来るようです（まだ来ないテナントとかも有って、詳細な条件は分からないのですが）。

ADFS証明書の更新について の記事で書いたとおり、証明書の更新のタイミングは「自己署名証明書の切れるタイミング」「通信用の公的SSL証明書の切れるタイミング」の2回有り、それぞれで実施をする必要があります。

これを放っておいて、どちらかの証明書の期限が切れた場合、もしくはトークン署名証明書が更新された後にUpdate-MsolDeferatedDomainコマンドを実施せずにプライマリ証明書に昇格してしまった場合はシングルサインオンができない状態になり、全てのユーザーがアクセスできないという事態になってしまいます。

というわけで、証明書は毎年忘れずに更新し、きちんと運用しましょうというお話でした。（どうしても忘れっぽい場合は、最初から3年なり5年なりの長めの外部＆自己署名証明書を実装しましょう）

あまり日本語のドキュメントが無かったので、自分のリマインダ代わりに手順を記載します。

ADFSは、その動作の為にSSL証明書を利用しますが、その用途によって「①サービス通信証明書」「②トークン暗号化解除証明書」「③トークン署名証明書」の3つが利用されます。

Office365を利用する場合、ウィザードで通常通り作成すると、①はIIS等でCSR作成した外部CA（もしくは自己署名やエンタープライズCA）の証明書で、②③がADFSが自動的に生成した証明書となります。

SSL証明書には有効期限がありますので、①②③ともに有効期限が来る前に更新をする必要があります。

ADFSサーバ – サービス通信証明書（①）

CSRの発行から登録についてもいくつか処理を実施しなくてはいけません。Microsoftのサポートページに機械翻訳のKBも載ってますので参考になさって下さい。流れとしては以下の通りです。
それを過ぎると、ADFS 2. 0 サービスの通信の証明書を変更する方法

• 【準備】CSRを発行する
• 【準備】CSRを外部CAに送信して証明書を発行して貰う
• 【準備】発行された証明書を秘密キーを含む形（pfx）でエクスポートする
• MMCの「証明書（ローカルコンピューター）」から上記のpfxを「個人」ストアにインポートする
• MMCからインポートした証明書の「全てのタスク」「秘密キーの管理」から、ADFSファームのサービスアカウント（スタンドアロンの場合はNETWORK SERVICE）に「読み取り」のアクセス権を与える
  
• IISの「Default Web Site」の「バインドの編集」から、HTTPSで利用しているSSL証明書を新しい物に変更する。
• ADFSの管理コンソールから「サービス」「証明書」を選び、右ペインの「サービス通信証明書の設定」をクリックすると、利用できる証明書の一覧が表示されますので、新しい物に変更します。
  

ADFSサーバ – トークン暗号化解除証明書、トークン署名証明書（②③）

以前の投稿「ADFSインストールから350日でSSO不可」「ADFSの自己証明書の期間延長」でも記載しましたが、自己証明書でADFSサービスが自動的に更新を行ってくれるので手順的にはそれほど問題は無いと思います。

Office365の場合は自動的に期限の切れる20日前に、その時点から1年間有効なセカンダリの証明書が発行されるので、それがプライマリに昇格する5日間の間にUpdate-MsolFederatedDomainコマンドを実行するか、Microsoft Office 365 Federation Metadata Update Automation Installation Toolをインストールしておきます。

手動で任意のタイミングで実行したい場合は、以下を参考に実行されて下さい。

Add-PSSnapin Microsoft.Adfs.PowerShell
Import-Module MSOnline
$LiveCred = Get-Credential
Connect-MsolService -Credential $LiveCred
Update-ADFSCertificate
Update-MsolFederatedDomain -DomainName contoso.com
Get-MsolFederationProperty
Restart-Servivce adfssrv

毎回実施するのが面倒な場合は、Set-AdfsProperties -CertificateDuration 3650 などを加えても良いでしょう。更新後は念のためADFSサービスを再起動します。

ちなみに、ADFSファーム構成の場合、この証明書情報はActiveDirectory上に格納されますのでこの工程と①の最後の工程はADFSのプライマリ（最初にインストールした物：Get-AdfsSyncPropertiesでRoleがPrimaryComputerと出る物）で実施すればファーム内の別サーバに同期されます。

※その他の①の工程（IISへの設定）は各マシンで個別に実施する必要があります。

ADFS Proxyサーバ

ADFS Proxyサーバは、基本的にはADFSサーバでいうサービス通信証明書に相当する証明書のみ利用しています。

通常の場合はADFS Proxy構成ウィザードを走らせる必要は無く、

• MMCの「証明書（ローカルコンピューター）」からpfxを「個人」ストアにインポートする
• MMCからインポートした証明書の「全てのタスク」「秘密キーの管理」から、NETWORK SERVICEに「読み取り」のアクセス権を与える
• IISの「Default Web Site」の「バインドの編集」から、HTTPSで利用しているSSL証明書を新しい物に変更する。

でいけるかと思います。

ただ、ADFS側でトークン署名証明書を更新した場合は、ADFS Proxy構成ウィザードを再実行した方が良いという情報もございますので、念のため実行しておいた方が良いでしょう。

ADFSのシングルサインオン環境において、外部からブラウザでアクセスすると、ADFS Proxy経由でのアクセスとなります。
　

この際、オペレーション上で少し気になる点がありました。

1. 前の画面でIDを入れたのに、再度最初から入力を促される
2. 前の画面では、username@domain.nameの形式で入力する必要があるが、移行先の画面では入力例がdomainusernameになっている

少し変だなとは感じつつも、まあデフォルトで埋め込まれている物だから仕方ないな…と思っていたのですが、ExchangeのMVPのMike Pfeifferからこれを解消するカスタマイズ方が紹介されています。

Useful Customizations to AD FS 2.0 when Deploying SSO with Office 365

詳しい手法については上記ページに任せようと思いますが（日本語環境でもほぼ一緒です）、こちらに従ってC:inetpubadfslsApp_GlobalResourcesCommonResources.ja.resxとC:inetpubadfslsFormsSignIn.aspx.csのファイルを書き換えます。
　

すると、違和感の無い画面表示になり、ユーザーIDの初期値に前の画面で入力した値（HTTPヘッダ中のGETパラメータのusernameに渡されている値から取得しています）が入力されるようになります。

セキュリティの問題で、メールアドレスのドメイン名とUPNドメイン名を分けている場合などは、UsernameExampleの値を実際の名前では無く「username@example.com」などに汎用化しても良いかもですね。

前回の投稿について、識者からいくつかコメントを頂きました。

• 自己証明書ではなく、サービス通信証明書をトークン暗号化・トークン署名でも使ったらどうか？

確かに、ADFS関連のトレーニングではこちらの手順についても教えて頂いた記憶がございます。更新時は手動で更新になってしまいますが、全部一緒のタイミングであれば更新し忘れも無いですし、証明書更新のためシステム少し止めますよと言っても理解が得られそうです。

何より面倒くさければ最初から3年間有効な証明書とか買ってしまえば済むことですしね。

• Office365なのに350日で利用出来なくなるのが問題なのだから、名前をOffice350にすれば良いのでは？

なるほどwww

というわけで、私の方でも少し対処を考えてみました。そもそも、ADFSの自己証明書の

1. 期間は365日
2. 切れる20日前に新しい自己証明書を発行（セカンダリに）
3. 2から5日経ったらセカンダリの証明書をプライマリに昇格させる

という値が問題になっているということです。こういった物は、きっとパラメーターになっていて、PowerShellなら設定出来るでしょうということで、PowerShellでGet-ADFSPropertiesコマンドを実行してみます。

すると、それっぽいパラメータがあります。

• CertificateDuration : 365
• CertificateGenerationThreshold : 20
• CertificatePromotionThreshold : 5

と言うわけで、証明書の期間を10年にして新しい自己証明書を発行してみます。

Set-AdfsProperties -CertificateDuration 3650
Update-ADFSCertificate -Urgent
Update-MsolFederatedDomain -DomainName contoso.com

これで、ADFSの自己証明書が10年に更新されました。ちなみに、通常はUpdate-ADFSCertificateはUrgentオプションを付けずに実行し、セカンダリの証明書として作成をします。プライマリに昇格するまでの5日間の間に、Update-MsolFederatedDomainコマンドにより新しい証明書をOffice365に転送します。

Office365側にも無事に転送され、10年として認識されていますようです。

と言うわけで、後で忘れそうな方は最初から延長してからADFS環境を組むのも良いかもしれません。

日経BPさんより、先週「ひと目でわかるADFS2.0 & Office365連携」が発売されました。

発表時に「ひと目でわかるADFS(仮)」というタイトルだったので、一部で「本当か！？」とささやかれておりましたが、無事発売となったようなので早速購入して来ました。

ページ数は220Pで、1章から6章までの章立てです。

1. 本書で学習する前に
2. 認証と認可（承認）
3. AD FS2.0の基本
4. AD FS2.0のインストールと構成
5. ローカルActive DirectoryとOffice365の連携
6. クライアントアクセスポリシー

内容のレベルについてはOffice365やADFSのトレーニング＋ハンズオンをくっつけたような感じで、トラブルシュートや運用系の部分は若干薄めですが、ADFSのさわりを扱うにはとてもよくまとまっている良い書籍かと思います。

ただ、良くも悪くも、各章ごとに知っておくべき事を必要十分な情報量を掲載しています。ADFSを触ったことのある人ならよく分かると思うのですが、認証/認可、RP/CPとか証明書まわりとか、重い部分が2章～3章に重なっており、ここをいかに華麗にマスター…さもなくばスルーするかがひと目で分かるポイントかと思います。

Office365でADFSをとりあえず利用する上では、殆ど選択肢無しのウィザード形式で実装できます。敢えて、4章から読み始めて仕組みでは無く効能・手順から入るようにするのも良いかもしれません。