次の方法で共有


フェデレーションを使用した Microsoft Entra 多要素認証へ移行する

多要素認証 (MFA) ソリューションの Microsoft Entra ID への移行は、クラウドへの道筋の最適な第一歩です。 今後、ユーザー認証の Microsoft Entra ID への移行も検討してください。 詳細については、クラウド認証を使用した Microsoft Entra 多要素認証への移行のためのプロセスを確認してください。

フェデレーションを使用した Microsoft Entra 多要素認証に移行するために、Microsoft Entra 多要素認証の認証プロバイダーが AD FS にインストールされています。 Microsoft Entra ID 証明書利用者の信頼とその他の証明書利用者の信頼は、移行されたユーザーに対して Microsoft Entra 多要素認証を使用するように構成されます。

以下の図は、移行プロセスを示しています。

移行プロセスのフロー チャート。このドキュメントのプロセス領域と見出しは同じ順序です

移行グループを作成する

新しい条件付きアクセス ポリシーを作成するには、それらのポリシーをグループに割り当てる必要があります。 この目的のために、Microsoft Entra セキュリティ グループまたは Microsoft 365 グループを使用できます。 新しいものを作成または同期することもできます。

また、ユーザーを Microsoft Entra 多要素認証に反復的に移行するためにも Microsoft Entra セキュリティ グループは必要です。 これらのグループは、要求規則で使用されます。

セキュリティに使用されるグループを再利用しないでください。 セキュリティ グループを使用して、条件付きアクセス ポリシーで高価値アプリのグループをセキュリティで保護する場合、その目的のみにグループを使用してください。

AD FS を準備する

AD FS サーバー ファームを 2019、FBL 4 にアップグレードする

AD FS 2019 では、アプリケーションなど、証明書利用者に対して追加の認証方法を指定できます。 グループ メンバーシップを使用して、認証プロバイダーを決定します。 追加の認証方法を指定することで、切り替えの間に他の認証をそのままに維持しながら、Microsoft Entra 多要素認証に切り替えることができます。 詳細については、「WID データベースを使用した、Windows Server 2016 での AD FS へのアップグレード」を参照してください。 この記事では、ファームを AD FS 2019 にアップグレードし、FBL を 4 にアップグレードする方法について説明します。

Microsoft Entra 多要素認証を呼び出すための要求規則を構成する

Microsoft Entra 多要素認証が追加の認証方法になったので、それを使用するユーザーのグループを割り当てることができます。 これを行うには、要求規則 (証明書利用者信頼とも呼ばれます) を構成します。 グループを使用すると、グローバルまたはアプリケーションによって、どの認証プロバイダーが呼び出されるかを制御できます。 たとえば、結合されたセキュリティ情報に登録したユーザーに対しては Microsoft Entra 多要素認証を呼び出し、これを行わなかったユーザーに対しては MFA サーバーを呼び出すことができます。

Note

要求規則には、オンプレミスのセキュリティ グループが必要です。 要求規則を変更する前に、それらをバックアップします。

規則をバックアップする

新しい要求規則を構成する前に、規則をバックアップします。 これらの規則ルールは、クリーンアップ手順の一部として復元する必要があります。

構成によっては、規則をコピーし、移行用に作成している新しい規則を追加することが必要になる場合もあります。

グローバル規則を表示するには、次のように実行します。

Get-AdfsAdditionalAuthenticationRule

証明書利用者の信頼を表示するには、次のコマンドを実行し、RPTrustName を証明書利用者の信頼の要求規則の名前に置き換えます。

(Get-AdfsRelyingPartyTrust -Name "RPTrustName").AdditionalAuthenticationRules 

アクセス制御ポリシー

注意

グループ メンバーシップに基づいて特定の認証プロバイダーが呼び出されるように、アクセス制御ポリシーを構成することはできません。

アクセス制御ポリシーから追加の認証規則に切り替えるには、MFA Server 認証プロバイダーを使用して、各証明書利用者信頼に対して次のコマンドを実行します。

Set-AdfsRelyingPartyTrust -TargetName AppA -AccessControlPolicyName $Null

このコマンドでは、現在のアクセス制御ポリシーから追加の認証規則にロジックを移行します。

グループを設定して SID を検索する

Microsoft Entra 多要素認証の呼び出し対象としたいユーザーを配置する特定のグループを用意する必要があります。 そのグループのセキュリティ識別子 (SID) が必要になります。

グループ SID を検索するには、次のコマンドとグループ名を使用します。

Get-ADGroup "GroupName"

Get-ADGroup スクリプトの結果を示すスクリーンショットの画像。

Microsoft Entra 多要素認証を呼び出すための要求規則の設定

以下の PowerShell コマンドレットは、企業ネットワーク上にいない場合に、グループのユーザーに対して Microsoft Entra 多要素認証を呼び出します。 "YourGroupSid" を、上記のコマンドレットを実行して検出された SID に置き換えます。

2019 で追加の認証プロバイダーを選択する方法を必ず確認してください。

重要

要求規則をバックアップする

グローバル要求規則を設定する

次の PowerShell コマンドレットを実行します。

(Get-AdfsRelyingPartyTrust -Name "RPTrustName").AdditionalAuthenticationRules

コマンドを実行すると、証明書利用者信頼の現在の追加の認証規則が返されます。 現在の要求規則に次の規則を追加します。

c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value == 
"YourGroupSID"] => issue(Type = "http://schemas.microsoft.com/claims/authnmethodsproviders", 
Value = "AzureMfaAuthentication");
not exists([Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", 
Value=="YourGroupSid"]) => issue(Type = 
"http://schemas.microsoft.com/claims/authnmethodsproviders", Value = 
"AzureMfaServerAuthentication");'

次の例では、ユーザーがネットワークの外部から接続するときに、MFA を要求するように現在の要求規則が構成されていることを前提としています。 この例には、追加する必要がある規則が含まれています。

Set-AdfsAdditionalAuthenticationRule -AdditionalAuthenticationRules 'c:[type == 
"http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", value == "false"] => issue(type = 
"http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", value = 
"http://schemas.microsoft.com/claims/multipleauthn" );
 c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value == 
"YourGroupSID"] => issue(Type = "http://schemas.microsoft.com/claims/authnmethodsproviders", 
Value = "AzureMfaAuthentication");
not exists([Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", 
Value=="YourGroupSid"]) => issue(Type = 
"http://schemas.microsoft.com/claims/authnmethodsproviders", Value = 
"AzureMfaServerAuthentication");'

アプリケーションごとの要求規則を設定する

この例では、特定の証明書利用者信頼 (アプリケーション) の要求規則を変更し、追加する必要がある情報が含まれています。

Set-AdfsRelyingPartyTrust -TargetName AppA -AdditionalAuthenticationRules 'c:[type == 
"http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", value == "false"] => issue(type = 
"http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", value = 
"http://schemas.microsoft.com/claims/multipleauthn" );
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value == 
"YourGroupSID"] => issue(Type = "http://schemas.microsoft.com/claims/authnmethodsproviders", 
Value = "AzureMfaAuthentication");
not exists([Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", 
Value=="YourGroupSid"]) => issue(Type = 
"http://schemas.microsoft.com/claims/authnmethodsproviders", Value = 
"AzureMfaServerAuthentication");'

Microsoft Entra 多要素認証を AD FS の認証プロバイダーとして構成する

AD FS の Microsoft Entra 多要素認証を構成するには、それぞれの AD FS サーバーを構成する必要があります。 ファームに複数の AD FS サーバーがある場合は、Azure AD PowerShell を使用してリモートで構成できます。

このプロセスのステップバイステップの指示については、「AD FS での認証プロバイダーとしての Microsoft Entra 多要素認証の構成」の記事の「AD FS サーバーの構成」を参照してください。

サーバーを構成したら、追加の認証方法として Microsoft Entra 多要素認証を追加できます。

Microsoft Entra 多要素認証と Azure Multi-Factor Authentication Server が選択された [認証方法の編集] 画面を示すスクリーン ショット

Microsoft Entra ID を準備して移行を実装する

このセクションでは、ユーザーの MFA 設定を移行する前の最後の手順について説明します。

federatedIdpMfaBehavior を enforceMfaByFederatedIdp に設定する

フェデレーション ドメインに対しては、MFA を Microsoft Entra 条件付きアクセスまたはオンプレミス フェデレーション プロバイダーによって適用することができます。 各フェデレーション ドメインには、federatedIdpMfaBehavior という名前の Microsoft Graph PowerShell セキュリティ設定があります。 federatedIdpMfaBehaviorenforceMfaByFederatedIdp に設定することで、フェデレーション ID プロバイダーによって実行される MFA を Microsoft Entra ID が受け入れるようにできます。 フェデレーション ID プロバイダーによって MFA が実行されなかった場合、Microsoft Entra ID は MFA を実行するために、その要求をフェデレーション ID プロバイダーにリダイレクトします。 詳細については、federatedIdpMfaBehavior に関する記事を参照してください。

注意

federatedIdpMfaBehavior 設定は、New-MgDomainFederationConfiguration コマンドレットの SupportsMfa プロパティの新しいバージョンです。

SupportsMfa プロパティを設定するドメインの場合、これらの規則によって、federatedIdpMfaBehaviorSupportsMfa の連携方法が決まります。

  • federatedIdpMfaBehaviorSupportsMfa の切り替えはサポートされていません。
  • federatedIdpMfaBehavior プロパティが設定されると、Microsoft Entra ID は SupportsMfa 設定を無視します。
  • federatedIdpMfaBehavior プロパティが設定されていない場合、Microsoft Entra ID は引き続き SupportsMfa 設定に従います。
  • federatedIdpMfaBehavior または SupportsMfa が設定されていない場合、Microsoft Entra ID では acceptIfMfaDoneByFederatedIdp 動作が既定となります。

Get-MgDomainFederationConfiguration を使用して、federatedIdpMfaBehavior の状態を確認できます。

Get-MgDomainFederationConfiguration –DomainID yourdomain.com

Get-MgDomainFederationConfiguration を使用して SupportsMfa フラグの状態を確認することもできます。

Get-MgDomainFederationConfiguration –DomainName yourdomain.com

次の例では、Graph PowerShell を使用して federatedIdpMfaBehaviorenforceMfaByFederatedIdp に設定する方法を示します。

Request

PATCH https://graph.microsoft.com/beta/domains/contoso.com/federationConfiguration/6601d14b-d113-8f64-fda2-9b5ddda18ecc
Content-Type: application/json
{
  "federatedIdpMfaBehavior": "enforceMfaByFederatedIdp"
}

Response

注: ここに示されている応答オブジェクトは、読みやすくするために短縮されている可能性があります。

HTTP/1.1 200 OK
Content-Type: application/json
{
  "@odata.type": "#microsoft.graph.internalDomainFederation",
  "id": "6601d14b-d113-8f64-fda2-9b5ddda18ecc",
   "issuerUri": "http://contoso.com/adfs/services/trust",
   "metadataExchangeUri": "https://sts.contoso.com/adfs/services/trust/mex",
   "signingCertificate": "A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u",
   "passiveSignInUri": "https://sts.contoso.com/adfs/ls",
   "preferredAuthenticationProtocol": "wsFed",
   "activeSignInUri": "https://sts.contoso.com/adfs/services/trust/2005/usernamemixed",
   "signOutUri": "https://sts.contoso.com/adfs/ls",
   "promptLoginBehavior": "nativeSupport",
   "isSignedAuthenticationRequestRequired": true,
   "nextSigningCertificate": "A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u",
   "signingCertificateUpdateStatus": {
        "certificateUpdateResult": "Success",
        "lastRunDateTime": "2021-08-25T07:44:46.2616778Z"
    },
   "federatedIdpMfaBehavior": "enforceMfaByFederatedIdp"
}

必要に応じて条件付きアクセス ポリシーを構成する

条件付きアクセスを使用して、ユーザーに MFA をいつ要求するかを決定する場合は、ポリシーを変更する必要はありません。

(複数の) フェデレーション ドメインで SupportsMfa が false に設定されている場合は、Microsoft Entra ID 証明書利用者の信頼の要求規則を分析し、同じセキュリティ目標を満たす条件付きアクセス ポリシーを作成します。

AD FS と同じ制御を適用するための条件付きアクセス ポリシーを作成すると、Microsoft Entra ID 証明書利用者の要求規則のカスタマイズのバックアップおよび削除を行えます。

詳細については、次のリソースを参照してください。

ユーザーを Microsoft Entra 多要素認証に登録する

このセクションでは、ユーザーが統合セキュリティに登録する (MFA とセルフサービス パスワード リセット) 方法と、MFA 設定を移行する方法について説明します。 Microsoft Authenticator は、パスワードレス モードとして使用できます。 また、いずれかの登録方法を使用して MFA の 2 番目の要素として使用することもできます。

ユーザーに統合されたセキュリティ情報に登録してもらうことをお勧めします。これは、MFA と SSPR の両方に認証方法とデバイスを登録するための単一の場所です。

Microsoft では、統合された登録プロセスを進めるためにユーザーに提供できる通信テンプレートを用意しています。 これには、メール、ポスター、テーブル テント、他のさまざまなアセットのテンプレートなどがあります。 ユーザーは、https://aka.ms/mysecurityinfo で各自の情報を登録します。これにより、統合されたセキュリティ登録の画面に移動します。

信頼できるデバイスまたは場所から登録する必要がある条件付きアクセスを使用して、セキュリティ登録プロセスを保護することをお勧めします。 登録状態の追跡については、「Microsoft Entra ID の認証方法のアクティビティ」を参照してください。

Note

信頼されていない場所またはデバイスから、統合されたセキュリティ情報を登録する必要があるユーザーについては、一時アクセス パスを発行したり、代わりにポリシーから一時的に除外したりできます。

MFA Server から MFA 設定を移行する

MFA サーバー移行ユーティリティを使用して、ユーザーに対して登録済みの MFA 設定を MFA サーバーから Microsoft Entra ID に同期できます。 同期できるのは、電話番号、ハードウェア トークン、および Microsoft Authenticator 設定などのデバイス登録です。

ユーザーを適切なグループに追加する

  • 新しい条件付きアクセス ポリシーを作成した場合は、それらのグループに適切なユーザーを追加します。

  • 要求規則にオンプレミスのセキュリティ グループを作成した場合は、それらのグループに適切なユーザーを追加します。

セキュリティに使用されるグループを再利用しないことをお勧めします。 セキュリティ グループを使用して、条件付きアクセス ポリシーで高価値アプリのグループをセキュリティで保護する場合、その目的のみにグループを使用してください。

監視

Microsoft Entra 多要素認証の登録は、認証方法の使用状況と分析情報レポートを使用して監視できます。 このレポートは、Microsoft Entra ID 内で確認できます。 [監視] を選択し、[使用状況と分析情報] を選択します。

[使用状況と分析情報] で、[認証方法] を選択します。

詳細な Microsoft Entra 多要素認証の登録情報は、[登録] タブで確認できます。[Azure 多要素認証を使用できるユーザー] ハイパーリンクを選択することで、ドリルダウンして登録済みユーザーの一覧を表示できます。

MFA へのユーザー登録を示す認証方法アクティビティ画面の画像

クリーンアップ手順

Microsoft Entra 多要素認証への移行が完了し、MFA サーバーを廃止する準備ができたら、以下の 3 つの操作を行います。

  1. AD FS の要求規則を移行前の構成に戻し、MFA Server 認証プロバイダーを削除します。

  2. AD FS の認証プロバイダーとして MFA Server を 削除します。 これにより、Microsoft Entra 多要素認証が有効になっている唯一の追加の認証方法になるので、すべてのユーザーがこれを使用することが保証されます。

  3. MFA Server の使用を停止します。

AD FS の要求規則を元に戻し、MFA Server 認証プロバイダーを削除する

「Microsoft Entra 多要素認証を呼び出すための要求規則を構成する」の手順に従って、バックアップした要求規則に戻し、AzureMFAServerAuthentication 要求規則をすべて削除します。

たとえば、ルールから次を削除します。

c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value ==
"**YourGroupSID**"] => issue(Type = "http://schemas.microsoft.com/claims/authnmethodsproviders",
Value = "AzureMfaAuthentication");
not exists([Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid",
Value=="YourGroupSid"]) => issue(Type =
"http://schemas.microsoft.com/claims/authnmethodsproviders", Value =
"AzureMfaServerAuthentication");'

MFA Server を AD FS の認証プロバイダーとして無効にする

この変更により、Microsoft Entra 多要素認証だけが認証プロバイダーとして使用されることが保証されます。

  1. AD FS 管理コンソールを開きます。

  2. [サービス] で、[認証方法] を右クリックし、[多要素認証方法の編集] を選択します。

  3. [Azure Multi-Factor Authentication Server] の横のチェック ボックスをオフにします。

MFA Server の使用を停止する

エンタープライズ サーバーの使用停止プロセスに従って、環境内の MFA Server を削除します。

MFA Server の使用停止時に考えられる考慮事項は次のとおりです。

  • サーバーを削除する前に、MFA Server のログを確認し、ユーザーまたはアプリケーションで MFA Server が使用されていないことを確認します。

  • サーバーの [コントロール パネル] から、Multi-Factor Authentication Server をアンインストールします

  • 必要に応じて、最初のバックアップ後に残っているログとデータ ディレクトリをクリーンアップします。

  • 該当する場合は、etpub\wwwroot\MultiFactorAuthWebServiceSdk ディレクトリと MultiFactorAuth ディレクトリに残っているすべてのファイルを含め、多要素認証 Web サーバー SDK をアンインストールします

  • 8.0 より前の MFA サーバー バージョンの場合は、多要素認証電話アプリ Web サービスの削除も必要になる場合があります

次のステップ