Okta MFAを使用してOffice 365向けのAzure AD MFAの要件を満たす
Okta多要素認証(MFA)を使用して、WS-Federation Office 365アプリインスタンス向けAzure AD MFAの要件を満たすことができます。
Okta MFAは次のユースケースで使用できます。
- Oktaと連携認証されたドメインのAzure AD条件付きアクセスによってトリガーされるMFAプロンプトのMFA要件をOktaで処理する。
- OktaとMicrosoft両方のMFAニーズに対して単一MFAソリューションを使用できるように、Okta MFAを使用してエンドユーザーをWindows Hello for Businessに登録することができる。
既知の問題
ユーザーが無限サインイン・ループに陥ることがある
以下のシナリオで、エンドユーザーが無限サインイン・ループに陥ることがあります。
-
Oktaサインオン・ポリシーの方がAzure ADポリシーより弱い
-
組織レベルのサインイン・ポリシーもアプリレベルのサインイン・ポリシーもMFAを必要としない
この場合、OktaはユーザーにMFAをプロンプトしませんが、Azure AD条件付きアクセスにはMFAが必要であり、入力されたMFAクレームがOktaによって渡されることが期待されます。その結果、ユーザーが無限認証ループに陥ります。
-
アプリレベルのサインオンポリシーでは、ユーザーが「ゾーン内」のネットワークからサインインする場合はMFAは必要ありませんが、ユーザーが「ゾーン外」のネットワークからサインインする場合はMFAが必要です。
この場合、ユーザーがゾーン内のネットワークからサインインしても、MFAは求められません。Azure AD条件付きアクセスにはMFAが必要であり、入力されたMFAクレームがOktaによって渡されることが期待されます。その結果、ユーザーが無限認証ループに陥ります。
-
-
ユーザーがMFA後すぐにOffice 365にアクセスしない
ユーザーがOktaでMFAを完了したがすぐにOffice 365にアクセスしない場合、OktaはMFAクレームを渡しません。これにより、ユーザーが無限認証ループに陥ることがあります。無限ループから抜け出すには、ユーザーはWebブラウザを再度開いてMFAをもう一度完了する必要があります。
ユーザーがMFA要件から除外されている場合、Oktaは成功したMFAクレームを誤ってMicrosoftに渡す
これは、Office 365サインオン・ポリシーが特定のエンドユーザー(個人またはグループ)をMFA要件から除外した場合に起こります。
この場合、ユーザーはMFAを求められますが、ポリシーはこのユーザーがMFAを完了することなくサインインできるようにセットアップされているため、Oktaは成功したMFAクレームをAzure AD条件付きアクセスに送ります。Azure AD条件付きアクセスはOkta MFAクレームを受け入れ、ユーザーがMFAを完了することなくサインインすることを許可します。
開始する前に
-
OktaでMFAを構成する
実装方法に基づいて、以下のいずれか、または両方を行います。
- 「多要素認証」で説明されている通り組織レベルのサインオン・ポリシーを構成します。
- 「Office 365サインオンポリシーのスタートガイド」で説明されている通りに、WS-Federation Office 365アプリ・インスタンス向けアプリサインオン・ポリシーを構成します。
-
Azure ADでMFAを構成する
Microsoftドキュメントに従って、AzureADインスタンスでMFAを構成します。
この手順を開始する
Okta MFAのサポートを有効にするには、Office 365ドメインの連携認証設定を変更する必要があります。ドメインの連携認証を手動で行ったか自動で行ったかに応じて、次の手順のいずれかを選択します。
手動で連携認証されたドメインの場合
[Setup Instructions(設定手順)]から更新された連携認証スクリプトを実行します。
- Okta Admin Consoleで[Applications(アプリケーション)]>[Applications(アプリケーション)]に移動します。
- WS-Federationが行われたOffice 365アプリを開きます。
-
[Sign On(サインオン)]タブ[View Setup Instructions(設定手順を表示)]をクリックします。
[How to Configure Office 365 WS-Federation(Office 365 WS-Federationの設定方法)]ページが開きます。
- このページで、[ドメインがすでにフェデレーションされている場合]セクションに移動します。
- このセクションからスクリプトをコピーして、Windows PowerShellで実行します。
- オプションの[Okta MFA from Azure AD(Azure ADからのOkta MFA)]で、[Enable for this application(このアプリケーションに対して有効にする)]がオンになっていることを確認し、[Save(保存)]をクリックします。
- 次のPowerShellコマンドを実行して、SupportsMfa値がTrueであることを確認します。
Connect-MsolService
Get-MsolDomainFederationSettings -DomainName <yourDomainName>結果の例
コピーActiveLogOnUri : https://example.okta.com/app/office365/issueruri/sso/wsfed/active
DefaultInteractiveAuthenticationMethod :
FederationBrandName : Okta
IssuerUri : issueruri
LogOffUri : https://example.okta.com/app/office365/issueruri/sso/wsfed/signout
MetadataExchangeUri : https://example.okta.com/app/office365/issueruri/sso/wsfed/mex
NextSigningCertificate :
OpenIdConnectDiscoveryEndpoint :
PassiveLogOnUri : https://example.okta.com/app/office365/issueruri/sso/wsfed/passive
SigningCertificate : <SigningCertificate>
SupportsMfa : True
自動的に連携認証されたドメインの場合
この場合、設定を構成する必要はありません。
- Okta Admin Consoleで[Applications(アプリケーション)]>[Applications(アプリケーション)]に移動します。
- WS-Federationが行われたOffice 365アプリを開きます。
- [Sign On(サインオン)]タブ >[Edit(編集)]をクリックします。
- オプションの[Okta MFA from Azure AD(Azure ADからのOkta MFA)]で、[Enable for this application(このアプリケーションに対して有効にする)]がオンになっていることを確認し、[Save(保存)]をクリックします。
- 次のPowerShellコマンドを実行して、SupportsMfa値がTrueであることを確認します。
Connect-MsolService
Get-MsolDomainFederationSettings -DomainName <yourDomainName>結果の例
コピーActiveLogOnUri : https://example.okta.com/app/office365/issueruri/sso/wsfed/active
DefaultInteractiveAuthenticationMethod :
FederationBrandName : Okta
IssuerUri : issueruri
LogOffUri : https://example.okta.com/app/office365/issueruri/sso/wsfed/signout
MetadataExchangeUri : https://example.okta.com/app/office365/issueruri/sso/wsfed/mex
NextSigningCertificate :
OpenIdConnectDiscoveryEndpoint :
PassiveLogOnUri : https://example.okta.com/app/office365/issueruri/sso/wsfed/passive
SigningCertificate : <SigningCertificate>
SupportsMfa : True
この機能を無効にする
この機能を無効にするには、以下の手順を実行します。
- Okta Admin Consoleで[Applications(アプリケーション)]>[Applications(アプリケーション)]に移動します。
- WS-Federationが行われたOffice 365アプリを開きます。
- [Sign On(サインオン)]タブ >[Edit(編集)]をクリックします。
- オプションの[Okta MFA from Azure AD(Azure ADからのOkta MFA)]で、[Enable for this application(このアプリケーションに対して有効にする)]がオンになっていることを確認し、[Save(保存)]をクリックします。
この機能をオフにする場合は、Oktaで自動的に連携認証が行われ、この機能が有効になっているすべての連携認証ドメインについて、SupportsMfa設定を手動でfalseに設定する必要があります。
このPowerShellコマンドレットを使用してこの機能をオフにします。
Set-MsolDomainFederationSettings -DomainName <targetDomainName> -SupportsMfa $false機能の仕組み
Okta MFAがAzure AD条件付きアクセスMFAの要件を満たす
Office 365がMFAを必要とするAzure AD条件付きアクセスポリシーで構成されている場合、アプリにアクセスを試みるエンドユーザーは、Azure AD MFAの要件を満たすために、OktaによってMFAを求められます。次に、Oktaによって成功したMFAクレームがAzure ADに渡されます。Azure ADによってこのクレームが受け入れられ、エンドユーザーに個別のMFAが求められることなく、アクセスが許可されます。
次の表に示されているように、Azure AD条件付きアクセスMFAが有効になっていて、組織またはアプリレベルあるいは両レベルでOkta MFAが有効になっている場合に、OktaによってMFAクレームが渡されます。
Okta orgレベルMFA | Oktaアプリ・レベルMFA | Azure AD MFA | 実行される操作の内容 |
---|---|---|---|
無効 | 無効 | 有効 |
エンドユーザーが無限サインインループに陥ります。これを防ぐには、Azure AD MFAの要件を満たすためにOkta MFAを構成する必要があります。 |
有効 | 無効 | 有効 | エンドユーザーはOktaでMFAプロンプトに応えて入力します。入力されたMFAクレームがOktaによってAzure ADに渡されます。Azure ADによってOktaからのMFAが受け入れられ、個別のMFAは求められません。ユーザーはOffice 365へのアクセスを許可されます。 |
無効 | 有効 | 有効 | |
有効 | 有効 | 有効 |
OktaによってユーザーがWindows Hello for Businessに登録される
前提条件:デバイスがハイブリッドAzure ADまたはAzure ADに参加している必要があります。
組織でWindows Hello for Businessが必要な場合、Windows Hello for Businessにまだ登録されていないエンドユーザーは、Oktaでステップアップ認証(SMS、プッシュなど)を入力するよう求められます。Windows Hello for Businessへの登録に成功したら、エンドユーザーはそれを使用してデバイスにログインできます。次の表に示されているように、OktaがWindows Hello for Businessへのエンドユーザーの登録を支援します。
Okta orgレベルMFA | Oktaアプリ・レベルMFA | 実行される操作の内容 |
---|---|---|
無効 | 無効 |
エンドユーザーが無限サインインループに陥ります。これを防ぐには、Azure AD MFAの要件を満たすためにOkta MFAを構成する必要があります。 |
有効 | 無効 | エンドユーザーはOktaでステップアップMFAプロンプトに入力します。Windows Hello for Businessへの登録に成功すると、エンドユーザーはAzure AD多要素認証を満たすための要素としてWindows Hello for Businessを使用できます。 |
無効 | 有効 | |
有効 | 有効 |
関連項目
Office 365のプロビジョニングおよびデプロビジョニングスタートガイド
Windows Hello for Business(Microsoftドキュメント)