「アカウントを一度削除して、同じ名前で作り直してみた」
こういう対応、現場で見たことはないでしょうか。
名前だけを見れば「元に戻った」ように見えますが、Windowsの内部ではこの2つのアカウントはまったくの別人として扱われています。
以前のアクセス権もグループの所属も、何一つ引き継がれません。
この記事では、Windows/ADのアカウント管理を裏側で支えている「SID(セキュリティ識別子)」という仕組みを解説します。
RID 500やDomain Adminsの512番といった、特権アカウント関連の記事で見かける数字の意味も、ここから枝分かれしています。
Windowsが本当に見ているのは「名前」ではなく「SID」
普段、私たちはアカウントを名前で扱います。
ログオン画面に表示されるのも、ADUCの一覧に並ぶのも、すべてアカウント名です。
ところがWindowsの内部では、認証やアクセス制御の判定はすべて別の値をもとに行われています。
SID(セキュリティ識別子/Security Identifier)
ユーザーやグループなどのセキュリティプリンシパルを一意に識別するために、Windowsが内部的に発行する値。サインインするたびにこの値を含むアクセストークンが生成され、リソースへのアクセス可否の判定はすべてこのSIDをもとに行われる。

Microsoft Learnでは、SIDについて次のように説明されています。
SID は常に一意のままです。セキュリティ機関は、同じ SID を 2 回発行することはなく、削除されたアカウントの SID を再利用することはありません。
つまりSIDは「使い捨ての整理番号」のようなものです。一度発行されたら二度と使い回されず、名前が同じでも中身(SID)が違えば、Windowsにとっては完全な別人になります。冒頭の「削除して同じ名前で作り直す」といった対応が難しいのは、この仕組みが機能しているためです。
SIDの構造を実例から読み解く
SIDはS-1-5-32-544のような文字列で表記されます。
一見ただの数字の羅列に見えますが、実は4つの要素に分解できます。

組み込みのAdministratorsグループを例に見てみます。
| 位置 | 値 | 意味 |
|---|---|---|
| S | S | SIDであることを示す固定表記 |
| リビジョン | 1 | SID構造のバージョン |
| 識別子機関 | 5 | 発行元の機関(5=NT Authority) |
| ドメイン識別子 | 32 | 発行元のドメイン(32=Builtin=ローカル環境) |
| RID | 544 | ドメイン内でこのアカウント・グループを区別する固有番号(544=Administrators) |
ドメイン環境のアカウントになると、ドメイン識別子の部分がそのドメイン固有の長い数字列に変わります。たとえば、あるドメインのDomain AdminsグループのSIDは次のような形になります。
S-1-5-21-1004336348-1177238915-682003330-512
21-1004336348-1177238915-682003330の部分がそのドメインを一意に示す識別子で、末尾の512がドメイン内でDomain Adminsを区別するRIDです。同じ企業内に複数のドメインがあっても、このドメイン識別子が重複することはありません。
RID(相対識別子/Relative Identifier)
SIDを構成する末尾の値。ドメインやローカル環境の中で、特定のアカウント・グループを他と区別するための番号。同じスコープ内で同じRIDを持つアカウントは存在しない。
よく見る主要なWell-known SID
環境によらず値が固定されている「Well-known SID(既知のSID)」もあります。
ログの読み解きや権限設計でよく出てくるものを挙げます。
| SID | 名称 | 何を示すか |
|---|---|---|
| S-1-1-0 | Everyone | すべてのユーザーを含むグループ |
| S-1-5-11 | Authenticated Users | 認証済みのすべてのユーザー・コンピューター |
| S-1-5-18 | System(LocalSystem) | OS自身やLocalSystemとして動くサービス |
| S-1-5-32-544 | Administrators(Builtin) | 各コンピューターに存在する組み込みの管理者グループ |
これらはドメインやOSのバージョンが変わっても値が一定なので、GPOのアクセス許可設定やイベントログの読み解きで頻繁に登場します。
RIDの数字が示している中身
ドメインアカウントの場合、RIDには特定の番号があらかじめ予約されています。実務で目にする機会が多いものを整理します。
| RID | 名称 | 補足 |
|---|---|---|
| 500 | Administrator | 最初に作成される既定の管理者アカウント。無効化やロックアウトはされないが、名前変更は可能 |
| 501 | Guest | 既定のゲストアカウント |
| 502 | KRBTGT | Kerberosの鍵配布センター(KDC)が使う特殊アカウント。ドメインコントローラーにのみ存在 |
| 512 | Domain Admins | ドメイン全体を管理する権限を持つグローバルグループ |
| 513 | Domain Users | ドメイン内の全ユーザーを含むグループ |
| 518 | Schema Admins | フォレストルートドメインにのみ存在し、スキーマ変更権限を持つ |
| 519 | Enterprise Admins | フォレストルートドメインにのみ存在し、フォレスト全体への権限を持つ |
| 525 | Protected Users | 認証保護を強制する特権アカウント保護用のグループ |
RID 500やRID 512の棚卸しは、特権アカウントの設計を見直すときの出発点になります。具体的な設計の考え方は「AD特権アカウントの設計|Tier0保護と管理者アカウント分離の実務」で解説していますので、あわせて参照してください。
名前を変えても消えない、削除すると別物になる
SIDの仕組みを理解すると、現場で起きがちな2つの誤解が整理できます。
1つ目は、同一ドメイン内でのアカウント名の変更です。Administratorアカウントは名前を変更できますが、名前を変えてもSIDは変わりません。Windowsの内部では、改名の前後でずっと同じアカウントとして扱われ続けます。
2つ目は、削除してからの再作成です。同じ名前・同じ属性で作り直しても、新しいアカウントには新しいSIDが発行されます。Microsoft Learnでも次のように説明されています。
新しい SID は古い SID と一致しないため、古いアカウントからのユーザーのアクセス権は新しいアカウントに移転されません。両方のアカウントは異なる 2 つのセキュリティ プリンシパルを表しています。
この「名前を変えてもSIDは変わらないが、削除すると変わる」という仕様は、ユーザープロファイルのフォルダ管理にも表れています。
WindowsはユーザープロファイルのパスをレジストリのProfileImagePathにSID単位で記録しており、Microsoftのサポート技術情報でも、アカウント名を変更してもC:\Users\配下のフォルダ名は自動的には変わらない仕様であることが明記されています。
ただしこの記事のフォルダ名変更の回避策(レジストリのProfileImagePathを手動で書き換える手順)については、Microsoft自身がWindows 10以降の環境には適用しないよう注意を出しています(winggetの動作に影響する可能性があるため)。「名前とSIDは別物」という前提だけ押さえておき、手動でのレジストリ修正は必要に迫られない限り避けるのが無難です。
実務でSIDを確認する方法
自分の環境のSIDは、コマンド一つで確認できます。
# 現在サインインしているユーザーのSIDを確認する
whoami /user
ADのユーザーオブジェクトであれば、PowerShellでも確認できます。SIDはGet-ADUserの既定のプロパティに含まれているため、-Propertiesオプションを付けなくても取得できます。
# 特定ユーザーのSIDを確認する
Get-ADUser -Identity "<ユーザー名>" | Select-Object Name, SamAccountName, SID
RID 500のBuilt-in Administratorが有効なまま放置されていないかを確認したい場合は、以下のようにSID末尾の値でフィルタできます。
# SIDの末尾が-500のアカウント(Built-in Administrator)を確認する
Get-ADUser -Filter * -Properties SID | Where-Object { $_.SID -like "*-500" }
よくある勘違いと見落とし
案外知られていないのが、「削除して同じ名前で作り直せば元通りになる」という誤解です。前述の通りSIDは再発行されるため、以前のアクセス権・グループメンバーシップ・共有フォルダの権限などは何一つ引き継がれません。退職者アカウントの扱いなどで安易に削除・再作成をすると、思わぬアクセス不能が発生します。
そのうえ見落とされがちなのが、「SIDを見れば個人情報が分かるのではないか」という不安です。SIDはあくまで内部的な整理番号であり、氏名や所属といった情報は一切含まれません。ドメイン識別子の部分からそのドメインを特定することはできますが、個人を直接特定できる情報ではありません。
実務でひやっとするのが、Built-in Administrator(RID 500)を「無効化したから安全」と思い込んでいるケースです。無効化はできますが削除はできない仕様のため、有効化されていないか・名前が推測されやすいままになっていないかは、無効化とは別に定期的な確認が必要です。
そして地味に効いてくるのが、アカウント名の変更をきっかけに発生するプロファイルフォルダのズレです。名前だけを変えると、内部的にはSIDで同一人物と扱われ続ける一方で、C:\Users\配下のフォルダ名は古い名前のまま残ります。ヘルプデスク対応で「フォルダ名とアカウント名が一致しない」と混乱する場面は、たいていこれが原因です。
自分の管理者アカウント、RIDはいくつか知っていますか
SIDは普段意識することのない仕組みですが、アカウントの削除・再作成、特権アカウントの棚卸し、イベントログの読み解きなど、実務のさまざまな場面で顔を出します。
まずは自分の環境でwhoami /userを実行し、自分のSIDの末尾がどんな数字になっているか、管理者アカウントのRIDがきちんと想定通りかを確認してみてください。名前だけを見ていては気づけない設定ミスが見つかることもあります。
あわせてご覧ください
- AD特権アカウントの設計|Tier0保護と管理者アカウント分離の実務
- ADのユーザーとグループ管理|最小権限を実現する設計パターン
- Protected Usersグループとは?Pass-the-Hash・Kerberoasting対策として使ってみた


コメント