Windows User Account and Access Management Questions

Managing user identities, accounts, and access on Windows systems including both local and domain environments. Topics include creating and modifying local and domain user accounts, password resets and policy enforcement, enabling and disabling accounts, and account lockout handling. Group management practices such as creating security groups, nested groups, assigning users to groups, and managing membership for least privilege. File system permission management using New Technology File System file system permissions and share permissions, covering read, write, execute, modify, and full control, plus permission inheritance and effective permission evaluation. Working with built in privileged groups such as local administrators and domain administrators, and understanding User Account Control elevation and when administrative privileges are required. Common administrative tools and interfaces such as the Services console for related tasks, Computer Management, Active Directory Users and Computers, command line utilities, and PowerShell for interactive management and audit reporting.

HardTechnical

92 practiced

Describe the security trade-offs of granting helpdesk staff the ability to 'Join a computer to the domain' or granting them temporary local admin rights on workstations. Consider potential lateral movement vectors, persistence, and auditing controls you would apply if this capability is necessary.

Sample Answer

**Situation & trade-off summary**

Granting helpdesk domain-join or temporary local admin rights trades operational efficiency for increased attack surface. Both empower quick workstation provisioning and troubleshooting but create vectors for lateral movement, privilege escalation, and persistence if abused or compromised.

**Risk breakdown**

- Domain-join: - Allows adding machines to AD — a compromised helpdesk account could add rogue hosts, modify computer object attributes, or weaken group policies. - Facilitates introduction of attacker-controlled endpoints inside trust boundaries.- Temporary local admin: - Local admin can load drivers, install services, dump credentials (LSASS), and run scheduled tasks — enabling credential theft and pivoting. - Local persistence via startup items, scheduled tasks, service backdoors.

**Lateral movement & persistence vectors**

- Credential harvesting (cached creds, Mimikatz)- Pass-the-Hash / Pass-the-Ticket using elevated local accounts- Moving from a joined host to domain resources using stored machine/computer account credentials- Backdooring Group Policy or creating privileged service accounts

**Mitigations / auditing controls (if capability necessary)**

- Just-in-time access: time-limited elevation via PAM (e.g., Microsoft Entra Privileged Identity Management, CyberArk, BeyondTrust).- Role separation: separate helpdesk accounts for admin actions; require multi-person approval for domain-join.- Least privilege: scope local admin to a small set of machines with endpoint groups; avoid shared local admin passwords—use LAPS.- Strong authentication: MFA on helpdesk and elevation requests.- Endpoint hardening: enable Credential Guard, restrict admin tools, Application Control (WDAC/AppLocker).- Monitoring & auditing: log Event IDs for domain-join, new computer object creation, local admin group changes; forward logs to SIEM; alert on uncommon patterns (off-hours joins, unexpected machine names, multiple joins from one account).- Artifact detection: EDR with process and credential theft telemetry; regular threat-hunting.- Recovery/rollback: immutable backups, GPOs to enforce baseline, rapid account revocation playbooks.

**Conclusion / recommendation**

Prefer JIT PAM + LAPS + strong logging and EDR. If permanent privileges are unavoidable, tightly scope, monitor, and require approval workflows to minimize lateral movement and persistence risk.

HardTechnical

75 practiced

Explain how Fine-Grained Password Policies (FGPP/Password Settings Objects) work in Active Directory. Discuss limitations, how PSOs are applied to users/groups, conflicts with domain password policy, and replication considerations in multi-domain-controller environments.

Sample Answer

**Brief definition**Fine-Grained Password Policies (FGPP) let you apply non-default password/lockout settings to specific users or groups. Implemented as Password Settings Objects (PSOs) introduced in Windows Server 2008 and stored in the domain directory partition under CN=Password Settings Container.

**How PSOs are applied**- A PSO is a directory object with attributes (minLength, complexityEnabled, lockoutThreshold, msDS-PasswordSettingsPrecedence, etc.).- You assign a PSO by adding user or global security group DNs to the msDS-PSOAppliesTo multi-valued attribute.- During authentication/changes, the DC computes the “resultant PSO” for the user: if multiple PSOs apply, the one with lowest msDS-PasswordSettingsPrecedence wins (numeric lower = higher priority). If equal, tie-breakers use GUID/LDAP order.

**Interaction with domain password policy**- Domain password policy is set in the Default Domain Policy GPO and acts as the baseline for all users in that domain.- A resultant PSO overrides domain policy settings for users it targets. If no PSO applies, domain policy remains effective.- FGPP cannot be assigned to OUs; it targets users/groups only.

**Limitations and important notes**- PSOs exist per domain only; they do not cross domain boundaries in a forest.- Can only apply to user objects or global security groups (not OUs or computer accounts).- Older domains/clients (pre-2008 functional level) may not fully support FGPP.- Some attributes may be “not configured” in a PSO and inherit domain values.- Built-in accounts and some special accounts may behave differently; test for service accounts.

**Replication and multi-DC behavior**- PSOs are stored in the domain partition and replicate to all DCs in that domain via normal AD intra-domain replication (not forest-wide). Create/update latency means a recently created/modified PSO may not be known to every DC immediately.- Authentication/Password-change operations are handled by the DC servicing the client and use the PSO data available on that DC. If replication lag exists, a DC might evaluate using stale settings — causing inconsistencies until replication completes.- Ensure AD replication health (repadmin, dcdiag) and consider making PSO changes during maintenance windows; for multi-domain forests, create PSOs in each domain where needed.

**Practical tips**- Use global security groups to manage application of PSOs at scale.- Set clear msDS-PasswordSettingsPrecedence values to avoid conflicts.- Validate with Get-ADFineGrainedPasswordPolicy / ADSIEdit and test on representative users; monitor replication after changes.

MediumSystem Design

91 practiced

You need to implement an account lifecycle for contractors that automatically disables accounts after an access end date and re-enables after approval. Describe a design using AD attributes, scheduled tasks or automation (PowerShell), and integration points with HR or an identity provider. Include rollback and audit considerations.

Sample Answer

**Clarify requirements**- Contractors have an access end date in HR; on that date AD accounts must be disabled automatically. Re-enable only after manager/HR approval. Maintain audit trail and safe rollback.

**High-level design**- Use an AD custom attribute (extensionAttribute1 = accessEndDate, extensionAttribute2 = reenableRequestID).- Daily scheduled automation runs (Windows Task Scheduler or Azure Automation) executing a PowerShell runbook that queries AD for expired accounts and disables them. Send notifications to manager and ticketing/IDP.

**PowerShell example**

powershell

# run daily: disable expired accounts, log to Audit DB
Import-Module ActiveDirectory
$today = Get-Date
Get-ADUser -Filter {extensionAttribute1 -le $today} -Properties extensionAttribute1 | ForEach-Object {
  Disable-ADAccount $_
  # write audit record (event log or central DB)
  Write-EventLog -LogName Application -Source "ContractorLifecycle" -EntryType Information -EventId 3001 -Message "Disabled account: $($_.SamAccountName)"
  # create ticket/notify manager with re-enable workflow link
}

**Approval / re-enable workflow**- Approval via ticketing system or IDP (e.g., Azure AD entitlement management). On approval, automation verifies authorization and calls Enable-ADAccount and clears extensionAttribute2; logs action.

**Integration points**- HR system: push accessEndDate to AD via API or SCIM; or export nightly CSV consumed by automation.- Identity Provider / SSO: sync AD status; for cloud-only accounts use Azure AD with Graph API.- Ticketing (ServiceNow) triggers approval tasks; automation polls for approved tickets.

**Rollback & safety**- Soft-disable: move to “Disabled-Contractor” OU and remove group memberships (capture current memberships in audit store) rather than permanent deletion.- Reversible steps: stored snapshot of group memberships and attributes to restore on re-enable.- Staged rollout: run in “report-only” mode first; alert without disabling.

**Audit & compliance**- Centralized audit: write events to SIEM and a change-log DB with user, actor (automation), timestamp, reason, and before/after attributes.- Retain logs per policy; include ticket IDs and approval metadata.- Alerts for unexpected re-enables or multiple toggles.

**Operational notes**- Test thoroughly with service accounts; implement RBAC for who can approve re-enables; enforce MFA on approvals. Schedule maintenance windows and document runbook for manual intervention.

MediumSystem Design

85 practiced

Design a Group Policy-based solution to enforce a company-wide account lockout policy that applies to all domain users but excludes a small set of service accounts that need higher thresholds. Describe steps, where to apply settings, and how to implement exceptions (do not assume FGPP is not available — discuss both options).

Sample Answer

**Approach summary**Enforce a strict, company-wide account lockout via domain-level policy for all users, and implement exceptions for service accounts using either FGPP (recommended) or careful account placement + process changes if FGPP isn’t available.

**Steps — enforce global policy**- Edit the Default Domain Policy (must be at domain level): Computer Configuration → Policies → Windows Settings → Security Settings → Account Policies → Account Lockout Policy.- Configure values (example): Account lockout threshold = 5 bad attempts, Lockout duration = 15 minutes, Reset counter = 15 minutes.- Link: ensure the GPO is the Default Domain Policy (only domain policy for account policies) and allow replication (DCs).

**Option A — Exceptions using Fine-Grained Password Policies (FGPP)**- Create a Password Settings Object (PSO) and link to a Global Security Group containing service accounts.- PowerShell example:

powershell

# create group
New-ADGroup -Name "SvcAcct_Exception" -GroupScope Global -GroupCategory Security
# create PSO
New-ADFineGrainedPasswordPolicy -Name "SvcAcct_PSO" -Precedence 1 -LockoutThreshold 20 -LockoutObservationWindow (New-TimeSpan -Minutes 30) -LockoutDuration (New-TimeSpan -Minutes 30) -ComplexityEnabled $true -MinPasswordLength 14
# apply to group
Add-ADFineGrainedPasswordPolicySubject -Identity "SvcAcct_PSO" -Members "SvcAcct_Exception"

- Put all service accounts into the group. Verify with Get-ADFineGrainedPasswordPolicy.

**Option B — If FGPP unavailable**- Use dedicated service account OU + managed service accounts and document higher thresholds as part of change control. Note: Default Domain Policy is the only object that defines domain account policies; GPOs on OUs won’t change domain account lockout rules for user accounts.- Alternative: convert vulnerable accounts to Managed Service Accounts (MSAs) or group-managed service accounts (gMSAs) which reduce credential use and can avoid interactive lockouts.

**Testing and validation**- Test with a test service account and a normal user; force bad logons and verify Event ID 4740 on DCs.- Monitor via SIEM and create alerts on excessive lockouts.

**Operational notes & trade-offs**- FGPP is precise and non-disruptive; recommended for small set of exceptions.- Avoid whitelisting high thresholds broadly — raises risk.- Document exceptions, require justification, rotate service account credentials, and prefer gMSAs where possible.

HardTechnical

87 practiced

You suspect a privileged domain account was used to access sensitive shares and exfiltrate data. Detail the incident response steps you would take specific to Windows account and access management: containment actions, forensic evidence collection (which logs and artifacts), account remediation (rotation/disable), and steps to determine scope of access.

Sample Answer

**Clarify & priorities**- Isolate suspected account activity window, affected hosts/shares, and business impact. Prioritize containment to stop further exfiltration while preserving evidence.

**Containment actions**- Immediately disable the domain account in a staged way: remove from privileged groups (Domain Admins, Enterprise Admins) then disable in AD to avoid breaking services that use the account.- Isolate involved endpoints and file servers from network (or apply host-based firewall rules) to stop lateral movement and exfil.- Block account logons via logon restrictions (Logon Workstations or deny logon via GPO) and revoke active Kerberos tickets (see remediation below).

**Forensic evidence collection (preserve chain of custody first)**- Collect Windows Event Logs from domain controllers and hosts for the timeframe: - Security (4624, 4625, 4648, 4672, 4673, 4688, 4698/4699) - AD DS/Directory Service logs (replication/auth anomalies) - System and Application logs- Collect Microsoft-Windows-SMBServer/Operational and File Server Resource Manager logs- Export Sysmon logs (if deployed): process creations, network connections, file creation- Collect Kerberos logs (Event IDs 4768/4769/4776) and ticket-granting events- Pull Netlogon debug and DC diagnostics if replication or DC compromise suspected- Acquire forensic images of involved endpoints and file servers (volatile memory first if possible) and preserve USN Journal, MFT, SAM, and Volume Shadow Copies- Pull open file/SMB session info live: use Net File and Get-SmbSession/Get-SmbOpenFile- Query SIEM for data egress: network flows, DNS, proxy/HTTP logs, and DLP alerts

Example commands to gather live evidence:

powershell

# Get SMB sessions on a file server
Get-SmbSession | Select-Object ClientComputerName,UserName,SessionId

# List open files
Get-SmbOpenFile | Select-Object ClientUserName,Path,FileId

# Query Security log for Kerberos and privilege events
Get-WinEvent -FilterHashtable @{LogName='Security'; ID=@(4624,4672,4768,4769,4625)} -MaxEvents 500

**Account remediation**- Disable account in AD after ensuring any dependent services are reconfigured.- Force credential rotation: reset password, rotate associated service account keys/certificates, and revoke/renew any linked credentials (SSH keys, stored secrets in vaults).- Revoke Kerberos tickets: restart affected service hosts or use klist purge on endpoints; clear TGTs using domain controller revocation when necessary.- Check and remove suspicious group memberships and scheduled tasks, service registrations, and delegated permissions.- If account used for automation, replace with new managed service accounts and update runbooks.

**Determine scope of access**- Query DC Security logs for all successful logons (4624) and privileged elevation (4672) for the account across time window.- On file servers, parse SMB open/close logs and File Access auditing to list files accessed/copies. Use FSRM or audit Object Access (4663) and correlate to user tokens.- Use MFT, USN Journal, and volume shadow copy snapshots to detect file creation/reads/deletes.- Correlate with network logs (proxy, VPN, firewall) and endpoint network connections from Sysmon to identify exfil endpoints and transfer methods (SMB copy, RDP, cloud upload).- Search for created archives (zip/rar), use timeline analysis to prioritize files exfiltrated.

**Reporting & recovery**- Produce timeline, list of accessed resources, indicators of compromise (IOCs) and recommend password resets organization-wide if needed.- Remediate hosts (patch, reimage if compromised), harden audit policies, enable/verify Sysmon and file-audit policies.- Implement least privilege reviews, break-glass monitoring, MFA for privileged accounts, and credential vaulting.

This sequence balances stopping active damage, preserving evidence for investigation/legal needs, and restoring secure operation.

Unlock Full Question Bank

Get access to hundreds of Windows User Account and Access Management interview questions and detailed answers.

Join thousands of developers preparing for their dream job.