ADFSの証明書はきちんと更新しましょう

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

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

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

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

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

Office365 Enterprise (Preview)でのSSO手順

Office365の次期バージョン(開発コードOffice15)のプレビューが開始されました。ヘルプを見てみたところ、概ねADFSがらみの部分は同じコンテンツのようでしたので、実際に試してみました。

ちなみに、環境はこんな感じです。

  • Office365ドメイン名:exchange2013.onmicrosoft.com
  • ADドメイン名:exchange2013.local
  • ADFS用ドメイン(新しいUPN)名:exchange2013.info
  • ADFSサービス名:sts.exchange2013.info
  • ADサーバ:ad.excange2013.local / Windows Server 2008 R2 SP1
  • ADFSサーバ兼ディレクトリ同期サーバ:adfs.exchange2013.local / Windows Server 2008 R2 SP1

まずは、ADFS用のドメインを追加します。新しい管理者ポータルから、「ドメイン」を開き「ドメインの追加」を選択します。ドメイン名を入力し、次へを選択します。

ドメインの認証画面が表示されますので、プルダウンから「一般的な手順」を表示させます。すると、認証用のTXTレコード(MS=ms12345678)が表示されますので、こちらと同じ値を追加しようとしている独自ドメインのDNSに登録します。

変更が出来たのを自身の端末などから確認ができたら、「確認」ボタンをクリックするとドメインの登録が完了します(ここはキャッシュなどの問題で数時間~24時間ほどかかる場合もございます。) ドメインの用途は必要なサービスを選択(SharePoint Onlineは他のサービスとは排他)して「次へ」をクリックすると、ドメインの追加は完了します。

続けて、独自ドメインのDNSレコードの構成に入ることもできます。追加する必要のあるレコードは、概ねOffice365の時と変わらないようですが、MXの向け先であるFOPEのFQDNのみcontoso-com.mail.eo.outlook.com のような変換ルールだったのが contoso-com.mail.protection.outlook.com のような変換ルールになってます。(プレビュー版だからの可能性も有ります。)

ドメインが追加されたことを確認したところで、オンプレミス(AD、ADFSサーバ)側の処理に入りたいと思いますが、先行して「ディレクトリ同期のアクティブ化」を実施されておくことをお勧めします。

「ユーザーとグループ」からシングルサインオンの右側にあるセットアップを選択し、「ActiveDirectory同期をアクティブ化する」をクリックします。(画面には「最大24時間かかる場合があります」と表示されますが、本当に数時間以上掛かるケースが多いです。

さて、この間にADFS、ディレクトリ同期サーバなどのセットアップを行います。

まずは、既存のActive Directory環境のアセスメントから実施します。今回、オンプレミスのActive Directoryが「exchange2013.local」というインターネット上で解決ができず、かつ自身で所有していない(=Office365 Enterpriseの追加ドメインとして利用できない)ドメインなので、独自ドメインの「exchange2013.info」を利用します。

今まで、username@exchange2013.localだったユーザ名をusername@exchange2013.infoに変更します。勿論、この作業以降はユーザは元のIDではログオンできなくなるので注意が必要です。(今まで利用していたのがexchange2013usernameの形式であれば問題なく継続してログオンできます。)

ドメインコントローラ上から、「Active Directoryドメインと信頼関係」を開き、ドメイン名の上のルートを右クリックしてプロパティを開き「代わりのUPNサフィックス」にexchange2013.infoを追加します。

これで、ユーザーを作成する際やプロパティを開いた際に、UPN名で「exchange2013.local」の他に「exchange2013.info」をプルダウンから選択して設定することが可能になります。ちなみに、これを行っただけでは既存のユーザのUPNは変更されませんので、GUIからユーザーを選択してプロパティを開いて変更するか、PowerShellなどで変更してしまいましょう。

ここでは、Office 365 環境用 ID フェデレーション実装ガイド で紹介されているPowerShellを利用してドメイン内のUPNを問答無用でexchange2013.infoに変更しました。

$UPNSuffix = "exchange2013.info"
Get-ADUser -Filter:* | foreach {
 [string]$newUPN = $_.SamAccountName + "@" + $UPNSuffix
 Set-ADUser $_ -UserPrincipalName:$newUPN
}

続いて、DNSを作成します。exchange2013.infoというゾーンは、現在内部DNSには無いのでそれを新規で作成し、sts.exchange2013.infoというホストをADFSサーバのIP(adfs.exchange2013.local)に向けるようにAレコードを作成します。

つぎに、ADFS実行用のサービスアカウントを作成します。Active Directoryユーザーとコンピューターから、任意のユーザーを作成します。ここでは、adfsserviceというユーザーを作成しています。厳密には管理者権限が無くても構成は可能ですが、警告が出たり手順が複雑になるので、ここでは管理者として構成しておきます。

これで、ようやくADFSをセットアップする準備が整いました。ADFSサーバにadfsserviceのアカウントでログインします。また、セットアップに必要なファイルを準備しておくと良いと思います。

  • AdfsSetup.exe(ADFS2.0RTM)
  • dirsync-ja.exe(ディレクトリ同期ツール
    ※少し前のサインインアシスタントが同梱されております
  • AdministrationConfig-ja.msi(Windows PowerShell用Microsoft Online Servicesモジュール)
  • sts_exchange2013_info.pfx(sts.exchange2013.infoのシリアル名が付いているpfx証明書)

まず、AdfsSetup.exeを起動してADFSをインストールします。使用許諾に同意した後に、「フェデレーションサーバ」の役割を選択して進めると、プログラムのインストールは完了します。

最後の所で「ADFS2.0の管理スナップインを開始する」のチェックボックスを外して完了します。(もしくはチェックを外さないで、次の起動画面の状態で準備の次の工程を進めます)

ADFSのセットアップには、SSL証明書が必要になります。今回はイントラ内での利用のみかつ検証環境なのでエンタープライズCAから発行された証明書を利用しようと思います。(既に発行済みの物を.pfxで保存して持ってきておきます)

MMCを起動し、「スナップインの追加と削除」から「証明書」を選び「ローカルコンピュータ」を選択します。

「個人」からインポートを選択し、用意したpfxファイルをエクスポート可能な形で「個人」にインポートします。この際に最初にエクスポートした際に設定したパスワードが要求されます。

インポートした証明書の秘密キーに対して、ADFSサービスアカウントが読み取り以上のアクセス権限を有している必要がありますので、証明書の「秘密キーの管理」から適切な権限を割り当てます。

続いて、ADFSのセットアップに戻ります。「ADFS2.0の管理」を起動し、中央ペインの構成ウィザードを起動します。

「新しいフェデレーションサービスを作成」「新しいフェデレーションサーバーファーム」を選択します。利用する証明書では、先ほどインポートした証明書が選択され、フェデレーションサービス名に sts.exchange2013.info が入っていることを確認します。また、ADFSのサービスアカウントはadfsserviceを選択し、パスワードを入力します。

しばらく待つとADFSのセットアップの完了です。

この後、Office365の情報を追加するとADFSのセットアップは完了しますが、その前に、ディレクトリ同期ツールのセットアップを先に完了させる必要があります。

dirsync-ja.exe を管理者として実行します。ライセンス許諾に同意して次へを選択すると、しばらく待つとインストールの終了です。終了後はそのまま設定ウィザードに移行しますので、Office365 Previewポータルでディレクトリ同期の準備が完了したことを確認した後、構成ウィザードを起動します。

ちなみに、手順等の問題で先に「サインインアシスタント」をインストールした場合、このインストールの途中で異常終了します。かならず一度アンインストールしてからディレクトリ同期ツールをインストールして下さい。

さて…、ここで完了をクリックする前に、元のOffice365 Previewポータルに戻ってディレクトリ同期が有効化されていることを確認します。場合によっては1日以上待つことになるかもしれませんが、そこは余裕を持ってスケジューリングをしておいて、気長に待ちます。

ディレクトリ同期が有効化された後に、構成ウィザードを開始します。ウィザードでは、同期用のOffice365の管理者アカウントとActive Directoryの管理者アカウントを設定します。設定が完了したら早速同期しておきます。

最後に、ADFSを有効化します。用意しておいたWindows PowerShell用Microsoft Online Servicesモジュールを実行してインストールを行います。

その後、ADFSサーバ上でPowerShellを起動してConnect-MsolServiceでOffice365に接続し、Convert-MsolFederatedDomainコマンドを実行してシングルサインオンを有効化します。

$LiveCred = Get-Credential
Connect-MsolService -Credential $LiveCred
Convert-MsolDomainToFederated -DomainName contoso.com

これで、サーバ側の準備は完了です。

Active化したuser01というアカウントでシングルサインオンの試験をしてみようと思います。https://sts.exchange2013.info/ を「イントラネットサイト」に設定した後に、ポータルに接続しまてIDを入力後、「exchange2013.infoにサインインする」をクリックすると、数回のリダイレクトの後にシングルサインオンできました。

というわけで、特にOffice365の時の手順と相違なくシングルサインオン環境が構築できました。共通的に利用している部分も多く、特にディレクトリ周りは同じ基盤を使って実装していると思われます。

ADFS証明書の更新について

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

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 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」などに汎用化しても良いかもですね。

Office365ライトニングトーク#2

先ほど、Office365ライトニングトーク第2回 で発表が完了しました。

発表したスライドは以下で共有しています。
http://www.slideshare.net/genkiw/office365-customize

他にもこんなことできないのとか、こうやったほうが便利だよとか有ったらみんなで共有していければと思います。

ADFSの自己証明書の期間延長

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

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

確かに、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環境を組むのも良いかもしれません。

ADFSインストールから350日でSSO不可

MicrosoftスクリプトセンターでMicrosoft Office 365 Federation Metadata Update Automation Installation Toolというスクリプトが公開されました。

こちらですが、やっていることは単純でインストール時に入力した資格情報を元に、毎日0時にUpdate-MsolFederationDomainを実行してくれるという物です。

これの何が嬉しいかと言いますと、Office365のADFSではトークン署名証明書はデフォルトで有効期限が1年間の自己証明書として発行されます。また、自動ロールオーバーの機能によって有効期限の20日前、すなわちインストール時から345日後に新しい証明書が発行され、その5日後(インストールから350日後)に差し替えられます。

この差し替えられた証明書ですが、自動ではOffie365側には登録されないため、インストール後345~350日後の間にOffice365に情報を伝送させておく必要があるということで、これを解決するためにとりあえず毎日情報の更新をOffice365に対して行っておこうというツールです。

Microsoft Office 365 Federation Metadata Update Automation Installation Tool
http://gallery.technet.microsoft.com/scriptcenter/Office-365-Federation-27410bdc

インストールは簡単で、ADFSサーバ上で実行し、Office365の管理者IDの資格情報とローカルサーバ上の資格情報を入力すれば、自動的にC:Office365-Scripts配下にMicrosoft-Office365-Update-MSOLFederatedDomain-CONTOSO.COM.ps1(ドメイン名入り)というps1ファイルと、同じ名前のDailyタスク(毎日0:00起動)を作成してくれます。

私の環境では、ADFS2.0のRU1が出た際に一度再セットアップとUpdate-MsolFederatedDomainを掛けてしまったので、まだこう言った事象には出くわしたことが無いのですが、気づくとこういった物は期限になっていたりするので、今のうちにやっておきましょうという感じですね。

【参考】
シングル サインオンを確認および管理する
トークン署名証明書の有効期限が毎年切れる:既定では、AD FS 2.0 は、毎年有効期限の切れる 20 日前に、自己署名証明書のトークン署名証明書を新たに生成します。証明書のロールオーバー、すなわち証明書の有効期限が近づいたときに新しい証明書を生成してプライマリ証明書に昇格させる機能は、AD FS 2.0 によって生成された自己署名証明書にのみ適用されます。
AD FS 2.0 が新しいトークン署名証明書を生成するタイミングを構成できます。証明書のロールオーバーの時期が近づくと、既存の証明書と名前が同じで秘密キーと拇印が異なる新しい証明書が AD FS 2.0 によって生成されます。新しい証明書は生成後、セカンダリ証明書として 5 日間経過した後プライマリ証明書に昇格します。既定で 5 日間に設定されていますが、変更が可能です。 

ひと目でわかる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章から読み始めて仕組みでは無く効能・手順から入るようにするのも良いかもしれません。