Active Directory and User Management Questions

Basic understanding of Active Directory roles, user accounts and permissions, group policies, domain vs. workgroup, login processes, and how user authentication works. Understanding how these systems affect user access and support issues.

EasyTechnical

75 practiced

Write a PowerShell one-liner (Windows PowerShell or PowerShell Core) using the ActiveDirectory module to find an AD user by sAMAccountName and display their Enabled status, lastLogonTimestamp, and direct group memberships. Include handling for when the user is not found.

Sample Answer

**Approach**Use Get-ADUser to find by sAMAccountName, handle not-found, fetch lastLogonTimestamp (converted), Enabled, and direct group memberships with Get-ADPrincipalGroupMembership filtered to direct (memberOf).

**One-liner**

powershell

$s='jsmith'; $u=Get-ADUser -Filter "sAMAccountName -eq '$s'" -Properties Enabled,lastLogonTimestamp,memberOf; if(-not $u){Write-Host "User $s not found"; exit} ; [pscustomobject]@{SamAccountName=$u.SamAccountName; Enabled=$u.Enabled; LastLogon=[DateTime]::FromFileTimeUtc($u.lastLogonTimestamp); DirectGroups=($u.memberOf | ForEach-Object { (Get-ADGroup $_).Name }) -join ','}

**Notes**- Converts lastLogonTimestamp to UTC date.- Uses memberOf for direct groups (not recursive).- If memberOf is null returns empty string.

HardSystem Design

83 practiced

Design and explain an Azure AD Connect deployment for a hybrid identity scenario. Cover sync rules and attribute mapping, filtering options (OU and attribute), writeback features (password, device, group), staging mode, HA considerations, and rollback or recovery approaches when sync breaks.

Sample Answer

**Clarify scope & goals**I’d deploy Azure AD Connect to provide synchronized identities for on-prem AD and Azure AD with seamless SSO, secure writebacks, and high availability for a production hybrid environment.

**Design summary**- Use Express settings for simple tenants; use Custom installation for multiple forests/complex mappings.- Install latest Azure AD Connect on a dedicated Windows Server 2019/2022 VM joined to domain, minimum 4 vCPU / 8 GB RAM.

**Sync rules & attribute mapping**- Use built-in rules for user, group, contact. Create custom inbound sync rules when transforming attributes (e.g., set userPrincipalName = mail if needed).- Use explicit attribute mapping for extensionAttributes, employeeID; map ImmutableId when doing sourceAnchor mapping.- Test mappings in Synchronization Service Manager and use Preview.

**Filtering**- OU-based filtering: include only OUs that contain synced accounts.- Attribute-based filtering: use filtering for msDS-ConsistencyGuid, extensionAttribute flags or custom attribute (e.g., cloudProvision=TRUE) to exclude service accounts or legacy objects.

**Writeback features**- Enable Password Writeback to allow cloud resets to update on-prem AD (requires Azure AD P1/P2 or appropriate license).- Device writeback to allow Hybrid Azure AD Join and Intune device objects back into on-prem.- Group writeback for Office 365 groups to on-prem if needed (ensure schema extensions and permissions).

**Staging mode & HA**- Use one active sync server and one or more servers in Staging Mode (hot standby) to avoid duplicate exports; staging server holds configuration and ready to take over. For true HA, maintain at least two servers and perform role-switch by disabling staging on primary and enabling on secondary.- Keep identical configuration, same service account permissions, and schedule sync cycles aligned.

**Rollback & recovery**- If sync breaks: immediately disable scheduler on Azure AD Connect to stop propagation.- Use Export/Import and run Connector Space to on-premise to evaluate pending changes. Use Azure AD Connect Health / logs to identify failures.- Restore from backup of configuration (export config via Azure AD Connect wizard) to staging server; fail over by enabling staging mode appropriately.- If bad attribute flow caused mass deletes or updates: use Azure AD Recycle Bin, Azure AD Connect soft-delete prevention (staging), and perform a targeted Restore using PowerShell (Restore-AzureADMSDeletedDirectoryObject) or rehydrate from on-prem backups.- Re-sync using delta/full import/export as needed; validate in pilot OUs before re-enabling sync.

**Operational best practices**- Use dedicated service accounts with least privilege and documented credentials rotation.- Monitor with Azure AD Connect Health and alerting; schedule maintenance windows for upgrades.- Test changes in a lab or staging server before production.

This design balances control over attribute flows, safe rollbacks, and operational HA suitable for a Systems Administrator running hybrid identity at scale.

HardTechnical

107 practiced

Explain token bloat and how large or deeply nested group memberships can impact user logon performance and Kerberos token sizes. Propose design patterns to avoid token bloat, suggest remediation steps for affected users, and monitoring strategies to detect oversized tokens.

Sample Answer

**Brief definition / impact**

- Token bloat = an access token or Kerberos PAC that grows large because a user’s SIDs (group memberships, nested groups, SIDHistory, and resource claims) accumulate. - Impact: slower interactive and service logons, delayed Group Policy processing, authentication failures (token creation failures), and larger Kerberos tickets increasing network/auth latency. Very large tokens can exceed OS limits and prevent logons.

**Why it happens (technical)**

- Each group membership becomes a SID inside the user’s access token and Kerberos PAC. Deeply nested groups multiply effective membership. - Windows historically had practical limits (MaxTokenSize registry default ~12288 bytes on some platforms and effective SID count limits ≈ 1000). Exceeding these causes errors or truncation of authorizations.

**Design patterns to avoid token bloat**

- Role-based groups: Use few, well-scoped role groups (RBAC) rather than many resource-specific groups. - Flatten where appropriate: Prefer direct group membership for roles vs extreme nesting. - Nested-group discipline: Only nest when it reduces administrative burden without exploding effective membership. Keep nesting shallow. - Use resource groups for ACLs and role groups for assignments; map role → resource group rather than add users to many resource groups. - Use claims-based or application-level authorization (e.g., groups stored in app DB) for large-scale SaaS where possible.

**Remediation steps for affected users**

1. Identify the user’s effective group set: PowerShell Get-ADPrincipalGroupMembership and whoami /groups to list SIDs. 2. Count SIDs; find redundant/nested groups and SIDHistory entries. 3. Remove unnecessary direct or nested memberships; migrate to role groups that consolidate rights. 4. Convert many small resource groups into a single role-to-resource mapping (application-level). 5. If immediate relief needed, move high-SID-count users into constrained groups or split accounts for specific duties. 6. Only as last resort: increase MaxTokenSize on domain members/servers per Microsoft guidance—this masks root cause and can complicate compatibility.

**Monitoring & detection strategies**

- Scheduled PowerShell job that: - Enumerates effective group SIDs per user (Get-ADUser + Get-ADPrincipalGroupMembership or token SID count from whoami) and alerts when SID count > threshold (e.g., 800–1000) or token size estimate > 10–12 KB.- Log monitoring: - Alert on authentication/logon failures and slow interactive logons. Monitor Event Logs for token-creation or Kerberos-related failures (authentication errors after logon attempt). - Kerberos ticket inspection: - Use klist and network capture of Kerberos to measure ticket/PAC sizes for sample logons. - Trending: - Track average token SID counts by department and flag spikes after group changes or merger activities. - Integrate with IDM change audits: alert when group nesting depth or newly created large groups appear.

**Closing guidance**

Start with detection (PowerShell + scheduled checks), remediate high-impact users by collapsing redundant memberships and adopting RBAC, and treat registry increases as a temporary workaround. Prioritize documentation and group-naming conventions to prevent recurrence.

EasyTechnical

72 practiced

As a Systems Administrator, describe both the GUI and PowerShell steps to reset a user's password in AD and force 'User must change password at next logon'. Also explain where those actions are logged and how to verify the change propagated across domain controllers.

Sample Answer

**GUI steps (Active Directory Users and Computers)**- Open Active Directory Users and Computers (dsa.msc) on a DC or workstation with RSAT.- Find the user, right-click → Reset Password…- Enter new password (or leave blank if policy allows) and check “User must change password at next logon.”- Click OK.

**PowerShell steps**- Example (run as a user with AD rights; RSAT module loaded):

powershell

# Import module (if needed)
Import-Module ActiveDirectory

# Reset password (secure string)
$new = ConvertTo-SecureString 'P@ssw0rd!' -AsPlainText -Force
Set-ADAccountPassword -Identity 'jdoe' -NewPassword $new -Reset

# Force change at next logon
Set-ADUser -Identity 'jdoe' -ChangePasswordAtLogon $true

- Alternative single cmd: Set-ADUser -Identity 'jdoe' -Replace @{pwdLastSet=0}

**Where actions are logged**- Security log on the domain controller that processed the change: - Event ID 4724 — "An attempt was made to reset an account's password" (successful entries show who performed the reset).- Directory Service audit entries: - Event ID 5136 (and related 5137/5138) in the DC’s Directory Service log if Directory Service Changes auditing is enabled (shows attribute modifications like pwdLastSet).- Location: Event Viewer → Windows Logs → Security, and Applications and Services Logs → Directory Service on DCs.

**Verify propagation across DCs**- Quick check with Get-ADUser against each DC:

powershell

Get-ADUser jdoe -Server dc01.contoso.com -Properties pwdLastSet | Select-Object Name,pwdLastSet
Get-ADUser jdoe -Server dc02.contoso.com -Properties pwdLastSet | Select-Object Name,pwdLastSet

- pwdLastSet = 0 indicates “must change at next logon.”- Replication tools: - repadmin /showrepl dc02 to see inbound replication status. - repadmin /sync /d <DC> <NamingContext> to force replication.- If replication delayed, check repadmin /replsummary and DC event logs for SYSVOL/AD replication errors.

Notes: ensure auditing for account management and directory service changes is enabled in GPO to capture detailed logs.

HardSystem Design

90 practiced

Describe the process, risks, and rollback options for modifying the Active Directory schema (for example to support Exchange or custom attributes). Include permission requirements, forest-wide replication considerations, testing in labs, and steps to validate schema updates post-deployment.

Sample Answer

**Overview / Approach**Modifying the AD schema is a forest‑wide, irreversible change that must be planned, tested, and executed with change control. Treat it like a major upgrade: document, get approvals, and schedule maintenance windows.

**Permissions**- Must be performed by a user who is a member of Schema Admins and Enterprise Admins (and Domain Admins for associated tasks).- Use an audited, dedicated admin account; enable Just‑In‑Time and MFA where possible.

**Pre‑deploy testing**- Build a lab that mirrors production: same AD functional level, GC placement, replication topology, Exchange/CAD schema tools version.- Apply schema updates in lab and run functional tests (object creation, attribute reads/writes, LDAP queries, backup/restore scenarios).- Run AD health checks (dcdiag, repadmin, NETLOGON tests).

**Risks**- Schema corruption or incomplete replication causing inconsistent object behavior.- Application incompatibility, replication storms, or accidental attribute misuse.- Irreversibility: native rollback is not supported; restoring requires authoritative restore of all DCs or forest recovery.

**Deployment considerations**- Schedule low‑impact window; ensure full system backups and VM snapshots (but do not rely solely on snapshots).- Verify replication is healthy (repadmin /showrepl) and GC availability.- Apply schema updates from a single Schema Master; wait for forest‑wide replication to complete before further changes.

**Validation post‑deployment**- Confirm schema partition changes on all DCs (ldifde -f export and compare, or Get-ADObject for new attributes).- Run repadmin /replsummary and dcdiag; verify event logs for errors.- Test application scenarios: Exchange setup steps, attribute population, authentication, GPO processing.- Monitor for 24–72 hours: replication latency, service logs, user impact.

**Rollback / Recovery**- Native “undo” not supported. Options: - If severe, perform forest recovery via authoritative restore of system state on all DCs (complex and disruptive). - Restore from backups taken pre‑change and rebuild domain controllers if necessary. - Mitigate by deprovisioning features that use new attributes and coordinating with app vendors.- Always have documented recovery runbooks and tested restores before proceeding.

**Best practices**- Change control, communication plan, incremental rollouts, vendor alignment (e.g., Exchange schema prep guidance), and robust monitoring.

Unlock Full Question Bank

Get access to hundreds of Active Directory and User Management interview questions and detailed answers.

Join thousands of developers preparing for their dream job.