Category Archives: Active Directory

Active Directory Audit Checklist: Privileged Access & Inactive User Reviews with PowerShell

đź§ľ Kapothi Audit Scroll: Forgotten Access Reviews

Auditors flagged: “User access reviews and privileged access reviews are not being conducted for users within Active Directory.” — a classic Kapothi moment.

When auditors raise this finding, it means the organization has not been regularly checking who has access to Active Directory and whether those users still need it. In practice, accounts may remain active long after employees leave, contractors finish projects, or service accounts are created without proper documentation. Privileged groups like Domain Admins or Enterprise Admins may also accumulate members who no longer require elevated rights. This creates a serious security gap — attackers love stale accounts and unused privileges because they are rarely monitored.

The IT department’s responsibility is to close this gap by:

  • Reviewing privileged groups — Identify all members of high‑risk groups and confirm with management that each one still requires access.
  • Checking inactive accounts — Generate reports of users who haven’t logged in for 30 or 60+ days, then disable or remove them after manual review.
  • Documenting approvals — Keep CSV exports and manager sign‑offs as audit evidence to prove reviews are being conducted.
  • Maintaining service accounts — Ensure every service account has a clear owner, documented purpose, and is excluded from bulk disable actions.
  • Repeating regularly — Schedule these reviews (monthly or quarterly) so auditors see a consistent compliance routine.

In short, the audit flag is a warning that access hygiene has slipped. The IT team must demonstrate control by producing evidence of reviews, showing that inactive accounts are cleaned up, and proving that privileged access is tightly managed. That’s how the Kapothi moment is turned into compliance success.

⚡ Privileged Access Review


  # List privileged accounts
  Get-ADGroup -Filter {Name -like "*Admin*"} |
  ForEach-Object { Get-ADGroupMember $_ |
  Select-Object @{Name="Group";Expression={$_.objectClass}}, Name, SamAccountName }
  

⚡ Inactive User Review (30 Days)


# Find enabled accounts inactive for 30 days
Search-ADAccount -UsersOnly -AccountInactive -TimeSpan 30.00:00:00 |
Where-Object { $_.Enabled -eq $true } |
Select-Object Name, SamAccountName, LastLogonDate

# Export inactive accounts (30 days) to CSV for audit evidence
Search-ADAccount -UsersOnly -AccountInactive -TimeSpan 30.00:00:00 |
Where-Object { $_.Enabled -eq $true } |
Select-Object Name, SamAccountName, LastLogonDate |
Export-Csv "InactiveUsers_30Days.csv" -NoTypeInformation

⚡ Optional Cleanup (Disable 60+ Days)


# OPTIONAL ⚠️ Cleanup Command
# Risk: This can disable service accounts or rarely used but valid accounts.
# Recommended: First run the 30-day inactive user listing command above, review manually,
# and only disable accounts after confirming they are safe to remove.
Search-ADAccount -UsersOnly -AccountInactive -TimeSpan 60.00:00:00 |
Where-Object { $_.Enabled -eq $true } |
Disable-ADAccount

⚡ Sensitive Group Memberships


  # Export key group memberships
  $groups="Domain Admins","Enterprise Admins","Schema Admins","Remote Desktop Users","Backup Operators";
  $groups | ForEach-Object {
    Get-ADGroupMember -Identity $_ |
    Select-Object @{Name="Group";Expression={$_}},Name,SamAccountName
  } | Export-Csv "AD_GroupMemberships.csv" -NoTypeInformation
  

⚡ Full AD Group Memberships (One Line)


  # Export all groups with members
  Get-ADGroup -Filter * | ForEach-Object { $g=$_.Name; 
    Get-ADGroupMember $g |
    Select-Object @{Name="Group";Expression={$g}},Name,SamAccountName 
  } | Export-Csv "All_AD_GroupMemberships.csv" -NoTypeInformation
  

Thus the Kapothi was resolved: from audit red flag to compliance evidence, with scrolls of PowerShell wisdom.

Kapothi Scroll: Rebooting Domain Controllers and FSMO Roles

Kapothi Scroll: Rebooting Domain Controllers and FSMO Roles

Kapothi — Sinhala slang for “getting into a big problem” — is our reminder that even in IT, what looks like disaster can be turned into wisdom. Today’s scroll: Do you need to transfer FSMO roles before rebooting a domain controller?

🏛 The Setup

  • Two domain controllers: Server1 and Server2.
  • All FSMO roles (Schema Master, Domain Naming Master, RID Master, PDC Emulator, Infrastructure Master) are on Server1.
  • Question: If you reboot Server1, must you transfer all roles to Server2 first?

🔎 The Truth

No, you don’t need to transfer FSMO roles for a short reboot. Server2 will continue authenticating users, handling DNS, and keeping AD alive. FSMO roles are only required for specific operations (schema changes, RID allocation, time sync from PDC). These can pause briefly without breaking daily logons.

✅ Pre‑Reboot Checklist

Before rebooting Server1, confirm Server2 is healthy:

# Replication health
repadmin /replsummary

# DNS resolution
nslookup yourdomain.local Server2_IP

# Time sync status
w32tm /query /status

# FSMO role holders
netdom query fsmo
  • Ensure Server2 is a Global Catalog (check in Active Directory Sites and Services).
  • Verify clients have Server2’s IP in their DNS list (ipconfig /all).

⚖️ When to Transfer FSMO Roles

  • If Server1 will be offline for days or weeks.
  • If you plan to decommission Server1.
  • If you need high availability for RID allocation or schema changes.

In those cases, transfer FSMO roles to Server2. Otherwise, a simple reboot is safe.

🌌 Kapothi Takeaway

  • Short reboot? No FSMO transfer needed.
  • Long absence or decommission? Transfer roles.
  • Always check replication, DNS, and Global Catalog before reboot.

Kapothi reminds us: what looks like a big problem is often just a small ritual, if you know the scrolls.

🔍 Troubleshooting Active Directory Connectivity

Troubleshooting Active Directory Connectivity

🔍 Troubleshooting Active Directory Connectivity

⚠️ Important: Replace kapothi.com in the commands below with your own AD domain name. For example, if your domain is example.local, substitute accordingly.

1. Check IP & DNS

This command shows the full network configuration of your PC. It helps verify that your DNS server is pointing to your Active Directory DNS, not a public one like Google or Cloudflare.

ipconfig /all
  

2. Ping Domain & Controller

Use ping to confirm basic network connectivity. If the domain or controller doesn’t respond, you may have a firewall or routing issue.

ping kapothi.com
ping <DomainControllerName>
  

3. DNS Resolution

Active Directory relies on DNS. These commands check if your domain resolves correctly and if the required SRV records for LDAP are present.

nslookup kapothi.com
nslookup -type=SRV _ldap._tcp.dc._msdcs.kapothi.com
  

4. Find Domain Controller

nltest queries the domain to locate an available Domain Controller. If this fails, your PC may not be properly joined to the domain or DNS is misconfigured.

nltest /dsgetdc:kapothi.com
  

5. Test Secure Channel

This PowerShell command checks the trust relationship between your PC and the domain. If broken, you can repair it using administrator credentials without rejoining the domain.

Test-ComputerSecureChannel -Server <DomainControllerName> -Verbose
Test-ComputerSecureChannel -Repair -Credential kapothi.com\<AdminUser>
  

6. Kerberos & Time Sync

Kerberos authentication requires synchronized clocks. This command checks that your PC’s time matches the domain controller’s time.

net time /domain:kapothi.com
  

7. Flush DNS Cache

If you’ve recently changed DNS settings, cached records may cause issues. Flushing clears old entries and forces fresh lookups.

ipconfig /flushdns
  

8. On the Domain Controller

Run these commands directly on the DC to check its health and replication status. They help confirm whether the issue is with the PC or the AD infrastructure itself.

dcdiag /test:Connectivity
repadmin /replsummary
  

đź’ˇ Tip: Always check Event Viewer logs on both PC and DC for detailed error messages. Look under System and Directory Service categories.

🛠 Domain Join Fix – File and Printer Sharing

One common cause of “The specified network name is no longer available” during domain join is that File and Printer Sharing is disabled on Domain Controllers. This service is required for SMB and RPC traffic, which Active Directory uses to establish secure channels.

Step 1 – Enable File and Printer Sharing

  • On each Domain Controller, open Control Panel → Network and Sharing Center → Advanced sharing settings.
  • Turn on File and Printer Sharing.
  • Alternatively, check Windows Firewall inbound rules for File and Printer Sharing (SMB-In) and ensure they are enabled.

Step 2 – Verify Access

From a workstation, confirm you can reach the domain shares:

\\kapothi.com\SYSVOL
\\kapothi.com\NETLOGON

If these folders are visible, the DCs are correctly allowing SMB traffic and the workstation should be able to join the domain.

Step 3 – Retry Domain Join

Once File and Printer Sharing is enabled and SYSVOL/NETLOGON are accessible, retry the domain join process. The secure channel should now establish successfully.

Active Directory SID Quick Reference

Active Directory SID Quick Reference

  • SID format: S-1-5-21-<domainID>-<RID>
  • Domain ID: The long middle section (e.g. 3450839898-1007371689-2406560646) is constant for all accounts in the domain.
  • RID: The last number (e.g. 7147) uniquely identifies the user or group.
  • Identity resolution:
Get-ADUser -Identity <SID>
  

→ Returns the user object (SamAccountName, DistinguishedName, etc.).

Useful PowerShell Commands

Full details of user

Get-ADUser -Identity <SID> -Properties *
  

Group memberships

Get-ADUser -Identity <SID> | Get-ADPrincipalGroupMembership
  

Username → SID lookup

Get-ADUser -Identity <username> | Select SID
  

Ritual View 🌱

  • Domain ID → temple walls (shared by all accounts).
  • RID → unique scroll inside the shrine.
  • SID → the true identity key, unchanged even if names are altered.