General Access denied due to permission settings

Non-Domain Admin users receive an "access denied" error when SecureAuth attempts to update attribute fields (e.g Self-Service, KBA/KBQ, etc.)

Verify the SecureAuth service account has "Read/Write" permissions to those user object attributes SecureAuth is trying to update. Apply permissions / Correct inheritance as needed.

1. Adding the Service account to the Domain Admins group temporarily or replacing the Service Account credentials on the data tab of the affected realm with a Domain Admin account is a good troubleshooting step to see if the issue is caused by an AD attribute permissions issue.

2. On the "Data" tab of the affected realm, "un-check" the read/write options for each attribute to figure out which is causing the "access denied" error during the update. This can be tricky if the error only occurs when an attribute is updated. If you un-check a specific attribute on the realm's data tab do not try to update that field during your testing.

If either of the options above resolve the error, review the security permissions for the AD account which is experiencing the "access denied" error to ensure the service account has Write permissions applied for the specific object attribute(s). This will indicate if the appropriate permissions exist, indicate a possible configuration change, blocked inheritance or special groups issue.