Tips for finding Knowledge Articles

  • - Enter just a few key words related to your question or problem
  • - Add Key words to refine your search as necessary
  • - Do not use punctuation
  • - Search is not case sensitive
  • - Avoid non-descriptive filler words like "how", "the", "what", etc.
  • - If you do not find what you are looking for the first time,reduce the number of key words you enter and try searching again.
  • - Minimum supported Internet Explorer version is IE9
Home  >

KB-6227: How to delegate permissions to unlock Active Directory accounts

App Access Service ,   Privileged Access Service ,  

12 April,16 at 10:58 AM

Applies to: Centrify Identity Service / Centrify Privilege Service


After configuring cloud manager policy settings to allow end user self-service password unlock
for Active Directory users, the connector service does not appear to actually unlock the account.
When an Active Directory user attempts to log on to the Centrify portal with a locked account, they
are prompted to enter username, password and any MFA requirements as configured per Authentication
Profiles. After the user completes the login requirements, the user is not logged into the portal
and is returned to the username login page with the following error:
  • Failed to login. Please try again or contact your system administrator

When viewing cloud connector logs located at C:\Program Files\Centrify\Cloud Management Suite\Log.txt,
the following error may be displayed:
  • UnlockAccount failed - Check account permissions (account may be specified via a profile or proxy may be running as a specific account
This issue is specific to Active Directory user accounts. Centrify User Service accounts
(cloud users) do not receive a similar error when performing self-service account unlock.


The above conditions may be encountered if the user or service account that runs as the cloud
connector service does not have delegated permissions to unlock Active Directory user accounts.


Administrators can perform the following manual steps to delegate Active Directory permissions
to unlock accounts for the user or service account used to run the cloud connector service.

To delegate the right to a group or user:
  1. Create the group or user account that you want to have the right to unlock user accounts in Active Directory Users and Computers (for example, Help Desk Admins).
  2. Right-click the domain in Active Directory Users and Computers (ADUC), and then click Delegate Control from the menu that is displayed.
  3. The Delegation of Control Wizard should be displayed. On the Welcome dialog box, click Next.
  4. On the Users and Groups dialog box, click Add. Select the group in the list that you want to give the right to unlock accounts, and then click OK. On the Users and Groups dialog box, click Next.
  5. On the Tasks to Delegate dialog box, click Create a custom task to delegate, and then click Next.
  6. On the Active Directory Object Type dialog box, click Only the following objects in the folder:. In the list, click User objects (the last entry in the list), and then click Next.
  7. On the Permissions dialog box, click to clear the General check box, and then click to select the Property-specific check box. In the Permissions list, click to select the Read lockoutTime check box, click to select the Write lockoutTime check box, and then click Next.
  8. On the Completing the Delegation of Control Wizard dialog box, click Finish.

The steps in this article can delegate the Account Read lockoutTime and Write lockoutTime right
to a group or user for a specific domain or organizational unit (OU). Because account policies are
domain specific, the account lockout policy itself can only be implemented to an entire domain.
Any user or group that has been given permission to read and write the LockoutTime attribute for
an OU or other container can unlock user accounts that reside in that container. The user or group
that has been given this permission does not have to reside in the container over which they have

This delegation does not affect rights or policies in other domains, even domains in the same
forest, or if this domain is the root of a forest.

Note: The above information is provided per Microsoft KB294952 as a courtesy for Centrify customers.


This will be addressed in a future release of Centrify Identity Service / Centrify Privilege Service

Still have questions? Click here to log a technical support case, or collaborate with your peers in Centrify's Online Community.