Windows LAPS実務ガイド ── 全PC共通のローカル管理者パスワードをやめる

キッティングの現場には、長く続いてきた「定番の手抜き」があります。マスターイメージに共通のローカル管理者パスワードを焼き込み、全台に展開する ── 保守に入るときはそのパスワードでログオンすればよいので、手順としては合理的に見えます。しかし、この構成はいま、攻撃者にとっての「合鍵の量産」として真っ先に狙われるポイントになっています。1台の侵害が、そのまま全台の侵害に変わるからです。

この記事では、中小企業の情シス担当者と、PCキッティング・保守運用を請け負う開発者を対象に、共通ローカル管理者パスワードがなぜ危険なのかを整理したうえで、その解決策としてOSに組み込まれたWindows LAPS(Local Administrator Password Solution)の仕組み、環境別の使い分け、導入手順、運用の落とし穴までを、2026年8月時点の一次情報にもとづいて解説します。BitLocker・WSUS廃止・ファイアウォール・証明書ストアと続けてきた情シス向けセキュリティ連載の続編です。

1. まず結論

• 全PC共通のローカル管理者パスワードは、1台の侵害を全台に広げる横展開(ラテラルムーブメント)の温床です。パスワードが同じならNTLMハッシュも同じなので、1台からハッシュを抜かれると残り全台にPass-the-Hashで入られます。¹
• Windows LAPSは、ローカル管理者パスワードを端末ごとにランダム化し、自動ローテーションするOS標準機能です。Pass-the-Hash・横展開への対策として、Microsoftが利点の筆頭に挙げています。¹
• 2023年4月11日の更新プログラム以降のWindows 10/11、Windows Server 2019/2022以降に組み込まれています。旧LAPS(MSI配布)と違い、追加インストールは不要です。旧LAPSはWindows 11 23H2以降で非推奨になりました。¹
• パスワードの保存先はActive DirectoryかMicrosoft Entra IDのどちらか一方です。ドメイン参加のみの端末はADへ、Entra参加のみの端末はEntra IDへ、ハイブリッド参加はどちらかを選択します。どちらにも参加していないワークグループ端末では使えません。¹
• 既定では何も起きません。BackupDirectoryの既定値は「無効」なので、ポリシー(GPOまたはIntune/CSP)で保存先を明示して初めて動き出します。²
• AD保存では事前準備が3つ必要です。スキーマ拡張(Update-LapsADSchema)、コンピューター自身の書き込み権限(Set-LapsADComputerSelfPermission)、閲覧権限の設計(Set-LapsADReadPasswordPermission)です。³
• パスワードの確認は Get-LapsADPassword / Get-LapsAADPassword、即時反映は Invoke-LapsPolicyProcessing、端末側での即時ローテーションは Reset-LapsPassword です。⁴
• 使われたパスワードは自動で使い捨てになります。管理対象アカウントでの認証後、既定では24時間でリセット+サインアウト(PostAuthenticationActions)が実行されます。²

2. なぜ全PC共通のローカル管理者パスワードが危険か

まず脅威の構図を正確に押さえます。ローカル管理者アカウント(いわゆるビルトインAdministratorや、キッティング時に作る保守用アカウント)のパスワードを全台で共通にすると、何が起きるのでしょうか。

Windowsは、ローカルアカウントのパスワードをそのままではなく、パスワードから計算したNTハッシュとして保持しています。そしてNTLM認証では、このハッシュそのものが認証の材料になります。つまり、パスワードが同じなら、ハッシュも全台で同じです。攻撃者がマルウェアや標的型攻撃で1台の管理者権限を取ると、その端末のメモリやローカルデータベース(SAM)からハッシュを取り出せます。ここからが本番で、取り出したハッシュは平文パスワードに戻さなくてもそのまま認証に使えます。これがPass-the-Hash攻撃です。共通パスワード環境では、1台から得たハッシュが残り全台への「合鍵」になり、侵害が一気に横へ広がります。NTLM認証の仕組みとなぜハッシュだけで認証が通るのかは「図解でわかるNTLMとKerberos」で詳しく説明しています。

flowchart TB
    subgraph BEFORE["共通パスワード環境"]
        A1["PC-01を侵害<br/>(マルウェア・標的型攻撃)"] --> H["管理者のNTハッシュを取得"]
        H -->|"Pass-the-Hash"| B1["PC-02"]
        H -->|"Pass-the-Hash"| B2["PC-03"]
        H -->|"Pass-the-Hash"| B3["…全台に横展開"]
    end
    subgraph AFTER["LAPS導入後"]
        C1["PC-01を侵害"] --> H2["PC-01のハッシュを取得"]
        H2 -->|"パスワードが端末ごとに違うので"| STOP["他のPCではこのハッシュで<br/>認証できない(ローカル管理者<br/>経由の横展開を遮断)"]
    end

対策の方向性は明確で、端末ごとにローカル管理者パスワードを別々にし、しかも定期的に変えることです。そうすれば、1台のハッシュが漏れても他の端末では使えず、ローカル管理者アカウントの使い回しという横展開経路を断てます(侵害されたPC上のドメイン資格情報の窃取など、他の横展開経路まで塞がるわけではない点には注意してください)。しかし、これを手作業でやるのは現実的ではありません。数十台のパスワードを個別に生成し、台帳で管理し、定期的に更新して回る ── この運用コストの高さこそが、共通パスワードという手抜きが生き残ってきた理由です。この「個別化と定期変更の自動化」を、ディレクトリへの安全な保存とセットでOS側が引き受けるのがWindows LAPSです。Microsoft自身、Windows LAPSの利点の筆頭に「Pass-the-Hash攻撃と横展開(lateral-traversal)攻撃からの保護」を挙げています。¹

なお、そもそも日常業務を管理者アカウントで行わない・保守用アカウントの用途を絞る、という特権管理の基本については「Windowsの管理者特権が必要になるのはいつなのか」も参照してください。

3. Windows LAPSとは何か ── 旧LAPSとの違い

LAPSという名前には歴史があり、実務では「どのLAPSの話か」を区別しないと会話がかみ合いません。

旧LAPS(レガシーMicrosoft LAPS)は、Microsoftが2016年に公開した追加インストール型のツールです。¹ MSIパッケージを全端末に配布してグループポリシー拡張(CSE)を入れ、パスワードをActive Directoryの ms-Mcs-AdmPwd 属性に平文で保存する構成で、長く事実上の標準でした。

Windows LAPSは、その後継としてOSに組み込まれた別実装です。2023年4月11日の更新プログラム以降のWindows 10、Windows 11 21H2/22H2、Windows Server 2019/2022に含まれ、Windows 11 23H2以降とWindows Server 2025以降には最初から入っています。¹ つまり、更新プログラムを普通に適用している環境なら、社内のPCにはすでにWindows LAPSが入っています。あとはポリシーを設定するだけです。

重要なのは、Windows LAPSが旧LAPSの改修版ではなく完全に別の実装であり、ADのスキーマ属性も旧LAPSとは別(msLAPS-*)だという点です。⁴ 旧LAPSからの移行を助けるために、旧LAPSのGPO設定をWindows LAPSが解釈して動く「エミュレーションモード」も用意されていますが、これには制約が多く(6章)、新規導入でわざわざ使う理由はありません。

4. どこにパスワードが保存されるか ── 環境別の判断表

Windows LAPSは、生成したパスワードをディレクトリに「バックアップ」します。保存先は端末の参加状態で決まり、ADとEntra IDの両方に保存することはできません。¹

AD保存の場合、パスワードはコンピューターオブジェクトの属性(平文なら msLAPS-Password、暗号化有効なら msLAPS-EncryptedPassword、期限は msLAPS-PasswordExpirationTime)に書き込まれます。⁶ このうちパスワードを含む属性(msLAPS-Password と暗号化系の msLAPS-Encrypted*)は機密属性(confidential)としてマークされ、通常の読み取り権限では参照できません。一方、期限の msLAPS-PasswordExpirationTime には機密マークがなく(SearchFlags: 0)、既定の読み取り権限で参照できるメタデータです。⁶暗号化保存とパスワード履歴を使うにはドメイン機能レベル(DFL)2016以上が必要です。³ 注意したいのは、暗号化設定(ADPasswordEncryptionEnabled)の既定値が有効だという点です。² DFLが2016より古いドメインでは暗号化は使えないため、自動的に平文へ切り替わることを当てにせず、ポリシーで暗号化を明示的に無効化して平文+ACL保護で保存する構成にします。³

Entra ID保存の場合は、テナント側で「ローカル管理者パスワードの管理」を有効にしたうえで、IntuneからLAPS CSP経由でポリシーを配布するのが標準構成です。ライセンス面では、Windows LAPSの機能自体は無料で、AD保存に追加要件はなく、Entra ID保存もMicrosoft Entra ID Free以上で利用できます。¹

ワークグループ端末に代替策がないのは、保存先となるディレクトリが存在しない以上どうにもなりません。現実的には、キッティング時に端末ごとに異なるパスワードを設定し、パスワードマネージャー等で台帳管理する手動運用になります。キッティングをスクリプト化しているなら、その中に端末別パスワードの生成を組み込むのが確実です(「winget + PowerShellでPCキッティングを自動化する」参照)。

5. 導入手順の実務 ── AD+GPO構成を軸に

ここでは件数の多いADドメイン+GPO構成を軸に、実際の手順を追います。Entra+Intune構成との違いは末尾にまとめます。

5.1. 事前準備(1回だけの作業)

AD保存では、ポリシーを配る前にフォレスト側の準備を済ませます。³

# 1. スキーマ拡張(フォレストで1回だけ。Schema Admins権限で実行)
Update-LapsADSchema

# 2. 対象OU配下のコンピューターに、自分のパスワード属性を更新する権限を付与
Set-LapsADComputerSelfPermission -Identity "OU=社内PC,DC=example,DC=co,DC=jp"

# 3. パスワードを閲覧できるグループを付与(Domain Adminsは既定で閲覧可能)
Set-LapsADReadPasswordPermission -Identity "OU=社内PC,DC=example,DC=co,DC=jp" `
    -AllowedPrincipals @("EXAMPLE\HelpdeskAdmins")

# 4. パスワード期限を操作(即時失効=リセット指示)できるグループを付与
#    (5.4の Set-LapsADPasswordExpirationTime に必要。Domain Adminsは既定で可能)
Set-LapsADResetPasswordPermission -Identity "OU=社内PC,DC=example,DC=co,DC=jp" `
    -AllowedPrincipals @("EXAMPLE\HelpdeskAdmins")

# 5. 想定外の閲覧権限保持者がいないか確認(6章で詳述)
Find-LapsADExtendedRights -Identity "OU=社内PC,DC=example,DC=co,DC=jp"

暗号化保存(DFL 2016以上、既定で有効)を使う場合は、もうひとつ設定が要ります。閲覧権限と復号権限は別物で、復号できるのは既定でDomain Adminsだけです。³ ヘルプデスクのグループに実際にパスワードを取得させたいなら、ポリシー側の ADPasswordEncryptionPrincipal にも同じグループ(EXAMPLE\HelpdeskAdmins)を指定してください。² これを忘れると、上の手順どおりに閲覧権限を与えても「属性は読めるのに復号できない」状態になります。

Update-LapsADSchema は旧LAPSの Update-AdmPwdADSchema とは別物で、追加されるのは msLAPS-* 属性です。旧LAPS導入済みの環境でも、Windows LAPS用のスキーマ拡張は改めて必要です。⁴ なお、GPOの中央ストア(Central Store)を使っている場合、Windows LAPSのテンプレートはWindows Updateでは中央ストアにコピーされないため、手動でコピーします。² このとき %windir%\PolicyDefinitions\LAPS.admx だけでなく、言語リソースの LAPS.adml(日本語UIなら ja-JP サブフォルダー内)も対応する言語フォルダーへ一緒にコピーしてください。ADMLが無いと、GPMCでLAPSポリシーの表示がリソースエラーになります。

5.2. ポリシー設定

GPOの設定場所は「コンピューターの構成 > ポリシー > 管理用テンプレート > システム > LAPS」です。² 最低限の必須設定は保存先の指定で、BackupDirectoryを「Active Directory」(値2)にしない限り、Windows LAPSは何もしません(既定値は「無効」)。² 主要な設定と既定値は次のとおりです。

ここで見落としがちなのが、管理対象アカウントの有効/無効です。ビルトインAdministratorは、Windowsセットアップの時点で無効化されています。⁷ Windows LAPSは無効のままのアカウントでもパスワードを管理しますが、アカウントの有効化まではしません。² つまり既定構成のままでは「パスワードはディレクトリに保存されているのに、そのアカウントでは誰もサインインできない」状態になり得ます。復旧手段として使うには、ビルトインAdministratorを有効化して運用する、有効化済みのカスタム保守アカウントを管理対象にする、またはWindows 11 24H2 / Server 2025以降なら自動アカウント管理(AutomaticAccountManagement系設定)で有効状態ごと管理する、のいずれかを明示的に選んでください。²

5.3. 動作確認とパスワードの取得

Windows LAPSは有効なポリシーを1時間ごとに処理します。適用を待たずに確認したいときは、対象端末で即時処理を実行します。³

# 端末側: ポリシーを即時処理(検証時の定番)
Invoke-LapsPolicyProcessing

# 端末側: イベントログで結果を確認
# 10003=処理開始 / 10004=成功 / 10005=失敗 / 10018=ADへの保存成功
Get-WinEvent -LogName "Microsoft-Windows-LAPS/Operational" -MaxEvents 20

保存されたパスワードは、権限を持つ管理端末から取得します。³

# ADからパスワードを取得(-AsPlainTextなしなら文字列を伏せたまま扱える)
Get-LapsADPassword -Identity PC-0123 -AsPlainText

# 出力例: Account, Password, PasswordUpdateTime, ExpirationTimestamp,
#         Source(EncryptedPasswordなら暗号化保存), AuthorizedDecryptor などが返る

GUI派には、「Active Directory ユーザーとコンピューター」のコンピューターのプロパティにLAPSタブが追加されており、そこからも参照できます。¹

5.4. 即時ローテーション

保守作業でパスワードを使い終わったときや、侵害の疑いがあるときは、次回の定期ローテーションを待たずに即時で回します。³

# 管理端末から: 期限を「今」にして、次回処理でローテーションさせる
Set-LapsADPasswordExpirationTime -Identity PC-0123
# 対象端末で即時処理を蹴れば、その場で新パスワードに変わる
Invoke-LapsPolicyProcessing

# 対象端末上で直接、即時ローテーションする場合
Reset-LapsPassword

5.5. Entra+Intune構成の場合の差分

Entra ID保存では、ADのようなスキーマ拡張・ACL設定は不要です。³ 代わりに、Microsoft Entraテナントの[デバイス設定]でローカル管理者パスワード管理の有効化が必要で、これを忘れると端末はパスワードを保存できません。⁵ ポリシーはIntuneからLAPS CSP経由で配布し、パスワードはEntra管理センター/Intune管理センターの画面か、Microsoft Graph経由の Get-LapsAADPassword で取得します。⁵

# Entra ID保存のパスワードをGraph経由で取得(委任アクセスの例)
# 接続時に必要なスコープを明示的に要求する
Connect-MgGraph -Scopes "Device.Read.All","DeviceLocalCredential.Read.All"
Get-LapsAADPassword -DeviceIds PC-0123 -IncludePasswords -AsPlainText

保存成功のイベントIDはADの10018に対して、Entra IDでは10029です。⁸

6. 運用の落とし穴

導入して終わりではありません。現場で実際に踏みやすいポイントを順に挙げます。

6.1. 閲覧権限が思ったより広い

パスワード属性は機密属性(confidential)なので通常の読み取りでは見えませんが、対象OUに拡張権利(All Extended Rights)を持つプリンシパルは読み取れます。過去の運用でOUに広い権限を委任していた環境では、想定外のグループがパスワードを読める状態になりがちです。導入時に Find-LapsADExtendedRights で拡張権利の保持者を洗い出し、SYSTEMとDomain Admins以外が出てきたら委任内容を見直してください。³

さらに、暗号化保存(ADPasswordEncryptionEnabled)を有効にすると、閲覧権限と復号権限を分離できます。閲覧権限を付与しただけでは暗号化されたパスワードは復号できず、復号できるのは既定でDomain Adminsのみ、変更するにはADPasswordEncryptionPrincipalで復号可能グループを指定します。³ 「ヘルプデスクは自分の担当OUのパスワードだけ復号できる」といった絞り込みは、この2段構えで設計します。

6.2. 「使ったら使い捨て」の仕組みと限界 ── PostAuthenticationActions

ヘルプデスクが取得したパスワードが、そのままメモ用紙やチャットに残り続けたら意味がありません。Windows LAPSは、管理対象アカウントでの認証を検知してから猶予時間(PostAuthenticationResetDelay、既定24時間)が経過すると、自動で後始末を実行します。既定のアクションは「パスワードをリセットしてサインアウト」です。²

注意すべき点が2つあります。第一に、猶予時間を0にするとこの機能自体が無効になります。² 第二に、トリガーは「認証」であって「パスワードの参照」ではありません。ディレクトリからパスワードを取り出しただけで使わなかった場合、この自動リセットは動きません。参照したパスワードは使用の有無にかかわらず、作業完了時に Set-LapsADPasswordExpirationTime で失効させる、を運用手順に固定しておくのが確実です。

6.3. 旧LAPSとの併用・移行

移行期に最も危険なのは、同じアカウントを旧LAPSとWindows LAPSの両方が管理する状態です。2つの仕組みが同じアカウントのパスワードを取り合う構成はセキュリティリスクでありサポートされません。⁹ ルールを整理すると次のとおりです。

• Windows LAPSのポリシーが1つでも適用されている端末では、Windows LAPS自身は旧LAPSのポリシーを常に無視します(Windows LAPS優先)。⁹ ただしこれはWindows LAPS側の解釈の話にすぎません。旧LAPSのCSE(グループポリシー拡張)がインストールされたままなら、旧CSEは旧GPOを独立して処理し続けます。旧GPOの適用対象に残したままWindows LAPSポリシーを有効化すると、両者が同じアカウントをローテーションする二重管理状態になります。
• 旧LAPSのGPO設定をWindows LAPSに処理させる「エミュレーションモード」は、旧LAPSのCSEがインストールされていない端末でのみ動作します。旧LAPS環境の前提(旧スキーマ・旧ACL)をそのまま使いますが、暗号化やEntra保存などの新機能は使えません。⁹
• OSを更新しただけで、旧LAPSのGPOが残っている端末が意図せずエミュレーションモードで動き出すことがあります。キッティング直後の想定外のパスワード変更を避けたい場合は、ローカル構成キーでBackupDirectory=0を設定してエミュレーションを止められます。⁹

移行は「対象OUを旧LAPSのGPO適用から外す(または旧CSEをアンインストールする)→ Windows LAPSポリシーを適用 → 旧GPO・旧CSEの残りを撤去」の順で、旧管理を外してから新管理を有効化し、端末単位でどちらの管理下かが常に一意になるよう進めます。逆順(先にWindows LAPSポリシーを適用)にすると、旧CSEが残っている端末で上記の二重管理が発生します。

6.4. 監査 ── 「誰がいつ見たか」を残す

ローカル管理者パスワードを集中保存する以上、その閲覧履歴は監査対象です。端末側の動作はイベントログの専用チャネル(イベントビューアーの「アプリケーションとサービス ログ > Microsoft > Windows > LAPS > Operational」)にすべて記録され、処理開始10003/成功10004/失敗10005、保存成功10018(AD)/10029(Entra)、適用中ポリシーの内容10021〜10023などが確認できます。⁸ AD側では Set-LapsADAuditing で対象OUに監査設定を構成し、パスワード属性へのアクセスをドメインコントローラーのセキュリティログに記録できます。⁴ Entra ID保存の場合は、Entra側の監査ログ・レポート機能で追跡します。¹

7. まとめ

• 全PC共通のローカル管理者パスワードは、1台の侵害がPass-the-Hashで全台に波及する構図を作ります。端末ごとの個別化と自動ローテーションが対策で、それを担うのがWindows LAPSです。
• Windows LAPSは2023年4月更新以降のWindows 10/11、Windows Server 2019/2022以降に組み込み済みで、追加インストールは不要です。旧LAPS(MSI配布)は非推奨になり、新規はWindows LAPS一択です。
• 保存先はADかEntra IDのどちらか一方で、端末の参加状態で決まります。ワークグループ端末では使えないため、手動の個別管理か参加形態の見直しが必要です。
• 既定では無効です。AD構成ならスキーマ拡張・自己更新権限・閲覧権限の3点を準備し、GPOでBackupDirectoryを設定して初めて動きます。
• 日常運用はPowerShellが軸です。取得は Get-LapsADPassword / Get-LapsAADPassword、即時反映は Invoke-LapsPolicyProcessing、即時ローテーションは Reset-LapsPassword。
• 落とし穴は、拡張権利による想定外の閲覧、参照しただけではPostAuthenticationActionsが動かないこと、旧LAPSとの二重管理、監査の未整備です。導入時にFind-LapsADExtendedRightsでの権限確認と、参照後の失効手順を固定してください。

関連記事

• BitLocker実務ガイド ── 回復キーの管理から始めるドライブ暗号化
• 図解でわかるNTLMとKerberos ── なぜ認証はNTLMに「落ちる」のか
• Windows の管理者特権が必要になるのはいつなのか - UAC、保護領域、設計上の見分け方
• winget + PowerShellでPCキッティングを自動化する ── 手順書を実行可能にする
• WindowsのTPMとは何か ── 図解でわかる「鍵を外に出さない金庫」と測定起動
• Windows PCを廃棄する前にやっておきたいこと ── データ消去・アカウント解除・バックアップの実務チェックリスト

関連する相談領域

合同会社小村ソフトでは、PCキッティングの自動化スクリプト作成、Windows LAPS導入を含む端末セキュリティ設定の整備、既存の共通パスワード運用からの移行計画づくりを扱っています。「キッティング手順書はあるが属人化している」「LAPSを入れたいがADの権限設定に自信がない」といった段階からで構いません。

• Windowsアプリ開発
• 技術相談・設計レビュー
• お問い合わせ

参考リンク

関連する記事

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

よくある質問

この記事のテーマについて、相談時によくある質問をまとめています。

旧LAPS(MSI配布のMicrosoft LAPS)をすでに運用しています。何かする必要がありますか？

移行の計画を始めてください。旧LAPSはWindows 11 23H2以降で非推奨となり、新しいOSではMSIのインストール自体がブロックされます。現在のOS(2023年4月更新適用済みのWindows 10/11、Windows Server 2019/2022以降)にはWindows LAPSが組み込まれているため、追加インストールなしで移行できます。移行期間中はWindows LAPSの「旧LAPSエミュレーションモード」で旧ポリシーを継続処理させることもできますが、旧LAPSのCSEがインストールされた端末では動作しない、暗号化やEntra ID保存など新機能が使えないなどの制約があります。同じアカウントを新旧両方で管理する構成はサポートされないので、端末単位でどちらが管理しているかを明確にして切り替えてください。

取得したパスワードを使った後、そのまま放置しても大丈夫ですか？

既定の構成なら自動で後始末されますが、即時ではありません。Windows LAPSには、管理対象アカウントでの認証(ログオン)を検知してから猶予時間の経過後に処理を行うPostAuthenticationActionsがあり、既定では認証の24時間後にパスワードのリセットとサインアウトが実行されます。裏を返せば、その猶予時間が過ぎるまで同じパスワードは有効なまま使えるので、「使った瞬間に無効になる」わけではありません。また、この仕組みが動くのは「パスワードで認証したとき」であって「ディレクトリから参照しただけ」では動きません。確実なのは、作業完了時に明示的に失効させる運用です。AD保存ならSet-LapsADPasswordExpirationTimeで期限切れにします(このコマンドレットはAD保存専用です)。Entra ID保存の場合は、対象端末上でReset-LapsPasswordを実行するか、Intuneのローカル管理者パスワードのローテーション操作を使います。

ドメインにもEntra IDにも参加していないワークグループ運用のPCでは使えますか？

使えません。Windows LAPSはパスワードの保存先としてActive DirectoryまたはMicrosoft Entra IDを必要とし、どちらにも参加していない端末にはバックアップ先がないためです。ワークグループ運用を続けるなら、端末ごとに異なるローカル管理者パスワードを設定して安全な場所(パスワードマネージャー等)で台帳管理する、という手動運用が現実的な代替になります。台数が増えてきたら、LAPSを含む集中管理の恩恵を受けるためにEntra ID参加(+Intune)やドメイン参加への移行を検討する時期です。

保存されたパスワードは誰が閲覧できますか？

Active Directory保存の場合、既定で閲覧できるのはDomain Adminsのメンバーで、他のユーザーやグループにはSet-LapsADReadPasswordPermissionで明示的に権限を付与します。ただし、パスワード属性は機密属性(confidential)であるものの、OUに対して拡張権利(All Extended Rights)を持つプリンシパルは読み取れてしまうため、Find-LapsADExtendedRightsで想定外の保持者がいないかを導入時に必ず確認してください。さらにADPasswordEncryptionEnabledで暗号化を有効にすれば(ドメイン機能レベル2016以上が必要)、復号できる相手をADPasswordEncryptionPrincipalで指定したグループに絞れます。Entra ID保存の場合は、既定ではグローバル管理者などの特権ロールが閲覧でき、Microsoft Graphでの取得にはDeviceLocalCredential.Read.All権限が必要です。

Windows LAPSの利用に追加ライセンスは必要ですか？

機能自体は無料です。Windows LAPSはサポートされるWindowsに組み込まれた標準機能で、Active Directoryへのパスワード保存に追加のライセンス要件はありません。Microsoft Entra IDへの保存も、Microsoft Entra ID Free以上のライセンスで利用できます。Intuneでポリシーを配布する場合のIntuneライセンスなど、周辺のEntra/Intune関連機能には別途ライセンス要件があり得るため、そこだけ確認してください。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。