はじめに

Linuxエンジニアが新しいサーバーにログインして最初に確認するのは、ユーザー一覧や権限設定ではないでしょうか。Linuxでは /etc/passwd を見れば、誰がシステムに存在するか一目瞭然です。

では、Windowsにおいて「ユーザー情報の実体」はどこにあるのでしょうか？
今回は、Linuxのテキストベース管理とWindowsのレジストリ（バイナリ）ベース管理の違いを徹底比較します。

1. ユーザー情報の「在処」を比較する

Linuxではユーザー情報をプレーンテキストで管理しますが、Windowsでは レジストリ内の「SAM（Security Accounts Manager）」というバイナリデータベース に格納されています。

比較項目	Linux (CentOS等)	Windows
基本情報	`/etc/passwd`	レジストリ `HKEY_LOCAL_MACHINE\SAM`
パスワードハッシュ	`/etc/shadow`	SAM データベース内（SYSKEYで暗号化）
ファイル形式	テキストファイル（ASCII）	バイナリ（Hiveファイル）
アクセス方法	`cat`、`vi`、`id` コマンド	`net user`、PowerShell、GUI

Linuxエンジニアの視点

cat /etc/passwd でユーザー一覧を確認できるLinuxと異なり、Windowsでレジストリエディタ（regedit）を開いても、デフォルトでは SAM ハイブの中身を閲覧できません。これは SAM がシステム特権（SYSTEM アカウント）によって保護されており、OSの起動中はロックされているためです。

実体ファイルは C:\Windows\System32\config\SAM に存在しますが、稼働中は排他ロックがかかっており、直接コピーできません。攻撃者はこの制約を回避するために「ボリュームシャドウコピー（VSS）」を悪用して SAM ファイルを窃取しようとすることがあります。

2. 識別子の違い：UID vs SID

Linuxの UID（User ID） は単純な整数（0、1000 など）ですが、Windowsの SID（Security Identifier） はより複雑な構造を持っています。

Linux UID の例: 1001
Windows SID の例: S-1-5-21-3623811015-3361044348-30300820-1013

SID の構造を分解する

S  - 1  - 5  - 21-3623811015-3361044348-30300820  - 1013
↑    ↑    ↑    ↑                                    ↑
識別 リビ  識別  ドメイン/マシン固有の識別子          RID
子   ジョン 機関  （マシンまたはドメインごとに一意）   (Relative ID)

SID が長くなるのは、そのユーザーが「どのマシン」または「どのドメイン」で作成されたかという情報を含んでいるためです。末尾の RID（Relative ID） が Linux の UID に最も近い概念であり、そのドメイン・マシン内での連番です（例：Administrator は常に RID 500、Guest は RID 501）。

セキュリティ上の重要ポイント：
Windows ではユーザー名を変更しても SID は変わりません。そのためファイルや共有フォルダの ACL（アクセス制御リスト）はユーザー名ではなく SID で管理され、名前変更後も権限が引き継がれます。この挙動は Linux の UID 変更と類似しています。ただし SID はグローバルにユニークであることが期待されており、クローンされた VM などで SID が重複するとドメイン参加時に問題が生じます。

3. パスワードハッシュ：Shadow vs NT Hash

Linuxの /etc/shadow に相当するものが、SAM 内に格納されている NT Hash（NTLMハッシュ） です。

比較項目	Linux（SHA-512 + Shadow）	Windows（NT Hash）
アルゴリズム	SHA-512 等	MD4
ソルト	あり	なし
ストレッチング	あり（数千回）	なし（1回）
ハッシュの形式例	`$6$salt$...`	`aad3b435b51404ee...`

ここに潜むリスク：Pass-the-Hash 攻撃

NT Hash にはソルトがないため、同じパスワードであればどのマシンでも同じハッシュ値になります。これにより、パスワードそのものを知らなくともハッシュ値を提示するだけで認証できてしまう 「Pass-the-Hash（PtH）」 攻撃が成立します。

通常の認証フロー:   パスワード → NT Hash → NTLM 認証
Pass-the-Hash:      （パスワード省略）NT Hash → NTLM 認証

この問題は NTLM 認証プロトコル固有のものです。Windows 環境ではソルトなしハッシュを前提とした設計になっているため、Kerberos 認証の強制や Protected Users グループの活用、Credential Guard の導入といった対策が有効です。

4. 実践：PowerShell でユーザー情報を確認する

Linux エンジニアらしく、コマンドラインで情報を取得してみましょう。

# ユーザー一覧と SID・有効状態を確認する（getent passwd に近い感覚）
Get-LocalUser | Select-Object Name, SID, Enabled

# 特定ユーザーの詳細（パスワードの最終変更日・有効期限など）を確認する
Get-LocalUser -Name "Administrator" | Select-Object *

# 現在ログイン中のユーザーの SID を確認する
[System.Security.Principal.WindowsIdentity]::GetCurrent().User.Value

Get-LocalUser は Linux の getent passwd に近い感覚で使用でき、SAM のローカルユーザー情報を参照します。ドメイン環境では Get-ADUser を使用します。

まとめ

観点	Linux	Windows
ユーザー情報の格納先	`/etc/passwd`（テキスト）	SAM レジストリ（バイナリ）
パスワードハッシュ	`/etc/shadow`（ソルト付き）	SAM 内 NT Hash（ソルトなし）
ユーザー識別子	UID（整数）	SID（ドメイン情報を含む文字列）
ハッシュの強度	高（ストレッチング・ソルトあり）	低（MD4 1回、ソルトなし）
主なリスク	Shadow ファイル漏洩	Pass-the-Hash、SAM 窃取

「テキストファイルで管理する Linux」と「データベース（レジストリ）で管理する Windows」——この設計思想の違いが、運用方法やセキュリティリスクに大きな差を生みます。特に NT Hash のソルトなし設計は、Windows 環境における認証攻撃を理解する上で重要な前提知識です。