オンプレミスとクラウドへのアクセスを許可するようにOffice 365のサインオン・ルールを構成する

OktaでOffice 365ドメインを正常にフェデレーションしたら、オンプレミスとクラウドの両方のアクセスを許可するようにOffice 365アプリのサインオン・ポリシーを構成する必要があります。

ユーザーのログイン要求は、Azure ADに対して認証され、プライマリ更新トークン(PRT)を受け取ります。このトークンはWindows 10デバイスの登録とともに付与され、WINLOGONサービスを使用します。ただし、WINLOGONサービスはレガシー認証を使用しているため、OktaのデフォルトのOffice 365サインオン・ポリシーによってブロックされています。したがって、WINLOGONサービスを許可するようにOffice 365のアプリ・レベルのサインオン・ポリシーを構成する必要があります。

MFAはレバ認証リクエストには強制適用できず、パスワードスプレーなどのサイバー攻撃に対して脆弱になります。したがって、レガシー認証の使用を最小限に抑えることをお勧めします。

この手順には次のタスクが含まれます:

  1. Oktaでサインオンルールを構成する

  2. Microsoft側でレガシー認証をブロックする

Oktaでサインオンルールを構成する

レガシー認証の使用を最小限に抑えながら、ハイブリッドAADに参加しているデバイスをAzure ADに安全に接続できるようにする方法は2つあります。

1. レガシー認証を使用するために選択したユーザーエージェント文字列のみを許可する

Office 365アプリのサインオン・ルールを使用して特定の信頼できるクライアントをフィルタリングし、 Windows-AzureAD-Authentication-ProviderなどのようにクライアントにOffice 365のリソースへのアクセスを許可できます。これにより、Office 365アプリにアクセスできるユーザー・エージェントをより細かく制御できます。Office 365サインオン・ポリシーでカスタム・クライアントを許可または拒否するを参照してください。

2. ローカルイントラネット内でのみレガシー認証を許可し、非ローカルにはMFAを要求する

この手順には2つの部分があります。

a. ローカルイントラネット内でのみレガシー認証を許可する

Microsoftテナントで、レガシー認証を使用するすべてのMicrosoftサービスを無効にします。次にOktaでOffice 365アプリのサインオンポリシーを変更して、デバイスがローカルイントラネットにある場合にのみレガシー認証を許可します。次のドキュメントを参照してください。

b. ローカルイントラネットの外部でMFAを要求する

ユーザーがローカルイントラネット上にないデバイスを使用している場合は、Azure ADリソースへのアクセスを許可する前に、MFAプロンプトを正常に完了するようにユーザーに要求します。Azure ADでこのようなユーザーに多要素認証を要求する条件付きアクセス・ポリシーを作成してから、Oktaで多要素認証を使用してAzure AD多要素認証を満たすように設定します。

このシナリオでは、Azure ADによってユーザーがOktaにリダイレクトされ、MFAプロンプトが完了します。プロンプトが正常に完了すると、OktaはMFAクレームをAzure ADに渡し、AzureADはユーザーがMicrosoftリソースにアクセスできるようにします。これにより、ユーザーが入力する必要があるのは1回のMFAプロンプトのみであるため、サインイン・エクスペリエンスが合理化されます。Okta多要素認証を使用してOffice 365向けのAzure AD多要素認証の要件を満たすを参照してください。

条件付きアクセス・ポリシーとOffice 365アプリのサインオン・ポリシーを組み合わせて使用して、幅広いセキュリティーを確保することをお勧めします。Oktaは、サインオン・イベントのたびにサインオン・ポリシーを適用します。サインオン後、Azure ADは定期的に条件付きアクセスポリシーを適用して、アクセスが安全であることを確認します。

Microsoft側でレガシー認証をブロックする

Microsoftで認証ポリシーを作成して、すべてのMicrosoftサービスのレガシー認証をブロックします。これらのポリシーをユーザーに割り当てます。 「Disable Basic authentication in Exchange Online(Exchange Onlineでの基本認証の無効化)」 (Microsoftドキュメント)を参照してください。