Active Directory Architecture and Management Questions
Comprehensive coverage of Microsoft Active Directory and directory services design, deployment, operation, and troubleshooting. Topics include the logical and physical structure of Active Directory such as forests, trees, domains, organizational units, naming contexts, domain controllers, global catalog servers, and site topology. Candidates should understand directory data models and object types and attributes, including user accounts, computer accounts, security groups and distribution groups, group scopes and nesting, membership management, and access control lists and permission models on directory objects. Expect questions on authentication and authorization flows including Kerberos based authentication, Lightweight Directory Access Protocol binds and queries, domain joining, trust relationships between domains and forests, and the impact of domain controller roles including flexible single master operation roles and read only domain controllers. Coverage also includes replication topology and behavior, site awareness and site link design, replication scheduling and conflict resolution, and techniques for troubleshooting replication and connectivity issues. Candidates should be able to explain group policy concepts for centralized configuration and security enforcement, delegation and administrative models, common management consoles and automation and scripting for administration, backup and recovery considerations, and how to design Active Directory deployments for scale, resilience, and integration with broader identity and access management and single sign on solutions.
HardSystem Design
32 practiced
Design a Group Policy strategy for a global organization of 200,000 users that enforces security baselines while minimizing logon times. Address GPO structure and consolidation, central store for ADMX files, use of filtering vs OU placement, loopback scenarios, slow link detection, GPO caching, and tools/metrics you would use to measure and optimize GPO processing at scale.
Sample Answer
**Situation & goals (brief)** Design a scalable Group Policy (GPO) strategy for 200k users that enforces security baselines while keeping interactive logon times low.**GPO structure & consolidation** - Create a small set of global, high-priority baseline GPOs (Account/Password, LAPS, Windows Update, Defender, Firewall, Audit) applied at domain or root OU. - Separate user and computer settings: computer baselines at Sites/Domain; user baselines in dedicated User OU(s). - Use one configuration per feature where possible (e.g., 1 Defender GPO) to reduce processing overhead and GPO linking complexity. - Versioned naming convention: “00-Baseline-Computer-Defender-v1” for clarity and order.**Central Store for ADMX** - Maintain a single Central Store in SYSVOL replicated via DFS-R. Enforce ADMX/ADML versioning and a release process (test OU first). Keep only supported ADMX to avoid policy bloat.**Filtering vs OU placement** - Prefer OU placement for broad scoping. Use security filtering or WMI filtering sparingly for exceptions (e.g., specific hardware); prefer group-based filtering with limited groups and nested groups to avoid expensive WMI queries. Use loopback in “merge” only for kiosk/VDI scenarios.**Loopback scenarios** - Enable loopback processing on tightly-scoped computer OUs (VDI, kiosks, exam stations). Document and limit its use; prefer user-targeted groups where feasible.**Slow link detection & GPO caching** - Adjust slow link threshold only if network topology justifies it; place large resources (scripts, preferences) on local servers per region. - Enable GPO caching (Group Policy Client-side Extensions caching) via registry/policy to reduce SYSVOL hits for roaming users and improve logon performance.**Optimization & measurement tools** - Use Group Policy Operational Event logs, GPResult, and RSOP for validation. At scale use: - Microsoft Message Analyzer/Network Monitor for SYSVOL traffic - Windows Performance Recorder / Xperf for logon trace analysis - AD Audit & SysTrack or Microsoft Endpoint Manager telemetry for aggregate logon times and policy processing durations - PowerShell scripts (Get-GPOReport, Test-GPOs) and GPMC reporting to find redundant/overlapping settings. - Track metrics: average interactive logon time, Group Policy processing time, number of GPOs applied, SYSVOL read volume by site. Run monthly pruning: merge redundant GPOs, remove unused settings, and test before deployment.**Trade-offs & maintenance** - Fewer GPOs = faster logons but less granularity. Compensate with well-managed security groups and scoped links. Automate ADMX and GPO lifecycle, maintain test OUs, and run phased rollouts.
HardTechnical
29 practiced
For an enterprise with 200,000 directory objects and heavy global search/query load, analyze Global Catalog scaling challenges. Discuss Partial Attribute Set (PAS) tuning, impact on replication traffic, GC placement strategies to balance read performance and replication cost, and alternatives such as application-side caching or partitioning attributes across services.
Sample Answer
**Overview / Context**For a 200k-object AD environment with heavy global search, Global Catalog (GC) scaling requires balancing read latency against replication and storage costs. I'll analyze PAS tuning, replication impact, GC placement, and alternatives from a SysAdmin perspective.**Partial Attribute Set (PAS) tuning**- Reduce PAS to include only attributes used by searches (e.g., mail, displayName, sAMAccountName). Exclude large or infrequently searched attributes (homeDirectory, thumbnailPhoto).- Test with auditing: enable search logging or capture queries to build an attribute-use list before modifying PAS.- Apply changes in lab first—changing PAS affects GC database size and replication payload.**Impact on replication traffic**- Adding attributes to PAS increases GC replication payload during initial replication and when attributes change; removal reduces it.- Expect larger USN deltas and higher inter-site replication bandwidth; plan maintenance windows and monitor Directory Replication Latency.- Use staging/incremental rollout to avoid replication storms.**GC placement strategies**- Deploy GCs near heavy read sources: branch office domain controllers or front-end clusters behind read-only proxies.- Use a hybrid approach: limited full GCs in central datacenters and lightweight GCs (reduced PAS) at branches to lower replication cost.- Consider site link costs, replication schedule adjustments, and RTO requirements.**Alternatives**- Application-side caching: implement TTL-based caches or Redis layer for repeated queries to cut GC reads.- Attribute partitioning: store large or rarely searched attributes in a separate database or microservice; apps query GC for identity keys and the service for heavy attributes.- Use LDAP index tuning and read-only replicas (RODCs) where applicable.**Recommendation**- Audit search attributes → minimize PAS → pilot reduced PAS on a subset GC servers → combine with app caching and strategic GC placement (central full GC + branch reduced PAS GCs). Monitor replication bandwidth, latency, and search performance; iterate.
MediumSystem Design
33 practiced
Your organization is adopting Office 365 and needs SSO with on-premises Active Directory while preserving password complexity policies. Compare Azure AD Connect options (Password Hash Sync, Pass-through Authentication, Federation/ADFS). For each method discuss SSO behavior, security trade-offs, operational overhead, and failover/resiliency considerations.
Sample Answer
**Overview / approach**Compare the three Azure AD Connect choices by four axes: SSO behavior (user experience), security trade‑offs, day‑to‑day operational overhead, and failover/resiliency. I’ll answer as a systems administrator evaluating for a hybrid AD environment preserving on‑prem password policies.**Password Hash Sync (PHS)**- SSO behavior: Seamless SSO for domain‑joined devices using Azure AD Seamless SSO; users can authenticate to Office 365 even if on‑prem ADFS isn’t available.- Security trade‑offs: Password hashes (not plain passwords) are synced to Azure AD. If the tenant is compromised, attacker could attempt offline attacks; mitigations include AD FS conditional access, MFA, and strong on‑prem policies.- Operational overhead: Low — single sync server, periodic sync, minimal maintenance.- Failover/resiliency: High — Azure handles auth; on‑prem outage doesn’t block logins. Account lockouts and password policy enforcement still on‑prem at change time (initial change triggers sync delay).**Pass‑through Authentication (PTA)**- SSO behavior: Users sign in against on‑prem credentials via lightweight agents; provides near‑transparent SSO when combined with Seamless SSO.- Security trade‑offs: No password hashes stored in cloud; credentials brokered through TLS to on‑prem. Still needs protection for PTA agents and network paths.- Operational overhead: Moderate — deploy multiple agents (recommended 2+), monitor agent health and connectivity.- Failover/resiliency: Depends on agent availability and on‑prem domain controllers. Use a minimum of two agents in different servers/subnets; if all agents fail, cloud auth fails.**Federation (AD FS)**- SSO behavior: True federated SSO — full control of auth flow; supports complex policies and integrated Windows auth for domain‑joined clients.- Security trade‑offs: Credentials never leave on‑prem; you control advanced policies. But AD FS infrastructure increases attack surface and requires patching, certificate management, and perimeter hardening.- Operational overhead: High — AD FS farms, proxy (WAP), monitoring, certificate renewals, capacity planning.- Failover/resiliency: Must design for HA (multiple AD FS servers, WAPs, load balancing). If federation goes down, users may be unable to sign in unless fallback (e.g., PHS) configured.**Recommendation (systems admin view)**- If you want low ops and good resiliency: PHS + Seamless SSO, add MFA/conditional access.- If you must never store password hashes in cloud and can operate HA federation: PTA (with agents) for simpler setup, or AD FS if you need complex on‑prem rules. For highest control and policy customization choose AD FS but budget for overhead and robust HA.
EasyTechnical
29 practiced
Explain the logical components of Active Directory: forest, tree, domain, organizational unit (OU), and naming contexts. For each component describe its purpose, typical administrative boundaries, and give one concrete example of how you would use it in a mid-sized enterprise (1k-5k users).
Sample Answer
**Forest — purpose & boundary**- Purpose: Topology that contains all AD objects, global schema and configuration, and the global catalog. Trusts are automatic inside.- Admin boundary: Enterprise-wide; schema and forest-level policies handled by AD architects.- Example: I’d use a single forest for the company so we share schema/extensions (e.g., custom employee attributes) and a global catalog for company-wide searches.**Tree — purpose & boundary**- Purpose: Hierarchical namespace of one or more domains sharing contiguous DNS namespace.- Admin boundary: Logical DNS-based grouping; rarely a separate admin domain.- Example: Use a tree if we acquire a subsidiary and want subordinate namespace like europe.example.com under example.com.**Domain — purpose & boundary**- Purpose: Security and replication boundary; stores user/computer accounts, domain controllers, group policies.- Admin boundary: Administrative control and replication scope; usually per legal/IT control unit.- Example: Create one domain for the company (single domain model) to simplify logons and GPO management for ~2k users.**Organizational Unit (OU) — purpose & boundary**- Purpose: Delegation of administration and application of Group Policy without creating new domains.- Admin boundary: Team/department level for delegated admins.- Example: Create OUs for Finance, HR, IT; delegate password resets to Helpdesk for specific OUs and apply finance-specific GPOs.**Naming Contexts (Partitions) — purpose & boundary**- Purpose: The domain, configuration, and schema partitions that define what replicates where (domain NC, configuration NC, schema NC).- Admin boundary: Replication control between DCs and sites.- Example: Ensure domain NC replicates to all DCs for auth, configuration NC replicates to track topology; verify proper site links to limit WAN replication for branch DCs.
HardSystem Design
32 practiced
Design a comprehensive Active Directory backup and disaster recovery plan for a 5-domain forest with an RPO of 1 hour and RTO of 8 hours. Specify backup types and frequency (system state, bare-metal), offsite replication, authoritative vs non-authoritative restore processes, FSMO recovery steps, testing cadence, and procedures to validate AD integrity after recovery.
Sample Answer
**Clarifying constraints**- 5‑domain forest, RPO = 1 hour, RTO = 8 hours. Assume mix of physical and virtual DCs; production has at least two DCs/domain, AD‑integrated DNS, and replication across sites.**Backup types & frequency**- System State (AD/NTDS + SYSVOL): application‑consistent VSS snapshot hourly (meets 1‑hour RPO) using enterprise backup (e.g., Veeam, Commvault, Rubrik) that supports VSS and AD-aware restores.- Transactional/log shipping: if using virtualization, enable incremental CBT/VSS snapshots every 15–30 minutes to shorten recovery of recent changes.- Bare‑metal image: nightly full bare‑metal backup for each DC to allow full server rebuild within RTO.- SYSVOL/DFSR: enable system state + separate file‑level backup every hour; keep separate DFSR staging backups.- Retention: 30 days online, 1 year cold archive.**Offsite replication & storage**- Primary backup target on SAN/NAS in site A; replicate backups asynchronously to secondary site B (WAN) with replication lag target < 15 minutes.- Cloud copy: nightly encrypted copy to Azure Blob or S3 for geographic separation.- Immutable/air‑gapped copy weekly.**Authoritative vs Non‑authoritative restores**- Non‑authoritative restore (usual): restore system state on rebuilt DC, start as normal DC; AD replication will pull updates from other DCs. Use when other DCs are healthy.- Authoritative restore (when you must restore deleted objects/OU or last known good state): perform system state restore on isolated DC in a disconnected network, use ntdsutil authoritative restore commands to mark desired partitions/objects authoritative, then bring DC online and allow replication to overwrite other DCs.Steps (high level):- Boot into Directory Services Restore Mode (DSRM)- Restore system state from backup- For authoritative: run ntdsutil -> authoritative restore -> select NC -> mark- Reboot; force replication and verify.**FSMO recovery**- Check current FSMO holders: netdom query fsmo / or Get-ADForest/Get-ADDomain.- Preferred: transfer FSMO to healthy DC (Move-ADDirectoryServerOperationMasterRole) if original still reachable.- If original is permanently lost: seize roles using ntdsutil on new intended holder, then clean metadata of failed DC (ntdsutil or Remove-ADComputer).- After seize: run repadmin /syncall, dcdiag, and update DNS/GC settings.**Post‑recovery AD integrity validation**- Run dcdiag /v and address errors- repadmin /replsummary and repadmin /showrepl for replication health- netdom query fsmo to confirm roles- Verify SYSVOL/NETLOGON share contents and DFSR event logs- Validate DNS zones and SRV records, run nslookup and dnscmd /enumrecords- Test user authentication, group policies (gpresult on sample clients), and LDAP queries- Run ADRecon/ADInfo checks or custom PowerShell to compare object counts and USNs with pre‑incident snapshot**Testing cadence & runbooks**- Daily: automated verification of backups (checksum, test restores of AD snapshot metadata), repadmin/ dcdiag alerts.- Weekly: restore test of a single DC to isolated network; validate login/GPO/DNS.- Monthly: full system state + bare‑metal restore to DR site for one DC per domain.- Quarterly: full DR tabletop + 50% production failover simulation; annual full forest DR test.- Maintain step‑by‑step runbooks: restore roles, authoritative procedures, contact lists, DSRM passwords, and script library for validation (PowerShell snippets to run dcdiag/repadmin/gpupdate).**Procedures & automation**- Automate backup verification and alerting.- Pre‑stage latest DSRM credentials and store encrypted in vault (e.g., CyberArk/Azure Key Vault).- After any restore/seize: clear lingering objects, run metadata cleanup, and monitor for 72 hours.This plan meets RPO=1h (hourly AD‑aware system state/VSS), RTO=8h (bare‑metal + offsite replicas + documented runbooks and tested procedures) while ensuring FSMO handling, authoritative/non‑authoritative flows, and continuous integrity validation.
Unlock Full Question Bank
Get access to hundreds of Active Directory Architecture and Management interview questions and detailed answers.
