Windows LAPS 실무 가이드 ── 전 PC 공통 로컬 관리자 비밀번호를 그만두기

키팅 현장에는 오래 이어져 온 「정석처럼 굳은 편의」가 있습니다. 마스터 이미지에 공통 로컬 관리자 비밀번호를 심고 전대에 배포한다 ── 유지보수에 들어갈 때 그 비밀번호로 로그온하면 되므로, 절차만 보면 합리적으로 보입니다. 그러나 이 구성은 지금, 공격자에게 「마스터키를 양산하는」 지점으로 가장 먼저 노려집니다. 한 대의 침해가 곧 전대의 침해로 바뀌기 때문입니다.

이 글에서는 중소기업 정보시스템 담당자와 PC 키팅·유지보수 운영을 맡는 개발자를 대상으로, 공통 로컬 관리자 비밀번호가 왜 위험한지를 정리한 다음, 그 해결책으로 OS에 들어 있는 Windows LAPS(Local Administrator Password Solution)의 구조, 환경별 구분, 도입 절차, 운영상의 함정까지를 2026년 8월 시점의 1차 정보를 바탕으로 설명합니다. BitLocker·WSUS 폐지·방화벽·인증서 저장소로 이어 온 정보시스템 보안 연재의 후속입니다.

1. 먼저 결론

• 전 PC 공통 로컬 관리자 비밀번호는, 한 대의 침해를 전대로 퍼뜨리는 횡적 이동(래터럴 무브먼트)의 온상입니다. 비밀번호가 같으면 NTLM 해시도 같으므로, 한 대에서 해시를 빼내면 나머지 전대에 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 저장에는 사전 준비가 세 가지 필요합니다. 스키마 확장(Update-LapsADSchema), 컴퓨터 자신의 쓰기 권한(Set-LapsADComputerSelfPermission), 열람 권한 설계(Set-LapsADReadPasswordPermission)입니다.³
• 비밀번호 확인은 Get-LapsADPassword / Get-LapsAADPassword, 즉시 적용은 Invoke-LapsPolicyProcessing, 디바이스에서 즉시 로테이션은 Reset-LapsPassword입니다.⁴
• 쓰인 비밀번호는 자동으로 일회용이 됩니다. 관리 대상 계정으로 인증한 뒤, 기본값에서는 24시간 후에 재설정+로그아웃(PostAuthenticationActions)이 실행됩니다.²

그림의 실선은 항상 성립하는 관계, 점선은 조건이 붙는 관계입니다(성립 조건은 상세 페이지의 관계별 설명에 적혀 있습니다). 관계 전체 목록(총 31건, 근거와 확신도 포함)과 주요 개념의 정의는 지식 맵 상세 페이지에 정리되어 있습니다(일본어). 데이터: JSON-LD / Turtle

2. 왜 전 PC 공통 로컬 관리자 비밀번호가 위험한가

먼저 위협의 구조를 정확히 잡습니다. 로컬 관리자 계정(이른바 기본 제공 Administrator나, 키팅 때 만드는 유지보수용 계정)의 비밀번호를 전대에서 같게 두면 무엇이 일어날까요.

Windows는 로컬 계정의 비밀번호를 그대로 두지 않고, 비밀번호에서 계산한 NT 해시로 보관합니다. NTLM 인증에서는 이 해시 자체가 인증 재료가 됩니다. 즉 비밀번호가 같으면 해시도 전대에서 같습니다. 공격자가 멀웨어나 표적형 공격으로 한 대의 관리자 권한을 얻으면, 그 디바이스의 메모리나 로컬 데이터베이스(SAM)에서 해시를 꺼낼 수 있습니다. 여기서부터가 본론입니다. 꺼낸 해시는 평문 비밀번호로 되돌리지 않아도 그대로 인증에 쓸 수 있습니다. 이것이 Pass-the-Hash 공격입니다. 공통 비밀번호 환경에서는 한 대에서 얻은 해시가 나머지 전대의 「마스터키」가 되어, 침해가 한꺼번에 옆으로 퍼집니다. 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

대책의 방향은 분명합니다. 디바이스마다 로컬 관리자 비밀번호를 다르게 두고, 게다가 정기적으로 바꾸는 것입니다. 그러면 한 대의 해시가 새어 나가도 다른 디바이스에서는 쓸 수 없어, 로컬 관리자 계정을 재사용하는 횡적 이동 경로를 끊을 수 있습니다(침해된 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. 사전 준비(한 번만 하는 작업)

AD 저장에서는 정책을 배포하기 전에 포리스트 쪽 준비를 마칩니다.³

# 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를 가진 principal은 읽을 수 있습니다. 과거 운영에서 OU에 넓은 권한을 위임한 환경에서는, 예상 밖의 그룹이 비밀번호를 읽을 수 있는 상태가 되기 쉽습니다. 도입 시 Find-LapsADExtendedRights로 확장된 권리 보유자를 가려내고, SYSTEM과 Domain Admins 이외가 나오면 위임 내용을 다시 봐야 합니다.³

여기에 암호화 저장(ADPasswordEncryptionEnabled)을 켜면 열람 권한과 복호화 권한을 나눌 수 있습니다. 열람 권한만 줘서는 암호화된 비밀번호를 복호화할 수 없고, 복호화할 수 있는 대상은 기본으로 Domain Admins뿐이며, 바꾸려면 ADPasswordEncryptionPrincipal로 복호화 가능 그룹을 지정합니다.³ 「헬프데스크는 담당 OU의 비밀번호만 복호화할 수 있다」와 같은 좁히기는 이 두 단계로 설계합니다.

6.2. 「쓰면 일회용」의 구조와 한계 ── PostAuthenticationActions

헬프데스크가 가져온 비밀번호가 메모지나 채팅에 그대로 남으면 의미가 없습니다. Windows LAPS는 관리 대상 계정으로의 인증을 감지한 뒤 유예 시간(PostAuthenticationResetDelay, 기본 24시간)이 지나면 자동으로 뒷정리를 실행합니다. 기본 동작은 「비밀번호를 재설정하고 로그아웃」입니다.²

주의할 점이 두 가지입니다. 첫째, 유예 시간을 0으로 두면 이 기능 자체가 꺼집니다.² 둘째, 트리거는 「인증」이지 「비밀번호 조회」가 아닙니다. 디렉터리에서 비밀번호를 꺼내기만 하고 쓰지 않은 경우에는 이 자동 재설정이 동작하지 않습니다. 조회한 비밀번호는 사용 여부와 관계없이, 작업이 끝나는 시점에 Set-LapsADPasswordExpirationTime으로 만료시킨다, 를 운영 절차에 고정하는 편이 확실합니다.

6.3. 구 LAPS와의 병용·이전

이전 시기에 가장 위험한 것은 같은 계정을 구 LAPS와 Windows LAPS가 둘 다 관리하는 상태입니다. 두 구조가 같은 계정의 비밀번호를 서로 가져가는 구성은 보안 위험이며 지원되지 않습니다.⁹ 규칙을 정리하면 다음과 같습니다.

• Windows LAPS 정책이 하나라도 적용된 디바이스에서는 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 공통 로컬 관리자 비밀번호는, 한 대의 침해가 Pass-the-Hash로 전대에 번지는 구조를 만듭니다. 디바이스마다 다르게 두고 자동 로테이션하는 것이 대책이며, 그것을 맡는 것이 Windows LAPS입니다.
• Windows LAPS는 2023년 4월 업데이트 이후의 Windows 10/11, Windows Server 2019/2022 이후에 이미 들어 있으며, 추가 설치는 필요 없습니다. 구 LAPS(MSI 배포)는 사용이 권장되지 않으며, 신규는 Windows LAPS뿐입니다.
• 저장 위치는 AD 또는 Entra ID 중 한쪽이며, 디바이스의 가입 상태로 정해집니다. 워크그룹 디바이스에서는 쓸 수 없으므로, 수동 개별 관리나 가입 형태를 다시 봐야 합니다.
• 기본값에서는 사용되지 않습니다. AD 구성이면 스키마 확장·자기 업데이트 권한·열람 권한 세 가지를 준비하고, 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으로 기한을 만료시킵니다(이 cmdlet은 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를 가진 principal은 읽을 수 있습니다. 따라서 도입 시 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 관련 기능에는 별도 라이선스 요건이 있을 수 있으므로, 그 부분만 확인하면 됩니다.

저자 프로필

기사 저자의 프로필 페이지입니다.

Go Komura

합동회사 코무라소프트 대표

Windows 소프트웨어 개발, 기술 상담, 장애 조사를 중심으로 재현이 어려운 장애 조사와 기존 자산이 남아 있는 프로젝트에 강점이 있습니다.