When a domain infrastructure assessment is commissioned, the client usually expects the finding to be an unpatched server. In practice, the most common path from an ordinary user account to full control of the domain is assembled from configurations that are not vulnerabilities but decisions - taken long ago, for a good reason that no longer holds.
These five recur most often.
1. Legacy protocols nobody uses but that are still enabled
Local name resolution protocols left enabled because one application once needed them. The result is that an attacker on the network can induce clients to send authentication material, without a single exploit.
Check: are legacy name resolution protocols and older file sharing dialects disabled, and is traffic signing required? Obstacle: almost always one old application nobody wants to touch.
2. Delegation that is broader than anyone realises
Delegation lets an account act on behalf of a user. Configured without constraints, it means compromising one server grants access to everything the users who connected to it can reach.
Check: which accounts have unconstrained delegation, and is any of them user-facing? Fix: move to constrained delegation and flag sensitive accounts as not delegatable.
None of these findings appears as critical in a vulnerability scanner report. All of them only become visible when you look at relationships between objects rather than the state of an individual server. That is why a domain assessment is not the same thing as a network scan.
3. Passwords in attributes and scripts
Descriptive attributes on objects are readable by any authenticated user. Service account passwords regularly turn up in them, entered for convenience. The same applies to scripts in shared folders that execute at logon.
Check: search attributes and shared folders for strings that look like passwords. The result is rarely empty.
4. Privileged membership that survived a job change
An administrator who solved one problem three years ago, was added to a privileged group and never removed. Or a service account for a decommissioned application that remains active with domain administrator rights.
Check: how many accounts are in the most privileged groups, when did each last log on, and who owns it? Typical finding: the member count is in double digits and the number who genuinely need those rights is in single digits.
5. Domain backups reachable from the domain
A copy of the domain database contains everything. If it sits on a share accessible to ordinary server administrators, the path to full control runs through it - without a single attack on a domain controller itself.
Check: who has access to backups, are they encrypted, and is a copy reachable from the production domain? This is also the most direct link to measure 12 - a backup that ransomware can reach is not a backup.
Connecting this to your obligations
All five findings belong to measures in Annex II of the Croatian Cybersecurity Regulation, and specifically to those most often self-assessed as implemented:
- Legacy protocols and configuration - measure 6, network security
- Delegation and privileged membership - measure 7, access control
- Passwords in attributes - measure 4, digital identities
- Access to backups - measures 5 and 12
That is why a technical assessment and a compliance assessment should not be separate projects. A document asserting that access control is established, alongside a finding of seventeen domain administrators, does not survive serious scrutiny.
A domain security assessment is carried out under written authorisation and within an agreed scope. All the checks above can be run against a production domain without interrupting service, but they do leave traces in monitoring - agree them with the team watching the logs, or your first finding will be your own test.
Sources
Not sure where you stand?
Half an hour of conversation, with no obligation. By the end you know what needs doing and in what order.