The Vilkas Wire
Top 5 Dangerous Vendor Configuration Mistakes That Lead to Active Directory Compromise
Mar 26, 2026 · By Ben Rollin
Some of the most dangerous footholds we find during internal penetration tests don’t come from exploits or missing patches, but rather from following vendor documentation to the letter.
We still see vendors instructing administrators to deploy software in ways that weaken Active Directory and overall network security. These types of setup steps are common, appear in otherwise trusted guides, and often result in reliable attack chains. The attacks we see are often due to documentation that prioritizes getting the product working over properly securing it, not just poor decisions on the part of a sysadmin.
Why Insecure Vendor Guidance Persists
Vendor documentation is typically written to ensure the product works the first time in as many environments as possible. That means reducing pain points during setup and avoiding anything that might cause issues or generate support tickets. The easiest way to do that, unfortunately, is to grant broad permissions and remove potential blockers, even if it introduces risk.
This does not come with malicious intent; in fact, in most cases, the guidance itself isn’t even considered “wrong” from the vendor’s perspective. It achieves the goal of quickly getting the system operational. The problem is that this guidance often ignores how those same configurations behave in a real Active Directory environment where attackers are actively looking for privilege escalation paths.
There’s also dwell time between how documentation is written and how attacks evolve in the wild. Many of these recommendations were put together years ago and never revisited, even as techniques like Active Directory Certificate Services (AD CS) abuse, ACL-based lateral movement and domain privilege escalation, and credential extraction from service contexts became widely understood.
We sometimes see vague language like “ensure the account has sufficient privileges,” which almost always results in over-permissioning. Even when warnings exist, they tend to be buried or written in a way that doesn’t reflect the actual risk. A well-intended, quick functional setup can all too easily become a long-term configuration. By the time anyone reviews the configuration from a security standpoint, it's tied into production systems and may be difficult to detangle without causing operational impact.
For these very reasons, we continue to see the same issues pop up across completely different environments, to the point where it's no longer random misconfigurations but rather consistent implementation of the same types of guidance.
The Top 5 Documentation-Driven Misconfigurations
1. “Install as Domain Admin”
Many enterprise products still recommend installing under a Domain Admin account to simplify permissions, which often just turns the product into a built-in privilege escalation path.
We routinely recover credentials for highly privileged accounts from service registry keys, scheduled tasks, application configuration files, and logs. The best part is that the credentials are typically stored in clear text, which results in quick and easy domain compromise.
Fix: Configure a dedicated service account (or local administrator account if possible) with only the permissions required for the product to function. If a vendor service truly “needs” Domain Admin (accept, perhaps in rare circumstances), that points to a design issue, not something you should accept.
2. Broadly Granted Dangerous AD Permissions (ACLs)
Vendor guides often instruct administrators to delegate broad permissions, such as full control over OUs, WriteDACL, or the ability to create and modify users and computers. These permissions may be framed as necessary for automation or integration.
Back in the real world, these are some of the most dangerous permissions you can grant in Active Directory. We regularly see these turn into direct attack chains where an attacker can reset passwords, modify SPNs, or take control of key objects and pivot to full domain compromise.
Various open-source penetration testing tools highlight these issues immediately because they provide clear paths to privilege escalation.
Fix: Delegate only what is explicitly required at the attribute or object level, and validate the result with tooling to make sure you didn’t introduce unintended escalation paths.
3. Insecure Certificate Template or PKI Instructions
Some PKI integration guides still recommend granting “Authenticated Users” enrollment rights or removing approval requirements for convenience, effectively turning AD CS into a privilege-escalation mechanism. When certificate templates are overly permissive, all it takes is a standard domain user account to request certificates usable for authentication and pivot directly to Domain Admin through known abuse paths like ESC1 and ESC4, among others.
This is one of the most common real-world escalation chains we see during many of our internal penetration tests.
Fix: Restrict enrollment to specific groups, require manager approval where appropriate, and audit certificate templates regularly for risky settings.
4. Overly Permissive AD Group Membership
It’s very common to see documentation recommending adding a service account to the Domain Admins group or to multiple built-in privileged groups (typically better left empty unless needed for a specific task) just to get something working.
This may start out as a temporary setup step, but it almost always becomes permanent. Once that account is in a highly privileged group, any compromise of the service it is tied to grants an attacker immediate domain-admin-level access, enabling domain takeover.
This pattern is a constant. We can often tell exactly which services are in use by querying the member list of the Domain Admins group, a direct result of various companies following the same guidance.
Fix: Define exactly what access is required and implement it through scoped groups, tiered administration, or local permissions where possible. Adding something to Domain Admins should never be the default solution.
5. Service Accounts with “Log On Locally” or AutoLogon Enabled
Troubleshooting steps often involve granting “log on locally,” enabling AutoLogon, and running services as SYSTEM or as a highly privileged domain account. These changes introduce the very real and all too common risk of credential exposure.
We regularly recover credentials from LSA Secrets, AutoLogon registry keys, and the memory of processes running under privileged service accounts. AutoLogon, in particular, stores credentials in the registry in a reversible format, and services running with elevated privileges frequently leave usable credentials behind. Gaining local administrator on a machine and stealing clear-text privileged domain credentials from LSA Secrets is a standard attack at this point.
If an attacker lands on a system configured this way, there is a strong chance they can extract reusable credentials and move laterally.
Fix: Use Group Managed Service Accounts (gMSAs) or properly scoped service accounts, avoid AutoLogon entirely, and do not grant local logon rights unless absolutely required. Any systems running privileged service accounts should be treated as high-risk.
Honorable Mentions
Plaintext Passwords in Configuration Files
A crowd favorite. Documentation tells admins to place credentials directly in config files like web.config, often in locations readable by standard users, opening a quick-and-dirty path to domain compromise or, at least, to the compromise of a key web or database server.
Fix: Use a secrets manager, DPAPI, or at minimum lock down file permissions.
Overly Broad Firewall or Network ACL Recommendations
Telling administrators to “open all ports” between systems sure makes connectivity easier, but it also creates a lateral movement path across the environment. Once inside the network, attackers rely on exactly this kind of access to move around unencumbered.
Fix: Define required ports explicitly, enforce host-based firewalls, and monitor unexpected traffic.
Legacy Community Posts That Never Die
Even after vendors update their guidance, old recommendations stick around in forums, blogs, and internal docs. We've gained footholds and compromised domains through copy-pasted, sloppily written scripts with hardcoded credentials in clear text.
Fix: Treat community content as untrusted and validate against current security guidance. Audit any "helper" scripts found online and do not re-use snippets that require hardcoded credentials.
The Elephant in the Room: Scale
Unfortunately, these issues don’t happen in isolation; much to the contrary. One line in a vendor setup guide can lead to the same misconfiguration being deployed across hundreds or thousands of environments. There's a reason why an experienced penetration tester knows quickly where to look and may get jaded from time to time seeing the same issues over and over.
Attackers know this too, and they study vendor documentation just as closely as defenders do. While in some instances these may be isolated mistakes by sysadmins, they're more often a predictable outcome of following trusted guidance.
How to Defend Against Mis-Documentation
The most effective defense is to stop treating vendor documentation as authoritative from a security standpoint; instead, treat it as a starting point, not a final state.
Review the permissions being granted before deploying anything new in the environment and assume that anything overly broad was chosen for convenience, not security. After deployment, validate the changes using widely available tooling or, if the changes are considerable, bring in a penetration tester.
Avoid using Domain Admin entirely for application setup and test deployments in a segmented environment before rolling them into production. Most importantly, train teams to question guidance rather than copy and paste it.
Closing Thoughts
Most compromises originate from a long-forgotten setup guide instructions, rather than fancy exploits
Our Testers consistently find that documentation-driven misconfigurations are some of the fastest paths to domain compromise. Real security testing isn’t just about finding vulnerabilities; it's about validating whether the way your environment was built can withstand an attacker. Don't blindly trust vendor documentation, and don't be afraid to push back when guidance seems iffy.
One last thought while we're on the subject, don't forget to change default credentials when setting up a new application or service!
Have a question about this article or a security challenge of your own?
Vilkas Cybersecurity helps organizations uncover and fix identity-driven attack chains. Fill out the form, and we'll get back to you shortly.