AD FS エクストラネットのロックアウトおよびエクストラネットのスマート ロックアウトの概要
エクストラネット スマート ロックアウト (ESL) を使用すると、ユーザーが悪意のあるアクティビティからエクストラネット アカウントのロックアウトを発生させるのを防ぐことができます。
ESL を使用すると、AD FS は、ユーザーにとってなじみのある場所からのサインイン試行と、攻撃者である可能性があるサインイン試行を区別できるようになります。 AD FS では、有効なユーザーが自分のアカウントを引き続き使用できるようにする一方で、攻撃者をロックアウトすることができます。 この区別により、ユーザーに対するサービス拒否攻撃と特定のクラスのパスワード スプレー攻撃を防ぐことができます。 ESL は Windows Server 2016 の AD FS で使用でき、Windows Server 2019 の AD FS に組み込まれています。
ESL は、Web アプリケーション プロキシまたはサードパーティ プロキシを使用してエクストラネットを経由するユーザー名とパスワードの認証要求に対してのみ使用できます。 すべてのサードパーティ プロキシでは、MS-ADFSPIP プロトコルをサポートして、F5 BIG-IP Access Policy Manager などの Web アプリケーション プロキシの代わりに使用する必要があります。 プロキシが MS-ADFSPIP プロトコルをサポートしているかどうかを確認するには、サードパーティのプロキシのドキュメントを参照してください。
AD FS 2019 の機能
AD FS 2019 でのエクストラネット スマート ロックアウトでは AD FS 2016 と比較して次の利点があります。
- なじみのある場所と不明な場所に対する独立したロックアウトしきい値。 既知の適切な場所のユーザーには、疑わしい場所からの要求よりも間違えた場合の余地を多めに設定できます。
- 従来のソフト ロックアウト動作を引き続き適用しながら、スマート ロックアウトの監査モード。 この区別により、ユーザーがなじみのある場所について学習しながら、AD FS 2012 R2 から使用できるエクストラネット ロックアウト機能によって保護を受けることができます。
構成情報
ESL を効にすると、アーティファクト データベース (AdfsArtifactStore.AccountActivity
) に新しいテーブルが作成されます。 ノードは、AD FS ファーム内で "ユーザー アクティビティ" プライマリ ノードとしても選択されます。 Windows Internal Database (WID) 構成では、このノードは常にプライマリ ノードになります。 SQL 構成では、ユーザー アクティビティ プライマリ ノードとして 1 つのノードが選択されます。
"ユーザー アクティビティ" プライマリ ノードとして選択されたノードを表示するには、(Get-AdfsFarmInformation).FarmRoles
を使用します。
すべてのセカンダリ ノードは、新規のサインインのたびにポート 80 を介してプライマリ ノードに接続し、不正なパスワードのカウントと、なじみのある場所についての最新の値を確認します。 また、セカンダリ ノードは、サインインの処理後にプライマリ ノードも更新します。
セカンダリ ノードがプライマリ ノードに接続できない場合、セカンダリ ノードは AD FS 管理者ログにエラー イベントを書き込みます。 認証は引き続き処理されますが、AD FS では更新された状態のみがローカルに書き込まれます。 AD FS は、プライマリ ノードへの接続を 10 分ごとに再試行します。 プライマリ ノードが使用可能になると、AD FS はプライマリ ノードに切り替わります。
用語
- FamiliarLocation: 認証要求中に、提示されているすべてのインターネット プロトコル (IP) が ESL によって確認されます。 これらの IP アドレスは、ネットワーク IP、転送された IP、オプションの X-Forwarded-For IP の組み合わせになります。 要求が成功すると、アカウント アクティビティ テーブルにすべての IP が "なじみのある IP" として追加されます。 要求の IP がすべて "なじみのある IP" に存在する場合、要求は "なじみのある" 場所として扱われます。
- UnknownLocation: 受信する要求の中に、既存の FamiliarLocation リストに存在しない IP が少なくとも 1 つある場合、その要求は "不明" な場所として扱われます。 このアクションは、Exchange Online のアドレスが成功した要求と失敗した要求の両方を処理する Exchange Online レガシ認証などのプロキシ シナリオを処理するためのものです。
- badPwdCount: 正しくないパスワードが送信され、認証に失敗した回数を表す値。 ユーザーごとに、なじみのある場所および不明な場所について、個別のカウンターが保持されます。
- UnknownLockout: 不明な場所からのアクセスでユーザーがロックアウトされた場合のユーザーごとのブール値。 この値は、badPwdCountUnfamiliar の値と ExtranetLockoutThreshold の値に基づいて計算されます。
- ExtranetLockoutThreshold: この値は、正しくないパスワードの最大試行回数を決定します。 しきい値に達すると、AD FS は、監視ウィンドウが経過するまで、エクストラネットからの要求を拒否します。
- ExtranetObservationWindow: この値は、不明な場所からのユーザー名とパスワードの要求がロックアウトされる期間を決定します。この期間を経過すると、AD FS は不明な場所からのユーザー名とパスワードの認証を再開します。
- ExtranetLockoutRequirePDC: 有効になっている場合、エクストラネットのロックアウトにはプライマリ ドメイン コントローラー (PDC) が必要です。 無効になっていると、PDC が使用できない場合、エクストラネットのロックアウトは別のドメイン コントローラーにフォールバックされます。
- ExtranetLockoutMode: ESL のログのみモードと強制モードを制御します。
- ADFSSmartLockoutLogOnly: ESL が有効になっています。 AD FS では管理と監査のイベントが書き込まれますが、認証要求の拒否は行われません。 このモードは、ADFSSmartLockoutEnforce が有効になる前に FamiliarLocation が設定されるように有効にすることを目的としています。
- ADFSSmartLockoutEnforce: しきい値に達した場合に、不明な認証要求のブロックをフル サポートします。
IPv4 アドレスと IPv6 アドレスがサポートされています。
トランザクションの構造
Pre-Auth Check: 認証要求中に、提示されているすべての IP が ESL によって確認されます。 これらの IP アドレスは、ネットワーク IP、転送された IP、オプションの X-Forwarded-For IP の組み合わせになります。 監査ログでは、これらの IP は、x-ms-forwarded-client-ip、x-forwarded-for、x-ms-proxy-client-ip の順に、
<IpAddress>
フィールドに一覧表示されます。これらの IP に基づいて、AD FS は、要求がなじみのある場所からのものであるかを判断し、それぞれの badPwdCount が設定されたしきい値未満かどうか、または前回失敗した試行が監視ウィンドウの期間よりも長くなったかどうかを確認します。 これらの条件のいずれかが true の場合、AD FS では、このトランザクションについて、さらに処理および資格情報の検証を行うことができます。 両方の条件が false の場合は、監視ウィンドウが経過するまで、アカウントは既にロック アウト状態になっています。 監視ウィンドウが経過すると、ユーザーは 1 回認証を試みることができます。 Windows Server 2019 では、AD FS は、IP アドレスがなじみのある場所と一致するかどうかに基づいて、適切なしきい値の上限をチェックします。
ログイン成功: ログインに成功すると、要求の IP がユーザーのなじみのある場所の IP 一覧に追加されます。
ログイン失敗: ログインに失敗した場合、badPwdCount が加算されます。 攻撃者が不正なパスワードをしきい値を上回る回数システムに送信すると、そのユーザーはロックアウト状態に移行します。 (badPwdCount > ExtranetLockoutThreshold)
アカウントがロックアウトされている場合、UnknownLockout 値は True になります。このロックアウトは、ユーザーの badPwdCount がしきい値を超えていることを意味します。 たとえば、誰かがシステムで許可されている回数以上のパスワードを試行したとします。 この状態では、有効なユーザーがサインインできる方法は 2 つあります。
- ObservationWindow 時間が経過するまで待つ。
- ロックアウト状態をリセットするため、Reset-ADFSAccountLockout を使用して badPwdCount をゼロにリセットする。
リセットが行われない場合、アカウントには、監視ウィンドウごとに AD に対して 1 回のパスワード試行が許可されます。 この試行の後、アカウントはロックアウト状態に戻り、監視ウィンドウが再起動されます。 badPwdCount 値は、パスワードのサインインが成功した後にのみ、自動的にリセットされます。
ログのみモードと強制モード
AccountActivity テーブルは、ログのみモードと強制モードの両方で値が設定されます。 ログのみモードがバイパスされて ESL が推奨される待期期間なしに直接強制モードに移ると、ユーザーのなじみのある IP が AD FS からはわからなくなります。 その後、ESL は ADBadPasswordCounter のように動作し、ユーザー アカウントがブルート フォース攻撃を現に受けている場合、正当なユーザー トラフィックをブロックする可能性があります。 ログのみモードがバイパスされ、ユーザーが UnknownLockout が True に等しいロックアウト状態になり、"なじみのある" IP 一覧に含まれていない IP から適切なパスワードでサインインを試みると、サインインできなくなります。 このシナリオを回避するため、ログのみモードは 3 から 7 日にすることをお勧めします。 アカウントが現に攻撃を受けている状況では、正当なユーザーがロックアウトされるのを防ぐために、最低 24 時間のログのみモードが必要です。
エクストラネット スマート ロックアウトの構成
以降のセクションでは、AD FS 2016 の ESL を有効にするための前提条件と構成について説明します。
AD FS 2016 の前提条件
ファーム内のすべてのノードに更新プログラムをインストールします。
まず、すべての Windows Server 2016 AD FS サーバーが、2018 年 6 月の Windows Update で最新の状態であり、AD FS 2016 ファームが 2016 ファームの動作レベルで実行されていることを確認します。
アクセス許可を確認します。
ESL では、すべての AD FS サーバーで Windows リモート管理が有効になっている必要があります。
アーティファクト データベースのアクセス許可を更新します。
ESL では、AD FS サービスアカウントに、AD FS アーティファクト データベースに新しいテーブルを作成するためのアクセス許可が必要です。 AD FS 管理者として任意の AD FS サーバーにサインインします。次に、PowerShell コマンド プロンプト ウィンドウで次のコマンドを実行して、このアクセス許可を付与します。
PS C:\>$cred = Get-Credential PS C:\>Update-AdfsArtifactDatabasePermission -Credential $cred
注意
$cred プレースホルダーは、AD FS 管理者のアクセス権限をもつアカウントです。 これにより、テーブルを作成するための書き込みアクセス権限が与えられます。
上記のコマンドは、十分なアクセス許可がないという理由で失敗する可能性があります。これは、AD FS ファームで SQL Server が使用されており、以前に提供された資格情報に SQL サーバー対する管理者権限がないためです。 この場合、AdfsArtifactStore データベースに接続しているときに次のコマンドを実行して、SQL Server データベースでデータベースのアクセス許可を手動で構成できます。
# when prompted with “Are you sure you want to perform this action?”, enter Y. [CmdletBinding(SupportsShouldProcess=$true,ConfirmImpact = 'High')] Param() $fileLocation = "$env:windir\ADFS\Microsoft.IdentityServer.Servicehost.exe.config" if (-not [System.IO.File]::Exists($fileLocation)) { write-error "Unable to open AD FS configuration file." return } $doc = new-object Xml $doc.Load($fileLocation) $connString = $doc.configuration.'microsoft.identityServer.service'.policystore.connectionString $connString = $connString -replace "Initial Catalog=AdfsConfigurationV[0-9]*", "Initial Catalog=AdfsArtifactStore" if ($PSCmdlet.ShouldProcess($connString, "Executing SQL command sp_addrolemember 'db_owner', 'db_genevaservice' ")) { $cli = new-object System.Data.SqlClient.SqlConnection $cli.ConnectionString = $connString $cli.Open() try { $cmd = new-object System.Data.SqlClient.SqlCommand $cmd.CommandText = "sp_addrolemember 'db_owner', 'db_genevaservice'" $cmd.Connection = $cli $rowsAffected = $cmd.ExecuteNonQuery() if ( -1 -eq $rowsAffected ) { write-host "Success" } } finally { $cli.CLose() } }
AD FS のセキュリティ監査ログが有効になっていることを確認する
この機能ではセキュリティ監査ログを使用するため、AD FS で監査を有効にし、すべての AD FS サーバーのローカル ポリシーを有効にする必要があります。
構成の手順
ESL では、AD FS プロパティの ExtranetLockoutEnabled を使用します。 このプロパティは、以前は Server 2012 R2 でエクストラネット ソフト ロックアウトの制御に使用されていました。 ESL が有効になっており、現在のプロパティ構成を表示する場合は、Get-AdfsProperties
を実行します。
構成に関する推奨事項
ESL を構成する際には、次のベスト プラクティスに従ってしきい値を設定します。
ExtranetObservationWindow (new-timespan -Minutes 30)
ExtranetLockoutThreshold: Half of AD Threshold Value
AD value: 20, ExtranetLockoutThreshold: 10
Active Directory のロックアウトは、ESL とは独立して動作します。 ただし、Active Directory のロックアウトが有効になっている場合は、AD FS で [ExtranetLockoutThreshold] を選択し、AD で [アカウント ロックアウトしきい値] を選択します。
ExtranetLockoutRequirePDC - $false
有効になっている場合、エクストラネット ロックアウトにはプライマリ ドメイン コントローラー (PDC) が必要です。 無効になっていて false として構成されている場合、エクストラネットのロックアウトは、PDC が使用できない場合に別のドメイン コントローラーにフォールバックされます。
このプロパティを設定するには、次を実行します。
Set-AdfsProperties -EnableExtranetLockout $true -ExtranetLockoutThreshold 15 -ExtranetObservationWindow (New-TimeSpan -Minutes 30) -ExtranetLockoutRequirePDC $false
"ログのみ" モードを有効にする
ログのみモードでは、AD FS はユーザーになじみのある場所の情報の値を設定し、セキュリティ監査イベントを書き込みますが、要求をブロックすることはありません。 このモードは、スマート ロックアウトが実行されていることを検証するため、および、強制モードを有効にする前に、ユーザーのなじみのある場所を AD FS が "学習" できるようにするために使用します。 AD FS は学習するにつれて、ユーザーごとのサインイン アクティビティを (ログのみモードか強制モードかに関係なく) 保存します。 次のコマンドレットを実行して、ロックアウト動作をログのみに設定します。
Set-AdfsProperties -ExtranetLockoutMode AdfsSmartlockoutLogOnly
ログのみモードは一時的な状態として想定されており、システムが、スマート ロックアウトの動作を使用してロックアウトの適用を導入する前に、サインインの動作を学習できるようにするものです。 ログのみモードの推奨期間は 3 から 7 日です。 アカウントが現に攻撃を受けている状況では、ログのみモードを最低 24 時間実行する必要があります。
AD FS 2016 では、エクストラネット スマート ロックアウトを有効にする前に 2012 R2 のエクストラネットのソフト ロックアウトの動作が有効になっている場合、ログのみモードによってエクストラネットのソフト ロックアウトの動作が無効になります。 AD FS スマート ロックアウトでは、ユーザーがログのみモードでロックアウトされることはありません。 ただし、オンプレミスの AD では、AD の構成に基づいてユーザーがロックアウトされる場合があります。 オンプレミス AD でユーザーをロックアウトする方法については、「AD ロックアウト ポリシー」を確認してください。
AD FS 2019 では、次の PowerShell を使用して、以前のソフト ロックアウト動作の適用を継続しながら、スマート ロックアウトについてはログのみモードを有効にできるというもう 1 つの利点があります。
Set-AdfsProperties -ExtranetLockoutMode 3
新しいモードを有効にするには、次を使用して、ファーム内のすべてのノードで AD FS サービスを再起動します。
Restart-service adfssrv
モードが構成されたら、EnableExtranetLockout パラメーターを使用してスマート ロックアウトを有効にできます。
Set-AdfsProperties -EnableExtranetLockout $true
強制モードを有効にする
ロックアウトのしきい値と監視ウィンドウで安定した設定が見つかったら、次の PSH コマンドレットを使用して、ESL を強制モードに移行できます。
Set-AdfsProperties -ExtranetLockoutMode AdfsSmartLockoutEnforce
新しいモードを有効にするには、次のコマンドを使用してファーム内のすべてのノードで AD FS サービスを再起動します。
Restart-service adfssrv
ユーザー アカウントのアクティビティの管理
AD FS では、アカウントのアクティビティ データを管理するための 3 つのコマンドレットが提供されています。 これらのコマンドレットは、プライマリ ロールを保持しているファーム内のノードに自動的に接続します。
注意
Just Enough Administration (JEA) を使用して、アカウントのロックアウトをリセットする AD FS コマンドレットを委任できます。 たとえば、ヘルプ デスクの担当者に ESL コマンドレットを使用するためのアクセス許可を委任できます。 詳細については、「管理者以外のユーザーへの AD FS PowerShell コマンドレットのアクセスの委任」を参照してください。
この動作をオーバーライドするには、-Server
パラメーターを渡します。
Get-ADFSAccountActivity -UserPrincipalName
このコマンドレットは、Account Activity REST エンドポイントを使用して、ファームのプライマリ ノードに自動的に接続します。 したがって、すべてのデータは常に一貫していることになります。 次を使用して、ユーザー アカウントの現在のアカウント アクティビティを読み取ります。
Get-ADFSAccountActivity user@contoso.com
プロパティ:
- BadPwdCountFamiliar: 既知の場所からの認証が失敗したときにインクリメントされます。
- BadPwdCountUnknown: 不明な場所からの認証が失敗したときにインクリメントされます。
- LastFailedAuthFamiliar: 使い慣れた場所から認証が失敗した場合、LastFailedAuthFamiliar は認証に失敗した時刻に設定されます。
- LastFailedAuthUnknown: 不明な場所からの認証が失敗した場合、LastFailedAuthUnknown は認証に失敗した時刻に設定されます。
- FamiliarLockout: BadPwdCountFamiliar>ExtranetLockoutThreshold の場合に True となるブール値。
- UnknownLockout: BadPwdCountUnknown>ExtranetLockoutThreshold の場合に True となるブール値。
- FamiliarIPs: ユーザーにとってなじみのある最大 20 個の IP。 20 個の IP を超えると、リスト内で最も古い IP が削除されます。
Set-ADFSAccountActivity
Set-ADFSAccountActivity は、新しいなじみのある場所を追加します。 なじみのある IP リストには、最大 20 個のエントリがあります。 20 個のエントリを超えると、リスト内で最も古い IP が削除されます。
Set-ADFSAccountActivity user@contoso.com -AdditionalFamiliarIps “1.2.3.4”
Reset-ADFSAccountLockout
あるユーザー アカウントについて、それぞれのなじみのある場所 (badPwdCountFamiliar) または不明な位置カウンター (badPwdCountUnfamiliar) のロックアウト カウンターをリセットします。 カウンタをリセットすると、リセットされたカウンターがしきい値を下回るため、FamiliarLockout または UnfamiliarLockout の値が更新されます。
Reset-ADFSAccountLockout user@contoso.com -Location Familiar
Reset-ADFSAccountLockout user@contoso.com -Location Unknown
AD FS エクストラネット ロックアウトについてのイベント ログとユーザー アクティビティ情報
以降のセクションでは、イベント ログ、ユーザー アカウント アクティビティ、ロックアウトを監視する方法について説明します。
Connect Health
ユーザー アカウントのアクティビティを監視するには、Connect Health を使用することをお勧めします。 Connect Health は、危険な IP と不正なパスワードの試行についてのダウンロード可能なレポートを生成します。 危険な IP のレポートの各項目は、指定されたしきい値を超える、失敗した AD FS サインイン アクティビティに関する集計情報を示しています。 AD FS サインイン アクティビティの失敗が発生したときに、カスタマイズ可能なメール設定を使用して管理者に警告するようにメール通知を設定できます。 詳細とセットアップ手順については、「Microsoft Entra Connect Health を使用した AD FS の 監視」を参照してください。
AD FS エクストラネット スマート ロックアウト イベント
注意
ESL のトラブルシューティングについては、「パスワード スプレー攻撃とアカウント ロックアウトの軽減」を参照してください。
エクストラネット スマート ロックアウト イベントを書き込むには、ログのみモードまたは強制モードで ESL を有効にし、AD FS セキュリティ監査を有効にする必要があります。 AD FS は、次の場合にエクストラネット ロックアウト イベントをセキュリティ監査ログに書き込みます。
- ユーザーがロックアウトされた場合。これは、ユーザーがサインイン試行の失敗に対するロックアウトしきい値に達していることを意味します。
- AD FS が、既にロックアウト状態にあるユーザーのサインイン試行を受信した場合。
ログのみモードでは、ロックアウト イベントをセキュリティ監査ログで確認できます。 検出されたイベントについては、Get-ADFSAccountActivity
コマンドレットを使用してユーザーの状態を確認し、ロックアウトがなじみのある IP アドレスから発生したか、または不明な IP アドレスから発生したかを判断できます。 Get-ADFSAccountActivity
コマンドレットを使用して、そのユーザーのなじみのある IP アドレスの一覧をダブルチェックすることもできます。
イベント ID | 説明 |
---|---|
1203 | このイベントは、不正なパスワードの試行ごとに書き込まれます。 badPwdCount が ExtranetLockoutThreshold で指定された値に達すると、アカウントは即座に AD FS でロックアウトされます。ロックアウトの期間は、ExtranetObservationWindow で指定されます。 Activity ID: %1 XML: %2 |
1210 | このイベントは、ユーザーがロックアウトされるごとに書き込まれます。 Activity ID: %1 XML: %2 |
557 (AD FS 2019) | ノード %1 で、のアカウント ストア rest サービスとの通信を試みているときにエラーが発生しました。 WID ファームを使用する場合は、プライマリ ノードがオフラインになる可能性があります。 SQL ファームを使用する場合は、AD FS でユーザー ストアのプライマリ ロールをホストする新しいノードが自動的に選択されます。 |
562 (AD FS 2019) | サーバー %1 のアカウント ストア エンドポイントと通信中にエラーが発生しました。 Exception Message: %2 |
563 (AD FS 2019) | エクストラネット ロックアウト状態の計算中にエラーが発生しました。 %1 の値により、このユーザーに対する認証が許可され、トークンの発行が続行されます。 WID ファームを使用する場合は、プライマリ ノードがオフラインになる可能性があります。 SQL ファームを使用する場合は、AD FS でユーザー ストアのプライマリ ロールをホストする新しいノードが自動的に選択されます。 Account store server name: %2 User ID: %3 Exception Message: %4 |
512 | 次のユーザーのアカウントがロックアウトされています。システム構成により、サインイン試行が許可されています。 Activity ID: %1 User: %2 Client IP: %3 Bad Password Count: %4 Last Bad Password Attempt: %5 |
515 | 次のユーザー アカウントはロックアウト状態にあり、正しいパスワードが指定されました。 このアカウントは侵害されている可能性があります。 More Data Activity ID: %1 User: %2 Client IP: %3 |
516 | 次のユーザー アカウントは、不正なパスワードの試行回数が多すぎるため、ロックアウトされました。 Activity ID: %1 User: %2 Client IP: %3 Bad Password Count: %4 Last Bad Password Attempt: %5 |
ESL に関してよく寄せられる質問
強制モードでエクストラネット スマート ロックアウトを使用している AD FS ファームで、悪意のあるユーザーのロックアウトに至ることはあるのでしょうか。
AD FS スマート ロックアウトが強制モードに設定されている場合、ブルート フォースまたはサービス拒否によって、正当なユーザーのアカウントがロックアウトされることはありません。 悪意のあるアカウントのロックアウトによってユーザーがサインインできなくなる唯一の方法は、悪意のあるアクターがユーザーのパスワードを持っている場合、またはそのユーザーの既知の (なじみのある) IP アドレスから要求を送信できる場合だけです。
ESL が有効になっていて、悪意のあるアクターがユーザーのパスワードを知っている場合はどうなりますか。
ブルート フォース攻撃のシナリオの一般的な目的は、パスワードを推測し、正常にサインインすることです。 ユーザーがフィッシングを受けた場合、またはパスワードが推測された場合、サインインは正しいパスワードと新しい IP という成功の条件を満たすため、ESL 機能はアクセスをブロックしません。 この場合、悪意のあるアクターが使用する IP は、なじみのあるもののように見えてしまいます。 このシナリオで最善の軽減策は、AD FS でのユーザーのアクティビティをクリアし、ユーザーに多要素認証を求めることです。 推測可能なパスワードをシステムが受け入れないように、Microsoft Entra パスワード保護をインストールする必要があります。
ユーザーがある IP から正常にサインインしたことが一度もなく、間違ったパスワードを数回使用しようとする場合、最終的にパスワードを正しく入力すると、サインインできるようになりますか。
ユーザーが (タイプミスなどで) 正しくないパスワードを複数回送信し、次の試行でパスワードを正しく送信した場合、ユーザーはすぐに正常にサインインできます。 この正常なサインインにより、不正なパスワードのカウントがクリアされ、その IP が FamiliarIP リストに追加されます。 ただし、不明な場所からの失敗したサインインのしきい値を超えると、ロックアウト状態になります。 監視ウィンドウを経過するまで待機してから、有効なパスワードを使用してサインインする必要があります。 アカウントをリセットするには、管理者の介入が必要になる場合があります。
イントラネットでも ESL は機能しますか。
クライアントが Web アプリケーション プロキシ サーバー経由ではなく、AD FS サーバーに直接接続している場合、ESL の動作は適用されません。
[クライアント IP] フィールドに Microsoft IP アドレスが表示されます。 ESL は、EXO プロキシを使用するブルート フォース攻撃をブロックしますか。
ESL は、Exchange Online またはその他のレガシ認証のブルート フォース攻撃シナリオを防ぐためにうまく機能します。 レガシ認証では、"アクティビティ ID" が 00000000-0000-0000-0000-000000000000 となります。 これらの攻撃では、悪意のあるアクターが Exchange Online のベーシック認証 (レガシ認証とも呼ばれる) を利用して、クライアントの IP アドレスが Microsoft のものとして表示されるようにします。 クラウドの Exchange Online サーバーは、Outlook クライアントに代わって認証の検証をプロキシします。 このようなシナリオでは、悪意のある送信者の IP アドレスは、x-ms-forwarded-client-ip で、Microsoft Exchange Online サーバーの IP は、x-ms-client-ip の値です。 エクストラネット スマート ロックアウトでは、ネットワーク IP、転送された IP、x-forwarded-client-IP、x-ms-client-ip の値が確認されます。 要求が成功すると、すべての IP がなじみのあるリストに追加されます。 要求が受信され、提示された IP のいずれかがなじみのあるリストに含まれていない場合、要求はなじみのないものとしてマークされます。 なじみのあるユーザーは正常にサインインできますが、不明な場所からの要求はブロックされます。
ESL を有効にする前に、ADFSArtifactStore のサイズを見積もることはできますか?
ESL を有効にすると、AD FS では、ADFSArtifactStore データベースでユーザーのアカウント アクティビティと既知の場所が追跡されます。 このデータベースのサイズは、追跡されるユーザーと既知の場所の数に比例してスケーリングされます。 ESL の有効化を計画するとき、ADFSArtifactStore データベースのサイズは、10 万ユーザーあたり最大 1 GB の割合で増加すると見積もることができます。 AD FS ファームで Windows Internal Database (WID) が使用されている場合、データベース ファイルの既定の場所は C:\Windows\WID\Data です。 このドライブがいっぱいにならないよう、ESL を有効にする前に、少なくとも 5 GB の空き記憶域があることを確認してください。 ESL を有効にした後は、ディスク記憶域に加えて、プロセス メモリの総量も、50 万人以下のユーザーに対して、最大 1 GB の RAM が増加するものとして計画します。