What an Appliance's LDAP Service Account Can Read in Active Directory

Why appliances hold directory credentials

Almost every network appliance that authenticates users talks to Active Directory over LDAP. A VPN gateway needs to check that a username exists, confirm group membership for access policies, and sometimes resolve attributes such as an email address or a department. To do that, it binds to the directory with a service account, and the appliance stores that account's password so it can bind again after every reboot.

That stored credential is the part most teams forget. The appliance is managed by the network team, the service account was created by the directory team years ago, and nobody revisits what it can see. When the appliance is compromised, the attacker inherits the account. The Ivanti Connect Secure zero-day CVE-2026-104935 is the latest example. Volexity reported that the attackers pulled the LDAP credential off the appliance and used it to query the directory directly.

Authenticated users can read more than you think

Active Directory is built to be readable. By default, any authenticated account can enumerate users, groups, computers, group membership, service principal names and most descriptive attributes. That is how domain-joined machines and applications work. It also means a low-privilege service account is a complete map of the environment: every admin group, every server, every account with a service principal name that could be Kerberoasted.

So even a perfectly scoped bind account hands an attacker reconnaissance. The question is what it can read beyond that baseline.

The attributes that matter

Some attributes are meant to be readable only by specific principals. In the Ivanti campaign, Volexity says the attackers searched for four kinds of data:

• LAPS passwords. LAPS stores a unique local administrator password for each computer in an attribute on that computer's object. Read access is controlled by delegated permissions. If the appliance account can read them, the attacker gets local admin on every machine in scope.
• BitLocker recovery information. When BitLocker recovery keys are backed up to AD, they live in child objects under each computer. Anyone who can read them can unlock a stolen or seized disk.
• userPassword and unixUserPassword. These attributes sometimes hold passwords left behind by Unix integration or old provisioning tools. Many directories have them populated without anyone remembering why.
• Logon script paths and account metadata. These show where scripts run from, which shares are writable, and which accounts are stale. All of it is useful for planning the next move.

The first two are the serious ones. They are supposed to be restricted, and they usually are, until a delegation is made too broad. A common pattern is that someone grants LAPS read rights to a helpdesk group, a service account gets added to that group to fix an unrelated problem, and the appliance can now read every local admin password in the domain.

How delegations drift

Permissions on confidential attributes are normally granted at the organizational unit level and inherited downward. That makes them easy to grant and hard to audit. Typical ways a bind account ends up over-privileged:

• It was made a member of a broad group, sometimes even a privileged one, during a troubleshooting session that was never rolled back.
• It shares an identity with another integration that genuinely needed more access.
• A LAPS or BitLocker delegation was applied to an OU high in the tree, and the account's group happens to be in the allowed list.
• The appliance vendor's setup guide suggested a domain admin account to get things working, and that stuck.

None of these show up in the appliance's configuration screen. You only see them from the directory side.

What the account should be able to do

An authentication proxy needs to validate users and read group membership. That is close to the default authenticated-user baseline. It does not need to read LAPS passwords, BitLocker recovery data or any password-bearing attribute. A good target is:

• One dedicated account per appliance or appliance cluster, never shared with other integrations.
• Membership in no groups other than the default domain users group, unless a specific, documented need exists.
• Explicit confirmation that it is not in any group delegated to read confidential attributes.
• A long random password, rotated on a schedule and immediately after any appliance compromise.
• Monitoring for that account doing anything other than its usual pattern of binds and group lookups.

The last point is the one that would have caught the Ivanti activity. A VPN bind account suddenly running broad searches for recovery information looks nothing like a VPN bind account at work.

Putting it into practice

Start with an inventory of every account used by appliances: VPNs, firewalls, mail gateways, wireless controllers, printers and scanners. For each, check effective permissions on the OUs holding computers and privileged users. Then decide what happens if that account leaks.

If you are reading this because an appliance has already fallen, the containment steps are covered in How to Contain Active Directory Exposure After a VPN Appliance Is Compromised. If you are wondering whether the appliance is still compromised after patching, read Why a Clean Integrity Check Cannot Clear a Compromised Appliance.