Privileged accounts and security checks

Review the memberships that can change the forest

Start with Domain Admins, Enterprise Admins, Schema Admins, the built-in Administrators and operator groups, and service-specific groups such as DNSAdmins. Record direct members as well as nested paths. A list of named administrators does not cover service accounts, delegated ACLs, or control of the hosts those administrators use.

Get-ADGroupMember -Identity 'Domain Admins'
Get-ADGroupMember -Identity 'Domain Admins' -Recursive
Get-ADGroupMember -Identity 'Schema Admins'

Use an appropriate domain or forest-root DC and the actual group names for that environment; built-in display names can be localized. Schema Admins membership should have a specific reason and lifecycle. An apparently empty group can still carry powerful ACLs, so review who can change its membership.

Follow the control paths through group membership, object permissions, GPOs, administrative workstations and service hosts. For each path, keep enough detail to show who controls it and how.

Protected accounts have a different ACL lifecycle

AdminSDHolder and SDProp maintain protected-account permissions independently of the OU’s normal inheritance. Moving a privileged account into a delegated OU does not make it an ordinary delegated object. Investigate the protected-group path before repeatedly repairing an ACL that the protection process restores. Protected accounts and groups.

Get-ADUser -LDAPFilter '(adminCount=1)' -Properties adminCount |
    Select-Object SamAccountName,DistinguishedName,adminCount

This gives you accounts to investigate. adminCount can remain after an account leaves a protected group, and ordinary inheritance may still be disabled. Check direct/nested membership and the security descriptor before clearing adminCount or restoring inheritance. The whole list won’t necessarily need the same fix.

Managed service accounts

The standalone MSA model is tied to one host. A group managed service account (gMSA) supports an identity shared by supported services across several hosts, with managed passwords. Confirm application support before migrating a service.

Get-ADServiceAccount -Filter * `
    -Properties ServicePrincipalNames, PrincipalsAllowedToRetrieveManagedPassword |
    Select-Object Name, ObjectClass, ServicePrincipalNames,
        PrincipalsAllowedToRetrieveManagedPassword

Check which hosts can retrieve the password and who can change their group membership. The service account still has its privileges even though Windows manages its password. Microsoft’s gMSA management guidance covers the application and host requirements.

Follow managed service account diagnostics for KDS availability, effective host membership, installation and a local readiness test.

Protected Users

Protected Users is intended for user accounts that can operate with its restrictions. Members need AES-capable Kerberos authentication; NTLM and delegation are restricted, cached offline sign-in is unavailable on supporting clients, and domain protections limit TGT life and renewal to four hours. Test the actual workflows before changing privileged users’ membership.

Do not add service or computer accounts. Microsoft explicitly excludes them from the intended use. Membership does not switch off Kerberos preauthentication or provide a special exemption from account lockout policy. The current Protected Users reference describes the protections and their requirements.

Get-ADGroupMember -Identity 'Protected Users'
Get-ADUser -Identity alice -Properties AccountNotDelegated, PasswordLastSet |
    Select-Object SamAccountName, AccountNotDelegated, PasswordLastSet

Check client OS support, domain functional level, available account keys, recovery access, and every application that still expects NTLM or delegation. A single failed connection after enrollment can reveal an old dependency; it is not a reason to weaken the whole domain’s authentication policy.

Retest after a new sign-in so the intended protections and group membership are in the session. When troubleshooting a failure, discover the available ProtectedUser client/DC logs with Get-WinEvent -ListLog '*ProtectedUser*'; record and restore logging changes made for a bounded collection.

Windows LAPS and legacy LAPS

Legacy Microsoft LAPS and Windows LAPS use different attributes and policy implementations. Having the schema attributes doesn’t tell you whether clients are using LAPS or rotating passwords.

Inspect schema coverage without retrieving stored passwords:

$schema = (Get-ADRootDSE).schemaNamingContext
Get-ADObject -SearchBase $schema `
    -LDAPFilter '(|(lDAPDisplayName=msLAPS-PasswordExpirationTime)(lDAPDisplayName=ms-Mcs-AdmPwdExpirationTime))' `
    -Properties lDAPDisplayName |
    Select-Object lDAPDisplayName

For a sample computer that should use AD-backed Windows LAPS:

Get-ADComputer -Identity WS01 -Properties msLAPS-PasswordExpirationTime |
    Select-Object Name, msLAPS-PasswordExpirationTime

Then inspect the client’s Windows LAPS Operational log and effective policy. Review who can read or decrypt the password attributes, who can change those permissions, and whether rotation is succeeding.

AD-backed encrypted passwords require DFL 2016 or later. DSRM password management additionally requires supporting DCs and encrypted storage. Permission to read an encrypted password is distinct from permission to decrypt it: the configured encryption principal is evaluated when the password is backed up. A later ACL edit does not rewrite an existing encrypted payload. AD deployment and decryption prerequisites.

Inspect delegated readers without collecting passwords:

Find-LapsADExtendedRights -Identity 'OU=Workstations,DC=contoso,DC=com' `
    -DomainController 'dc1.contoso.com'

Review the returned ExtendedRightHolders, nested memberships and who can change those groups. The cmdlet reference describes the query. Include the configured authorized decryptor in the permission review.

On a managed client, collect a complete processing cycle:

Get-WinEvent -FilterHashtable @{
    LogName = 'Microsoft-Windows-LAPS/Operational'
    Id = 10003,10004,10005,10018
    StartTime = (Get-Date).AddDays(-1)
} | Select-Object TimeCreated,Id,Message

10003 starts processing, 10004 records success, 10005 records failure, and 10018 records successful AD password backup. Inspect surrounding events for the underlying error. For example, 10017 is an ending failure status, so earlier events supply the cause. If the managed account is absent, check account-management mode: automatic account creation is a newer Server 2025/Windows 11 24H2 capability, not an assumption for every client. Windows LAPS troubleshooting.

Invoke-LapsPolicyProcessing is an active policy-processing action and can change/rotate the managed password. Capture evidence before triggering it. Test authorized recovery as part of deployment, including DSRM recovery when normal domain access is unavailable; an expiration timestamp alone is not that test.

Windows LAPS can back up to AD or Microsoft Entra ID, with capabilities depending on the chosen backing store and prerequisites. A migration must account for the existing client extension and targeted local account. Microsoft’s migration guide permits temporary coexistence only when the two policies target different accounts.

SMB signing is a client and server setting

From an elevated PowerShell session on the machine being reviewed:

Get-SmbClientConfiguration | Select-Object RequireSecuritySignature
Get-SmbServerConfiguration | Select-Object RequireSecuritySignature

The first controls outbound client behavior; the second controls inbound server behavior. Record both. For SMB2 and later, EnableSecuritySignature is not the effective requirement switch. Inspect RequireSecuritySignature and, when troubleshooting a particular connection, collect the negotiated protocol evidence.

Defaults differ by OS, version, edition, and role. Use Microsoft’s SMB signing controls for the target version, especially when a newly upgraded client stops reaching a third-party share. Disabling signing as a broad workaround conceals the compatibility problem and changes security for other connections too.

The current release guidance specifies outbound signing for Server 2025 and both directions for Windows 11 24H2 Pro, Enterprise and Education. Inspect the effective settings and connection rather than applying those defaults to every historical installation. For an active connection, record the server/share, dialect and encryption state with Get-SmbConnection; encryption and signing policy are separate pieces of evidence.

Inspect effective audit policy on the machine

auditpol /get /category:*

Check the DC’s effective subcategories even when the setting appears in a GPO report. Include credential validation, Kerberos authentication and service-ticket operations, account management and directory changes where required.

Advanced subcategories can interact with older category-level policy; inspect the setting that forces subcategory policy to override category settings. Object-access auditing also needs the appropriate object SACL. Confirm actual events arrive at the collector and survive the intended retention period. Microsoft’s audit policy recommendations provide a baseline to adapt and test.

Directory-change auditing has another gate: the attribute schema. searchFlags bit 0x100 (fNEVERVALUEAUDIT) suppresses auditing of individual attribute values. It is separate from the confidential bit 0x80 and RODC-filtered bit 0x200. A suitable SACL and enabled audit subcategory do not override that schema rule. Search flag definitions.

For a recorded modification, inspect event 5136’s object GUID, LDAP attribute name, operation type and correlation ID. A replacement commonly produces a Value Deleted/Value Added pair; one event alone may show only one side. Keep the source XML and check what reached the collector before deciding that a missing value means nothing changed. Microsoft’s 5136 field definition describes the correlation. Test the audit path with a controlled non-sensitive attribute; don’t assume every attribute’s value will appear.

krbtgt rotation needs a runbook

Get-ADUser -Identity krbtgt -Properties PasswordLastSet |
    Select-Object SamAccountName, PasswordLastSet

Collect this per domain with replication health and the last documented rotation. One timestamp is not proof that all DCs have the expected key history.

The KDC retains current and previous keys. Removing an old key therefore involves coordinated resets, convergence, and timing against the configured ticket lifetimes. RODCs have separate krbtgt accounts. Use the Microsoft recovery procedure and a tested plan appropriate to routine rotation or compromise recovery. Choose the rotation cadence for the environment and its recovery requirements.