対象: 新Office365 Office 365 Enterprise, Office 365 Midsize Business
(この記事は 2014 年 5 月 13 日に Office Blogs に投稿された記事 Choosing a sign-in model for Office 365の翻訳です。最新情報については、翻訳元の記事をご参照ください。)
今回は、Office 365 チームで ID 管理を担当するテクニカル プロダクト マネージャー Paul Andrew の記事をご紹介します。
Office 365 で、3 つの ID モデルのうちどれがお客様に適しているかについて、質問をいただくことがよくあります。これらのモデルのうちどれを選ぶかによって、Office 365 でのユーザー アカウントの管理方法やサインイン時のパスワードの検証方法が異なります。今回の記事では、各モデルの説明、各モデル間での移行方法、およびニーズに合わせて最適なモデルを選択する方法について取り上げます。
![]()
Office 365 の 3 つの ID モデル
上図は 3 つの ID モデルを示したもので、右にいくほど実装が複雑になります。Office 365 の実装をスムーズに行うためには、最初はお客様のニーズを満たす ID モデルのうちで最も簡単なものを採用して、Office 365 をすぐに使用できるようにすることをお勧めします。その後、業務の要件が詳細に決定してから、より機能性の高い ID モデルに徐々に移行することも可能です。最も簡単に実装できるのがクラウド ID モデル、最も機能性が高いのがフェデレーション ID モデル、最も多くのお客様に適していると思われるのが同期 ID モデルと考えてください。それでは、各モデルについてもう少し詳しく説明します。
![]()
クラウド ID:このモデルでは、ユーザーの作成と管理は Office 365 で行われ、Azure Active Directory に保存されます。また、パスワードの検証も Azure Active Directory で実行されます。Azure Active Directory は、Office 365 で使用されるクラウド ディレクトリです。同一ユーザー アカウントはオンプレミスには存在せず、Office 365 管理センターでユーザーを作成する以外は、必要な構成はありません。
![]()
同期 ID:このモデルでは、ユーザー ID はオンプレミスのサーバーで管理され、アカウントとパスワード ハッシュがクラウドに同期されます。ユーザーは、オンプレミスとクラウドで同じパスワードを入力します。サインイン時のパスワードの検証は、Azure Active Directory が実行します。このモデルでは、Microsoft Azure Active Directory 同期ツール (DirSync) を使用します。
![]()
フェデレーション ID:このモデルの要件は同期 ID と同じですが、オンプレミスの ID プロバイダーでユーザー パスワードの検証を行うという点が異なります。つまり、パスワード ハッシュを Azure Active Directory に同期する必要はありません。このモデルでは、Active Directory フェデレーション サービス (AD FS) またはサードパーティの ID プロバイダーを使用します。
各モデル間で切り替えが可能
マイクロソフトでは、お客様のニーズを満たす ID モデルのうち、最も簡単なものを使用することを推奨します。変更が必要になったら、これらのモデルの間で簡単に切り替えることが可能です。ここからは、お客様がご利用可能な各モデル間の切り替えについて説明します。
クラウド ID から同期 ID:この切り替えの手順は、DirSync ツールの展開作業の一部に含まれています。この手順を実施する前に、クラウドでユーザーを作成しておく必要があります。クラウド ID モデルから同期 ID モデルに移行するとき、DirSync と Azure Active Directory が既存の全ユーザーを照合します。このユーザー照合処理は、場合によって 2 とおりの方法で実行されます。1 つめは、クラウドのユーザーが事前に Active Directory のソースから同期されている場合の処理方法です。このケースでは、各ユーザーが一意の ImmutableId 属性を所有していて、同期再開時には同一の値となるはずです。このため、同一の ImmutableId 属性を持つユーザーが照合されます。これは「完全一致」と呼ばれます。
2 つめは、クラウドのユーザーに ImmutableId 属性が設定されていない場合の処理方法です。このケースでは、同一の電子メール属性を持つユーザーを検出する「あいまい一致」が試行されます。電子メール アドレスでの照合により複数のユーザーが検出されると、同期エラーが発生します。あいまい一致機能でユーザーの照合を確実に行うには、Office 365 とオンプレミスの Active Directory で同一のプライマリ SMTP アドレスを使用する必要があります。すべてのユーザーがクラウドに含まれているにもかかわらず Active Directory に含まれていないユーザーが存在する場合には、PowerShell を使用して該当ユーザーを抽出してから Active Directory にインポートすると、あいまい一致を実行できるようになります。
同期 ID からフェデレーション ID:同期 ID はフェデレーション ID を使用するための前提条件であるため、フェデレーション ID プロバイダーを展開するときには、必然的にこの切り替えを行うことになります。ユーザー ID は、同期 ID とフェデレーション ID で同じものを使用します。このため、フェデレーション サービスをオンプレミスで実装し、Office 365 管理センターでフェデレーションを有効にするだけで、同期 ID モデルからフェデレーション ID モデルへの切り替えが完了します。同期 ID からフェデレーション ID への切り替えはドメイン単位で実施できます。この操作では、ユーザー資格情報の検証 (通常はパスワードを使用) を行う ID プロバイダーを定義し、Azure Active Directory とオンプレミスの ID プロバイダーとの間でフェデレーションの信頼を構築します。フェデレーション ID に切り替えるときにパスワード ハッシュ同期を無効化することもできますが、有効にしておくと、バックアップとして使用できるので便利です。これについては次の段落で説明します。
![]()
フェデレーション ID から同期 ID: PowerShell で Convert-MsolDomainToStandard コマンドを使用すると、1 つのドメインをフェデレーション ID モデルから同期 ID モデルに切り替えることができます。DirSync のパスワード同期オプションが最近追加されたため、この機能を活用してインフラストラクチャを簡素化するために、同期 ID モデルに切り替えるお客様もいらっしゃることと思います。また、フェデレーション ID プロバイダーで、物理サーバーや電源などに障害が発生したり、お客様とのインターネット接続が不通になったりすると、ユーザーがサインインできなくなります。同期 ID モデルに切り替えておけば、このような障害がフェデレーション ID プロバイダーで発生した場合に、有用なバックアップとなります。
フェデレーション ID から同期 ID へ戻すための所要時間はユーザー数によって異なり、ドメインのユーザー 2,000 人あたり 1 時間として、それに 2 時間を足した時間を要します。同期 ID への切り替えが完了すると、該当するユーザーのクラウド パスワードが使用されるようになります。先日、マイクロソフトは、フェデレーション ID 用に構成されているドメインでもパスワード ハッシュ同期機能を使用できるようになった (英語) ことを発表しました。従来、Azure Active Directory は、フェデレーション構成のドメインではパスワード ハッシュ同期を無視していました。しかし、先日の変更によりフェデレーション構成のドメインでもパスワード ハッシュ同期が引き続き使用できるようになったため、フェデレーション ID から同期 ID に切り替えるとパスワード検証が即座に有効になります。バックアップとしてパスワード同期を構成していない場合にフェデレーション ID から同期 ID に切り替えるときは、この構成を行い、PowerShell で set-MsolUserPassword コマンドを実行してパスワードを割り当てるか、ランダム パスワードを使用します。
同期 ID からクラウド ID: Office 365 管理センターで操作するか、PowerShell で Set-MsolDirSyncEnabled コマンドを実行すると、ディレクトリ同期を完全に無効化してクラウド管理型の ID に移行できます。Office 365 テナントでこの更新を実行するには、約 72 時間を要します。このとき、PowerShell で Get-MsolCompanyInformation コマンドを実行して DirectorySynchronizationEnabled 属性の値を見ると、進捗状況が確認できます。詳細については、サポート技術情報の記事をお読みください。
クラウド ID モデルが適している場合
クラウド管理型の ID では、オンプレミスでの ID 構成が不要で、最も簡単に ID モデルを実装できます。Office 365 管理センターでユーザーを入力、管理する以外に、必要な作業はありません。他にオンプレミスのユーザー ディレクトリを所有しない場合は、これが最適な方法です。私は最大で 200 人のユーザーを抱える企業で使用されているケースを見たことがあります。
また、長期間にわたるディレクトリ再構築プロジェクトが進行中である、ディレクトリのガバナンスが複雑であるなどの理由で、オンプレミスのディレクトリが非���に複雑なため統合作業を回避したい場合にも、クラウド ID が適しています。既にオンプレミスのディレクトリを所有していて、Office 365 の試用版やパイロット版を使用する場合にも、オンプレミスのディレクトリに接続する際にユーザーを照合できるため、クラウド ID モデルが適しています。
既にオンプレミスのディレクトリを所有している企業にとっては、オンプレミスと Office 365 の両方でユーザー ディレクトリの保守を行うのではなく、ディレクトリをクラウドに同期する方が一般的です。このとき、パスワード同期またはフェデレーション ID でのサインインを採用した方が、オンプレミスのみでユーザー管理を行えばよいので適していると考えられます。
以上から、クラウド ID モデルは、オンプレミスのディレクトリを所有していない場合、ユーザー数が非常に少ない場合、オンプレミスのディレクトリが大規模な再構築中である場合、Office 365 の試用版やパイロット版を使用している場合に適していると言えます。
同期 ID モデルが適している場合
同期 ID モデルもまた構成が非常に簡単で、同期元のオンプレミスのディレクトリを所有していれば、DirSync ツールをインストールし、他にオンプレミスのディレクトリでいくつかの整合性チェックを行うだけで済みます。この詳細については、私が最近投稿したブログ記事「既存のディレクトリと Office 365 を簡単に同期」で説明しています。2013 年 6 月までは、このモデルにはパスワード同期機能が含まれておらず、同期 ID でプロビジョニングされたユーザーは Office 365 で使用するクラウド パスワードを作成する必要がありました。これが大きな理由となり、多くのお客様がフェデレーション ID モデルの実装を選択していました。しかし、パスワード同期が使用できるようになったため、同期 ID モデルは、同期元のオンプレミスのディレクトリを所有していて、かつオンプレミスとクラウドで同じパスワードを使用できるようにしたいと希望される多くのお客様にも適した方法になりました。
最も簡単な方法で導入作業を完了した後は、将来的に高度なシナリオでフェデレーションが必要となるかどうかに基づいて、パスワード同期または ID フェデレーションのどちらを使用するかを検討することを推奨します。この高度なシナリオについては、次項で説明します。高度なシナリオを導入する予定がなければ、パスワード同期の使用を推奨します。また、最終的にフェデレーション ID を使用する予定であっても、パイロット版の Office 365 を使用している場合や 何らかの理由で AD FS サーバーを展開する時間を確保できていない場合は、同期 ID モデルの使用を推奨します。
以上から、オンプレミスのディレクトリを既に所有していて、フェデレーション ID モデルを使用したシナリオを導入する予定がない場合は、同期 ID モデルが適しています。
フェデレーション ID モデルが適している場合
前述のとおり、オンプレミスとクラウドで同じパスワードを使用できるようにするためだけにフェデレーション ID を展開している企業が多数あります。しかし、2013 年 7 月にパスワード ハッシュ同期機能が同期 ID モデルに追加されたため、同期 ID モデルよりも複雑でネットワークとサーバーのインフラストラクチャの展開が必要となるフェデレーション ID モデルを選択するお客様は減少しています。
同期 ID モデルで必要となる構成は、すべてフェデレーション ID モデルでも必須です。このため、まずは同期 ID を構成して Office 365 を迅速に導入し、その後フェデレーション ID に移行することを推奨します。
ここからは、フェデレーション ID モデルが適しているシナリオについて説明します。以下のシナリオに該当しないお客様は、よりシンプルな同期 ID モデルとパスワード同期機能を組み合わせて使用することを検討してください。
既存のインフラストラクチャ
シナリオ 1: 既に AD FS を展開済みの場合。何らかの理由で既に AD FS を展開済みの場合、Office 365 でもこれを使用したいと考えるお客様が多いかと思います。この場合、AD FS でフェデレーションされたサインインを使用する複数の SaaS アプリケーションを所有することになります。また、Azure Active Directory は既存のインフラストラクチャに接続して、余計なオーバーヘッドをほぼ発生させることなく、AD FS の保守を行います。もちろん、AD FS の展開は、Office 365 を使用するための要件ではありません。Office 365 ではパスワード ハッシュ同期機能を使用し、その他のワークロードでは引き続き展開済みの AD FS を使用することも可能です。
シナリオ 2: サードパーティのフェデレーション ID プロバイダーを既に使用している場合。マイクロソフトではないサードパーティの ID プロバイダーを認証に使用しているお客様には、フェデレーション ID モデルが最適です。しかし、サードパーティの ID プロバイダーはパスワード ハッシュ同期機能をサポートしていません。そこでマイクロソフトは、サードパーティの ID プロバイダーのテストと認定を行う「Works with Office 365 – Identity」プログラムを実施しています。
シナリオ 3: Forefront Identity Manager 2010 R2 を使用している場合。Forefront Identity Manager 2010 R2 では、Microsoft Azure Active Directory 用の Forefront Identity Manager コネクタを使用して、Azure Active Directory にプロビジョニングする ID のカスタマイズができます。豊富なカスタマイズ オプションが使用できますが、パスワード ハッシュ同期機能はサポートされていません。
技術的要件
シナリオ 4: オンプレミスの Active Directory に複数のフォレストが存在している場合。複数のフォレストが存在する場合、DirSync ツールを使用できません。このため、複数のフォレストを同期させるには、Forefront Identity Manager 2010 R2 で Microsoft Azure Active Directory 用 Forefront Identity Manager コネクタを使用するか、新しい Azure Active Directory 同期サービス (英語)を使用する必要があります。これらの代替用同期ツールのうち、パスワード ハッシュ同期機能をサポートしているものは現時点では存在しません。このため、オンプレミスとオンラインで同じパスワードが自動的に使用されるようにするには、フェデレーション ID モデルを実装する必要があります。こうしたツールを展開する前に、フォレストの統合についても検討してください。単一のフォレストに統合されれば、DirSync ツールを使用できるようになります。フォレスト統合の詳細については、こちらの TechNet 記事を参照してください。
シナリオ 5: オンプレミスと統合されたスマートカードまたは多要素認証 (MFA) ソリューションが既に存在する場合。Azure Active Directory には、サインインのフェデレーション以外に、スマート カードやその他の認証プロバイダーを使用するための拡張メソッドはありません。これらの認証プロバイダーの多くは AD FS の拡張機能を提供していて、Office 365 のサインインでは AD FS プロバイダーによるフェデレーションを通じてこれらの拡張機能を使用できます。Azure Active Directory はネイティブで Office 365 での多要素認証の使用をサポートしているため、代わりにこちらを使用することも可能です。
シナリオ 6: カスタムハイブリッドアプリケーションまたはハイブリッド検索が必要な場合。SharePoint または Exchange でハイブリッド検索を行うアプリケーションや SharePoint のカスタム アプリケーションなどのカスタム ハイブリッド アプリケーションを開発するとき、クラウドとオンプレミスの両方で単一の認証トークンが必要となる場合がよくあります。この場合、シングル サインオン トークンをアプリケーション間のユーザー認証で使用できるようにするという、パスワードの共通化よりも高水準の仕様が求められます。カスタム アプリケーションの開発を進めていて、オンプレミスとクラウドの両方のサービスで同時に認証を行う必要がある場合、ハイブリッド構成が必須となります。
シナリオ 7: パスワードを忘れたときに Web からアクセスしてリセットできるようにする場合。フェデレーション ユーザーに対しては、AD FS で表示されるサインイン ページを制御できます。このサインイン ページを変更して、パスワードを忘れた場合のリセット機能、およびパスワード変更機能を追加することが可能です。この機能は AD FS では提供されていませんが、こちらの TechNet 記事 (英語)に記載されているように、AD FS の実装時に手動で追加できます。ただし、パスワード同期モデルを採用すると、サインイン ページを編集することはできません。代わりに、追加サブスクリプションとして Azure Active Directory プレミアム (英語)をご用意しています。こちらを Office 365 テナントに追加すると、3 種類の ID モデルのいずれにおいても、パスワードを忘れた場合のリセット機能が使用できます。
ポリシーに関する要件
シナリオ 8: サインインの監査および即時無効化、またはそのいずれかが必要な場合。AD FS でフェデレーション ID を実装した場合、各サインイン操作は、オンプレミスでのサインイン操作のログ記録と同様に、標準の Windows イベント ログに記録されます。Active Directory でアカウントを無効化すると、それ以降は同じ Active Directory を使用するフェデレーション サインイン操作がすべて失敗するため、アカウントの無効化は即時実行されます (これは、複数のドメイン コントローラー サーバーにまたがる内部の Active Directory レプリケーション ポリシー、およびキャッシュされたクライアント サインイン トークンに従って実行されます)。このようなレポートはクラウドでは提供されず、パスワード同期対象ユーザーの無効化は 3 時間ごとに実行されるアカウント同期のときにのみ行われるため、パスワード同期機能を使用している場合にはサインインの監査およびアカウントの即時無効化を利用できません。その代わり、アカウントを無効化する前に、無効化処理の一環としてアカウントのパスワード リセットを実行することで、即時無効化が可能です。パスワード変更処理を行うと、その後 2 分以内に Azure Active Directory と同期され、ユーザーの古いパスワードが使用できなくなります。また、手動でディレクトリ同期をトリガーして、アカウント無効化の要求を送信することもできます。
シナリオ 9: シングルサインオンが必要な場合。パスワード同期機能を使用すると、オンプレミスと Office 365 で同じサインイン パスワードを使用できます。一方、シングル サインオン機能を使用すると、Active Directory ドメインに接続されている Windows PC にサインインできると同時に、Office 365 への接続時にパスワー��を再入力する必要がなくなります。この機能を使用するには、ユーザーの PC がサインイン済みであるかどうかを AD FS サーバーに確認するため、フェデレーション ID が必要です。シングル サインオン機能の代わりに、[Save My Password] チェックボックスも使用できます。このチェックボックスをオンにすると、ユーザーのパスワードが Windows Credential Manager (CredMan) に保存され、該当する PC のログイン資格情報によってセキュリティ保護され、ユーザーが PC にサインインしたときに、CredMan によってパスワードのロックが解除されます。Outlook クライアントではシングル サインオンがサポートされていないため、ユーザーが毎回パスワードを入力するか、[Save My Password] をオンにしておく必要があることに注意してください。
シナリオ 10: ネットワークの場所や勤務時間によるクライアントのサインイン制限が必要な場合。サインイン制限は、Active Directory の 2 つの機能によってサポートされます。まず、AD FS に含まれている、クライアント アクセス ポリシー (英語)です。ユーザーが企業ネットワークの外部と内部のどちらにいるか、または指定された Active Directory グループ内にいて企業ネットワークの外部にいるかに応じて、ユーザーのサインインを制限することができます。対象となるユーザーに対して、すべてのアクセスを制限したり、ActiveSync 接続または Web ブラウザーの接続のみを制限したりすることが可能です。もう 1 つ、Active Directory のユーザー ポリシーでログイン制限を設定し、勤務時間によってユーザーのサインインを制限することもできます。フェデレーションでは、パスワードの検証がオンプレミスの Active Directory に委任されるため、Active Directory で設定されているすべてのポリシーが有効になります。
シナリオ 11: Azure Active Directory へのパスワードハッシュ同期をポリシーで禁止する場合。少数ですが、Azure Active Directory へのパスワード ハッシュ同期を禁止するセキュリティ ポリシーを設定するお客様がいらっしゃいます。この場合、オンプレミスとオンラインで同じパスワードを使用できるようにするには、フェデレーション ID モデルを実装するほかありません。マイクロソフトは、お客様のあらゆるデータのセキュリティを確保するために尽力しています。セキュリティ担当者の方は、ぜひ Office 365 セキュリティ センターをご確認ください。また、TechNet 記事「パスワード同期機能の実装 (英語)」でパスワード ハッシュ同期機能のしくみを説明しています。さらに、パスワード ハッシュ同期機能に関する詳細なセキュリティ ガイダンスを TechNet で公開 (英語)しています。
上記に挙げた 11 のシナリオのいずれかに該当する場合は、フェデレーション ID モデルが適しています。
最近の機能強化による状況の変化
最近の機能強化により Office 365 のサインイン機能が改良され、適切なモデルを簡単に選択できるようになりました。この記事では、お客様のニーズに応じてどの ID モデルが適しているかを説明しましたが、これはすべての機能強化を考慮したものです。しかし、すべてのお客様がこれらを把握しているとは限らないので、注意してください。
Office 365 で使用可能な 3 つの ID モデルは、インストール不要の極めて簡単なものから、さまざまな利用シナリオに対応する非常に高機能なものまで、バラエティに富んでいます。お客様のニーズを満たすモデルのうち最もシンプルなものから導入を開始することで、迅速かつ簡単に Office 365 の利用を開始していただけます。その後、ニーズの変化に合わせて ID モデルを切り替えていただくことが可能です。
—Paul Andrew (@pndrw)
![]()
