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

適用対象

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

注意

Windows Server 2019 のキー信頼に問題がありました。 問題を解決するには、「 KB4487044」を参照してください。

適切な数

必要なドメイン コントローラーの数はどのように判断すればよいでしょうか。 ドメイン コントローラーのパフォーマンス監視機能を使用すると、既存の認証トラフィックを確認できます。 Windows Server 2016 以降には、KDC が要求パフォーマンスカウンターとして含まれています。 このカウンターを使用して、最初の 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 2008R2) ことができない管理者の多くは、Windows Server 2012R2) を使うと、1つのドメインコントローラーで最も多くの負荷がかかるか、一般的には "蓄積 on" と呼ばれるものになります。 "蓄積 on" の概念を示すために、次のシナリオについて考えてみます。

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

dc-chart1

この環境が変化します。 最初の変更には、windows Server 2016 以降にアップグレードされた DC1 が含まれています。これにより、Windows Hello for Business キー信頼認証がサポートされます。 次に、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 2019 ドメインコントローラーでも、この負荷の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 用にプロビジョニングされたクライアントの合理的な配分と組み合わせて、最初のドメイン コントローラーのアップグレード候補として識別します。

認証の監視

上記と同じ方法を使用して、ドメインコントローラーをアップグレードした後で Kerberos 認証を監視し、Windows Hello for Business 展開の最初のフェーズを監視します。 ドメインコントローラーを Windows Server 2016 以降にアップグレードする前と後の認証のデルタをメモしておきます。 このデルタは、Windows Hello for Business クライアントの最初のフェーズに起因する認証を表します。 次のようなステートメントを作成できる、環境のベースラインが提供されます。

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

_N_は、Windows Hello for business に切り替えたクライアントの数と_x_は、アップグレードされたドメインコントローラーからの認証率の増加率に等しいものです。 この情報を用意することで、ドメインコントローラーのアップグレードの観察を適用し、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 クエリごとにこれをラウンド ロビン方式で割り当てます。 これは最善のロード バランサーではありませんが、この構成がサービスやアプリケーションと互換性がある場合は、静的なドメイン コントローラーの構成よりも優れた代替構成です。