Windowsのコマンドプロンプトで、今そのコマンドを実行しているユーザーを確認するならwhoamiです。表示は通常「ドメインまたはPC名\ユーザー名」ですが、これだけでPCのActive Directory参加状態やMicrosoft Entra参加状態まで判定できません。ユーザーの所属、UPN、PCの参加先を分けて調べましょう。
最短手順:通常のcmdでwhoamiを実行する
スタートで「cmd」を検索してコマンドプロンプトを開きます。Windowsキー+Rでcmdを実行する方法や、エクスプローラーのアドレスバーでcmdを入力する方法でも開けます。自分の現在の実行ユーザーを調べるだけなら、管理者としての実行は通常不要です。
whoami
以下は説明用の出力例です。実際の表示は環境により異なります。
corp\john.doe
この例ではcorpがアカウントのドメイン部分、john.doeがユーザー名です。ローカルアカウントではPC名が前半に出るため、「バックスラッシュの前に文字がある=ADドメインユーザー」とは限りません。別ユーザーとして起動したcmdやタスクでは、その実行アカウントの情報が返ります。
目的別:何を確認したいかでコマンドを選ぶ
実行中のユーザー:whoami。
ユーザー名とSID:whoami /user。
UPN形式のユーザー名:whoami /upn(対応するドメインアカウント等の条件が必要)。
PCのAD参加状態:Win32_ComputerSystemのPartOfDomainとDomain。
Microsoft Entraの参加・登録状態:dsregcmd /statusの各セクション。
Microsoftのwhoami公式仕様では、引数なしの表示、UPN、ユーザーSID、グループ、特権を区別しています。UPN、ドメインのDNS名、メールアドレス、PCのDNSサフィックスを同一視しないことが重要です。
UPNを確認する:/upnと/fqdnを混同しない
whoami /upn
UPNの説明例は[email protected]のような形式です。UPNのサフィックスは組織で構成され、ADのDNSドメイン名やメールアドレスと必ず一致するわけではありません。単に@の後ろを切り取って「PCの参加ドメイン」とする方法は避けます。
whoami /fqdnは別のユーザー名形式を求めるオプションであり、[email protected]を取得するための指定ではありません。UPNが目的なら/upnを使います。/upnや/fqdnはローカルアカウントなどでは取得できない場合があるため、エラーだけでWindowsの破損やドメイン離脱と判断しないでください。
環境変数のUSERDOMAINは補助情報として扱う
cmdでは次のように現在プロセスの環境変数を表示できます。PowerShellでは%変数名%ではなく$env:変数名です。
echo %USERDOMAIN%
echo %USERDNSDOMAIN%
echo %USERNAME%
USERDOMAINはローカルアカウントではPC名になることがあり、USERDNSDOMAINはアカウントや環境によって未定義の場合があります。環境変数はプロセス内で変更できるため、アクセス許可の判定や本人確認の根拠にはしません。whoamiの出力との違いは、起動ユーザーや環境の継承を調べる手掛かりです。
PCが参加しているADドメインを確認する
次はPowerShellで実行する読み取りコマンドです。ユーザーの所属ではなく、そのPCの情報を取得します。
Get-CimInstance Win32_ComputerSystem |
Select-Object Name, PartOfDomain, Domain, Workgroup
Win32_ComputerSystemの仕様に従い、PartOfDomainとDomainを組み合わせて読みます。PartOfDomainがFalseならDomainにはワークグループ名が返るため、Domainという列名だけでAD参加と判定しません。AD参加PCへローカルユーザーでサインインする場合もあり、whoamiの前半と違っていても矛盾とは限りません。
cmdから呼び出す場合は次の1行です。WMICの利用を前提にせず、利用可能なPowerShellのCIMコマンドで確認します。
powershell.exe -NoProfile -Command "Get-CimInstance Win32_ComputerSystem | Select-Object Name,PartOfDomain,Domain,Workgroup"
Microsoft Entra参加・ハイブリッド参加・登録を見分ける
dsregcmd /status
Microsoftのdsregcmd解説に沿って、Device StateのAzureAdJoinedとDomainJoinedを読みます。一般的な判定は次のとおりです。
AzureAdJoined = YES、DomainJoined = NO:Microsoft Entra参加。
AzureAdJoined = NO、DomainJoined = YES:ADドメイン参加。
両方YES:Microsoft Entraハイブリッド参加。
職場アカウントの登録(WorkplaceJoined)はUser Stateで別に確認します。
ユーザー状態やSSO状態を見るときは、調べたい利用者の通常のセッションで実行します。管理者として別ユーザーで起動すると、ユーザー依存の結果が変わる場合があります。テナント名が見えることやAzureAdJoinedだけで、端末準拠・条件付きアクセス・すべてのアプリへのサインイン成功まで証明できるわけではありません。
出力にはテナント、端末識別子、ユーザー情報が含まれます。公開掲示板へ全量を貼らず、管理者へ必要部分だけを安全に渡します。状態確認のためにdsregcmd /leaveやアカウント切断を実行する必要はありません。
whoamiの詳細オプションを使い分ける
whoami /user
whoami /groups
whoami /priv
whoami /all
whoami /logonid
/userは現在のアカウント名とユーザーSID、/groupsは現在のトークンに含まれるグループ、/privは特権を表示します。/allはユーザー・グループ・特権などの情報をまとめる指定で、UPNや/fqdnを含むすべての独立オプションをそのまま連結する意味ではありません。
/logonidは現在のログオンIDを確認するもので、ユーザーSIDやドメイン名とは別です。出力形式を確認せず、イベントログで見た16進数の値をそのまま期待しないでください。管理者権限の有無をドメイン名だけで判断せず、必要ならグループ属性や特権と対象操作を照合します。
ユーザードメインを表示するバッチとPowerShellの例
次はgetUserDomain.batとして保存する例です。DOMAIN部分だけを切り出すのではなく、実行アカウント全体を残すことで、ローカルアカウントやサービスアカウントとの取り違えを減らします。各行を改行したまま保存してください。
@echo off
whoami
if errorlevel 1 exit /b 1
pause
pauseは手動で画面を読むためのものです。タスクスケジューラなど無人実行では待ち続ける原因になるため使いません。ダブルクリックでは一瞬で閉じる場合があるので、確認時はcmdを開いてそこから実行するとエラーを読めます。
次はPowerShell用のGet-UserDomain.ps1です。WindowsIdentityで取得する名前も、現在の実行コンテキストの情報です。
$identity = [System.Security.Principal.WindowsIdentity]::GetCurrent()
[pscustomobject]@{
Account = $identity.Name
UserSid = $identity.User.Value
}
保存場所へ移動して.\Get-UserDomain.ps1で実行します。コードはPowerShellであり、.batに保存しません。スクリプト実行が組織ポリシーで制限される場合は、管理者へ承認済みの実行方法を確認してください。
タスクスケジューラで調べる場合の注意
タスクがSYSTEMや別管理者として動けば、そのアカウントが結果になります。デスクトップを操作中の利用者を自動的に探すスクリプトではありません。収集したい対象を先に決め、実行アカウント、開始フォルダー、保存先、出力のアクセス権を確認します。
PowerShellスクリプトの操作設定では、プログラムにpowershell.exe、引数に-NoProfile -Fileと実際のスクリプトの引用符付きパスを指定する方式を使います。実行ポリシー回避オプションを足すのではなく、組織の署名・配布方法に従います。定期実行を作る前に、同じアカウントで手動確認し、保存結果とエラーを読めることを確認します。
コマンドが見つからない・アクセスが拒否されるとき
「whoamiが認識されない」場合は、入力、実行場所、PATHを確認します。cmdでは次のようにWindows標準の場所を指定して確認できます。別サイトからwhoami.exeをダウンロードする必要はありません。
"%SystemRoot%\System32\whoami.exe"
where whoami
アクセス拒否なら、実行ファイルやスクリプトの権限、アプリ制御、組織の制限を確認します。常に管理者として実行すればよいわけではなく、別ユーザーで昇格すると調べたい本人の結果から変わることがあります。PATH全体やシステム権限を一括変更せず、表示されたエラーを管理者へ伝えます。
PowerShellの実行ポリシーを調べる読み取りコマンドは次のとおりです。
Get-ExecutionPolicy -List
Get-ExecutionPolicyの公式仕様でスコープごとの状態を確認できます。ユーザー名を調べる目的だけでUnrestrictedへ変更したり、端末全体の実行制限を解除したりしません。whoamiを直接実行して済む場面では、スクリプト化自体が不要です。
関連するネットワーク情報は、必要なときだけ追加確認する
ipconfigはIP構成、netsh interface show interfaceはインターフェイスの状態、netstatは接続情報、ipconfig /displaydnsはDNSキャッシュの確認に使います。ただし、これらの出力だけではユーザーのAD所属やPCの参加状態を証明できません。特に接続固有のDNSサフィックスをユーザードメインと混同しないでください。
ipconfig
netsh interface show interface
netstat
ipconfig /displaydns
ネットワーク出力やDNSキャッシュは内部アドレスやアクセス先を含むことがあります。調査に不要な情報まで集めたり公開したりせず、関連する症状がある場合だけ利用します。
確認練習とまとめ
1. 通常のcmdでwhoamiを実行し、アカウント全体を記録する。
2. whoami /userと比較し、名前とSIDが別の情報であることを確認する。
3. PCの所属が必要な場合だけPartOfDomainとDomainを確認する。
4. Entra環境ではdsregcmd /statusのDevice StateとUser Stateを区別する。
5. タスク実行時は、対話ユーザーではなくタスクのアカウントが対象になることを確認する。
ユーザードメインの取得は、何の所属情報が欲しいのかを明確にすることが出発点です。whoamiのアカウント、UPN、PCのAD参加先、Entra参加状態を切り分ければ、不要な昇格やセキュリティ設定変更をせずに調査できます。この記事の出力例は説明用であり、更新時にWindows実機で動作を再現した結果ではありません。


コメント