どこからでも始めるのはいつも難しいです。 よく考えて、Habréに関する最初の記事を、現在取り組んでいるトピックであるOffice 365のすべての形で取り上げることにしました。
このサイトには、このサービスの特定のコンポーネントを説明する記事がすでにいくつかあります。 また、 ADFSを使用した承認の設定 とActive Directoryとの同期についても説明しましたが、実践に加えて、少しの理論は害になりません。 もちろん、すべてを伝えることは不可能であり、面白くありませんが、私の意見では重要な瞬間に注目する価値があります。
私自身の経験から言えば、Office 365での認証はかなり複雑なトピックであり、見かけの単純さと自明性が微妙なニュアンスを隠していることが多く、その知識によりシステムをより適切に展開し、問題を特定するのに必要な時間を短縮できます。 これらは、今日お話ししたいニュアンスです。
Office 365には、Exchange Online、Sharepoint Online、Lync Online、さらにはOffice Pro Plusでユーザーを認証するために使用される3種類の識別子があります。
- Microsoft Online IDは、通常のWindows Azure Active Directoryアカウントです。 これはおなじみのActive Directoryに類似していますが、Microsoftクラウド製品（たとえば、Office 365に加えて、MS Dynamics CRM Onlineにも使用されます）での作業に適合しています。 ユーザーは、管理ポータルを使用して手動で作成するか、CSVファイルを使用して一括で作成します。
- Microsoft Online ID + DirSyncは同じ「クラウド」ユーザーですが、Microsoft Directory Synchronizationユーティリティまたは略してDirSyncを使用して作成されたADのアカウントのコピーです。 ほとんどすべての主要な属性はローカルADから転送されますが、ユーザーパスワードは転送されません。 ユーザー管理の一部はADを介して、一部はポータルで行われます。
- フェデレーションID + DirSync-システムの中心にあるのは、ADからアカウントをコピーするのと同じ原則ですが、唯一の違いは、Active Directoryフェデレーションサービス2.0が承認に使用されることです。 ユーザー管理はローカルADを介して行われます。
識別子タイプの比較
| MicrosoftオンラインID | Microsoft Online ID + DirSync | フェデレーションID + DirSync |
聴衆
| 聴衆
| 聴衆
|
「のために」
| 「のために」
| 「のために」
|
「反対」
| 「反対」
| 「反対」
|
実際には、3番目のオプションが最もよく選択されます。 これにより、ユーザーはアクセス権とパスワードポリシーを完全に制御しながら、アカウントの均一性を実現し、ユーザー管理を可能な限り簡素化できます。
最初の2つのオプションが技術的に非常に明白である場合、ADFSを使用して認証を実装するときに問題が発生します。
認証メカニズムについて説明する前に、現実の状況を説明します。1000人以上のユーザーがADFSを介した認証でOffice 365を使用しました。 あまり美しくない朝、ユーザーは自分のOutlookがメールに接続できなかったが、それでもOutlook Web Access、SharePoint、またはLyncにアクセスできると不平を言い始めました。 失敗の理由はサーバーポリシーの変更であり、その結果、ADFSプロキシサービスがクラッシュしました。 この問題をローカライズするのに数時間を費やしましたが、Office 365での認証に関するいくつかの簡単なことを理解することで節約できました。
そのため、Office 365は認証に2つの主要なメカニズム（プロファイルとも呼ばれます）を使用します。
パッシブメカニズム -ブラウザーまたはシングルサインオンサービスを使用したOffice 365サービスでの承認に使用されます。
このメカニズムの動作原理は、スキームによって説明できます。
- ユーザーは、ブラウザーまたはLyncクライアントを使用して、SharePoint Onlineサービス、Exchange OWA、またはLyncサーバーから情報を要求し、認証プラットフォームで承認を要求する応答を受信します
- 要求を受信した後、認証プラットフォームはフェデレーション識別子が使用されていることを判断し、ローカルActive Directory内のユーザーの有効性を確認するユーザーソースIDを必要とします。これにより、要求がADFSサーバーURLにリダイレクトされます。
- ADFSサーバーは、ローカルADのユーザーを認証し、署名されたユーザーソースIDを発行します。
- 一種の「パスポート」で武装したユーザーは、再び認証プラットフォームに目を向け、今度はそこから「クラウドベースのID」NET IDを受け取ります。
- この証明書はさらにサービスを操作するために使用されます
アクティブメカニズム -Outlookを使用した電子メールサービスでの認証、またはActiveSync、IMAP、POP3プロトコルの使用時に使用されます。
回路は以前のバージョンと非常によく似ています：
この承認メカニズムの動作原理は、1つの重要な詳細を除き、すべての手順を繰り返します。ユーザーは、資格情報を明示的にExchange Onlineサービスに送信します（HTTPSで自然に保護されます）。 Exchange Onlineは、偽装メカニズムを使用して、ADFSサーバーとの通信やユーザーソースIDの取得など、ユーザーに代わってすべての追加手順を実行します。
したがって、注意が必要ないくつかの重要なポイントを特定できます。これらは、DNS、証明書、公開、およびフォールトトレランスです。
DNS
問題が発生した場合、特定のサービスの認証時にユーザーが現在使用しているDNSサーバーを常に覚えておく必要があります。
認証
すべてのユーザーが企業ネットワーク上にあり、ブラウザーとLyncクライアントのみを使用してOffice 365を操作している場合、この項目を忘れて、CAの自己署名証明書を自由に使用できます。 ただし、外部ユーザーがいる場合、または会社のメールを受信するようにお気に入りの電話を構成する場合は、信頼できる証明機関が発行した有効な証明書が必要になります。 ベストプラクティスとして、Office 365に移行する段階であっても、ワイルドカードでない場合はすぐに購入を計画してから、少なくとも1組のSANを持つ通常の購入を計画してください。
耐障害性
実際、どのITシステムでも最も明白なことは最も苦痛なことのようです。 フェデレーション認証をセットアップする場合、ADFSサーバーの復元力を確保することは重要であり、見落とされがちな手順です。 ADFSの信頼性の向上は非常に簡単な作業であり、サードパーティのNLBまたは標準のWindows Load Balancer（WNLNB）を使用することから成ります。 私は明らかなことについて話していることを理解していますが、残念ながら、多くの管理者はフォールトトレランスのトピックに注意を払わず、「1日後に」別のサーバーを配信しようとします。 実際には、詳細に説明しませんが、ADFSバランスの欠如がOffice 365の問題の最も一般的な原因です。
転記
OutlookまたはActiveSyncがOffice 365ユースケースに表示されるとすぐに、ADFSを外部に正しく公開するという疑問が生じます。 これにはいくつかの可能性があります。
- ADFSサーバーを公開することは、管理者が使用していない、最悪で最も安全ではないオプションです。
- ADFSプロキシを展開する-2つの追加サーバーとそれらの間の負荷分散が必要です（再びサードパーティのNLBまたはWNLBを使用）。 利点の中でも、構成と管理の容易さに注目する価値があります。 そこにはほとんど何もありません。
- Forefront TMG / UAGを介した公開は、セットアップと保守が難しくなりますが、より機能的です。 これにより、外部ユーザー向けにADFS機能を拡張し、より複雑なOffice 365承認シナリオを実装できます。管理者によっては、TMGおよびADFSプロキシパブリケーションを使用することができます。
- 外部リバースプロキシ-Citrix NetScalerや単純なトンネルなど、SAML要求/応答を変更しないソリューション/デバイスになります。 リバースプロキシの要件については、 こちらをご覧ください。
Office 365での認証は、非常に長い間書くことができるトピックです。 今日、私は、誤解や間違いを引き起こすことが多い重要なポイントを自分の意見で伝えようとしました。 一部の人にとって、この記事は明らかですが、問題を特定するのに数時間の不快な時間と1キログラムの神経細胞を節約できる人がいることを願っています。