Active Directory and Identity Management Questions

Answer (Systems Administrator perspective)

Overview & principle
Protecting Domain Admins requires reducing attack surface, separating duties, and adding strong controls so high-privilege credentials are rarely used and never exposed.

Dedicated Admin Workstations (DAWs)

• I require admins to perform all sensitive tasks from hardened DAWs (Windows 10/11 Enterprise or Server with minimal apps, EM/EDR, disk encryption, restricted browser/USB).
• DAWs are domain-joined to a separate admin OU, patched regularly, and used only for admin operations (no email/web browsing).

Privileged Account Vaulting

• Store non-personal privileged credentials in a vault (e.g., CyberArk, Azure AD PIM, HashiCorp Vault).
• Use check-out/check-in workflows, just-in-time provisioning, and session recording to avoid credential reuse and capture who used which creds.

Multi-Factor Authentication (MFA)

• Enforce MFA for all privileged accounts and vault access; prefer hardware tokens or FIDO2 for high assurance.
• Combine MFA with conditional access (location, device compliance) to reduce risk.

LAPS for local admin passwords

• Deploy LAPS to rotate local Administrator passwords per machine, stored in AD, and audited.
• Ensure role-based access to read those values and log all retrievals.

Tiered Administration Model

• Implement tiers (Tier 0 = Domain Controllers/AD, Tier 1 = Servers, Tier 2 = Workstations). Admins have separate accounts per tier: low-privilege daily accounts and separate Tier-0 privileged accounts used only on DAWs.
• Limit cross-tier access and service accounts—treat privileged service accounts like Tier-0 assets.

Monitoring & Detection

• Log and SIEM all privileged activities: vault access, LAPS reads, DAW logins, privileged Kerberos events (4768/4769/4672), unusual interactive logons, and lateral movement indicators.
• Deploy EDR and alert on credential dumping, pass-the-hash/kerberos anomalies, and suspicious service creation.
• Regularly review vault audit trails and run red-team exercises to validate controls.

Practical example
I implemented DAWs + CyberArk + MFA and LAPS: result—vault session recordings reduced unauthorized use, LAPS removed shared local admin creds, and alerts on DAW logins caught a compromised workstation before domain impact.

Trade-offs

• DAWs and vaults add overhead and training; balance security with operational usability via automation (just-in-time access, delegated workflows).

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.

Role of the Global Catalog (GC)
The GC is a read-only partial replica of every object in the forest that stores a subset of attributes used for search and logon. It enables forest-wide searches and helps resolve universal group membership during authentication.

Data stored vs full domain partitions

• Full domain partition (on a domain controller): contains all attributes for objects in that domain.
• GC: contains objects from all domains but only the Partial Attribute Set (PAS) — commonly used attributes like sAMAccountName, objectGUID, and memberOf — not every attribute.

How PAS affects queries

• Queries against the GC can return results quickly for PAS attributes.
• If a query requests non-PAS attributes, the GC will refer the client to a domain controller holding the full domain partition, adding latency.

When GC is needed for auth and universal group membership

• GC is required during user logon when the user or resources involve universal groups (to evaluate membership across the forest).
• Also required for forest-wide searches and for services that need universal group information.

GC placement and logon traffic across sites

• Place at least one GC per site with users who authenticate frequently to reduce inter-site RPC/LDAP traffic and avoid slow logons.
• Without a local GC, authentication that requires universal group expansion will generate cross-site calls to a remote GC, increasing WAN traffic and logon time.

Example action: ensure at least one writable DC that is also a GC in high-latency/large-user sites to optimize logon performance.

Approach & key design choices

• Read HR CSV, build in-memory dictionaries for fast lookups; operate in batches to limit DC load.
• Use Get-ADUser with -Filter on samAccountName for existing lookup; create disabled accounts when missing.
• Use a transactional pattern (preview then apply) and write idempotent audit lines with a checksum to avoid duplicates.
• Throttle using Start-Sleep between batches and Parallelism with runspaces avoided to keep safe for DCs.

Core PowerShell function

function Sync-HRToAD {
  param(
    [Parameter(Mandatory)][string]$CsvPath,
    [int]$BatchSize = 500,
    [int]$PauseMs = 500
  )

  Import-Module ActiveDirectory
  $hr = Import-Csv $CsvPath | ForEach-Object {
    $_ | Add-Member -NotePropertyName _hash -NotePropertyValue ((($_.employeeID,$_.sAMAccountName,$_.givenName,$_.sn,$_.title,$_.managerID) -join '|') | Get-FileHash -Algorithm MD5).Hash -PassThru
  }

  # build lookup
  $hrBySam = @{}
  foreach($u in $hr){ $hrBySam[$u.sAMAccountName] = $u }

  # get AD users in same scope (only sAMAccountNames present) in pages
  $allAD = @()
  $properties = 'employeeID','sAMAccountName','givenName','sn','title','manager','Enabled'
  $page = 0
  do {
    $adPage = Get-ADUser -Filter * -Properties $properties -ResultSetSize $BatchSize -SearchBase (Get-ADDomain).DistinguishedName -Server (Get-ADDomainController -Discover -Service ADWebServices).HostName -ErrorAction Stop
    if($adPage.Count -eq 0){ break }
    $allAD += $adPage
    $page += 1
    Start-Sleep -Milliseconds $PauseMs
  } while($adPage.Count -eq $BatchSize)

  $adBySam = @{}
  foreach($a in $allAD){ $adBySam[$a.sAMAccountName] = $a }

  $auditLog = Join-Path $env:ProgramData 'HRSync-Audit.log'

  function Write-Audit($sam,$action,$hash){
    $line = "{0} | {1} | {2} | {3}" -f (Get-Date -Format o), $sam, $action, $hash
    # idempotent: only append if not already present
    if(-not (Select-String -Path $auditLog -Pattern ([regex]::Escape($line)) -Quiet)){
      Add-Content -Path $auditLog -Value $line
    }
  }

  # Process creates/updates
  foreach($batch in ($hrBySam.GetEnumerator() | ForEach-Object { $_ } | ForEach-Object -Begin {$i=0} -Process { $i++; [PSCustomObject]@{Index=$i;Item=$_} } | Group-Object { [math]::Floor(($_.Index-1)/$BatchSize) } )){
    foreach($entry in $batch.Group){
      $sam = $entry.Item.Value.sAMAccountName
      $hrRec = $entry.Item.Value
      if($adBySam.ContainsKey($sam)){
        $ad = $adBySam[$sam]
        $needUpdate = $false
        $modify = @{}
        foreach($prop in @('employeeID','givenName','sn','title')){
          if(($ad.$prop -as [string]) -ne ($hrRec.$prop -as [string]) ){ $modify[$prop] = $hrRec.$prop; $needUpdate = $true }
        }
        # manager resolution by employeeID -> DN
        if($hrRec.managerID){
          $mgr = $allAD | Where-Object { $_.employeeID -eq $hrRec.managerID } | Select-Object -First 1
          $mgrDN = $mgr.DistinguishedName
          if($mgrDN -and $mgrDN -ne $ad.manager){ $modify['manager'] = $mgrDN; $needUpdate = $true }
        }
        if($needUpdate){
          Set-ADUser -Identity $ad -Replace $modify
          Write-Audit $sam 'Updated' $hrRec._hash
        }
      } else {
        # create disabled user minimal required attributes
        New-ADUser -SamAccountName $sam -Name ("{0} {1}" -f $hrRec.givenName,$hrRec.sn) -GivenName $hrRec.givenName -Surname $hrRec.sn -Title $hrRec.title -EmployeeID $hrRec.employeeID -AccountPassword (ConvertTo-SecureString 'P@ssw0rd!' -AsPlainText -Force) -Enabled $false
        Write-Audit $sam 'CreatedDisabled' $hrRec._hash
      }
    }
    Start-Sleep -Milliseconds $PauseMs
  }

  # Disable AD users missing from HR
  foreach($ad in $allAD){
    if(-not $hrBySam.ContainsKey($ad.sAMAccountName)){
      if($ad.Enabled -ne $false){
        Disable-ADAccount -Identity $ad
        Write-Audit $ad.sAMAccountName 'DisabledMissingFromHR' $ad.sAMAccountName
      }
    }
  }

  "Sync completed. Audit: $auditLog"
}

Why these choices

• In-memory dictionaries give O(1) lookups for 100k users; batching and PauseMs protect domain controllers.
• Using per-record hash makes audit idempotent: repeated runs don't duplicate actions unless data changes.
• Minimal create (disabled + temp password) follows security posture; operator can set password policies/OU placement as needed.
• Transaction safety: function is safe to re-run; major changes are discrete AD cmdlets — for full transactional guarantees use AD recycling or snapshots, but that’s uncommon.

High-level summary
Kerberos is a ticket-based authentication protocol Active Directory uses to prove identity without sending passwords over the network. As a systems administrator you’ll see it for logons, AD LDAP/LDAPS, CIFS, and service-to-service auth.

Key components

• Key Distribution Center (KDC): runs on each domain controller; includes Authentication Service (AS) and Ticket Granting Service (TGS). Stores user and machine keys (derived from passwords).
• Ticket Granting Ticket (TGT): a time-limited, encrypted ticket the KDC issues after initial credentials are verified. It proves a user is authenticated to the KDC.
• Ticket Granting Service (TGS): part of KDC that issues service tickets when presented a valid TGT and service request.

Client flow to obtain a service ticket

1. Client sends AS-REQ to KDC with username (no password).
2. KDC verifies credentials (uses stored hash) and returns AS-REP containing TGT (encrypted with KDC key) plus a session key encrypted with the client’s key derived from password — client decrypts using its password-derived key and stores TGT.
3. When accessing a service, client sends TGS-REQ to KDC presenting the TGT and requested SPN (service principal name).
4. KDC (TGS) validates TGT and returns a service ticket (TGS-REP) encrypted with the service account key plus a session key for client-service communication.
5. Client presents the service ticket to the target server; server decrypts with its key, validates and establishes a secure session (mutual auth if required).

Operational notes

• TGT lifetime, renewals, and clock skew are common troubleshooting points.
• Ensure SPNs are correctly registered and service account keys/passwords in sync to avoid ticket decryption failures.