この記事では、Windows でローカル アカウントのリモート使用をブロックする方法について説明します。
元の製品バージョン: SQL Server 2016 Developer、SQL Server 2016 Enterprise、SQL Server 2016 Enterprise Core
元の KB 番号: 4488256
まとめ
Active Directory 環境でリモート アクセスにローカル アカウントを使用すると、いくつかの異なる問題が発生する可能性があります。 最も重大な問題は、管理ローカル アカウントのユーザー名とパスワードが複数のデバイスで同じである場合に発生します。 そのグループ内の 1 つのデバイスで管理者権限を持つ攻撃者は、ローカルのセキュリティ アカウント マネージャー (SAM) データベースのアカウント パスワード ハッシュを使用して、"ハッシュを渡す" 手法を使用するグループ内の他のデバイスに対する管理者権限を取得できます。
詳細
最新のセキュリティ ガイダンスでは、Windows の新機能を利用してローカル アカウントによるリモート ログオンをブロックすることで、これらの問題に対応しています。 Windows 8.1 および Windows Server 2012 R2 では、次のセキュリティ識別子 (SID) が導入されました。
S-1-5-113: NT AUTHORITY\Local account
S-1-5-114: NT AUTHORITY\Local アカウントと Administrators グループのメンバー
これらの SID は、Windows 7、Windows 8、Windows Server 2008 R2、および Windows Server 2012 でも、更新プログラムをインストールした後に定義されます Microsoft セキュリティ アドバイザリ: 資格情報の保護と管理を強化するための更新プログラム: 2014 年 5 月 13 日。
認証されているユーザー アカウントがローカル アカウントの場合、ログオン時に最初の SID がユーザー アクセス トークンに追加されます。 ローカル アカウントが組み込みの Administrators グループのメンバーである場合、2 番目の SID もトークンに追加されます。
これらの SID は、すべてのローカル アカウントまたはすべての管理ローカル アカウントへのアクセスを許可または拒否できます。 たとえば、グループ ポリシーのユーザー権利の割り当てでこれらの SID を使用して、"ネットワークからこのコンピューターへのアクセスを拒否する" および "リモート デスクトップ サービス経由のログオンを拒否する" ことができます。これは、最新のセキュリティ ガイダンスで推奨されるプラクティスです。 これらの新しい SID が定義される前に同じ効果を得るには、制限する各ローカル アカウントに明示的に名前を付ける必要がありました。
Windows 8.1 および Windows Server 2012 R2 ガイダンスの最初のリリースでは、すべての Windows クライアントとサーバーの構成について、ローカル アカウント (S-1-5-113) へのネットワークおよびリモート デスクトップ ログオンを拒否しました。 これにより、すべてのローカル アカウントのすべてのリモート アクセスがブロックされます。
フェールオーバー クラスタリングがクラスター ノード管理に非管理者ローカル アカウント (CLIUSR) に依存していることと、そのネットワーク ログオン アクセスをブロックするとクラスター サービスが失敗することがわかりました。 CLIUSR アカウントは Administrators グループのメンバーではないので、[ネットワークからこのコンピューターへのアクセスを拒否する] 設定で S-1-5-113 を S-1-5-114 に置き換えると、クラスター サービスが正常に動作します。 これは、管理ローカル アカウントへのネットワーク ログオンを拒否することで、"ハッシュを渡す" 種類の攻撃に対する保護を提供しながら、これを行います。
ガイダンスを変更せずに、フェールオーバー クラスターのシナリオ用の "特殊なケース" 脚注を追加することもできますが、代わりに、次の表に示すように、展開を簡略化し、Windows Server 2012 R2 メンバー サーバーのベースラインを変更することを選択しました。
| ポリシー パス | Computer Configuration\Windows Settings\Local Policies\User Rights Assignment |
|---|---|
| ポリシー名 | ネットワークからこのコンピューターへのアクセスを拒否 |
| 元の値 | ゲスト、ローカル アカウント* |
| 新しい値 | ゲスト、ローカル アカウント、および Administrators グループのメンバー* |
- このガイダンスでは、これらの制限にドメイン管理者 (DA) とエンタープライズ管理者 (EA) を追加することもお勧めします。 例外は、ドメイン コントローラーと専用の管理ワークステーションにあります。 DA と EA はドメイン固有であり、汎用グループ ポリシー オブジェクト (GPO) ベースラインでは指定できません。
Note
この変更は、メンバー サーバーのベースラインにのみ適用されます。 リモート デスクトップ ログオンの制限は変更されていません。 組織は、非クラスター化サーバーのローカル アカウントへのネットワーク アクセスを拒否することもできます。
ローカル アカウントの制限は、Active Directory ドメインに参加しているシステムを対象としています。 参加していないワークグループ Windows デバイスは、ドメイン アカウントを認証できません。 そのため、これらのデバイスでのローカル アカウントのリモート使用に対して制限を適用すると、コンソールでのみログオンできます。
CLIUSR アカウントの詳細
CLIUSR アカウントは、機能が Windows Server 2012 以降のバージョンにインストールされている場合にフェールオーバー クラスタリング機能によって作成されるローカル ユーザー アカウントです。
Windows Server 2003 以前のバージョンのクラスター サービスでは、ドメイン ユーザー アカウントを使用してサービスを開始しました。 このクラスター サービス アカウント (CSA) は、クラスターの形成、ノードの参加、レジストリ レプリケーションなどを行うために使用されました。 基本的に、ノード間で行われたあらゆる種類の認証では、このユーザー アカウントが共通の ID として使用されます。
ドメイン管理者が、ドメイン ユーザー アカウントからアクセス許可を削除するグループ ポリシー ポリシーを設定していたため、いくつかのサポートの問題が発生しました。 管理者は、これらのユーザー アカウントの一部がサービスの実行に使用されたことを考慮していません。
たとえば、この問題は、サービスとしてのログオン権限の使用で発生しました。 クラスター サービス アカウントにこのアクセス許可がない場合は、クラスター サービスを開始できませんでした。 複数のクラスターに同じアカウントを使用していた場合、複数の重要なシステムで運用ダウンタイムが発生する可能性があります。 また、Active Directory でのパスワードの変更にも対処する必要がありました。 Active Directory でユーザー アカウントのパスワードを変更した場合は、そのアカウントを使用するすべてのクラスターとノードでパスワードを変更する必要がありました。
Windows Server 2008 では、サービスの回復性を高め、エラーが発生しやすく、管理しやすくするために、サービスを開始する方法に関するすべてを再設計しました。 組み込みのネットワーク サービスを使用してクラスター サービスを開始しました。 これは完全なアカウントではなく、縮小された特権セットであることに注意してください。 このアカウントの範囲を減らすことで、グループ ポリシーの問題の解決策が見つかりました。
認証の場合、アカウントは、共通 ID のクラスター名オブジェクト (CNO) と呼ばれるクラスター名に関連付けられているコンピューター オブジェクトを使用するように切り替えました。 この CNO はドメイン内のコンピューター アカウントであるため、ドメイン ポリシーで定義されているように、パスワードが自動的にローテーションされます。 (既定では、これは 30 日ごとです)。
Windows Server 2008 R2 以降、管理者はデータセンター内のすべてを仮想化し始めました。 これにはドメイン コントローラーが含まれます。 クラスター共有ボリューム (CSV) 機能も導入され、プライベート クラウド ストレージの標準になりました。 一部の管理者は仮想化を採用し、データセンター内のすべてのサーバーを仮想化しました。 これには、ドメイン コントローラーを仮想マシンとしてクラスターに追加し、CSV ドライブを使用して VM の VHD/VHDX を保持することが含まれます。
これにより、多くの企業に "Catch 22" シナリオが作成されました。 VM にアクセスするために CSV ドライブをマウントするには、ドメイン コントローラーに連絡して CNO を取得する必要がありました。 ただし、ドメイン コントローラーが CSV で実行されていたため、起動できませんでした。
ドメイン コントローラーへの接続が遅いか信頼性が低いと、CSV ドライブへの I/O にも影響します。 CSV は、ファイル共有への接続と同様に、SMB を介したクラスター内通信を行います。 SMB に接続するには、接続を認証する必要があります。 Windows Server 2008 R2 では、リモート ドメイン コントローラーを使用して CNO を認証する必要がありました。
Windows Server 2012 では、両方の世界を最大限に活用し、発生していたいくつかの問題を回避する方法について考える必要がありました。 引き続き、削減されたネットワーク サービス ユーザー権限を使用してクラスター サービスを開始しています。 ただし、すべての外部依存関係を削除するために、ノード間の認証にローカル (ドメイン以外) ユーザー アカウントを使用するようになりました。
このローカル "ユーザー" アカウントは、管理アカウントまたはドメイン アカウントではありません。 このアカウントは、クラスターの作成時に各ノード、または既存のクラスターに追加される新しいノードに自動的に作成されます。 このアカウントは、クラスター サービスによって自己管理されます。 アカウントのパスワードが自動的にローテーションされ、すべてのノードが自動的に同期されます。 CLIUSR パスワードは、ドメイン ポリシーで定義されている CNO と同じ頻度でローテーションされます。 (既定では、これは 30 日ごとです)。アカウントはローカルであるため、仮想化されたドメイン コントローラーが正常に起動できるように、CSV を認証してマウントできます。 すべてのドメイン コントローラーを恐れずに仮想化できるようになりました。 そのため、外部の依存関係を減らすことで、クラスターの回復性と可用性を高めます。
このアカウントは CLIUSR アカウントです。 これは、コンピューター管理スナップインの説明によって識別されます。
よく寄せられる質問は、CLIUSR アカウントを削除できるかどうかです。 セキュリティの観点からは、監査中に追加のローカル アカウント (既定ではない) にフラグが設定される場合があります。 ネットワーク管理者が、このアカウントの目的が不明な場合 (つまり、"フェールオーバー クラスター ローカル ID" の説明を読まない) 場合、影響を理解せずに削除する可能性があります。 フェールオーバー クラスタリングが正しく機能するためには、このアカウントが認証に必要です。
結合ノードはクラスター サービスを開始し、CLIUSR 資格情報を渡します。
同じ効果を得るために、ノードが参加できるように、すべての資格情報が渡されます。
継続的な成功を確実にするために、もう 1 つのセーフガードを提供しました。 CLIUSR アカウントを誤って削除した場合、ノードがクラスターに参加しようとしたときに自動的に再作成されます。
要約すると、CLIUSR アカウントはクラスター サービスの内部コンポーネントです。 構成または管理する必要がないように、自己管理です。
Windows Server 2016 では、証明書を利用してクラスターを外部の依存関係なしで動作できるようにすることで、さらに 1 歩進みました。 これにより、異なるドメインまたはすべてのドメインの外部にあるサーバーを使用してクラスターを作成できます。