Windows 11 へアップグレード後、RSAT の ActiveDirectory モジュールで Get-ADPrincipalGroupMembership を実行すると「ユーザーが認証されていません」で失敗することがあります。本記事では原因の考え方と、-Credential で確実に解決する手順をまとめます。
発生する症状とエラーメッセージ
Windows 10 から Windows 11 にアップグレードした後、Active Directory のユーザーが所属しているグループ一覧を CSV 出力しようとして、次のような手順で突然エラーになるケースがあります。
- PowerShell を「別ユーザーとして実行」で管理者資格情報（例：ドメイン管理者や権限を持つ運用アカウント）で起動
Import-Module ActiveDirectoryGet-ADPrincipalGroupMembership -Identity "UserName" | Export-Csv ...- しかし
The operation being requested was not performed because the user has not been authenticated（要求された操作は、ユーザーが認証されていないため実行されませんでした 等）で失敗する
なお、PowerShell 7（pwsh.exe）ではなく、Windows PowerShell 5.1（powershell.exe）で実行していることを確認済み、という前提で話を進めます。
| 項目 | 内容 |
|---|---|
| 対象コマンド | Get-ADPrincipalGroupMembership（ActiveDirectory モジュール） |
| 主な用途 | ユーザーの所属グループ一覧を取得して CSV に出力（ネストされたグループを含めて把握したい場面でよく使う） |
| 代表的なエラー | The operation being requested was not performed because the user has not been authenticated |
| よくある誤解 | 「別ユーザーとして実行」＝ AD への認証も必ずそのユーザーで行われる、とは限らない |
なぜ「別ユーザーとして実行」だけでは失敗することがあるのか
結論から言うと、PowerShell を別ユーザーで起動できていても、Active Directory への通信（LDAP / ADWS など）が期待した資格情報で認証されない状況があり得ます。特に Windows 11 端末では、端末のセキュリティ設定（VBS、Credential Guard、Windows Hello for Business など）や、ログオン方式・権限分離（UAC）によって「ローカルでの実行ユーザー」と「ネットワーク認証に使われる資格情報」がズレることがあります。
もう少し噛み砕くと、次のようなパターンが原因候補として挙げられます。
- 昇格（管理者権限）と認証（ドメインへのログオン/SSO）は別物で、管理者として起動できた＝AD にも自動で通る、とは限らない
- 別ユーザーとして起動しても、そのユーザーの Kerberos/NTLM チケットが十分に取得されていない、または利用されない
- ActiveDirectory モジュールが内部的に利用する通信経路（ADWS など）で、暗黙の認証がうまくはまらず失敗する
- 実は AD に到達できておらず（DNS、VPN、FW、プロキシ等）、結果として「認証されていない」に見える
この手の「認証コンテキストがズレる問題」は、同じ操作をしても端末やセキュリティ基準、ドメイン側の設定差で発生有無が変わるため、原因追跡に時間がかかりがちです。そこで、最短で確実な解決策として「コマンド側で資格情報を明示する」方法が有効になります。
解決策：-Credential で管理者資格情報を明示して実行する
対処の要点はシンプルです。Get-ADPrincipalGroupMembership に -Credential を付けて、AD に対して使う資格情報を明示します。これにより「別ユーザーとして実行」の挙動に依存せず、意図したアカウントで AD へ認証して処理できます。
ワンライナーでまず確認（その場で原因を切り分け）
最初の確認としては、次のワンライナーが手早いです。これで通るなら「資格情報の明示が必要な環境」という当たりが付きます。
Import-Module ActiveDirectory
Get-ADPrincipalGroupMembership -Identity "UserName" -Credential (Get-Credential) |
Select-Object Name, GroupScope, GroupCategory推奨の実行例（CSV 出力まで）
Import-Module ActiveDirectory
$cred = Get-Credential # 管理者アカウントを入力（例：DOMAIN\AdminUser）
Get-ADPrincipalGroupMembership -Identity "UserName" -Credential $cred |
Export-Csv -Path "C:\scripts\usermembershipreport.csv" -NoTypeInformationポイントは次の通りです。
Get-Credentialで対話的に資格情報を取得し、そのまま-Credentialに渡す- PowerShell セッションの実行ユーザーが誰であっても、AD 側の認証は
$credを優先して実施される - 原因切り分けの段階でも、この方法なら「認証コンテキストのズレ」を一気に回避できる
ドメインコントローラーを明示する例（複数ドメイン/名前解決が怪しいとき）
ドメイン環境によっては、参照先を明示することで安定することがあります。拠点間 VPN や DNS のゆらぎがある場合は、まず 1 台の DC に固定して成功/失敗を切り分けるのがコツです。
Import-Module ActiveDirectory
$cred = Get-Credential
Get-ADPrincipalGroupMembership -Identity "UserName" -Credential $cred -Server "dc01.contoso.local" |
Export-Csv -Path "C:\scripts\usermembershipreport.csv" -NoTypeInformation複数ユーザーをまとめて CSV 出力する例（実務向け）
ユーザー名を複数扱う場合は、出力に「どのユーザーの行なのか」を残しておくと後工程が楽です。次の例では、ユーザー一覧ファイル（1行1ユーザー）を読み、所属グループをまとめて出力します。
Import-Module ActiveDirectory
$cred = Get-Credential
# 例：C:\scripts\users.txt に samAccountName を1行ずつ並べる
$users = Get-Content -Path "C:\scripts\users.txt"
$rows = foreach ($u in $users) {
try {
Get-ADPrincipalGroupMembership -Identity $u -Credential $cred |
Select-Object @{Name='User';Expression={$u}},
Name, SamAccountName, GroupCategory, GroupScope, DistinguishedName
}
catch {
# 取得できないユーザーがいても全体処理を止めない
[pscustomobject]@{
User = $u
Name = ''
SamAccountName = ''
GroupCategory = ''
GroupScope = ''
DistinguishedName = ''
Error = $_.Exception.Message
}
}
}
$rows |
Export-Csv -Path "C:\scripts\usermembershipreport.csv" -NoTypeInformation -Encoding UTF8上の例では、正常行とエラー行が混ざっても CSV で後追いできるようにしています。運用現場では「途中の1ユーザーで止まる」のが一番つらいので、例外処理を入れておくと安全です。
-Credential で解消する理由（仕組みを押さえる）
Active Directory モジュールの cmdlet は、裏側で DirectoryServices や ADWS などを利用して対象のドメインコントローラーへ問い合わせます。その際、資格情報が明示されていない場合は、Windows の認証情報（現在のログオンコンテキスト、チケット、SSPI の状態など）に依存して認証が行われます。
しかし、次のような状況では「ローカルでは別ユーザーとして実行できているのに、ネットワーク側では期待した資格情報にならない」ことがあります。
- 端末がドメイン参加していない（または VPN 未接続）ため、ドメインの SSO 前提が崩れている
- 管理者アカウントがスマートカード/Windows Hello など特定方式でログオンしており、チケット取得の前提が異なる
- 端末側のセキュリティ（Credential Guard など）により、資格情報の委任・取り回しが制限される
- ネットワーク経路の問題で DC へ到達できず、認証処理が完了しない
-Credential を付けると、cmdlet 側が指定された資格情報を使って明示的に接続（バインド）しにいくため、上記の「暗黙の認証」に左右されにくくなります。結果として、今回のようなエラーは解消するケースが多いです。
追加の切り分け：委任（delegation）関連の設定を確認する
質問の環境によっては、管理者アカウントの「委任」関連設定が影響することがあります。具体的には、AD ユーザーのプロパティで「このアカウントは委任できない」（Account is sensitive and cannot be delegated）が有効だと、特定の認証経路・実行形態で想定外の認証トラブルにつながることがあります。
状態確認は次で行えます。
(Get-ADUser <YourAdminAcct> -Property accountnotdelegated).accountnotdelegated| 結果 | 意味 | 考えられる影響 |
|---|---|---|
| false | 委任不可フラグは無効 | この要因での問題は起きにくい（ただし他要因はあり得る） |
| true | 委任不可フラグが有効 | 環境によっては資格情報の受け渡しが制限され、SSO 前提の操作が不安定になることがある |
このフラグ自体はセキュリティ上の意味があるため、安易に無効化するのではなく、まずは本記事の推奨通り -Credential で回避できるかを優先してください。どうしても運用上の制約がある場合は、ドメイン管理者と相談しながら「グループ参照用の運用アカウントを別途用意する」など、より安全な落としどころを検討するのが現実的です。
それでも失敗するときのチェックリスト
-Credential を付けても失敗する場合は、認証以前に「到達性」や「前提条件」の問題が隠れていることがあります。次の項目を上から順に潰すと、原因の当たりを付けやすくなります。
| チェック項目 | 確認コマンド例 | 意図 |
|---|---|---|
| ActiveDirectory モジュールが読み込めるか | Get-Module -ListAvailable ActiveDirectory | RSAT/モジュールのインストール状態を確認 |
| Windows PowerShell 5.1 で実行しているか | $PSVersionTable.PSVersion | pwsh ではなく powershell.exe であることを再確認 |
| AD への最小クエリが通るか | Get-ADUser -Identity "UserName" -Credential $cred | 「ユーザー取得すらできない」のか「所属グループ取得だけ失敗」なのかを切り分け |
| ドメインコントローラーへ名前解決できるか | Resolve-DnsName <DC名> | DNS が崩れると認証も不安定になりやすい |
| ADWS/LDAP へ到達できるか | Test-NetConnection -ComputerName <DC名> -Port 9389 | ADWS を利用する経路の疎通確認（環境により必要） |
| 現在の実行ユーザー/チケットの状況 | whoami / klist | 想定通りのアカウントで動いているか、Kerberos チケットがあるかを見る |
特に、端末が社外に持ち出される運用（VPN 前提）だったり、Windows 11 の端末セキュリティが強化されている環境では、ネットワーク到達性の問題が「認証エラー」として表面化することがあります。まずは DC へ名前解決・疎通できる状態を作るのが先決です。
回避策：memberOf 属性から「直接所属グループ」だけ取得する
どうしても Get-ADPrincipalGroupMembership が通らない／資格情報入力を避けたい（作業手順を簡略化したい）場合、代替としてユーザーの memberOf 属性から「直接所属しているグループ」だけ取得する方法があります。
ただし、この方法には重要な制約があります。
- ネストされたグループ（入れ子の所属）は追えない
- primary group（既定では Domain Users など）は
memberOfに出ないため、見落としが発生することがある
最小の例（DN の一覧をそのまま出す）
Get-ADUser -Identity "UserName" -Properties memberOf |
Select-Object -ExpandProperty memberOfグループ名に変換して見やすくする例
Get-ADUser -Identity "UserName" -Properties memberOf |
Select-Object -ExpandProperty memberOf |
Get-ADGroup |
Select-Object Name, GroupScope, GroupCategory「まずは直接所属だけで良い」「ネストは別の工程で処理する」と割り切れるなら、memberOf ベースは軽量で扱いやすい選択肢です。一方で、権限監査やアクセス権調査など「実効権限」を見たい場面ではネストを追う必要があるため、基本は Get-ADPrincipalGroupMembership を使える状態に戻すのがおすすめです。
どの取得方法を選ぶべきか（比較表）
| 方法 | ネストされたグループ | primary group | 資格情報の扱い | 向いている用途 |
|---|---|---|---|---|
| Get-ADPrincipalGroupMembership | 追える（実効に近い一覧になりやすい） | 環境により含まれる/扱える | Win11では暗黙認証が不安定な場合あり → -Credential 推奨 | 権限監査、棚卸し、CSVレポート |
| Get-ADUser -Properties memberOf | 追えない | 含まれない | 比較的シンプル（ただしAD照会なので結局は認証が必要） | 直接所属の確認、簡易レポート |
| 運用アカウントでログオンして実行 | 追える | 環境依存 | 対話入力不要だが、端末切替や手順が重い | 手動作業、踏み台端末での運用 |
運用でのおすすめ：最小権限のアカウントを使う
グループ参照（読み取り）だけが目的なら、強い権限（例：Domain Admin）を日常作業に使うのは避けた方が安全です。可能であれば、次のような方針にすると事故リスクを下げられます。
- 「参照専用」の運用アカウントを用意し、必要最小限の権限だけ付与する
- スクリプトは
-Credentialを前提にし、誰の端末で実行しても同じ結果になるようにする - パスワードを平文で埋め込まない（
Get-Credential、資格情報マネージャー、組織の秘密情報管理に従う）
よくある質問
PowerShell を「別ユーザーとして実行」しているのに、なぜ -Credential が必要なのですか？
「別ユーザーとして実行」はローカルの実行コンテキストを切り替える手段ですが、AD への認証が常にそのユーザーに揃うとは限りません。Windows 11 では端末のセキュリティ機能や実行形態の違いで SSO の前提が崩れやすく、-Credential で接続に使う資格情報を明示した方が確実です。
pwsh（PowerShell 7）だとダメですか？
ActiveDirectory モジュールは Windows PowerShell 5.1 を前提とする場面が多く、PowerShell 7 での互換性レイヤー経由だと挙動が変わることがあります。まずは powershell.exe（5.1）での実行を基準にし、必要に応じて Windows PowerShell の互換セッションを使うのが安全です。
-Credential を使うと毎回パスワード入力が必要で面倒です
対話入力を減らしたい場合は、実行端末・実行ユーザーを固定した上で、資格情報の扱いを工夫します。たとえば、同一ユーザー/同一端末に限定して暗号化保存できる Export-Clixml を使う方法があります（共有や別端末移動には向きません）。
# 初回のみ：資格情報を保存（このPCのこのユーザーだけ復号可能）
$cred = Get-Credential
$cred | Export-Clixml -Path "C:\scripts\ad_cred.xml"
# 2回目以降：読み込み
$cred = Import-Clixml -Path "C:\scripts\ad_cred.xml"運用要件によっては、Windows 資格情報マネージャーや専用の運用アカウント、スケジュール実行用のサービスアカウント（組織のルールに従う）など、別の選択肢が適切な場合もあります。いずれにせよ、パスワードを平文でスクリプトに埋め込むのは避けてください。
まとめ
- Windows 11 / RSAT 環境で
Get-ADPrincipalGroupMembershipが「ユーザーが認証されていません」で失敗することがある - 「別ユーザーとして実行」だけでは、AD への認証コンテキストが期待通りにならない場合がある
- 最も確実な対処は
-Credentialで資格情報を明示して実行すること - 委任設定（
accountnotdelegated）や到達性（DNS/ポート）も併せて確認すると切り分けが早い - 回避策として
memberOfから直接所属のみ取得する方法もあるが、ネストや primary group に注意
結論として、今回のケースは -Credential を付けて実行することで解消することが多く、再発防止の観点でもスクリプト側で明示しておくのがおすすめです。
コメント