Windows Server identity security: LAPS, gMSA and Protected Users

Start DC01, SRV01 and CL01. Work on DC01 as SAATLAB\Administrator in PowerShell as administrator unless a step says otherwise.

1Prepare AD for Windows LAPS

On DC01, run this:

Update-LapsADSchema -Confirm:$false
Set-LapsADComputerSelfPermission -Identity 'OU=Workstations,OU=SAATLAB,DC=saatlab,DC=internal'

You should see something like this:

Name         DistinguishedName
----         -----------------
Workstations OU=Workstations,OU=SAATLAB,DC=saatlab,DC=internal

The schema update adds the msLAPS attributes to computer objects. The permission lets each computer in Workstations (and the OUs below it) write its own password, and nothing else.

✅ Checkpoint: Update-LapsADSchema finished without errors and the permission is set on Workstations.

2Turn on LAPS with Group Policy

Create a GPO called C-LAPS linked to Workstations and edit it. Go to Computer Configuration, Policies, Administrative Templates, System, LAPS.

Enable Configure password backup directory and choose Active Directory. Enable Password Settings (keep the defaults: large letters, small letters, numbers, specials; 14 characters; 30 days). Enable Enable password encryption.

On CL01 (as labadmin or an admin), apply it now instead of waiting:

gpupdate /force
Invoke-LapsPolicyProcessing

Back on DC01, read the password:

Get-LapsADPassword -Identity CL01 -AsPlainText

You should see something like this:

ComputerName        : CL01
DistinguishedName   : CN=CL01,OU=Workstations,OU=SAATLAB,DC=saatlab,DC=internal
Account             : Administrator
Password            : 7k#Qe2v!Lm9xRt
PasswordUpdateTime  : 19/10/2026 18:55:31
ExpirationTimestamp : 18/11/2026 18:55:31
Source              : EncryptedPassword
DecryptionStatus    : Success
AuthorizedDecryptor : SAATLAB\Domain Admins

CL01’s built-in Administrator now has a unique random password that changes every 30 days and is stored encrypted. Only Domain Admins can decrypt it by default. After someone uses it, run Reset-LapsPassword on the computer so it’s never reused.

✅ Checkpoint: Get-LapsADPassword shows a password for CL01 with Source EncryptedPassword.

3Create a gMSA for the intranet site

On DC01, run this:

Add-KdsRootKey -EffectiveTime ((Get-Date).AddHours(-10))
New-ADServiceAccount -Name gmsa_intranet -DNSHostName gmsa_intranet.saatlab.internal -PrincipalsAllowedToRetrieveManagedPassword 'SRV01$'
setspn -D HTTP/intranet.saatlab.internal SAATLAB\svc_intranet
setspn -S HTTP/intranet.saatlab.internal SAATLAB\gmsa_intranet$
Disable-ADAccount svc_intranet

You should see something like this (after the KDS key GUID):

Unregistering ServicePrincipalNames for CN=svc_intranet,OU=Service Accounts,OU=SAATLAB,DC=saatlab,DC=internal
        HTTP/intranet.saatlab.internal
Updated object
Checking domain DC=saatlab,DC=internal

Registering ServicePrincipalNames for CN=gmsa_intranet,CN=Managed Service Accounts,DC=saatlab,DC=internal
        HTTP/intranet.saatlab.internal
Updated object

The KDS root key normally takes 10 hours before DCs use it, so every DC has it replicated. Backdating it with -EffectiveTime is fine in a one-site lab, never in production. gMSAs live in the Managed Service Accounts container and their names end in $, like computer accounts.

On SRV01, install and test it:

Install-ADServiceAccount gmsa_intranet
Test-ADServiceAccount gmsa_intranet

You should see this:

True

✅ Checkpoint: Test-ADServiceAccount returns True on SRV01, and the SPN now belongs to gmsa_intranet$.

4Create a separate admin account in Protected Users

On DC01, run this:

New-ADUser -Name 'adm.rahul' -GivenName Rahul -Surname Verma -SamAccountName adm.rahul -UserPrincipalName adm.rahul@saatlab.internal -Path 'OU=Admin Accounts,OU=SAATLAB,DC=saatlab,DC=internal' -AccountPassword (Read-Host -AsSecureString 'Password (16+ characters)') -Enabled $true
Add-ADGroupMember 'Domain Admins' -Members adm.rahul
Add-ADGroupMember 'Protected Users' -Members adm.rahul
Get-ADPrincipalGroupMembership adm.rahul | Select-Object -ExpandProperty Name

You should see something like this:

Domain Users
Domain Admins
Protected Users

Rahul keeps rahul.verma for email and daily work, and uses adm.rahul only for admin tasks on servers and DCs. Sign out of DC01, sign in as SAATLAB\adm.rahul, and run klist tgt: the EndTime is 4 hours after StartTime, not 10, because Protected Users get short TGTs.

✅ Checkpoint: adm.rahul is in Domain Admins and Protected Users, and its TGT lasts 4 hours.

5Give admins a stricter password policy

On DC01, create a fine-grained password policy for Domain Admins:

New-ADFineGrainedPasswordPolicy -Name 'PSO-Admins' -Precedence 10 -MinPasswordLength 16 -ComplexityEnabled $true -PasswordHistoryCount 24 -MaxPasswordAge 365.00:00:00 -MinPasswordAge 1.00:00:00 -LockoutThreshold 5 -LockoutDuration 00:30:00 -LockoutObservationWindow 00:30:00 -ReversibleEncryptionEnabled $false
Add-ADFineGrainedPasswordPolicySubject 'PSO-Admins' -Subjects 'Domain Admins'
Get-ADUserResultantPasswordPolicy adm.rahul | Select-Object Name, MinPasswordLength, LockoutThreshold

You should see something like this:

Name       MinPasswordLength LockoutThreshold
----       ----------------- ----------------
PSO-Admins                16                5

Rahul’s normal account still follows the domain policy (12 characters); his admin account follows PSO-Admins. If several PSOs apply, the lowest precedence number wins. A user with no PSO shows nothing from Get-ADUserResultantPasswordPolicy.

✅ Checkpoint: adm.rahul’s resultant policy is PSO-Admins with a 16-character minimum.

Take snapshots called “Identity security” of DC01, SRV01 and CL01.

'DC01','SRV01','CL01' | ForEach-Object { VBoxManage snapshot $_ take "Identity security" }