Troubleshooting Permissions Issues

Note: Applies to Directory hybrid (on-premises AD) deployments only

If you find that some changes are not being committed, the Directory Service Account may not have sufficient privileges for either the specific user, or the organizational unit (OU).

When permissions are the issue, the 'Approve' page in the Hyperfish Web Application will state that some changes have failed to be applied, and debug logging will reveal the following error: 

ERROR [TIMESTAMP] Error updating AD. Message: Error updating AD, The user has insufficient access rights.

To confirm that this is a permissions issue, you can run a PowerShell session as the Hyperfish service account:

runas /user:<hyperfishserviceaccountname> powershell.exe

Then, attempt to apply a failed change to the affected user object(s) using the Set-ADUser (ActiveDirectory module) cmdlet, e.g.:

Import-Module ActiveDirectory

Set-ADUser <username> -City "Seattle"

If the service account doesn't have permissions to write to that object, the error message will state that there are insufficient access rights to perform the operation:

If you aren't able to reproduce the issue with this method, be absolutely sure you are running the cmdlet as the Directory service account. If you are unsure of the service account identity, run the following in PowerShell: 

Get-WmiObject Win32_Service | where-object {$_.name -eq "HyperfishAgent"} | select StartName

Also, be sure to try against multiple user objects to see if permissions change between OUs. 

Once confirmed, here are some things to check:

1 Make sure the Directory Service account has sufficient privileges

If the multiple objects within the same AD container cannot be written to, make sure the Hyperfish service account has been granted delegated rights to the OU. 

2 Make sure the user object is not a member of a Protected Group

MS Active Directory considers Domain Admins, Enterprise Admins, and Schema Admins groups as “Protected Groups” and switches the user object inheritance flag to disable inheritance from the parent object. Therefore, a Directory service account with delegated permissions will not be able to modify these objects.

Even if the user object is manually set to inherit from the parent, the SDProp job runs every hour to scan for objects that are considered “protected” and resets the inheritance flag.

Refer to the SDProp section in this TechNet article for more information: https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/appendix-c--protected-accounts-and-groups-in-active-directory

3 Make sure inheritance is enabled for the object (the user account to be updated)

This is especially applicable if the user object was previously a member of a protected group.