皆さんこんにちは、国井です。

ADFSサーバーは長らくOffice 365のシングルサインオンを実現するために欠かせない機能として、多くの企業で導入されてきました。しかし、最近ではAzure AD Connectのパススルー認証やパスワードハッシュ同期+SSOを利用することで、ADFSサーバーを利用しなくてもシングルサインオンは実現できるようになっています。また、クレームルールを使ったアクセス制御についても、Azure ADの条件付きアクセスを利用することによって、その代替になりつつあります。

そうすると、私たちの中でギモンが生まれます。

「ADFSって必要なの？」

もちろん必要なければ消えてなくなるだけなのだけど、実際にはそうでもなさそうです。
そこで記念すべき400回目の投稿となる今回は、ADFSが必要となるケースを私なりに考えてみました。

ハイブリッド構成

Exchange ServerとExchange Online、Skype for Business ServerとSkype for Business Onlineなど、オンプレミスとクラウドでサービス間連携を行う場合、1つのIDでオンプレミスとクラウドの両方をシームレスにアクセスできる必要があります。その場合、ADFSを使って認証はActive Directoryに一元化し、クラウドへのアクセスはADFSを使って橋渡しをしてあげるような仕組みが必要となります。

ハイブリッド構成は恐らくADFSサーバーを利用する最有力な理由になるのではないかと思います。

Windows Hello for Business のオンプレミス展開・ハイブリッド展開

Windows Hello for Business(WHfB)は、Windows Helloを使って行う認証(つまりパスワードを使わない認証)方法で、Azure ADにアクセスするための機能ですが、WHfBはオンプレミス展開、またはハイブリッド展開を実装することで、オンプレミスのActive DirectoryにサインインするときにWHfBを使うことができます。
このとき、WHfBによる認証を行うためのインターフェイスとして動作するのがADFSサーバーで、顔認証などによるWindows Helloでの認証結果をADFSサーバーが受信し、その内容に基づいてADFSサーバーが代理でActive Directoryにサインインする、というようなアクセスを行います。
また、WHfBほど複雑な実装をしなくても、単純に証明書を使った認証でパスワードを入れなくても良いようにしたい、というときにもADFSサーバーは役立ちます。

最近は、パスワードを使って認証を行うこと自体が脆弱だといわれる時代なので、こうした認証・認可の実装は今後、重要になってくるかもしれないですね。

詳細なアクセスログの収集

Azure ADにサインインしたときにもログって収集できますが、ADFSサーバーを利用しているときのようなトークンの中に含まれる内容まで詳細にログを記録してくれるわけではありません。また、Azure ADに記録されるログは最大で1か月しか保存してくれないので、長期的に、そして詳細な内容をログとして残しておきたいというときにオンプレミスのActive Directory＋ADFSサーバーという選択肢は考えられると思います。

これは、IdPをオンプレミスに持つか、クラウドに持つか、という議論にもつながってくる話だと思います。

社内IPに基づくクレームルール

最後はオマケです。
Azure ADを使ってアクセス制御を行う場合、IPアドレスベースのアクセス制御ができますが、この設定はグローバルIPアドレスをベースにしたアクセス制御を行います。
それに対して、ADFSサーバーによるクレームベースのアクセス制御では、プライベートIPアドレスをベースにしたアクセス制御を行います。もし、社内のIPアドレスのうち、特定のIPアドレスからのみアクセスを許可したい、のようなニーズがある場合にはADFSサーバーが必要になってくると考えられます。

■　■　■

いかがでしたか？
これからADFSサーバーを導入しようか考えている会社はまだしも、
既にADFSサーバーを導入している会社において、Azure ADのほうが良さそうだという短絡的な理由で、ADFSサーバーをやめてしまうと「やっぱり必要だった」というときに目も当てられません。ですので、必要なケース、そうでないケースをきちんと見極め、必要な場合にADFSサーバーを利用するようにしたいですね。

皆さんこんにちは。国井です。

今日はOffice 365 Advent Calendar 2017に参加して、本投稿を書いています。

■Office 365 Advent Calendar 2017
https://adventar.org/calendars/2585

Office 365へのサインインのうち、50％がADFSサーバーを使ったサインインだといわれているので、そのADFSサーバーへのサインインをAzure ADの多要素認証と組み合わせて強化していく方法について見てみたいと思います。

ADFSサーバーで多要素認証を実装すると言ったら、基本的に証明書認証一択だったと思いますが、Azure AD Premium P1で提供されるAzure MFAを組み合わせると、Azure MFAの電話認証等がADFSサーバーでも利用できるようになります。

この設定自体は以前からあったのですが、Azure ADで提供されるツールをインストールするなどの作業がなくなったので、簡単に利用できるようになりました。
(以前提供していたツールって、インストール後のウィザードが複雑すぎて何をすれば正解なのか、よくわからなかったりして、実装には色々と苦労させられてたんですよね..)

ではさっそく、簡単になったAzure MFAをWindows Server 2016と組み合わせて設定する方法について実装方法をみていきましょう。

準備

Azure AD Premium P1以上のライセンスとADFSサーバーによるAzure ADシングルサインオン環境が必要です。
実はこれが一番のハードルだったりします。。

Azure MFAを利用できるようにするための初期設定

Azure MFA用の証明書の作成、証明書とAzure MFAのアプリIDを組み合わせてSPNを作成、ADFSと関連づける設定、この3つをPowerShellで実行します。

$certbase64 = New-AdfsAzureMfaTenantCertificate -TenantID <ドメイン名>
New-MsolServicePrincipalCredential -AppPrincipalId 981f26a1-7f43-403b-a875-f8b09b8cd720 -Type asymmetric -Usage verify -Value $certBase64
Set-AdfsAzureMfaTenant -TenantId <ドメイン名> -ClientId 981f26a1-7f43-403b-a875-f8b09b8cd720

Azure MFAのアプリIDは981f26a1-7f43-403b-a875-f8b09b8cd720って決まっているので、そのまま入力するだけ。TenantIdにはAzure AD Connectのコネクタスペースの名前が入りますが、それはすなわちActive Directoryのドメイン名になります。

Azure MFAの利用開始

Windows Server 2016のADFSサーバーで管理ツールを開き、以下の設定を行います。

1．[サービス]-[認証方法]から[多要素認証方法の編集]を開き、[Azure MFA]を有効にします。

2．[証明書利用者信頼]からMicrosoft Office 365 Identity Platformのアクセス制御ポリシーを開き、[すべてのユーザーを許可し、MFAを要求]を選択します。

以上で設定は終わりです。
ちなみに、[サービス]-[認証方法]から[プライマリ認証方法の編集]を開いて、[Azure MFA]を使うように設定する必要はありません。

ユーザーの設定

多要素認証方法を選択しておく必要があります。
多要素認証方法の設定はAzure ADに直接保存されるので、Azure ADが提供する多要素認証の初期設定サイト(https://aka.ms/mfasetup)にアクセスし、電話番号などを設定してもらいます。

アクセスしてみる

Office365のサイトにアクセスしようとすると、ADFSサーバーのURLにアクセスしたとたん、事前に設定した多要素認証の方式に従い、電話またはアプリを使った認証が始まります。

ちなみに、社外からアクセスするときにパスワードを入力しないで、Azure MFAだけを使うように設定することも可能です。

この設定自体、それほど複雑なものではないと思いますが、これがWindows Hello for Businessのハイブリッド展開を行う上で欠かせない設定要素になりますので、覚えておきましょう。

明日のAdvent Calendarは@teracwoさんです。お楽しみに。

■参考
Configure AD FS 2016 and Azure MFA
https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/operations/configure-ad-fs-and-azure-mfa

皆さんこんにちは、国井です。
Windows Server 2008のサポート期限切れが近づくにつれて問い合わせが多くなってくるWindows Server 2008で作成したADFS環境をどうやってWindows Server 2016へ移行するか？という話題。

Windows OS全般に言えることですが、基本的に2世代前からのアップグレードはマイクロソフトとしてサポートされることはなく、ADFSも例外ではありません。

2008→2012のアップグレードドキュメント
https://technet.microsoft.com/ja-jp/library/dn486819(v=ws.11).aspx

2012→2016のアップグレードドキュメント
http://azuread.net/2017/02/22/windows-server-2016%E3%81%AEadfs%E3%82%B5%E3%83%BC%E3%83%90%E3%83%BC%E3%81%AB%E3%82%A2%E3%83%83%E3%83%97%E3%82%B0%E3%83%AC%E3%83%BC%E3%83%89/

というわけで、2008→2016の移行は、アップグレードウィザードみたいな既存の仕組みは全くないので、自分で移行(というか、再構築)していかなければなりません。

では、設定を見てみましょう。

既存環境の設定の確認

まず、移行前と移行後で同じパラメーターで動作させる必要があるので、既存の環境から次のパラメーターを確認しておきます。

・フェデレーションサービス名
・フェデレーションサービスの表示名
・フェデレーションサービスの識別子

次に、サービス通信証明書は移行先でも同じものを使いますので、ADFS管理ツールからエクスポートしておきます。

最後に、証明書利用者信頼などの設定はWindows Server 2016のセットアップディスクの中にあるPowerShellスクリプトを使ってエクスポートすることができます。

エクスポートコマンド
cd <セットアップディスクのドライブ>\support\adfs
export-federationconfiguration.ps1 -Path <エクスポートデータの保存先パス>

Active Directoryスキーマの拡張

ADFSをWindows Server 2016にするってことは、Active DirectoryドメインコントローラーもWindows Server 2016にする可能性が高いと思います。ドメインコントローラーを以前のOSからアップグレードしている場合は、スキーマが古いままになっているので、スキーマもアップグレードしておきます。

スキーマのアップグレードコマンド
cd <セットアップディスクのドライブ>\support\adprep
adprep /domainprep
adprep /forestprep

ADFS 2016の実装

Windows Server 2016のADFS (ADFS 2016と勝手に呼ぶこととする)をインストールします。インストールするときは、ADFS2.xからのサーバー入れ替えになるので、既存のADFSサーバーはシャットダウンしておきます。

ADFS 2016のインストールでは、インストールウィザード中に前の手順で控えておいたパラメーターを入力します。また、サービス通信証明書もインストールウィザード中に入れることになりますが、これも前の手順でエクスポートしておいたものを入れましょう。
これができれば、ADFS 2016環境の出来上がり。

ただし、トークン署名証明書は新しいものに変わってしまっているので、証明書を入れ替える時のステップを実行する必要があります。証明書の入れ替え方法はMSさんのサイトを参考にするとよいでしょう。

AD FS の証明書更新手順（トークン署名証明書、トークン暗号化解除証明書）
https://blogs.technet.microsoft.com/jpntsblog/2016/12/19/ad-fs-%E3%81%AE%E8%A8%BC%E6%98%8E%E6%9B%B8%E6%9B%B4%E6%96%B0%E6%89%8B%E9%A0%86%EF%BC%88%E3%83%88%E3%83%BC%E3%82%AF%E3%83%B3%E7%BD%B2%E5%90%8D%E8%A8%BC%E6%98%8E%E6%9B%B8%E3%80%81%E3%83%88%E3%83%BC/

最後に、前の手順でエクスポートしたデータをインポートしましょう。こちらも同じくWindows Server 2016のセットアップディスクの中にあるPowerShellスクリプトを使ってインポートします。

インポートコマンド
cd <セットアップディスクのドライブ>\support\adfs
import-federationconfiguration.ps1 -Path <エクスポートデータの保存先パス>

これでサービスを再起動すれば、設定を読み取って動作し始めるようになります。

ADFSプロキシの移行

ADFSプロキシ(現Webアプリケーションプロキシ)は、ほとんどサーバー固有の情報を持たないので、作り直してしまったほうが簡単です。作り直すときは、前の手順でエクスポートしておいたサービス通信証明書があれば十分です。

■ ■ ■

トークン署名証明書は作り直さないで移行するオプションなどありますが、細かな話はADFSトレーニングの中で聞いていただければと思います。

皆さんこんにちは。国井です。

今日はご質問いただいた内容について。
最近(と言っても随分前ですが)、Azure ADのサインイン画面が変わりましたが、それに合わせてADFSサーバーのフォーム認証画面もAzure ADっぽくすることができるようになりました。
これについてはMVPふじえさんが紹介してくださっているので、そちらを参考にされるとよいと思います。

■[AD FS]ログイン画面をAzure ADの新UIライクにカスタマイズする
http://idmlab.eidentity.jp/2017/11/ad-fsazure-adui.html

実際に設定してみた画面がこちら。Azure ADのサインイン画面に似ているようでちょっと違いますかね。

一方、新しいAzure ADのサインイン画面で印象的なのはこの画面ではないかと思います。

この画面で、サインインの状態を維持するように設定すると、永続Cookieと呼ばれるCookieが作成され、ブラウザーを閉じてもサインインの状態が維持されます。
これと同じことをADFSサーバーのサインイン画面でも出したいと思っても、残念ながら既定で設定画面がないため、設定できません。
もし、ADFSサーバーからサインインを行い、永続Cookieを発行させたい場合、Set-AdfsPropertiesコマンドレットを使って、

Set-AdfsProperties -EnableKmsi $true

のように実行すれば、サインイン画面は次のように変化します。

この画面で、[サインアウトしない]にチェックをつければ、永続Cookieが発行され、24時間サインインしたままの状態が継続されます。
ちなみに24時間有効という設定自体も

Set-AdfsProperties –KmsiLifetimeMins <分数>

で設定可能です。

■参考：AD FSシングルサインオン設定
https://msdn.microsoft.com/ja-jp/library/mt148493(v=ws.11).aspx

デフォルトでは、セッションCookieが有効ですが、この1行をクレームとして入れておくことによって、Cookieを使いまわし、永続的にサインイン状態を保つことができます。これにより、Azure ADでの認証・認可プロセスも省略されるため、条件付きアクセスで多要素認証を設定するようにしてあっても多要素認証は行われなくなります。

c:[Type == “http://schemas.microsoft.com/2014/03/psso”] => issue(claim = c);

皆さんこんにちは。国井です。
今日はWindows Server 2016のADFSサーバーの証明書認証についてです。

Windows Server 2016のADFSサーバーは外部アクセスでも、証明書のみで認証を済ませることができるとあって、前のバージョンからの移行を行うモチベーションになっていたりします。
さらに、Windows Server 2016のADFSサーバーの証明書認証では、TCP443で通信できるようになっており(これまではTCP49443を使って通信していた)、この点では大きなメリットがあります。

設定方法については、最近ADFS/Azure AD絡みの投稿をいっぱい書いてくださっているMiyaさんのサイトで紹介されています。

https://miya1beginner.com/windows-server-2016-adfs-sans-binding

本題ですが、TCP49443からTCP443に切り替えた時に、今まで行っていた証明書認証ができなくなるというご質問をいただいたので、その解決方法を紹介します。

基本的には上記のサイトで紹介されている手順を踏めば、それで必要な設定はすべて揃ったことになるのですが、証明書の入れ替えを前に行っていたりすると、スムーズに証明書認証の設定変更ができていないことがあるのです。
ADFSでは、http.sysのバインド設定で証明書とホスト名(FQDN)、それからポート番号をマッピングさせ、管理しているのですが、そのバインド設定が正しくないときがあるのです。
確認するときはコマンドプロンプトで「netsh http show sslcert」と入力すると、

こんな感じでホスト名、ポート番号、証明書の組み合わせが確認できます。
今見てもらっている組み合わせの中でチェックするポイントは、Miyaさんのブログの中にもありましたが、適切な証明書が割り当てられているか？そして、ポート番号443だけが使われるように構成されているか？という点です(私の知る限りでは)。

それを踏まえて、もう一度、上の画面を見てみると、ポート番号49443のマッピングが残されていることがわかります。ですので、これを削除しましょう。
削除するときは「netsh http delete sslcert hostnameport=sts.xxx.adfs.jp:49443」という感じで入力したうえで、もう一度「netsh http show sslcert」を実行すれば、

ほら、消えました。
この状態でサインインを試してみると、

こんな感じで画面が推移し、TCP443でも証明書認証ができるようになります。

皆さんこんにちは。国井です。

最近、お知らせばかりが続いていますが、今回もお知らせです。
2018年6月30日に開催される勉強会、Interact 2018に登壇することになりました。
テーマは

・Azure AD B2B
・ADFS + OpenID Connect

の2本立てです。
既に現時点で300名以上の申し込みがあるようで、これから申し込みできるのか、よくわからないですが、ご興味のある方は参加してみていただければと思います。
参加登録はこちらから。

https://interact.connpass.com/event/77420/

皆さんこんにちは。国井です。

一時期、Office 365へのサインインの50%はADFS経由と言われるぐらい、Office 365のサインインにはシングルサインオン(SSO)環境を構築し、運用している会社がたくさんあるかと思います。しかし、最近ではADFSでできる大抵のことはAzure ADでもできるようになっており、Azure AD Connectを使えばシームレスSSOもサポートされるので、いよいよサーバーレスで移行しようという話がちらほら出てくるようになりました。
(クラウド！って言っている時代にADFS2台+WAP2台の構成は..)

そこで今日はADFSからAzure ADへSSO環境を移行する方法を紹介しましょう、って書こうと思ったら既にAzure ADへの移行に関するドキュメントが色々と出ていました。

■Resources for migrating applications to Azure Active Directory
https://docs.microsoft.com/ja-jp/azure/active-directory/manage-apps/migration-resources

■ADFS廃止のすすめ (移行手順が分かりやすく書いてあるのでおすすめ！)
https://github.com/teppeiy/AzureAD-Tips/blob/master/ADFS/Goodbye-ADFS.md

基本的にはここに書いてある手順を参考していただければと思うのですが、
ADFSサーバーのパラメーターシートをもとに各設定をAzure ADに移行しようと思ったら、何をどこへ移行するべきなのか？というところで迷子になるのではないかと思います。
ですので、今回はその辺りを整理してみました。

※ざっくり書いたので間違ってたら、ご指摘いただけるとありがたいです。

こうやってみてみると、だいたいADFSにあるものはAzure ADにもあり、[属性ストア]のカスタマイズができないなど、ほとんどの人にとって無くても困らない？機能しか、ADFSには残されていなかったりします。
ただ、ADFSとAzure ADで機能的には同じでも、アーキテクチャが大きく異なるものがあるので、その点については次回以降で触れていきます。

皆さんこんにちは。国井です。
オンプレミスActive Directoryの認証結果に基づいてAzure ADへのサインインを省略するシングルサインオン(SSO)機能を実装する場合、これまではADFSサーバーを使っていました。
ですが、最近ではAzure AD Connectで提供されるシームレスシングルサインオン機能によって代替できるようになったため、ADFSサーバーからシームレスシングルサインオン機能に切り替えたいという声も聞くようになってきました。

そこで今回は直近で登場したばかりのADFSサーバーからのステージドマイグレーション機能を利用して、段階的にADFSを利用するユーザーをシームレスシングルサインオンに切り替える方法を紹介します。

おさらい：SSOの条件

Azure ADに作られたユーザーアカウントを利用してサインインする場合、これまで3つの方法がありました。

1つめはAzure ADに直接作成したユーザーでサインインする方法、
2つめはAzure AD Connectを利用してActive Directoryから同期したユーザーでサインインする方法、
そして、3つめはAzure AD Connectを利用してActive Directoryから同期したユーザーを利用してADFSサーバーでSSOアクセスする方法です。

3つめの方法は2つめの方法が前提となって利用可能なサインイン方法です。

3つめの方法でAzure ADに対するSSOアクセスを行う場合、Azure ADに登録されたドメイン名の単位で判定をしていました。
Azure ADにカスタムドメイン名として会社のドメイン名を登録したら、そのドメイン名をSSOで利用するドメインとして設定すると、カスタムドメイン名画面ではフェデレーションの欄にチェックが付きます。

その結果、xxxx@adfs.jp のようなユーザー名でサインインしたときに、adfs.jp ドメインがフェデレーションドメインだとわかると、ADFSサーバーへリダイレクトしてSSOアクセスの処理を開始していたのです。

おさらい：ADFSサーバーの廃止設定

特定のドメインに対するADFSサーバーの利用を止める場合、Convert-MSOLDomainToStandardコマンドレットを実行します。
すると、SSOアクセスは廃止され、Azure ADに同期されたユーザーのユーザー名とパスワードを入力してサインインする方式に切り替わります。

このとき、事前にシームレスシングルサインオンの設定をしておけば、Convert-MSOLDomainToStandardコマンドレットを実行することで、自動的にADFSサーバーからシームレスシングルサインオンにSSO方式が切り替わります。

段階的な切り替え

Convert-MSOLDomainToStandardコマンドレットを実行すればシームレスシングルサインオンに切り替えることができます。しかし設定はドメイン単位なので、基本的にすべてのユーザーの移行をいっぺんに行わなければなりません。それはIT管理者の立場からしてみれば、とてもリスクの大きい作業だと感じることでしょう。
そこで、Azure ADでは新しく一部のユーザーだけをADFSサーバーからシームレスシングルサインオンに切り替える段階的な移行方法をサポートするようになったのです。

では設定を見てみましょう。
Azure AD管理センター画面(https://aad.portal.azure.com)から[Azure AD Connect]をクリックし、[マネージドユーザーサインインの段階的なロールアウトを有効にする]をクリックします。

[段階的なロールアウト機能を有効にする] 画面で、パスワードハッシュ同期またはパススルー認証を選択し、移行対象となるユーザーをグループの単位で指定します。

ご覧のような感じでグループの選択を行ったら終わり。

これだけです。次回からサインインするときはADFS経由ではなく、シームレスシングルサインオンによるサインインになります。
ちなみに、この方法による移行方法は完全にADFSをやめてしまうわけではないので、
PowerShellコマンドレットで、Get-MsolDomainFederationSettingsコマンドレットを叩くと、今までのADFSサーバー設定が引き続き残っていることがわかります。

ADFSサーバーからシームレスシングルサインオンへの段階的な移行には、現状のADFSサーバーの状態に問題がないか確認したり、
クレームルールをAzure ADへどのように移行するか？ Office 365以外で証明書利用者信頼に登録されているクラウドアプリがある場合にどうやってAzure ADへ移行するか？
など検討しなければならない課題は色々あります。2020年にはこれらをまとめて学べるトレーニングコースを提供予定ですので、出来上がりましたら、改めてご案内させていただきます。

・参考URL
AAD Connect Healthを利用したADFSサーバーの監視
http://azuread.net/2015/08/21/aad-connect-health%E3%82%92%E5%88%A9%E7%94%A8%E3%81%97%E3%81%9Fadfs%E3%82%B5%E3%83%BC%E3%83%90%E3%83%BC%E3%81%AE%E7%9B%A3%E8%A6%96/

皆さんこんにちは。国井です。
このブログでは様々なトピックを取り上げて、色々な方にアクセスしていただいたおかげで10年以上が経過しました。その間にもテクノロジーは進化し、わかりやすいところで言えばADFSサーバーからAzure ADへの変化があったわけです。

ところが私が過去に執筆したADFSに関する投稿は未だに一定のアクセス数があり、
今あるADFSサーバーに対峙している方もまだまだ多いのではないかと思います。
ニーズが少なくなったと考え、かつて開催していたADFSトレーニングはもう終了をやめてしまいましたが、もし必要な方がいたらと思い、今日はかつて提供していたADFSトレーニングのテキストを公開してみることにしました。

とはいえ300ページを超える大作なので、分割して提供していこうと思います。
※演習操作手順書については前提条件となる環境によって手順が異なるので、ここでは(一部)割愛してお届けします。

■ ■ ■

目次

第1章 ID 連携の概要

第 1 章では、デジタルアイデンティティの概要と ID 連携の必要性について解説します。ID 連携を実現するためにマイクロソフトが提供するソリューション、ADFS (Active Directory Federation Services) と Azure AD の概要について解説します。

コンピューター システムの世界では、人やモノなどを識別する情報として、ユーザー名やコンピューター名などの情報が存在します。このような、人やモノを識別する情報をデジタルアイデンティティ (ID) と呼んでいます。

デジタルアイデンティティには、人やモノを識別する情報に付随する情報が含まれます。例えば、ユーザー名の場合、ユーザー名に付随する情報として、部署名、役職、事業所、電話番号などの情報がありますが、これらの情報もデジタルアイデンティティに含まれます。

デジタル アイデンティティを正しく確認できることで、コンピューターシステムでは、一人ひとりに合わせた適切なサービスを提供できるのです。

私たちがコンピューター システム上に存在する、様々なアプリケーションを利用する際、特定の利用者だけにアプリケーションを利用できるように ID の確認を行います。それが認証と承認です。

認証とは「本人確認」のことであり、コンピューターシステムの世界では一般にユーザー名とパスワードを利用して本人確認を行います。認証というと、ユーザーの認証が有名ですが、実際にはコンピューターの認証やサービスの認証など、様々な ID を対象に認証を行うことができます。
認証を通じて「本人確認」を行うことにより、誰かになりすましたユーザーであるか？、どこかのコンピューターになりすましたコンピューターではないか？など、「なりすまし」を防止する効果があります。

Active Directory の場合、ドメインをひとつの管理単位として認証と承認を行っています。Active Directory の認証と承認では、Kerberos (ケルベロス) と呼ばれる認証・承認のシステムを採用し、認証に成功すると、認証成功のあかしとしてドメインコントローラーから TGT と呼ばれるチケットが発行されます。

Active Directory で行った認証の結果に基づいて、クラウドや業務提携を結ぶ別組織への認可を行う仕組みを提供するのが ADFS サーバーです。ADFS サーバーでは認可を行うために使用する ST チケットの代わりに、クラウド等で汎用的に利用可能な「トークン」と呼ばれるデータを利用します。
Active Directory ドメインコントローラーと ADFS サーバーは次のような方法で連携し、クラウドや業務提携を結ぶ別組織への認証・認可を実現します。

① ユーザーはドメインコントローラーで認証
通常のサインインと同じように、ユーザー名とパスワードを入力してドメインコントローラーで認証を行います。

② 認証結果に基づき、ADFS でユーザーにトークンを発行
Active Directory で行われた認証の結果に基づき、ADFS サーバーに対してトークンの要求を行います。ADFS サーバーは要求を行うユーザーに合わせて、名前やメールアドレスなどの情報 (クレーム) を含めたトークンを発行します。
また、トークンを発行するときには、あらかじめ条件を設定し、条件を満たさないユーザーからのトークン発行要求に対して、トークン発行そのものを拒否する認可機能を備えています。

③ トークンをアプリに提示して最終的なアクセス許可レベルを決定
トークンを取得したユーザーはアプリに対してトークンを提示し、アクセス許可を得ます。どのようなアクセス許可が割り当てられるかはトークンの中に含まれるクレームの情報に基づいてアプリが決定します。

以上のような流れで処理を行うことによって、次のようなメリットが得られます。

認証と認可を行う組織を別々にできる

ADFS サーバーを利用することによって、認証を行うサーバーと認可を行うサーバーを別々のサーバーにすることができます。つまり、認証サーバーと認可サーバーを異なる組織に配置して運用することが可能です。

クレーム情報をもとに認可が行える

ドメインの場合、ユーザーやグループを基準にアクセス許可を割り当てていました。ドメインで発行されるチケットにユーザーやグループの情報が含まれていたからです。しかし、ADFS サーバーを利用する場合、トークンに含まれる情報 (クレーム) は自由に決められます。そのため、アプリが求める情報をトークンに含まれるように構成したり、部署名や役職などをクレームに入れて部署名や役職名をもとにしたアクセス許可を設定したりすることができるようになります。このように ADFS サーバーを利用した認証・認可はクレーム情報をもとに処理されることから、「クレーム ベース認証」と呼ばれることがあります。

組織間でシングルサインオンが実装できる

クレーム ベース認証は認証と認可を行う組織を別々にできます。そのため、自分の組織で 1 度だけ認証を行い、その認証結果をもとに別の組織で認可を行う、組織間でのシングル サインオンが実装できるメリットがあります。

クレーム ベース認証では、ID 情報を認証側だけに持たせて運用する方法と、認証側・認可側の両方に持たせる方法があります。

クレームベース セキュリティ

クレーム ベースセキュリティの場合、認可サーバー側で ID 情報を持ちません。認可サーバーでは、トークンに含まれる ID 情報を使って、ID を識別します。ADFS サーバーを利用する多くのアプリケーションではクレーム ベース セキュリティの方法で、認証サーバーと認可サーバー間の連携を実現しています。

ID 連携

ID 連携の場合、認証サーバーと認可サーバーの両方でID 情報を持ちます。認証サーバーで認証した結果に基づいてトークンを渡すことで、認可サーバーにおける特定の ID で認証を済ませたとみなします。この方法で連携する場合、認証サーバーと認可サーバーで同じ ID 情報を持たなければならないため、Microsoft Forefront Identity Manager (FIM) などを利用して、ディレクトリ サービスに格納されている ID 情報を同期します。このとき、ID 情報を同期し、認可のサーバーに ID 情報を登録するプロセスを「プロビジョニング」と呼びます。

ADFS サーバーで発行されるトークンは 1 つ以上のクレームから構成されています。クレームとはユーザーなどの特徴を表す情報で、クレーム ベース認証では、名前、メールアドレス、電話番号などの様々な情報を扱うことができます。

クレーム ベース認証で扱われるユーザー情報は、認証サーバーに格納されている情報を活用することができます。例えば、Active Directory ドメインを認証サーバーとして利用していれば、Active Directoryユーザーのプロパティに登録されている属性情報をクレームとして利用できます。

1 つ以上のクレームから構成されるトークンは、ADFS から発行された後に改ざんされることのないよう、トークン全体に対してデジタル署名を施します。このとき、デジタル署名に使われる証明書を「トークン署名証明書」と呼びます。

前のページで ID 連携を利用することで、認証側で認証したユーザーと認可側で保有するユーザーを関連付けて、シングルサインオンを実現できることを解説しました。

では、2つのディレクトリに格納されているユーザーはどのように関連付けるのでしょうか？

ID 連携で 2つのディレクトリに格納されているユーザーを関連付けるときは、あらかじめキーとなるクレームを決めておき、そのクレームの値が同じであるかをチェックすることで、2 つのユーザーが同一のユーザーであると判断します。

クラウドで提供されるアプリで ID 連携を実装する場合、Google Apps や Salesforce では
NameIdentifier クレームに含まれるユーザー名 (メールアドレス形式) が 2つのディレクトリで同一であることをチェックします。

ID 連携のためのプロビジョニング

2つのディレクトリにある ID を連携させるためには、プロビジョニングを行い、2 つのディレクトリに同じ ID を持つ必要があります。Office 365 では、後述するディレクトリ同期ツールによって、2つのディレクトリでの同期を実現しますが、その他のアプリでは何かしらの方法で ID 同期を行う仕組みを持つ必要があります。

編集後記

ADFSトレーニングは2017年8月の開催を最後に開催していないのですが、会計で言うところの減価償却も終わっただろうし、有償で受講していただいた方にお届けしてから3年以上も経過するので、もう良いだろうと思い、公開することにしました。
Advent Calendarっぽく25回に分割してお届けしますので、ゆっくりと読み進めてもらえれば嬉しいです。

<続く>

The post ADFSトレーニングテキスト全文公開チャレンジ(1) first appeared on Always on the clock.

皆さんこんにちは。国井です。
前回からスタートしたADFSトレーニングテキスト全文公開チャレンジ。
Advent Calendar風に毎日公開していこうかなと思っているのですが、
第2回は「第1章 ID連携の概要」から後半部分の「ID連携とは」をお届けします。

■ ■ ■

ADFS サーバーを利用して ID 連携を実装する場合、アクセスするアプリが自社内にあるのか、またはクラウドなどの領域外にあるのかによって認証・認可のステップは異なります。

自社内にあるアプリにアクセスする場合、Active Directory で認証を行った後、同じく自社内にある ADFS サーバーが認可を行った結果としてアプリのためのトークンを発行し、そのトークンを持って直接アプリにアクセスします。そして、アプリはトークンの内容に基づいて最終的なアクセスの可否を決定 (認可) します。

それに対して、領域外にあるアプリにアクセスする場合、異なる領域で利用可能なトークンを発行した上でアプリにアクセスする必要があります。そこで、ADFS サーバーでは、異なる領域のトークンを発行するサーバー(トークンを発行するサーバーを STS と呼びます。詳しくは後述します。) にアクセスするためのトークンを発行します。
以上のような動作によってアクセスの可否を決定するため、ADFS サーバーとアプリでの認可に加えて、STSでの認可も同時に行うことができます。

次のページから、領域外にあるアプリにアクセスする場合を例に、具体的にそれぞれのサーバーにアクセスする際の処理について解説します。

ADFS を利用して ID 連携機能を実装した場合、以下のような動作で認証と認可の処理を行います。

① アプリケーションにアクセスすると、セキュリティ トークンを要求される
クライアント コンピューターから ID 連携を利用したアプリケーション (APP サーバー) に接続すると、トークンが必要であることをクライアントに通知 (リダイレクト) します。

② 認可側の ADFS サーバーにアクセスし、認証先を指定される
トークンが必要であることを知ったクライアント コンピューターは①で得た情報をもとに認可側の ADFS サーバーに接続します。ここで、クライアント コンピューターが認証を行う先を紹介します。もし、複数の認証先が存在する場合には、クライアントコンピューターから選択することも可能です。

③ 認証側の ADFS サーバーにアクセス
②の結果、どこで認証を行うか決定したら、クライアントコンピューターは認証を行う場所にある ADFS サーバーに接続します。すると、トークンを取得するために事前に認証を行うよう、認証用のエンドポイント (Web ページ) にリダイレクトします。

④ 認証側の ADFS サーバーで認証を要求
クライアント コンピューターは ADFS サーバーの認証用ページにアクセスすると、認証を開始します。あらかじめ決められた認証方法に基づいて、認証を行います。

⑤ 認証 & 属性値の取得
クライアント コンピューターから④で入力した資格情報は認証側の ADFS サーバー経由で認証システムに送信され、正しい資格情報であることを確認します。ADFS では、認証システムに Active Directory を利用するため、Active Directory に対して資格情報の確認を行います。認証が成功すると、その結果をもとに、メールアドレスや姓名など、ユーザーの属性値を Active Directory から取得します。属性値の取得は Active Directory からだけでなく、SQL Server や LDAP ディレクトリから取得することも可能です。

⑥ 認証結果をもとに特定のクレームが含まれるトークンを発行
⑤で入手した属性値をもとに、ADFS サーバーはユーザーのためのトークンを発行します。
資格情報の確認 (認証) は Active Directory が行ったのに対して、トークンの発行は ADFS サーバーが行う、というように、認証とトークンの発行は別々のサーバー役割によって行われている点に注目してください。

⑦ 認可側の ADFS サーバーにアクセスし、トークンをもとに認可を行う
認証トークンが発行されると、クライアント コンピューターはトークンを持って、認可側の ADFS サーバーにアクセスします。すると、ADFS サーバーは認証トークンを確認し、アクセス可否を判断します。また、ADFS サーバーであらかじめ定義されたルールに基づき、認証トークン内のクレームは必要に応じて書き換えられ、認可トークンとして利用できるようにします。

⑧ 認可側の ADFS サーバーで発行されたトークンを利用してアクセス
認可トークンを受け取ったクライアント コンピューターは、認可トークンを持って、アプリケーションサーバーにアクセスします。すると、アクセスに必要な権限を持ったユーザーとみなし、アプリケーションへのアクセスを許可します。

以上のように、ADFS サーバーでは ID 連携の方式に基づく、認証と認可を行うことにより、異なる組織にあるアプリケーションにアクセスできるようになります。
このとき、認証側と認可側に ADFS サーバーをそれぞれ配置することで、ID 連携における、認証と認可を別々の場所で行うことができます。

前のページでは、ID 連携の動作詳細について確認しました。一連の動作の中で利用された資格情報とトークンについて、整理しましょう。

Windows 認証に使用した資格情報
手順④で行われた認証は Active Directory に対する認証です。この認証に成功すると、資格情報をもとにトークンを作成するための作業に入ります。

認証側 ADFS サーバーで発行されるトークン
Windows 認証を行った後、認証側 ADFS サーバーに対してトークンの要求を行います。ここで要求・発行されるトークンは、ID 連携で使われる、認証トークンになります。

認可側 ADFS サーバーで発行されるトークン
認証トークンを持って、認可側の ADFS サーバーにアクセスし、アクセスを認可された場合、新たなトークンが発行されます。このトークンは認可トークンになります。

前のページで 3 つの資格情報とトークンについて解説しましたが、そのうち、ADFS サーバーが発行するトークンとして認証トークンと認可トークンがありました。このように、ID 連携の中でトークンを発行するサービスを STS (Security Token Serivces) と呼びます。ADFS を利用している場合、ADFS サーバーがトークンを発行する機能を持っているため、ADFS サーバーは STS であると言えます。

また、ID 連携で認証と認可を行う場合、認証を行う側と認可を行う側に分かれて、それぞれ処理が行われていました。ADFS では、認証を行う側のシステム/ネットワーク全般を Claim Provider (CP)、認可を行う側のシステム/ネットワーク全般を Relying Party (RP) と呼びます。

なお、STS、CP、RP という名称については、ADFS における呼び方であり、ID 連携の規格のひとつである、SAML2.0 では異なる呼び方をします。詳しくは、「WS-Federation / SAML とは」のページを参照してください。

このテキストでは、ADFS における呼び方で名称を統一します。

RP 側の STS がCP側のSTSで発行した認証トークンの内容を解釈し、認可トークンを発行するとき、どのCP側のSTSから発行された認証トークンでも扱ってよいわけではありません。RPが信頼したCPから送られてきた認証トークンだけを扱うようにしなければ、悪意のある第三者が作成した認証トークンを疑いもせずにRPが処理してしまう可能性があるからです。

RPが適切なCPで発行された認証トークンだけを扱えるようにするために、STSでは信頼関係という設定を行います。信頼関係はSTSどうしで設定するもので、信頼関係を設定することで、決められたCPとRPの組み合わせで認証と認可を行うように定義できます。

クレーム ベース認証を行う際、利用可能な認証先が複数存在する場合、ユーザーはどこで認証を行うか選択することができると解説しました。このとき、利用可能な認証先の単位を「レルム (Realm)」と呼びます。複数のレルムの中から認証先をユーザーが選択すると、選ばれたレルムは CP として ID 連携の中で動作するようになります。

Active Directory ベースの認証と承認の仕組みを利用すると、承認の仕組みはアプリケーションの中で実装されます。アプリケーションの中で、誰にどのようなアクセス (権限) を割り当てるかを定義していたため、具体的な設定はアプリケーションによってまちまちでした。

一方、クレーム ベース認証 (ID 連携) を使ってアクセス制御 (認可) を行う場合、ADFS サーバーで認可トークンを発行するタイミングで行います。そのため、アプリケーションは認可のための仕組みを一切持つ必要がありません。つまり、アプリケーションと認可機能は独立して実装できます。

クレーム ベース認証を利用するアプリケーションは、認可を行わない代わりに、認可トークンを受信し、解釈できなければなりません。マイクロソフトでは Windows Identity Foundation (WIF) というコンポーネントを提供し、トークンの解釈とトークン内のクレームの識別を実現しています。WIF は ASP.NET または WCF アプリケーションと共に利用することができます。

WIF には実行環境を提供する WIF そのものと、WIF を利用した開発環境を提供する WIF SDK があります。WIF はアプリケーションがクレームを識別できるようにするためだけでなく、ADFS そのものの実行基盤にも活用されます。そのため、アプリケーションを実行するサーバーと、ADFS を実行するサーバーでそれぞれ必要となります。一方、WIF SDK はクレーム対応アプリケーションを開発する環境でインストールして利用します。

Visual Studio を利用して WIF アプリケーションを作成するには、Windows Identity Foundation SDK 3.5 以上が前提条件になりますので、事前にインストールしてください。

■ ■ ■

編集後記

このテキストを初めて作ったのは2012年頃で、まだID連携の必要性が世間で理解されていない頃でした。
当時は「ブラウザーにパスワードをキャッシュすればよいのに、わざわざサーバーをインストールする意味がわからない」などと言われたものです。
最後に今は亡きWIF(現.NET Framework内のコンポーネント)の説明を入れましたが、WIFが..というよりはADとクレームベースではアクセス制御の仕組みが違うんだよ、ということを知ってもらいたくて、あえて残しておきました。
明日もお楽しみに。

<続く>

The post ADFSトレーニングテキスト全文公開チャレンジ(2) first appeared on Always on the clock.

皆さんこんにちは。国井です。
3日目にして早くも公開するのを忘れそうになりましたｗ 今日は第2章「ADFSのインストールと初期設定」からADFSのコンポーネントについて解説します。

■ ■ ■

第 2 章では、ADFS サーバーをインストールする環境として活用する Azure 仮想マシンと仮想ネットワークの概要、そして ADFS をインストールするために必要な前提条件や効果的なインストール方法について確認します。

自組織とクラウドサービス間で ID 連携を行う場合、それぞれの環境に STS を用意する必要があります。このとき、クラウドサービスでは Azure AD、自組織では ADFSサーバーを利用して STS の機能を提供します。

ADFS サーバーを実装する場合、ADFS サーバー以外にも、ADFS サーバー用のデータベースサーバー、トークンを発行するユーザーを識別するために使用する Active Directory ドメインサービス、外部からのトークン発行要求を受け付ける Web アプリケーションプロキシが必要になります。以下に、それぞれのコンポーネントの特徴について紹介します。

■Active Directory
Windows Server 2016 の ADFS では Active Directory だけでなく、OpenLDAP 等のサード パーティー製ディレクトリ サービスを利用することもできますが、一般的には Active Directory を利用して認証機能を実装します。

■ADFS サーバー
ADFS サーバーはオンプレミスの STS (IdP/CP) として動作します。ADFS サーバーは負荷分散装置を利用することで、2台目以降のサーバーを実装し、高可用性構成を実装することも可能です。

■ADFS サーバー用データベース
ADFS サーバーで使用するデータベースには SQL Server または組み込みのデータベース (WID) を利用できます。SQL Server を利用する場合には SQL Server のクラスタリング機能で、WID の場合には ADFS サーバーの機能で複数台のサーバーによるデータベースの提供が可能です。

■Web アプリケーションプロキシ
Webアプリケーションプロキシはインターネットから ADFS サーバーへのアクセスを受け付ける、ADFSのプロキシ サーバーとして動作します。また、Webアプリケーションプロキシは ADFS サーバーと同じく、Web サービスとして提供されるため、負荷分散装置を利用することで高可用性構成を実装することも可能です。

■Azure AD Connect
Azure AD に対するプロビジョニングを行う役割としてマイクロソフトの Web サイトより提供されるAzure Active Directory Connect (Azure AD Connect) を利用します。Azure AD Connect は新規または既存のサーバーにインストールして利用することができ、インストールが完了すると自動的に Azure AD に対するディレクトリの同期を実行します。AAD Connect は複数のサーバーにインストールすることはできますが、複数のサーバーで同時にサービスを実行することができません。そのため、ステージングモードを利用して、アクティブなサーバー以外ではサービスを実行しないように構成します。また、アクティブなサーバーで障害が発生した時には、手動でアクティブなサーバーを切り替える必要がある点にも注意してください。

Microsoft Azure における仮想マシンの実装方法が確認できたら、続いて ADFS サーバーで必要となるコンポーネントについて確認します。ADFS サーバーでは以下のコンポーネントを使用します。

■証明書の定義
ADFS ではトークンの署名や通信の暗号化などに証明書を利用します。そのため、それぞれの通信等で必要となる証明書を事前に用意しておきます。

■フェデレーションメタデータの定義
フェデレーション メタデータとは、ADFS サーバー等で利用可能なサービス コンポーネントを定義した XML ファイルです。ADFS サーバーでは、セットアップを行うことにより、自動的に生成されます。

■RP の信頼関係構築
STS 信頼を設定し、クラウドサービス (Azure AD) との間で ID 連携が行えるよう、構成します。

■クレームルールの定義 (CP と RP で実装)
クレーム ルールとは、トークンの中で扱うクレームの情報を定義するためのコンポーネントです。

次のページから、それぞれのコンポーネントについて、詳しく解説します。

ADFS では、次の 3 種類の証明書を利用します。既定では、自己署名の証明書が実装されていますが、必要に応じて認証局から発行された証明書に変更して、利用することができます。

■SSL 証明書
ADFS サーバーとクライアントコンピューターの間で行われる通信を SSL 暗号化するために必要な証明書で、ADFS サーバーに証明書を実装し、利用します。ADFS サーバーを外部からのアクセスを受け付けるように構成する場合、SSL 証明書には公的な認証局から発行された証明書を利用する必要があります。

■トークン署名証明書
ADFS サーバーで作成されたトークンを悪意の第三者によって改ざんされることを防ぐためにトークンはデジタル署名されます。デジタル署名を行うときに利用される証明書がトークン署名証明書です。トークン署名証明書は ADFS サーバーに証明書を実装し、利用します。

■トークン暗号化解除証明書
クライアントから送られる認証関連情報を暗号化する際、ADFS サーバーはトークン暗号化解除証明書を利用してクライアントが施した暗号化を解除します。

フェデレーション メタデータには、エンドポイントの定義、クレームベース認証を行うために利用可能なクレーム情報、証明書の公開キーが含まれており、ADFS を利用するときには、フェデレーションメタデータを参照し、どのようなクレーム ベース認証が可能であるか識別します。

■エンドポイントの定義
エンドポイントは、ADFS のサービスを利用するための「接続口」としての役割を果たします。フェデレーション メタデータでは、エンドポイントの場所が記されているため、クライアントコンピューターはADFS サーバーに接続し、クレーム ベース認証を行うために必要な様々なサービスを利用することができます。

■クレームベース認証を行うために利用可能なクレーム情報
トークンに追加するクレームの情報は、あらかじめフェデレーションメタデータで定義した情報だけが登録可能です。

■証明書の公開鍵
ADFS サーバーに接続し、通信するためには様々な証明書を利用します。そのときに必要な証明書の公開鍵の情報がフェデレーションメタデータには記載されています。

これらの情報が含まれるフェデレーション メタデータは、STS の信頼関係を設定するときに使用します。ADFS サーバーで信頼する相手のフェデレーション メタデータをインポートすることにより、フェデレーション メタデータに記された STS とのクレーム ベース認証や ID 連携が実現できるようになります。また、フェデレーション メタデータは WS-Federation パッシブ プロファイルまたは SAML 2.0 Web SSO プロファイルで使用します。

ADFS サーバーの各種サービスに接続するためのエンドポイントは、すべて Web サービスとして提供されており、それぞれ別々の URL が提供されています。ADFS エンドポイントは、ADFS 管理ツールの [サービス] – [エンドポイント] から確認できます。

編集後記

今回はADFSサーバーのコンポーネントについて解説をしました。Active Directoryドメインコントローラーの他、ADFSサーバー、ADFSプロキシ、Azure AD Connectのサーバーが必要になり、さらにADFSサーバーとADFSプロキシは冗長化のために2台ずつ用意するという、シングルサインオンだけで何台サーバー用意するんだ！と言いたくなるような構成ですね。冗長化については別のトレーニングコースで扱っていたため、このコースでは詳細について触れないのですが、このあたりの情報は当時は本当に少なく、みんな苦労したものです。今でも苦労されている方がもしいらしたらコメントやTwitterなどで反応をいただければ追記するかもしれません。ではまた明日！

The post ADFSトレーニングテキスト全文公開チャレンジ(3) - ADFSのコンポーネント first appeared on Always on the clock.

皆さんこんにちは。国井です。
ADFSトレーニングテキスト全文公開チャレンジの4日目はSTS信頼についてです。次回の内容が大きな内容になるので、今回は少なめの公開です。ぱっと読めるのでお付き合いください。

■ ■ ■

ADFS サーバーで、信頼関係を設定する場合、CP と RP で利用するリソースに対して、個別に信頼関係を設定します。以下では、具体的に信頼関係を設定すべき相手を解説しています。

■CP が利用する Active Directory ドメインの定義
ADFS では、トークンを発行する前に行われる認証に Active Directory を利用します。CP の [要求プロバイダー認証] に Active Directory ドメインを登録し、ADFS サーバーと Active Directory 間の信頼関係を設定します。[要求プロバイダー認証] には、既定で ADFS サーバーが参加する Active Directory ドメインが登録されています。

■CP が利用する RP の定義
CP で発行され認証トークンを、クライアントを通じて受け渡しする RP の定義を行います。CP の [証明書利用者信頼] で RP の ADFS サーバーを登録し、CP が RP を信頼する信頼関係を定義します。CP と RP が同一の ADFS サーバーの場合には、この設定は不要です。

■RP が利用する CP の定義
CP で発行され認証トークンを、RP が受け取れるようにするための定義を RP で行います。RP の [要求プロバイダー認証] で CP の ADFS サーバーを登録し、RP が CP を信頼する信頼関係を定義します。CP と RP が同一の ADFS サーバーの場合には、この設定は不要です。

■RP が利用するアプリケーションの定義
RP で発行された認可トークンを提示する先となるアプリケーションサーバーを定義します。RP の [証明書利用者信頼] で アプリケーション サーバーを登録することで、RP とアプリケーションサーバー間の信頼関係が確立されます。

CP として利用している ADFS サーバーに RP となるレルムを定義する場合、ADFS 管理ツールの [証明書利用者信頼] から新しい信頼を設定します。新しい信頼の設定方法には以下の 3 つの方法があります。

■自動設定
Office 365 (Azure AD) を RP として証明書利用者信頼を設定する場合、Office 365で用意されたコマンドレット (コマンドレットの詳細については次の章で解説します) が用意されており、コマンドレットを実行することで自動的に設定されます。

■フェデレーションメタデータを登録して信頼を設定
[証明書利用者信頼の追加ウィザード] で RP となるレルムで公開されているフェデレーション メタデータを指定します。フェデレーションメタデータはクラウドで公開されている URL を指定して定義する方法と、XML ファイルを証明書利用者信頼に登録する方法があります。

■識別子と STS のエンドポイントを登録して信頼を設定
RP でフェデレーションメタデータが公開されていない (もしくは存在しない) 場合、RP で事前に定義された識別子と、RP でトークンの受け渡しを行う STS のエンドポイント (URL 形式) をそれぞれ指定します。識別子は一般に URL の形式もしくは URN の形式で記述します。なお、URN の形式は大文字・小文字を区別することに注意してください。

編集後記

CPとRPの信頼関係の設定について今回は解説しました。ADFSサーバーでは要求プロバイダー信頼と証明書発行信頼という謎な日本語訳のメニューがありました。これらのメニューは英語版のADFSだとClaim Provider TrustとRelying Party Trustとはっきり書いてあるので、なんだCPとRPのTrust(信頼関係)の設定なんだ！とすぐにわかるようになっています。日本語訳してくれなかったら皆がこれほど理解に苦しむこともなかったのに。。

The post ADFSトレーニングテキスト全文公開チャレンジ(4)–STS信頼 first appeared on Always on the clock.

皆さんこんにちは。国井です。
Advent Calendar風にお届けしてきたADFSトレーニングテキスト全文公開チャレンジですが、しっかり土日は公開せずにお休みさせていただきました。
週も明けて改めて続きを公開していきます。今回はADFSサーバーのインストールと必要な要素についてです。

■ ■ ■

ADFS のインストールを行うときには、次のステップで実装します。

■認証局環境の実装
前のページで解説した 3 種類の証明書が利用できるよう、環境を整えます。

■データベースの準備
ADFS のデータベースには、OS 標準で用意されている WID (Windows Internal Database) または SQL Server を利用できます。SQL Server を利用する場合には、ADFS サーバーをインストールする前にインストールしておかなければなりません。

■サービスアカウントの作成
ADFS サービスを実行するためのサービスアカウントを用意します。ADFS ではグループの管理されたサービスアカウントを利用することを推奨しており、事前に作成しておくことをお勧めします。

■ADFS のインストール
Windows Server 2016 の [役割と機能の追加] から ADFS を追加します。ADFS の役割の追加後に実行可能な [フェデレーション サービスの構成] を実行し、ADFS の初期設定を行います。

■フェデレーションサービス名の構成
ADFS の名前を意味するフェデレーションサービス名は ADFS サーバーのインストールと共に自動的に設定されますが、必要に応じて変更します。

ADFS で利用する証明書を実装するときには、以下の点に注意してください。

■証明書の名前をフェデレーションサービス名と同じにする
SSL による通信を行う際、クライアントコンピューターは SSL 通信を行うホスト名として、フェデレーション サービス名 (ADFS サーバー名ではない！) を指定します。そのため、SSL 通信を行うための証明書をはじめ、ADFS サーバーで使用する、すべての証明書はフェデレーションサービス名と一致している必要があります。

■証明書の発行要求や入れ替えに IIS は利用できない
Windows Server 2012 R2の ADFS サーバーより、IIS を伴わずに ADFS がインストールされるようになりました。そのため、SSL 証明書は IIS 管理ツールからインストールしたり、証明書の発行要求を行ったり、入れ替えをしたり、することができません。

証明書のインストールと入れ替えには ADFS 管理ツールを使用します。また、証明書の発行要求には別のサーバーにインストールされた IIS を利用するか、certreq.exe コマンドを利用する方法が一般的です。

・certreq.exeによる証明書発行要求 (CSR) の作成
Certreq.exe -new certreq.inf certreq.csr

・certreq.exeによる証明書の作成
Certreq.exe -accept certreq.cer

■証明書の有効期間に伴う証明書の書き換え (トークン署名証明書)
証明書には有効期間があります。有効期間が近づいたら書き換えを行い、期限切れにならないように構成します。トークン署名証明書には、既定で自己署名証明書が使われており、証明書の有効期間は Get-ADFSProperties コマンドレットによって 365日に設定されています。そして、365日後に ADFS が利用できなくなることを防ぐため、ADFS サーバーではロールオーバーと呼ばれる機能を実装し、有効期間が近づいたら証明書の書き換えを行い、証明書の延長を行います。ところが、証明書の書き換えには異なる証明書の鍵を利用して行われるため、フェデレーションメタデータに記載された鍵情報が変わってしまい、結果としてフェデレーション メタデータの再発行をしなければなりません。

このような問題を解決するためには、2 つの方法があります。
ひとつは、商用認証局から発行された証明書を利用することです。トークン署名証明書にはSSL 証明書と同じ証明書を利用することができるため、SSL 証明書の入れ替えのタイミングでトークン署名証明書を入れ替えるように運用することができます。また、商用認証局の証明書は同じ鍵で証明書の延長ができるというメリットがあります。

もうひとつは、Set-ADFSProperties コマンドレットで証明書の有効期間を長く設定することです。次のコマンドレットを実行することで、有効期間を 10 年に延ばすことが可能です。

Set-ADFSProperties -CertificateDuration 3650
Update-ADFSCertificate –Urgent

■証明書の有効期間に伴う証明書の書き換え (SSL 証明書)
トークン署名証明書と同じく、SSL 証明書にも有効期間があり、有効期間が近づいたら書き換えを行います。SSL 証明書には公的な認証局から発行された証明書を利用するため、一般には証明書の鍵を書き換えずに有効期間だけを書き換えることができます。このことはフェデレーションメタデータの再発行を必要しないことを意味します。
一方、SSL 証明書にはトークン署名証明書のようなロールオーバー機能がないため、手動で書き換えを行わなければなりません。書き換え操作は新しい証明書を ADFS サーバーにインストールした後、それぞれの ADFS サーバーで次のコマンドレットを Windows PowerShell から実行します。

Get-ChildItem cert:\LocalMachine\My | fl
#1 台目の ADFS サーバーでの実行コマンドレット
Set-AdfsSslCertificate -Thumbprint <Thumbprint>
#2 台目以降の ADFS サーバーでの実行コマンドレット
Set-AdfsCertificate -CertificateType Service-Communications `
-Thumbprint <Thumbprint>
Restart-Service adfssrv –Force

<Thumbprint> 欄には Get-ChildItem cert:\LocalMachine\My | fl コマンドレットで確認した、新しい証明書の Thumbprint の値が入ります。
一方、Web アプリケーションプロキシでは、新しい証明書をインストールした後、それぞれのサーバーで次のコマンドレットを Windows PowerShell から実行します。

Get-ChildItem cert:\LocalMachine\My | fl
Set-WebApplicationProxySslCertificate -Thumbprint <Thumbprint>
Get-WebApplicationProxyApplication | `
Set-WebApplicationProxyApplication `
-ExternalCertificateThumbprint <Thumbprint>

Certreq.exe で使用する要求ファイルの作成

Certreq.exe で CSR を作成するためには CSR に含まれる内容を事前に inf ファイルとして作成しておく必要があります。inf ファイルはメモ帳を開いて、以下のような書式で記述します。

[NewRequest]
Subject = “C=JP,ST=Tokyo,L=Shinagawa-ku,O=adfs,CN=fs1.adfs.jp”
Exportable = TRUE
KeyLength = 2048
MachineKeySet = TRUE
SMIME = FALSE

認証局によって、決められた記述方法を定義している場合があります。詳しくは認証局にお問い合わせください。

証明書の入れ替え時のエラー

上記の方法によって証明書の入れ替えても、Office 365の一部サービスでは証明書入れ替えが正しく反映されない場合があります (KB2973873)。
こうした問題には、Windows PowerShell から「netsh http show sslcert」コマンドを使用して設定を反映させます。

Get-ChildItem cert:\LocalMachine\My | fl
netsh
HTTP
DELETE SSLCert IPPORT=0.0.0.0:443
ADD SSLCert IPPORT=0.0.0.0:443 Certhash=<Thumbprint> Appid={5d89a20c-beab-4389-9447-324788eb944a}

ADFS サーバーで利用するデータベースには、WID (Windows Internal Database) と SQL Server のいずれかを選択できます。WIDを選択した場合、WID は ADFS サーバーのインストールとともにインストールされるので、事前準備は必要ありません。しかし、SQL Server を利用する場合は ADFS サーバーのインストール中にデータベースを選択するため、SQL Server 自体を事前にインストールしておく必要があります。また、データベースとして WID を選択した場合、SAML Token Replay Detection と SAML Artifact Resolution を利用できない、マスター データベースを持つ ADFS サーバー (最初にインストールした ADFS サーバー) でしか ADFS 管理ツールを利用できない、といった制約があります (ただし、Office 365の実装では使用しません)。

しかし、ADFS サーバーのデータベースに格納される情報は ADFS サーバーの構成情報だけであり、トークンに関わる情報は格納されることはありません。そのため、ADFS 管理ツールから変更を行わなければ、データベースの内容が変更されることもないので、データベースへの I/O を考慮に入れたり、高頻度でのバックアップを行う必要はないでしょう。

データベースサーバーの冗長構成を実装する場合、WID では 2 台以上の WID を利用した ADFS サーバーを実装することで、1 台目の ADFS サーバーが持つ WID データベースから定期的にレプリケーションを行います。一方、SQL Server を利用する場合、SQL Server 自身で利用可能な冗長構成を活用します。

既定では、ADFS サーバーのサービスを実行するためのサービス アカウントにグループの管理されたサービス アカウントを使用します。グループの管理されたサービスアカウントは複数のサーバーで共通のサービスアカウントを利用するために設計されたサービス アカウントで、Windows Server 2008 R2 以降のActive Directory で作成することができます。

グループの管理されたサービス アカウントは ADFS の実装時に作成することが可能です。しかし、グループの管理されたサービス アカウントを作成するときに生成されるパスワードは KDS ルートキーをもとに作られるため、KDS ルートキー自体、事前に作成しておかなければ、グループの管理されたサービスアカウントの作成自体、失敗します。KDS ルートキーを作成するときは次のコマンドレットを実行します。

Add-KdsRootKey -EffectiveTime ((Get-Date).addhours(-10))

一方、グループの管理されたサービス アカウントを作成するときは次のコマンドレットを実行します。

New-ADServiceAccount -Name <サービス アカウント名> `
-DNSHostName <サービスを利用するサーバーの名前>

DNSHostName スイッチではグループの管理されたサービス アカウントを使用するサーバー名を指定します。ただし、ADFS サーバーの構成ウィザードではサービスアカウントを指定することにより、自動的に DNSHostName は設定されるため、-DNSHostName オプションで明示的に ADFS サーバー名を指定する必要はありません。(-DNSHostName オプションは指定しないと New-ADServiceAccount コマンドレット自体、動作しないので適当なサーバー名を指定しておいてください)

ADFS サービスのサービスアカウントは管理者権限がなくてもサービスを動作させることは可能です。しかし、サービス アカウントに管理者権限がないと、ADFS サーバーのインストール中に SPN (Service Principal Name) の登録に失敗します。そのため、管理者権限のないユーザーをサービスアカウントとして利用するときには、SPN の登録を ADFS サーバーのインストール完了後に手動で行う必要があります。SPN の登録を行うときには、次のコマンドを実行します。

setspn -a host/adfssrv <ドメイン名>\<サービス アカウント名>
setspn –a HTTP/<ADFS サーバーの FQDN> <ドメイン名>\<サービス アカウント名>

編集後記

ADFSサーバーのインストールって本当面倒ですよね。インストールそのものはウィザードを実行すればよいだけなんだけど、前提条件として行わなければならない要素や設定が多く、実装に困らされたものです。特にトークン署名証明書の有効期間が1年という問題は何も知らずにインストールすると1年後に誰もサインインできなくなるというトラブルを引き起こします。だから証明書の有効期間を延ばしておくというのはセオリーなんだけど、そういうことって当時は情報がなかったのですよね。
今回はインストールと言いつつ、インストールそのものの手順にたどり着けなかったですが、次回はきちんとお伝えしますので、お楽しみに。

The post ADFSトレーニングテキスト全文公開チャレンジ(5) – ADFSのインストール(前編) first appeared on Always on the clock.

皆さんこんにちは。国井です。
ADFSトレーニングテキスト全文公開チャレンジの第6回目はADFSサーバーのインストールについてです。
前回は前提条件の話でしたが、今回はインストールそのものの話が登場します。
早速どうぞ！
■ ■ ■

ADFS サーバーのコンポーネントは Windows Server 2016 の役割として提供されます。そのため、役割を追加し、初期構成を行うことで、追加でコンポーネントをダウンロードすることなく、ADFS サーバーを利用するために必要な設定は完了します。

一方、マイクロソフトでは Office 365 (Azure AD) との ID 連携を簡単に実装できるようにするため、Azure Active Directory Connect (Azure AD Connect) と呼ばれるツールを提供し、Azure AD Connect のウィザードに沿ってインストールすることもできます。Azure AD Connect を利用する場合、1 回のウィザードで複数台のADFS サーバーを同時にインストールできるだけでなく、後述する Web アプリケーションプロキシも同時にインストールできるため、Azure AD との組み合わせで ADFS サーバーを利用するときは有効なツールといえます。

Azure AD Connect のウィザードで ADFS サーバーや Web アプリケーションプロキシをインストールする場合、遠隔からインストール操作を行うことになります。そのため、遠隔からインストールするために必要な権限を割り当てておく必要があります。ドメイン管理者としての権限があれば ADFS サーバーをインストールすることができますが、Web アプリケーションプロキシとなるサーバーはワークグループのサーバーであるケースがあるため、その場合には次の設定を行ってください。

■Azure AD Connect を実行するサーバーで次のコマンドレットを実行します

Set-Item WSMan:\localhost\Client\TrustedHosts `
-Value <Web アプリケーションプロキシサーバー> -Force

■Web アプリケーションプロキシとなるサーバーで次のコマンドレットを実行します

Enable-PSRemoting -force

なお、2 台以上の ADFS サーバーを設置して運用する場合、クライアントからのアクセスを受け付けるためにハードウェアの負荷分散装置またはネットワーク負荷分散 (NLB) を利用します。このとき、クライアントからの ADFS サーバーへのアクセス要求は機械的に分散されるため、どちらの ADFS サーバーに接続しても同じような STS としての処理ができるよう、サーバーファーム内の各サーバーには同じ証明書を実装してください。

ADFS をインストールすると、フェデレーションサービスの名前が設定され、既定では ADFS サーバーの FQDN がフェデレーションサービスの名前として設定されます。ところが 2台以上のサーバーで ADFS を構成する場合、2 台で 1 つのフェデレーション サービス名を構成しなければならないため、既定の名前から変更する必要があります。フェデレーション サービスに関する設定は ADFS 管理ツールの [ADFS] を右クリックし、[フェデレーション サービスのプロパティ] を開いて設定します。

■フェデレーションサービスの表示名
レルムを選択する画面や、Web アプリケーション プロキシを経由してアクセスするときの画面に表示される名前がフェデレーション サービスの表示名です。表示名は単なるラベルなので、ユーザーにとってわかりやすい名前を設定すると良いでしょう。

■フェデレーションサービス名
1 台以上の ADFS サーバーで構成されるフェデレーション サービスに対して設定する、システム上の名前です。この名前は SSL 証明書に設定された FQDN と一致している必要があります。つまり、クライアントコンピューターから ADFS サーバーにアクセスするときの FQDN にはフェデレーションサービス名を利用します。そのため、フェデレーションサービス名は名前解決ができるように、DNSサーバーにレコードを登録しておく必要があります。

■フェデレーションサービスの識別子
他のサーバー/サービスからフェデレーションサービスを識別するために使用する識別子です。この名前は ID 連携を行う相手から見て一意である必要があります。一般には SSL 証明書の FQDN を含む URL (http://<FQDN>/adfs/services/trust) に設定します (URL は一意であればよく、実在する必要はありません)。

ADFS を利用してクレームベース認証を行う場合、組織内から認証を要求される場合と、組織外 (インターネット上) から認証を要求される場合があります。そのいずれの要求にも応えられるようにするためには、ADFS サーバーにインターネットからアクセスできるようにする必要があります。

ただし、ADFS サーバーはトークンを発行する STS としての役割を持つため、インターネットからの直接アクセスを許可すると、攻撃者からの攻撃によってサービスを乗っ取られる可能性があります。そのため、インターネットからのアクセスを実現するためには、ADFS サーバーへの代理アクセスを実現する Web アプリケーション プロキシを DMZ に設置し、Web アプリケーション プロキシ経由で ADFS サーバーにアクセスさせるような運用を行います。

Web アプリケーションプロキシを利用してインターネットからのクレーム ベース認証を受け付けるように構成した場合、これまでのバージョンの ADFS で提供していた ADFS プロキシとは異なり、ADFS サーバーに対する単なる代理接続だけでなく、認証・認可に関わる、すべての通信に対するプロキシとして動作します。その結果、イントラネットのアクセスに対する認証が集約され、一度の認証で、ADFS に関連するアクセスはもちろんのこと、イントラネット内のすべてのリソースにアクセスできるようになります。

ADFS サーバーとともに組織内に ADFS プロキシを実装することによって、インターネットからの安全なクレーム ベース認証が実装できます。ただし、クライアントからのアクセスを受け付ける場合、ADFS サーバーにアクセスしても Web アプリケーション プロキシにアクセスしても、同じサーバーに接続しているかのように見せる必要があるため、次の点に注意する必要があります。

■Web アプリケーション プロキシと ADFS サーバーで同じ FQDN で名前解決できるようにする
Web アプリケーション プロキシと ADFS サーバーを同じサーバーであるように見せるためには、同じ FQDN で名前解決できるようにします。

■Web アプリケーション プロキシと ADFS サーバーで同じ証明書を利用する
Web アプリケーション プロキシと ADFS サーバーのどちらにアクセスしても、同じサーバーと通信しているように見せるためには、同じ SSL 証明書を使って通信を行います。なお、Web アプリケーション プロキシは STS として動作しないため、トークン署名証明書の実装は不要です。

■Web アプリケーション プロキシと Web サーバーで同じ証明書を利用する
SSL 通信を行う Web サーバーを Web アプリケーション プロキシ経由で公開している場合、Web アプリケーションプロキシを Web サーバーのように見せる必要があるため、Web サーバーと同じ証明書を Web アプリケーション プロキシに実装します。

Web アプリケーションプロキシと ADFS サーバーで同じ FQDN を設定した場合、外部からのアクセスには Web アプリケーション プロキシへ、Web アプリケーション プロキシからのアクセスには ADFS サーバーへ、それぞれアクセスできるように名前解決を行う必要があります。このような名前解決を実現する場合、次のいずれかの名前解決方法を実装します。

■Web アプリケーション プロキシの DNS サーバーアドレスとして内部の DNSサーバーを指定

■Web アプリケーション プロキシで Hosts ファイルを構成

Hosts ファイルを使用する場合、Hosts ファイルに ADFS サーバーのコンピューター名 (FQDN) と IP アドレスを登録しておくことで、ADFS サーバーへ要求の転送ができるようになります。一方、DNSサーバーで名前解決を行う場合、イントラネットと DMZ で別々の DNSサーバーを用意し、外部からのユーザーは DMZ の DNSサーバー、Web アプリケーションプロキシはイントラネットの DNS サーバーを利用するように構成します。

Web アプリケーションプロキシの役割を利用する場合、サーバー マネージャーの [役割と機能の追加] から [リモート アクセス] の役割を追加します。役割を追加すると、Web アプリケーション プロキシの構成ウィザードを実行することができるため、ウィザード内で利用する ADFS サーバーや証明書を指定します。ADFS サーバーに追加された Web アプリケーション プロキシは [リモート アクセス管理ツール] 画面のほか、
Get-AdfsWebApplicationProxyRelyingPartyTrust コマンドレットを利用して確認することができます。

Web アプリケーションプロキシを通じてインターネットに公開する社内のアプリケーションは、[リモート アクセス管理ツール] から登録します。公開の設定を行う際、公開された社内アプリケーションにアクセスする場合、Web アプリケーション プロキシによる認証 (事前認証) を行ってから社内アプリケーションへのアクセスを許可する方法と、Web アプリケーションプロキシによる認証を行わないで (パススルー) 社内アプリケーションへのアクセスを許可する方法のうち、いずれかを選択することができます。このうち、事前認証を選択すると、ADFS を活用したクレームベース認証と、トークンを利用した社内アプリケーションへのアクセスが実現します。

編集後記

今さらADFSサーバーをインストールする手順の解説って、どれだけ需要があるんだろう？と思いながら載せてみました。証明書の実装だったり、名前解決の設定であったり、結構な落とし穴があることを改めて振り返ってみて思い出しました。これから構築する人がどれだけいるかわかりませんが、今さらこんな落とし穴にはまらないよう、誰かの役に立てば幸いです。

The post ADFSトレーニングテキスト全文公開チャレンジ(6) – ADFSのインストール(後編) first appeared on Always on the clock.

皆さんこんにちは。国井です。
ADFSトレーニングテキスト全文公開チャレンジの7回目ですが、クレームルールの概要について解説します。
クレームルールはアクセス制御の話でよく登場しますが、ここではクレームルールとは？という話からスタートします。

■ ■ ■

クレーム ルールはクレームを定義するための規則で、主な規則として、受け付け変換規則、発行承認規則、発行変換規則があります。

■受け付け変換規則
受け付け変換規則は、[要求プロバイダー信頼] から設定可能な規則で、認証用データベースや CP から取得する属性情報を定義するために利用します。受け付け変換規則にはあらかじめ、10 個の規則が用意されていますが、ADFS が内部的な処理を行うために用意されている規則であり、誤って削除すると ADFS によるトークン発行ができなくなるので注意してください。

誤って受け付け変換規則を削除した場合
デフォルトで用意されている受け付け変換規則を再度作成する PowerShell スクリプトが提供されているため、スクリプトを実行し、復元してください。
http://jorgequestforknowledge.wordpress.com/2013/10/07/restoring-the-default-acceptance-transform-rules-for-the-ad-cp-trust-in-adfs-v3-0/

■発行承認規則 (アクセス制御ポリシー)
発行変換規則は、[証明書利用者信頼] から設定可能な規則で、トークンの内容をもとに認可の許可/拒否の基準を定義します。

■発行変換規則 (要求発行ポリシー)
発行変換規則は、[証明書利用者信頼] から設定可能な規則で、受け付け変換規則で作成したトークンに含まれるクレームをどのように扱うかを定義するために使われます。受け付け変換規則から送信されたクレームの内容は、単純に付け替えする (パススルー) だけでなく、一部の文字列を変換したり、クレームの値を異なるクレームの値として利用するなどの変換が可能です。
それぞれの規則の中では、「ルール」を作成することができます。ルールでは、特定のデータベースから属性情報を取得したり、取得した属性情報をもとにアクセスを許可する、などの規則を定義します。

ルールは、それぞれの規則の中で 1 つまたは複数作成することができ、ルールの集合を「ルール セット」と呼びます。ルールセット内の各ルールは、ルールの内容に関わらず最後まで処理します。例えば、Administratorsグループ以外のユーザーに対してクレームの追加を拒否するルールがあった場合、Administrators グループ以外のユーザーは、該当するルールに記載されているクレームを追加することはありませんが、トークンそのものの発行を拒否したわけではなく、残りのルールは継続して処理され、クレームが追加されます。

受け付け変換規則では、クレームにセットする属性値をデータベースから取得するためのルールを作成します。そのため、次のような要求規則テンプレートが主に利用されます。

■[LDAP 属性を要求として送信] 要求規則テンプレート
認証に使用した Active Directory から、認証したユーザーの属性値を取得するためのルール用テンプレートです。このテンプレートでは、電子メールアドレス (mailaddress 属性) や名前 (name 属性) などを Active Directory から収集できます。収集する Active Directory の属性情報は一覧から選択するだけでなく、属性名を直接入力して収集することも可能です。また、Active Directory から UPN として取得した属性値はそのまま UPN としてクレームに追加できるばかりでなく、UPN 属性値を mailaddress の属性値としてクレームに追加するなどの操作も可能です。
もし、Active Directory データベースに該当する属性値が存在しない場合、空の属性値でクレームが追加されるわけではなく、クレームそのものが発行されません。

■[グループ メンバーシップを要求として送信] 要求規則テンプレート
認証に使用した Active Directory から、認証したユーザーが所属するグループの情報を取得するためのルール用テンプレートです。所属するグループの情報をそのままクレームに追加できるばかりでなく、グループの名前を異なる名前に変換してクレームにセットすることも可能です。

発行承認規則では、クレームの内容からリソースへのアクセスを許可または拒否するためのルールを作成します。そのため、次のような要求規則テンプレートが主に利用されます。

■[入力方向の要求に基づいてユーザーを許可または拒否] 要求規則テンプレート
受け付け変換規則で作成されたクレームの内容から、特定の条件に基づいて許可または拒否を判定するために使うテンプレートです。属性と属性値の条件を指定し、条件に一致する場合のみアクセスを許可するように定義します。

■[入力方向の要求をパススルーまたはフィルター処理] 要求規則テンプレート
受け付け変換規則で作成されたクレームの内容から、特定の条件に基づいて許可または拒否を判定するために使うテンプレートです。[入力方向の要求に基づいてユーザーを許可または拒否] テンプレートと同じく、属性と属性値の条件に基づいてアクセスの許可 / 拒否を判定しますが、このテンプレートの場合には、特定の属性のプレフィックスが特定の文字列であるか、電子メールアドレスのサフィックスが特定の文字列であるか、などの細かな条件を設定できるメリットがあります。

■[すべてのユーザーを許可] 要求規則テンプレート
受け付け変換規則で作成されたクレームの内容に関わりなく、すべてのユーザーによるアクセスを許可するときに使うテンプレートです。リソースにアクセスさせるために特に条件を設ける必要がないときに利用します。

発行変換規則は受け付け変換規則から送信されたクレームを、どのようなクレームとして扱うかを定義するためのルールを作成します。そのため、次のような要求規則テンプレートが主に利用されます。

■[入力方向の要求をパススルーまたはフィルター処理] 要求規則テンプレート
受け付け変換規則から送信されたクレームをそのまま利用するときに使うテンプレートです。また、このテンプレートではクレームに特定の文字列が含まれる時だけパススルーするように構成することも可能です。

■[入力方向の要求を変換] 要求規則テンプレート
受け付け変換規則から送信されたクレームを違う属性として扱う場合に使うテンプレートです。例えば、受け付け変換規則で UPN として設定されたクレームを発行変換規則では電子メールアドレスとしてクレームにセットするように指示することができます。また、このテンプレートでは、属性を変換するだけでなく、属性値を変換することも可能です。例えば、title クレームに「課長」と入っている場合、「課長」を「manager」に変換して、RP 側のクレームとしてセットすることができます。

トークンの中に組み込むクレームとして利用する属性情報は、あらかじめ ADFS 管理ツール [サービス] – [要求記述] で定義されています。クレームとして利用する属性は [要求記述] から追加してカスタマイズすることが可能です。
要求記述で定義されている個々の属性には、URL が設定されていますが、定義されている場所を表しているだけで、実際にアクセスすることはありません。そのため、インターネットへのアクセス経路を確保する必要はありません。
新規に要求記述を追加するときは、URL を指定する必要がありますが、単純に定義している場所 (URL) を指定するだけなので、http://<組織のFQDN>/claims/<属性名>/ などとしておくと良いでしょう。

編集後記

トークンの中に含まれる情報である、クレームをどうやってカスタマイズするかを定義するクレームルール。
クレームルールと言われれば何をする設定なのか想像がつくけど、ADFSサーバーのUIでは「要求規則」って言うんですよね。わかりにくい。。
ただ、説明はわかりやすくしたつもりなので、参考になれば幸いです。

The post ADFSトレーニングテキスト全文公開チャレンジ(7) - クレームルール first appeared on Always on the clock.

皆さんこんにちは。国井です。
ADFSトレーニングテキスト全文公開チャレンジの8回目は第3章に入って、Office 365との連携について見ていきます。

■ ■ ■

第 2 章では、ADFS サーバーの実装方法を確認しました。第 3 章では、ID 連携機能を活用して Office 365 にアクセスできる様子について確認します。

Exchange や SharePoint 等のサービスをクラウド上で提供する Office 365 では、認証・認可の部分にAzure AD を活用しています。そのため、前の章でも解説したように Azure AD に直接ユーザーを作成して運用することも、Azure AD を STS としての活用することで ID 連携を実装することもできます。

それでは、Office 365 と Azure AD の組み合わせで利用できる、3 種類のサインイン方法について確認します。

1 つ目は「クラウド ID」とも呼ばれる、Office 365 経由で Azure Active Directory (Azure AD) に登録されたユーザーをそのまま利用する方法です。この方法は、既定の Office 365 へのサインイン方法で、Office 365を利用するときは事前に Azure AD にユーザーを作成しておく必要があります。

2 つ目はオンプレミスで使用している Active Directory ユーザーを Azure AD と同期し、Azure AD に登録されたユーザー アカウントを使って Office 365 にサインインする方法です。この方法は、Azure AD に手動でユーザーを作成する必要がないだけでなく、ユーザーは Active Directory と Azure AD で同じユーザー名とパスワードが利用できるメリットがあります。

3 つ目はオンプレミスで使用している Active Directory ユーザーを Azure AD と同期し、Active Directory に登録されたユーザー情報を用いて Office 365 へアクセスする方法です。この方法では、新しく ADFS サーバーを配置し、Active Directory に登録されたユーザー情報に基づき Office 365 へアクセスするためのトークンを発行することで、ID 連携を実現します。その結果、Active Directory ドメインにサインインしているユーザーは Office 365 に改めてサインインすることなくアクセスできます。

3 種類の Office 365 の認証方法は、いつでも自由に変更することができます。そのため、Office 365の導入を行うプロジェクトの中で、いつ認証方法を変更するかについては依存要素を考慮することなく決定できるメリットがあります。しかし、パイロットの段階から ID 連携の方法を実装することはリスクが伴うため、プロジェクト後半のフェーズで実装することも検討してください。

たとえば、Office 365導入展開のプロジェクトを 3つに分割して、徐々に理想の認証方法へ変化させていく方法があります。

このプロジェクトの最初のフェーズ (パイロット導入) では、Azure AD に直接ユーザーを作成して運用します。Azure AD に直接ユーザーを作成することで、余計な手間を排除して手軽に利用開始できるメリットがあります。

2番目のフェーズ (展開) では、オンプレミスに配置された ID ストア (Active Directory) に対してディレクトリ同期を実行します。これにより、本格的な運用を開始する前に、簡単に組織のすべてのユーザーをまとめて移行でき、かつ Active Directory と同じパスワードを利用できるメリットがあります。

もし、ディレクトリ同期を行う際、既に作られたユーザーがある場合には SMTP マッチによって既存の Azure AD アカウントを移行します (SMTP マッチについて後ほど解説します)。

3番目のフェーズ (拡張) では、複数回に渡るユーザー名とパスワードの入力処理を軽減するために、ADFS サーバーを利用した ID 連携を実装します。これにより、ユーザーは1度の資格情報の入力によって、Active Directory と Office 365 の両方にアクセスできるようになります。

Active Directory ユーザーが Office 365 にシングル サインオンを行う場合、大きく分けて 3 つのアクセス方法 (パッシブ プロファイル、リッチクライアント プロファイル、アクティブプロファイル) があります。ここでは、パッシブ プロファイルと呼ばれる、Web ブラウザー経由で Office 365 のWeb サイトにアクセスするときの認証・認可処理について解説します。

① Office 365 サイトのサインイン ページで資格情報の入力を求められる
クライアント コンピューターからOffice 365 サイトのサインインページ (https://portal.office.com/) にアクセスすると、資格情報の入力を求められます。

② 認証先を指定される
前の手順で表示されたサインインページで、ユーザー名を入力すると、シングルサインオンが可能なユーザーであるか確認します。シングル サインオン可能ユーザーであることが確認できた場合、サインイン ページでのパスワード認証を無効にし、あらかじめ決められたレルムからトークンを発行してもらうよう、クライアントコンピューターに要求します。

③ Windows ユーザーの Kerberos チケットをもとに ADFS サーバーでトークンを発行
トークンを要求されたクライアント コンピューターは Windows 統合認証を利用して資格情報を提示します。ADFS サーバーは Active Directory にアクセスして資格情報を確認し、問題がなければ認証トークンを発行します。

④ Azure AD にアクセスし、認証トークンをもとに認可を実施
クライアント コンピューターは発行されたトークンを Azure AD に提示し、認可を行います。Azure AD で認可されると、Office 365 にアクセスするためのトークンが発行されます。

⑤ Azure AD で発行されたトークンを利用して Office 365 にサインイン
クライアント コンピューターは Azure AD で発行されたトークン (認可トークン) を利用して Office 365 にサインインします。

以上の処理の結果、ユーザーはサインイン時にパスワードを入力することなく、Office 365 にアクセスできるようになります。ドメインに参加していないコンピューターからシングル サインオン ユーザーを利用して、上記のプロセスを実行する場合、③の Kerberos チケットを ADFS サーバーに提示できないため、ユーザー名とパスワードの入力を③の時点で求められます。

Active Directory ユーザーが外出先から Office 365 のシングル サインオンを行う場合、パッシブプロファイルでも異なる処理でシングル サインオン プロセスが実行されます。

① Office 365 サイトのサインイン ページで資格情報の入力を求められる
クライアント コンピューターからOffice 365 サイトのサインインページ (https://portal.office.com/) にアクセスすると、資格情報の入力を求められます。

② 認証先を指定される
前の手順で表示されたサインインページで、ユーザー名を入力すると、シングルサインオンが可能なユーザーであるか確認します。シングル サインオン可能ユーザーであることが確認できた場合、サインイン ページでのパスワード認証を無効にし、あらかじめ決められたレルムからトークンを発行してもらうよう、クライアントコンピューターに要求します。

③ Web アプリケーション プロキシにアクセスし、認証を要求
社内にいるときには Azure AD から提示された ADFS サーバーに直接アクセスすることができましたが、外出先からは社内に配置された ADFS サーバーにアクセスすることはできません。そこで、DNS サーバーによって ADFS サーバーの名前解決は Web アプリケーション プロキシ (WAP) に対して行われるように構成しておき、ユーザーはその設定に従い、WAP にアクセスします。WAP では、Active Directory ドメインの資格情報を入力し、認証を行います。

④ ユーザー認証の実施
WAP のフォーム画面から入力した資格情報は、ADFS サーバーを経由してドメインコントローラーで確認されます。

⑤ 認証トークンの発行
④で入力した資格情報が正しいものであることが確認できたら、ADFS サーバーは Office 365 にアクセスするための認証トークンを発行し、WAP 経由でクライアントに渡されます。

⑥ Azure ADにアクセスし、認証トークンをもとに認可を実施
クライアント コンピューターは発行されたトークンを Azure AD に提示し、認可を行います。Azure AD で認可されると、Office 365 にアクセスするためのトークンが発行されます。

⑦ Azure AD で発行されたトークンを利用して Office 365 にサインイン
クライアント コンピューターは Azure AD で発行されたトークン (認可トークン) を利用して Office 365 にサインインします。

このように、社外からのアクセスの場合、まだ Active Directory での認証を行っていないため、WAP にアクセスした時点で Active Directory の資格情報の入力が求められます。

Office 365 のシングル サインオン環境において、Outlook アプリケーションからメールボックスにアクセスする場合、ブラウザーアクセスとは異なる方法で認証・認可が行われます。

① Outlook から Office 365 にアクセスし、資格情報を提示
Outlook を起動し、Outlook から Office 365 にアクセスするとき、Outlook は Azure AD に登録されたユーザーの資格情報を提示します。

② 資格情報の確認先をチェック
Office 365 は Outlook クライアントから提示された資格情報を確認するため、確認先を Azure AD に確認します。

③ 資格情報を提示して認証
Azure AD に登録されたユーザーがシングルサインオン ユーザーであることが確認できた場合、WAPに資格情報を提示します。

④ 認証トークンの発行
WAP に提示された資格情報を ADFS サーバー経由で Active Directory が確認し、正しいものであることが確認できると、ADFS サーバーは認証トークンを発行し、Office 365に提示します。

⑤ Azure AD にアクセスし、認証トークンをもとに認可
Office 365 は認証トークンを Azure AD に提示します。

⑥ Azure AD から認可トークンを発行
認証トークンを受け取った Azure AD は認可トークンを Office 365 に対して発行します。

⑦ アプリケーションからのアクセスを開始
認可トークンは最終的にクライアント コンピューターに渡され、その認可トークンを利用してアプリケーションからのアクセスが開始できるようになります。

アクティブ プロファイルの場合、クライアント コンピューターから送信された資格情報をもとに、トークンの発行に関わる処理をすべてクラウド (Azure AD/Office 365) 主導で行われます。この方法では、Windows資格情報の確認を Azure AD 経由で行うため、インターネットから ADFS サーバーへのアクセス要求を受け付けられるようにするため、WAP を用意していることが特徴です。
また、WAP へのアクセスは Office 365から HTTPS プロトコルを使って行われるため、WAP には Office 365 が許可する SSL 証明書を利用していることが前提となります。
一方、Windows 資格情報は Outlook クライアントから送信されます。そのため、ユーザーが Office 365 にアクセスするために毎回ユーザー名やパスワードを入力しないようにするため、Outlook 自身に資格情報を保存 (キャッシュ) しておく必要があります。

Office 2013 / Office 2016 または Office 365 ProPlus (以降、Office 365 ProPlus と省略) では、アプリケーションを通じて行われる認証・認可部分にActive Directory Authentication Library (ADAL) と呼ばれるコンポーネントを利用し、Office 365 ProPlus アプリケーション経由での認証・認可にパッシブ プロファイルを使うようになりました。このような ADAL を利用した認証方式を先進認証 (Modern Authentication) と呼びます。ここでは、先進認証を利用して Office 365 にアクセスするときの認証・認可処理について解説します。

① Office 365 サイトで認証を要求される
Office 365 ProPlus から Office 365 サイトにアクセスすると、トークンを保有していないため、認証を要求されます。

② 認証先を指定される
前の手順で表示されたサインインページで、ユーザー名を入力 (または Office 365 ProPlus によりキャッシュされているユーザー名を提示) すると、シングル サインオンが可能なユーザーであるか確認します。シングル サインオン可能ユーザーであることが確認できた場合、サインインページでのパスワード認証を無効にし、あらかじめ決められたレルムからトークンを発行してもらうよう、クライアント コンピューターに要求します。

③ Windows ユーザーの Kerberos チケットをもとに ADFS サーバーでトークンを発行
トークンを要求された Office 365 ProPlus は Windows 統合認証を利用して資格情報を提示します。ADFS サーバーは Active Directory にアクセスして資格情報を確認し、問題がなければ認証トークンを発行します。一方、ドメインに参加していないコンピューターや Active Directory で認証していないコンピューターの場合はサインインページが表示され、資格情報の入力を求められます。

④ Azure AD にアクセスし、認証トークンをもとに認可を実施
クライアント コンピューターは ADFS サーバーから発行されたトークンを Azure AD に提示し、認可を行います。Azure AD で認可されると、Office 365 にアクセスするためのトークンが発行されます。このとき、Azure AD から発行されるトークンには、アクセス トークンとリフレッシュ トークンの 2 種類があります。

⑤ Azure AD で発行されたトークンを利用して Office 365 にアクセス
クライアント コンピューターは Azure AD で発行されたトークンのうち、アクセス トークンを利用して Office 365 にアクセスします。

以上の処理の結果、ユーザーは Outlook を含む、すべての Office アプリケーションから Office 365 にアクセスするときに、パスワードを入力する必要がなくなり、トークンを利用してアクセスできるようになります。また、アクセストークンは有効期間が 1 時間に設定され、その有効期間が切れるとリフレッシュ トークンを使って Azure AD からアクセス トークンを再取得します。リフレッシュ トークンは 14 日間有効で継続利用することにより最大で 90 日間有効なトークンで、Office アプリケーションを終了してもコンピューター内にキャッシュされます。そのため、リフレッシュ トークンが有効な限り、ADFS を利用した再認証を行わない点に注意してください。

編集後記

ADFSの接続先クラウドアプリNo1のOffice 365との連携方法にいよいよ入ってきました。
Office 365への接続方法にはブラウザーからの接続とアプリからの接続があり、どちらの方法で接続するかによってSSOの方法も違っていたりします。
アプリの接続の場合、レガシー認証と先進認証の2つのパターンがあり、レガシー認証(Office 365 と ADFS サーバーによる ID 連携 (Outlook アクセスの場合)の項目で解説した接続方法)は2021年中にサービスを終了することを既に発表しています。
そのため、会社の中でレガシー認証が使われていないかを確認し、来るべき時に向けて先進認証に切り替えていく作業が今の段階から必要になります。
これについては別の投稿で解説していますので、参考にしてみてください。

The post ADFSトレーニングテキスト全文公開チャレンジ(8) – ADFSのコンポーネント first appeared on Always on the clock.

皆さんこんにちは。国井です。
ADFSトレーニングテキスト全文公開チャレンジの9回目はOffice 365とADFSを連携させるための具体的な方法について解説します。

■ ■ ■

Office 365 の各サービスへのシングルサインオンを実現する場合、ADFS サーバーを利用した ID 連携の他、Azure AD ディレクトリと Active Directory の間でのプロビジョニング (ID 同期) が必要になります。Azure AD では Azure AD ディレクトリと Active Directory の間での ID 同期のためのツールとして、Azure Active Directory Connect (AAD Connect) ツールを無償で提供しており、これを利用することにより、ID 連携に必要なプロビジョニングの部分を実現します。

また、外部から Office 365 にアクセスする場合や、Outlook アプリケーションからメールボックスにアクセスするときは、Web アプリケーションプロキシ経由で ADFS サーバーにアクセスし、トークンを取得する必要がある点にも注意してください。

ブラウザー アクセスによる Office 365 へのシングルサインオンを実現するには、以下の設定が必要になります。

① Active Directory の設定 : Office 365 に登録されたドメイン名を持つメールアドレスまたは UPN の登録
Office 365 のシングルサインオンを行うためには、Active Directory のドメイン名が Office 365 で使用するドメイン名と同じでなければなりません。もし、異なるドメイン名を Active Directory に設定している場合、代替 UPNサフィックスを設定するか、Office 365 のドメイン名と同じドメイン名を使用するメールアドレスをユーザーに登録することで対処します (メールアドレスの登録によるシングル サインオンの設定方法については「Alternate Login ID」の項で解説します)。

② ADFS サーバーの設定 : ADFS サーバーとしての設定
ADFS サーバーそのものを利用するための設定を行います。具体的には、ADFS サーバーのインストールや証明書の実装などが含まれます。

③ ADFS サーバーの設定 : Azure AD の登録
④ ADFS サーバーの設定 : フェデレーション ドメインの登録
ADFS サーバーが利用する Azure AD の登録を行います。Azure AD の登録にはフェデレーションドメインの名前を指定して行うため、フェデレーション ドメインの登録を行うことで自動的に Azure AD は登録され、その結果、ADFS サーバーに証明書利用者信頼 (RP) が自動的に設定されます。Azure AD の登録設定は PowerShell コマンドレットを通じて行います。

⑤ Office 365 の設定 : ディレクトリ同期のアクティブ化
Office 365 でシングルサインオンを行う場合、Active Directory に登録されたユーザーを Azure AD にあらかじめ同期させておく必要があります。同期の設定に先立ち、Office 365 では同期を許可する設定を行っておきます。

⑥ Active Directory の設定 : ディレクトリ同期ツールによる同期
Active Directory 内のユーザーやグループの情報を同期します。同期は Active Directory から Azure AD ディレクトリに向けて一方向に行われます。

⑦ 同期したユーザーのアクティブ化
Active Directory との間で同期したユーザーは、同期完了時点ではまだ利用可能な状態ではありません。アクティブ化の操作を通じてユーザーアカウントは初めて Office 365 で利用可能な状態となります。
社外から Office 365 にアクセスする場合、次の設定が追加で必要になります。

⑧ WAP のインストール・初期設定
社外から ADFS サーバーにアクセスし、トークンを発行するには、WAP を経由する必要があります。そのため、事前に WAP をインストールし、初期設定を済ませておきます。

⑨ DNS レコードの登録
WAP にアクセスするための URL は社内から ADFS サーバーにアクセスするときの URL と同じでなければならなりません。そこで、ADFS サーバーと同じ URL に対する IPアドレスが WAP の IPアドレスとなるように外部 DNS サーバーにレコードを登録します。
一方、社内から ADFS サーバーを経由して、Office 365 にアクセスする場合、ADFS サーバーそのものの DNS レコードのほか、利用するサービスに合わせた DNS レコードを登録する必要があります。
Outlook アプリケーションから Office 365 にアクセスする場合、社外からのアクセス方法の設定に加えて、次の設定が追加で必要になります。

⑩ 公的認証局から発行された証明書
アクティブ プロファイルでは、Office 365 から WAP に SSL 通信するため、Office 365で利用可能な証明書、つまり公的認証局から発行された証明書を WAP に実装しなければなりません。Skype for Business から Office 365 にアクセスする場合、シングルサインオンの利用の有無にかかわりなく、必要な DNS レコードを登録する必要があります。

次のページから個々の項目について、具体的な設定を確認します。

Azure Active Directory Connect による Office 365 SSO 環境の構築
マイクロソフトでは、2015 年 6 月に Azure Active Directory Connect (AAD Connect) と呼ばれるツールを新しく提供しました。AAD Connect は Office 365のシングルサインオン環境を構築するために必要な設定を自動的に行うものです。本ページで解説した手順のうち、②,③,④,⑥,⑧の手順をウィザードを通じて実行することができます。

Azure AD では、既定で登録されドメイン名 (.onmicrosoft.com の形式のドメイン名) とは別にオリジナルのドメイン名を設定できます。Azure AD でドメイン名を設定すると、Azure AD のユーザー名も「ユーザー名＠ドメイン名」の形式で設定できるため、組織で普段使用しているメールアドレスとユーザーサインイン名を同じにできるメリットがあります。

Azure AD で新しくドメイン名を登録する場合、Office 365 管理センターまたは Azure 管理ポータル画面から設定できます。ドメイン登録はインターネットにおけるドメイン名を所有している組織だけが登録できるよう、ドメイン登録を行う際に、DNS サーバーへの TXT レコードの登録が求められます。そのため、Azure AD の管理者は、自身のドメインの DNS サーバーへのアクセスができること、そして DNS サーバーへのレコード登録の方法を事前に確認してください。

Office 365 管理者アカウントのアドレス
シングルサインオンの設定はドメインの単位で行います。そのため、新しく作成したドメイン名をシングルサインオンできるように構成すると、そのドメイン名を持つユーザーはシングルサインオンを強制されます。Office 365 の契約時に作成される管理者アカウント (全体管理者) はシングルサインオン ユーザーとして構成できますが、ADFS サーバーなどのシングルサインオン環境にトラブルが発生すると、全体管理者もサインインできなくなります。そのため、最初の全体管理者アカウントのアドレスには、オリジナルのドメイン名を設定せず、既定で設定される onmicrosoft.com ドメインを利用することをお勧めします。

Active Directory のユーザーアカウントを利用して Office 365 のサインインを行う場合、Active Directory ユーザーのユーザー プリンシパル名 (UPN) と、Office 365 に登録されたユーザー名 (メールアドレス) は同一のものでなければなりません。UPN は Active Directory ドメイン名に基づいて決定されるため、ドメイン名に .local のようなインターネットでは利用できない名前を設定していると、UPN と Office 365 のユーザー名は同一にはなりません。

この問題を解決するために、Active Directory では代替 UPNサフィックスを利用します。代替 UPN サフィックスを利用すると、本来のドメイン名の代わりとなるドメイン名を設定できるため、Office 365 と同一の名前を設定できるようになります。

例えば、example.local ドメインに yamada ユーザーが存在する場合、このユーザーの UPN は yamada@example.local となります。しかし、Office 365 で example.com ドメインを利用する場合、yamada ユーザーのユーザー名は yamada@example.com となり、Active Directory の UPN とは異なるものになります。ここで、代替 UPN サフィックスで example.com を設定しておくと、yamada ユーザーの UPN を yamada@example.local から yamada@example.com に変更できるようになります。この結果、yamada ユーザーのユーザー名は Active Directory と Office 365 で同一の名前となります。

サインインアカウントと SMTP アドレス
Office 365 では、管理ポータルからユーザーを作成した場合、作成したユーザー名 (サインイン アカウント) がそのまま Exchange Online のSMTP アドレスになりますが、ディレクトリ同期によって作成されたユーザーの場合、onmicrosoft.com ドメインのアドレスがプライマリ SMTP アドレスとなり、ディレクトリ同期によって作成するユーザーのアドレスはプライマリ SMTP アドレスにはなりません。そのため、同期ユーザーのアドレスをプライマリ SMTP アドレスに明示的に指定する場合、メールアドレス (mail) 属性に UPNと同じアドレスを設定するか、proxyaddresses 属性に「SMTP:<UPN>」(SMTP は大文字)と入力し、設定します。

前のページでも解説したように、Office 365 でシングル サインオンを実行するときには、オンプレミスにADFS サーバーを配置する必要があります。Office 365 における ADFS サーバーは、CP としてのみ動作するため、連携して動作する証明書利用者信頼 (RP) を別途指定しなければなりません。Office 365 のための証明書利用者信頼の設定は、「Windows PowerShell 用 Windows Azure Active Directory モジュール」というツールを使って行う必要があります。

Windows PowerShell 用 Windows Azure Active Directory モジュールは、Office 365 のサイトからダウンロードすることができます。モジュールをインストールするときは、同じく Office 365 のサイトからダウンロード・インストール可能なディレクトリ同期ツール、もしくはマイクロソフト Web サイトからダウンロード・インストール可能な 「Microsoft Online Services サインイン アシスタント」ツールをインストールしておく必要があります。

Windows PowerShell 用 Windows Azure Active Directory モジュールをインストールしたコンピューターには、デスクトップにショートカットが作成されるので、このショートカットから Windows PowerShell を実行します。次のコマンドレットを実行することで、自動的に証明書利用者信頼の設定が施されます。

■Azure AD への接続のためのコマンドレット

$Cred = Get-Credential
Connect-MsolService -Credential $cred

■シングルサインオンのために使用する ADFS サーバーの指定

Set-ADFSContext -Computer <ADFSサーバー名>

■シングルサインオンのために使用するドメイン名の指定

Convert-MsolDomainToFederated -DomainName <ドメイン名>

Convert-MsolDomainToFederated コマンドレットを実行すると、Office 365 で使用するドメイン名のうち、シングルサインオンに使用するドメイン名を定義することができます。なお、Convert-MsolDomainToFederated コマンドレットで定義可能なドメイン名は事前に Azure AD に登録されたドメインだけです。ドメイン所有者の確認が完了すると、Office 365 の管理者コンソールに表示されるドメイン名一覧でその旨確認できます。

複数の Active Directory ドメインをフェデレーション ドメインとして利用する
フェデレーション ドメインの登録は Convert-MsolDomainToFederated コマンドレットを利用して行うことをここまでで学習しました。このとき、複数の Active Directory ドメインで、複数の代替 UPN サフィックスを利用して同期を行い、複数のフェデレーション ドメインとして ID 連携を行う場合、それぞれのコマンドレットの実行時に、-supportmultipledomain オプションを付けて実行します。

Office 365 では、ADFS サーバーで発行されたトークンをもとに、Azure AD に登録されているユーザーとのマッピングを行います。そのため、Active Directory ユーザーの情報は Azure AD にコピー (同期) させる必要があります。ユーザー情報の同期には、Office 365のサイトからダウンロード・インストール可能なディレクトリ同期ツールを利用します。

ディレクトリ同期ツールは、64 ビット版のセットアッププログラムだけが提供されており、ドメインコントローラーを含む、任意の 64 ビット版Windows Server OS にインストールすることができます。ディレクトリ同期ツールをインストールすると、初回起動時に Active Directory のドメイン管理者と Azure AD の管理者アカウントの資格情報の提示を求められます。入力した資格情報はディレクトリ同期ツールの中で保存され、2 回目以降のディレクトリ同期のために使われます。

ディレクトリ同期ツールを実行すると、Active Directory ドメインに保存されているユーザー情報が Azure AD に同期されます。同期は (現時点では) Active Directory から Azure AD に対して一方向に行われるため、ディレクトリ同期ツールで同期されたユーザーの情報は Office 365 から変更することができません。

また、ディレクトリ同期ツールではアカウントの同期を行いますが、Azure AD に同期されたユーザーに対する Office 365のライセンスの関連付けは行いません。そのため、ディレクトリ同期の完了後、必要に応じて同期ユーザーへのライセンス割り当てを Office 365 管理ポータルなどから行ってください。

SQL Server を利用してディレクトリ同期ツールをインストール
ディレクトリ同期ツールはデータベースとして SQL Server Express を利用します。SQL Server Express の最大データベース サイズは 2GB であり、ディレクトリ同期ツールで扱う ID の数として 50000 アカウントが上限とされています。そのため、50000 アカウントを超えて同期を行う必要がある場合、SQL Server Express ではなく、SQL Server を利用して同期を行うようにインストールする必要があります。AAD Connect からインストールする際に既存の SQL Server を利用してディレクトリ同期ツールをインストールするように選択できます。

ブラウザーから Office 365 サイトにアクセスし、シングル サインオンを行う場合、Active Directory における認証結果 (Kerberos チケット) をもとに (つまり Windows 統合認証を利用して) ユーザーのトークンを発行します。そのため、Kerberos チケットをブラウザーの操作によって自動的に Office 365 サイトに送信し、認証が行えるようにする必要があります。

Kerberos チケットを利用して、自動的にサインインが行えるようにするには、Internet Explorer の [ローカル イントラネット] から ADFS サーバーのエンドポイント URL (https://<フェデレーション サービス名>/adfs/ls/) を登録する必要があります。

サインインユーザーとは異なるユーザーで Office 365 にサインインする
トラブルシューティングなどの目的で Windows にサインインしたユーザーとは異なるユーザーで Office 365 にサインインする場合、ブラウザーのローカルイントラネットの設定を行わないでください。ローカルイントラネットの設定を行わない場合、Office 365にサインインするタイミングで認証ダイアログが表示されるので、そこで現在サインインしているユーザーとは異なるユーザーでサインインすることができます。

Internet Explorer 以外のブラウザーから Office 365 にサインインする
Internet Explorer 以外のブラウザーを利用してサインインする場合、あらかじめ ADFS サーバーでシングルサインオンを許可するよう、設定する必要があります。ADFSサーバーでの SSO 許可設定は、ブラウザー種類とバージョンの単位で行う必要があり、PowerShell の以下のコマンドレットを実行し、登録します。

■Firefox や Google Chrome (Mozilla/5.0) を SSO 用ブラウザーとして登録

$old=(Get-AdfsProperties).WIASupportedUserAgents
$new=$old+”Mozilla/5.0″
Set-ADFSProperties -WIASupportedUserAgents $new

外出先から Office 365 にアクセスする場合や Outlook アプリケーションから Office 365にアクセスする場合、ADFS サーバーの代わりに WAP にアクセスしてシングルサインオン プロセスを開始します。そのため、これらのアクセス方法をサポートする場合には、事前に WAP をインストールしておく必要があります。

WAP 経由でのトークン発行プロセスは、ADFS サーバーにアクセスするときと同じ証明書を利用する必要があります。そのため、WAP をインストールする前に ADFSサーバーに実装した SSL 証明書と同じ証明書を WAP に実装してください。

なお、WAP では外部に公開する証明書利用者信頼を明示的に指定する必要がありますが、Azure AD の証明書利用者信頼を公開する場合、その設定は不要です。WAPのインストールが完了すれば、自動的に ADFS サーバーへのトークンの発行要求は転送されるように動作します。

Office 365 では、ブラウザーからアクセスする場合、Outlook からアクセスする場合、Skype for Businessからアクセスする場合と、様々なシングル サインオン方法があります。そのため、どのようなアプリケーションからアクセスを行うかによって、必要となる DNS レコードも異なります。ここでは、それぞれのケースにおいて必要な DNS レコードについて確認します。

■社内からブラウザーでアクセスする場合
ADFS サーバーにアクセスするためのレコード (A レコード) が社内 DNS サーバーに作られていれば、シングルサインオンが実現します。なお、NLB などによって ADFS サーバーを複数台立てて運用しているときには、負荷分散用 IP アドレスを Aレコードに登録してください。

■社内から Skype for Business (SfB) でアクセスする場合
社内からリッチクライアント プロファイルでアクセスする場合も基本的にパッシブプロファイルと同じです。ただし、SfB Online 関連のレコードは社内の DNS サーバーで名前解決するため、社内の DNS サーバーに SfB Online 関連のレコードも一緒に登録してください。

■社外からSkype for Business またはブラウザーでアクセスする場合
社外からアクセスする場合、WAP のアドレスを外部 DNS サーバーに A レコードとして登録します。また、SfB を利用している場合は SfB Online 関連レコードも外部 DNS サーバーに登録してください。

■Outlook でアクセスする場合
Outlook からシングルサインオンを実行する場合、WAP のアドレスを社内 DNS サーバーと外部 DNS サーバーに それぞれ A レコードとして登録します。また、Exchange Online 関連レコードも、それぞれの DNS サーバーに登録してください。

編集後記

Advent Calendar風に12月25日までゆっくりと公開していこうと思ったのですが、分量が多すぎて、ここまでは年内に公開が終わらなさそうです。そのため、今日は少しボリュームを増やしてみました。読みにくいなどの意見があれば、分割して公開しますので、ご意見などお寄せください。

The post ADFSトレーニングテキスト全文公開チャレンジ(9) – Office365連携環境の構築ステップ first appeared on Always on the clock.

皆さんこんにちは。国井です。
ADFSトレーニングテキスト全文公開チャレンジの10回目となる今回はAzure AD Connectを利用したID連携のための環境づくりについて解説します。

■ ■ ■

Active Directory と Azure AD の間でのディレクトリ同期を担当する Azure Active Directory Connect ツールは、同期元となる Active Directory ドメインと同期先となる Azure AD ディレクトリをそれぞれ自由に指定することができ、次のようなパターンでの同期設定ができます。

■1つのドメイン (フォレスト) から 1 つの Azure AD ディレクトリへ同期

■複数のドメイン (フォレスト) から 1 つの Azure AD ディレクトリへ同期

一方、AAD Connect では複数の Azure AD ディレクトリを同期先として指定することはできません。複数の Azure AD ディレクトリを同期先として使用する場合には、マイクロソフトが有償で提供するディレクトリ同期製品である、Microsoft Identity Manager (MIM) を利用する必要があります。

ディレクトリ同期ツールには、いずれもマイクロソフトのディレクトリ同期製品である Microsoft Identity Manager (MIM) のエンジンが使われており、ディレクトリ同期を実行すると MIM のコンポーネントを利用して Active Directory と Azure AD の同期が行われます。
ディレクトリ同期ツールは Active Directory と Azure AD の間で直接同期を行っているわけではなく、ディレクトリ同期ツールの中に作成されるメタバース (Metaverse) と呼ばれるデータベースに一旦格納し、それから同期処理を行います。
メタバースは様々なディレクトリ データベースからディレクトリ固有の情報を取り除き、汎用的な情報だけを保存することで、他のディレクトリデータベースへスムーズな同期を実現します。たとえば、Active Directory におけるユーザー名を表す sAMAccountName 属性は、他のディレクトリ データベースでは使われることの無い、Active Directory 固有の情報です。こうした情報はメタベースに格納する際に sAMAccountName 属性から username 属性に変換するなどの処理を施してから格納します。このような処理を行うとき、変換処理を行う前のデータを格納する場所としてコネクタスペース (CS) が用意されています。
一方、Active Directory からメタバースへデータを格納する際、一時的な領域として用意されているコネクタ スペースへのデータ格納処理を Import、コネクタスペースからデータを変換し、格納する処理をSynchronization と呼んでいます。
メタバースにデータを格納するための処理として使われる、コネクタスペースや格納処理を表すImport/Synchronization はすべて Management Agent (MA) と呼ばれる設定で定義されます。ディレクトリ同期ツールでは、Active Directory とメタバースをつなぐ MA として Active Directory Connector があらかじめ用意されています。
メタバースに格納されたデータは最終的に Azure AD に同期しますが、メタバースから Azure AD への書き込み処理は Windows Azure Active Directory Connector MA で定義されている Export 処理によって実現します。

スタートメニューから Synchronization Service を実行し、[Management Agents] タブをクリックするとメタバースにつながる MA を 2 つ確認することができます。ひとつが Active Directory につながる Active Directory Connector、もうひとつが Azure AD につながる Azure AD Connector です。それぞれの MA による Import、Synchronization、Export の各処理は既定で 30 分おきに実行され、その結果は miisclient.exe の [Operations] タブで確認することができます。それぞれの MA の処理は次の順序で行われるため、[Operations] タブを確認することで、正しくディレクトリ同期が行われているか確認できます。[Operations] タブを確認すると、同期処理が次のような順序で行われていることが確認できます。

① Active Directory Connector の Delta Import Delta Sync
② Windows Azure Active Directory Connector の Delta Import Delta Sync
③ Windows Azure Active Directory Connector の Export

①～③の処理結果をクリックすると、左下ペインにメタバースまたは Azure AD に登録されたオブジェクトの数やそれぞれのオブジェクトに関する情報をクリックして確認できるため、同期時にどのようなオブジェクトが同期されたかも同時に確認できます。

AAD Connect による同期対象のカスタマイズを行う方法には、Synchronization Service ツールを利用する方法と、Synchronization Rules Editor ツールを利用する方法があります。

■Synchronization Service ツール
Synchronization Service ツールでは、同期するドメインまたは OU の限定ができます。Synchronization Service ツールの Active Directory Connector MA のプロパティから [Configure Directory Partitions] をクリックして設定します。[Select Directory Partitions] 欄でフォレスト内で同期対象とするドメインを選択、または [Containers] 欄でドメイン内で同期対象とする OU を選択することができます。
補足：現在では、Azure AD Connectのセットアップウィザード内で同期対象OUは選択できるようになっています。

■Synchronization Rules Editor ツール
Synchronization Rules Editor ツールでは、ユーザーやグループなど、同期すべき対象に対して 2 つのディレクトリ間でどのようにマッピングさせるかを定義しています。マッピング設定は、メタバースに登録する方法を定義している Inbound (Inbound Synchronization Rule : ISR) と Outbound (Outbound Synchronization Rule : OSR) の 2 つから構成されており、それぞれのマッピング ルールにはディレクトリ間のオブジェクトをどのような属性をキー属性としてマッピングするかを定義する Provision ルールと、その他の属性をどのようにマッピングするかを定義する Join ルールがあります。

AAD Sync で同期対象を一部のユーザーまたはグループに限定したい場合、Active Directory MA のInbound ルールを作成し、同期対象を属性の単位で定義できます。

SyncRulesEditor.exe を利用してディレクトリ同期対象のカスタマイズを行う場合、既定のルールではなく、必ず新規に Inbound – Join ルールを作成し、条件設定を行います。
SyncRulesEditor.exe では、Active Directory MA からメタバースへ同期する際に、CloudFiltered = Trueの値を設定することで、Azure AD への同期が抑制されます。そのため、ルール作成時に、Transformations項目で CloudFiltered = Trueの値を設定します。
一方、CloudFiltered = Trueの値を適用するオブジェクトの指定は ルール内のScoping Filter 項目から行います。Scoping Filter の中で「同期させたくない」オブジェクトの条件を指定します。例えば、ユーザーの description 属性に NOSYNC という値が設定されている場合には同期しないという条件を設定するのであれば、Scoping Filter で description equal NOSYNC となるように設定します。

SyncRulesEditor.exe によるルール作成を行う際、CloudFiltered = True を設定する Transformations 項目から直接条件を設定することも可能です。Transformations 項目から条件を設定するときは、IIF 関数を利用します。IIF 関数とは、条件と条件を満たすときに設定する値を同時に設定できる関数で、次のような要領で記述します。

IIF(条件, 条件に合致するときの値, 条件に合致しないときの値)

CloudFiltered 属性の値として、IIF 関数を利用し、条件には同期させないオブジェクトの情報を入力し、条件に合致するときの値に TRUE、条件に合致しないときの値に NULL を設定します。以上を踏まえ、SUPPORT_338945a0 ユーザーが同期されないように構成する場合、次のような IIF 関数式を書きます。

IIF([sAMAccountName] = “SUPPORT_338945a0”, True, NULL)

IIF 関数で複数の条件を設定するときは || を使います。sAMAccountName 属性が存在しない場合 (IsPresent([sAMAccountName])=False と記述)、または SUPPORT_338945a0 ユーザーの場合には同期されないように構成するときは、次のような IIF 関数式を書きます。

IIF(IsPresent([sAMAccountName]) = False || [sAMAccountName] = “SUPPORT_338945a0”, True, NULL)

その他、IIF 関数内の条件部分には次のような式を記述することができます。

■department (部署属性) が 営業 ではない場合

[department] <> “営業”

■PhysicalDeliveryOfficeName (事業所属性) に 東京または大阪の場合

[PhysicalDeliveryOfficeName] = “東京” || [PhysicalDeliveryOfficeName] = ”大阪”

■sAMAccountName の最初から 4 文字が AAD_ の場合

Left([sAMAccountName], 4) = “AAD_”

■sAMAccountName に } という文字が含まれる場合

InStr([sAMAccountName], “}”) > 0

■sAMAccountName の最初から 4 文字が CAS_ でかつ後続に } という文字が含まれる場合

Left([sAMAccountName], 4) = AAD_ && InStr([sAMAccountName], “}”) > 0

■特定の OU (ou=sales,dc=example,dc=com) に含まれる場合

Right([distinguishedName], 26) = “ou=sales,dc=example,dc=com”

ディレクトリ同期ツールではなく、Azure AD に直接ユーザーを作成した場合、既定でそのユーザーは Active Directory ユーザーと関連付けられず、別々のユーザーとしてみなされます。
もし、Azure AD に作成したユーザーを後から Active Directory ユーザーと関連付けを行いたい場合、SMTP マッチと呼ばれる関連付けを行います。SMTP マッチはディレクトリ同期を行う際、Azure AD と AD ユーザーの次の値が同じであれば、自動的に関連づけを行います。

■Azure AD ユーザー：Exchange Online のプライマリ SMTP アドレス
■AD ユーザー：ユーザーの mail 属性または proxyAddresses 属性

Exchange Online のプライマリ SMTP アドレスは Office 365 管理ポータルから [管理] – [Exchange] をクリックして Exchange 管理センターに移動し、該当するユーザーのプロパティから [電子メールオプション] で確認できます。[電子メール オプション] 画面に複数の SMTP アドレスが登録されている場合、SMTP: または smtp: でアドレスが表示されますが、プライマリ SMTP アドレスは SMTP: で始まる値で表示されます。

これまで、ADFS サーバーを利用した ID 連携の方法について解説しました。実際の運用では ADFS サーバーを複数台のサーバーで運用することにより、継続してサービスを利用できるように構成できますが、万が一 ADFS サーバーが全く利用できなくなった場合には、ID 連携を利用せずに、ディレクトリとパスワードを同期する運用に切り替えることができます。
ID 連携から同期 ID に切り替える操作は Azure AD PowerShell の以下のコマンドレットを実行します。

Set-MsolDomainAuthentication -Authentication Managed `
-DomainName <ドメイン名>

Azure AD PowerShell では Convert-MsolDomainToStandard コマンドレットを別途用意していますが、このコマンドレットは ADFS サーバーが動作している前提で利用するため、ADFS サーバーに障害が発生したときの運用には向きません。

また、フェデレーション ID から同期 ID に切り替わるとき、マイクロソフトが公表する情報に基づくと、2～3 時間程度の待ち時間が発生します。そのため、切り替わるのに要する時間よりも早く ADFS サーバーの復旧が可能であれば、同期 ID に切り替えるよりもサーバーの復旧を行うべきでしょう。
ADFS サーバーも、ディレクトリ同期ツールも、永続的に使用不能になった場合、同期 ID からクラウド ID に切り替える選択肢があります。しかし、クラウド ID への切り替え処理には最大 72 時間を要する上、ディレクトリ同期ツールが実行できなくても同期された ID は引き続き利用可能なため、クラウド ID への切り替えではなく、ディレクトリ同期ツールの再構築による対応を行うことをお勧めします。
もし、同期 ID からクラウド ID への切り替えを行う場合、Office 365 管理ポータルの [ユーザーとグループ] からディレクトリ同期の [非アクティブ化] をクリックして、処理を行います。

ADFS サーバーやディレクトリ同期ツールを含む SSO 環境のディザスタ リカバリーを行う際、あらかじめ遠隔地に DR サイトを用意しておき、障害発生時に DR サイトに切り替えて、引き続きサービスを提供する運用方法があります。
SSO 環境で DR サイトへの切り替えを行う場合、これまでに登場した、次のテクノロジーを組み合わせることによって切り替えができますので、手順をメンバーで共有したり、自動化させたりしながら、すばやく切り替えられるようにしてください。

■ドメインコントローラーの切替
ADFS サーバーがトークンを発行する際、Active Directory ユーザーの認証も同時に行うため、DR サイトからでもドメインコントローラーにアクセスできる必要があります。そのため、DR サイトにも追加のドメイン コントローラーを 1 台用意してください。

■ADFS サーバーの切替
現在使用している ADFS サーバーからセカンダリとして構成している ADFS サーバーへ切り替える場合、セカンダリの ADFS サーバーから PowerShell の以下のコマンドレットを実行します。

Set-ADFSSyncProperties -Role PrimaryComputer

ADFS サーバーが組み込みのデータベースを利用して運用されている場合、ADFS サーバー間では 5 分に一度、データベースの複製を行います。しかし、データベースの内容には ADFS 管理ツールで設定した内容しか含まれないため、直近で管理ツールから設定変更を行っていない限り、複製されていないことが別のトラブルを引き起こすことは考えられないでしょう。
また、クライアントコンピューターからの名前解決要求に対して DR サイトの ADFS サーバーが処理を受け付けられるよう、フェデレーションサービス名の DNS レコードを書き換えてください。

■Web アプリケーション プロキシの切替
現在使用しているWeb アプリケーション プロキシを別の Web アプリケーション プロキシへ切り替える場合に、Web アプリケーション プロキシ サーバー上で行う操作はありません。ただし、Web アプリケーションプロキシが正常に動作するためには、名前解決が正しく行われる必要があります。具体的には次の2つの点に注意してください。

1 つは Web アプリケーション プロキシが ADFS サーバーにアクセスする際の名前解決です。DR サイトに切り替えて運用している場合、Web アプリケーション プロキシがアクセスする ADFS サーバーは DR サイトの ADFS サーバーになります。DR サイトの ADFS サーバーにアクセスできるよう、Hosts ファイル等を書き換えておいてください。
もう 1 つはクライアントコンピューターが Web アプリケーション プロキシ にアクセスする際の名前解決です。一般に外部に公開されている DNS サーバーに Web アプリケーション プロキシの IP アドレスが登録されていますが、この情報を DR サイトの Web アプリケーション プロキシをポイントするように設定変更します。

■ディレクトリ同期ツールの切替
ディレクトリ同期ツールはステージングモードを有効にしておくことで、待機系のサーバーをあらかじめ用意しておくことができます。もし DR サイトにステージングモードのサーバーを実装している場合、ステージングモードを無効にして、ディレクトリ同期が開始できるように構成してください。なお、本番系と待機系では設定を同期する機能がないため、もし SyncRulesEditor.exe などで設定を変更している場合、その設定は手動で待機系にも同じ設定を施しておいてください。

編集後記

Azure AD ConnectとADFSサーバーの冗長構成について解説しました。
Azure AD Connectは今でも通用する話でADFSを使わない人でも役立てる場面もあるのではないかと思います。
どうでもいいことですが、このころはAzure Active Directory Connectの短縮名って、AAD Connectか、Azure AD Connectか、など揺れていましたね。明日もお楽しみに！

The post ADFSトレーニングテキスト全文公開チャレンジ(10) – Azure AD Connect first appeared on Always on the clock.

皆さんこんにちは。国井です。
ADFSトレーニングテキスト全文公開チャレンジの11回目となる今回はOffice 365以外のサービスをADFS経由でシングルサインオンする方法についてです。

■ ■ ■

この章では一貫して Office 365 の各サービスへのシングルサインオンのために、Azure AD と Active Directory の ID 連携を ADFS サーバーを通じて設定してきました。一方、Office 365 以外のクラウドサービスとの間でも ID 連携によってシングルサインオンを行いたい場合、大きく分けて 2 つの ID 連携のオプションが考えられます。

■ADFS サーバーの証明書利用者信頼にクラウド サービスを登録
ADFS サーバーの証明書利用者信頼に別のクラウドサービスを Office 365 と同じように登録すれば、それぞれの URL にアクセスしたときにシングルサインオンにより、認証プロセスをスキップしてサービスにアクセスできます。

■Azure AD にクラウド サービスを登録
Azure AD では Office 365 以外にも、およそ 2800 種類のクラウドサービスを登録でき、登録されたクラウド サービスは Azure AD にサインインするだけで SAML プロトコルを利用してシングルサインオンが実現します (Google Apps や Salesforce など一部のサービスのみ)。つまり、ADFS サーバーを利用してAzure AD にシングルサインオンし、Azure AD から各種クラウド サービスにシングルサインオンすれば、Active Directory へのサインインだけで、すべてのサービスへアクセスできることになります。この方法は ADFS サーバーに比べて簡単に STS 信頼を設定できるメリットがあります。

Azure AD からシングルサインオンのためのサービスの登録は Microsoft Azure 管理ポータルから Azure AD ドメインを登録して行います。

Azure AD にサインインするだけでアクセスできる、連携可能なサービスには次のようなものがあります。

■SaaS アプリ
前のページでも説明したように、2800 種類以上の SaaS アプリがあらかじめ Azure AD には登録されており、連携設定を行うことで、Azure AD にサインインするだけで、それぞれの SaaS アプリへのサインインを省略してアクセスできます。

■PaaS アプリ
自社開発された Web アプリなどにアクセスする際、Web アプリの中に認証機能を持たせるのではなく、Azure AD を利用して認証・認可を行うことで、認証機能の一元化が行えます。Azure Web Apps の機能を利用して Azure AD に認証したユーザーだけが Web アプリにアクセスできるように構成したり、OpenID Connect や OAuth 2.0 を利用して Azure AD で認証・認可を行うように実装したりすることができます。

■社内 Web アプリ
社内で展開している Web サーバーを Azure AD の機能を利用して外部に公開することができます。このとき、Azure AD がリバースプロキシとして動作すると同時に、Azure AD での認証を済ませたユーザーだけが Web サーバーにアクセスできるよう、構成できます。

以上のサービスにアクセス可能な Azure AD ですが、本書では SaaS アプリとの連携について、次のページから詳しく解説します。

Azure AD に関連付けてシングルサインオンを行う場合、シングルサインオンのために設定しなければならない項目があります。特に、WS-Federation や SAML プロトコルを利用する場合には、フェデレーションメタデータの交換方法など、指定しなければならない項目が多数存在します。Azure AD ではこうした面倒を省いて、必要最小限の設定でシングルサインオンの設定が完了できるよう、プリセットされた SaaS アプリが用意されています。

また、登録したい SaaS アプリが用意されていない場合、[カスタム] と呼ばれる設定を利用して、登録することができます。[カスタム] 設定では SAML プロトコルを利用したシングルサインオン アクセスの設定や、またはサインインフォーム画面にあらかじめ登録したユーザー名とパスワードの文字列を自動的に流し込んでサインインを自動完了させる方法で、シングルサインオンを実現します。

Azure AD に SaaS アプリを関連付けてシングルサインオンを行う場合、ID の関連付け方法には 3 つの方法があります。

■パスワードベースのシングルサインオン
SaaS アプリのサインインフォーム画面に、あらかじめ登録しておいたユーザー名とパスワードを自動的に入力し、サインインを自動完了させるシングルサインオン方法です。この方法は、Facebook や Twitter など SAML プロトコル等によるシングルサインオンをサポートしていないアプリで使われるシングルサインオン方法で、ユーザー名とパスワードは Azure AD に登録しておいて自動的に提示する方法と、クライアント コンピューターに登録しておいて自動的に登録する方法があります。
Azure AD に登録して提示する方法では、ユーザーごとに異なるユーザー名とパスワードを提示する方法と、Azure AD のグループに所属するユーザー全員で同じユーザー名とパスワードを提示する方法があります。
その他の ID の関連付け方法については、次のページ以降で解説します。

登録した資格情報を自動的に提示するプラグイン
Azure AD またはクライアントで登録したパスワード シングルサインオン用の資格情報はブラウザーから透過的に提示できるように専用のプラグインが用意されています。そのプラグインが Access Panel Extension アドオンプログラムで、Internet Explorer や Microsoft Edge など様々なブラウザー種類に対応したバージョンが提供されています。
なお、Access Panel Extension アドオンは Azure AD から初めて SaaS アプリにアクセスするタイミングで自動的にインストールが促されます。

■ID 連携ベースのシングルサインオン
Azure AD と SaaS アプリの間で SAML プロトコルによる ID 連携を設定し、シングルサインオンを実現する方法です。この方法は、Google Apps や Salesforce など SAML プロトコルによるシングルサインオンをサポートしているアプリで使われるシングルサインオン方法で、SAML プロトコルによる ID 連携の他、API コールによるプロビジョニングも同時に実現します。

■既存のシングルサインオン
Azure AD は SaaS アプリへのリンクのみを提供し、シングルサインオンはサードパーティ製の仕組みを利用して実現する方法です。例えば、ADFSサーバーで ID 連携のための設定を既に行っている場合、Azure AD で ID 連携のための設定を行う必要はありません。このように、他の仕組みでシングルサインオンを既に実現している場合にこの方法を選択します。

Salesforce を例に Azure AD に SaaS アプリを関連付け、SAML プロトコルによるシングルサインオンを実現する方法について解説します。
Azure AD で ADFS サーバーを利用した ID 連携環境を構築しているケースにおいて、Azure AD と Salesforce でシングルサインオンを実現する場合、クライアントは 3 つの STS を経由して Salesforce へのアクセスを実現します。
ここでは、ADFS – Azure AD – Salesforce の連携でシングルサインオンを実現する場合の認証と認可の処理について確認します。

① アプリケーションにアクセスすると、セキュリティ トークンを要求される
クライアント コンピューターから Salesforce のサインインページに接続し、Azure AD を利用したサインインを行う選択肢を選択すると、トークンが必要であることをクライアントに通知 (リダイレクト) します。

② Azure AD にアクセスし、認証先を指定される
トークンが必要であることを知ったクライアント コンピューターは①で得た情報をもとに Azure AD に接続します。ここで、クライアント コンピューターが認証を行う先として ADFS サーバーを紹介します。この情報に基づき、クライアントの通信は ADFS サーバーへリダイレクトされます。

③ ADFS サーバーにアクセスし、認証を開始
ADFS サーバーにリダイレクトされたユーザーは認証を開始します。もし、ドメイン参加しているコンピューターが既にドメインにサインインしている場合、Kerberos チケットを保有しているため、Kerberos チケットをもとに ADFS サーバーはトークンを発行します。Kerberos チケットを保有していないクライアントの場合は資格情報を入力する認証が行われ、その結果に基づいて ADFS サーバーからトークンが発行されます。

④ ADFS サーバーが発行したトークンを持って Azure AD にアクセス
ADFS サーバーが発行したトークンを受け取ると、クライアントコンピューターは Azure AD にアクセスします。Azure AD は ADFS サーバー発行のトークンを受け取ると、その内容を確認し、Azure AD が改めてトークンを発行します。

⑤ Azure AD が発行したトークンを持って Salesforce Identity へアクセス
クライアントは Azure AD が発行したトークンを持って Salesforce の STS である Salesforce Identity にアクセスします。Salesforce Identity はトークンの内容を確認し、Salesforce Identity が改めてトークンを発行します。

⑥ 認証結果をもとに特定のクレームが含まれるトークンを発行
クライアントは Salesforce Identity が発行したトークンを持って Salesforceにアクセスします。Salesforce はトークンの内容を確認し、アクセス可否の判断を行います。

以上のように、STS によるトークンの受け渡しは ADFS – Azure AD 間だけでなく、3 つ以上の STS を経由して行うことができます。これにより、ドメイン参加し、ドメインにサインインしているユーザーは改めてユーザー名とパスワードを入力することなく、Azure AD へのアクセスや Salesforce へのアクセスが実現します。

Azure AD と Salesforce で SAML プロトコルによる ID 連携を行う場合、Azure AD と Salesforce でそれぞれ必要な設定は次のとおりです。

① オンプレミスの設定：ADFS サーバーと Azure AD による SSO 設定
Office 365 のシングルサインオンを行うため必要な設定を行います。

② オンプレミスの設定 : AAD Connect による Azure AD への同期
Active Directory に登録されているユーザーを Azure AD へ同期します。これにより、Azure AD 経由で Salesforce にアクセスする場合でも Active Directory ユーザーを引き続き利用できます。なお、この設定は Office 365 の SSO設定の一環で既に行っている場合は不要です。

③ Azure AD の設定 : Azure AD ディレクトリの登録
Azure AD と SaaS アプリの連携は Azure AD 管理センターから設定します。Office 365を利用している場合、https://aad.portal.azure.com より利用開始できます。

④ Azure AD の設定 : SaaS アプリとして Salesforce の登録
Salesforce をアプリとして Azure AD に登録します。

⑤ Azure AD の設定 : ID 連携の設定
Azure AD と Salesforce の間での ID 連携を行うための設定をします。

⑥ Azure AD の設定 : プロビジョニングの設定
Azure AD に登録されたユーザーを Salesforce に同期するために必要なプロビジョニング設定を行います。

⑦ Azure AD の設定 : アクセス許可の割り当て
Azure AD から Salesforce へのアクセスを許可するユーザー/グループを定義し、アクセス許可のあるユーザー/グループだけにトークンが発行されるよう、構成します。

⑧ Salesforce の設定 : ID 連携の設定
Azure AD で設定した ID 連携の設定に対応する設定を Salesforce 側でも行います。

⑨ Salesforce の設定 : プロビジョニングの設定
Azure AD で設定したプロビジョニングの設定に対応する設定を Salesforce 側でも行います。

⑩ Salesforce の設定 : ライセンスの割り当て
Azure AD から同期されたユーザーに対してライセンスを割り当て、認証・認可を済ませたユーザーが Salesforce にアクセスできるようにします。

次のページから④から⑩の項目について、具体的な設定を確認します。
<続く>

編集後記

Salesforceを例にOffice365以外のクラウドサービスとのSAMLプロトコルによる連携法右方について解説しました。ADFS – Azure AD – Salesforce という接続方法なので、Azure AD – Salesforce という接続を考えている方でも役立つのではないかなと思いました。
参考になれば幸いです。
次回は具体的な設定方法を紹介します。

The post ADFSトレーニングテキスト全文公開チャレンジ(11) – Office365以外のサービスのSSO first appeared on Always on the clock.

皆さんこんにちは。国井です。
ADFSトレーニングテキスト全文公開チャレンジの12回目となる今回はAzure ADとクラウドサービスをID連携させてシングルサインオンする方法についてです。
今回は中途半端なところからスタートするので、簡単におさらいをしておくと、
ADFSとOffice 365以外のクラウドでID連携する場合、ADFSとクラウドを直接接続する方法と、ADFSからAzure ADを経由してクラウドに接続する方法があります。
ここでは、Azure ADを経由してクラウドに接続する際に必要なID連携設定について見ていきます。(Office 365連携によって既にADFSとAzure ADの間は連携されているので省略します)

■ ■ ■

Azure AD ディレクトリ(https://portal.azure.com/)内の [エンタープライズ アプリケーション] から SaaS アプリを追加します。
SaaS アプリの追加は、[エンタープライズ アプリケーション] ブレードから [新しいアプリケーション]をクリックし、追加するクラウド サービスをクリックして、追加します。
アプリケーションの種類によって、ID 連携方法は異なり、ここで例として挙げている Salesforce ではパスワード連携、SAML プロトコルによる ID 連携、ADFS による連携の 3種類を選択できますが、Facebook や Twitter などの SAML プロトコルの対応が無いアプリの場合はパスワード連携だけが選択できるようになっています。

Azure AD に SaaS アプリを追加すると、Salesforce アプリのブレードが表示され、左ペインから Salesforce に接続するための様々な設定項目が選択できます。このうち、[シングルサインオン] メニューでは SAML プロトコルによる ID 連携の設定を行うことができます。
[シングルサインオン] メニューでは、最初に [モード] 欄から [SAML ベースのサインオン] を選択します。すると、SAML プロトコルで連携するための設定項目が表示されます。続く [サインオン URL] 欄ではAzure AD から SaaS アプリにアクセスするときの最初の URL で、一般的にサインインページを指定します。Salesforce では、Salesforce の [私のドメイン] 設定で定義した URL を指定します。
続いて [SAML 署名証明書] 欄では Salesforce に登録するトークン署名証明書の公開鍵を作成し、ダウンロードしておきます。ID 連携ではフェデレーション メタデータの交換が必要であることを前の章で解説しましたが、SaaS アプリによってはフェデレーション メタデータを交換せず、トークン署名証明書の公開鍵だけを Azure AD から SaaS アプリに受け渡すことで STS 信頼を完了させるケースがあります。Salesforce はこのケースに当たるため、Azure AD の設定画面からトークン署名証明書をダウンロードし、ダウンロードした証明書を Salesforce の管理画面にインポートします。
最後に [Salesforce の構成] では、Salesforce 側に提供するパラメーターが表示されるため、このパラメーターを控えておきます。

フェデレーションメタデータへのアクセス方法あれこれ
Office 365 (Azure AD) の ID 連携では STS 信頼を設定するためにフェデレーション メタデータとなる XML ファイルを ADFS サーバーと Azure AD の間で交換しましたが、Salesforce ではフェデレーション メタデータ内の証明書情報だけが確認できればよいため、フェデレーション メタデータを交換せず、証明書ファイルだけを Salesforce に受け渡ししています。
このようにアプリケーションによって、ID 連携時に STS 信頼を設定する方法は異なります。証明書ファイルを登録するだけの STS 信頼の設定方法は SharePoint Server でも採用されている方法です。ただし、SharePoint Server の場合は URN と呼ばれる文字列を互いに設定し、同じ文字列を持つ STS どうしが信頼されるように同時に設定しています。
そのほかにも、Google Apps との連携ではフェデレーション メタデータを交換しますが、XML ファイルそのものを手動で交換するのではなく、XML ファイルが保存されている URL を好感します。この方法は、証明書が入れ替わることによって、フェデレーションメタデータを再交換するという手間を省くことができて便利な交換方法です。
いずれの方法も Azure AD だけで一方的に決められる STS 信頼の設定方法ではなく、あくまでも相手の SaaS アプリがどのような方法をサポートしているかによって決まります。

Azure AD 側で ID 連携の設定を行ったら、Salesforce 側でも同様の設定を行います。設定は、Salesforce の管理画面内にある [SAML シングルサインオン設定] から行います。

■発行者
Azure AD の発行者の URL を登録します。

■ID プロバイダの証明書
Azure AD でエクスポートしたトークン署名証明書を登録します。

■SAML ID の場所
トークン内で受け渡しするクレームを指定します。Azure AD では NameIdentifier クレームが受け渡しされるよう、プリセットされています。

■SAML プロバイダの起動要求バインド
HTTP リダイレクトを選択すると、パッシブ プロファイルによる ID 連携プロセスが実施されます。Azure AD ではパッシブ プロファイルを使用するようにプリセットされています。

■ID プロバイダのログイン URL / ログアウト URL
Azure AD とのやり取りを行うためのエンドポイントを登録します。

Salesforce をはじめ、多くの SaaS アプリでは、プロビジョニングによって他のディレクトリストアからの同期を受け付けるようなインターフェイスがありません。そのため、Azure AD では SaaS アプリに対して API コールを行い、SaaS アプリに対して、Azure AD に保存されているユーザーアカウントを作成するように命令することで、実質的なプロビジョニングを実現します。
そのため、Azure AD のプロビジョニング設定では、API コールを行うために必要な設定をあらかじめ定義しておきます。Salesforce の場合には API コールを行うために [ユーザー セキュリティ トークン] と呼ばれるキーが必要となるため、ユーザー セキュリティ トークンを事前に Salesforce から取得し、トークンを Azure AD に登録しています。
また、プロビジョニングによって登録されたユーザーに対しては、SaaS アプリ側でライセンスを割り当てます。ただし Salesforce の場合、後述する Azure AD のアクセス許可設定に連動して、自動的にライセンス割り当てが行われるため、Salesforce 側で手動でライセンス割り当てを行う必要はありません。

Azure AD で ID 連携の設定とプロビジョニングの設定が完了したら、最後にアクセス許可の割り当てを行います。アクセス許可の割り当ては、Azure AD のユーザーまたはグループの単位で行うことができます(グループに対するアクセス許可割り当ては Azure AD Premium ライセンスを保有する場合のみ)。
アクセス許可の割り当ては、Microsoft Azure管理ポータルから Azure AD ディレクトリ内の [アプリケーション] から [アカウントの割り当て] を利用して設定します。Salesforce に代表されるように、SaaS アプリによってはアクセス許可の割り当てと同時にライセンス割り当ても行えるものもあります。

Azure AD に登録したアプリは、Microsoft Azureで提供されるユーザー用のポータルサイトである、「アクセスパネル」Webサイト (https://myapps.microsoft.com/) よりショートカットをクリックしてアクセスできます。
アクセスパネルでは、アクセス許可が割り当てられたアプリの一覧が表示され、一覧から該当するアプリをクリックすることで、シングルサインオンプロセスが開始され、追加の資格情報を入力することなく、アプリへのアクセスが実現されます。また、Office 365ユーザーの場合には、画面左上のランチャーボタンにアプリを登録しておくことで、Office 365 のメニューからシングルサインオンプロセスを開始することも可能です。
その他、組織内のポータルサイトにショートカットを埋め込んで利用したい場合には、Microsoft Azure管理ポータル画面に用意されているショートカット URL を利用することで、アクセスパネルやOffice 365ランチャーを使わずにシングルサインオンプロセスを開始できます。

編集後記

今回はSAMLプロトコルを利用した Azure AD と Salesforce の連携について解説しました。SAMLプロトコルによるID連携の話をするときって、Salesforceを引き合いに出すことが多いのですが、これは標準的な設定でクセがないことが理由だったりします。私はSalesforce使わないよ、という方でもSalesforceを例に実装方法を学べば、他のSaaSアプリにも応用できると思います。

The post ADFSトレーニングテキスト全文公開チャレンジ(12) – SaaSアプリの登録 first appeared on Always on the clock.