ADFS対Azure AD：MICROSOFTが認証ゲームをどのように変更したか

ADFSによって追加されましたか？ パスワードハッシュ同期に困惑？ パススルー認証によって困惑しましたか？ Azure ADがオンプレミス認証をどのように残しているかを見てみましょう。

マイクロソフトがOffice365を2011年に発売したとき、初期の要件の一つは、ADドメイン内からプラットフォームにアクセスしていた企業ユーザーに何らかの形のシングルサインオンを提供することでした。,

これには、AdfsとオンプレミスADを介して提供されるフェデレーションサービスにAzure ADをリンクしました。

それ以来、クラウドの採用は、現代の組織がユーザーを認証する方法に大きな影響を与えてきました。 オンプレミスの機能への依存は、ヘルプではなく障害になっています。

このように、ますます多くの組織は、レガシー技術の虚飾から自分自身を解放し、不必要な混乱を引き起こすことなく、クラウドを活用する方法を探,

しかし、それは既存のメソッドがその用途を持っていないと言うことではありません、クラウドの究極の利点は、あなたのニーズに最適なメソッドを選択するための柔軟性を持っていることです。

ADFSからAzure AD Connectへ–そしてクラウド認証

最初のクラウド認証オプションは、Azure AD Connectの”パスワードハッシュ同期”機能を利用しており、ユーザーがクラウドで直接認証できるようになっていました。, ただし、これが発生した場合、ユーザーはシングルサインオンできなくなります。

サービスを確実に採用するためにはユーザーエクスペリエンスが重要であるため、パスワードハッシュアプローチに基づくシングルサインオンの提供が大きな そのため、多くの組織は全世界で展開ADFSるためのユーザーがアクセスOffice365″サービスを容易にします。

二年前、microsoftが新しい認証方法とともに利用可能なシングルサインオンのさまざまな方法を作成し始めたとき、物事は変わり始めました。,

パススルー認証とシームレスなシングルサインオン

これらの方法の一つは、パススルー認証(PTA)でした。 PTAは、Office365へのwebサインオンと、ADドメインコントローラーに送信される認証要求を統合します。つまり、ユーザーはAzureでサインオンフォームを完了しますが、Azure AD Connectサーバーを通過した後もIDとパスワードはADによって検証されます。 時のMicrosoft開発したこと、そして新たな改善方法を提供するシングルサインオンできます。,

この新しい”シームレスなシングルサインオン”により、Azureは認証のKerberosチケットを受け入れることができました。 このKerberosトークンは、ユーザーが認証された元のADにリンクされ、検証のためにAzureに渡すことができます。 つまり、オンプレミスでサインインしてからOffice365にアクセスしようとするユーザーは、シンプルで安全なKerberosトークンで認証できます。

ただし、PTAにはまだオンプレミスコンポーネントが必要です。, これは最初はAzure AD Connectサーバーにエージェントとしてインストールされますが、可用性を高めるために追加のサーバーにインストールすることもできます。

問題になる可能性があるのは、このオンプレミス要件です。 インターネットパイプが失敗した場合、認証がクラウドのみに切り替わるか、認証エージェントへのインターネット接続が復元されるまで、Office365へのアクセ,

ビデオ：なぜAzure認証に移行するのですか？

オンプレミス認証プロセスのスレーブにならないでください。 この短いビデオを今すぐご覧ください。

• フェデレーション認証と管理認証アーキテクチャの違いを発見
• 認証を移行するためのベストプラクティスのアプローチを理解する

今すぐ見る

両方のベスト–ハイブリッドソリューション

このような状況を避けるために、別のオプションがあります。, パスワードハッシュ同期(PHS)を利用すると、ユーザーは常にAzure ADに対して直接認証できます。

これは、Office365環境への一貫したアクセスを提供する最良の方法ですが、ユーザーが必要とするシングルサインオン機能を削除するように見えます。

しかし、この場合、PHSはシームレスなシングルサインオン機能によって補完することができます。 紺碧の広告が同じなので、広告ベー Kerberosトークンを必要としませんの入力をユーザー IDおよびパスワードを入力します。,

オンプレミスユーザーはシームレスなシングルサインオンを使用してアクセスできますが、他のユーザーはサービスにアクセスするために正しいIDとパスワード

このシナリオでは、オンプレミス環境に依存することはなく、インターネット障害が発生した場合でも、外部ユーザーは認証できます。

このシナリオでは、 内部ADに障害が発生した場合でも、Kerberosトークンが使用できなくても、ユーザーはIDとパスワードを使用してアクセスできます。

違いは何ですか？,

この時点で、三つの認証方法の相対的な長所と短所を見る価値があるかもしれません。

これらの関数は、認証がオンプレミスのみである必要がある場合（クラウドベースのwebページに入力されていない場合）、またはユーザーのデバイスが内部または外部であるかどうかを判断する場合に、ADFSが依然として適切な選択であることを示しているようです。他のすべての場合には、ＰＴＡまたはＰＨＳの使用が好ましいであろう。, PHSはより良い可用性を提供し、オンプレミスの要素に依存しないため、一般に認証に推奨される方法です。

あなたのために働くものを見つける

最近（February2019）、NCSCはOffice365のセキュリティ保護に関するアドバイスを”クラウドネイティブ認証”を使用するよう この実施PHS、シームレスなシングルサインオンできます。 完全な文書はここで見つけることができます。

多くの組織にとって、これはADFSの実装からPHSとシームレスなシングルサインオンの使用に移行することを意味します。,

同期と認証の両方の変更には、ダウンタイムを最小限に抑えるためにある程度の注意を払ってアプローチする必要があります。もちろん、これはOFFICE365認証要件をADFS環境から削除するだけであり、他の依存者は削除されませんが、これらのほとんどは必要に応じてAzure ADに移動でき

シームレスなシングルサインオンによるADFSからpassword hash syncへの移行は少し恐ろしいように見えますが、ThirdSpaceは移行プロセスを加速するのに役立ちます。,

ADFSにはまだ用途があり、状況によっては最良の選択肢になる可能性があるため、特定の組織に最適な認証方法に関する専門家のアドバイスを

多くの人がクラウドベースの認証にジャンプしている理由についての詳細を得るために私たちの短いビデオを見てください。

また、四半期ごとのMicrosoft Technology Updateウェビナーシリーズで、Azure AD、Windows10、Office365に登場するすべての最新ニュースと機能をご覧ください。

---