「セイテク・シス管道場（Web）」では、Windows Serverの要素技術やシステム管理の基本的な部分に焦点を当てたいと思います。今回は、ユーザーやグループ、コンピューターのID、セキュリティ識別子（Security Identifier《SID》）の話です。Windowsにとって、ユーザー名は表示名に過ぎません。Windowsのセキュリティモデルにおいて、その中心にあるのはSIDです。

ユーザーを識別するのは世界で1つだけのセキュリティ識別子（SID）

　
　Windowsは、何らかのオブジェクト（例えば、ファイルやフォルダー）に対して何らかの操作を実行するのが誰か、つまりユーザー（セキュリティプリンシパル）やグループ（セキュリティグループ）を一意に識別するためにSIDを使用します。現在、Windowsにログオン中の自分のSIDを確認するには、コマンドプロンプトまたはPowerShellで「whoami /user」を実行します。PowerShellで次のように実行すれば、ローカルユーザー/グループ、ドメインユーザー/グループのSIDを確認することができます（画面1）。

画面1　自分のSIDと、すべてのローカルユーザー/グループのSID

　SIDは、「S」から始まり、リビジョン番号「1」、48ビットの識別子機関「5など」、可変長（最大32ビット）の副識別子機関と相対識別子（RID）で構成されます。このSIDの構造を深く知ろうとすると、ややこしくなってしまいます。とりあえず、次に示す一般的なSIDの例の3種類と既知のSID（Well-known SID）の存在を知っていればいいでしょう。なお、SIDは上記のコマンドラインでも確認できますが、Windows SysinternalsのPsgetSidを使用すると、名前からSID、SIDから名前を解決できて便利です。

PsGetSid｜Windows Sysinternals（Microsoft Learn）

一般的なSIDの例

既知のSID（Well-known SID）の例

セキュリティ識別子 > 既知のSID（Well-known SIDs）｜Windows Server（Microsoft Learn）

　このうち、Windowsデバイス（コンピューター）に固有のマシンSIDは、プレインストールPCの初回起動時、Sysprepによる一般化後の初回起動時、ドメインコントローラーからの降格時に自動生成されます。PsGetSidをパラメーターなし（または-nobannerのみ）で実行すると、マシンSIDを確認することができます（画面2）。

画面2　PsGetSidを使用したSIDの確認

　ランダムに生成されるSIDは十分に長く、この世に何十億台のWindowsデバイスがあったとしても、理論上、重複することはありません。重複することがあるとしたら、以下の記事で説明したように、不適切な方法でクローンされた場合です。

ITニュース.　最近の更新に含まれる仕様変更で、マシンSIDの重複は厳禁に！（マシンSIDの重複“実話”）

　この記事では、長い間、マシンSIDはネットワーク上で重複しても何も不都合は生じないというのが常識でしたが、Windows 11バージョン24H2以降、およびWindows Server 2025以降では品質更新プログラムの影響でその常識が通用しなくなり、重複するとKerberos認証やNTLM認証が失敗するようになったことを説明しました。繰り返しますが、適切な方法で使用している限り、マシンSIDが重複することはありません。

　ローカルユーザーやローカルグループ（ビルトインローカルグループ）のSIDは、「マシンSID-RID」の形式になります。Administrator（コンピューター名￥Administrator）のSIDは常に「マシンSID-500」、Guest（コンピューター名￥Guest）のSIDは常に「マシンSID-501」です。そして、ローカルユーザーやローカルグループには「マシンSID-1001」以降のSID（1001以降のRID）が順番に割り当てられます。

　一方、Active Directoryのドメイン環境では、マシンSIDではなく、ドメインSIDが使用されAdministrator（ドメイン名￥Administrator）のSIDは常に「ドメインSID-500」、Guest（ドメイン名￥Guest）のSIDは常に「ドメインSID-501」、ドメインユーザーやドメイングループ、ドメインコンピューターアカウントには「ドメインSID-1001」以降のSID（1001以降のRID）が順番に割り当てられます。

　マシンIDは重複しないと言いましたが、ドメイン環境では少し違います。実は、ドメインSIDは、新しいフォレスト/ドメインを作成する際、最初のドメインコントローラーのマシンSIDがドメインSIDになります。そして、同じドメインに追加されるドメインコントローラーは、昇格時に同じマシンSID（ドメインSID）に変更されます（画面3）。

画面3　同じドメインのドメインコントローラーは、同じマシンSID（最初のドメインコントローラーの昇格前のマシンSIDだったもの）を持つ

　ドメインコントローラーのネットワークからの参照にはマシンSIDではなく、ドメインコントローラーのコンピューターアカウントのSID（ドメインSID-RID）が使用されるため、ドメインコントローラーのマシンSIDの重複が問題になることはありません。なお、ドメインコントローラーを降格すると、元のマシンSIDに戻るのではなく、新しいマシンSID（新しいSAMデータベース）が作成されることを実機で確認しました。

　セキュリティ対策の一環として、ローカルやドメインのAdministratorの名前を分かり難いものに変更するというものがあります（通常、「アカウント: Administrator アカウント名の変更」ポリシーを使用して）。Windows Server 2025のセキュリティベースライン（以下の記事を参照）にもその対策は含まれます。

vol.80　CIS対応のセキュリティ態勢を簡単に導入、維持できる新機能「OSConfig」｜Windows Server 2025大特集（17）

　最初に言ったように、名前は表示名に過ぎません。Administratorの名前を変更しても、システムにログオンできるユーザーであれば、すべてのユーザーのユーザーSIDを参照できるので、元Administratorであることは簡単にばれてしまいます（前出のコマンドで）。SIDは一般ユーザーに隠されている属性ではありません。そのSIDが「500」のRIDを持つなら、そのユーザーがAdministratorということになります（画面4）。

画面4　一般ユーザー（localuser）でログオンしてもすべてのローカルユーザーのSIDを確認できる。taroyamadaが元Administrator、つまりローカル管理者であることがわかる

　ログオン画面からはユーザーSIDを確認できないので、セキュリティ対策としてのAdministratorの名称変更は、まったく意味がないというわけではありません。それよりもむしろ、別のローカルユーザーまたはドメインユーザーをローカルまたはドメインの管理者にして、既定の管理者であるAdministratorはアカウントを無効にしたほうが、セキュリティ対策として、より有効です。

SIDとUAC、SIDとセキュリティ記述子

　ユーザーがWindowsにログインするたびに、ログオンセッション、つまりそのユーザーのアクセストークンが作成されます。アクセストークンには、ユーザーのSID、グループのSID、ユーザー権利が含まれます。

　「ユーザーアカウント制御（UAC）」が有効な場合（ビルドインAdministrator以外は既定で有効な場合、管理者ユーザーがWindowsにログオンすると、標準ユーザーに相当する制限トークンと、管理者のフルトークンが作成されます。ユーザーの操作は、通常は制限トークンで実行され、管理者権限が必要なときに、UAC昇格によりフルトークンの使用が可能になります。昇格しないコマンドプロンプトと昇格したコマンドプロンプトの両方で「whoami /priv」や「whoami /groups」（または「whoami /all」）を実行すると、制限トークンとフルトークンのそれぞれで実行可能な特権や有効なグループメンバーシップの違いを確認できます（画面5）。

画面5　UACが有効な場合、制限トークンとフルトークンのそれぞれで実行可能な特権や有効なグループメンバーシップが異なる

　ユーザーが操作する対象のオブジェクトは、「セキュリティ記述子（Security Descripter）」を持ちます。その中にはユーザーやグループのSIDとともに、随意アクセス許可（DACL）や監査設定（SACL）といった「アクセス制御リスト（Access Control List《ACL》）」が格納されています。エクスプローラーの「セキュリティ」タブでは、ユーザーやグループ、そしてそのアクセス許可がユーザーフレンドリーな名前で表示されますが、Get-ACLコマンドレットを使用すると、ACLの文字列表現である「SDDL」形式の中にSIDを確認できます。また、icaclsコマンドを使用すると、名前はもちろん、SIDでアクセス許可を付与することができます（画面6）。

画面6　Get-ACLの出力にあるSDDLにはSIDが確認できる。icaclsコマンドを使用するとSIDによる権限の付与も可能

　Windowsにオンラインアカウント（MicrosoftアカウントやMicrosoft Entra IDアカウント）でサインインする場合は、オンラインアカウントはWindowsの世界のSIDを持ちません。クラウド側に何らかのユーザーフレンドリーではないIDを持っているかもしれませんが、それは利用者からは見えないものです。そのため、オンラインアカウントがWindowsのセキュリティモデルに直接的に交わることはできません。Windowsのセキュリティモデルの中では、クラウドへのデバイス登録時に自動作成されるローカルアカウントのSIDが使用されます。そして、クラウドのアクセストークンについては、そのローカルアカウントのセッションが保持しており、クラウドアプリのSSOアクセスを可能にしています。

Windows Server 2025に見つけた、ビルトイングループ名の問題

　ユーザー名やグループ名は表示名に過ぎないと言いましたが、Windows Server 2025日本語版やWindows 11日本語版では、そうとも言い切れない例を見つけました。それは、「BUILTIN¥OpenSSH ユーザー」（S-1-5-32-585）です。英語版では「BUILDIN¥OpenSSH Users」なので問題はないのですが、日本語版ではローカライズされた表示名に問題があります。詳しくは以下の記事に説明しましたが、OpenSSH Serverの設定ファイル「C:¥ProgramData¥ssh¥sshd_config」には許可グループとして「AllowGroups administrators "openssh users"」と書かれています。そのため、「BUILTIN¥OpenSSH ユーザー」グループにユーザーを追加しても、日本語環境では期待通りに許可されません。OpenSSH Serverはオープンソースの実装であり、Windowsのセキュリティモデルの外にあるため、こういった残念な不具合が生まれてしまうのでしょうか。

メモ.　「OpenSSH ユーザー」グループにユーザーを追加してもSSH接続できない問題｜Windowsトラブル解決

“今”の機能（ケーパビリティ）SIDは名前を持たない

　最近のバージョンのWindowsでは、エクスプローラーでユーザーのホームディレクトリ（%USERPROFILE%）などのアクセス許可を確認すると、「不明なアカウント（S-1-15-･･･）」に対するアクセス許可の存在を見るかもしれません。もし、そのSIDが「S-1-5-21-･･･」なら、過去に存在、今は削除されてしまったユーザーやグループに対するアクセス許可が残っているのでしょう。そのエントリは削除しても問題ないはずです。しかし、そのSIDが「S-1-5-3-･･･」であれば、正規のSIDなので削除しないでください。

　「S-1-5-3-･･･」は、機能（ケーパビリティ）SIDと呼ばれ、Microsoftストアアプリ（ユニバーサルWindowsプラットフォーム《UWP》アプリ）に関係した正規のアクセス許可です。ストアアプリが登場した当初は、「APPLICATION PACKAGE AUTHORITY￥インターネット接続（S-1-15-3-1）」など、対応するユーザーフレンドリーな名前を持つ、既知の機能SIDが使用されていました。^*1 現在のWindowsでは、Windowsが認識しているすべての機能SIDは「HKEY_LOCAL_MACHINE¥SOFTWARE¥Microsoft¥SecurityManager¥CapabilityClasses」キーにある「AllCachedCapabilities」に登録されており、各機能SIDはユーザーフレンドリーな名前を持ちません（画面7）。アクセス許可に、ユーザー名やグループ名ではなく、SIDがそのまま表示されるのはこれが理由です。

*1　現在のWindows 11でも、PsGetSid S-1-15-3-1（APPLICATION PACKAGE AUTHORITY¥インターネット接続）～PsGetSid S-1-15-3-12（APPLICATION PACKAGE AUTHORITY￥ユーザーの連絡先）の12個の機能SIDを確認できます。

画面7　現在のWindowsでは、機能SIDは名前を持たないため、「不明なアカウント（S-1-5-3-･･･）」と表示される

セキュリティ識別子 > 機能SID（Capability SIDs）｜Windows Server（Microsoft Learn）

 セイテク・シス管道場（Web） (1) ｜(2)｜(3)