One bad account, and suddenly it’s not just one account anymore
If your organisation runs on Windows, Active Directory is probably the thing quietly running everything. Users, computers, groups, permissions, logins, access to the stuff that actually matters, most of it traces back to AD sooner or later. Which is exactly why a weakness in it rarely stays small. Get into the right account, and you’re not looking at one machine, you’re potentially looking at the whole domain.
We go through your AD environment and find the configuration gaps, the excessive privileges, the authentication weak points, before someone finds a way to actually use them.
What we’re actually doing
We look at how your Active Directory is really set up, not how the diagram says it’s set up. Domains, forests, user and group permissions, privileged accounts, Group Policy, service accounts, computer accounts, delegation, trust relationships, admin access, Kerberos, legacy protocols still hanging around, and the paths that connect a normal-looking account to something much more powerful.
The question we’re answering: could someone get from a low-level foothold to real control, and if so, how?
Why bother
AD sits at the center of your identity setup. One compromised privileged account, and depending on how things are wired, that can cascade into a lot more than anyone intended.
We’re looking for excessive admin privileges, weak access controls, accounts nobody’s touched since someone left the company, service accounts nobody’s really managing, Group Policy that’s weaker than it should be, delegation set up too generously, trust relationships that don’t need to exist anymore, legacy authentication still limping along, exposed credentials, and permissions nobody would sign off on if they actually saw them written down.
Environments drift. That’s just what happens over time, reorgs, new hires, old permissions nobody remembers granting. Regular review is really the only way to catch that drift before it becomes a real problem.
What we look at
Domain and forest layout. Domains, forests, organizational units, trusts, admin boundaries. We’re checking for anything that creates exposure or just makes good security harder to maintain.
Users and groups. Privileged groups, admin accounts, nested groups, dormant accounts, former employees who still have access, shared accounts, service accounts, anything holding more than it needs.
Privileged accounts. Domain admins, enterprise admins, delegated admins, local admins, privileged service accounts. Are admin accounts actually separated from everyday ones, or is everyone just using one login for everything?
Group Policy. Password rules, lockout settings, user privileges, security settings, admin controls, authentication config, and any legacy settings or inconsistencies nobody’s cleaned up.
Service accounts. These quietly accumulate more permission than anyone remembers granting. We check for that, plus weak credential management.
Kerberos. As the backbone of AD authentication, its configuration matters a lot, including delegation set up more broadly than it needed to be.
Delegation. A classic privilege escalation path. We check which accounts or systems have more delegation rights than their actual job requires.
Trust relationships. Domains and forests trusting each other for legitimate reasons is normal. We check whether those relationships still make sense, or whether they’ve quietly widened the blast radius if one side gets hit.
Permissions generally. Users, groups, computers, organizational units, all checked for access that doesn’t make sense on closer inspection.
Legacy protocols. Older authentication mechanisms tend to widen your attack surface without anyone actually deciding that on purpose. We find where they’re still in play.
How this actually runs
Scope and planning. We agree what’s being assessed, which domain, which systems and accounts, and what access we need.
Discovery. We map domains, forests, OUs, users, groups, computers, trusts, admin relationships.
Configuration review. We compare what’s actually configured against what secure practice looks like.
Privilege and permission analysis. We dig into privileged groups, permissions, delegation, nested memberships, and where they could lead.
Authentication and policy review. Authentication mechanisms, Group Policy, service accounts, password controls.
Attack path analysis. Where we’re allowed, we trace the relationships between accounts, groups, and permissions to find realistic routes to higher privilege.
Risk prioritisation. Ranked by exposure, exploitability, what’s affected, and how much it could actually cost you.
Reporting and retesting. A clear report on what we found and how to fix it. Once you’ve made changes, we come back and confirm they held.
What tends to turn up
Excessive privileged access. Weak admin controls. Inactive accounts nobody’s cleaned up. Nested group memberships nobody’s audited in years. Weak service account security. Insecure delegation. Trust relationships carrying more risk than value. Weak Group Policy. Legacy authentication. Unnecessary admin privileges. Exposed credentials. Admin and standard accounts that aren’t actually separated. Real escalation and lateral movement paths. Misconfigured computer accounts. More domain-level access than anyone intended.
Assessment vs. penetration testing
Different questions. An assessment finds the configuration weaknesses and excessive permissions. Penetration testing actually tries to exploit them, to confirm what an attacker could really do with what we found. Some organisations need one. A lot get the most value from both, the assessment maps the weak points, the test proves which ones matter.
Assessment vs. a generic vulnerability scan
A vulnerability scan tends to look at systems and applications broadly. This goes deeper into identity specifically, permissions, policies, authentication, privilege, domain architecture. They complement each other, they’re not substitutes.
Who this is for
Enterprise Windows environments. Corporate networks. Data centres. Hybrid IT setups. Large directories. Multi-domain and multi-forest environments. Anything Microsoft-based. Remote workforces. Any business-critical app connected to AD.
It matters most where permissions have quietly evolved over years without anyone stepping back to look at the whole picture, which, honestly, describes most enterprise environments eventually.
When to do this
Before or after major infrastructure changes. After a migration. After a merger or acquisition. After restructuring. Following changes to privileged access. After adding new domains or trusts. During regular security reviews. After a suspected incident. Before compliance work. Whenever legacy systems are still hanging off the domain.
Regular reviews matter because drift is basically guaranteed, roles change, systems get added, “temporary” access never gets revoked, and nobody notices until someone’s specifically looking for it.
How to actually tighten this up
Apply least privilege, genuinely, not just on paper. Manage privileged accounts deliberately. Run access reviews on a schedule. Remove inactive accounts instead of leaving them dormant. Keep admin accounts truly separate from everyday ones. Enforce strong authentication. Manage service account credentials properly. Review Group Policy regularly. Segment your network sensibly. Cut legacy authentication where you can. Monitor privileged activity. Reassess trust relationships periodically. Patch domain infrastructure promptly.
What actually matters depends on your architecture and risk profile, this isn’t a generic checklist to tick off blindly.
Why work with us
We look at this from an identity, configuration, and attack-path angle, not just a settings checklist. How do users, groups, computers, permissions, and admin accounts actually interact across your environment? Where has unnecessary privilege quietly accumulated? Findings come with clear context, real risk ranking, and fixes your team can act on. Once you’ve made changes, we come back and confirm they actually worked.
Bottom line
Active Directory sits at the center of how you manage identity and access, so weaknesses there rarely stay contained. They ripple outward, usually further than anyone expects. A proper assessment finds the excessive privileges, the insecure configurations, the authentication gaps, and the realistic paths an attacker could take, so you’re fixing real exposure instead of guessing.
FAQs
What is an Active Directory Security Assessment?
A review of your AD environment: users, groups, permissions, authentication, policies, delegation, trusts, privileged accounts, and configuration.
Why does this matter?
AD usually controls access to a huge range of systems. A weak permission or compromised privileged account can create risk far beyond where it started.
What does it actually check?
Domain configuration, privileged accounts, permissions, Group Policy, service accounts, delegation, trusts, authentication, and escalation paths.
Can it find actual attack paths?
Yes. We can trace relationships between accounts, groups, and permissions to find realistic routes to higher privilege.
Is this the same as penetration testing?
No. This finds the weaknesses. Penetration testing actually exploits them to prove real-world risk.
How often should we do this?
Depends on your environment, but regularly, and especially after major infrastructure, identity, or domain changes.
Can you assess hybrid setups?
Yes, including where on-premises AD connects to cloud identity and other enterprise services.
What’s in the report?
Identified weaknesses, affected accounts or configurations, risk context, evidence, remediation steps, and retesting results where applicable.
Secure your Active Directory environment
Talk to Sunvak Boreal about your Windows environment. Let’s find out where privilege has quietly built up, and where one compromised account could take someone much further than it should.