マシン SID の重複神話

更新日: 2011 年 1 月 18 日

2009 年 11 月 3 日、Sysinternals は、コンピューターのセキュリティ識別子 (マシン SID) を変更するユーティリティ NewSID を提供停止することに決定しました。私が NewSID を作成したのは 1997 年でした (当初の名前は NTSID)。当時、マシン SID を変更できるツールはマイクロソフトの Sysprep ツールしかなく、さらに Sysprep は、アプリケーションがインストールされているコンピューターの SID を変更できなかったからです。マシン SID は、Windows セットアップによって生成される一意の識別子です。Windows は、管理者定義のローカル アカウント/グループの SID のベースとして、このマシン SID を使用します。システムにログオンしたユーザーは、オブジェクト承認 (アクセス許可チェック) に関しては、各自のアカウント SID やグループ SID に基づいて表されます。2 つのマシンが同じマシン SID を持つ場合は、これらのシステム内のアカウントやグループも同じ SID を持つ可能性があります。このため、1 つのネットワーク上に同じマシン SID を持つコンピューターが複数あれば、セキュリティ リスクが存在することは明らかです。少なくとも、これが世間の常識でした。

NewSID の提供停止を考え始めたのは、Windows Vista では正常に機能したという報告も多くありましたが、私自身も NewSID を完全にテストしていたわけではなく、特定の Windows コンポーネントが NewSID の使用後に失敗するという報告をいくつか受けたことが理由です。これらの報告の調査を開始する際に、私は、重複 SID が問題を起こす可能性があるという皆さんと同様の信念を一歩下がって疑ってみました。そして、考えれば考えるほど、マシン SID の重複、つまり複数のコンピューターで同じマシン SID を使用することが、セキュリティなどの面で問題を引き起こすことはないと確信するようになりました。私は、Windows のセキュリティ チームと展開チームにこのことを伝えましたが、ワークグループ内であろうとドメイン内であろうと、同じマシン SID を使用する 2 つのシステムで問題が発生するという状況を思い付く人は誰もいませんでした。この時点で、NewSID を提供停止する決意が固まってきました。

マシン SID が重複していてもかまわないというニュースは、多くのユーザーにとって驚きでした。特に、Windows NT の導入以降、イメージ化されたシステムで SID を変更することはイメージ展開の原則であったからです。このブログでは、最初にマシン SID について説明し、Windows がどのように SID を使用するかを解説します。その後、1 つの例外を除いて、Windows はマシン SID をそのコンピューターの外部に公開することはなく、複数のシステムで同じマシン SID を使用できることを証明し、この神話の正体を暴きます。

SID

Windows は、SID を使用して、マシンだけではなく、すべてのセキュリティ プリンシパルを表します。セキュリティ プリンシパルには、マシン、ドメイン コンピューター アカウント、ユーザー、セキュリティ グループなどがあります。名前は、SID をユーザーにわかりやすく表現したものです。これにより、アカウントを参照するアクセス コントロール リスト (ACL) を更新しなくも、アカウントの名前を変更することができます。SID は、構造体リビジョン番号、48 ビットの識別子機関値、および 32 ビットのサブ機関変数または相対識別子 (RID) で構成される可変長の数値です。機関値は、SID を発行したエージェントを識別します。通常、このエージェントは Windows ローカル システムまたはドメインです。サブ機関値は、発行機関に対するトラスティを識別します。RID は、Windows が共通のベース SID に基づいて一意の SID を作成する方法です。

Sysinternals の PsGetSid (英語) ツールをコマンドライン引数なしで実行すると、マシンの SID を表示できます。

図 1

ここで、リビジョン番号は 1、機関は 5 で、4 つのサブ機関値があります。Windows NT の設計時点では、マシン SID がネットワークの識別に使用されていた可能性があります。したがって、一意性を確保するため、セットアップが生成する SID には、1 つの固定サブ機関値 (21) と、ランダムに生成された 3 つのサブ機関値 (出力の "S-1-5-21" より後の数値) があります。 

システムで最初のユーザー アカウントを作成する前に、Windows には、Administrator アカウントや Guest アカウントなどの組み込みのユーザーとグループがいくつか定義されています。Windows は、これらのアカウントに対して新しいランダム SID を生成するのではなく、マシン SID に相対識別子 (RID) というアカウントごとに一意の数値を追加することで一意性を確保します。これらの初期アカウントの RID は事前に定義されており、Administrator ユーザーの RID は常に 500 です。

図 2

インストール後、Windows は、新しいローカル ユーザーやグループ アカウントに 1000 で始まる RID を割り当てます。PsGetSid を使用すると、特定の SID に対応するアカウント名を表示できます。次の図で、RID が 1000 のローカル SID は、Abby のアカウントであることがわかります。これは、セットアップ時に Windows から名前を付けるように指示された管理者アカウントの名前です。

図 3

これらの動的に作成される SID に加えて、Windows には、RID だけではなく常に SID 全体が事前に定義されているアカウントがいくつか定義されています。例として、Everyone グループの SID はどの Windows システムでも S-1-1-0 です。

図 4

別の例として、ローカル システム アカウント (System) があります。これは、セッション マネージャー (Smss.exe)、サービス コントロール マネージャー (Services.exe)、Winlogon (Winlogon.exe) などのシステム プロセスが実行されるアカウントです。

図 5

ドメインに参加しているコンピューターは、ドメインの SID に基づくコンピューター ドメイン SID も持ちます。次の図では、PsGetSid が NTDEV ドメインのドメイン SID を表示しています。

図 6

コンピューター アカウントのドメイン SID は、次のように、コンピューター名に "$" を追加することで表示できます。

図 7

私のコンピューターのドメイン SID の SID は、このドメイン SID と RID 3858199 で構成されています。同じドメイン SID を持つコンピューターの重複は、当然問題があります。また、コンピューターの名前を変更するだけでは、マシン SID またはコンピューター ドメイン SID のいずれにも影響しません。ドメインに参加しているコンピューターを複製する場合、それに一意のドメイン アカウントを提供するには、ドメインへの参加を解除し、コンピューター名を変更してから、再度ドメインに参加するしかありません。

SID とアクセス コントロール リスト

あるアカウントが Windows システムにログオンすると、ローカル セキュリティ機関サブシステム (LSASS -Llsass.exe) がログオン セッションと、そのセッションのためのトークンを作成します。トークンは、アカウントを表すために Windows カーネルが定義するデータ構造です。トークンには、アカウントの SID、認証時にアカウントが属しているグループの SID、さらにアカウントと上記のグループに割り当てられているセキュリティ権限が含まれます。あるログオン セッションを参照する最後のトークンが削除されると、LSASS はそのログオン セッションを削除し、ユーザーはログオフしたと見なされます。次の図では、Sysinternals の LogonSessions (英語) ユーティリティを使用して表示された私の対話型ログオン セッションを確認できます。

図 8

次の図では、Process Explorer のハンドル ビューで、Lsass がこのセッションのために作成したトークンを確認できます。アカウント名の後の数値 7fdee が、LogonSessions に表示されたログオン セッション ID と一致していることがわかります。

図 9

既定では、プロセスはその親プロセスのトークンのコピーを継承します。たとえば、私の対話型セッションで実行されているすべてのプロセスは、Userinit.exe プロセスから継承されたトークンのコピーを持ちます。Userinit.exe プロセスは、Winlogon がどの対話型ログオンにおいても最初に作成するプロセスだからです。プロセスのトークンの内容を確認するには、Process Explorer で、プロセスをダブルクリックし、プロセス プロパティ ダイアログの [Security] ページに切り替えます。

図 10

私のプロセスの 1 つがファイルやレジストリ キーと同様にオペレーティング システム オブジェクトを開くと、セキュリティ サブシステムはアクセス許可チェックを行って、プロセスのトークンに含まれる SID を参照する、オブジェクトのアクセス コントロール リスト (ACL) 内のエントリを評価します。

リモート コンピューターの共有の "net use" によってリモート ログオン セッションが作成されますが、このリモート ログオン セッションにも同様のチェックが実行されます。共有に正しく接続するには、そのリモート システムに既知のアカウントを使用してシステムに認証される必要があります。コンピューターがワークグループに含まれる場合は、リモート システムのローカル アカウントの資格情報を指定する必要があります。ドメインに参加しているシステムの場合は、リモート システムのローカル アカウントまたはドメイン アカウントの資格情報を指定できます。共有内のファイルにアクセスすると、そのシステムにあるファイル サーバー ドライバーは、偽装と呼ばれるメカニズムを利用し、ログオン セッションに基づくトークンを使用してアクセス許可チェックを行います。

SID の重複

コンピューター グループへの展開用として準備された Windows インストールを作成するためにマイクロソフトがサポートする方法は、Windows を参照コンピューターにインストールし、Sysprep ツールを実行して複製用のシステムを準備することです。このプロセスはイメージの一般化と呼ばれ、このプロセスを使用して作成されたイメージを起動すると、Sysprep がインストールを個別化します。Sysprep は、個別化の際に、新しいマシン SID を生成し、プラグ アンド プレイ ハードウェア検出を実行し、製品のライセンス認証タイマーをリセットし、新しいコンピューター名などの構成データを設定します。

ただし、一部の IT 管理者は、Windows をシステムの 1 つにインストールし、アプリケーションをインストールおよび設定してから、Windows インストールのコピーの SID をリセットしない展開ツールを使用しています。これまでのベスト プラクティスは、NewSID などの SID リセット ユーティリティを実行して SID を変更することでした。そのようなユーティリティは、新しいマシン SID を生成してから、マシン SID を含むすべての場所をシステム内から (すべてのファイル システムとレジストリ ACL を含む) 検索して、それらを新しい SID に更新します。マイクロソフトがこの方法で変更されたシステムをサポートしない理由は、Sysprep と異なり、これらのツールでは、Windows がマシン SID への参照を隠している場所を必ずしもすべて認識できないためです。古いマシン SID と新しいマシン SID が混在しているシステムの信頼性やセキュリティは保証できません。

それでは、複数のコンピューターが同じマシン SID を持つことは問題になるでしょうか。唯一問題になるとしたら、Windows が他のコンピューターのマシン SID を参照する場合です。たとえば、リモート システムに接続し、ローカル マシン SID がリモート マシンに転送され、アクセス許可チェックに使用される場合、SID の重複はセキュリティの問題を引き起こす可能性があります。リモート システムは、受け取ったリモート アカウントの SID を同じ SID のローカル アカウントと区別できないためです (この 2 つのアカウントの SID は、ベースとなる同じマシン SID と同じ RID を持つとします)。しかし、先に確認したように、Windows では、ローカル コンピューターにのみ既知のアカウントを使用して別のコンピューターに認証されることはありません。そうではなく、リモート システムに対してローカルなアカウントか、そのリモート コンピューターが信頼するドメインのドメイン アカウントのいずれかの資格情報を指定する必要があります。リモート コンピューターは、ローカル アカウントの SID を独自のセキュリティ アカウント データベース (SAM) から取得し、ドメイン アカウントの SID をドメイン コントローラー (DC) の Active Directory データベースから取得します。リモート コンピューターが、接続しているコンピューターのマシン SID を参照することはありません。

言い換えると、コンピューターへのアクセスを最終的に制御するのは、SID ではなく、アカウントのユーザー名とパスワードだということです。リモート システムのアカウントの SID を知っているだけでは、コンピューターやコンピューター上のリソースにアクセスすることはできません。SID だけでは不十分であるというさらなる証拠として、ローカル システム アカウントなどの組み込みアカウントは、すべてのコンピューターで同じ SID を持つことを思い出してください。SID だけでアクセスできるとすれば、重大なセキュリティ ホールになります。

最初に書きましたが、このルールには 1 つの例外があります。それは DC 自体です。各ドメインは、ドメインの最初のドメイン コントローラーのマシン SID から取得される一意のドメイン SID を持ち、そのドメインの DC のすべてのマシン SID はそのドメイン SID と一致します。したがって、これは、マシン SID が他のコンピューターから参照されるケースと言うことができます。つまり、ドメインのメンバー コンピューターは、DC、つまりはドメインのマシン SID と同じマシン SID を持つことができません。ただし、メンバー コンピューターと同様に、各 DC もドメイン内のコンピューター アカウントを保持しており、それがリモート システムに認証される際の ID になります。ローカル アカウント SID がマシン SID に基づくのと同様のしくみで、ドメイン内のすべてのアカウント (コンピューター、ユーザー、セキュリティ グループ) の SID もドメイン SID に基づいていますが、この 2 つに関連性はありません。

このサポート技術情報の記事など、SID の重複に関するいくつかの記事では、複数のコンピューターが同じ SID を持つ場合、NTFS 形式の FireWire ディスクなどのリムーバブル メディア上のリソースは、ローカル アカウントに対する安全性を確保できないと警告しています。ただし、これらの記事では、リムーバブル メディア上のアクセス許可はどちらにしてもセキュリティを提供しないということに触れていません。これは、NTFS アクセス許可を考慮しないオペレーティング システムを実行しているコンピューターにリムーバブル メディアを接続することができるためです。さらに、リムーバブル メディアは、Administrators グループのようにすべてのシステムで同じ既知の SID にアクセスを許可するようなアクセス許可を既定で持つことがよくあります。これが物理的セキュリティの基本原則であり、Windows 7 でリムーバブル ストレージを暗号化するための Bitlocker-to-Go が導入された理由です。

SID の重複が問題になる最後のケースは、分散アプリケーションがコンピューターを一意に識別するためにマシン SID を使用している場合です。マイクロソフトのどのソフトウェアもこのケースには当てはまりません。また、すべての DC が同じマシン SID を持つという事実から、当然このようなマシン SID の使用方法は機能しません。コンピューターの一意性に依存するソフトウェアは、コンピューター名またはコンピューターのドメイン SID (ドメイン内のコンピューター アカウントの SID) のいずれかを使用しています。

新しいベスト プラクティス

長い間、SID の重複の問題が疑問視されていなかったことには少し驚きますが、誰かしらがこの問題について正確に理解しているのではないかと誰もが思っていました。残念なことに、NewSID が実際に役立つことはありませんでしたし、提供を停止した今、惜しいと思うこともありません。Sysprep は、ほかにもマシン固有の状態をリセットします。それが重複していると、Windows Server Update Services (WSUS) などの特定のアプリケーションに問題が発生する可能性があるためです。したがって、マイクロソフトのサポート方針として、今後も複製されたシステムは Sysprep を使用して一意であることが要求されることに注意してください。

公開: 2009 年 11 月 3 日火曜日 8:00 AM/投稿者: markrussinovich (英語)