Windows Hello for Business 展開用の適切な数の Windows Server 2016 ドメイン コントローラーの計画

適用対象

  • Windows 10、バージョン 1702 以降
  • ハイブリッド展開またはオンプレミス展開
  • キー信頼

適切な数

必要なドメイン コントローラーの数はどのように判断すればよいでしょうか。 ドメイン コントローラーのパフォーマンス監視機能を使用すると、既存の認証トラフィックを確認できます。 Windows Server 2016 には、KDC AS 要求のパフォーマンス カウンターが含まれています。 これらのカウンターを使用すると、最初の Kerberos 認証によるドメイン コントローラーの負荷の量を確認できます。 Windows Hello for Business のキー信頼の展開の認証は、Kerberos 認証には影響しない (変更されない) ことに留意することが必要です。

Windows 10 では、Active Directory ユーザー アカウントを 1 つまたは複数の公開キーにマッピングすることによって、Windows Hello for Business のキー信頼の認証を実行します。 このマッピングはドメイン コントローラーで行われるため、この展開には Windows Server 2016 ドメイン コントローラーが必要です。 公開キーのマッピングは Windows Server 2016 ドメイン コントローラーでのみサポートされます。 そのため、キー信頼の展開のユーザーは、Windows Server 2016 ドメイン コントローラーで認証する必要があります。

Windows Server 2016 ドメイン コントローラーの適切な数を判断することは、公開キーの信頼でマップされたユーザーを含む、すべての認証要求を満たすために十分なドメイン コントローラーを用意するのに重要です。 多くの管理者が気づいていないことですが、最新バージョンのドメイン コントローラー (ここでは Windows Server 2016) を既存のドメイン コントローラー (Windows Server 2008R2 または Windows Server 2012R2) の展開に追加すると、直ちにその 1 つのドメイン コントローラーに最大限の負荷が集中しやすくなります。これを、一般的に "piling on" (山積み) と呼びます。 "piling on" の概念を示すためには、次のようなシナリオを考えてみてください。

管理された環境に 1,000 台のクライアント コンピューターが存在し、この 1,000 台のクライアント コンピューターの認証の負荷が、環境内の 10 台のドメイン コントローラーに均等に分散されているとします。 Kerberos AS 要求の負荷は、次のようになります。

dc-chart1

この環境が変化します。 最初の変更では、Windows Hello for Business のキー信頼認証をサポートするために、DC1 が Windows Server 2016 にアップグレードされます。 次に、100 台のクライアントが公開キーの信頼の展開を使用して Windows Hello for Business に登録します。 他のすべての要素が変わらない場合、認証は次のようになります。

dc-chart2

Windows Server 2016 ドメイン コントローラーが、すべての公開キー信頼認証の 100% を処理しています。 ただし、パスワード認証の 10% も処理しています。 どうしてでしょうか。 この動作が発生するには、ドメイン コントローラー 2 ~ 10 がパスワードおよび証明書信頼の認証のみをサポートしており、Windows Server 2016 ドメイン コントローラーのみが公開キー信頼の認証をサポートしているためです。 Windows Server 2016 ドメイン コントローラーは、パスワードと証明書信頼の認証も処理できるため、これらのクライアントを認証するための負荷も引き続き共有します。 DC1 はすべての形式の認証を処理できため、より多くの認証の負荷が集中し、過負荷になりやすくなります。 別の Windows Server 2016 ドメイン コントローラーを追加し、他のクライアントには Windows Hello for Business を展開しない場合はどうでしょうか。

dc-chart3

別のドメイン コントローラーを Windows Server 2016 ドメイン コントローラーにアップグレードすると、公開キー信頼の認証は 2 台のドメイン コントローラーに分散され、それぞれが 50% の負荷を処理します。 しかし、パスワードおよび証明書信頼の認証の分散は変更されません。 両方の Windows Server 2016 ドメイン コントローラーは、この負荷の 10% を引き続き共有します。 次に、半分のドメイン コントローラーを Windows Server 2016 にアップグレードし、WHFB クライアントの数は変わらない場合のシナリオを見てみましょう。

dc-chart4

ドメイン コントローラー 1 ~ 5 が公開キー信頼の認証の負荷を共有し、各ドメイン コントローラーは公開キー信頼の負荷の 20% を処理していますが、依然としてそれぞれがパスワードおよび証明書信頼の認証の 10% を処理しています。 これらのドメイン コントローラーはまだドメイン コントローラー 6 ~ 10 よりも負荷が大きくなっていますが、負荷は適切に分散されています。 次に、クライアント コンピューターの半分がキー信頼の展開を使用する Windows Hello for Business にアップグレードしたシナリオを見てみましょう。

dc-chart5

配分は変化していないことがわかります。 Windows Server 2016 ドメイン コントローラーが、それぞれ公開キー信頼の認証の 20% を処理しています。 ただし、(クライアントの数の増加により) 認証の量が増加したため、同じ 20% でも作業の量が増加しています。 前の例では、公開キー信頼の認証の 20% は、公開キー信頼の認証に対応したドメイン コントローラーごとに 20 の認証に相当していました。 しかし、クライアントをアップグレードしたことにより、同じ 20% でも、公開キー信頼に対応したドメイン コントローラーごとに処理する公開キー信頼の認証は 100 になります。 また、公開キー信頼以外の認証の配分は 10% のままですが、以前のドメイン コントローラーではパスワードと証明書信頼の認証の量が減少しています。

ここでいくつかの結論が得られます。

  • ドメイン コントローラーをアップグレードすると、新しい認証の配分は変化しますが、古い認証の配分は変化しません。
  • ドメイン コントローラーをアップグレードしても、パスワードと証明書信頼の認証の配分には影響しません。これは、新しいドメイン コントローラーがパスワードと証明書信頼の認証に対応できるためです。
  • アップグレードされたドメイン コントローラーでは、より多くの形式の認証をサポートするため、通常、ダウンレベルのドメイン コントローラーよりも認証の負荷が大きくなります。
  • クライアントを Windows Hello for Business にアップグレードすると、公開キー信頼の認証をサポートするドメイン コントローラーで分散される公開キー信頼の認証の量は増加し、すべてのドメイン コントローラーでのパスワードと証明書信頼の認証の量は減少します。
  • クライアントを Windows Hello for Business にアップグレードしても、認証の配分には影響しません。認証の量が変化するだけです。

上記の例では、"万能サイズ" の数を示すことが現実的ではない理由を示し、"適切な量" が意味することを説明しました。 実際の環境では、認証はドメイン コントローラー間で均等には分散されません。

AS 要求の負荷の総量を特定する

各組織で、環境内で発生する AS 要求の負荷の基準計画を持つことが必要です。 Windows Server は、これを判断するに役立つ KDC AS 要求のパフォーマンス カウンターを提供します。

Windows Hello for Business の公開キー信頼にクライアントをアップグレードすることを予定しているサイトを選択します。 認証トラフィックが最も多くなる時期を選択します。月曜日の午前中は、すべてのユーザーがいっせいにオフィスに戻ってくるため適しています。 そのサイト内のすべてのドメイン コントローラで、このパフォーマンス カウンターを有効にします。 2 時間分の KDC AS 要求のパフォーマンス カウンターを収集します。

  • 初期認証 (サインインとロック解除) が多いと予測される時間の前の 30 分
  • 初期認証が多いと思われる時間
  • 初期認証が多いと予測される時間の後の 30 分

たとえば、午前 9 時に従業員が出社するようにスケジュールされているとします。 この場合、パフォーマンスのキャプチャーは、午前 8 時 30 分に開始し、午前 10 時 30 分に終了します。 パフォーマンス ログがデータをラップしていないことを確認します。 認証の上昇トレンド、ピーク、下降トレンドを確認できます。

注意

すべての認証トラフィックをキャプチャします。 最も正確な認証情報を取得するために、すべてのコンピューターの電源が切られていることを確認します (コンピューターやサービスは最初に電源を入れたときに認証されます。評価では、この認証を検討する必要があります)。

すべてのドメイン コントローラーのパフォーマンス データを集計します。 各ドメイン コントローラーの KDC AS 要求の最大数を探します。 サイトで最大数の要求が発生した時間の中央値を求めます。これが、サイトで最大量の認証が発生している時間を表します。

中央値の時間の、各ドメイン コントローラーの認証の数を加算します。 これで、ピーク時のサイトの合計認証数が得られました。 このメトリックを使用して、中央値の時間のドメイン コントローラーの認証数を、認証の合計数で割ることによって、ドメイン コントローラー間での認証の配分を決定できます。 この商を 10 倍することで配分をパーセンテージに変換します。 計算を検証するには、すべての配分の合計が 100% になることを確認します。

認証の配分を確認します。 いずれも 70% を超えないことが理想的です。 常に、予期しない事態のために一部の容量を予約することをお勧めします。 また、ドメイン コントローラーの主な目的は認証を提供し、Active Directory の操作を処理することです。 認証の配分の小さいドメイン コントローラーを、Windows Hello for Business 用にプロビジョニングされたクライアントの合理的な配分と組み合わせて、最初のドメイン コントローラーのアップグレード候補として識別します。

認証の監視

前と同じ方法で、ドメイン コントローラーをアップグレードし、Windows Hello for Business の展開の第 1 フェーズの後で、Kerberos 認証を監視します。 ドメイン コントローラーを Windows Server 2016 にアップグレードする前と後のデルタをメモします。 このデルタは、Windows Hello for Business クライアントの最初のフェーズに起因する認証を表します。 これにより、環境の基準計画が決まり、次のように結論付けることができます。

"Every n Windows Hello for Business clients results in x percentage of key-trust authentication."

_ここで n ビジネスおよび_x_向けの Windows こんにちはに切り替えられたクライアントの数_がアップグレードされたドメイン コント ローラーからの認証の増加率に相当します。 この情報を使用して、ドメイン コントローラーをアップグレードと、Windows Hello for Business クライアントの数の増加の観測を、適切なフェーズでの展開に適用できます。

クライアントの数を増やすと、Windows Server 2016 ドメイン コントローラー間で分散される認証の量が変化することに注意してください。 Windows Server 2016 ドメイン コントローラーが 1 台だけである場合、分散は行われず、そのドメイン コントローラーが担当する認証の量が増加するだけです。

ドメイン コントローラーの数を増やすと、認証の量は分散されますが、変化しません。 したがって、複数のドメイン コントローラーを追加すると、各ドメイン コントローラーが担当する認証の負担は減少します。 2 台のドメイン コントローラーをアップグレードすると、配分は 50% に変化します。 3 台のドメイン コントローラーをアップグレードすると、配分は 33% に変化します。以降も同様です。

戦略

最もシンプルな戦略は、1 台のドメイン コントローラーをアップグレードし、そのドメイン コントローラーを監視しながら、70% または 80% のしきい値に達するまで段階的に新しい Windows Hello for Business のキー信頼のクライアントを増やすことです。

次に、2 番目のドメイン コントローラーをアップグレードします。 両方のドメイン コントローラーでの認証を監視し、2 台のドメイン コントローラー間で認証がどのように分散されるかを確認します。 アップグレードした 2 台のドメイン コントローラーで認証を監視しながら、Windows Hello for Business クライアントの数をさらに増やします。 環境で指定されている容量に達したら、別のドメイン コントローラーをアップグレードします。

対象サイトの展開が完了するまでこれを繰り返します。 この時点で、最初に行ったように、すべてのドメイン コントローラーで認証を監視します。 各ドメイン コントローラーの認証の配分を確認します。 各ドメイン コントローラーが担当する配分のパーセンテージを識別します。 1 台のドメイン コントローラーが担当する認証が 70% を超えている場合は、認証の量の配分を減らすために、ドメイン コントローラーの追加を検討します。

ただし、これを検討する前に、認証の負荷が高くなっている原因が、ドメイン コントローラーを静的に構成する構成を持つアプリケーションやサービスではないことを確認します。 このような場合、ドメイン コントローラーを追加しても、認証の負荷が増加する問題は解決されません。 代わりに、すべてのサービスやアプリケーションの認証を手動で別のドメイン コントローラーに配分します。 または、特定のドメイン コントローラーではなく、単にドメイン名を使用します。 各ドメイン コントローラーは、ドメイン名の DNS 登録された A レコードを持っており、DNS は DNS クエリごとにこれをラウンド ロビン方式で割り当てます。 これは最善のロード バランサーではありませんが、この構成がサービスやアプリケーションと互換性がある場合は、静的なドメイン コントローラーの構成よりも優れた代替構成です。