AdministratorsとAdministratorは、名前が似ていますがWindowsでは別の対象です。Administratorsは複数のユーザーやグループを所属させるローカルグループで、組み込みSIDはS-1-5-32-544です。AdministratorはWindowsが持つ組み込みローカルユーザーアカウントで、そのコンピューター固有SIDの末尾がRID 500になります。複数形か単数形かだけでなく、「グループ」と「ユーザー」の違いとして理解してください。
さらに、Administratorsグループのメンバーであることと、現在のアプリが常に完全な管理者権限で動いていることも同じではありません。ユーザーアカウント制御（UAC）により、管理者メンバーの通常操作には標準ユーザー相当のアクセストークンが使われ、昇格を承認したプロセスだけが管理者トークンで動く構成が基本です。
違いを表で整理する
| 項目 | Administrators | Administrator |
|---|---|---|
| 種類 | ローカルグループ | 組み込みローカルユーザー |
| 人数 | 複数のメンバーを保持できる | 一つのアカウント |
| 識別 | S-1-5-32-544 | コンピューターSID＋RID 500 |
| 名前変更 | 表示名よりSIDで識別する | 改名されても末尾500で識別できる |
| 用途 | ローカル管理権限を与える主体をまとめる | 回復・初期管理などに使われる特別な組み込みアカウント |
日本語版WindowsではAdministratorsが「Administrators」またはローカライズされた表示で見えることがあり、組織によってAdministratorも改名されている場合があります。表示名だけでスクリプトや監査を組むと取り違えるため、Microsoftが定義するSIDを基準にします。SIDはセキュリティプリンシパルを識別する値で、アクセス制御は名前そのものではなくSIDを使って判断されます。
Administratorsグループとは
Administratorsは各Windowsコンピューターに存在する組み込みローカルグループです。このグループのメンバーは、昇格時にシステム全体へ影響する設定変更を行えるため、メンバーシップは必要最小限にします。ローカルユーザーだけでなく、Microsoft Entra IDやActive Directoryのユーザー・グループ、製品が作成したサービス用主体が含まれる構成もあります。
ドメイン参加PCでは、ドメイン側のグループがローカルAdministratorsへ入れ子になっている場合があります。その場合、個々のユーザー名が直接一覧に見えなくても、ドメイングループ経由で権限を持つことがあります。監査では直接メンバーだけで結論づけず、組織のID基盤とグループの入れ子を確認します。
Administratorsはユーザー名ではないため、通常はこの名前でサインインしません。「Administratorsでログインする」という表現は不正確で、実際にはそのグループのメンバーであるユーザーとしてサインインします。どのアカウントでサインインしたかと、そのアカウントがどのグループを経由して権限を得たかを分けて記録します。
組み込みAdministratorアカウントとは
AdministratorはWindowsに組み込まれたローカルユーザーアカウントです。Microsoftの資料では、このアカウントのRIDは500であり、改名されてもSID末尾で識別できます。通常のWindowsセットアップでは、別の管理者メンバーを作成した後に組み込みAdministratorが無効化される構成が一般的ですが、アップグレード履歴、展開イメージ、組織ポリシーにより状態は異なります。
「Administratorが見当たらない」から削除されたと決めつけないでください。改名、無効化、表示方法、管理ツールのフィルターが理由かもしれません。反対に、名前がAdministratorの別ユーザーを作っても、それがRID 500の組み込みアカウントとは限りません。名前とSIDをセットで確認します。
組み込みAdministratorを日常利用の解決策として有効化するのは勧められません。特別な既知アカウントは攻撃対象になりやすく、監査上も個人を識別しにくくなります。回復目的で必要な組織は、Microsoftのセキュリティ方針、パスワード管理、利用記録、無効化条件を含む正式な手順を用意します。
UACにより「管理者メンバー」と「昇格中」は分かれる
Administratorsグループの一般ユーザーでサインインすると、UACは通常操作用と管理操作用のアクセストークンを分けます。エクスプローラーや通常起動したPowerShellが、管理者グループの全権限を常時使うわけではありません。システム変更を行うアプリが昇格を要求すると、同意または資格情報入力の画面が出て、承認したプロセスだけが高い権限で動きます。
そのため、「Administratorsに入っているのにアクセス拒否になる」「同じユーザーなのに管理者として実行すると結果が違う」という現象は矛盾ではありません。ファイルやレジストリのACL、所有者、整合性レベル、アプリの実行トークン、組織ポリシーを確認します。アクセス拒否を解消するためにUACを無効化するのではなく、必要な管理操作だけを承認済み手順で昇格します。
読み取り専用でローカルアカウントを確認する
PowerShellのMicrosoft.PowerShell.LocalAccountsモジュールには、ローカルユーザーとローカルグループメンバーを取得するコマンドレットがあります。次のコマンドは変更を行わず、名前、有効状態、SIDを表示します。
Get-LocalUser |
Select-Object Name, Enabled, PrincipalSource,
@{Name='SID'; Expression={$_.SID.Value}}出力されたSIDの末尾が「-500」のユーザーが、組み込みAdministratorアカウントです。表示名がAdministratorでなくてもSIDを優先します。ただし、結果を外部へ共有するとPCのSIDやアカウント名が漏れるため、サポート投稿へそのまま貼り付けず、必要部分だけを組織内の安全な場所へ保存します。
64ビットWindows上の32ビットPowerShellではLocalAccountsモジュールを利用できない場合があります。コマンドが見つからないときに非公式モジュールを導入せず、64ビット版PowerShellを確認するか、組織の標準管理ツールを使ってください。
AdministratorsグループのメンバーをSIDで確認する
表示言語に依存せずAdministratorsを指定するには、既知SID S-1-5-32-544を使います。次はメンバー一覧を読み取る例です。
$administratorsSid = [Security.Principal.SecurityIdentifier]'S-1-5-32-544'
Get-LocalGroupMember -SID $administratorsSid |
Select-Object Name, ObjectClass, PrincipalSource,
@{Name='SID'; Expression={$_.SID.Value}}Name列に「PC名\ユーザー」「ドメイン名\グループ」などが表示され、ObjectClassでユーザーかグループかを見分けられます。PrincipalSourceは主体の由来を判断する助けになります。見覚えのないメンバーがいても、即座に削除しません。端末管理、バックアップ、セキュリティ製品、ドメイン運用が必要としている可能性があるため、所有者、導入経緯、ポリシーを先に確認します。
現在のサインイン主体とトークンを確認する
現在のユーザーSIDはwhoamiで確認できます。
whoami /user現在のアクセストークンに含まれるグループは次で確認できます。
whoami /groupsAdministratorsのSIDが表示されても、UACによって通常トークン側で制限された状態を示すことがあります。単に行があるかだけで「このウィンドウは完全に昇格済み」と断定せず、表示される属性、起動方法、実行しようとしている管理操作を合わせて判断します。本記事のコマンドは読み取り専用なので、確認のためにUACを無効化する必要はありません。
ローカルとドメインを混同しない
| 表記例 | 意味の例 | 確認先 |
|---|---|---|
| PC01\Administrator | PC01のローカル組み込みアカウント | Get-LocalUserとSID末尾500 |
| PC01\HelpdeskLocal | PC01の別ローカルアカウント | ローカルユーザー一覧 |
| CONTOSO\IT-Admins | ドメイン側のグループ | Active Directory管理者とグループ構成 |
| Administrators | ローカル組み込みグループ | S-1-5-32-544のメンバー |
「Domain Admins」とローカル「Administrators」も同一ではありません。ドメインの管理グループが各PCのAdministratorsへ追加される設計はありますが、それはグループの入れ子による権限付与です。ドメインコントローラー、メンバーサーバー、一般PCではローカルアカウントの扱いも異なるため、対象コンピューターの役割を確認します。
安全な監査の進め方
- 対象PC、調査日時、サインインユーザーを記録します。
- Get-LocalUserでRID 500の組み込みアカウント名と有効状態を確認します。
- S-1-5-32-544を指定してAdministratorsの直接メンバーを取得します。
- ドメイングループが含まれる場合は、ID管理者へ入れ子と所有者を確認します。
- 不要に見える主体は、用途と復旧方法を確認してから別の承認済み変更で扱います。
監査と修正を同じ操作にしないことが重要です。メンバー削除、アカウント無効化、パスワード変更はサービス停止や管理不能を招く可能性があります。変更前に代替管理者、緊急アクセス、端末管理製品への影響、復元手順、監査ログを準備します。特にリモート管理中は、自分が使っている唯一の管理経路を削除しないでください。
Guestを代替として有効にしない
Administratorが無効だからといって、Guestを有効にして共有管理用に使うのは誤りです。MicrosoftはGuestを限定的なアクセス向けの既知アカウントとして説明し、セキュリティ上無効のままにすることを推奨しています。管理作業には、個人を識別でき、強い認証と監査を適用した必要最小限のアカウントを使います。
一時的な管理権限が必要な場合も、共有パスワードのAdministratorやGuestではなく、組織が承認した特権アクセス管理、期限付きグループメンバーシップ、ローカル管理者パスワード管理などを検討します。具体的な方式は環境によって異なるため、端末管理・ID管理の担当者が設計します。
よくある誤解
- 「AdministratorsはAdministratorの複数形」ではなく、前者はグループ、後者はユーザーです。
- 「名前がAdministratorなら組み込みアカウント」とは限らず、SID末尾500を確認します。
- 「Administratorsのメンバーなら全アプリが常時フル権限」ではなく、UACのトークンが関係します。
- 「一覧に直接ユーザーがないなら管理者でない」とは限らず、グループ経由のメンバーシップがあります。
- 「見覚えがないメンバーは即削除」ではなく、用途と所有者を確認してから変更します。
結論として、Administratorsはローカル管理者を束ねるS-1-5-32-544のグループ、AdministratorはRID 500の組み込みローカルユーザーです。名前ではなくSIDを使い、UACで実行トークンが分かれること、ドメイングループから間接的に権限を得ることまで含めて確認すれば、権限の取り違えを防げます。
コメント