whoami /all の結果が長くて、どこを見れば権限が分かるのか迷う人は多いはずです。結論から言うと、最初に見るべきなのは BUILTIN\Administrators の属性、Mandatory Label の整合性レベル、必要な特権が一覧にあるかどうかの3点です。whoami /all は「アカウントの登録情報」ではなく、いまそのプロセスが使っているアクセス トークンを表示するので、「管理者のはずなのに失敗する」「右クリックで管理者として実行すると成功する」といった差を読み解くのに向いています。この記事では、結果の見方、実務での判断基準、読み違えやすいポイント、補助コマンドまで整理します。(Microsoft Learn)
| まず見る場所 | 確認すること | 判断の目安 |
|---|---|---|
| USER INFORMATION | ユーザー名と SID | 想定外のアカウントなら、その後の判定は全部ずれる |
| GROUP INFORMATION | BUILTIN\Administrators の属性 | Group used for deny only なら、そのトークンは管理者グループを許可判定に使えない |
| GROUP INFORMATION | Mandatory Label | Medium は通常起動、High は昇格後の目安 |
| PRIVILEGES INFORMATION | 必要な特権の有無と状態 | 行がなければ未保有、Disabled は未有効化、Enabled は有効 |
特に重要なのは、「そのグループに入っているか」よりも「そのグループが今のトークンで使える状態か」を見ることです。whoami /all の価値は、所属の有無より、現在の実行コンテキストで有効な権限を見抜ける点にあります。(Microsoft Learn)
whoami /all が見ているのは「現在のアクセス トークン」
Windows では、ユーザーがサインインするとアクセス トークンが作られ、そのコピーがユーザーの代わりに動くプロセスに付与されます。アクセス トークンには、ユーザーの SID、所属グループの SID、特権、ログオン情報などが入っています。つまり whoami /all は、「このアカウントが一般論として何者か」ではなく、このコマンドを実行したプロセスが今どんなセキュリティ コンテキストで動いているかを見せるコマンドです。(Microsoft Learn)
この前提を押さえると、同じユーザーでも結果が変わる理由が分かります。UAC が有効な管理者アカウントでは、サインイン時に標準ユーザー用のトークンと管理者用のトークンが分かれ、通常のアプリは標準ユーザー側のトークンで起動します。さらに子プロセスは親プロセスのアクセス トークンを引き継ぐため、CMD か PowerShell かより、どう起動したかのほうが重要です。通常起動のターミナルと、「管理者として実行」したターミナルでは、同じ人が開いていても whoami /all の結果が変わります。(Microsoft Learn)
全体を見るなら /all、グループだけなら /groups、特権だけなら /priv、セッション切り分けなら /logonid が便利です。出力形式は table、list、csv を選べ、/nh でヘッダーも省けます。ログとして残すなら list、サーバー間比較なら csv が扱いやすいです。(Microsoft Learn)
whoami /all
whoami /groups
whoami /priv
whoami /logonidUSER INFORMATION は「誰のトークンか」を確定する場所
最初に確認したいのは、本当に想定したユーザーで実行しているかです。USER INFORMATION ではユーザー名と SID が分かります。名前は見慣れていても、ローカル アカウントとドメイン アカウントでは SID が別ですし、SID は一意で再利用されません。トラブルシュートでは「表示名が合っている」だけで安心せず、必要なら SID まで見るほうが安全です。(Microsoft Learn)
ここが想定と違っていたら、以降の GROUP INFORMATION や PRIVILEGES INFORMATION を読んでも意味がありません。タスク スケジューラ、サービス、別ユーザー実行、管理ツール経由の起動では、自分が見ているデスクトップのユーザーと、失敗している処理の実行ユーザーがずれていることがあるからです。whoami /all はあくまで現在のプロセスのトークンを見るものなので、失敗している処理と同じ文脈で実行するのが基本です。(Microsoft Learn)
GROUP INFORMATION は「所属」より「属性」が大事
GROUP INFORMATION は、単に所属グループの一覧を見る場所ではありません。重要なのは各行の Attributes です。Windows のアクセス チェックでは、SID が存在するだけでは足りず、その SID が有効かどうかが効いてきます。(Microsoft Learn)
| よく見る表示 | 意味 | 実務での読み方 |
|---|---|---|
Enabled group | アクセス チェックに使われる | 許可・拒否の判定にこの SID が使われる |
Group used for deny only | 拒否 ACE だけに使われ、許可 ACE には使われない | Administrators がこれなら、管理者メンバーでも今のトークンは管理者として動いていない |
Mandatory Label\Medium Mandatory Level | 中整合性 | 通常起動の目安 |
Mandatory Label\High Mandatory Level | 高整合性 | 昇格後の目安 |
Mandatory group | システム上の必須属性 | 管理者判定の主役ではない。Enabled や deny only のほうを優先して見る |
この表のうち、現場で最も効くのは BUILTIN\Administrators の行です。Microsoft のトラブルシュート文書でも、BUILTIN\Administrators が Group used for deny only と表示される場合、そのユーザーは Administrators グループのメンバーでも、そのトークンでは最小権限で動いており、管理タスクを実行できないと説明されています。インストーラー、MMC、サーバー設定変更が失敗するときは、まずこの行を見てください。(Microsoft Learn)
もう1つ大事なのが Mandatory Label です。これは通常の AD グループではなく、整合性レベルを表す SID です。Microsoft は MIC（必須整合性制御）で、低・中・高・システムの整合性レベルを使ってアクセスを制御すると説明しており、標準ユーザーや非昇格プロセスは通常「中」、昇格したユーザーは「高」になります。Administrators に入っているかだけではなく、今のプロセスが Medium なのか High なのかを見ることで、UAC による差をかなり正確に読めます。(Microsoft Learn)
なお、whoami /all に出ないグループをすぐに「所属していない」と断定するのは危険です。Microsoft は、whoami はログオン セッション SID を表示しないと案内しており、さらにトークンに含まれる domain local group は、どのドメインのコンピューターでトークンが作られたかでも変わります。サーバー A では見えるのにサーバー B では見えないのは、壊れているより「トークンの条件が違う」ケースが少なくありません。(Microsoft Learn)
PRIVILEGES INFORMATION は「システム操作の権利」を見る場所
PRIVILEGES INFORMATION は、ファイルやフォルダーの ACL を直接見る場所ではありません。Microsoft は、privilege はシャットダウンや時刻変更のようなシステム全体に関わる操作の権利であり、オブジェクトに設定されたアクセス権とは別物だと説明しています。つまり、whoami /all で特権が充実していても、ファイル共有やレジストリ キーのアクセス拒否がそのまま解決するわけではありません。そこは ACL 側の確認が必要です。(Microsoft Learn)
読み方の基本はシンプルです。行がないなら、そのトークンはその特権を持っていない。Disabled なら、特権自体はトークンにあるが、現在は有効化されていない。Enabled なら、今のトークンで有効です。Windows は特権操作の実行時に、必要な特権を保持しているか、その特権が有効かを確認します。また Microsoft は、多くの特権が既定では無効だと説明しています。(Microsoft Learn)
Disabled をすぐに「使えない」と読み切らないのもコツです。アクセス トークンには特権の有効・無効を切り替える仕組みがあり、アプリケーションや実行方法によっては必要時に有効化されることがあります。逆に、行そのものがない特権は、昇格しても勝手には増えないので、ローカル セキュリティ ポリシーやグループ ポリシー、アカウント設計の確認に進むべきサインです。(Microsoft Learn)
| 特権名 | ざっくりした意味 | 実務での見どころ |
|---|---|---|
SeBackupPrivilege | ファイルやディレクトリのバックアップ | バックアップ系ツール、退避処理、監査用取得で重要 |
SeRestorePrivilege | 復元操作、所有者設定など | リストア、所有者変更、移行ツールで重要 |
SeDebugPrivilege | 他プロセスのデバッグ | 解析ツール、診断ツール、特定の管理操作で確認対象 |
SeImpersonatePrivilege | 認証後のクライアント偽装 | サービス、サーバー処理、代理実行系で注目 |
SeSystemtimePrivilege | システム時刻の変更 | サーバー時刻変更や一部の設定変更で確認 |
SeTimeZonePrivilege | タイムゾーンの変更 | 時刻ではなくタイムゾーンだけ変えたい場面で確認 |
この中でも実務で混同しやすいのが SeSystemtimePrivilege と SeTimeZonePrivilege です。Microsoft の UAC 説明では、標準ユーザーは時計の表示確認やタイムゾーン変更はできても、ローカル システム時刻の変更には完全な管理者アクセス トークンが必要とされています。「時刻だけ変えられない」という問い合わせでは、この2つを見分けると切り分けが早くなります。(Microsoft Learn)
よくある症状ごとの読み解き方
次の表は、whoami /all を実務でどう使うかを症状ベースでまとめたものです。見出しごとに別ツールへ飛ぶ前に、この切り分けを入れるだけで無駄な調査がかなり減ります。(Microsoft Learn)
| 症状 | まず見る場所 | 典型的な読み方 | 次の一手 |
|---|---|---|---|
| 管理者なのにインストールや設定変更が失敗する | BUILTIN\Administrators、Mandatory Label | Administrators が deny only、または Medium なら非昇格の可能性が高い | 「管理者として実行」で開いたターミナルで再確認する |
| 通常起動では失敗するが、管理者として実行だと成功する | GROUP INFORMATION と PRIVILEGES INFORMATION | UAC によるトークン差が濃厚 | 通常起動版と昇格版の出力を並べて比較する |
| タイムゾーンは変えられるのに時刻は変えられない | SeSystemtimePrivilege と SeTimeZonePrivilege | 時刻変更に必要な特権や完全な管理者トークンが足りない可能性 | 昇格の有無と、どちらの特権を見ているかを確認する |
| サーバー A では通るのにサーバー B では拒否される | グループ一覧全体 | domain local group、ローカル グループ、ログオン種別の違いでトークン差が出ている可能性 | whoami /all だけで断定せず、GPO やローカル設定も見る |
| ファイルや共有だけ拒否される | 特権より ACL の観点 | user rights は十分でも、対象オブジェクトの ACL で拒否されることがある | 対象リソースの ACL、所有者、継承設定を確認する |
whoami /all が向く運用、向かない運用
whoami /all は万能ではありません。ただし、現在の実行トークンの把握という用途ではかなり強力です。逆に、ポリシーの出どころ、アカウント自体の設定、Kerberos セッションの状態まで全部を1本で見ようとすると限界があります。(Microsoft Learn)
| やりたいこと | whoami /all の向き | 併用したいもの |
|---|---|---|
| 現在の実行ユーザーと権限を確認したい | ◎ | whoami /all 本体で十分 |
| UAC の昇格有無を見たい | ◎ | 通常起動と昇格起動の比較 |
| 適用された GPO を見たい | △ | gpresult /r、詳しく見るなら /v や /z |
| アカウントの基本情報を見たい | △ | net user <ユーザー名>、必要なら /domain |
| Kerberos チケットを見たい | × | klist |
| クレーム ベースの情報を見たい | △ | whoami /claims |
整理すると、whoami /all が強いのは「いま失敗しているその実行コンテキストは何か」を見る場面です。GPO の原因追跡は gpresult、アカウント情報の確認は net user、Kerberos まわりは klist のほうが早いです。用途を分けると、調査がかなり短くなります。(Microsoft Learn)
実務で失敗しにくい確認手順
現場で迷ったら、次の順番で確認するのが堅実です。ポイントは、失敗している処理と同じ条件で whoami /all を取ることです。通常起動のアプリが失敗しているのに、昇格したターミナルの結果だけ見ても、原因を取り違えます。(Microsoft Learn)
- 失敗しているアプリと同じ起動方法で、CMD か PowerShell を開きます。UAC の差が疑わしいなら、通常起動版と「管理者として実行」版の両方を用意します。(Microsoft Learn)
whoami /allをそのまま見て終わらせず、listかcsvで保存します。後で比較しやすくなります。(Microsoft Learn)USER INFORMATIONでユーザー名と SID を確認し、想定したアカウントかを確定します。(Microsoft Learn)GROUP INFORMATIONでBUILTIN\Administratorsの属性とMandatory Labelを確認します。ここが UAC 切り分けの中心です。(Microsoft Learn)PRIVILEGES INFORMATIONで、必要な特権が「ない」のか、「あるが Disabled」なのか、「Enabled」なのかを見分けます。(Microsoft Learn)- トークンに問題がなければ、次は
gpresult、net user、klist、対象オブジェクトの ACL に進みます。whoami /allだけで粘りすぎないのがコツです。(Microsoft Learn)
比較用に残すなら、たとえば次の形が使いやすいです。出力形式は公式に list と csv が用意されています。(Microsoft Learn)
whoami /all /fo list > whoami-normal.txt
whoami /all /fo csv /nh > whoami-normal.csv
gpresult /r
net user <ユーザー名> /domain
klistありがちな読み違い
ありがちな誤解の1つ目は、Administrators に出ている = その場で管理者権限があると思い込むことです。実際には、Group used for deny only なら許可 ACE に使われません。名前だけで判断せず、属性まで見てください。(Microsoft Learn)
2つ目は、Disabled = その特権は存在しないと読むことです。Disabled は、その特権がトークン内にあるが現在有効ではない、という意味です。逆に、一覧に行がない特権は、そのトークンにありません。ここを取り違えると、不要な再インストールや不要なアカウント変更に走りがちです。(Microsoft Learn)
3つ目は、whoami /all に出ないグループは AD でも未所属だと決めつけることです。トークンに含まれる SID はログオン種別やコンピューター条件でも変わり、Microsoft も whoami がログオン セッション SID を表示しないと案内しています。特にサーバー間比較では、「AD の所属」と「そのサーバー上で生成されたトークン」を分けて考えたほうが安全です。(Microsoft Learn)
4つ目は、権限の問題なら whoami /all だけで完結すると考えることです。Windows のアクセス制御では、ユーザー権利とオブジェクトの ACL は別です。ファイル、フォルダー、共有、レジストリ、サービスの拒否は、トークン側でなく対象側の設定が原因のことも多いので、whoami /all で異常が見当たらなければ ACL の確認に進みましょう。(Microsoft Learn)
まとめ
whoami /all の結果から権限を読み解くコツは、ユーザー名ではなくトークンを見る意識を持つことです。まず USER INFORMATION で誰のトークンかを確定し、次に GROUP INFORMATION で Administrators の属性と Mandatory Label を見て、最後に PRIVILEGES INFORMATION で必要な特権の有無と状態を確認します。ここまでで見えないなら、次は gpresult、net user、klist、ACL の確認に移るのが最短です。次回からは、失敗しているアプリと同じ起動方法で whoami /all を取り、通常起動版と昇格版を比較するところから始めてください。(Microsoft Learn)
コメント