Troubleshooting: Unable to Update AD Attributes for Privileged Accounts (AdminSDHolder)

Version Affected: All
 
 

Overview

Members of Active Directory (AD) built-in Protected Groups (such as Domain Admins) fail operations that require a service account to write to their AD attributes. For example, enrolling a privileged account for time-based passcodes or Push Notifications fails with an LDAP "Access is denied" exception, or a non-administrator service account gets a permissions error updating other attributes for the same accounts.

Cause

Active Directory protects members of certain built-in groups using a mechanism called AdminSDHolder. By default, AdminSDHolder disables permission inheritance for these protected accounts, and periodically re-applies a fixed set of permissions to them — overwriting any permission granted directly to the account itself, including a permission a SecureAuth service account needs to write to one of its attributes.

You can confirm whether a specific user is protected this way by checking their AD AdminCount attribute — a value of 1 means the user is a member of a protected group. For more background, see Microsoft's Protected Accounts and Groups in Active Directory.

Resolution

Because AdminSDHolder overwrites permissions granted directly to a protected account, the durable fix is to grant the needed permission on the AdminSDHolder object itself, so it propagates to every protected account. The Active Directory Users and Computers GUI does not handle this kind of granular permission correctly — even applying a permission to "This object and descendant objects" does not grant the correct access. Instead, use dsacls from an elevated command prompt:

dsacls "CN=AdminSDHolder,CN=System,DC=domain,DC=com" /G "domain\service-account:RPWP;attribute;"

For example, to grant a service account named service-account Read and Write permission on the audio attribute (used to store the OATH Seed for privileged accounts enrolling for time-based passcodes):

dsacls "cn=AdminSDHolder,cn=System,dc=domain,dc=com" /G "domain\service-account:RPWP;audio;"

Special Considerations

Active Directory only re-applies AdminSDHolder's permissions periodically (up to about an hour). If you can't wait for that cycle, you can re-apply the permission directly on the affected privileged account to get it working immediately — this only lasts until the next AdminSDHolder replication cycle overwrites it again. Re-enabling permission inheritance directly on an affected account works the same way, as a temporary measure only.


 

SecureAuth Knowledge Base Articles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.

Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.