Microsoft アカウントでサインイン
サインインするか、アカウントを作成します。
こんにちは、
Select a different account.
複数のアカウントがあります
サインインに使用するアカウントを選択してください。

概要

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 account および管理者グループのメンバー

これらの SID は、 更新プログラム KB 2871997をインストールした後、Windows 7、Windows 8、Windows Server 2008 R2 および Windows Server 2012 でも定義されます。

認証されるユーザー アカウントがローカル アカウントの場合、最初の SID はログオン時にユーザー アクセス トークンに追加されます。 ローカル アカウントがビルトイン管理者グループのメンバーである場合は、2 番目の SID もトークンに追加されます。

これらの SID は、すべてのローカル アカウントまたはすべての管理ローカル アカウントへのアクセスを許可または拒否できます。 たとえば、グループ ポリシーのユーザー権利の割り当てでこれらの ID を使用して、"ネットワーク経由でこのコンピュータへのアクセスを拒否する" および "リモート デスクトップ サービス経由のログオンを拒否する" ことができます。 これは、最新のセキュリティ ガイダンスで推奨される方法です。 これらの新しい SID が定義される前に同じ効果を実現するには、制限する各ローカル アカウントに明示的に名前を付ける必要がありました。

Windows 8.1 および Windows Server 2012 R2 ガイダンスの最初のリリースでは、すべての Windows クライアントとサーバーの構成について、ネットワークとリモート デスクトップの "ローカル アカウント" (S-1-5-113) へのログオンを拒否しました。 これにより、すべてのローカル アカウントのすべてのリモート アクセスがブロックされます。

フェールオーバー クラスタリングがクラスタ ノード管理に非管理者ローカル アカウント (CLIUSR) に依存し、ネットワーク ログオン アクセスをブロックするとクラスタ サービスが失敗する可能性が再びわかりました。 CLIUSR アカウントは管理者グループのメンバーではないため、[ネットワークからこのコンピュータへのアクセスを拒否する] 設定で S-1-5-113 を S-1-5-114 に置き換えると、クラスタ サービスが正しく動作します。 これは、管理ローカル アカウントへのネットワーク ログオンを拒否することによって、"ハッシュを渡す" 種類の攻撃に対する保護を提供しながら行われます。

ガイダンスを変更せずにフェールオーバー クラスターシナリオの "特殊なケース" 脚注を追加することもできますが、次の表に示すように、展開を簡略化し、Windows Server 2012 R2 メンバー サーバーのベースラインを変更することを選択しました。

ポリシー パス

Computer Configuration\Windows Settings\Local Policies\User Rights Assignment

ポリシー名

ネットワーク経由でのコンピューターへのアクセスの拒否

元の値

ゲスト、ローカル アカウント*

新しい値

ゲスト、ローカル アカウントおよび管理者グループのメンバー*


このガイダンスでは、これらの制限にドメイン管理者 (DA) とエンタープライズ管理者 (EA) を追加することもお勧めします。 ただし、ドメイン コントローラと専用の管理ワークステーションは例外です。 DA と EA はドメイン固有であり、汎用グループ ポリシー オブジェクト (GPO) ベースラインで指定することはできません

注意事項

  • この変更は、メンバ サーバーのベースラインにのみ適用されます。 リモート デスクトップ ログオンの制限は変更されていません。 組織は、クラスタ化されていないサーバーの "ローカル アカウント" へのネットワーク アクセスを拒否することもできます。

  • ローカル アカウントの制限は、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" シナリオが作成されました。 CSV ドライブをマウントして VM にアクセスするには、ドメイン コントローラーに接続して CNO を使用する必要がありました。 ただし、ドメイン コントローラは CSV で実行されていたため、起動できませんでした。

ドメイン コントローラへの接続が遅いか信頼性が低い場合は、CSV ドライブへの I/O にも影響します。 CSV は、ファイル共有への接続と同様に、SMB を介したクラスター内通信を行います。 SMB に接続するには、接続を認証する必要があります。 Windows Server 2008 R2 では、リモート ドメイン コント ローラーを使用して CNO の認証を含む。

Windows Server 2012 では、両方の世界を最大限に活用し、発生しているいくつかの問題を回避する方法を考える必要がありました。 クラスタ サービスを開始するには、削減されたネットワーク サービス ユーザー権利を引き続き使用しています。 ただし、すべての外部依存関係を削除するために、ノード間の認証にローカル (非ドメイン) ユーザー アカウントを使用するようになりました。

このローカルの "ユーザー" アカウントは、管理者アカウントまたはドメイン アカウントではありません。 このアカウントは、クラスターの作成時に各ノード、または既存のクラスターに追加される新しいノードに自動的に作成されます。 このアカウントは、クラスタ サービスによって完全に自己管理されます。 アカウントのパスワードが自動的にローテーションされ、すべてのノードが自動的に同期されます。 CLIUSR パスワードは、ドメイン ポリシーで定義されている CNO と同じ頻度でローテーションされます。 (既定では、これは 30 日ごとです)。 アカウントはローカルであるため、仮想化されたドメイン コントローラーを正常に起動できるように CSV を認証してマウントできます。 すべてのドメイン コントローラーを恐れずに仮想化できるようになりました。 したがって、外部の依存関係を減らすことで、クラスターの回復性と可用性を向上させます。

このアカウントは CLIUSR アカウントです。 これは、[コンピューターの管理] スナップインの説明によって識別されます。

CLIUSR アカウント

よくある質問は、CLIUSR アカウントを削除できるかどうかです。 セキュリティの観点からは、監査中に追加のローカル アカウント (既定ではない) にフラグが設定される場合があります。 ネットワーク管理者がこのアカウントの目的が不明な場合 (つまり、"フェールオーバー クラスター ローカル ID" の説明を読んでいない場合)、影響を理解せずにアカウントを削除する可能性があります。 フェールオーバー クラスタリングが正しく機能するには、このアカウントが認証に必要です。

CLIUSR の資格情報を渡す

1) 参加ノードはクラスタ サービスを開始し、CLIUSR 資格情報を渡します。

2) 同じ効果を得るために、ノードが参加できるように ll 資格情報が渡されます。

我々は継続的な成功を確実にするために、もう一つの安全装置を提供しました。 CLIUSR アカウントを誤って削除した場合、ノードがクラスタに参加しようとすると、CLIUSR アカウントが自動的に再作成されます。

要約すると、次のようになります。 CLIUSR アカウントは、クラスタ サービスの内部コンポーネントです。 構成や管理が不要なため、完全に自己管理できます。

Windows Server 2016 では、証明書を利用して、外部依存関係なしでクラスターを動作させることで、さらに一歩進んでいきました。 これにより、異なるドメインまたはすべてのドメインの外部にあるサーバーを使用してクラスターを作成できます。

ヘルプを表示

スキルを磨く
トレーニングの探索
新機能を最初に入手
Microsoft Insider に参加する

この情報は役に立ちましたか?

言語の品質にどの程度満足していますか?
どのような要因がお客様の操作性に影響しましたか?

ご意見をいただきありがとうございます。

×