Windows Server Administration Questions

Approach (brief)
Use the ActiveDirectory module cmdlets with existence checks so the script can be run repeatedly without creating duplicates.

PowerShell (idempotent)

# Requires: RSAT-AD-PowerShell (ActiveDirectory module)
Import-Module ActiveDirectory

$sam = 'j.smith'
$upn = 'j.smith@corp.contoso.com'
$display = 'John Smith'
$ou = 'OU=Users,DC=corp,DC=contoso,DC=com'   # adjust target OU
$group = 'Sales'
$initialPassword = (ConvertTo-SecureString 'P@ssw0rd!ChangeMe' -AsPlainText -Force)

# Create user if not exists
if (-not (Get-ADUser -Filter { SamAccountName -eq $sam } -ErrorAction SilentlyContinue)) {
    New-ADUser -Name $display `
               -SamAccountName $sam `
               -UserPrincipalName $upn `
               -DisplayName $display `
               -Path $ou `
               -AccountPassword $initialPassword `
               -Enabled $true
} else {
    # Ensure properties and enabled state are correct
    Set-ADUser -Identity $sam -DisplayName $display -UserPrincipalName $upn
    Enable-ADAccount -Identity $sam
    # Optionally reset password if desired:
    # Set-ADAccountPassword -Identity $sam -NewPassword $initialPassword -Reset
}

# Add to group if not already a member
if (-not (Get-ADGroupMember -Identity $group -Recursive | Where-Object { $_.SamAccountName -eq $sam })) {
    Add-ADGroupMember -Identity $group -Members $sam
}

Required modules & permissions

• Module: ActiveDirectory (install RSAT-AD-PowerShell on client/server)
• Permissions: delegated rights to create/manage accounts and modify group membership (Domain Admins, Account Operators, or a delegated OU-level role)

Idempotency notes

• Uses Get-ADUser and Get-ADGroupMember checks before creating/adding.
• Safe to re-run; Set-ADUser/Enable-ADAccount update existing account instead of duplicating.

Approach (summary)
Use role-based security groups, assign permissive share ACL (Change) and enforce final rights via NTFS ACLs on the folder. Use inheritance from the departmental root folder and Domain Local groups on the file server to support cross-domain memberships and least privilege.

Groups & scope

• Dept-Managers (Global) — contains manager user accounts
• Dept-Employees (Global) — contains employee user accounts and nested teams as needed
• Dept-HR (Global) — contains HR user accounts
• FileShare-Dept-Access (Domain Local on file server domain) — NTFS ACLs applied to this group; members = Dept-Managers, Dept-Employees, Dept-HR (and other cross-domain global/universal groups as required)

Reason: Global groups hold users; Domain Local group applied to ACL supports cross-domain/global membership without changing ACLs.

Share and NTFS assignments

• Share permission on \fileserver\deptshare: Authenticated Users or Everyone — Change (or Full). Rationale: simpler management; restrict via NTFS.
• NTFS on \DeptRoot (inherit to children):
  • Dept-Managers: Full Control (propagate to all subfolders)
  • Dept-Employees: Modify, Traverse/Read & Execute, List Folder Contents, Read & Write
  • Dept-HR: Read & Execute, List Folder Contents, Read
• Avoid explicit Deny entries; use them only for narrowly scoped exceptions.

Inheritance

• Apply permissions at DeptRoot and enable inheritance so subfolders inherit unless broken for sensitive folders.
• For sensitive subfolders, remove inheritance and set explicit NTFS permissions (e.g., Managers only).

Auditing & verification

• Enable Object Access auditing via GPO (Success/Failure) and enable SACLs on DeptRoot for Read/Write/Delete as needed. Monitor Security logs / SIEM for access events.
• Verify effective permissions:
  • GUI: Security tab → Advanced → Effective Access (select user or group)
  • PowerShell:
    • Get-ACL and parse DACL: ```powershell
      (Get-Acl '\fileserver\deptshare\DeptRoot').Access

    • Resolve group nesting and members: ```powershell
      Get-ADPrincipalGroupMembership user | Get-ADGroup -Properties groupScope

  • Tools: Sysinternals AccessChk to test a user’s effective rights: ```cmd
    accesschk.exe -u domain\user \fileserver\deptshare\DeptRoot

  • On a test machine, log in as user and run whoami /groups to confirm token and then Effective Access GUI to confirm real-world effect.

Cross-domain & nested groups notes

• Use Global groups for users, Universal if multi-domain forest membership needed, and Domain Local for ACLs on resource domain. Confirm Kerberos token has expanded groups (large token issues may arise).
• For nested or cross-forest trusts, validate group resolution with Get-ADGroupMember and test actual access (AccessChk / Effective Access).

Verification checklist

• Confirm share permission is not overly restrictive (Change/Full for Everyone) and NTFS enforces roles.
• Audit SACLs generating events on access.
• Test representative users from each role (and nested/cross-domain accounts) with Effective Access and AccessChk.
• Document ACLs, group membership, and change control for future audits.

Direct answer (overview)
If you’re at a standalone or isolated Windows Server with an unknown local Administrator password and no DC access, use supported administrative recovery workflows that preserve data: Windows Recovery Environment (WinRE), offline registry/System hive management, built-in recovery/restore options, or an in-place repair install — avoid unsupported “exploit” hacks.

Safe, supported workflows

• WinRE recovery: boot to WinRE (F8/installation media) and use the built-in Recovery options (System Restore, Startup Repair, or Command Prompt) to perform supported repair or restore operations. This can allow a repair install that preserves data and local accounts.
• Offline SYSTEM/Registry mount (authorized troubleshooting): with administrative approval, mount the system hive from WinRE or from another working OS instance (reg load/Regedit) to inspect/restore account and policy settings or to enable Windows repair features. Treat this as sensitive forensic activity and log actions.
• Restore from trusted backup or System State: recover the SAM or a known-good system image from backups to restore local account access without destructive reinstall.
• In-place upgrade/repair install: run a repair install using the original Windows media to preserve data and most settings while restoring system files and account functionality.

When domain tools apply

• If domain-joined and reachable later, use LAPS, Group Policy, or domain admin-controlled password reset. For DC-less situations, restore from domain controller backups once network is restored.

Security & compliance considerations

• BitLocker: ensure you have recovery keys before mounting disks or moving drives; otherwise data can be irretrievably locked.
• Authorization and audit: get management approval, perform changes under change control, and record actions in logs for compliance (who, when, why).
• Least privilege & rotation: after recovery, rotate credentials, review local admin membership and audit logs, and enforce MFA where possible.
• Avoid unapproved tools: don’t use undocumented exploits or third-party toolkits that break compliance.

Preventive mitigations

• Deploy LAPS for domain-joined hosts and documented “break-glass” local account procedures for standalone servers.
• Maintain tested full-system backups and BitLocker recovery key escrow.
• Document and test recovery runbooks and schedule periodic DR drills.

This approach preserves data, follows supported Microsoft recovery mechanisms, and balances operational need with security and auditability.

Situation & goal
I would treat this as a suspected Active Directory compromise involving a privileged domain account and immediately begin coordinated forensics + IR to identify scope, preserve evidence, and contain lateral movement.

Logs & Event IDs to collect

• Domain Controllers (AD / DC): Security log, Sysvol, NTDS.dit snapshot (if authorized)
  • Key Event IDs: 4624 (Logon), 4625 (Logon failure), 4672 (Special privileges), 4768/4769/4770 (Kerberos TGT/service ticket), 4776 (NTLM auth), 4662 (Directory service object access), 5136 (AD object modification), 1102 (audit log cleared)
• Endpoints/Servers: Security, System, Application, PowerShell/ScriptBlock transcription, Sysmon
  • Sysmon IDs: 1 (process create), 3 (network connect), 6/7 (driver/file create), 10 (process access), 11/12 (file create/write)
• Network: firewall/IDS logs, authentication proxies, Windows Event Forwarding collector logs

Preserve evidence & integrity

• Isolate affected hosts to network segment but do not power off; take live memory captures (WinPMEM), disk images (Bitlocker keys handled), and export event logs via wevtutil or EDR with timestamps preserved.
• Record SHA256 hashes of images, store on write-once media, document acquisition tool, operator, date/time (UTC), and chain-of-custody form.
• Ensure NTP drift check; preserve original system time metadata; collect .evtx with API to avoid truncation.

Identify lateral movement & abuse

• Look for:
  • Pass-the-Hash/NTLM: 4624 logons with Authentication Package = NTLM, Logon Type 3/10 from odd hosts; 4776 NTLM authentication failures/successes; unusual workstation as source for DC logons.
  • Kerberos anomalies: multiple/failed 4768 requests, golden ticket indicators (unusual krbtgt service ticket lifetimes), S4U2Self/S4U2Proxy misuse (4769 for service tickets).
  • Lateral tools: Sysmon process chains spawning psexec/wmi (wmic, winrm), suspicious remote service creation.
• Correlate timeline: cross-reference 1) high-privilege logons (4672), 2) new service installations, 3) replication or AD object edits (5136/4662).

Immediate containment steps

• Disable compromised account(s) or reset credentials after collecting live session artifacts; revoke Kerberos tickets by resetting krbtgt twice (scheduled, with understanding of impact).
• Implement network-level blocking between compromised hosts, isolate jump hosts, and disable remote management channels used (Admin$/SMB/RPC) only after evidence capture.
• Rotate secrets and privileged credentials via privileged account management, reset service account passwords where feasible.

Chain-of-custody & legal

• Log every action in an evidence log: who, when (UTC), tool, rationale; use write-once storage; preserve original media; coordinate with legal/HR for escalation; avoid altering original data beyond necessary live captures.

Post-incident

• Rebuild compromised hosts from known-good images, harden DC auditing (Sysmon, enhanced logging), enforce LAPS/PAWs, MFA for admin accounts, and continuous EDR/SIEM alerting for the above indicators.

Situation / Goal
I needed Help Desk to reset passwords and unlock accounts only for users in the Employees OU, with full auditability and least-privilege controls.

Delegation steps (practical)

• Open Active Directory Users and Computers, right-click Employees OU → Delegate Control.
• Add the Help Desk group.
• Use the wizard: choose “Create a custom task to delegate” → “Only the following objects in the folder” → select “User objects.”
• Grant permissions: “Reset user passwords and force password change at next logon.”
• If unlock requires explicit ACL change, use Advanced Security on the OU to grant Write lockoutTime (or use granular ACE via “Delegate Control” to add that right).

If using AD ACLs directly

• Open ADUC → View → Advanced Features → OU Properties → Security → Advanced → Add Help Desk group → select specific Extended Rights: “Reset Password” and allow write lockoutTime.

Auditing configuration

• Enable success auditing for “Account Management” in Group Policy (Computer Configuration → Policies → Windows Settings → Security Settings → Advanced Audit Policy Configuration → Account Management → Audit User Account Management: Success).
• Configure SACL on Employees OU (Advanced Security → Auditing) to audit Success for Reset Password and Write lockoutTime.
• Forward logs to SIEM; alert on Event IDs: 4724 (password reset attempt), 4767 (account unlocked), and correlate with ticket IDs.

Procedural controls for least privilege & accountability

• Require ticket with unique ID and approval before Help Desk action; log ticket ID in AD operation notes.
• Enforce MFA for Help Desk consoles and privileged sessions.
• Monthly access review (recertification) of the Help Desk group memberships.
• Implement Just-In-Time elevation (Privileged Access Management) for sensitive cases.
• Retain audit logs 1 year; run weekly automated reports of resets/unlocks and investigate anomalies.

Result: Help Desk can perform necessary support without expanded rights, all actions are auditable and controlled, preserving least privilege and accountability.