[アーティクル]
10/20/2021

マシン SID の重複神話

翻訳元: The Machine SID Duplication Myth (英語)

更新日: 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 (英語)

ページのトップへ

ブログにコピー: ([Ctrl] + [C] でコピーしてください)

次の方法で共有

マシン SID の重複神話