Embed Size (px)
Citation preview
AD FS 2.0 での Microsoft Office 365 シン グル サインオン (SSO)
Microsoft France
発行: 2012 年 6 月
バージョン: 1.0a
著者: Philippe Beraud (Microsoft France)、Jean-Yves Grasset (Microsoft France)寄稿者: Philippe Maurent (Microsoft Corporation)
著作権© 2012 Microsoft Corporation.All rights reserved.
要約
Microsoft Active Directory フェデレーション サービス (AD FS) 2.0 は、WS-Federation (WS-Fed) および WS-Trust プロトコルをサポートすることで、Microsoft Office 365 とその Web アプリケーションおよびリッチ クライアント アプリケーションで、クレームベース (Web) のシングル サインオン (ID フェデレーションとも呼ばれます) を利用できるようにします。
このドキュメントの目的は、Office 365 のサービスを対象としたさまざまなシングル サインオン展開オプション、Active Directory の社内用資格情報および AD FS 2.0 を使用してシングル サインオンを Office のサービスに対して有効にする方法、およびこうした展開に関して認識する必要がある構成要素について、既存のドキュメントに基づいてさらに理解を深められるようにすることです。
このドキュメントは、AD FS 2.0 での Office 365 のシングル サインオン機能の基本について理解し、このような展開を自分の環境に導入したいと考えているシステム アーキテクトおよび IT 担当者を対象としています。
このドキュメントは 「現状有姿のまま」 提供されます。このドキュメントで説明されている情報およびビューは、URL および他のインターネット Web サイトの参照を含めて、予告なく変更されることがあります。そのようなリスクがあることを承知の上でお読みください。
このドキュメントに記載されている事例の一部は、説明のみを目的とした架空のものです。実在する事例とは一切関係ありません。
このドキュメントは、マイクロソフト製品の知的所有権に対する法的な権利をお客様に提供するものではありません。このドキュメントの複製と利用は、お客様が社内でこれを参照する目的の場合に限って許可されます。このドキュメントの変更についても、社内で参照する目的の場合に限って許可されます。
© 2012 Microsoft Corporation.All rights reserved.
Microsoft、Active Directory、Internet Explorer、SQL Server、Windows、Windows PowerShell、および Windows Server は、マイクロソフト グループの商標です。 その他すべての商標は各社が所有しています。
AD FS 2.0 での Microsoft Office 365 シングル サインオン (SSO) 2
コンテンツ管理
1 はじめに................................................................................................................................... 11.1 このドキュメントの目的..............................................................................................2
1.2 このドキュメントの構成..............................................................................................4
1.3 対象読者について..........................................................................................................4
1.4 MTC パリ/相互運用ラボでのライブ デモについて.......................................................5
2 ACTIVE DIRECTORY フェデレーション サービス (AD FS) 2.0 の概要.................................62.1 パッシブ/アクティブセキュリティ トークン サービス (STS).....................................7
2.2 異機種混在環境でのフェデレーション.........................................................................8
2.3 このドキュメントで使用されている用語...................................................................10
2.4 展開の種類に関する注意事項......................................................................................12
3 MICROSOFT OFFICE 365 でのフェデレーション認証.........................................................153.1 フェデレーション ID の要件.......................................................................................16
3.2 フェデレーション ID のサインイン操作.....................................................................21
3.3 フェデレーション ID の認証の種類............................................................................23
4 SSO 構成と関連する考慮事項について.................................................................................264.1 シングル サインオンを準備する................................................................................27
4.2 AD FS 2.0 を計画して展開する...................................................................................29
4.3 MICROSOFT ONLINE SERVICES モジュールのインストールと構成...............................33
4.4 シングル サインオンの確認........................................................................................45
5 OFFICE 365 でのフェデレーション認証のしくみについて..................................................475.1 AD FS 2.0 構成について.............................................................................................47
5.2 パッシブ/WEB プロファイル認証のフローについて...................................................62
5.3 MEX/リッチ クライアント プロファイル認証のフローについて...............................65
5.4 EAS 基本認証/アクティブ プロファイル認証のフローについて................................66
6 注意事項.................................................................................................................................. 696.1 複数のトップ レベル ドメインのサポート.................................................................69
6.2 OFFICE 365 向けの強力な認証 (2FA) のサポート........................................................70
6.3 クライアントの場所に基づいて OFFICE 365 サービスへのアクセスを制限する.......73
6.4 OFFICE 365 のスマート リンクを使用する.................................................................77
AD FS 2.0 での Microsoft Office 365 シングル サインオン (SSO)
PAGE
1 はじめに
Microsoft Office 3651 では、高度な電子メール機能、共有の予定表、インスタント メッセージ (IM)、ビデオ会議、およびドキュメントの共同作業支援機能をどこからでも安全に利用できます。
これは、のコミュニケーション製品と共同作業支援製品のクラウド バージョン、および Microsoft のデスクトップ スイートの最新バージョンを組み合わせたもので、あらゆる規模のビジネスに対応します。 Office 365 に実際に含まれる製品は次のとおりです。
Microsoft Office: Microsoft Office Professional Plus 2010 は Microsoft Office Web Apps にシームレスに接続し、PC、モバイル デバイス、およびブラウザーで生産性を向上させます。
メモ:
適切なデバイス、インターネット接続、およびサポートされているブラウザーが必要です。一部のモバイル機能には Office Mobile 2010 (Office 2010 アプリケーション、スイート、または Office Web Apps には含まれません ) が必要です。 また、Office Web Apps、Office Mobile 2010、および Office 2010 アプリケーションの機能には違いがいくつかあります。
Microsoft Exchange Online: Exchange Online は、最新のウイルス対策およびスパム対策ソリューションを備えたクラウドベースの電子メール、予定表、および連絡先を提供します。 この Exchange Online を使用すると、実質的にどのモバイル デバイスからでも電子メールにアクセスし、ボイス メール、ユニファイド メッセージング、およびアーカイブのオプションを利用できます。
Microsoft SharePoint Online: SharePoint Online はクラウドベースのサービスで、企業ソーシャル ネットワークとカスタマイズ機能によって同僚、顧客、およびパートナーのコミュニケーションを実現するサイトを作成できます。
Microsoft Lync Online: Lync Online はクラウドベースの IM、プレゼンス、およびオンライン 会議を提供し、画面を共有したり、音声/ビデオ会議を行ったりできます。
メモ:
Office 365 の詳細については、このドキュメントの他に、製品のオンライン ドキュメント 2、「Office 365 for Enterprises 展開ガイド 3」、「Office 365 TechCenter4」、および Office 365 コ ミュニティの Web サイト ( ブログ、フォーラム、 Wiki など ) 5 を参照してください。
SharePoint Online で作成された匿名アクセス用のインターネット サイトを除き、Office 365 のサービスにアクセスするにはユーザー認証が必要です。
1 Microsoft Office 365: http://office365.microsoft.com/
2 Office 365 のヘルプ: http://onlinehelp.microsoft.com/ja-jp /office365-enterprises/
3 Office 365 for Enterprise 展開ガイド: http://www.microsoft.com/download/ja-jp/details.aspx?id=26509
4 Office 365 TechCenter Web サイト: http://technet.microsoft.com/ja-jp/office365/default
5 Office 365 コミュニティの Web サイト: http://community.office365.com/ja-jp/default.aspx
4 AD FS 2.0 での Microsoft Office 365 シングル サインオン (SSO)
1.1 このドキュメントの目的
Office 365 では、シングル サインオン機能によって、組織が Active Directory ドメイン サービス (AD DS) に対して認証を行うことができ、これにより、組織のユーザーが社内用資格情報を使用してプロビジョニイングされている Office 365 のサービスにアクセスできます。
このようにして、内部の企業ネットワークのユーザーまたは VPN で接続されたユーザーが、Office 365 のサービスにシームレスにアクセスします。 また、自宅のコンピュータや企業ネットワークに接続されていないコンピューターから Office 365 にアクセスするときも、社内用資格情報を使用することができます。 これは、多くの組織が待ち望んでいたサインイン機能です。
企業ネットワーク上の会社のコンピューター: 会社にいるユーザーが企業ネットワークにサインインするときは、シングル サインオンにより再サインインせずに Office 365 のサービスにアクセスできます。
会社のコンピューターでローミング: ドメインに参加しているコンピューターに社内用資格情報を使用してログオンしているが、企業ネットワークに接続されていないユーザーについても同様に (たとえば、自宅やホテルで会社のコンピューターを使用している場合)、シングル サインオンにより再サインインせずに Office 365 のサービスにアクセスできます。
自宅または公共のコンピューター: 企業ドメインに参加していないコンピューターを使用する場合は、社内用資格情報を使用してサインインして、Office 365 のサービスにアクセスする必要がありますが、ユーザーが覚える必要があるのは、企業と Office 365 アクセスの資格情報 1 セットだけなのでやはり便利です。
この記事の執筆の時点では、Office 365 のシングル サインオン機能によるこの認証を行うには、組織が Active Directory フェデレーション サービス (AD FS) 2.0 を社内に展開し、このサービスと安全に通信できるように Office 365 を構成する必要があります。
まずは、以下のような OASIS 標準に関する簡単なドキュメントを参照してください。
WS-Federation (WS-Fed) ( 英語 ) 6
WS-Trust ( 英語 ) 7
Security Assertion Markup Language (SAML) 2.0 ( 英語 ) 8
「 Microsoft Active Directory Federation Services (AD FS) 2.0 Release to Web (RTW) 910 」 は 、Microsoft と Microsoft 以外のフェデレーション ソリューションでの、クレームベースのクロスドメイン (Web) シングル サインオン (SSO) (ID フェデレーションとも呼ばれます) を提供します。
6 Web Services Federation Language (WS-Federation) Version 1.2: http://docs.oasis-open.org/wsfed/federation/v1.2/ws-federation.pdf7 WS-Trust Version 1.3: http://docs.oasis-open.org/ws-sx/ws-trust/200512/ws-trust-1.3-os.pdf8 Security Assertion Markup Language (SAML) 2.0: http://go.microsoft.com/fwlink/?LinkId=193996
9 Microsoft AD FS 2.0 Release to Web (RTW) のダウンロード: http://www.microsoft.com/ja-jp/download/details.aspx?id=10909
10 Microsoft AD FS 2.0 のダウンロード: http://www.microsoft.com/ja-jp/download/details.aspx?id=10909
AD FS 2.0 での Microsoft Office 365 シングル サインオン (SSO) 5
Wikipedia11 では、ID フェデレーション (連合アイデンティティ) は次のように定義されています。
「連合アイデンティティまたはアイデンティティの連合とは、自律的セキュリティドメイン間でアイデンティティ情報を持ち運べるようにする技術・標準・ユースケースである。アイデンティティ連合の最終目標は、あるドメインのユーザーがシームレスに、余分なユーザー管理を必要としない形で、安全に別のドメインのデータやシステムにアクセスできるようにすることである。」
このドキュメントでは、既存の Microsoft ドキュメントおよびサポート技術情報の記事に基づいて、Office 365 のシングル サインオン機能 (ID フェデレーションとも呼ばれます) についてさらに詳しく説明します。
MSDN Channel 9 Web キャスト「Microsoft Office 365: Identity and Access Solutions ( 英語 ) 12」など、このトピック関する貴重な情報を提供してくれた Microsoft のシニア プログラム マネージャー Ross Adams 氏には特に感謝します。
この目的で、このドキュメントの残りの部分では AD FS 2.0 テクノロジについて簡単に説明し、基本的な概念、要件、および要素を紹介するほか、以下についても解説します。
Office 365 におけるさまざまな ID オプション
この状況における Office 365 の ID アーキテクチャと機能の概要
フェデレーション認証のさまざまな実装シナリオ
AD FS 2.0 でのフェデレーション認証の動作方法
その他、考慮する必要がある追加情報
この状況で AD FS 2.0 と一緒に Microsoft Office 365 プロジェクトを使用すると完了しやすくなるので、結果的に、顧客が Microsoft Office 365 の潜在能力を最大限に引き出すことができます。
ディレクトリ同期にはシングル サインオンは必要ありませんが (充実したユーザー エクスペリエンスを提供します)、シングル サインオンにはディレクトリ同期が必要です。
したがって、社内 AD DS と Microsoft Online Services ディレクトリの同期を維持するには、ディレクトリ同期を実装する必要があります。 このメリットの 1 つは、Active Directory ユーザーおよびコンピューターを使用して従来の方法で企業ユーザー アカウントを制御および管理できるという点です。たとえば、社内環境と Office 365 環境の間でシームレスにユーザーを管理できます。 Microsoft Online Services ディレクトリ同期ツールを使用すると、サービス管理者が、社内 AD DS で行われた変更に基づいて、Office 365 ユーザー、連絡先、およびグループを更新し続けることができます。
シングル サインオンをインストールおよび構成してから、ディレクトリ同期を実装することをお勧めします。 これは絶対に従わなければならない要件ではありませんが、従うことを推奨します。
ディレクトリ同期は、Office 365 で初めて導入されたわけではありません。 このディレクトリ同期は、Microsoft Identity Lifecycle Management (ILM) 2007 (今の Microsoft Forefront Identity Manager (FIM) 2010) をベースに構築され、 その構成は Office 365 環境向けに簡素化されています。 手動で構成する必要はなく、すべてがウィザードによって構成されます。
11 Wikipedia での ID フェデレーションの定義: http://ja.wikipedia.org/wiki/連合アイデンティティ
12 Microsoft Office 365: Identity and Access Solutions: http://channel9.msdn.com/Events/TechEd/NorthAmerica/2011/OSP215
6 AD FS 2.0 での Microsoft Office 365 シングル サインオン (SSO)
このドキュメントでは、ディレクトリ同期についてはこれ以上詳しく説明しません。このトピックの詳細については、Office 365 のオンライン ドキュメントの「Active Directory 同期 : ロードマッ プ13」および「ディレクトリ同期を管理する 14」を参照してください。
1.2 このドキュメントの構成
前述の目的を説明するために、このドキュメントは次のテーマに従って構成されています。各テーマについては以降のセクションで説明します。
Active Directory フェデレーション サービス (AD FS) 2.0 の概要;
Microsoft Office 365 でのフェデレーション認証;
Office 365 でのフェデレーション認証のしくみについて;
SSO 構成と関連する考慮事項について;
注意事項;
最後に、付録のリファレンスを使用すると、Web 上で詳細情報を簡単に検索できます。
1.3 対象読者について
一般的に (クロス ドメイン) シングル サインオン (ID フェデレーションとも呼ばれます) は範囲の広いトピックで、プロトコル、トークンなど、多面的で深い理解を求められるものが多くあります。
前述したように、この記事の執筆の時点では、この機能を有効するテクノロジとして AD FS 2.0 のみがサポートされています (これは、将来的に拡充される可能性があります)。
メモ:
AD FS 2.0 を使用した Office 365 シングル サインオン機能については、このドキュメントの他に、製品のドキュメント ( 英語 ) 15、専用の「シングル サインオンの FAQ 16」および「Office 365 SSO コ ンテンツマップ17」を参照してください。
このドキュメントは、Office 365 のこの機能について理解したいと考えているシステム アーキテクトおよび IT 担当者を対象としています。導入準備として、このトピックで使用できる 一連の Office 365 Virtual Lab ( 英語 ) 18を実行できます。
13 Active Directory 同期: ロードマップ: http://onlinehelp.microsoft.com/ja-jp/office365-enterprises/ff652543.aspx
14 ディレクトリ同期を管理する: http://onlinehelp.microsoft.com/ja-jp/office365-enterprises/ff652533.aspx
15 シングル サインオンで使用するために Active Directory フェデレーション サービス 2.0 を計画して展開する: http://onlinehelp.microsoft.com/ja-jp/office365-enterprises/ff652539.aspx
16 シングル サインオンの FAQ: http://community.office365.com/ja-jp/wikis/sso/381.aspx
17 Office 365 SSO コンテンツ マップ: http://community.office365.com/ja-jp/wikis/sso/1067.aspx18 Office 365 Virtual Labs for IT Pros: http://technet.microsoft.com/en-us/office365/hh699847
AD FS 2.0 での Microsoft Office 365 シングル サインオン (SSO) 7
1.4 MTC パリ/相互運用ラボでのライブ デモについて
Microsoft Technology Center19 (MTC) は、革新的なテクノロジと世界レベルの専門情報にアクセスできる共同作業環境です。顧客およびパートナーは、この環境でそれぞれのニーズに合ったソリューションを計画、設計、および展開できます。
2004 以降、MTC パリはこうしたグローバル センターの一部として機能しており、その目的は、Microsoft ソリューションを利用して重要なビジネス目標を達成する手順を顧客に示すことです。 この施設内では、MTC アーキテクトと Microsoft テクノロジの専門家が中心となり、MTC データセンターで実行されている検出プロセスおよびシナリオベースのデモを使用して顧客の課題に取り組んでいます。
非常に興味深いことに、MTC パリでは Microsoft フランスの相互運用ラボがホストおよび実行され、さまざまなトピックに関して、Microsoft のソリューション/アクションと、他のテクノロジまたは製品がどのように連携しているかを顧客が確認し理解できます。 こうしたトピックには、高度な Web サービス、PHP、Java、SAP、アプリケーション ライフサイクル管理などが含まれます。セキュリティと ID も忘れてはいけません。
このラボでは、顧客とパートナーが、操作の相互運用性の観点からそれぞれのニーズに応じてソリューションを適用する目的で、複数のベンダーの技術構成をテストします。 MTC パリでは、20 を超える競合ソリューションがホストされ、 これらのソリューションは、 300 台を超えるサーバーおよび 200 テラバイトを超えるストレージに構築された、MTC パリのデータセンター インフラストラクチャに展開されています。 Microsoft では多数の競合ベンダーと共に、異種システムの統合を促進します。 このように相互運用性によって顧客の統合が保証され、顧客が革新への投資を最大化し、価値を生み出すことができるのです。
疎結合された環境で ID の移植性とセキュリティを確保するには、考えられるシナリオにおいて、関連する各セキュリティ領域での ID 管理について十分に理解することが重要です。 前述したように、Microsoft プラットフォームは、一連の製品とテクノロジをネイティブで提供することでクレームベース ID の概念を支えます。 たとえば、エンタープライズクラスのクレーム プロバイダー セキュリティ トークン サービス (STS) や、クレーム対応のアプリケーションおよびサービス (認証、アクセス制御、監査など) を構築するためのフレームワークをすぐに使用できます。 「実際」 の異機種混在環境では、これらのコンポーネントは必ず連携させる必要があります。
この相互運用性について説明するために、MTC パリのセキュリティおよび ID 管理の相互運用ラボでは、複数の ID 管理シナリオ、特に、このドキュメントで説明されるフェデレーションのグループ作業シナリオを提供する永続的な専用プラットフォームを提案します。このシナリオでは、クラウドの公開グループ作業リソース用に OASIS WS-Trust および WS-Federation プロトコル、ID 用の Microsoft AD FS 2.0 ソリューションおよび Microsoft Office 365 ソリューションを使用します。
19 Microsoft Technology Center: http://www.microsoft.com/ja-jp/business/mtc
8 AD FS 2.0 での Microsoft Office 365 シングル サインオン (SSO)
2 Active Directory フェデレーション サービス (AD FS) 2.0 の概要
Windows 2000 (Server) プラットフォーム以降、AD DS で提供される Kerberos ベースのユーザー ID によって、(Microsoft および Microsoft 以外の) Active Directory 対応リソースに対するセキュリティで保護された認証とシングル サインオンが容易になりました。これらのリソースは、独自のドメイン/フォレストおよびその他の信頼された Active Directory ドメイン/フォレスト内にあります。
AD FS 2.0 により ID フェデレーションが可能になり、Web アプリケーションおよびサービスが事実上どこにあっても、上記の集中型認証、承認、およびシングル サインオンの概念をそのアプリケーションやサービスに拡張することができます。
前に説明したように、ID フェデレーションは、標準ベースのプロトコルを利用してクレーム プロバイダーと証明書利用者の間のフェデレーション信頼を確立し、セキュリティ境界を越えて Web アプリケーションおよびサービスに安全かつ容易にアクセスできるようにします。
組織については、AD FS 2.0 は、企業ユーザーに対してリッチなフェデレーション機能を提供し、次の場所にあるリソースにシームレスにアクセスできるようにします。
企業イントラネット内
企業境界ネットワークの企業ネットワーク外、エクストラネット、およびクラウド内 (例: Microsoft の PaaS (Platform as a Service)、Microsoft Windows Azure プラットフォーム 20 内)
認識された組織のユーザーにリソースを提供したパートナー組織の境界ネットワーク
フェデレーション ID をサポートする SaaS (Software as a Service) ベンダーとしてのソフトウェアを備えたクラウド内 (例: このドキュメントでは Microsoft Office 36521 製品/サービスを備えた Microsoft)
AD FS 2.0 は Windows (Server) プラットフォームのコンポーネントなので、その使用権は、関連するライセンス コストに含まれます。
重要なメモ:
Windows Server 2008 (R2) で使用できる AD FS ロールは AD FS 2.0 には対応していません。これは以前のバージョン 1.1 です。 特定のバージョンのオペレーティング システム (Windows Server 2008 または Windows Server 2008 R2) を対象とした AD FS 2.0 ソフトウェア パッケージは、AdfsSetup.exe セットアップ ファイルです。 このファイルをダウンロードするには、「 Active Directory Federation Services 2.0 RTW22」にアクセスしてください。
20 Microsoft Windows Azure プラットフォーム: http://www.windowsazure.com/21 Microsoft Office 365: http://office365.microsoft.com/22 Active Directory Federation Services 2.0 RTW: http://www.microsoft.com/download/ja-jp/details.aspx?id=10909
AD FS 2.0 での Microsoft Office 365 シングル サインオン (SSO) 9
重要なメモ:
この記事の執筆の時点では、AD FS 2.0 用の更新プログラムのロールアップ 2 を使用できます。 この更新プログラムのロールアップ (または以前のロールアップ23) には、このドキュメントで特に説明されている Office 365 のシングル サインオン機能を対象とした、AD FS 2.0 RTW の修正プログラムおよび更新プログラムが含まれます。 この更新プログラムのロールアップおよびそのダウンロードの詳細については、記事 2681584 「 Description of Update Rollup 2 for Active Directory Federation Services (AD FS ) 2.0 ( 英語 ) 24」を参照してください。
2.1 パッシブ/アクティブセキュリティ トークン サービス (STS)
AD FS 2.0 は、基本的には、セキュリティ トークン サービス (STS) です。 こうしたサービスでは、セキュリティ トークンを発行、検証、および交換できます。
セキュリティ トークンはクレームのコレクションです。クレームは、名前、 ID、電子メール、グループ、ロール、特権、機能など、ユーザーに関する説明で、承認や認証に関する決定を行う際に使用されます。.
通常、セキュリティ トークンは、標準化された安全な方法に従ってクレームをパッケージ化し、トークンを発行するクレーム プロバイダー (信頼されたフェデレーション パートナー) から、トークンを受け入れて使用する証明書利用者 (信頼するフェデレーション パートナー) に転送します。
OASIS Security Services (SAML) Technical Committee (TC) ( 英語 ) 25 によって開発された Security Assertion Markup Language (SAML) 標準では、こうしたセキュリティ トークン形式である SAML 形式が記述されてます。 Office 365 では、SAML 1.1 アサーション/トークンがサポートされています。
STS はさまざまな形式でトークンを発行し、トークン署名用の X.509 証明書によって送信中のセキュリティ トークンのコンテンツを保護できます。これにより、証明書利用者が、信頼されたクレーム プロバイダーを明確に検証できるようになります (トークンの暗号化もサポートされています)。
交換の概念により、信頼の種類、トークン形式、「インピーダンス適応」 に対するセマンティクスとクレーム (の評価) の観点からトークンの処理および変換機能が発生します。
AD FS 2.0 には、関連するクレーム要求を提供および処理できるようにクレーム パイプラインが含まれています。これは、クレームが STS を通じて従う必要があるパスを表しており、クレームをセキュリティ トークンの一部として発行するには、このパスに従う必要があります。 STS は、クレーム パイプラインのさまざまな段階におけるフロー クレームのエンド ツー エンド プロセス全体を管理します。これには、クレーム ルールベース エンジンによるクレーム ルールの処理も含まれます。
このため、AD FS では、AD DS が資格情報ストアとして使用されます。 また、AD FS 2.0 では、Active Directory Lightweight Directory Service (AD LDS)、Microsoft SQL Server データベース、その他のデータ ソースなど、複数の属性ストアの属性を使用することもできます。
23 記事 2607496 Active Directory フェデレーション サービス (AD FS) 2.0 の更新プログラムのロールアップ 1 について: http://support.microsoft.com/kb/2607496
24 記事 2681584 Description of Update Rollup 2 for Active Directory Federation Services (AD FS) 2.0: http://support.microsoft.com/kb/268158425 OASIS Security Services (SAML) Technical Committee (TC): http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security
10 AD FS 2.0 での Microsoft Office 365 シングル サインオン (SSO)
AD FS 2.0 の入門ドキュメントとして、「Understanding Key Concepts Before You Deploy AD FS 2.0 ( 英語 ) 26」をお読みになることをお勧めします。
結果的に、AD FS 2.0 は次の役割を果たします (また、これに従って、複数の種類の信頼スキーマのトポロジに参加します)。
純粋な ID プロバイダー セキュリテイ トークン サービス (IP-STS): AD FS 2.0 にクレーム プロバイダーが構成されていない場合。ただし、資格情報ストアおよびオプションの属性ストアは除きます。
IP-STS は資格情報ストアに対して認証を行います。セキュリティ トークンは、ターゲットの証明書利用者に発行されます。したがって、これに基づいてアクセス制御の決定が行われます。
純粋な証明書利用者 STS (RP-STS): AD FS 2.0 がクレーム プロバイダーを構成したが、その構成ですべてのローカル認証方法が無効になっている場合。 AD FS 2.0 は、信頼されたクレーム プロバイダー/STS でのみ認証を行うように指示できます。
RP-STS は、要求者によって提示されたセキュリティ トークンを確認した後、ターゲット リソース、またはターゲット リソースへのチェーン内の次の証明書利用者に対してセキュリティ トークンを生成します。 前者の場合は、委任トークン (Act As トークン) を発行し、委任シナリオをサポートできます。
ハイブリッド: AD FS 2.0 がクレーム プロバイダーを構成し、その構成ですべてのローカル認証方法が有効になっている場合。
2.2 異機種混在環境でのフェデレーション
公開 さ れ て い る 一 連 の フ ェ デ レ ー シ ョ ン シナリ オ に 合 わ せ て 、 AD FS 2.0 で は 、 WS-Federation、WS-Trust、SAML 2.0 など、企業で広く実装および使用されている複数の OASIS 標準をサポートしています。
実際、AD FS 2.0 では、以前のバージョン 1.1 と同様、ブラウザー ベースのパッシブ クライアント向けに WS-Fed パッシブ プロトコル ( 英語 ) 27 がサポートされています。 この仕様では、SAML アサーション形式がセキュリティ トークンに使用されていますが、その名前が示すとおり、これはプロトコルではありません。
このプロトコルは、サードパーティ IDA ベンダーのほとんどで採用されています。 したがって、AD FS 2.0 で WS-Fed パッシブ プロトコルをサポートすると、主なマーケット ソリューションとの相互運用が実現する可能性があります。 後で説明するように、このプロトコルは、Office 365 のシングル サインオン機能で使用されます。
AD FS 2.0 は、これに加え、Security Assertion Markup Language (SAML) 2.0 ( 英語 ) 28 プロトコルのほか、SAML 1.1 および 2.0 アサーション (セキュリティ トークン) もサポートしています。 ホワイト ペーパー「Using AD FS 2.0 for interoperable SAML 2.0-based federated Web Single Sign-On ( 英
26 Understanding Key Concepts Before You Deploy AD FS 2.0: http://technet.microsoft.com/en-us/library/ee913566(WS.10).aspx27 Web Services Federation Language (WS-Federation) Version 1.2: http://docs.oasis-open.org/wsfed/federation/v1.2/ws-federation.pdf28 Security Assertion Markup Language (SAML) 2.0: http://go.microsoft.com/fwlink/?LinkId=193996
AD FS 2.0 での Microsoft Office 365 シングル サインオン (SSO) 11
語 ) 29」を読むと、相互運用できる SAML 2.0 ベースのフェデレーション Web シングル サインオンを使用するときに考慮する必要があるさまざまな構成要素について理解を深めることができます。
このドキュメントの執筆の時点では、SAML プロトコル (SAML-P) は、Office 365 のシングル サインオン機能によってサポートされていません。
メモ:
SAML 仕様セットでは、XML ベースのアサーション、プロトコル、バインド、プロファイルなどが定義されまています。 SAML Core 仕様書では、SAML アサーションの一般的な構文とセマンティクス、およびこれらのアサーションを 1 つのシステム エンティティから別のシステム エンティティに要求および送信するときに使用するプロトコルについて言及しています。 SAML アサーションは、通常、クレーム プロバイダーから証明書利用者に転送されます。 Office 365 のシングル サインオン機能は現時点では SAML 2.0 プロトコル (SAML-P 2.0) をサポートしていません。ただし、認証トークンに対しては、SAML 1.1 Core 仕様書 ( 英語 ) 30で指定されているように SAML 1.1 アサーションを使用します。
メモ:
SAML-P 2.0 は、将来的にアプリケーション サポート制限付きで Office 365 のシングル サインオン機能に対して導入される可能性があります。
さらに、AD FS 2.0 は、フロントチャネル フェデレーションの SAML 2.0 と WS-Fed パッシブ プロトコルの間のゲートウェイとして動作することで、プロトコル ゲートウェイの機能をネイティブで提供します。 ホワイト ペーパー「Step-by-Step Guide: Federated Collaboration with Shibboleth 2.0 and SharePoint 2010 technologies31」では、SharePoint 2010 との関連においてこの機能を詳しく説明しています。
AD FS 2.0 は、これらのモードに対する SAML 2.0 の相互運用性のテストに合格しました。このテストについては、「Liberty Interoperability Testing Procedures for SAML 2.0 version 3.2.2 ( 英語 ) 32」に記載されています。
AD FS 2.0 のこの機能は、2008 年 2 月、Microsoft によって発表された、製品の開放性、相互運用性の向上、開発者、パートナー、顧客、および競合他社に対する新しい機会創出に関する 所信表明 ( 英 語 ) 33を受けて実現したものです。
29 Using AD FS 2.0 for interoperable SAML 2.0-based federated Web Single Sign-On: http://download.microsoft.com/documents/France/Interop/2010/Using_ADFS2_0_For_Interoperable_SAML_2_0-Based_Federated_SSO.docx30 Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML) V1.1: http://www.oasis-open.org/committees/download.php/3406/oasis-sstc-saml-core-1.1.pdf31 Step-by-Step Guide: Federated Collaboration with Shibboleth 2.0 and SharePoint 2010 technologies: http://download.microsoft.com/documents/France/Interop/2010/Federated_Collaboration_With_Shibboleth_2_0_and_SharePoint_2010_technologies-1_0.docx32 Liberty Interoperability Testing Procedures for SAML 2.0 version 3.2.2: http://www.projectliberty.org/liberty/content/download/4709/32204/file/Liberty_Interoperability_SAML_Test_Plan_v3.2.2%20.pdf
12 AD FS 2.0 での Microsoft Office 365 シングル サインオン (SSO)
人と組織の間での情報交換、そしてアプリケーションとサービスの相互運用性は、最優先すべきニーズになってきています。 Microsoft は、相互運用性のニーズについて顧客とやり取りしながら 、Microsoft 製品の開放性と相互運用性を高めていく方法に関する顧客の意見に耳を傾け、相互運用性に取り組んできました。
Microsoft では、こうした利益を実現し、ニーズを満たす目的で、相互運用性に関する 4 つの指針を Windows Server、SharePoint などの広く普及している自社製品に適用していきます。
1. これらの製品へのオープン接続を保証する
2. データの移植性を促進する
3. 業界標準のサポートを強化する
4. 相互運用性および標準のトピックに関して、オープン ソース コミュニティを含め、 IT 業界との情報交換や共同作業を進んで行う
もちろん、これらの指針は、こうした明確な目標を持つ AD FS 2.0 にも適用されます。
AD FS 2.0 は、WS-Fed パッシブ プロトコル、SAML 2.0 プロトコルなど、一般的なブラウザーベースのプロトコル以外にも、スマート クライアントに対して OASIS WS-Trust ( 英語 ) 34標準をサポートします。これは、Office 365 のシングル サインオン機能でも利用されます。
この能力はすべて市場から認められています。 実際、ヨーロッパで開催された IAM (ID およびアクセス管理) および GRC (ガバナンス、リスク管理、およびコンプライアンス ) の主要イベント、European Identity Conference (EIC) 2009 では、Microsoft の Geneva プロジェクト (AD FS 2.0 および WIF 1.0) が、「ベスト革新」 部門においてアナリスト会社 Kuppinger Cole から 2009 年 European Identity 賞 ( 英語 ) 35を受賞しました。このプロジェクトではフェデレーションがユーザー コンテナーの一部となっており、「ID フェデレーションの今後の使用と普及において非常に有意義な強化機能の 1 つである」 とされています。
2.3 このドキュメントで使用されている用語
表 1 では、このドキュメントで使用されている AD FS 2.0 関連の用語について詳しく説明します。表 1: AD FS 2.0 の用語
用語 説明
AD FS 2.0 構成データベース 1 つの AD FS 2.0 インスタンスまたはフェデレーション サービスを表す構成データがすべて保存されているデータベース。 この構成デ ー タ を保存 す る に は 、 Windows Server 2008 (R2) に付属の Windows Internal Database (WID) 機能を使用するか、Microsoft SQL Server データベースを使用します。
クレーム あるエンティティが自身について、または他の主題について作成するステートメント。 たとえば、名前、電子メール、グループ、特権、または機能に関するステートメントがあります。 クレームはプロバイダー (ここでは、Office 365 の顧客) によって発行され、1 つ以上の値が指定されます。 また、クレームの値の型、場合によっては関連付けられているメタデータによっても定義されます。
33 News Press Release. Microsoft Makes Strategic Changes in Technology and Business Practices to Expand Interoperability: http://www.microsoft.com/presspass/press/2008/feb08/02-21ExpandInteroperabilityPR.mspx34 WS-Trust Version 1.3: http://docs.oasis-open.org/ws-sx/ws-trust/200512/ws-trust-1.3-os.pdf35 European Identity Award 2009: http://www.id-conf.com/blog/2009/05/07/awards-for-outstanding-identity-management-projects/
AD FS 2.0 での Microsoft Office 365 シングル サインオン (SSO) 13
用語 説明
フェデレーション サービス AD FS 2.0 の論理インスタンス。 フェデレーション サービスは、スタンドアロン フェデレーション サーバー (FS) または負荷分散フェデレーション サーバー ファームとして展開できます。 フェデレーション サービスの名前は、既定では SSL/TLS 証明書のサブジ ェ ク ト名で す 。 フ ェ デ レ ー シ ョ ン サ ー ビ ス の DNS 名は、SSL/TLS 証明書のサブジェクト名で使用する必要があります。
フェデレーション サーバー AD FS 2.0 のフェデレーション サーバー (FS) の役割で動作するように構成された Windows Server 2008 (R2) が実行されているコンピューター。 フェデレーション サーバーは、セキュリティ トークンおよび ID 管理 に対する要求を発行、管理、および検証できるフェデレーション サービスの一部として機能します。 セキュリティ トークンは、クレーム (ユーザーの名前、ロールなど) のコレクションです。
フェデレーション サーバー ファーム
1 つのフェデレーション サービス インスタンスとして動作するように構成された、同じネットワーク内の 2 台以上のフェデレーション サーバー。
フェデレーション サーバー プロキシ
インターネット上のクライアントと、企業ネットワーク上のファイアウォールの内側にあるフェデレーション サービスの間で、中継プロキシ サービスとして動作するように構成された Windows Server 2008 (R2) が実行されているコンピューター。 スマート フォン、ホーム コンピューター、インターネット キオスクなどから Office 365 のサービスにリモート アクセスできるようにするには、フェデレーション サーバー プロキシ (FS-P) を展開する必要があります。
証明書利用者 特定のトランザクションでクレームを使用する AD FS 2.0 フェデレーション サービス、サードパーティのフェデレーション ソリューション、アプリケーション、またはサービス。
証明書利用者の信頼 AD FS 2.0 管理スナップインでは、証明書利用者の信頼は信頼オブジェクトで、自分の組織のフェデレーション サービスからクレームを使用する、他のフェデレーション サービス、アプリケーション、またはサービス (この場合は Office 365) との関係を維持するときに作成されます。
ネットワーク ロード バランサー フォールト トレランス、高可用性、および複数ノード間での負荷分散に使用される専用アプリケーション (ネットワーク負荷分散など) またはハードウェア デバイス (マルチレイヤー スイッチなど)。 AD FS 2.0 については、この NLB を使用して作成するクラスター DNS 名は、フェデレーション サーバーを最初にファームに展開したときに指定したフェデレーション サービス名と一致する必要があります。
メモ:
AD FS 2.0 の詳細については、このドキュメントの他に、製品のドキュメント ( 英語 ) 36および専用の AD FS 2.0 Q&A フォーラム ( 英語 ) 37を参照してください。
36 AD FS 2.0 TechNet のドキュメント: http://technet.microsoft.com/en-us/library/adfs2(WS.10).aspx37 AD FS 2.0 Q&A フォーラム: http://social.msdn.microsoft.com/Forums/en-US/Geneva/threads
14 AD FS 2.0 での Microsoft Office 365 シングル サインオン (SSO)
2.4 展開の種類に関する注意事項
2.4.1 ソフトウェアの前提条件と要件
フェデレーション サーバーをセットアップするには、Windows Server オペレーティング システム関連では、Microsoft Active Directory Federation Services (AD FS) 2.0 Release to Web (RTW)3839 に Windows Server 2008 Service Pack 2 (SP2) または Windows Server 2008 R2 が必要です。
メモ:
既にお気づきのように、Windows Server 2008 および Windows Server 2008 R2 には、AD FS のサーバー ロールがインストールされていますが、 これはバージョン 1.1 で適切なバージョンではありません。Office 365 のシングル サインオン機能にはバージョン 2.0 が必要です。
また、AD FS 2.0 RTW には、次のソフトウェア前提条件もあります。
インターネット インフォメーション サービス (IIS) 7 または 7.5 (Windows Server のバージョンによって異なります)。
Microsoft .NET Framework 3.5 SP1。
システム要件の詳細については、AD FS 2.0 のホーム ページ 40 を参照してください。
AD FS 2.0 をインストールしたら、AD FS 2.0 修正プログラムをインストールする必要があります。 前に説明したように、AD FS 2.0 用の更新プログラムのロールアップ 2 を使用できます。 この更新プログラムのロールアップには、このドキュメントで特に説明されている Office 365 のシングル サインオン機能を対象とした AD FS 2.0 RTW の修正プログラムおよび更新プログラムが含まれます。
2.4.2 フェデレーション サービス
上記の用語が示すように、AD FS 2.0 フェデレーション サービスは 2 つの方法で展開できます。 1 つはスタンドアロン展開で、もう 1 つはファーム展開です。
スタンドアロン フェデレーション サーバーは、フェデレーション サービスの 1 つのインスタンスです。 小規模な運用環境であるか、AD FS 2.0 テクノロジを評価している場合は、通常、スタンドアロン フェデレーション サーバーを作成します。
(負荷分散) フェデレーション サーバー ファームには複数のフェデレーション サーバーが含まれており、これらのサーバーでは、同じフェデレーション サービス インスタンスがホストされています。 高可用性および負荷分散が必要なときは、通常、ファームを作成します。 ファーム シナリオで新しいフェデレーション サービスを作成すると、ファーム内の最初のコンピューターが、そのファームのプライマリ フェデレーション サーバーになります。
38 Microsoft AD FS 2.0 Release to Web (RTW) のダウンロード: http://www.microsoft.com/ja-jp/download/details.aspx?id=10909
39 Microsoft AD FS 2.0 のダウンロード: http://www.microsoft.com/ja-jp/download/details.aspx?id=10909
40 AD FS 2.0 のホーム ページ: http://www.microsoft.com/ja-jp/server-cloud/windows-server/active-directory-overview.aspx
AD FS 2.0 での Microsoft Office 365 シングル サインオン (SSO) 15
2.4.3 構成情報の保存
AD FS 2.0 では、構成情報がデータベースに保存されます。 スタンドアロン フェデレーション サーバーでは、その構成情報はローカルの Windows Internal Database (WID) に保存されます。
WID は、手動でインストールする必要はありません。この WID を必要とする最初のアプリケーションまたはサービスによってインストールされます。 また、独自の Windows サービスで実行され、Windows Server 2008 および Windows Server 2008 R2 に付属しています。 SQL Server Express のバリアントであるこの WID は、SQL バックエンドを必要とするオンボックス アプリケーションまたはサービスを対象としています。
WID データベースは、スタンドアロン フェデレーション サーバーにある場合は読み取り /書き込みができます。一方、(負荷分散) フェデレーション サーバー ファームのシナリオでは、プライマリ フェデレーション サーバーのデータベースは読み取り/書き込みができますが、ファーム内のその他のセカンダリ フェデレーション サーバーにあるデータベースは読み取り専用です。 セカンダリ フェデレーション サーバーはファーム内のプライマリ フェデレーション サーバーに接続し、データを同期させます。これを行うには、定期的にそのサーバーに対してポーリングを行い、データが変更されていないかどうかを確認します。 セカンダリ フェデレーション サーバーの目的は、アクセス要求の負荷を分散しながら、プライマリ フェデレーション サーバーに対してフォールト トレランスを提供することです。
また、SQL Server データベースにも構成情報を保存でき、これによりパフォーマンス強化機能 (ファームごとの WID の制限である 5 台を超えるフェデレーション サーバーを使用してスケールアウトする機能を含む)、SAML トークン リプレイ検出、SAML アーティファクト解決など、追加の機能が提供されます。 詳細については、「Federation Server Farm Using SQL Server ( 英語 ) 41」を参照してください。
2.4.4 プロキシ
2.4.4.1 AD FS 2.0 フェデレーション サーバー プロキシ
フェデレーション サーバー プロキシの役割を境界ネットワークに展開すると、以下のメリットがもたらされ、AD FS 2.0 インストールのセキュリティおよびパフォーマンスが向上します。
セキュリティ: フェデレーション サーバー プロキシでは、保護されたフェデレーション サービスへのバックエンド要求から、それに対応するフロントエンド要求を切り離すことで追加の防御層を提供します。その際、スタンドアロン フェデレーション サーバーか (負荷分散) フェデレーション サーバー ファームかには左右されません。 フェデレーション サーバー プロキシでは、既知の HTTP プレフィックスに送信された要求のみが処理されます。 また、AD FS 2.0 に代わって要求に含まれるデータを検証することで (証明書の検証など)、追加の値を提供することもできます。
キーの保護: AD FS 2.0 のトークン署名秘密キーおよびサービス ID キーは、フェデレーション サーバー プロキシに保存されません。
企業のリソース: フェデレーション サーバー プロキシは、Active Directory などの企業リソースにアクセスせずに、AD FS 2.0 クライアント要求を行うことができます。
キャッシュ: フェデレーション サーバー プロキシでは、静的な HTTP コンテンツをキャッシュすることにより、フェデレーション サーバーの負荷を軽減できる可能性があります。
41 Federation Server Farm Using SQL Server: http://technet.microsoft.com/en-us/library/gg982487(WS.10).aspx
16 AD FS 2.0 での Microsoft Office 365 シングル サインオン (SSO)
また、フェデレーション サーバー プロキシを使用すると、ドメインに参加していない外部ユーザーが、標準の認証プロンプトではなく [フォーム ベース認証] ページを表示できるというメリットもあります。
フェデレーション サーバーの役割と同様、フェデレーション サーバー プロキシの役割は、スタンドアロン フェデレーション サーバー プロキシまたは (負荷分散) フェデレーション サーバー プロキシ ファームとして展開できます。
2.4.4.2 代替プロキシ
AD FS 2.0 フェデレーション サービス エンドポイント (「5.1.5 エンドポイント」を参照) を境界ネットワークからインターネットに公開/発行できる、Microsoft Threat Management Gateway (TMG) などのプロキシがあります。 詳細については、ブログの投稿「Publishing ADFS through ISA or TMG Server ( 英語 ) 42」を参照してください。
(AD FS 2.0 を Microsoft Forefront Unified Application Gateway (UAG) Service Pack 1 (SP1) アプライアンスから実装する機能もあります。 UAG SP1 for AD FS 2.0 を構成する方法については、UAG のドキュメントの記事「Deploying federation with AD FS ( 英語 ) 43」を参照してください。
42 Publishing ADFS through ISA or TMG Server: http://blog.c7solutions.com/2011/06/publishing-adfs-through-isa-or-tmg.html43 Deploying federation with AD FS: http://technet.microsoft.com/en-us/library/dd857388.aspx
AD FS 2.0 での Microsoft Office 365 シングル サインオン (SSO) 17
3 Microsoft Office 365 でのフェデレーション認証
AD FS 2.0 の構成オプションは会社によって異なるので、実行できる操作や機能を知ることは重要です。 SharePoint Online で匿名アクセスが確立されるインターネット サイトを除き、 Office 365 のサービスにアクセスするにはユーザー認証が必要です。
この目的で、Microsoft Office 365 には 2 つの種類の ID が用意されています。
1. Microsoft Online Services クラウド ID (クラウド ID): ユーザーは、Office 365 のサービスにサインインするときに使用するクラウド資格情報を受け取ります。この資格情報は、他のデスクトップまたは企業の社内用資格情報とは異なります。 サービス /クラウドでは、クラウド ID がマスター ID です。
メモ:
オプションのディレクトリ同期を使用すると、社内のマスター ユーザー ID は、クラウド ID の形式でサービス/クラウドと同期できます。
2. フェデレーション ID: 前述のシングル サインオン機能は、社内 Active Directory と一緒に使用できます。 これにより、ユーザーは、独自の Active Directory の社内用資格情報を使用して Office 365 のサービスにサインインすることができます。 社内 Active Directory のユーザー ID がマスター ID になり、これはフェデレーション ID の形式でサービスと同期できます。
ユーザーが Office 365 にアクセスするには、Office 365 ユーザー アカウントに対して認証を行います。それには、プロンプトを使って有効な資格情報を指定するか、シングル サインオン プロセスを実行します。 認証されると、ユーザーの ID は、Office 365 アカウントに関連付けられているユーザー名を参照します。 以上のことを考えると、使用できる認証方法は 3 つあります。
1. クラウド ID
2. クラウド ID とディレクトリ同期 (DirSync)
3. フェデレーション ID とディレクトリ同期 (DirSync)
この ID の種類 (クラウドとフェデレーション) は、ユーザー エクスペリエンス、管理要件、展開に関する考慮事項、および Office 365 を使用した機能に影響します。
こうした操作を次のように簡単に分類します。
クラウド ID でのユーザー エクスペリエンス: ユーザーはクラウド ID でサインインします。 クラウド ID は、従来のチャレンジ/レスポンスを使用して認証されます。ユーザーの種類はユーザー名とパスワードに含まれ、 認証はクラウドで行われます。 ユーザーは常に資格情報を入力するように求められます。
上述したように、ユーザーには 2 つの ID があります。1 つは社内サービスへのアクセス用の ID で、もう 1 つは Office 365 のサービス用の ID、つまり Microsoft Online Service クラウド ID です。したがって、ユーザーが Office 365 サービスにアクセスするときは、AD ドメインにログインしている場合でも資格情報を入力するように求められます。 この手間は、多
18 AD FS 2.0 での Microsoft Office 365 シングル サインオン (SSO)
くの場合、パスワード保存のメッセージが表示されたときに保存オプションを選択することで軽減できます。
フェデレーション ID でのユーザー エクスペリエンス: ユーザーは企業 ID を使用してサインインし、オンライン サービスおよび企業サービスにアクセスします。 つまり、 Online 365 サービスにアクセスするときは、AD FS 2.0 を使用して透過的に認証されます。 認証は組織の Active Directory に対して社内で行われ、ユーザーは本当の意味での SSO を利用できます。 さらに、2 要素認証 (2FA) が社内に展開されている場合は、これを利用することもできます。
クラウド ID での管理者エクスペリエンス: 組織の管理者は、クラウドおよび社内の両方でパスワード ポリシーを管理します。 クラウド ID のパスワード ポリシーは、Office 365 サービスと共にクラウドに保存されます。 パスワードのリセットは、社内および Microsoft Online Services クラウド ID に対して管理する必要があるので、ユーザーは、両方のポリシーに従ってパスワードを変更する必要があります。 なお、2FA は統合されていません。
フェデレーション ID での管理者エクスペリエンス: 組織の管理者は、社内についてのみパスワード ポリシーを管理するので、フェデレーション ID に対するパスワード リセットについては心配する必要がありません。 組織の Active Directory では、パスワード ポリシーを保存および制御します。 パスワードのリセットは、社内 ID に対してのみ行われます。 最終的には、複数の 2FA 統合オプションが提供されます (「6.2 OFFICE 365 向けの強力な認証 (2FA) のサポート」を参照)。
図 1: Office 365 ID プラットフォーム
このドキュメントの残りの部分では、この関連でシングル サインオン機能とフェデレーション ID について説明します。 ユーザー アカウントの作成、パスワード ポリシーなど、Office 365 クラウド ID に関する具体的な情報については、まず「Office 365 ID サ ービスの説明 44」を参照してください。
44 OFFICE 365 ID サービスの説明: http://www.microsoft.com/download/ja-jp/details.aspx?id=13602
AD FS 2.0 での Microsoft Office 365 シングル サインオン (SSO) 19
3.1 フェデレーション ID の要件
3.1.1 Active Directory の要件
組織が Office 365 のシングル サインオン機能を利用できるようにするには、ドメイン コントローラーで、少なくとも Windows Server 2003 以上が、混合モードまたはネイティブ モードの機能レベルで実行されている必要があります。
3.1.2 会社用コンピューターの要件
会社用コンピューターには、最新のサービス パックが適用された Windows XP、Windows Vista、または Windows 7 が実行されている必要があります。 さらに、Offie 365 のサービスを適切に検出および認証できるように、一連のコンポーネントと更新プログラムが、リッチ クライアント (Office Professional Plus 2010 など) が使用されている各会社用コンピューターに適用されていなければなりません。また、この会社用コンピューターは Office 365 に接続されています。
Microsoft には、自動セットアップ パッケージ、つまり Office 365 デスクトップ セットアップ アプリケーションが用意されています。これにより、必要な更新プログラムでワークステーションが自動構成されます。手動で 1 つずつ更新プログラムをインストールする必要はありません。 このアプリケーションは、Microsoft Online Services Connector の取って代わったものです。 会社用コンピューターに Office 365 デスクトップ セットアップ アプリケーションがインストールされている場合は、オペレーティング システムのすべての要件が満たされています。
Office 365 デスクトップ セットアップ アプリケーションのメリットを次に示します。
必要な更新プログラムを自動的に検出する
更新プログラムとコンポーネントを、承認後または確認なしでコマンドラインからインストールする
Internet Explorer および Lync を、Office 365 で使用できるように自動的に構成する
メモ:
この更新プログラムの要件の一覧が、更新プログラムを他の方法で展開する必要がある組織に対して発行されます。 必要な更新プログラムの一覧とその詳細については、記事「 Office 365 デスク トップの更新を手動でインストールする 45」を参照してください。
Office 365 デスクトップ セットアップ アプリケーションは、Microsoft Online ポータル (MOP) からダウンロードできます。 SharePoint Online、Outlook Web App (OWA) など、Web ベースのクライアントについては、Office 365 デスクトップ セットアップ アプリケーションをインストールする必要がありません。このアプリケーションは、Outlook、Lync などのシック クライアントを対象としています。
Office 365 デスクトップ セットアップ アプリケーションの重要な機能の 1 つが Microsoft Online Services サインイン アシスタント (MOS SIA) です。 これは Office 365 デスクトップ セットアップ アプリケーションだけを対象にしているわけではありません。このドキュメントで説明する特定の状況においても重要な機能です。
45 Office 365 デスクトップの更新を手動でインストールする: http://community.office365.com/ja-jp/wikis/administration/852.aspx
20 AD FS 2.0 での Microsoft Office 365 シングル サインオン (SSO)
メモ:
「IT プロフェッショナル用 Microsoft Online Services サインイン アシスタント RTW 46」のダウンロード (msoidcli_32bit.msi (32 ビット システム用) または msoidcli_64bit.msi (64 ビット システム用)) は IT 担当者を対象としており、System Center Configuration Manager (SCCM) または類似のソフトウェア配布システムを通じて、管理されたクライアント システムを Office 365 クライアントの展開の一部として配布することを目的としています。 MOS SIA は上述したデスクトップ セットアップ プロセスの一部としてインストールされるので、Office 365 デスクトップ セットアップ アプリケーションを使用して Office 365 をインストールするユーザーには、このダウンロードは必要ありません。
コミュニティの記事「Microsoft Online Services サインイン アシスタント (MOS SIA) の説明 47」で説明されているように、MOS SIA のコンポーネントは、一連のダイナミック リンク ライブラリ ファイル (DLL) と Windows サービスで構成されています。 これらのコンポーネントは Office サブスクリプション、Lync などのデスクトップ アプリケーションから呼び出され、Office 365 に対してユーザーを認証し、認証トークン要求を行います。 これは、AD FS 2.0 を介してバックグラウンドで行われます。
コンポーネント間のアーキテクチャ上の関係は次のとおりです。
図 2: Microsoft Online Services サインイン アシスタントのアーキテクチャの概要
46 IT プロフェッショナル 用 Microsoft Online Services サインイン アシスタント RTW: http://www.microsoft.com/download/ja-jp/details.aspx?id=28177
47 Microsoft Online Services サインイン アシスタント (MOS SIA) の説明: http://community.office365.com/ja-jp/wikis/office/1080.aspx
AD FS 2.0 での Microsoft Office 365 シングル サインオン (SSO) 21
メモ:
Windows セキュリティ サポート プロバイダー インターフェイス (SSPI) は、明確に定義された共通の API を備えたソフトウェア インターフェイスです。このインターフェイスを使用して、任意の分散アプリケーション プロトコルの認証 (およびメッセージ統合、メッセージ プライバシー、サービスのセキュリティ品質) 用に統合セキュリティ サービスを取得します。 1 つ以上のソフトウェア モジュールが実際の認証機能を提供しており、 セキュリティ サポート プロバイダー (SSP) と呼ばれる各モジュールが、ダイナミック リンク ライブラリ (DLL) として実装されます。 SSP は、1 つ以上のセキュリティ パッケージを提供します。 さまざまな SSP およびパッケージを使用できます。 Windows には NTLM セキュリティ パッケージと Microsoft Kerberos プロトコル セキュリティ パッケージが付属しています。 さらに、Secure Socket Layer (SSL) セキュリティ パッケージまたは他の SSPI 対応 SSP をインストールすることもできます。
SSPI の詳細については、Microsoft TechNet の記事「The Security Support Provider Interface ( 英 語 ) 48」および Microsoft MSDN の記事「Security Support Provider Interface (SSPI) ( 英語 ) 49」を参照してください。
以下のバイナリが %Program Files%\Common Files\Microsoft Shared\Microsoft Online Services にインストールされます。
MSOIDCLI.dll: アプリケーションが直接読み込むことができるファイル。Office 365 に対してユーザーを認証する必要があります。
MSOIDSVC.exe: Windows サービスとして、サービス名 MSOIDSVC でインストールされます。 社内 AD FS 2.0 フェデレーション サービスおよび Office 365 ID プラットフォームのサインイン サービスに対して、実際のログオンとサービス チケット要求を実行するコア コンポーネントです。
MSOIDSVC.exe: MSOIDSVC サービスを監視するウォッチドッグ プロセス。 MSOIDSVC サービスが開始すると起動します。
MSOIDRES.dll: ローカライズされたエラー メッセージのテキスト文字列が含まれるリソース ファイル。
Windows 7 システムには、以下の追加 DLL がインストールされます。
MSOIDCredProv.dll: COM オブジェクトとしてシステムに登録されている Windows 資格情報プロバイダー コンポーネントです。
MSOIDSSP.dll: %windir%\system32 フォルダーにインストールされる SSP コンポーネントです。
メモ:
64 ビット版 Windows では、msoidcli.dll および msoidres.dll が %Program Files (x86)%\Common Files\Microsoft Shared\Microsoft Online Services にインストールされます。 64 ビット版 Windows 7 では、msoidcredprov.dll もこのフォルダーにインストールされます。
MOS SIA のインストールの一環として、以下のレジストリ キーと値が作成または更新されます。48 The Security Support Provider Interface: http://technet.microsoft.com/en-us/library/bb742535.aspx49 Security Support Provider Interface (SSPI): http://msdn.microsoft.com/en-us/library/windows/desktop/aa378663(v=vs.85).aspx
22 AD FS 2.0 での Microsoft Office 365 シングル サインオン (SSO)
メモ:
一部の値のデータは、インストールされているバージョンおよび言語によって異なります。
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSOIdentityCRL]"Language" (default: dword:00000409)"TargetDir" (default: %Program Files%\Common Files\Microsoft Shared\Microsoft Online Services)"MSOIDCRLVersion" (as of writing, current version is 7.250.4287.0)
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSOIdentityCRL\Environment]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSOIdentityCRL\Environment\Production]"RemoteFile" (default: http://clientconfig.microsoftonline-p.net/PPCRLconfig.srf)
"Flags" (default: dword:00000001)"Level" (default: dword:00000002)
MOS SIA は Office 365 デスクトップに付属しますが、Office 365 デスクトップ セットアップは認証またはサインイン サービスではありません。シングル サインオンと混同しないでください。 Office 365 デスクトップ セットアップの詳細については、Office 365 のオンライン ヘルプのトピック「Office 365 用にデスクトップをセットアップする 50」を参照してください。
3.1.3 AD FS 2.0 フェデレーション サーバーの要件
Office 365 デスクトップ セットアップ アプリケーションは、Office 365 に接続するすべてのコンピューターにインストールする必要があります。これには、AD FS 2.0 フェデレーション サービス用のコンピューターが含まれます。 この要件は、フェデレーション サーバー上で、 Windows PowerShell 用 Microsoft Online Services モジュールのツールによって求められます。したがって、Office 365 環境への接続を確立するには、Windows PowerShell を使用してドメインを統合します。
50 Office 365 用にデスクトップをセットアップする: http://onlinehelp.microsoft.com/ja-jp/Office365-enterprises/ff637594.aspx
AD FS 2.0 での Microsoft Office 365 シングル サインオン (SSO) 23
メモ:
Windows PowerShell は、システム管理と自動化用に設計されたコマンド ライン シェルおよびスクリプト言語です。 この Windows Shell では、コマンドレットと呼ばれる管理タスクが使用されます。 各コマンドレットには、パラメーターと呼ばれる必須の引数とオプションの引数があり、処理対象のオブジェクトを特定するか、コマンドレットによるタスクの実行方法を制御します。 また、スクリプトでコマンドレットを結合すると、複雑な関数を実行し、さらに細かな制御を実現できます。これは、Windows およびアプリケーションの管理の自動化にも役立ち、 社内およびクラウド内で最新世代の Microsoft Server 製品を管理する一般的な方法になっています。
Windows PowerShell 2.0 の詳細については、Windows PowerShell の Web サイト 51 、Windows PowerShell のオンライン ヘルプ 52、Windows PowerShell Weblog ( 英語 ) 53、およびプログラマーズ ガイドおよび完全なリファレンスが含まれる「 Windows PowerShell Software Development Kit (SDK) ( 英語 ) 54」を参照してください。
もっと正確に言うと、Microsoft Online Services モジュールは、Office 365 デスクトップ セットアップ アプリケーションに付属する Microsoft Online Services サインイン アシスタント (MSO SIA) に依存します。
Office 365 デスクトップ セットアップ アプリケーションを AD FS 2.0 フェデレーション サーバーにインストールする手順は、クライアント インストールの手順と同じです。
3.2 フェデレーション ID のサインイン操作
サインイン操作は、使用中の Office 365 ID の種類によって変わります。 エンドユーザーのサインイン操作は、クライアントの種類、アクセス方法 (企業ネットワークの内側か外側か)、およびコンピューターがドメインに参加しているかどうかによって異なります。
表 2 では、ドメインに参加しているコンピューターに対する主な組み合わせと、その操作について説明します。
表 2: Office 365 でのフェデレーション ID のサインイン操作 (ドメインに参加しているコンピューターあり)
アプリケーション 企業ネットワーク内 企業ネットワーク外
Outlook 2010/Outlook 2007 、 Exchange ActiveSync、POP、IMAP
初回接続時 (およびパスワードを変更するたびに)、資格情報を入力するように求められます。その際、資格情報を保存するためのチェック ボックスが表示されます。
Microsoft Online ポ ー タル 、 SharePoint Online、Office Web Apps
ポップアップでクリックしてサインインするように求められます。資格情報を入力する必要はありません。1
ポップアップでクリックしてサインインするように求められます。資格情報を入力する必要があります。1
Outlook Web Apps シームレスにサインオンします。ダ 資格情報を入力するように求められ
51 Windows PowerShell の Web サイト: http://technet.microsoft.com/ja-jp/scriptcenter/dd742419.aspx52 Windows PowerShell のオンラインヘルプ: http://technet.microsoft.com/ja-jp/library/bb978526.aspx53 Windows PowerShell Weblog: http://blogs.msdn.com/powershell54 Windows PowerShell SDK: http://msdn2.microsoft.com/en-us/library/aa830112.aspx
24 AD FS 2.0 での Microsoft Office 365 シングル サインオン (SSO)
イアログは表示されません。 ます。
Office 2010/Office 2007 ア プ リ ケ ー シ ョ ン と SharePoint Online
ポップアップでクリックしてサインインするように求められます。資格情報を入力する必要はありません。
Lync 2010 と Lync Online シームレスにサインオンします。ダイアログは表示されません。
1 すべてのアプリケーションでユーザー名を入力するか、クリックしてサインインする必要があります。この操作を省略するには、スマート リンクを使用します (「6.4 Office 365 のスマート リンクを使用する」を参照)。
上記の表で示すように、フェデレーション ID を使用する場合、ドメインに参加しているコンピューターで、エンドユーザーがパスワードの入力を求められることはあまりありません。たとえば、次のような場合はパスワードは不要です。
企 業 ネ ッ ト ワ ー ク 内 で 、 ブ ラ ウ ザ ー を 使 用 し て Microsoft Online ポ ー タ ル (MOP)、SharePoint Online、または Outlook Web Apps (OWA) にアクセスする場合。
Office 2007 または 2010 アプリケーションを使用して SharePoint Online リソースにアクセスする場合。
Lync 2010 を使用して Lync Online にアクセスする場合。
Outlook ユーザーは、初回使用時に社内用資格情報を入力するように求められます。ここで、今後使用できるようにパスワードを保存できます。 パスワードを保存すると、パスワードを変更しない限り、パスワードを再入力するように求められることはありません。パスワードの変更は、組織のパスワード ポリシーに従って行われます。
表 3 では、ドメインに参加していないコンピューターに対する主な組み合わせと、その操作について説明します。
表 3: Office 365 でのフェデレーション ID のサインイン操作 (ドメインに参加しているコンピューターなし)
アプリケーション 企業ネットワーク内 企業ネットワーク外
Outlook 2010/Outlook 2007、Exchange ActiveSync、POP、IMAP
初回接続時 (およびパスワードを変更するたびに)、資格情報を入力するように求められます。その際、資格情報を保存するためのチェック ボックスが表示されます。
Microsoft Online ポ ー タル 、 SharePoint Online、Office Web Apps
ポップアップでクリックしてサインインするように求められます。資格情報を入力する必要があります。1
Outlook Web Apps 資格情報を入力するように求められます。
Office 2010/Office 2007 ア プ リ ケ ー シ ョ ン と SharePoint Online
ポップアップでクリックしてサインインするように求められます。資格情報を入力する必要があります。
Lync 2010 と Lync Online 資格情報を入力するように求められます。
1 すべてのアプリケーションでユーザー名を入力するか、クリックしてサインインする必要があります。この操作を省略するには、スマート リンクを使用します (「6.4 OFFICE 365 のスマート リンクを使用する」を参照)。
AD FS 2.0 での Microsoft Office 365 シングル サインオン (SSO) 25
3.3 フェデレーション ID の認証の種類
このセクションでは、Office 365 で動作するフェデレーション ID のユーザー認証の種類について説明します。
3.3.1 Web ブラウザーからの認証
上述したように、Office 365 は、Microsoft Online ポータル (MOP)、SharePoint Online、Outlook Web App (OWA) など、Web ブラウザーを使用してアクセスできる複数のサービスを提供します。 こうしたサービスにアクセスするとき、ブラウザーは、サインイン資格情報を指定するサインイン ページにリダイレクトされます。
フェデレーション ID のサインイン操作は次のとおりです。
1. Web ブラウザーは、Office 365 サインイン サービスにリダイレクトされます。ここで 、IETF 標準 RFC 822 Standard for ARPA Internet Text Messages ( 英語 ) 55 に基づいて書式設定さ れ た User Principal Name (UPN) ( 英語 ) 56 の形式で企業 ID を 入 力 し ま す ( 例 : [email protected])。 このサインイン サービスによって、ユーザーがフェデレーション ドメインの一部であることが判断され、認証目的での社内 AD FS 2.0 サービスへのリダイレクトが提案されます。
2. (ドメインに参加している) コンピューターにログオンしているユーザーは統合 Windows 認証 (Kerberos または NTLMv2) を使用して認証され、AD FS 2.0 によって SAML 1.1 ログオン トークンが生成されます。Web ブラウザーは、このログオン トークンを Office 365 サインイン サービスに提示します。 サインイン サービスは、ログオン トークンを使用して認証トークンを生成します。Web ブラウザーは、要求されたサービスにこれを提示し、ユーザーをログインさせます。
コンピューターに認証に対する保護の強化 (EAP) 57 が採用され、Firefox、Chrome、または Safari を使用している場合、統合 Windows 認証 (IWA) では企業ネットワーク内から Office 365 にサインインできないことがあります。 この場合は、ログオン プロンプトが定期的にユーザーに対して表示される可能性があります。これについては、記事「Office 365 で AD FS 2.0 サービス エンドポイントに ログインしようとすると、資格情報の入力を繰り返し求められる58」を参照してください。 これはAD FS 2.0 および EAP に対する (Windows 7 および修正プログラムが適用されたオペレーティング システム上の) 既定の構成が原因で発生します。
Office 365 のサービスにアクセスするクライアントについては、Firefox、Chrome、および Safari で EAP 機能がサポートされるまで、Windows Internet Explorer 8 以上をインストールして使用することをお勧めします。 Firefox、Chrome、または Safari を使用して Office 365 のシングル サインオンを使用する場合は、次のアプローチを検討できますが、これによりセキュリティ上の問題が発生する可能性があります。
認証に対する保護の強化の修正プログラムをコンピューターからアンインストールする。
55 User-Principal-Name attribute: http://msdn.microsoft.com/en-us/library/windows/desktop/ms680857(v=vs.85).aspx56 RFC 822 Standard for ARPA Internet Text Messages: http://tools.ietf.org/html/rfc822
57 認証に対する保護の強化: http://support.microsoft.com/kb/968389
58 Office 365 で AD FS 2.0 サービス エンドポイントにログインしようとすると、資格情報の入力を繰り返し求められる: http://support.microsoft.com/kb/2461628
26 AD FS 2.0 での Microsoft Office 365 シングル サインオン (SSO)
次の Set-ADFSProperties コマンドレットを使用して、AD FS 2.0 サーバーで認証に対する保護の強化設定を変更する。
PS C:\Windows\system32> Add-PSSnapin Microsoft.Adfs.Powershell PS C:\Windows\system32> Set-ADFSProperties –ExtendedProtectionTokenCheck:None
メモ:
詳細については、AD FS 2.0 運用ガイドの「AD FS 2.0 Administration with Windows PowerShell ( 英語 ) 59」および「AD FS 2.0 Cmdlets Reference ( 英語 ) 60」を参照してください。
記事「Authentication Handler Overview ( 英語 ) 61」で説明されているように、各フェデレーション サーバーの AD FS 2.0 Web ページの認証設定を、統合 Windows 認証ではなくフォーム ベース認証 (FBA) を使用するように再構成する。
3.3.2 リッチ クライアント アプリケーションからの認証
リッチ クライアントには、通常、コンピューターにインストールされる Microsoft Office デスクトップ アプリケーションが含まれます。 この種類のアプリケーションから認証を行う方法は 2 つあります。
1. Microsoft Online Services サインイン アシスタント (MOS SIA): (Office 365 デスクトップ セットアップ アプリケーションによってインストールされる ) Microsoft Online Services サインイン アシスタントには Windows サービスの MSOIDSVC.exe が含まれます。この実行プログラムは、Office 365 サインイン サービスから認証トークンを取得し、リッチ クライアントに返します。
フェデレーション ID では、このドキュメントで後で説明するように (「5.3 MEX/リッチ クライアント プロファイル認証のフローについて」を参照)、MSOIDSVC サービスは、まず AD FS 2.0 フェデレーション サービスに接続し、資格情報 (Kerberos または NTLMv2 を使用) を認証して、ログオン トークンを取得します。このトークンは、Office 365 サインイン サービスに送信されます ((WS-Federation に従って) メタデータ情報および WS-Trust を使用)。
2. SSL 経由の基本/プロキシ認証: Outlook クライアントは、基本認証の資格情報を SSL 経由で Exchnage Online に渡します。 Exchange Online は認証要求を Office 365 サインイン サービスに対してプロキシした後、(シングル サインイン用に) 社内 AD FS 2.0 にプロキシします。 認証フローについては、このドキュメントの後半で説明します (「5.4 EAS 基本認証/アクティブ プロファイル認証のフローについて」を参照)。
59 AD FS 2.0 Administration with Windows PowerShell: http://go.microsoft.com/fwlink/?LinkId=19400560 AD FS 2.0 Cmdlets Reference: http://go.microsoft.com/fwlink/?LinkId=177389).61 Authentication Handler Overview: http://msdn.microsoft.com/en-us/library/ee895365.aspx
AD FS 2.0 での Microsoft Office 365 シングル サインオン (SSO) 27
重要なメモ:
この認証では、境界ネットワーク (非武装地帯、DMZ、またはスクリーン サブネットとも呼ばれます) にプロキシ サーバーまたは AD FS 2.0 フェデレーション サーバー プロキシを展開する必要があります。
表 4 では、アプリケーションおよびオペレーティング システムのさまざまな組み合わせについて、フェデレーション ID での認証メカニズムについて詳しく説明します。
表 4: Office 365 におけるフェデレーション ID の認証メカニズム
アプリケーション 認証メカニズム
Outlook 2007/Outlook 2010、Exchange ActiveSync、POP/IMAP/SMTP クライアント
SSL 経由の基本認証。AD FS 2.0 フェデレーション サーバー プロキシを介して認証されます (完全に実装された AD FS 2.0 シナリオ)
Web ブラウザー Web サインイン、WS-Federation (AD FS 2.0)
Microsoft Office 2007/Office 2010 (Word、Excel、および PowerPoint)
Web サインイン、WS-Federation (AD FS 2.0)
Lync 2010 WS-Federation (メタデータ) および WS-Trust (サインイン アシスタントと AD FS 2.0)
28 AD FS 2.0 での Microsoft Office 365 シングル サインオン (SSO)
4 SSO 構成と関連する考慮事項について
Microsoft Online ポータル (MOP) では、シングル サインオン機能をセットアップするときに実行する必要があるすべてのインストール手順と、関連するオプションを確認できます。また、このポータルでは、こうした情報が完全に文書化されています。
認証後、MOP の [管理者] ページで、左側のウィンドウから [ユーザー] コンテナー オプションを選択するか、https://portal.microsoftonline.com/UserManagement/UserManager.aspx に移動します。
[詳細情報] リンクをクリックすると、オンライン ドキュメントである「シングル サインオンを準備 する 62」ページが表示されます。 重要な関連情報については、次のセクションで説明します。
[アクティブ化] リンクは、「シングル サインオンのセットアップと管理 63」ページに対応します。 このページでは、シングル サインオン機能をセットアップするときに実行する 10 の手順 (および必要なディレクトリ同期 (このドキュメントでは説明しません)) について順を追って説明します。
62 シングル サインオンを準備する: http://onlinehelp.microsoft.com/ja-jp/office365-enterprises/ff652540.aspx
63 シングル サインオンのセットアップと管理: https://portal.microsoftonline.com/IdentityFederation/IdentityFederation.aspx
AD FS 2.0 での Microsoft Office 365 シングル サインオン (SSO) 29
「シングル サインオン ロードマップ 64」ページでは、これらの手順の概要について説明します。
4.1 シングル サインオンを準備する
記事「シングル サインオンを準備する 65」では、シングル サインオン機能を使用したり、フェデレーション ID を適切に展開したりできるように、組織における社内 IT 環境を準備する作業について説明します。 組織の社内 Active Directory では、シングル サインオンと適切に連動するように、Active Directory ドメイン名の構造と使用の両方の観点から特定の設定を構成する必要があります。
Active Directory 環 境 を 準 備 す る に は 、 Microsoft Office 365 for Enterprise 展 開 準 備 ツ ー ル 66 (Office365DeploymentReadinessTool.exe) を実行することを強くお勧めします。このツールは 、MICROSOFT OFFICE 365 展開ガイド 67 に付属しています。
このツールは、Active Directory 環境を調査し、シングル サインオンをセットアップできる状態であるかどうかに関する情報を記載したレポートを作成します。 シングル サインオンをセットアップできる状態でない場合は、シングル サインオンを準備するのに必要な変更が一覧表示されます。
64 シングル サインオン ロードマップ: http://onlinehelp.microsoft.com/ja-jp/office365-enterprises/hh125004.aspx
65 シングル サインオンを準備する: http://onlinehelp.microsoft.com/ja-jp/office365-enterprises/ff652540.aspx
66 Microsoft Office 365 for Enterprise 展開準備ツール: http://community.office365.com/ja-jp/forums/358/t/22545.aspx
67 Microsoft Office 365 展開ガイド: http://community.office365.com/ja-jp/forums/358/t/23127.aspx
30 AD FS 2.0 での Microsoft Office 365 シングル サインオン (SSO)
関連する評価には次のトピックが含まれます。
1. UPN: フェデレーション ID では、企業ユーザーにユーザー プリンシパル名 (UPN) が必要です (Active Directory では必要ありません)。 UPN により、企業向け Office 365 におけるユーザー ID が、クラウドでの ID に関連付けられます。 この値がない場合、ユーザーは社内用資格情報を使用して Office 365 にサインインできません。
フェデレーション ID の UPN に使用できるのは、半角英数字、ピリオド、ダッシュ、および下線のみです。これ以外の文字は使用できません。 また、アットマーク (@) の前の末尾にピリオドを使用することもできません。 UPN に関する問題に対処できるように、ユーザーを一括で変更するオプションがいくつか用意されています。 この操作には、 ADModify ( 英 語 ) 68 などの複数のツールを使用できます。
ドメインの一致: Office 365 ドメイン名がローカル Active Directory のドメイン名と一致する場合は、名前空間に関して特別に考慮する必要はありません。
2. サブドメイン: 最初に最上位レベルのドメインを構成してから、サブドメインを構成します。 idmgt.fr などの最上位ドメインを登録するときに、legal.idmgt.fr、paris.idmgt.fr などのサブドメインを登録する必要はありません。 サブドメインは自動的に登録されます。
3. ローカル ドメイン: .local (idmgt.local など) または .int (idmgt.int など) として構成されたローカル ドメインはインターネットからアクセスできないので (つまり、パブリック ルーティングや DNS での識別が不可能)、フェデレーションでは使用できません。 パブリック ドメインをレジストラーに登録し、そのドメインを Office 365 に統合することはできます。 その後、新しいドメインを UPN ドメイン サフィックスとしてフォレストに追加し、その新しいドメインで UPN を指定します。 これにより、フェデレーション ユーザーの UPN ドメイン サフィックスが、Office 365 に統合したドメインに含められます。
4. 複数の独立したログオン ドメイン: 最近まで、1 つの組織内でユーザーの UPN サフィックスに対して複数の最上位レベルのドメインを使用するには (@idmgt.fr、@idmgt.co.uk など)、
68 ADModify: http://admodify.codeplex.com/
AD FS 2.0 での Microsoft Office 365 シングル サインオン (SSO) 31
AD FS 2.0 フェデレーション サービスの個別のインスタンスをサフィックスごとに展開する必要がありました。 これは、AD FS 2.0 パッケージの更新プログラムのロールアップ 2 (または以前の AD FS 2.0 パッケージの更新プログラムのロールアップ 1) には適用されません (「4.3 Microsoft Online Services モジュールのインストールと構成」を参照)。
5. 複数のフォレスト: 複数のフォレストは、現在フェデレーション ID に対してはサポートされていません。
4.2 AD FS 2.0 を計画して展開する
既に説明したように、Office 365 のシングル サインオン機能を利用し、フェデレーション ID を使用して企業ユーザーを Office 365 に対して認証するには、社内 AD FS 2.0 インフラストラクチャの準備を整えておく必要があります。 以降のセクションでは、エンドユーザーに最適なシナリオ、要件などを判断できるように、Office 365 を対象としたさまざまな AD FS 2.0 実装シナリオについて説明します。
記事「シングル サインオンで使用するために Active Directory フェデレーション サービス 2.0 を計 画して展開する69」も合わせてよくお読みになることをお勧めします。この記事には、シナリオを最終的に選択するうえで役に立つ補足的な検討事項が記載されています。
4.2.1 Office 365 用の AD FS 2.0 実装シナリオ
AD FS 2.0 フェデレーション サービスは、ほとんどのエンタープライズレベルのサービスと同様、ビジネス ニーズに基づいてさまざまな方法で実装できます。 記事「Office 365 ID フェデレーション サービスにおける AD FS 2.0 の導入シナリオ 70」で説明されているように、以下の AD FS 2.0 実装シナリオでは、社内 AD FS 2.0 フェデレーション サービスをインターネットに発行します。これにより、Office 365 のシングル サインオン機能についてより具体的に説明します。
各シナリオは、サーバー ファームではなくスタンドアロン AD FS 2.0 フェデレーション サーバーを使用することで、多様性をもたせることができます。 ただし、重要なインフラストラクチャ サービスについては、いつでもアクセスできるように、ベスト プラクティスとして高可用性テクノロジを使用して実装することを Microsoft では推奨しています。
社内 AD FS 2.0 フェデレーション サービスの可用性は、フェデレーション ID の Office 365 サービスの可用性に直接影響し、そのサービス レベルは Office 365 のお客様の責任となります。
4.2.1.1 シナリオ 1 - AD FS 2.0 の完全実装
AD FS 2.0 フェデレーション サーバー ファーム サービスの Active Directory クライアントは、シングル サインオン認証を介して要求を送信します。 (負荷分散された) AD FS 2.0 フェデレーション サーバーのプロキシは、インターネット クライアントと内部 AD FS 2.0 環境の間で要求と応答を中継することでやり取りし、こうしたコア認証サービスをインターネットに公開します。
69 シングル サインオンで使用するために ACTIVE DIRECTORY フェデレーション サービス 2.0 を計画して展開する: http://onlinehelp.microsoft.com/ja-jp/office365-enterprises/ff652539.aspx
70 OFFICE 365 ID フェデレーション サービスにおける AD FS 2.0 の導入シナリオ: http://support.microsoft.com/kb/2510193
32 AD FS 2.0 での Microsoft Office 365 シングル サインオン (SSO)
図 3: AD FS 2.0 の完全実装シナリオ
上記の図では、企業ユーザーは負荷分散された AD FS 2.0 フェデレーション サーバー ファームの内部エンドポイントにリダイレクトされますが、外部ユーザーについては、負荷分散された AD FS 2.0 フェデレーション サーバー プロキシを使用して、フェデレーション サービスにアクセスする必要があるのがわかります。
Office 365 の観点から言うと、企業ネットワーク外からのクライアントの認証要求をフェデレーション サーバー ファームにリダイレクトするという点でプロキシは外部ユーザーの役に立っていますが 、それだけではありません。 こうしたプロキシは、Outlook (2007 または 2010) がフェデレーション ID を使用して Exchange Online に接続するときに必要です。 プロキシがないと、Outlook プロファイルを作成するときに、資格情報を入力するように求められ続けます (または 401 HTTP 応答が返されます)。
まとめると、プロキシにより以下のユーザー シナリオが可能になります。
1. 会社用コンピューター、ローミング: ドメインに参加しているコンピューターに社内用資格情報を使用してログオンしているが、企業ネットワークに接続されていない (たとえば、自宅やホテルで会社用コンピューターを使用している) ユーザーは、Office 365 のサービスにアクセスできます。
2. 自宅または公共のコンピューター: 企業ドメインに参加していないコンピューターを使用する場合は、社内用資格情報を使用してサインインし、Office 365 のサービスにアクセスする必要があります。
3. ス マ ー ト フォン : ス マ ー ト フォン か ら Microsoft Exchange ActiveSync を 使 用 し て 、Microsoft Exchange Online などの Office 365 のサービスにアクセスするには、社内用資格情報を使用してサインインする必要があります。
4. Microsoft Outlook などの電子メール クライアント : Outlook (2007 または 2010) または Office に含まれていない電子メール クライアント (IMAP クライアント、POP クライアントなど) を使用している場合は、社内用資格情報を使用してサインインし、 Office 365 の電子メールにアクセスする必要があります。
この実装シナリオは Office 365 サポート サービスによって完全にサポートされ、Microsoft のベスト プラクティスに対応します。 このシナリオの構成は中規模および大規模の企業組織に適しており、 負荷に応じて、認証用のサーバーがさらに必要になる可能性があります。 AD FS 2.0 展開は、これ
AD FS 2.0 での Microsoft Office 365 シングル サインオン (SSO) 33
を考慮して、Microsoft Online ポータル (MOP)、SharePoint Online ポータル、および Outlook Web Apps (OWA) トラフィックだけでなく、オンライン サービスに対するすべての要求を処理できるように拡張する必要があります。
4.2.1.2 シナリオ 2 - ファイアウォールで公開された AD FS 2.0
AD FS 2.0 フェデレーション サーバー ファーム サービスの Active Directory クライアントは、シングル サインオン認証を介して要求を送信します。 TMG サーバー (またはサーバー ファーム) では、リバース プロキシによってコア認証サービスがインターネットに公開されます。
重要なメモ:
この機能を動作させるには、AD FS 2.0 フェデレーション サーバー ファーム上の認証に対する保護の強化 (EAP) 71 を無効にする必要がありますが、記事「「 firewall-published 」構成で Active Directory フェデレーション サービス (AD FS) を設定後、インターネットベースのクライアントコンピュー ターが認証できない」で説明されているように、無効にするとシステムのセキュリティ プロファイルが脆弱化します。72セキュリティの観点から、この方法は推奨されません。
このシナリオが Office 365 サポート サービスでサポートされるようにするには、以下の条件を満たす必要があります。
インターネット クライアントとフェデレーション サーバーの間の HTTPS (ポート 443) トラフィックのリバース プロキシが透過的である。
フェデレーション サーバーは、SAML 要求の信頼できるコピーをインターネット クライアントから受け取る必要がある。
インターネット クライアントは、社内 AD FS サーバーに直接接続されているかように、SAML 応答の信頼できるコピーを受け取る必要がある。
記事「Forefront Threat Management Gateway 2010 を使用するときに発生する Active Directory フェ デレーション サービスの可用性に関する問題のトラブルシューティング 73」には、この構成で不具合が生じる原因となる一般的な構成の問題が記載されています。
4.2.1.3 シナリオ 3 – 外部公開されていない AD FS 2.0
AD FS 2.0 フェデレーション サーバー ファーム サービスの Active Directory クライアントは、シングル サインオン認証を介して要求を送信します。サーバー ファームは、いかなる方法でもインターネットに公開されることはありません。
記事「フェデレーション ユーザーが、 Exchange Online メールボックスに接続できない 」 で説明されているように、Outlook リッチ クライアントは Exchange Online リソースに接続できません。74 この詳細については、「5.3 MEX/リッチ クライアント プロファイル認証のフローについて」を参照してください。
さらに、インターネット クライアント (モバイル デバイスを含む) では Office 365 リソースを使用できません。 したがって、サービス レベルの理由により、このシナリオが推奨されないことはわか
71 認証に対する保護の強化: http://go.microsoft.com/fwlink/?LInkId=178431
72「firewall-published」構成で Active Directory フェデレーション サービス (AD FS) を設定後、インターネットベースのクライアントコンピューターが認証できない: http://support.microsoft.com/kb/2535789
73 Forefront Threat Management Gateway 2010 を使用するときに発生する Active Directory フェデレーション サービスの可用性に関する問題のトラブルシューティング: http://support.microsoft.com/kb/2535789
74 フェデレーション ユーザーが、Exchange Online メールボックスに接続できない: http://support.microsoft.com/kb/2466333
34 AD FS 2.0 での Microsoft Office 365 シングル サインオン (SSO)
ります。これは、Office 365 のシングル サインオン機能によってサポートされるアドバタイズされたサービスが完全に提供されるわけではないからです。 このような状況において、このシナリオは Office 365 サポート サービスでサポートされます。
社内管理者は、Windows PowerShell 用 Microsoft Online Services モジュール ツールで Update-MSOLFederatedDomain コマンドを使用して、信頼されたフェデレーション データを定期的に手動で更新する必要があります (「4.3.1 MICROSOFT ONLINE SERVICES モジュールのインストール」を参照)。 詳細については、「シングル サインオンを確認および管理する 」の「 信頼済みのプロパティを 更新する 75」を参照してください。
4.2.1.4 シナリオ 4 - VPN で公開された AD FS 2.0
AD FS 2.0 フェデレーション サーバー (またはサーバー ファーム) サービスの Active Directory クライアントは、シングル サインオン認証を介して要求を送信します。サーバーまたはサーバー ファームは、いかなる方法でもインターネットに公開されることはありません。 インターネット クライアントは、社内ネットワーク環境への仮想プライベート ネットワーク (VPN) 接続を介してのみ AD FS 2.0 フェデレーション サービスに接続し、そのサービスを使用します。
インターネット クライアント (モバイル デバイスを含む) が VPN 対応でない場合、Office 365 のサービスを使用することはできません。 サービス レベルの理由から、これは推奨されません。
このシナリオが Office 365 サポート サービスでサポートされるようにするには、以下の条件を満たす必要があります。
クライアントが、HTTPS (ポート 443) 経由で DNS 名によって AD FS フェデレーション サービスに接続できる。
クライアントが、適切なポート/プロトコルを使用して、DNS 名によって Office 365 エンドポイントに接続できる。
VPN/インターネット ユーザーのシングル サインオンは、このシナリオに対応するがサポートされていない。
前のシナリオと同様、社内管理者は、Windows PowerShell 用 Microsoft Online Services モジュール ツールで Update-MSOLFederatedDomain コマンドを使用して、信頼されたフェデレーション データを定期的に手動で更新する必要があります (「4.3.1 Microsoft Online Services モジュールのインストール」を参照)。
4.2.2 AD FS 2.0 インフラストラクチャを構築する
使用できる計画オプションおよび検討すべき関連設定は多数あるので、AD FS 2.0 インフラストラクチャを構築して既存のものに適合させる手順については、このドキュメントでは説明しません。
AD FS 2.0 の詳細については、記事「シングル サインオンで使用するために Active Directory フェデ レーション サービス 2.0 を計画して展開する 76」のほかに、Microsoft TechNet の「Active Directory Federation Services (AD FS) 2.0 ( 英語 ) 」ドキュメントを参照してください。 たとえば、記事「Install the AD FS 2.0 Software ( 英語 ) 77」には、インストール手順と、使用できる多数の計画オプ
75 信頼済みのプロパティを更新する: http://onlinehelp.microsoft.com/ja-jp/office365-enterprises/ff652538.aspx#BKMK_UpdateTrustProperties
76 シングル サインオンで使用するために Active Directory フェデレーション サービス 2.0 を計画して展開する: http://onlinehelp.microsoft.com/ja-jp/office365-enterprises/ff652539.aspx77 Install the AD FS 2.0 Software: http://technet.microsoft.com/en-us/library/dd807096(WS.10).aspx
AD FS 2.0 での Microsoft Office 365 シングル サインオン (SSO) 35
ションに対する便利なチェックリストが記載されています。 最初のシナリオ 「AD FS 2.0 の完全実装」 を検討している場合、プロキシ オプションをインストールして構成するには、AD FS 2.0 フェデレーション サービスのインストールを完了しておく必要があります。
AD FS 2.0 ソフトウェア パッケージ (AdfsSetup.exe) は、「Active Directory Federation Services 2.0 RTW78」からダウンロードできます。 AD FS 2.0 用の更新プログラムのロールアップ 2 は、展開されているすべての AD FS 2.0 フェデレーション サーバーおよびフェデレーション サーバー プロキシのサーバーに適用する必要があります。 パッケージのダウンロードについては、記事 2681584「Description of Update Rollup 2 for Active Directory Federation Services (AD FS) 2.0 ( 英 語 ) 79」を参照してください。
4.3 Microsoft Online Services モジュールのインストールと構成
選択した実装シナリオ (「4.2.1 OFFICE 365 用の AD FS 2.0 実装シナリオ」を参照) に従って AD FS 2.0 インフラストラクチャの構築が完了すると、Windows PowerShell 用 Microsoft Online Services モジュールのツールのインストールに進むことができます。
メモ:
このツールは Microsoft Online Services サインイン アシスタント (MSO SIA) を必要とします。MSO SIA は、Office 365 デスクトップ セットアップ アプリケーションに含まれます。また、「IT プロフェッショナル 用 Microsoft Online Services サインイン アシスタント 80」から別途ダウンロードすることもできます。
基本的に、このツールを実行すると、シングル サインオン機能の構成を完了できるように一連のコマンドレットが環境と PowerShell インターフェイスに追加されます。 追加された Windows PowerShell コマンドレットを使用して、内部ドメインと Office 365 ID プラットフォームの間の信頼関係を構成できます。 これにより、ユーザーの認証要求を AD FS 2.0 フェデレーション サービス URL にリダイレクトできます。
また、AD FS 2.0 トークン署名で使用される証明書の公開キーがアップロードされ、フェデレーションされるクレームとドメインがアドバタイズされます。 AD FS 2.0 構成に変更が加えられた場合、構成を再度更新する必要があります。詳細については、このホワイト ペーパーの以降の部分で説明します。
4.3.1 Microsoft Online Services モジュールのインストール
Microsoft Online Services モジュールのインストールおよびシングル サインオンの構成を行うには 、AD FS 2.0 フェデレーション サーバー セッションに対する管理者特権が必要です。
ツールをインストールするには、次のように処理します。
78 Active Directory Federation Services 2.0 RTW: http://www.microsoft.com/download/ja-jp/details.aspx? id=10909
79 記事 2681584 Description of Update Rollup 2 for Active Directory Federation Services (AD FS) 2.0: http://support.microsoft.com/kb/2681584
80 IT プロフェッショナル用 Microsoft Online Services サインイン アシスタント: http://www.microsoft.com/download/ja-jp/details.aspx?id=28177
36 AD FS 2.0 での Microsoft Office 365 シングル サインオン (SSO)
1. AD FS 2.0 フェデレーション サーバー セッションからドメイン管理者としてログオンし 、Microsoft Online ポータル (MOP) のページ「シングル サインオン用に Windows PowerShell 用 Microsoft Online Services モジュールをインストールする 81」の手順 2. に移動します。
2. Microsoft Online Services モジュール (AdministrationConfig-en.msi) の該当のバージョン (32 ビットまたは 64 ビット) に対応するダウンロード リンクをクリックし、[実行] をクリックして実行します。
メモ:
このリンクは、MOP の [管理] 部分の [ユーザー] セクションの下にあるページ「シングル サイ ンオンのセットアップと管理 82 」にも含まれます。 これについては、AD FS 2.0 インストールのダウンロード ポイントの始めの部分で説明しました。また、これはプロセスの手順 3. に関連します。
Windows PowerShell 用 Microsoft Online Services モジュールのセットアップ ウィザードが表示されます。
81 シングル サインオン用に Windows PowerShell 用 Microsoft Online Services モジュールをインストールする: http://onlinehelp.microsoft.com/ja-jp/office365-enterprises/ff652560.aspx
82 シングル サインオンのセットアップと管理: https://portal.microsoftonline.com/IdentityFederation/IdentityFederation.aspx
AD FS 2.0 での Microsoft Office 365 シングル サインオン (SSO) 37
3. ウェルカム ページで、[次へ] オプションを選択します。
4. [ライセンス条項] ページで、[ライセンス条項に同意します] を選択し、[次へ] をクリックします。
5. [インストールの場所] ページで、インストール場所の既定値を選択し、[次へ] をクリックします。
38 AD FS 2.0 での Microsoft Office 365 シングル サインオン (SSO)
6. [インストールの準備完了] ページで、[インストール] をクリックします。
7. 完了ページで、[完了] オプションをクリックします。
このステージでは、「Office 365 用 Windows PowerShell コマンドレット 83」で説明されているように、以下のコマンドレットが、新しいシングル サインオン ドメイン (ID フェデレーション ドメインとも呼ばれる) を Office 365 に追加するなど、シングル サインオン (ID フェデレーションとも呼ばれる) に関連するタスクを実行します。
表 5: Office 365 用 Windows PowerShell シングル サインオン コマンドレット
シングル サインオン コマンドレット
説明
New-MsolFederatedDomain 新しいシングル サインオンを Office 365 に追加し、社内の AD FS 2.0 フェデレーション サービスと Office 365 間で証明書利用者の信頼設定を構成します。 ドメイン確認の要件によっては、新しいシングル サインオン ドメインを追加する処理を完了するために、このコマンドレットを何回か実行しなくてはならない場合があります。
Convert-MsolDomainToStandard 指定したドメインをシングル サインオンから標準認証に変換します。 このプロセスでは、AD FS 2.0 フェデレーション サービスと Office 365 内の証明書利用者の信頼設定も削除されます。 この変換後、このコマンドレットはすべての既存のユーザーをシングル サインオンから標準認証に変換します。 変換プロセスの中で、シングル サインオンが設定されていた既存のユーザー全員に、新しい一時パスワードが付与されます。 変換された各ユーザー名と新しい一時パスワードは、管理者が参照できるようにファイルに記録されます。 これで、管理者は変換された各ユーザーに新しい一時パスワードを配信して、ユーザーが Office 365 にサインインできるようにすることができます。
Convert-MsolDomainToFederated 指定したドメインを標準認証からシングル サインオンに変換します。このとき、 AD FS 2.0 フェデレーション サービスと Office 365 間で証明書利用者の信頼設定も構成されます。 標準認証からシングル サインオンにドメインを変換すると、各ユーザーも変換する必要があります。 この変換は、次回ユーザーがサインインしたときに自動的に行われます。管理者が特に作業する必要はありません。
83 Office 365 用 Windows PowerShell コマンドレット: http://onlinehelp.microsoft.com/ja-jp/office365-enterprises/hh125002.aspx
AD FS 2.0 での Microsoft Office 365 シングル サインオン (SSO) 39
シングル サインオン コマンドレット
説明
Get-MsolFederationProperty AD FS 2.0 フェデレーション サービスと Office 365 の両方から主な設定を取得します。 この情報を使用して、AD FS 2.0 フェデレーション サービスと Office 365 間の設定の不一致によって起こる認証の問題のトラブルシューティングを行えます。
Get-MsolDomainFederationSettings Office 365 の主な設定を取得します。 Office 365 と AD FS 2.0 フェデレーション サービスの両方の設定を取得するには、Get-MsolFederationProperty コマンドレットを使用します。
Remove-MsolFederatedDomain 指定したシングル サインオン ドメインを Office 365 から削除し、そのドメインに関連付けられている、AD FS 2.0 内の証明書利用者の信頼設定を削除します。メモ : 指定したドメインに関連付けられたオブジェクトが存在する場合、そのドメインを削除できません。
Set-MsolDomainFederationSettings シングル サインオン ドメインの設定を更新するために使用されます。
Set-MsolADFSContext Office 365 および AD FS 2.0 フェデレーション サービスに接続するための資格情報を設定します。 このコマンドレットは、その他のシングル サインオン コマンドレットを呼び出す前に実行する必要があります。 このコマンドレットを呼び出すときにパラメーターを省略すると、ユーザーは別のシステムに接続するための資格情報を求められます。 AD FS 2.0 フェデレーション サービスをリモートで使用する場合、ユーザーはプライマリ AD FS 2.0 サーバーのコンピューター名を指定する必要があります。 指定したログファイルは、そのセッションのすべてのシングル サインオン コマンドレットで共有されます。 ログファイルを指定しない場合、既定のログファイルが作成されます。
Update-MsolFederatedDomain AD FS 2.0 フェデレーション サービスと Office 365 の両方の設定を変更します。 構成の変更や証明書の定期的なメンテナンス (証明書の有効期限が間もなく終了する場合など) のために、AD FS 2.0 内の URL または証明書情報を変更するときは、このコマンドレットを実行する必要があります。 このコマンドレットは、Office 365 内で変更が発生した場合にも実行する必要があります。 2 つのシステム内の情報が正しいことを確認するには、Get-MsolFederationProperty コマンドレットを使用して設定を取得できます。
4.3.2 Microsoft Online Services への Windows PowerShell の接続
次に、オンライン管理者の資格情報を使用して、 Windows PowerShell 用 Microsoft Online Services モジュールから Windows PowerShell を開き、Windows PowerShell をオンライン ドメインに接続します。
Windows PowerShell を Microsoft Online Services に接続するには、次のように処理します。
1. [スタート]、[すべてのプログラム]、[Microsoft Online Services]、[Windows PowerShell 用 Microsoft Online Services モジュール] の順にクリックし、シングル サインオンのコマンドレットを使用して Windows PowerShell コマンド プロンプトを開きます。
40 AD FS 2.0 での Microsoft Office 365 シングル サインオン (SSO)
2. Windows PowerShell コマンド プロンプトで、「Connect-MsolService」と入力します。 このコマンドは、Microsoft Online 管理者の資格情報の入力を要求し、Windows PowerShell のコンテキストをオンライン管理者として設定します。
PS C:\Windows\system32> Connect-MsolServicePS C:\Windows\system32> _
メモ:
新しいバージョンの Windows PowerShell モジュールが存在する場合、新しいバージョンが利用可能であることを示す黄色の警告テキストが表示されます。 常に最新バージョンのモジュールを実行するようにしてください。
3. 通常、 AD FS 2.0 サ ー バ ー 上 で 作 業 を 行 っ て い な い 場 合 は 、 コ マ ン ド Set-MsolADFSContext を実行して AD FS コンテキスト サーバーを設定する必要があります。 このコマンドでは、AD FS 2.0 サーバーのホスト名の入力が求められます。
PS C:\Windows\system32> Set-MsolADFSContext
コマンド パイプライン位置 1 のコマンドレット Set-MsolADFSContext次のパラメーターの値を指定してください:コンピューター: idmgt-dcPS C:\Windows\system32> _
AD FS 2.0 サーバー上で作業を行っている場合、このコマンドレットを実行する必要はありません。
4.3.3 フェデレーション ドメインとしての新しいドメインの作成
Windows PowerShell を Microsoft Online Services に接続した後に Windows PowerShell コマンドプロンプトから新しいドメインをフェデレーション ドメインとして作成するには、次のように処理します。
1. Windows PowerShell を Microsoft Online Services に接続します (「4.3.2 MICROSOFT ONLINE
SERVICES への WINDOWS POWERSHELL の接続」を参照)。
2. コマンド New-MsolFederatedDomain –DomainName <ドメイン名> を実行します。
PS C:\Windows\system32> New-MsolFederatedDomain –DomainName demo.idmgt.archims.fr警告: ドメイン レジストラーで ps.microsoftonline.com を指している DNS の demo.idmgt.archims.fr CNAME レコードを追加して、demo.idmgt.archims.fr のドメイン所有者を確認してください。 詳細については、
AD FS 2.0 での Microsoft Office 365 シングル サインオン (SSO) 41
http://technet.microsoft.com/en-us/library/cc742578.aspx を参照してください。PS C:\Windows\system32> _
図 4new-MsolFederatedDomain コマンドレットの 1 回目の実行
3. ドメイン名レジストラーに登録されているドメインに対して、ドメインの所有者の証明に関する TXT レコード (または必要に報じて MX レコード) を作成します。例:
エイリアスまたはホスト: demo.idmgt.archims.fr値: v=verifydomain MS=ms90115610TTL: 1 時間
実際に、Office 365 は、ユーザーのレジストラーで作成された DNS レコードを使用して、そのユーザーがドメインを所有していることを確認します。 詳細については、記事「Office 365 にドメインを追加する 84」および「任意のドメイン名レジストラーでドメインを確認す る 85」を参照してください。
4. 上 記 の 警 告 に 従 っ て ド メ イ ン レ コ ー ド を 作 成 し た 後 、 コ マ ン ド New-MsolFederatedDomain –DomainName <ドメイン名> を再度実行してプロセスを完了します。
PS C:\Windows\system32> New-MsolFederatedDomain –DomainName demo.idmgt.archims.fr正常に demo.idmgt.archims.fr ドメインを追加しました。 PS C:\Windows\system32> _
これにより、ドメインの所有者の証明が確認されます。 新しく登録されたドメインは、Exchange Online と同様に、Office 365 サービスに伝達されます。
名前空間は 「フェデレーション名前空間」 として予約されます。
名前空間ごとに AD FS 2.0 フェデレーション サービスのパブリック エンドポイントが https://adfs.demo.idemgt.archims.com/adfs/ls/ に設定されます。
Exchange Online では、登録されたドメインが承認済みドメインとして作成されます。
84 OFFICE 365 にドメインを追加する: http://onlinehelp.microsoft.com/ja-jp/office365-enterprises/ff637620.aspx
85 任意のドメイン名レジストラーでドメインを確認する: http://onlinehelp.microsoft.com/ja-jp/office365-enterprises/gg584188.aspx
42 AD FS 2.0 での Microsoft Office 365 シングル サインオン (SSO)
図 5new-MsolFederatedDomain コマンドレットの 2 回目の実行
メモ:
ドメインを Microsoft Online ポータル (MOP) から追加することもできます。 追加手順は同じです。また、ドメインを同じ方法で確認する必要もあります。 MOP 経由でドメインを追加した場合、ユーザーはコマンド ラインからドメインをフェデレーションに変換するだけで済みます。コマンド ラインからすべての処理を 1 回の操作で容易に行うことができます。 ドメインの変換手順については、以降で説明します。
上記の手順を完了すると、ドメインが正しく追加されたこと、およびドメインが Microsoft Online ポータル (MOP) によってフェデレーションされていることを確認できます。 MOP で作業している場合は、ナビゲーションバー内の上部にある [管理者] オプションを単に選択します。 次に、左の列で、[ユーザー管理] の下にある [ドメイン] を選択し、追加したドメインを選択します。そのドメインがフェデレーションされていることが表示されます。
AD FS 2.0 での Microsoft Office 365 シングル サインオン (SSO) 43
ドメインが 「フェデレーション」 になっている場合、ドメイン サフィックスを Microsoft Online ユーザー アカウントに追加できなくなります。 フェデレーション ドメイン名をユーザーが使用できるようにするには、ユーザーを社内で作成する必要があります。 依然としてアカウントをクラウド内で直接作成することもできますが、アカウントを社内で作成しない限り、アカウントにフェデレーション ドメイン名を割り当てることはできません。
4.3.4 AD FS 2.0 構成のすべての変更内容の更新
Office 365 ID プラットフォームを AD FS 2.0 フェデレーション サービスからの新しい設定で更新しなければならない場合があることはよくあります。
トークン署名証明書、フェデレーション サービス名、フェデレーション サービス識別子など、 AD FS 2.0 フェデレーション サービスからのフェデレーション メタデータは、実際には、テナント ドメインがフェデレーションの種類に最初に変換されるときに、Office 365 ID プラットフォームと 1 回のみ同期されます。
AD FS 2.0 のメタデータの一部が社内で変更されると、Office 365 との信頼関係が完全に壊れる場合があり、テナントの全社規模で機能が停止する可能性があります。
情報の更新が必要になる一般的な問題を以下に示します。
AD FS 2.0 フェデレーション サーバーまたは (負荷分散された) AD FS 2.0 フェデレーション サーバー プロキシ、あるいはその両方で、SSL/TLS 証明書の有効期限が切れている (通常は 1 年単位)。
AD FS 2.0 フェデレーション サーバーまたは (負荷分散された) AD FS 2.0 フェデレーション サーバー プロキシ、あるいはその両方に対して新しい証明書が発行された。
AD FS 2.0 実装シナリオが進展した (「4.2.1 OFFICE 365 用の AD FS 2.0 実装シナリオ」を参照)。
AD FS 2.0 フェデレーション サービスのエンドポイントの URL が変更された。
44 AD FS 2.0 での Microsoft Office 365 シングル サインオン (SSO)
証明書または構成自体との不一致がある。 フェデレーション ID を持つユーザーが社内用の資格情報を使用して Office 365 にアクセスするときに [サイトへのアクセスで問題が発生しました。サイトを再度参照してください。] というエラーが表示された。
その他
このすべての問題を解決するには、現在の構成情報を更新して社内の情報を Office 365 ID プラットフォーム内の情報と一致させる必要があります。
構成を手動で更新するには、次のように処理します。
1. Windows PowerShell を Microsoft Online Services に接続します (「4.3.2 MICROSOFT ONLINE
SERVICES への WINDOWS POWERSHELL の接続」を参照)。
2. コマンド Update-MsolFederatedDomain –DomainName <ドメイン名> を実行します。
代わりに、Microsoft Office 365 フェデレーション メタデータの更新オートメーション インストール ツール ( 英語 ) 86を使用して、Microsoft Office 365 フェデレーション メタデータの定期的な更新を自動化できます。これにより、AD FS 2.0 フェデレーション サービスで構成されたすべての変更内容が Office 365 ID プラットフォームに自動的に確実にレプリケートされます。
このツールはスケジュールされたタスクとして実行され、Microsoft Online (MSOL) の資格情報を AD FS 2.0 サーバー上の資格情報マネージャーに安全に保管します。また、このツールは、新しいメタデータを Office 365 に定期的にプッシュすることで、運用メタデータの変更による機能停止を回避したり最小限に抑えたりします。
構成を自動的に更新するには、次のように処理します。
1. 管理者として AD FS 2.0 サーバーにログインします。
2. オ ン ラ イ ン ギャラ リ ー か ら テ キ ス ト フ ァ イ ル O365-Fed-MetaData-Update-Task-Installation.ps1.txt をダウンロードして、AD FS 2.0 サーバーのデスクトップ上に .ps1 ファイルとして保存します。
3. 新しく作成したファイル O365-Fed-MetaData-Update-Task-Installation.ps1 を右クリックして [プロパティ] をクリックします。次に、[全般] タブで [ブロックの解除] をクリックし、[OK] をクリックします。
4. [スタート] メニューから管理用の Windows PowerShell ウィンドウを起動し、ディレクトリを [デスクトップ] に変更します。
5. 次のコマンドを実行し、サーバー上でスクリプトを実行できるように Y を押します。
PS C:\Users\Administrator> Set-ExecutionPolicy 無制限
86Microsoft Office 365 フェデレーション メタデータの更新オートメーション インストール ツール http://gallery.technet.microsoft.com/scriptcenter/Office-365-Federation-27410bdc
AD FS 2.0 での Microsoft Office 365 シングル サインオン (SSO) 45
6. 手順 2. で保存した .ps1 ファイルを実行します。
PS C:\Users\Administrator> cd .\DesktopPS C:\Users\Administrator>.\O365-Fed-MetaData-Update-Task-Installation.ps1
7. フェデレーション ドメイン (例: 「demo.idmgt.archims.fr」) を入力して確認します。
8. 以下のように、グローバル管理者アカウントとパスワードを入力します。
ユーザー名: [email protected]
パスワード: ****************
オンライン資格情報の入力が正常に完了すると、次のメッセージが表示されます。
SuccessAdded MSOL credentials to the local Credential Manager
9. 現在ログオンしている管理者のパスワードを入力します。
10. ツールは処理を実行して終了します。
指定した MSOL 資格情報が AD FS 2.0 サーバーに安全に保管されます。これにより、Windows PowerShell 用 Microsoft Online Service モジュールのコマンドレットを、スケジュールされたタスクとして実行し、社内の AD FS 2.0 フェデレーション サービスと Office 365 の間でメタデータを最新の状態に維持できます。
MSOL 資格情報を確認するには、次のように処理します。
46 AD FS 2.0 での Microsoft Office 365 シングル サインオン (SSO)
1. [スタート] をクリックし、[検索] フィールドに「資格情報」と入力して、検索結果の [資格情報マネージャー] をクリックします。
2. Microsoft-Office365-Update-MSOLFederatedDomain-DEMO.IDMGT.ARCHIMS.FR と い う名前の新しい汎用資格情報、およびツールに入力したグローバル管理者のユーザー名 ([email protected]) を確認します。
3. [資格情報マネージャー] を閉じます。
作成された、スケジュールされたタスクを確認するには、次のように処理します。
1. [スタート] をクリックし、[検索] フィールドに「タスク」と入力して、検索結果の [タスク スケジューラ] をクリックします。
AD FS 2.0 での Microsoft Office 365 シングル サインオン (SSO) 47
2. [タスク スケジューラ ライブラリ ] を選択し、リスト内にある Microsoft-Office365-Update-MSOLFederatedDomain-DEMO.IDMGT.ARCHIMS.FR という名前のタスクを表示します。
a. このタスクは毎日深夜に実行されます。b. このタスクは、ツール内で指定された管理者アカウントとして実行されます。c. このツールは以下の処理を実行します。
C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe –command C:\Office365-Scripts\Microsoft-Office365-Update-MSOLFederatedDomain-DEMO.IDMGT.ARCHIMS.FR.ps1
3. [タスク スケジューラ] を最小化します。
4. C:\Office365-Scripts に移動します。
5. Microsoft-Office365-Update-MSOLFederatedDomain-DEMO.IDMGT.ARCHIMS.FR.ps1 という名前の .ps1 ファイルおよび History.log という名前のログ ファイルがあります。
6. History.log を開くと、ツールのインストール場所を確認できます。
4.4 シングル サインオンの確認
記事「シングル サインオンを確認して管理する 87」で説明されているように、シングル サインオンの確認およびトラブルシューティングを行ってシングル サインオンを可能な限り容易な状態にしておくことが最善の方策です。 Lync または Exchange Online アクセスに関する問題に直面した場合も、単に社内用の資格情報を使用して Microsoft Online ポータル (MOP) にアクセスし、シングル サインオンが正常に機能しているかどうかを確認することが最善の方策です。 これにより、問題がアプリケーション/サービスに固有の問題であるか、シングル サインオンに関する問題であるかを確認できます。 ユーザーが社内用の資格情報を使用して MOP にサインオンでき、OWA にサインオンできない場合、問題はシングル サインオンに関連しないことを確認できます。
87 シングル サインオンを確認して管理する: http://onlinehelp.microsoft.com/ja-jp/office365-enterprises/ff652538.aspx
48 AD FS 2.0 での Microsoft Office 365 シングル サインオン (SSO)
シングル サインオンを確認するには、次のように処理します。
1. Internet Explorer を開き、 https://portal.microsoftonline.com に移動して Microsoft Online ポータル (MOP) にアクセスします。 login.microsoftonline.com の URL に直ちにリダイレクトされます。この URL は、Microsoft Online Services の ID プロバイダーです。
2. [ユーザー ID] に社内用の企業 UPN を入力します。
3. [パスワード] の内側をクリックします。 これにより、フェデレーション ID のホーム領域検出 (HRD) プロセスが起動され、UPN のドメイン部分がフェデレーションされているかどうかが確認されます。
メモ:
IE で HTTP トレースを有効にしたり、Fiddler2 ( 英語 ) 88 HTTP トレース アプリケーションのようなツールでトラフィックを監視したりしている場合、 login.microsoftonline.com の URL で、ホーム領域検出 (HRD) プロセスの一環として GetUserRealm が呼び出されていることを確認できます。 また、その結果に AD FS 2.0 フェデレーション サービスのパッシブ エンドポイント情報が表示されていることも確認できます (「5.1.5 エンドポイント」を参照)。
4. シングル サインオンが正しくセットアップされている場合、ユーザーはここでパスワードを入力することもできません。 [パスワード] は網掛け表示されます。 ユーザーに AD FS 2.0 フェデレーション サービスへのリンクが提供されます。 [<ユーザーの会社> にサインインする必要があります] というメッセージが表示されます。
88 Fiddler2: http://www.fiddler.com
AD FS 2.0 での Microsoft Office 365 シングル サインオン (SSO) 49
5. [<ユーザー の 会 社 > に サ イ ン イ ン す る ] リ ン ク ( 上 記 の ス ク リ ー ン キャプ チャの [Demo.idmgt.archims.fr にサインインする] リンク) をクリックします。 これは、ユーザーを AD FS 2.0 フェデレーション サービスのパッシブ エンドポイントに送るためのリダイレクト リンクです。 次に、ユーザーは社内用の資格情報を提供します。 ユーザーがドメインに接続されている場合、AD FS 2.0 エンドポイントに到達します。このとき、資格情報の要求はありません。
サインインできる場合、シングル サインオンは正しくセットアップされています。
50 AD FS 2.0 での Microsoft Office 365 シングル サインオン (SSO)
5 Office 365 でのフェデレーション認証のしくみについて
このセクションの目的は、Windows PowerShell 用 Microsoft Online Services モジュールを使用して確立された構成に関する追加の情報を提供し、シングル サインオンをセットアップすることです。 このセクションでは、AD FS 2.0 の結果の設定について説明するほかに、トランザクションに関与する主なコンポーネント間のやりとりの種類、つまり、クライアント、社内の AD FS 2.0 インフラストラクチャ、Office 365 ID プラットフォーム (およびそのサインイン サービス)、および Office 365 内のサービスの間のやり取りの種類についていくつか説明します。
5.1 AD FS 2.0 構成について
5.1.1 AD FS 2.0 要求パイプラインとエンジンに関する簡単な説明
前述のとおり、AD FS 2.0 フェデレーション サービスは要求ベースのモデルに依存する STS です。 このモデルにおける要求パイプライン (「The Role of the Claims Pipeline ( 英語 ) 89」を参照) とは、要求がフェデレーション サービス全体にわたって従う必要のあるパスのことです。要求を SAML トークンの一部として発行できるようにするには、要求はこのパスに従う必要があります。
フェデレーション サービスは、要求パイプラインの様々なステージに要求を流すエンド ツー エンド プロセス全体を管理します。これには、要求規則ベースのエンジン (「The Role of the Claims Engine ( 英語 ) 90」を参照) によるさまざまな要求規則セットの処理も含まれます。
要求エンジンは、要求パイプラインの特定のステージに関連する 3 つの主要タスクを処理します。
1. 要求プロバイダーからの入力方向の要求を受け付ける (変換の承諾規則)。
2. 要求の要求側を承認する (承認の発行規則)。
3. 証明書利用者への出力方向の要求を発行する (変換の発行規則)
図 6AD FS 2.0 要求パイプライン
要求パイプラインの一部として要求規則を処理する要求エンジンのほかに、AD FS 2.0 構成には、この機能全体を制御する 3 つの主な関係があります。
89 The Role of the Claims Pipeline: http://technet.microsoft.com/en-us/library/ee913585(WS.10).aspx90 The Role of the Claims Engine: http://technet.microsoft.com/en-us/library/ee913582(WS.10).aspx
AD FS 2.0 での Microsoft Office 365 シングル サインオン (SSO) 51
1. 属性ストア: この場所で、AD FS 2.0 フェデレーション サービスは属性を照会し、要求のソースを特定します。 Active Directory ドメイン サービス (AD DS) が既定で宣言されている場合、AD FS 2.0 フェデレーション サービスは、Active Directory ライトウェイト ディレクトリ サービス (AD LDS)、Microsoft SQL Server データベース、その他のデータ ソースなど、他のいくつかの属性ストアからの属性を使用することもできます。
2. 要求プロバイダーの信頼: この場所で、AD FS 2.0 フェデレーション サービスと要求プロバイダーの間のフェデレーション信頼が構成されます。 変換の承諾規則と呼ばれる一連の規則に基づいて、要求プロバイダーからの要求はフィルター処理されるか、トランザクションのコンテキストで証明書利用者の信頼に渡されます。 社内の Active Directory は、Office 365 とのシングル サインオンに関する要求プロバイダーです。
3. 証明書利用者の信頼: この場所で、AD FS 2.0 フェデレーション サービスと証明書利用者の間のフェデレーション信頼が構成されます。 ここで、フェデレーション サービスは、 承認の発行規則に基づいてどのユーザーが証明書利用者にアクセスできるかを制御した後、変換の発行規則に基づいて要求を証明書利用者に発行します。 Office 365 ID プラットフォームは、Office 365 とのシングル サインオンに関する証明書利用者です。逆に、Office 365 では、Exchange Online、SharePoint Online などが Office 365 ID プラットフォームの証明書利用者であると言えます。
5.1.2 要求の説明
AD FS 2.0 フェデレーション サービスによって Office 365 ID プラットフォームの証明書利用者に発行される SAML 1.1 ログオン トークンには、社内の Active Directory 要求プロバイダー (次のセクションを参照) をソースとする要求が含まれます。この Active Directory 要求プロバイダーによって、Office 365 サインイン サービスはユーザーをクラウド内のシャドウ ID と照合できます。
社内ユーザーのユーザー原則名 (UPN)。ディレクトリ同期によって、プロビジョニングされたユーザーの値に関連付けられます。
名前変更可能な一意のユーザー ID。この値は、クラウド内のオブジェクトの有効期間中、不変である必要があります。 そうでない場合、オブジェクトが重複して、予期しない同期エラーが発生する可能性があります。
既定では、これは、社内の Active Directory オブジェクトの GUID (ImmutableID) です。 オブジェクト GUID ByteArray は、Base64 文字列に変換されます。
それぞれの詳細については、要求に関する次の 2 つの説明を参照してください。
UPN (http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn)。
ソース ユーザー ID (http://schemas.microsoft.com/LiveID/Federation/2008/08/ImmutableID)。
5.1.3 社内の Active Directory 要求プロバイダーの信頼
変換の承諾規則セットでは、Active Directory 属性ストアに関する以下の規則が宣言されます。
52 AD FS 2.0 での Microsoft Office 365 シングル サインオン (SSO)
入力方向の要求の種類は以下のとおりです。
Windows アカウント名
名前
プライマリ SID
グループ SID
プライマリ グループ SID
拒否のみグループ SID
拒否のみプライマリ SID
拒否のみグループ SID
認証方法
認証タイム スタンプ
5.1.4 Microsoft Office 365 ID プラットフォームの証明書利用者の信頼
Microsoft Online Services モジュールのコマンドレット (「4.3.3 フェデレーション ドメインとしての新しいドメインの作成」を参照) を使用してドメインをフェデレーション ドメインとして作成すると、Microsoft Office 365 ID プラットフォームの証明書利用者の新しい信頼の自動定義が作成されます。
5.1.4.1 プロパティ
[Microsoft Office 365 ID プラットフォーム] プロパティの [監視] タブには、Office 365 サインイン サービス メタデータの取得元の URL (https://nexus.microsoftonline-p.com/federationmetadata/2007-06/federationmetadata.xml) が表示されます。
AD FS 2.0 での Microsoft Office 365 シングル サインオン (SSO) 53
またこのタブには、信頼定義が AD FS 2.0 機能を使用して、証明書利用者のメタデータを監視すること、および信頼定義を自動的に更新して証明書利用者の現在の設定を反映することも示されています。
「フェデレーションが壊れている場合、問題は PKI にあります。問題が PKI にない場合はタイポがあります。正確に入力されている場合 (ケース カウント)、問題はやはり PKI にあります。」
Laura E. Hunter
これにより、Office 365 ID プラットフォーム側で発生したすべての変更内容がシームレスに取り入れられます。 この機能によって、AD FS 2.0 フェデレーション サービス側の証明書利用者の信頼を維持するための管理作業が大幅に軽減されます。
逆に言うと、これは以下の機能に特化した役割です。
信頼情報を手動で更新するための Windows Powershell 用 Microsoft Online Services モジュールのコマンドレット Update-MsolFederatedDomain
または
信頼情報を自動で更新するための Microsoft Office 365 フェデレーション メタデータの更新オートメーション インストール ツール
AD FS 2.0 フェデレーション サービス側で情報が変更された場合や、Office 365 ID プラットフォーム側 (「4.3.4 AD FS 2.0 構成のすべての変更内容の更新」を参照) に情報を反映するために、これらによって信頼情報 (つまりフェデレーション メタデータ) が更新されます。
Office 365 サインイン サービスのメタデータを以下に示します。 メタデータの一般的な構文およびセマンティクスについては、「OASIS Web Services Federation Language (WS-Federation) Version 1.2 ( 英語 ) 91」で定義されています。
<?xml version="1.0" encoding="utf-8"?><EntityDescriptor wsu:Id="0c0d1ca7-7292-4bc6-801c-f880f6098f4e" entityID="urn:federation:MicrosoftOnline" xmlns="urn:oasis:names:tc:SAML:2.0:metadata" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"> <RoleDescriptor xsi:type="fed:SecurityTokenServiceType" protocolSupportEnumeration="http://schemas.xmlsoap.org/ws/2005/02/trust http://docs.oasis open.org/wsfed/federation/200706" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:fed="http://docs.oasis-open.org/wsfed/federation/200706"> <KeyDescriptor use="signing" wsu:Id="stscer"> <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
91 OASIS Web Services Federation Language (WS-Federation) Version 1.2 : http://docs.oasis-open.org/wsfed/federation/v1.2/os/ws-federation-1.2-spec-os.pdf
54 AD FS 2.0 での Microsoft Office 365 シングル サインオン (SSO)
<X509Data> <X509Certificate>MIICWzCCAcSgAwIBAgIJANswIPW/+LJFMA0GCSqGSIb3DQEBBQUAMCkxJzAlBgNV BAMTHkxpdmUgSUQgU1RTIFNpZ25pbmcgUHVibGljIEtleTAeFw0xMDA3MTYyMTI0 NTZaFw0xNTA3MTUyMTI0NTZaMCkxJzAlBgNVBAMTHkxpdmUgSUQgU1RTIFNpZ25p bmcgUHVibGljIEtleTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAlM7mGMQ6 Ha0JP8odYF4ArNF294zQzoRoR7PSv88tyHD/6wINeVn/ebD+XVI9ebRmRFdJYRFr dqOrYwJOPmq9bG+zF2HblKX718BcAKw7Ku6iqkk0YwtCM1hijr9FlyBGIS9XoE+Y y/qs+WNJyaUnXIw0YMwvoj0ev0KOtd6X7ekCAwEAAaOBijCBhzAdBgNVHQ4EFgQU v0DdCHPD3pifWehnZfE6eCztZj8wWQYDVR0jBFIwUIAUv0DdCHPD3pifWehnZfE6 eCztZj+hLaQrMCkxJzAlBgNVBAMTHkxpdmUgSUQgU1RTIFNpZ25pbmcgUHVibGlj IEtleYIJANswIPW/+LJFMAsGA1UdDwQEAwIBxjANBgkqhkiG9w0BAQUFAAOBgQBP FFgHrWNtMRHsbjb/YUj67a7YvVnht11yH73oWLDdS/WW4VYHB3RiZuxU07EtIFXk yjRQ2lmHuza9+IljVKirLw8Zp6CH6tTiZC8WiyRI8cgenztPLO7x1Rwbg5d4bKkV P0dX7pe/Z6hrouK9Xc8828mjL09OlyiH6L+tZc0hJw== </X509Certificate> </X509Data> </KeyInfo> </KeyDescriptor> <KeyDescriptor use="signing" wsu:Id="stsbcer"> <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#"> <X509Data> <X509Certificate>MIICWzCCAcSgAwIBAgIJAOAWPCFtWFILMA0GCSqGSIb3DQEBBQUAMCkxJzAlBgNV BAMTHkxpdmUgSUQgU1RTIFNpZ25pbmcgUHVibGljIEtleTAeFw0xMDA3MTYyMTI0 MjZaFw0xNTA3MTUyMTI0MjZaMCkxJzAlBgNVBAMTHkxpdmUgSUQgU1RTIFNpZ25p bmcgUHVibGljIEtleTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEArFszs9TG 9LSN0yT3PDzEMCql9OAN3qV6vv6HSoJR2E1WFZAXEt9KpO9AwVkD0pxat1DoCztf dVlhk+ZhD8yv7x1PIzQJsLxC233Ch6pd3riFSJdA0BJtgr7V07You6keKDj6hYWk Io97zOFMbnR8GrJXxOaAR4bvwaF2osYjY3UCAwEAAaOBijCBhzAdBgNVHQ4EFgQU m7Ph5zX8u1dUl8zE+5jQ+KarrUYwWQYDVR0jBFIwUIAUm7Ph5zX8u1dUl8zE+5jQ +KarrUahLaQrMCkxJzAlBgNVBAMTHkxpdmUgSUQgU1RTIFNpZ25pbmcgUHVibGlj IEtleYIJAOAWPCFtWFILMAsGA1UdDwQEAwIBxjANBgkqhkiG9w0BAQUFAAOBgQBd aADu9GMezEPONs2wXMXZnwc3BAFWlP+hlp5T+vuVZlSsczyTn9Kmbw3oos8EMmro GrzuxF3g71533ZnRC+Z+x1rltMXiI7vIcbwY1h3E6nt5X3/q/rhQu2bsCx7D9051 pCdWWSxjYHz2MH29x68OXOF0447aXyCzCg7O7Lj1cw== </X509Certificate> </X509Data> </KeyInfo> </KeyDescriptor> <fed:ClaimTypesOffered> <auth:ClaimType Uri="http://schemas.xmlsoap.org/claims/EmailAddress" Optional="True" xmlns:auth="http://docs.oasis-open.org/wsfed/authorization/200706"> <auth:DisplayName> 電子メール アドレス </auth:DisplayName> </auth:ClaimType> <auth:ClaimType Uri="http://schemas.xmlsoap.org/ws/2006/12/authorization/claims/action" Optional="True" xmlns:auth="http://docs.oasis-open.org/wsfed/authorization/200706"> <auth:DisplayName> Action for which the token is valid </auth:DisplayName> </auth:ClaimType> <auth:ClaimType Uri="http://schemas.microsoft.com/ws/2006/04/identity/claims/RequestorDomain" Optional="True" xmlns:auth="http://docs.oasis-open.org/wsfed/authorization/200706"> <auth:DisplayName> Domain name of the entity that requested the token on behalf of the user </auth:DisplayName> </auth:ClaimType> <auth:ClaimType Uri="http://schemas.microsoft.com/ws/2006/04/identity/claims/ThirdPartyRequested" Optional="True" xmlns:auth="http://docs.oasis-open.org/wsfed/authorization/200706"> <auth:DisplayName> Indicates this token was not requested directly by the user. </auth:DisplayName> </auth:ClaimType> </fed:ClaimTypesOffered> <fed:TokenTypesOffered> <fed:TokenType Uri="urn:oasis:names:tc:SAML:1.0"/> </fed:TokenTypesOffered> <fed:MexEndpoint> <EndpointReference xmlns="http://www.w3.org/2005/08/addressing"> <Address>https://login.microsoftonline.com/login.srf</Address> </EndpointReference> </fed:MexEndpoint> <fed:PassiveRequestorEndpoint> <EndpointReference xmlns="http://www.w3.org/2005/08/addressing"> <Address>https://login.microsoftonline.com/login.srf</Address> </EndpointReference> </fed:PassiveRequestorEndpoint> </RoleDescriptor>
AD FS 2.0 での Microsoft Office 365 シングル サインオン (SSO) 55
<RoleDescriptor xsi:type="fed:ApplicationServiceType" protocolSupportEnumeration="http://schemas.xmlsoap.org/ws/2005/02/trust http://docs.oasis- open.org/wsfed/federation/200706" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:fed="http://docs.oasis-open.org/wsfed/federation/200706" xmlns:mfg="urn:microsoft:live:federation"> <fed:TargetScopes> <EndpointReference xmlns="http://www.w3.org/2005/08/addressing"> <Address> https://login.microsoftonline.com/extSTS.srf </Address> </EndpointReference> </fed:TargetScopes> <fed:ApplicationServiceEndpoint> <EndpointReference xmlns="http://www.w3.org/2005/08/addressing"> <Address> https://login.microsoftonline.com/extSTS.srf </Address> </EndpointReference> </fed:ApplicationServiceEndpoint> <fed:PassiveRequestorEndpoint> <EndpointReference xmlns="http://www.w3.org/2005/08/addressing"> <Address> https://login.microsoftonline.com/login.srf </Address> </EndpointReference> </fed:PassiveRequestorEndpoint> <mfg:FederationMetadataPutEPR> <EndpointReference xmlns="http://www.w3.org/2005/08/addressing"> <Address> https://ppsanamespace.service.microsoftonline-p.net/pksecure/ProvisionTrustPK.srf </Address> </EndpointReference> </mfg:FederationMetadataPutEPR> </RoleDescriptor>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#"> <SignedInfo> <CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> <Reference URI="#0c0d1ca7-7292-4bc6-801c-f880f6098f4e"> <Transforms> <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/> <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> </Transforms> <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <DigestValue>aQPeWCSJOS22Dk60yhNDG/NCiIo=</DigestValue> </Reference> </SignedInfo> <SignatureValue> TCgu1tc0TAuJay2GEPFHlNbwJtXGX203/oEem0gToHNEE6IxOaXgRFduLNqZw/QMJdHgdXPf558E7+GmhQRRSfEiAyXkxQEoh Q7pvHgujapyo2iSTBgLIT7hme3nxADHvKrlEolKBIh3aBnTz0Eqn1FUB68qvNH7UFuBqTU0bJ0= </SignatureValue> <KeyInfo> <X509Data> <X509Certificate> MIICWzCCAcSgAwIBAgIJANswIPW/+LJFMA0GCSqGSIb3DQEBBQUAMCkxJzAlBgNVBAMTHkxpdmUgSUQgU1RTIFNpZ25pbm cgUHVibGljIEtleTAeFw0xMDA3MTYyMTI0NTZaFw0xNTA3MTUyMTI0NTZaMCkxJzAlBgNVBAMTHkxpdmUgSUQgU1RTIFNp Z25pbmcgUHVibGljIEtleTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAlM7mGMQ6Ha0JP8odYF4ArNF294zQzoRoR7 PSv88tyHD/6wINeVn/ebD+XVI9ebRmRFdJYRFrdqOrYwJOPmq9bG+zF2HblKX718BcAKw7Ku6iqkk0YwtCM1hijr9FlyBG IS9XoE+Yy/qs+WNJyaUnXIw0YMwvoj0ev0KOtd6X7ekCAwEAAaOBijCBhzAdBgNVHQ4EFgQUv0DdCHPD3pifWehnZfE6eC ztZj8wWQYDVR0jBFIwUIAUv0DdCHPD3pifWehnZfE6eCztZj+hLaQrMCkxJzAlBgNVBAMTHkxpdmUgSUQgU1RTIFNpZ25p bmcgUHVibGljIEtleYIJANswIPW/+LJFMAsGA1UdDwQEAwIBxjANBgkqhkiG9w0BAQUFAAOBgQBPFFgHrWNtMRHsbjb/YU j67a7YvVnht11yH73oWLDdS/WW4VYHB3RiZuxU07EtIFXkyjRQ2lmHuza9+IljVKirLw8Zp6CH6tTiZC8WiyRI8cgenztP LO7x1Rwbg5d4bKkVP0dX7pe/Z6hrouK9Xc8828mjL09OlyiH6L+tZc0hJw== </X509Certificate> </X509Data> </KeyInfo> </Signature></EntityDescriptor>
2 番目の RoleDescriptor 要素は、私たちが関心を持っている Office 365 サインイン サービスの証明書利用者の役割に対応しています。
56 AD FS 2.0 での Microsoft Office 365 シングル サインオン (SSO)
この要素では、組織の社内用インフラストラクチャとのやり取りを行うために、Office 365 サインイン サービス用の 2 つのエンドポイントが定義されています。
1. Web クライアント (ブラウザー) 用のパッシブ エンドポイント: https://login.microsoftonline.com/login.srf.
2. スマート クライアント用のアクティブ エンドポイント: https://login.microsoftonline.com/extSTS.srf.
5.1.4.2 変換の発行規則
信頼の自動定義では、変換の発行規則セット内に 2 つのカスタム規則が作成されます。
この 2 つの規則は以下のように定義されます。
1. 「Active Directory: UPN & ImmutableID」 カスタム規則: ユーザーのログオン名に基づいて Active Directory のクエリが実行されると、この規則によって以下の情報が取得されます。
UPN 要求: プロビジョニングされたユーザーの値に関連付けられたユーザーの UPN。
ImmutableID 要求: ユーザーのプロビジョニングのために関連付けられたユーザーの ID。この ID は、名前変更可能な一意の ID です。
この規則では、以下のように、発行された SAML 1.1 ログオン トークン内にある属性ステートメント要素の UPN および ImmutableID 属性要素のソースを特定できます。
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"]=> issue(store = "Active Directory", types = ("http://schemas.xmlsoap.org/claims/UPN", "http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID"), query = "samAccountName={0};userPrincipalName,objectGUID;{1}", param = regexreplace(c.Value, "(?<domain>[^\\]+)\\(?<user>.+)", "${user}"), param = c.Value);
2. 「ImmutableID から NameID」 カスタム規則 : 名前が示しているとおり、この規則では、ImmutableID 要求が SourceID 要求に変換されます。
この規則では、以下のように、発行された SAML 1.1 ログオン トークン内にある属性ステートメント要素の件名要素のソースを特定できます。
AD FS 2.0 での Microsoft Office 365 シングル サインオン (SSO) 57
c:[Type == "http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID"]=> issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", Value = c.Value, Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"] = "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified");
結果的に、SAML 1.1 ログオン トークンは以下のようになります。 この XML ベースの著名済みトークンは、いわゆる 「ベアラー」 トークンです。これは、存続期間の短い (つまり、所有証明のない) ベアラー トークンであり、AD FS 2.0 フェデレーション サービスによって Office 365 サインイン サービスに対して発行されます。
このようなトークンには、属性ステートメントと認証ステートメントが含まれます。
属性ステートメント: このステートメントは、NameID (ImmutableID) によってここで識別されている件名が特定の要求 (この例では UPN および ImmutableID) に関連付けられていることを表明します。 要求は、文字列名と値のペアで提供されます。
認証ステートメント: このステートメントは、AD FS 2.0 フェデレーション サービスが次の特定の認証方法を使用してセキュリティ プリンシパル (つまり、件名) を特定の時間に認証し た こ と を 表 明 し ま す 。 AuthenticationMethod=「urn:oasis:names:tc:SAML:1.0:am:password」;
SAML 1.1 トークンの一般的な構文とセマンティクスは、 OASIS SAML 標準「Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V 1.1 ( 英語 ) 92」のコア仕様で定義されています。
<saml:Assertion MajorVersion="1" MinorVersion="1" AssertionID="_55b4b481-da5e-49fa-a8f2-af3198cbd1b3" Issuer="http://sts.idmgt.demo/adfs/services/trust"
IssueInstant="2012-02-14T15:53:38.976Z" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"> <saml:Conditions NotBefore="2012-02-14T15:53:38.960Z" NotOnOrAfter="2012-02-14T16:53:38.960Z"> <saml:AudienceRestrictionCondition> <saml:Audience>urn:federation:MicrosoftOnline</saml:Audience> </saml:AudienceRestrictionCondition> </saml:Conditions> <saml:AttributeStatement> <saml:Subject> <saml:NameIdentifier Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"> jQs1n5IS0EKf4byoSsOr6A== </saml:NameIdentifier> <saml:SubjectConfirmation> <saml:ConfirmationMethod>urn:oasis:names:tc:SAML:1.0:cm:bearer</saml:ConfirmationMethod> </saml:SubjectConfirmation> </saml:Subject> <saml:Attribute AttributeName="UPN" AttributeNamespace="http://schemas.xmlsoap.org/claims"> <saml:AttributeValue>[email protected]</saml:AttributeValue> </saml:Attribute> <saml:Attribute AttributeName="ImmutableID" AttributeNamespace="http://schemas.microsoft.com/LiveID/Federation/2008/05"> <saml:AttributeValue>jQs1n5IS0EKf4byoSsOr6A==</saml:AttributeValue> </saml:Attribute>
</saml:AttributeStatement> <saml:AuthenticationStatement AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:password" AuthenticationInstant="2012-02-14T15:53:38.929Z"> <saml:Subject> <saml:NameIdentifier Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"> jQs1n5IS0EKf4byoSsOr6A== </saml:NameIdentifier> <saml:SubjectConfirmation> <saml:ConfirmationMethod>urn:oasis:names:tc:SAML:1.0:cm:bearer</saml:ConfirmationMethod>
92 Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V1.1: http://www.oasis-open.org/committees/download.php/3406/oasis-sstc-saml-core-1.1.pdf
58 AD FS 2.0 での Microsoft Office 365 シングル サインオン (SSO)
</saml:SubjectConfirmation> </saml:Subject> </saml:AuthenticationStatement> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:SignedInfo> <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /> <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" /> <ds:Reference URI="#_55b4b481-da5e-49fa-a8f2-af3198cbd1b3"> <ds:Transforms> <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /> </ds:Transforms> <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" /> <ds:DigestValue>hKJnVjG/rq/bdy1RrnztTIiBE6c=</ds:DigestValue> </ds:Reference> </ds:SignedInfo> <ds:SignatureValue> tT4kMFkVL+l2D6fcD9QhDW+HN+rktCq7lZ9WMsPV+3ONoSq+KH/4qMrO0XncZySYlxMlhLbl7ZAJP5t0eErFbEBfH8+J3PPrsaRU+ mXQe7lfIj1ir1l+hCpbC3Hywnirm01sLaj8NUHnM3/B0KDWblOzpPkOXKvM4Rd4SVsNiKykwp2Em3f80hZWLu2mQRJxiti2n6NcOt Md4YhOV0fNhH5LHzc0SWNUiIALqtrc7b67YaOFMM21oxQBRffxnY4ns5kRU/aTKCTTwZzamBoRdCI97j0CjT8XTv+LfLHkcWaBH+5 up0Xd+g3T8jTikGQpMDzuvbOtIlY69DUnCIz0DQ== </ds:SignatureValue> <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#"> <X509Data> <X509Certificate> MIIC8DCCAdigAwIBAgIQF1RifzXrH59A+2Jtoe+5ADANBgkqhkiG9w0BAQsFADA0MTIwMAYDVQQDEylBREZTIFNpZ25pbmcgL SBhZGZzLmRlbW8uaWRtZ3QuYXJjaGltcy5mcjAeFw0xMTA4MTAxOTIyNTZaFw0xMjA4MDkxOTIyNTZaMDQxMjAwBgNVBAMTKU FERlMgU2lnbmluZyAtIGFkZnMuZGVtby5pZG1ndC5hcmNoaW1zLmZyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQE AwNpcxWSMJ3TbXfHEAAa4Moi7+S+k6JypSPq45FHAkyn3QkGzRsjJt9KF05/PvUsudukl+OZxXUHsb1pWMQniZAh5G7h6rUXf k1eeJhDHgBFpwI5yrLGdUlcGrQxNNE4UCLuDwRWG9WjA6Gr7q3bD68vFom/OitsyK18RRB4kCkFWHTln98b7EDieFQQPDxoRP o+Od6eQ/sejR6D7zJKW9LByT8H8BBOrm4CD9vpBoHiVxIgciLrARx0oCiayh/oYihZDWI8HYv1TlVd9uh+Rxsax7Qt0dWA/Me 06gOO5THo2YmxVA4wG3sdyl74MjgmPSv2qR6mP4GAGxk4sfK59iQIDAQABMA0GCSqGSIb3DQEBCwUAA4IBAQAxr2UPF+6osSL mF0bdn+Ysj98Q69c6LVLBmTcnd9VBqoefBtcvQe/rp34f2Ok3nqLVRgQv+aWfQrCwM5/5e93saZpdY2UH/U8cvSb+X2PqBK9y CPDejAtfjo3sCv0ET+0UkoQirK4/CTn07tg+37teZ1EVHaO3DHiI695llnW7Z7j/LH7TLaIP2l9WY2Fe5D+B0iZlYE9kCTDUq hVR4037cTKC7RKyl/hBPc1xRtQE0ya0lhb4THZjID4fHv9KYQOGaiUHnETt+Qc12pYnZW66O7KXj1Ap47IStGvWiOMbJ6jm4Y oGyZRa7MC5Gh2z3AQGZ2Rj1KPW3OQ/T3u3u84k </X509Certificate> </X509Data> </KeyInfo> </ds:Signature></saml:Assertion>
注 意 す る 必 要 が あ る の は 、 上 の ト ー ク ン 内 に あ る 発 行 元 の URI ( 例 : http://sts.idmgt.demo/adfs/services/trust) を使用して Office 365 サインイン サービス内の名前空間が特定されていることです。
5.1.4.3 承認の発行規則
信頼の自動定義では、承認の発行規則セット内に 「すべてのユーザーに対するアクセスを許可」 規則が作成されます。
すべてのユーザーを承認するこの規則は以下のように定義されます。
=> issue(Type = "http://schemas.microsoft.com/authorization/claims/permit", Value = "true");
AD FS 2.0 での Microsoft Office 365 シングル サインオン (SSO) 59
5.1.5 エンドポイント
AD FS 2.0 エンドポイントを使用して、フェデレーション ソリューション /アプリケーションへのアクセスをクライアントに提供します。 クライアント認証が正常に終了した後、エンドポイントはクライアントに SAML 認証トークンを発行します。 このエンドポイントを AD FS 2.0 フェデレーション サービスのフェデレーション サーバー (ファーム) 上で管理します。また、(負荷分散された) AD FS 2.0 フェデレーション サーバー プロキシでこのエンドポイントを個々に管理したり、セキュリティで保護したり、公開したりできます (「2.4.4.1 AD FS 2.0 フェデレーション サーバー プロキシ」を参照)。
AD FS 2.0 フェデレーション サーバー プロキシは、AD FS 2.0 の展開モードです。これは、AD FS 2.0 の展開を目的として特別に設計されており、内部でホストされる AD FS 2.0 サービスへのリモート アクセスを提供します。
通常の展開 (「4.2.1.1 シナリオ 1 - AD FS 2.0 の完全実装」を参照) では、フェデレーション サーバー プロキシは、境界ネットワークでホストされ、データをポート 443 経由で FS (ファーム) に渡します。FS は、必要な SAML セキュリティ トークンを発行します。
AD FS 2.0 フェデレーション サーバー プロキシは、AD FS 2.0 証明書利用者にアクセスするためのトークン要求に応答できます。 注意する必要があるのは、フェデレーション サーバー プロキシは 、AD FS 2.0 サービスのプロキシのみに制限されているため、汎用のリバース プロキシ (Microsoft Forefront Threat Management Gateway (TMG) など) を使用することなく、企業ファイアウォールの内側でホストされる証明書利用者へのアクセスを有効にすることはできないということです。
このホワイトペーパーの特定のコンテキストでは Exchange Online で AD FS 2.0 フェデレーション サーバー プロキシが必要とされます。また、前述のように、企業の内部ネットワークの外側から SharePoint 2010 Online および Lync Online にアクセスできるようにするには、AD FS 2.0 フェデレーション サーバー プロキシが必要です。 さらに、企業ネットワークの内側の AD FD 2.0 フェデレーション サービスおよび AD FS 2.0 フェデレーション サーバー プロキシを可用性の高い方法で実装する必要があります。このインフラストラクチャの機能が停止すると、フェデレーション サービスにアクセスできなくなるためです。
60 AD FS 2.0 での Microsoft Office 365 シングル サインオン (SSO)
図 7AD FS 2.0 エンドポイント
Office 365 オンライン サービスにアクセスするには、3 つの異なるエンドポイントを検討する必要があります。
1. パッシブ フェデレーション (WS-Federation のパッシブなプロファイル) のエンドポイント: Microsoft Online ポータル (MOP)、SharePoint Online ポータル、Outlook Web App (OWA) の各サービスにアクセスするときに、Web クライアントはこのエンドポイントを使用します。
Web クライアント (ブラウザー) は、このエンドポイントを使用して AD FS 2.0 フェデレーション サービスとの認証を直接的に行います。
認証中のブラウザーベースの操作への移行のため、SharePoint Online ドキュメント ライブラリからドキュメントを開くときは、このエンドポイントが Office 2007 Service Pack 2 (SP2) または Office 2010 (Word、Excel、または PowerPoint) にも適用されます。 クライアントは、SharePoint Online からの応答を効果的に使用して、ブラウザーに似たダイアログ ウィンドウを表示します。ダイアログ ウィンドウは、リダイレクト スキームに依存する、フェデレーション関連の Web プロトコル (この特定のコンテキストでは WS-Federation) をサポートします。
このエンドポイントに関連する認証フローについては、「5.2 パッシブ/WEB プロファイル認証のフローについて」を参照してください。
2. アクティブ フェデレーション (WS-Trust のアクティブなプロファイル) のエンドポイント: このエンドポイントは、AD FS 2.0 をサポートするリッチ クライアントによって使用されます。具体的には、このホワイトペーパーでは、Lync 2010 および Office サブスクリプション クライアントによって使用されます。
上記の 2 つのクライアントは、このエンドポイントを使用して、AD FS 2.0 サービスと直接ネゴシエートして認証を行います。 関連する認証フローの詳細については、「5.3 MEX/リッチ クライアント プロファイル認証のフローについて」を参照してください。
AD FS 2.0 での Microsoft Office 365 シングル サインオン (SSO) 61
3. EAS 基本認証/アクティブなプロファイルのエンドポイント: このエンドポイントは、サービスを使用してユーザーに代わって認証を行うすべてのクライアントに適用されます。したがって、認証には基本認証が使用されます (資格情報が基本認証に渡されます)。
Office 365 に 関 す る 限 り 、 こ のエン ド ポ イ ン ト は 、通常、 Microsoft Exchange 2010 ActiveSync (EAS)、Outlook 2007 と 2010、 IMAP、POP と SMTP、Exchange 2010 Web サービスによって使用されます。
クライ アント は基本認証の資格情報を SSL 経由で Exchange Online に送信しま す 。Exchange Online は、このエンドポイントを使用し、クライアントに代わってこの認証要求を AD FS 2.0 フェデレーション サービスに転送します。 関連する認証フローの詳細については、「5.4 EAS 基本認証/アクティブ プロファイル認証のフローについて」を参照してください。
クライアント アクセスを制限する目的で、これらの 3 つのエンドポイントをフェデレーション サーバー プロキシ レベルで制御/フィルター処理できます (採用された実装シナリオに従っている場合は、「4.2.1 OFFICE 365 用の AD FS 2.0 実装シナリオ」を参照)。 また、2011 年 10 月から、AD FS 2.0 発行規則によるフィルター処理もサポートされるようになりました (「6.3 クライアントの場所に基づいて OFFICE 365 サービスへのアクセスを制限する」を参照)。
Get-MsolFederationProperty コマンドレットを使用して、現在の AD FS 2.0 エンドポイントの情報を確認できます。
現在の設定を表示するには、次のように処理します。
1. Windows PowerShell を Microsoft Online Services に接続します (「4.3.2 MICROSOFT ONLINE
SERVICES への WINDOWS POWERSHELL の接続」を参照)。
2. コマンド Get-MsolFederationProperty –DomainName <ドメイン名> を実行します。 上のコマンドからの出力を以下に示します。 この情報は非常に有益であり、これを使用して、シングル サインオン構成に問題がないかどうかを簡単に確認できます。
PS C:\Windows\system32> Get-MSOLFederationProperty -DomainName demo.idmgt.archims.fr
Source : ADFS ServerActiveClientSignInUrl : https://adfs.demo.idmgt.archims.fr/adfs/services/trust/2005/usernamemixedFederationServiceDisplayName : ADFS IDMGT MTC ParisFederationServiceIdentifier : http://sts.idmgt.demo/adfs/services/trust
FederationMetadataUrl : https://adfs.demo.idmgt.archims.fr/adfs/services/trust/mexPassiveClientSignInUrl : PassiveClientSignOutUrl : [Issuer] CN=ADFS Signing - adfs.demo.idmgt.archims.fr [Serial Number] 1754627F35EB1F9F40FB626DA1EFB900 [Not Before] 10/08/2011 21:22:56 [Not After] 09/08/2012 21:22:56 [Thumbprint] 25A70E3841C2614B097587EBDB9BBF0AE00D818CNextTokenSigningCertificate :Source : Microsoft Office 365ActiveClientSignInUrl : https://adfs.demo.idmgt.archims.fr/adfs/services/trust/2005/usernamemixedFederationServiceDisplayName : ADFS IDMGT MTC ParisFederationServiceIdentifier : FederationMetadataUrl : PassiveClientSignInUrl : [Issuer] CN=ADFS Signing - adfs.demo.idmgt.archims.fr [Serial Number] 1754627F35EB1F9F40FB626DA1EFB900 [Not Before] 10/08/2011 21:22:56
62 AD FS 2.0 での Microsoft Office 365 シングル サインオン (SSO)
[Not After] 09/08/2012 21:22:56 [Thumbprint] 25A70E3841C2614B097587EBDB9BBF0AE00D818CNextTokenSigningCertificate :
これは、AD FS 2.0 フェデレーション サービスのエンドポイントの情報を示しています。
パッシブ フェデレーション (WS-Federation のパッシブなプロファイル) のエンドポイントは、PassiveClientSignInUrl エントリに対応する adfs/ls/ エンドポイントです。
アクティブ フェデレーション (WS-Trust のアクティブなプロファイル) のエンドポイントは、FederationMetadataUrl エントリに対応する /adfs/services/trust/mex/ エンドポイントです。
EAS 基本認証/アクティブ プロファイルのエンドポイントは、ActiveClientSignInUrl エントリに対応する /adfs/services/trust/2005/usernamemixed エンドポイントです。
何らかの理由でクライアントが誤ったエンドポイントに達した場合にこのコマンドを実行すると、原因の特定に役立つ可能性があります。
トラブルシューティングの観点で、また次のセクションで詳しく説明されているように、あらゆる Office 365 シングル サインオン通信の認証フローは予測できます。 予測される認証フロー パターンを、問題のあるシングル サインオンを試みているときに取得した実際の認証フローと比較または対比して、プロセスの何が間違っているかを判断できます。
「Microsoft Online Services Diagnostics and Logging (MOSDAL) サポート ツールキット 4.0 93」の AD FS 認証診断部分でこのような取得と比較を実行し、以下のように、Office 365 のパッシブ/アクティブ フェデレーション認証の問題をトラブルシューティングできます。
マシンが企業ネットワーク上にあるかどうか、またはインターネット上にあるかどうかを検出します
Office 365 の登録を確認します
MEX/フェデレーション メタデータを AD FS 2.0 フェデレーション サービスから取得できることを確認します
AD FS 2.0 で発行されたログオン トークンを使用して、Office 365 へのアクティブ/パッシブ ログインを実行します
MOSDAL を実行してパッシブ/アクティブ シングル サインオンをテストするには、次のように処理します。
1. .msi パッケージを Microsoft ダウンロード センターからダウンロードしてインストールします。
2. MOSDAL サポート ツールキットを起動します。
93 Microsoft Online Services Diagnostics and Logging (MOSDAL) サポート ツールキット 4.0: http://www.microsoft.com/ja-jp/download/details.aspx?id=626
AD FS 2.0 での Microsoft Office 365 シングル サインオン (SSO) 63
3. [O365] タブで、[シングル サインオン (ID フェデレーション)] を選択し、[次へ] をクリックします。
4. 使用する資格情報を入力し、[次へ] をクリックします。
5. [次へ] をクリックし、診断の実行を開始します。
64 AD FS 2.0 での Microsoft Office 365 シングル サインオン (SSO)
同様に、Microsoft Remote Connectivity Analyzer (RCA)94を使用して、Office 365 のパッシブ シングル サインオンの問題を診断できます。
RCA を実行してシングル サインオンをテストするには、次のように処理します。
1. Web ブラウザーを開いて、https://testexchangeconnectivity.com に移動します。
2. [Office 365] タブをクリックします。
94 Microsoft リモート接続アナライザー (RCA): https://www.testexchangeconnectivity.com/
AD FS 2.0 での Microsoft Office 365 シングル サインオン (SSO) 65
3. [Microsoft シングル サインオン] を選択し、[次へ] をクリックします。
66 AD FS 2.0 での Microsoft Office 365 シングル サインオン (SSO)
4. 社内用の企業 UPN とパスワードを入力し、セキュリティに関する確認事項のチェック ボックスをオンにして、確認コードを入力します。次に、[テストの実行] をクリックします。
問題がある場合は、「AD FS 2.0 Troubleshooting Guide ( 英語 ) 95」を共に使用して問題を解決できます。
5.2 パッシブ/Web プロファイル認証のフローについて
以下のスキーマでは、ユーザーは企業ネットワークに接続された、ドメインに参加している作業コンピューターのブラウザーから、SharePoint Online や Outlook Web App (OWA) に似た Web ベースの Office 365 サービスにアクセスします。
Office 365 への認証を行う場合、インターネット ブラウザーは組織の AD FS 2.0 フェデレーション サービスへの接続を確立して、SAML 1.1 ログオン トークンを要求します。
統合 Windows 認証 (Kerberos または NTLMv2) を使用して、AD FS フェデレーション サービスへの認証が実行されます。ユーザーの操作は必要ありません。また、ユーザーの確認が要求されることもありません。 ログオン トークンが Office 365 サインイン サービスに提示され、Office 365 サービスへのアクセスが許可されます。
95 AD FS 2.0 Troubleshooting Guide: http://technet.microsoft.com/en-us/library/adfs2-troubleshooting-guide(WS.10).aspx
AD FS 2.0 での Microsoft Office 365 シングル サインオン (SSO) 67
図 8 パッシブ/Web プロファイル認証のフロー
パッシブ プロファイル認証のフローは以下のとおりです。
1. ユーザーが Web ベースの Office 365 サービスにアクセスします。 サービスは、Office 365 サインイン サービスによって署名された認証トークンが必要であることをクライアントに伝えて、リダイレクトされた HTTP 302 経由で Office 365 ID プラットフォームのサインイン サービス URL を返し、そこからチケットを取りに行きます。
2. クライアントは Office 365 サインイン サービスに移動し、認証トークンを求めます。 サインイン サービスは、ユーザーが入力した UPN を取得し、それがフェデレーション ドメインかどうかを確認します。 次に、サインイン サービスは、ユーザーをサインインできないこと、およびユーザーの社内用の要求プロバイダー (つまり、社内の AD FS 2.0 フェデレーション サービス) によって署名されたログオン トークンが必要であることを伝えます。 したがって、サインイン サービスは、AD FS 2.0 フェデレーション サービスのパッシブ フェデレーション エンドポイントの URL (adfs/ls/) を、リダイレクトされた HTTP 302 経由で返します。
3. クライアントは、AD FS 2.0 フェデレーション サービスに移動し、ログオン トークンを要求します。 AD FS 2.0 フェデレーション サービスは、ユーザーに社内の Active Directory に対する認証 (この構成では既定で統合 Windows 認証を使用する) を行うように要求し、認証が成功すると、社内の Active Directory を照会してユーザー要求を取得します。次に、ログインしたユーザーに関する要求、つまり UPN とソース ID (ImmutableID) が含まれる SAML 1.1 トークンを発行し、現在宣言されている X.509 トークン署名証明書を使用して SAML 1.1 トークンを署名します。
4. クライアントは、この署名された SAML 1.1 ログオン トークンを HTTP POST 経由で Office 365 サインイン サービスに提示します。 サインイン サービスは、フェデレーション ドメイン用の信頼された要求プロバイダーが、X.509 署名証明書の公開キーを使用して、入力方向のトークンを確かに署名していることを確認します。この X.509 署名証明書は、エクスポートされたメタデータによって信頼の確立中に共有されたものです。 次に、サインイン サービスは、Office 365 ID プラットフォームからソース ID を内部的な一意の ID (一意 ID) に変換
68 AD FS 2.0 での Microsoft Office 365 シングル サインオン (SSO)
し、UPN と一意 ID が含まれる新しいトークンを発行して署名します。 これにより、認証トークンが形成されます。
5. 認証トークンはクライアントに戻され、クライアントはその認証トークンを Web ベースの Office 365 証明書利用者サービスに提示します。 証明書利用者サービスはトークンを開き、そのトークンが、共有公開キーに基づいて、信頼された要求プロバイダー (つまり、Office 365 ID プラットフォーム) によって署名されていることを確認します。 証明書利用者サービスは、一意 ID 要求を確認し、その一意 ID を使用してディレクトリ内のユーザーを検索します (一意 ID は、ユーザーのプロビジョニング/作成の一環として設定され、サービスと同期されます)。 ユーザーが見つかると、証明書利用者サービスは、ユーザーに Web ベースの目的の Office 365 サービスへのアクセスを許可する前に、必要なアクセス制御チェックを適用できます。
このプロセスは非常に複雑に思えますが、このプロセスを分解すると、このプロセスが実際にどのように機能しているかを把握できます。 ここで問題があった場合は、問題を容易に判別できます。少なくともトラブルシューティングを開始できます。
詳細については、記事「Office 365 におけるシングル サインオンの仕組み 96」を参照してください。 プロトコルの観点からの詳細については、OASIS WS-Federation (WS-Fed) ( 英語 ) 仕様の第 13 章「Web (Passive) Requestors」97を参照してください。 フローを取得する必要がある場合は、ネットワーク トレース アプリケーションまたは Fiddler ツール (および「Fiddler Inspector for Federation Messages ( 英語 ) 98」) を使用できます。 後者については、記事「AD FS 2.0: How to Use Fiddler Web Debugger to Analyze a WS-Federation Passive Sign-In ( 英語 ) 99」を参照してください。
96 Office 365 におけるシングル サインオンの仕組み: http://community.office365.com/ja-jp/wikis/sso/1002.aspx97 Web Services Federation Language (WS-Federation) Version 1.2 : http://docs.oasis-open.org/wsfed/federation/v1.2/ws-federation.pdf98 Fiddler Inspector for Federation Messages: http://social.technet.microsoft.com/wiki/contents/articles/fiddler-inspector-for-federation-messages.aspx99 AD FS 2.0: How to Use Fiddler Web Debugger to Analyze a WS-Federation Passive Sign-In: http://social.technet.microsoft.com/wiki/contents/articles/3286.aspx
AD FS 2.0 での Microsoft Office 365 シングル サインオン (SSO) 69
5.3 MEX/リッチ クライアント プロファイル認証のフローについて
図 9 MEX/リッチ クライアント プロファイル認証のフロー
上のスキーマでは、ドメインに参加している作業コンピューターからユーザーが Lync Online へのアクセスを試みます。 アクティブ プロファイル認証のフローは以下のとおりです。
1. 企業ネットワーク上でドメインに参加している作業コンピューターにユーザーがログオンします。 ログオンが成功すると、クライアントの MSOIDSVC サービス、つまり、Microsoft Online Services サインイン アシスタント (MOS SIA) サービス (「3.1.2 会社用コンピューターの要件 を参照) が始動し、ログオンしたユーザーの UPN のドメイン サフィックスを調べてそのユーザーの Active Directory ドメインを取得します。 MSOIDSVC サービスは、Office 365 ID プラットフォームのサインイン サービス上でホーム領域検出 (HRD) サービスを呼び出します。
サインイン サービスは、そのドメインが、登録されたフェデレーション ドメインかどうかを確認します。 そうでない場合、サインイン サービスは何も返しません。登録されたフェデレーション ドメインの場合、サインイン サービスは、登録されたフェデレーション サーバー、つまり組織の社内用 AD FS 2.0 フェデレーション サービスのメタデータ交換エンドポイント (MEX エンドポイント) の URL を返します。
2. 何も返されない場合、MSOIDSVC サービスは終了します。 MEX エンドポイントの URL が返された場合、MSOIDSVC サービスはフェデレーション サービスの MEX エンドポイント (/adfs/services/trust/mex/) にアクセスします。この MEX エンドポイントは、フェデレーション サービスによって公開される WS-Trust エンドポイントのリストを返します。
3. MSOIDSVC サービスは、SAML 1.1 ログオン トークンを要求するために最も適した認証エンドポイントの種類 (統合 Windows 認証用 (Kerberos または NTLMv2)) を選択します。 次に、MSOIDSVC サービスは、選択された認証エンドポイントにアクセスし、Kerberos または
70 AD FS 2.0 での Microsoft Office 365 シングル サインオン (SSO)
NTLMv2 を使用して認証を行います。 認証が完了すると、フェデレーション サービスは、ログオンしたユーザーの NTLMv2 トークンまたは Kerberos チケットを取得し、社内の Active Directory を照会してユーザー要求を取得します。その後、ログインしたユーザーに関する要求、つまり UPN とソース ID (ImmutableID) が含まれる SAML 1.1 ログオン トークンを発行し、現在宣言されている X.509 トークン署名証明書を使用して SAML 1.1 ログオン トークンに署名します。 ログオン トークンは MSOIDSVC サービスに返されます。
4. ここで、MSOIDSVC サービスは、AD FS 2.0 フェデレーション サービスから受け取った SAML 1.1 ログオン トークンを提供し、Office 365 サインイン サービスに認証トークンを要求します。
Office 365 サインイン サービスは、受信したログオン トークンを確認し、Office 365 ID プラットフォームからソース ID を内部的な一意の ID (一意 ID) に変換し、新しい認証トークン (UPN と一意 ID 要求を含む) を発行します。この新しい認証トークンはクライアントに送り返されます。 これで、この認証トークンをログインで使用できます。 このすべての処理はログオン時に透過的に実行されるため、ユーザーに表示されません。
現在、MSOIDSVC サービスは、このトークンを、クライアント アプリケーションですぐに使用できるようにキャッシュに入れています。
5. ユーザーは、ここで Lync 2010 を起動します。 Lync 2010 は Lync Online への接続を試み、Lync Online は認証トークンを要求します。
6. Lync 2010 (MSOIDCLI.dll へのインプロセス呼び出し経由 ) は、MSOIDSVC からの認証チケットを要求します。 MSOIDSVC サービスは認証チケットを既に取得しており、それを Lync Online に送信します。 Lync Online はトークンを処理し、必要なアクセス制御チェックを適用してから、ユーザーにサービスへのアクセスを許可します。
5.4 EAS 基本認証/アクティブ プロファイル認証のフローについて
下のスキーマでは、ドメインに参加している作業コンピューターからユーザーが Outlook を開きます。 Exchange Online に対して認証を行う場合、Outlook は、Office 365 に対する基本認証資格情報を暗号化形式で使用します。 Office 365 プラットフォームは、組織の AD FS 2.0 フェデレーション サービスへの接続を確立し、SAML ログオン トークンを要求して、ユーザーに Office 365 サービスへのアクセスを許可します。
AD FS 2.0 での Microsoft Office 365 シングル サインオン (SSO) 71
図 10EAS 基本認証/アクティブ プロファイル認証のフロー
Exchange ActiveSync (EAS) 基本認証/アクティブ プロファイル認証のフローは以下のとおりです。
1. 企業ネットワーク上でドメインに参加している作業コンピューターにユーザーがログオンします (MSOIDSVC サービスはラウンド トリップを行って SAML 1.1 認証トークンを取得し、キャッシュに入れます)。 ユーザーは、ここで Outlook 2010 を起動します。
Outlook は、Exchange Online への接続 (Negotiate を使用する統合 Windows 認証および SSPI 層経由) を試みますが、Exchange Online は基本認証のチャレンジを行います。
2. ユーザーに 1 回目のプロンプトが表示されます。ユーザーは社内用の資格情報 (UPN 形式のユーザー名およびパスワード) を入力する必要があります。 ユーザーはその資格情報を保存できます。保存すると、パスワードが変更されるまでプロンプトは表示されません。 これは Outlook によって Exchange Online に送信されます。
3. Exchange Online は、「プロキシ認証」 と呼ばれる処理を行います。この処理では、ユーザーのシャドウ表現が作成されます。 次に、基本認証からドメイン /UPN を取得し、それを Office 365 サインイン サービスに送信します。
Office 365 ID プラットフォームは、組織の社内用 AD FS 2.0 フェデレーション サービスのアクティブ プロファイル エンドポイントの URL (/adfs/services/trust/2005/usernamemixed) を返します。
4. Exchange Online は、基本認証の資格情報を取得し、それをフェデレーション サービスのアクティブ プロファイル エンドポイントに送信します。
フェデレーション サービスは、社内の Active Directory に対する基本資格情報を使用してユーザーを認証し、社内の Active Directory を照会してユーザー要求を取得します。次に、SAML 1.1 ログオン トークン (ユーザーに関する UPN 要求とソース ID (ImmutableID) 要求が含まれる) を発行し、現在宣言されている X.509 トークン署名証明書を使用して SAML 1.1 ログオン トークンに署名します。 このログオン トークンは Exchange Online に戻ります。
72 AD FS 2.0 での Microsoft Office 365 シングル サインオン (SSO)
5. Exchange Online は、これを Office 365 サインイン サービスに送信します。 サインイン サービスは、ログオン トークンを確認して認証トークンに変換します。認証トークンには、Office 365 ID プラットフォームからの UPN と内部的な一意の ID (一意 ID) が含まれます。 これで、この認証トークンをログインで使用できます。
これで、Exchange Online は認証トークンを使用してユーザーを認証できるようになり、ユーザーのシャドウ表現を削除します。
顧客の資格情報は上記の一連の認証レグのどの場所にも保持されないこと、および顧客の資格情報は Microsoft データセンターに保管またはキャッシュされないことに注意する必要があります。
また、以下で説明しているように、新しい Outlook セッションごとに資格情報の入力を求めるプロンプトの表示を回避するために、ユーザーは Outlook のパスワード プロンプトで [パスワードを保存する] オプションを選択し、自分の資格情報を Windows Credential Manager にキャッシュするように選択できます。
Windows Credential Manager は、ユーザーの資格情報を保管するための安全な領域 (資格情報コンテナー) を提供し、リモート サービスへのアクセスを容易にします。 保管されたパスワードを複数のレベルで保護できます。
ドメインに参加しているコンピューターの場合、Credential Manager のコンテンツにアクセスするには、ユーザー パスワードが認識されている必要があります。
ハード ディスクの盗難に関する懸念は、Windows 7 の BitLocker など、ディスク暗号化テクノロジの展開によって軽減できます。
自宅用のワークステーションや管理されていない他のクライアントでは、パスワードをローカルにキャッシュした場合、リスクが増大する場合があります。 顧客は、クライアント アクセス ポリシー (「6.3.2 クライアント アクセス ポリシーの使用」を参照) を実装することで、顧客のネットワークの外側から顧客の Office 365 サービスに接続されることを防止できます。これにより、管理されていないクライアントで従業員が社内用のパスワードをキャッシュすることに関するリスクを軽減できます。
AD FS 2.0 での Microsoft Office 365 シングル サインオン (SSO) 73
6 注意事項
このセクションでは、シングル サインオンに関して注意する必要がある情報について説明します。 記事「Configuring Advanced Options for AD FS 2.0 ( 英語 ) 100」を参照することもできます。
6.1 複数のトップ レベル ドメインのサポート
AD FS 2.0 の更新プログラムのロールアップ 1 が最初に公開されるまで、AD FS 2.0 によるシングル サインオン機能を利用する組織は、組織内のユーザーの UPN サフィックスに対して複数のトップ レベル ドメイン (例: @idmgt.fr、@idmgt.co.uk) を保持している場合、サフィックスごとに AD FS 2.0 フェデレーション サービスの別々のインスタンスを展開する必要がありました。
更新プログラムのロールアップ 2 (または以前の更新プログラムのロールアップ 1) をすべての AD FS 2.0 フェデレーション サーバーにインストールし、この機能を Office 365 で使用するための指示に従うと、新しい要求規則が設定され、ユーザーの UPN サフィックスに基づいてトークン発行元 ID が動的に生成されるようになります。
結果として、Office 365 内の複数のトップ レベル ドメイン (サブドメインなし) でシングル サインオンがサポートされるように AD FS 2.0 フェデレーション サービスの複数のインスタンスをセットアップする必要がなくなります。 このためには、Windows PowerShell 用 Microsoft Online Services モジュールと共に新しいスイッチ SupportMultipleDomain を使用する必要があります。
重要なメモ:
1 つのトップ レベル ドメインと複数のサブドメインを使用する場合、このスイッチは必要ありません。 たとえば、UPN サフィックスで使用するドメインが @legal.idmgt.fr、@paris.idmgt.fr、および @idmgt.fr であり、トップ レベル ドメイン (この場合は idmgt.fr) が最初に追加され、そのドメインに対してフェデレーションが行われた場合、SupportMultipleDomain スイッチを使用する必要はありません。 これは、これらのサブドメインは親の範囲内で効果的に管理され、1 つの AD FS 2.0 フェデレーション サービスを使用してこれを処理できるためです。
複数のトップ レベル ドメイン (@idmgt.fr および @ idmgt.co.uk) があり、これらのドメインにサブドメイン (@paris.idmgt.fr および @london.idmgt.co.uk) も含まれる場合、サブドメインに対して SupportMultipleDomain スイッチは機能しないため、これらのユーザーはログインできなくなります。 この問題は、Office 365 サインイン サービス内の名前空間を特定するのに、AD FS 2.0 フェデレーション サービスによって発行されたログオン トークン内の発行元 URI が使用されるという事実に関連します。
1 つの対処方法として、次のように、 Office 365 ID プラットフォームの証明書利用者の信頼 (「5.1.4.2 変換の発行規則」を参照) の 「変換の発行規則」 で正規表現を構成し、発行元 URI のドメイン名を切り捨てることができます。
c:[Type == "http://schemas.xmlsoap.org/claims/UPN"] => issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid", Value = regexreplace(c.Value, ".+@(?<domain>.+)", "http://${domain}/adfs/services/trust/"));
100 Configuring Advanced Options for AD FS 2.0: http://technet.microsoft.com/en-us/library/hh237448(WS.10).aspx
74 AD FS 2.0 での Microsoft Office 365 シングル サインオン (SSO)
追加の情報については、記事「 複数のトップ レベル ドメインのサポート 101」を参照してください。
6.2 Office 365 向けの強力な認証 (2FA) のサポート
AD FS 2.0 フェデレーション サービス (通常は AD FS 2.0 フェデレーション サーバー ファーム (「4.2.1.1 シナリオ 1 - AD FS 2.0 の完全実装」を参照)) は、企業ネットワークの内側に配置されており、既定で統合 Windows 認証 (IWA) を使用して内部ネットワーク上の社内ユーザーを認証します。
ただし、社内ユーザーが自宅、空港、インターネットカフェなど、リモートの場所にいるときに、クラウド内に存在する Office 365 のサービスのような通常のリソースにアクセスしなければならないことが一般的になりつつあります。
このホワイト ペーパーで説明されているシングル サインオン機能のメリットを得るには、このようなユーザーが AD FS 2.0 フェデレーション サービスにアクセスし、認証トークンを要求して、利用可能なサービスに必要に応じてアクセスできるようにする必要があります。
このような状況に対処するには、また結果的にユーザーが AD FS 2.0 フェデレーション サービスにリモート アクセスできるようにするには、組織はそのような状況で AD FS 2.0 フェデレーション サーバー プロキシ経由でネットワーク境界をアクセス制御境界として活用します。 AD FS 2.0 フェデレーション サーバー プロキシは、この目的のために特別に設計された AD FS 2.0 の展開モードであり、内部でホストされる AD FS 2.0 フェデレーション サービスへのアクセスを提供するとともに、結果的に、Office 365 内の必要なサービスへのプロキシ アクセスを可能にします。
メモ:
「2.4.4.2 代替プロキシ」で説明されているように、代替のプロキシを使用して、企業ネットワークの外側から AD FS 2.0 フェデレーション サービスを公開できます。 このセクションの以降の部分で、AD FS 2.0 フェデレーション サーバー プロキシについて重点的に説明します。
これは、組織の (社内の) インフラストラクチャ内で管理されており、特に注意を必要とするものではありません。
このようなリモート アクセスを許可する組織は、一般的に、入力方向のアクセスを保護するための強力な認証技法を検討します。 攻撃者は入力方向のアクセス ポイントに容易に到達できます。また、フェデレーション サーバー ファームへの認証が成功すると、さまざまな証明書利用者のセキュリティ トークンへのアクセスが攻撃者に許可される可能性があります。したがって、リモート認証のセキュリティを確保することが重要になります。
強力な認証または 2 要素認証 (2FA) は、セキュリティを向上します。これらの認証では、ユーザーが 2 つの認証基準を満たす必要があるためです。たとえば、「知っているもの」 (ユーザー名/パスワード) と 「持っているもの」 (トークンまたは証明書) を組み合わせます。
Office 365 では、組織のネットワークの外側にある Web クライアントに対して強力な認証を有効にできます。
Web ブラウザー以外のクライアントで 2FA はサポートされません。 Outlook 2010、Lync 2010、ActiveSync、およびその他のリッチ クライアントには、強力な認証の資格情報の入力をユーザーに要求する機能がありません。したがって、これらのクライアントをサポートできません。
101 複数のトップ レベル ドメインのサポート: http://community.office365.com/ja-jp/wikis/sso/1007.aspx
AD FS 2.0 での Microsoft Office 365 シングル サインオン (SSO) 75
ただし、認証中のブラウザー ベースの操作への移行のため、このルールにいくつかの例外があります。 実際には、Office 2007 Service Pack 2 (SP2) または Office 2010 クライアント (Word、Excel、または PowerPoint) が SharePoint Online ドキュメント ライブラリへのアクセスを試みると、クライアントは SharePoint Online からの応答を使用してブラウザーに似たダイアログ ウィンドウを表示します。このダイアログ ウィンドウは、リダイレクト スキームに依存する、フェデレーション関連の Web プロトコル (WS-Federation) をサポートします。
このシナリオでは、「パッシブ フェデレーション」 エンドポイントに対して 2FA を要求するようにフェデレーション サーバー プロキシを構成することで強力な認証が実現します (「5.2 パッシブ/WEB プロファイル認証のフローについて」を参照)。
重要なメモ:
強力な認証は、「パッシブ フェデレーション」 エンドポイントに対してのみ適用する必要があります。そうでない場合、他のクライアントが接続できなくなります。
これは、組織の (社内の) インフラストラクチャ内で管理されており、Office 365 Online サービスに対して特定の構成を行う必要はありません。 この目的のために、組織は独自の 2FA インフラストラクチャ (ある場合) を展開する必要があります。
企業ネットワークの外側にある上記の Office 365 Web アプリケーションにアクセスするユーザーに対する 2FA 認証とシングル サインオンの適用は、組織によってプロキシ レベルで実装されます。 これは、Office 2007 Service Pack 2 (SP2) または Office 2010 クライアント (Word、Excel、または PowerPoint) にも適用されます。 ただし、既に述べたとおり、Office 365 の他のリッチ クライアント アプリケーション (Outlook、Lync など) は現在サポートされていません。
AD FS 2.0 フェデレーション サーバー プロキシについては、使用する (サード パーティの) 2FA ソリューション プロバイダーでサポートされる機能に応じて、以下のサインイン方法を使用して 2FA 資格情報の収集と処理を行うことができます。
AD FS 2.0 を使用するスマートカード ベースのサインイン
サード パーティの 2FA ソリューション プロバイダーの IIS HTTP モジュールを使用するフォームベースの サインイン
カスタマイズされた AD FS 2.0 ログイン ページを使用して 2FA ソリューション プロバイダーとやり取りするフォームベースのサインイン
フェデレーション サーバー プロキシ (または AD FS 2.0 フェデレーション サーバー) をインストールすると、パッシブ フェデレーション要求を処理するためのサインイン ページと呼ばれる ASP.NET Web アプリケーションが同じサーバーに展開されます。
サインイン ページ Web アプリケーションは、インターネット インフォメーション サービス (IIS) 内で実行されます。関連するページは %SystemRoot%\Inetpub\adfs\ls に配置され、IIS の既定の Web サイトの /adfs/ls 仮想ディレクトリの下に展開されます。
サインイン ページは、特に WS-Federation プロトコルを処理し、機能拡張ポイントを公開します。機能拡張ポイントでは、さまざまなカスタマイズを行うことができます。特にフォームベース認証 (FBA) の動作をカスタマイズできます。
76 AD FS 2.0 での Microsoft Office 365 シングル サインオン (SSO)
メモ:
AD FS 2.0 サインイン ページのカスタマイズに関する詳細情報については、AD FS 2.0 SDK ドキュメント内の「AD FS 2.0 Sign-In Pages Customization Overview ( 英語 ) 102」を参照してください。
6.2.1 AD FS 2.0 を使用するスマートカード ベースのサインイン
この方法には、スマートカード ベース認証の組み込みサポートが備えられています。 スマートカードを使用すると、AD FS 2.0 フェデレーション サービスは強力な認証の要求を下流のアプリケーションおよびサービスに提示できます。下流のアプリケーションおよびサービスは、認証の強度に基づいてさらなる認証を実行できます。
6.2.2 サード パーティの 2FA ソリューション プロバイダーの IIS HTTP モジュールを使用するフォームベースの サインイン
この方法は、Windows Server 2008 または Windows Server 2008 R2 で使用されるインターネット インフォメーション サービス (IIS) バージョンと互換性がある IIS HTTP モジュールをサード パーティの 2FA ソリューションがサポートしていること、および組織内にある各 AD FS 2.0 フェデレーション サーバー プロキシにサード パーティの 2FA ソリューションがインストールされていることを前提とします。 このモジュールがプロキシにインストールされて構成されると、基本的に、このモジュールは、プロキシの URL を宛先とするすべてのトラフィックを途中で取り込みます。
この方法ではフォームベースのカスタマイズが少なくて済みます。また、通常はセットアップも容易です。しかし、エンドユーザーの操作については、最適ではありません。以下の 2FA 認証プロセス手順で説明されているように、複数のリダイレクトが発生することに加えて、資格情報を要求する少なくとも 2 つの異なるプロンプトが表示されるためです。
1. 途中で取り込んだトラフィックを通過させる前に、このモジュールはブラウザーを 2FA ソリューションにリダイレクトします。ここで、ユーザーは 2FA の資格情報を入力します2FA の資格情報は 2FA サービスによって検証されます。
2. 2FA ソリューションに対する認証が成功すると、モジュールは、ブラウザーをフェデレーション サーバー プロキシのログイン ページに戻してトラフィックを通過させ、トラフィックが AD FS 2.0 フェデレーション サーバー プロキシによって処理されるようにします。
3. ユーザーが Office 365 Web アプリケーションに対して認証されるには、ユーザーはこのページ上で社内用の Active Directory 資格情報を入力する必要があります。
RSA Authentication Agent 7.0 for Web for IIS および RSA SECURID トークンを使用するこの方法の詳細については、記事「AD FS 2.0 Step-by-Step Guide: Integration with RSA SecurID in the Extranet ( 英語 ) 103」を参照してください104。
このメソッドは、少ないカスタマイズで済ますことができ、セットアップも容易です。 この方法の欠点はエンド ユーザー操作にあります。ユーザーは複数のリダイレクトを通過し、資格情報を 2 つの場所で収集されます。
102 AD FS 2.0 Sign-In Pages Customization Overview: http://msdn.microsoft.com/en-us/library/ee895356.aspx103 AD FS 2.0 Step-by-Step Guide: Integration with RSA SecurID in the Extranet: http://technet.microsoft.com/en-us/library/hh344805(WS.10).aspx104 RSA Authentication Agent 7.0 for Web for IIS: http://www.rsa.com/node.aspx?id=3663
AD FS 2.0 での Microsoft Office 365 シングル サインオン (SSO) 77
6.2.3 カスタマイズされた AD FS 2.0 ログイン ページを使用するフォームベースのサインイン
この方法は、フェデレーション サーバー プロキシのカスタマイズされたフォームベースのログイン ページの背後で実行されるコードから呼び出すことができるインターフェイスをサード パーティの 2FA ソリューション プロバイダーがサポートしていることを前提とします。 通常、カスタマイズされたフォームベースのログイン ページには、認証用の特別な要素を入力するための、ユーザー用の特別なフィールドや、それらの要素をシームレスに収集するための特別なロジックが導入されています。
たとえば、Login People の Digital DNA Technology を使用できます。その結果、ユーザーは 「知っているもの」 (パスワード) と 「持っているもの」 (コンピューター、スマートフォン、USB キーなど) に基づく強力な認証を使用できるようになります。これにより、 2 番目の認証要素が作成され、ID とプライバシーの両方を保護すると同時に AD FS 2.0 の相互運用性のすべての可能性を実現する高レベルのセキュリティに到達します。 サード パーティの 2FA ソリューション プロバイダーとの統合の詳細については、ホワイト ペーパー「Integrating Login People Digital DNA Server with AD FS 2.0 for interoperable federated Single Sign-On ( 英語 ) 105」を参照してください。
この方法では、前述の方法よりもユーザー エクスペリエンスが最適化されています (2FA および Active Directory の両方の資格情報に対して、フォームベースの 1 つのログイン ページのみが使用される)。ただし、セットアップのための管理作業が増大します。組織内のフェデレーション サーバー プロキシごとにフォームベースのログイン ページをカスタマイズして 2FA の資格情報と社内の Active Directory の資格情報の両方を収集できるようにする必要があるためです。
6.3 クライアントの場所に基づいて Office 365 サービスへのアクセスを制限する
インターネットに公開する Office 365 内のサービスを制御し、その結果、外部アクセス シナリオのいくつかをブロックしなければならない場合があります。
6.3.1 AD FS 2.0 エンドポイントの使用
AD FS 2.0 エンドポイントの公開によって、サービスへのクライアント アクセスを制御できます (「5.1.5 エンドポイント」を参照)。
たとえば、パッシブ フェデレーション エンドポイントを公開しないことで、組織は、企業ネットワークの外側から Web クライアントがサービスに接続することを禁止できます。
重要なメモ:
前述のとおり、基本認証クライアントの接続を許可するには (Outlook 2010 を含む)、どのような場合であっても AD FS 2.0 フェデレーション サーバー プロキシを展開する必要があります。 フェデレーション サーバー プロキシを利用できない場合、Outlook 2010 クライアントは、内部の企業ネットワークからであっても認証できません。
105 Integrating Login People Digital DNA Server with AD FS 2.0 for interoperable federated Single Sign-On: http://download.microsoft.com/documents/France/Interop/2011/Integrating-LoginPeople-DDNA-Server.docx
78 AD FS 2.0 での Microsoft Office 365 シングル サインオン (SSO)
6.3.2 クライアント アクセス ポリシーの使用
2011 年 10 月から Office 365 でサポートされるようになったクライアント アクセス ポリシーは、AD FS 2.0 用更新プログラムのロールアップ 2 (または以前の AD FS 2.0 用更新プログラムのロールアップ 1) を必要とします。このクライアント アクセス ポリシーは、Office 365 のサービスを対象とするものであり、以下の 3 つの部分で構成されるソリューションによって提供されます。
1. 接続元のクライアントに関する情報を提供する認証要求属性を使用します。 AD FS 2.0 フェデレーション サーバー プロキシは、要求コンテキストの 5 つの新しい HTTP ヘッダーを AD FS 2.0 フェデレーション サービスに渡します。
a. x-ms-forwarded-client-ip;
b. x-ms-client-application;
c. x-ms-client-user-agent;
d. x-ms-proxy;
e. x-ms-endpoint-absolute-path.
重要なメモ:
ファイアウォールに公開する AD FS 2.0 の実装シナリオ (「4.2.1.2」を参照) に従ってサード パーティのプロキシを使用する場合、HTTP ヘッダー x-ms-proxy を送信するようにプロキシを構成する必要があります。また、プロキシ ホストの完全修飾 DNS 名の値を含める必要があります。
2. この追加の要求コンテキスト情報を使用するために、クライアント アクセス ポリシーでは、一連の新しい要求コンテキストの要求の種類が導入されています。
a. http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip
b. http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application
c. http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-user-agent
d. http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy
e. http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path
これに基づいて、要求コンテキストの新しい要求の種類ごとにカスタマイズした 「変換の承諾規則」 を Active Directory 要求プロバイダー信頼 (「5.1.3 社内の ACTIVE DIRECTORY 要求プロバイダーの信頼」を参照) に追加し、ポリシー エンジンで新しい要求の種類を使用できるようにする必要があります。
たとえば、要求コンテキストの要求の種類 http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip に対して、以下のパススルー要求規則を作成する必要があります。
c:[Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip"] => issue(claim = c);
また、これに似た追加のパススルー要求規則を、残りの 4 つの要求の種類ごとに作成する必要があります。
3. これで、AD FS 2.0 は要求パイプライン内の新しい要求コンテキストの要求を使用できます。具体的には、AD FS 2.0 は、Office 365 ID プラットフォームの証明書利用者の信頼 (「5.1.4.3
AD FS 2.0 での Microsoft Office 365 シングル サインオン (SSO) 79
承認の発行規則」を参照) の 「承認の発行規則」 セットに定義された関連するカスタム規則を使用し、新しい要求コンテキストの要求に基づいて処理を行うことができます。
AD FS 2.0 フェデレーション サービスは、記事「クライアントの場所に基づいた Office 365 サービ スに対するアクセスの制限106」で説明されているように、アクセスを要求したユーザー、ユーザーのデバイスの IP アドレス、およびアクセス方法の組み合わせに基づいてアクセスを許可または拒否するためのアクセス ポリシーをサポートできます。
このソリューションでは以下のシナリオを実現できます。
Office 365 へのすべての外部アクセスをブロックする : 内部の企業ネットワーク上のクライアントからのすべての Office 365 アクセスは許可されますが、外部クライアントからの要求は、外部クライアントの IP アドレスに基づいて拒否されます。
Exchange ActiveSync (EAS) を除いて、Office 365 へのすべての外部アクセスをブロックする: 内部の企業ネットワーク上のすべてのクライアントからの Office 365 アクセスに加えて、EAS を使用するあらゆる外部クライアント デバイス (スマート フォンなど) からの Office 365 アクセスが許可されます。 他のすべての外部クライアントは拒否されます。
SharePoint Online、Outlook Web App (OWA) など、ブラウザーベースのアプリケーションを除いて、Office 365 へのすべての外部アクセスをブロックする: Office 365 の Web ベースのサービスを除いて、Office 365 への外部アクセスが拒否されます。
指定した Active Directory グループに対して、Office 365 へのすべての外部アクセスをブロックする: このシナリオは、クライアント アクセス ポリシーの展開をテストおよび検証する目的で使用されます。 1 つ以上の Active Directory グループのメンバーに対してのみ、Office 365 への外部アクセスをブロックします。 このシナリオを使用してグループのメンバーのみに外部アクセスを提供することもできます。
クライアント アクセス ポリシー ビルダー ツール ( 英語 ) 107は、このようなカスタム AD FS 2.0 クライアント アクセス ポリシーの構成を容易かつ効率的にすることを目的とします。
ツールを使用してカスタムの AD FS 2.0 クライアント アクセス ポリシーを構成するには、次のように処理します。
1. ツ ー ル を オ ン ラ イ ン ギャラ リ ー か らダウ ン ロ ー ド し 、 フ ァ イ ル Office_365_-_Client_Access_Policy_Builder.ps1 をデスクトップに保存します。
2. 新しく作成したファイル Office_365_-_Client_Access_Policy_Builder.ps1 を右クリックして [プロパティ] をクリックします。次に、[全般] タブで [ブロックの解除] をクリックし、[OK] をクリックします。
106 クライアントの場所に基づいた OFFICE 365 サービスに対するアクセスの制限: http://community.office365.com/ja-jp/wikis/sso/927.aspx
107 クライアント アクセス ポリシー ビルダー ツール: http://gallery.technet.microsoft.com/scriptcenter/Client-Access-Policy-30be8ae2
80 AD FS 2.0 での Microsoft Office 365 シングル サインオン (SSO)
3. Office_365_-_Client_Access_Policy_Builder.ps1 を右クリックし、[PowerShell で実行] をクリックします。
4. [Create Rules for Claim Types] をクリックし、Active Directory 要求プロバイダー信頼に対して 5 つのパススルー要求規則を作成します。
既存のクライアント アクセス ポリシーのパススルー規則の存在が検出された場合、ツールは何も処理しません。そのパススルー規則がインターフェイスに反映されます。
AD FS 2.0 での Microsoft Office 365 シングル サインオン (SSO) 81
5. [Office 365 - Client Access Policy Builder] の [Step 1] が完了すると、インターフェイスの [Step 2] 部分のロックが解除されます。
6. ラジオ ボタン リストから目的のクライアント アクセス ポリシー シナリオを選択します。
7. [Single external IP address] の横に、自分の環境の外部 IP アドレスを入力します。 外部 IP アドレスの範囲を使用する場合、[External IP address range] を選択することで、[Office 365 - Client Access Policy Builder] ツールに範囲を指定できます。
8. 目的のシナリオを選択し、有効な外部 IP アドレスを入力すると、[Build] ボタンをクリックして Office 365 ID プラットフォームの証明書利用者の信頼に対する要求規則を生成します。
6.4 Office 365 のスマート リンクを使用する
Office のスマート リンクは、フェデレーション ID を使用して Office 365 へのアクセスのワークロードを軽減します。 スマート リンクは、次の Web パッシブ ワークロードを操作する書式設定済みのリンクです。Microsoft Online ポータル (MOP)、Outlook Web Access (OWA)、および SharePoint Online (SPO)。
書式設定済みのリンクを使用する理由は、フェデレーション ユーザーのサインイン プロセスを簡素化するためです。 ユーザーが Office 365 ワークロードに対して認証を行う場合、既定の動作として、ユーザーは自分の UPN を login.microsoftonline.com プロンプトに入力し、ホーム領域検出 (HRD) プロセスを起動する必要があります。その後、ユーザーは社内の AD FS 2.0 フェデレーション サービスにリダイレクトされます (4.4 シングル サインオンの確認 を参照)。
ドメインに参加している社内の作業コンピューターからの完全に透過的なシングル サインオン操作が望まれる場合、ホーム領域検出プロンプトをバイパスするようにカスタマイズしたスマート リンクを展開して使用できます。
使用する Office 365 サービスに応じてスマート リンクを適切にカスタマイズする方法については、記事「Office 365 でのスマート リンクの使用 108」を参照してください。
108 Office 365 でのスマート リンクの使用: http://community.office365.com/ja-jp/wikis/sso/851.aspx
82 AD FS 2.0 での Microsoft Office 365 シングル サインオン (SSO)
Microsoft Online ポータル (MOP) にサインインするには、以下のスマート リンクを使用できます。
https:// adfs.demo.idmgt.archims.fr /adfs/ls/?wa=wsignin1.0&wtrealm=urn:federation:MicrosoftOnline ( 英語 )
または
https://login.microsoftonline.com/login.srf?wa=wsignin1.0&whr= demo.idmgt.archims.fr &wreply=https: %2f%2fportal.microsoftonline.com%2fdefault.aspx
Outlook Web Access (OWA) にサインインするには、以下のスマート リンクを使用できます。
https://outlook.com/owa/[email protected]
または
https://login.microsoftonline.com/login.srf?wa=wsignin1.0&whr= demo.idmgt.archims.fr &wreply=https: %2f%2foutlook.com%2fowa%2f o365a40demo%2eidmgt%2earchims%2efr %2f?exsvurl=1&ll-cc=en-US
SharePoint Online (SPO) にサインインするには、以下のスマート リンクを使用できます。
https://login.microsoftonline.com/login.srf?wa=wsignin1.0&whr= demo.idmgt.archims.fr &wreply=https: %2f%2f idmgt %2esharepoint%2ecom%2f%5fforms%2fdefault%2easpx
ユーザー独自の構成に応じて、上記のスマート リンクの黄色で囲まれた部分を、AD FS 2.0 フェデレーション サービスのパッシブ フェデレーションのパブリック エンドポイント、フェデレーション ドメイン、またはユーザーの UPN の適切な値で置き換えます。
クエリ文字列パラメーターの詳細については、OASIS WS-Federation (WS-Fed) ( 英語 ) 109 仕様の第 13 章「Web (Passive) Requestors」を参照してください。
109 Web Services Federation Language (WS-Federation) Version 1.2 : http://docs.oasis-open.org/wsfed/federation/v1.2/ws-federation.pdf
AD FS 2.0 での Microsoft Office 365 シングル サインオン (SSO) 83
