Category: Windows Active Directory

Posted on

Active Directory Disabled Accounts are not Dead

Why Disabled Accounts in Active Directory Are a Security Risk You Can’t Ignore
When an employee leaves or a service account is retired, the easy move is to just disable the account and move on. But disabled accounts are often overlooked during security reviews, and that neglect can create serious gaps in your environment. Attackers know this — disabled doesn’t mean unreachable, especially if the account still exists in Active Directory with its original group memberships and permissions intact. A compromised disabled account with Domain Admin group membership is just as dangerous as an active one.

The real problem is that disabled accounts accumulate over time, and most IT teams don’t have a reliable process to audit them regularly. When you’re focused on active threats, it’s easy to forget that a stale account with overly permissive group membership is a ticking clock. The fix is straightforward: schedule regular reviews of disabled accounts, strip unnecessary group memberships as part of the disable process, and treat disabled accounts with the same rigor as active ones when it comes to sensitive group membership.

A practical starting point is running a PowerShell query to pull all disabled accounts and their group memberships at once, then cross-referencing against your most sensitive groups like Enterprise Admins and Domain Admins. This takes an hour or two to set up and can surface accounts that have been sitting with elevated permissions long after they should have been cleaned up. The goal is simple: disabled accounts should have zero access to anything critical.

PowerShell Sample script:

$DisabledUsers = Get-ADUser -Filter {Enabled -eq $false} -Properties MemberOfforeach ($User in $DisabledUsers) { Write-Host “Username: $($User.Name)” foreach ($Group in $User.MemberOf) { Write-Host “Group: $Group” }}
}

Posted on

GPO Security Filtering: Best Practices

By default, Authenticated Users is added to Security Filtering when creating a GPO, which applies it broadly to all users/computers — acceptable for simple environments, but not ideal.

The recommended approach is to target a specific group via Security Filtering. However, a common mistake is removing Authenticated Users entirely, which strips the built-in read privileges needed for the GPO to process correctly.

The correct method: Rather than removing Authenticated Users from the Scope tab, leave it in place and revoke only its Read permission via the Delegation tab:

  1. Go to Delegation → Advanced
  2. Under Authenticated Users, uncheck Read
  3. Return to the Scope tab — Authenticated Users will no longer appear in Security Filtering
Posted on

GPO does not apply when using custom user groups

The simplest method to using a custom user group is to remove the “Authenticated Users” group and add the custom user group created.   This is what everyone says including Microsoft.  The problem is that now the GPO does not apply anywhere.    There are a lot of things attached to “Authenticated Users” like computers and special permissions that you lose when you remove it entirely.  So if you keep it there and just remove the apply privilege the custom groups will work correctly without needing to figure out what needs to be added.

The simple method is to not remove but modify the “Authenticated Users group.   Go ahead and add the custom user group either before or after this modification.

Go to the Delegation tab and hit Advanced.   Then select “Authenticated Users” and remove the check from “Apply group policy” and apply.   After doing this you can go back to Scope and “Authenticated Users” will not be there.  The group policy is now ready for use.

Contact us