仮想アカウント
パスワード管理が不要で、コンピューターアカウントの資格情報でネットワークにアクセスしながらサービス単位でACLを付与できるサービス実行アカウント。
NT SERVICE\サービス名
gMSA(group Managed Service Account)
パスワードの自動生成・自動更新とSPN管理の簡素化を提供するActive Directoryドメインのサービスアカウント。ドメインコントローラー側のKDSルートキーの準備を前提とする。
グループ管理サービスアカウント
SCM(サービス制御マネージャー)
サービスの起動時に実行アカウントでログオンさせる、Windowsのサービス管理コンポーネント。
「サービスとしてログオン」権利
セキュリティプリンシパルがサービスとしてプロセスを実行できるようにするユーザー権利。
LocalSystemアカウント
サービスの実行アカウントの1つ。ローカルでは広範な特権を持つ一方、ネットワーク上ではコンピューターの資格情報としてリモートサーバーに認証される。
管理者権限
コンピューター全体の設定を変更できる権限。
昇格
LocalService / NetworkService
ローカル権限を最小に抑えた組み込みのサービスアカウント。リモートに対してLocalServiceは匿名、NetworkServiceはコンピューターアカウントとして見える。
サービス個別のネットワーク身元
リモートのリソースに対して、同一マシン上の個々のサービスを別々のアカウントとして識別・認可できること。
コンピューターアカウント(PC$)
ドメイン参加マシンがActive Directory上に持つアカウント。LocalSystem・NetworkService・仮想アカウントで動くサービスは、この身元でリモートのリソースへ認証される。
ワークグループ構成
Active Directoryドメインに参加しない、Kerberosの土俵にないWindowsのネットワーク構成。この構成のシステムのWindows認証には依然としてNTLMが使われ、使われなければならない。
ドメインユーザーのサービスアカウント
サービスの実行アカウントとして割り当てられたドメイン(またはローカル)のユーザーアカウント。SCMがパスワードを保存し、起動のたびにログオンに使う。
Kerberoasting
SPNが登録されたアカウントへのサービスチケットを認証済みユーザーとして要求し、オフラインでパスワードの総当たりを試みる攻撃。
SPN(サービスプリンシパル名)
Kerberos認証を受けるサービスが実行アカウントに登録する名前。
Kerberos
チケットによる一度だけの本人確認と相互認証を提供する認証プロトコル。Windows ServerはKerberos version 5と、公開鍵認証・認可データの転送・委任のための拡張を実装する。
Kerberos認証
KDSルートキー
gMSAのパスワード計算の元になる、キー配布サービスのルートキー。作成は1回だけだが、全ドメインコントローラーへの複製を待つ必要がある。
ドメイン機能レベル(DFL)
ドメイン内のドメインコントローラーに要求するWindows Serverの世代を示す設定値。利用できるActive Directoryの機能の範囲を決める。
ドメインコントローラー
Active Directoryのディレクトリサービスを提供し、KDCの機能やNTLMのパススルー認証の相手を担うサーバー。
パスワード入力を前提とするアプリ
実行アカウントの構成に任せず、アプリ自身が資格情報のパスワード入力・保存を要求する作りのソフトウェア。
イベント4624(ログオン成功)
アカウントが正常にログオンしたときに記録される監査イベント。
サービスはユーザーアカウントのセキュリティコンテキストで実行され、SCMが起動時にそのアカウントでログオンさせる。「サービスとしてログオン」権利はセキュリティプリンシパルがサービスとしてプロセスを実行できるようにする。
LocalSystemのトークンにはNT AUTHORITY\SYSTEMとBUILTIN\AdministratorsのSIDが含まれ、ローカルコンピューター上で広範な特権を持つ。sc.exeでサービスの実行アカウントを指定するobj=パラメーターの既定値がLocalSystemであることが、安易な選択の温床になる。
ローカル権限はどちらも最小で、リモートに対してLocalServiceは匿名、NetworkServiceはコンピューターアカウントとして見える。SYSTEMはNTFSボリューム上で既定でフルコントロールを持つのに対し、最小権限の組み込みアカウントはそこが違う。
仮想アカウントは自動的に管理されて作成もパスワード設定も不要という長所を保ったまま、サービス1つにつき固有の身元を持つのでアカウント共有による分離不能という短所を解消する。SQL Serverの既定のサービスアカウントもこれである。
仮想アカウントの身元はマシンローカルで、ネットワーク上ではコンピューターアカウントに縮退する。ドメインのリソースへはその身元でアクセスできるが、リモート側からどのサービスかを区別できず、複数サーバーで同じ身元を共有することもできない。
ドメイン参加マシンでは、LocalSystem・NetworkService・仮想アカウントで動くサービスがリモートのリソースへアクセスするとき、DOMAIN\コンピューター名$として認証される。接続先のACLにPC$を付与すれば、ドメインユーザーを使わずに済むケースは多い。
コンピューターアカウントはActive Directoryのオブジェクトなので、ドメインに参加していないマシンには存在しない。接続先の資格情報を明示的に扱う設計が必要になる。
SCMがパスワードを保存して起動のたびにログオンに使うが、期限は管理してくれない。パスワードが期限切れになるとログオンが失敗し、サービスは起動しなくなる。
Kerberos認証を受けるサービスは実行アカウントにSPNを登録し、ドメインの任意の認証済みユーザーがそのアカウントへのサービスチケットを要求できる。人間が決めた10〜16文字程度のパスワードは、取得したチケットへのオフライン総当たりに耐えられない。
SPNはKerberos認証を受けるサービスが実行アカウントに登録する名前で、サービスチケットの宛先を特定する。
攻撃の起点はSPNが登録されたアカウントで、SPNがなければサービスチケットの要求対象にならない。
gMSAのパスワードは240バイトのランダム生成で総当たり・辞書攻撃を受けにくい。実効性のある対策はパスワードを人間が推測・解読できない強度にすることで、マイクロソフトも長いパスワードの強制とgMSAの利用を挙げている。
既定30日ごとの自動ローテーションで人間が変更を計画する必要も、サービスを止める必要もなくなる。複数サーバーで同じ身元を共有でき、SPNの登録・管理も簡素化できる。
パスワードはKDSのルートキーからドメインコントローラーが計算し、許可されたホストだけが取得する。KDSルートキーの作成は1回だけの作業だが、全ドメインコントローラーへの複製を待つため作成から最大10時間はgMSAを作成できない。
gMSAにはActive Directoryドメイン環境であること、ドメインとフォレストの機能レベルがWindows Server 2012以上であること、gMSA名がフォレスト内で一意であることが要る。パスワード変更間隔は作成時にしか設定できない。
ルートキーはドメインコントローラーが保持し、そこからgMSAのパスワードを計算する。
gMSAはWindowsサービス・IISアプリケーションプール・タスクスケジューラのタスクなど、標準の仕組みでログオン身元を構成するものには広く対応するが、アプリが内部でパスワードを要求する作りだと使えない。フェールオーバークラスタリング自体もgMSAをサポートしないなどの制約があるため、本番投入前にテスト環境で動作を確認する。
ドメインユーザーを使わざるを得ない場合の緩和策として、対話型ログオンとリモートデスクトップを拒否し、「サービスとしてログオン」だけを許可する。
現状の棚卸しは、サービス一覧の実行アカウントと、ログオンタイプ5で記録されるイベント4624で確認できる。