Using AD for Admin users

Using AD for Admin users

By default, a Curity Identity Server installation comes with one Admin account. Naturally, you can add additional administrators directly to the system, and it is also possible to leverage an external source for the Admin UI users.

The Curity Identity Server needs a Data Source that uses the LDAP type and connects to AD. A Credentials Manager using that Data Source is then mapped and used in the Admin Service configuration.

Data Source

Create the Data Source in Facilities -> Data Sources -> New, and choose LDAP as the type. Add the needed details to connect to AD. Make sure the Ldap Server Type is set to active-directory.

Client ID format

The Client ID should be in the format of:


Credential Manager

When you create the AD Data Source, you can configure a Credential Manager to use that Data Source. Go to Facilities -> Credential Managers -> New. Set Algorithm Type to plaintext and select the Data Source you just created.

Admin User

By default, there is only one Admin account in the system, stored as admin in the Curity database. However, if you alter the configuration so that a Credential Manager performs that account verification for the Admin UI, it is impossible to log in using the default admin account. Therefore, you should designate at least one AD as an admin user before switching the configuration over to using AD.

Go to System -> Groups -> Find the admin group, and click Edit. Now click +External Administrator Account and add a user from AD to assume the permissions of the group admin. Commit the changes.

Admin Service

Now that we have configured an AD user that can log in with full admin permissions, we can switch the Admin Service to use the Credential Manager for account verification.

Go to System -> Admin Service -> Credential Manager -> Choose the previously created Credential Manager from the drop-down list. Then make sure to Commit the changes.

After logging out, it should now be possible to log in using the AD user that we made part of the admin group.

Remove default admin user

At this point, you could also remove the default admin user. However, do so only after verifying that logging in with an AD user works.

Reverting the Changes

If the connection to AD isn't working for some reason, and it's impossible to log in to the Admin UI, you can revert the changes. Here are the steps required to revert to the internal Credential Manager using the Curity shell:

  1. Start the shell: <IDSVR_HOME>/idsvr/bin/idsh -u <someAdminUser>
  2. Enter the configure mode: configure
  3. Delete the configured Credential Manager for the Admin service: delete environments environment admin-service credential-manager
  4. Commit the changes: commit

These steps will remove the configured Credential Manager using AD and revert back to the internal Credential Manager. Provided you did not delete the admin user, it should now be possible to log in with the default admin account.


By default, The Curity Identity Server will look for any groups returned as part of the account verification using the Credentials Manager. You can leverage the groups to set permissions throughout the Admin UI itself. We will highlight high-level perspectives below and cover specific details in a separate article.

Each part of the Admin UI has configurable Permissions settings. For example, below is the perspective of a specific client (client-two).

You can configure permissions to control Create, Read, Update, and Delete privileges. You can also control whether the permissions apply to UI, CLI, or the RESTCONF interface. Lastly, you can set whether or not child components inherit these permissions.

In the example below, group50 is resolved from AD and used for the configuration. This would correspond to something similar to a DN of CN=group50,OU=test_groups,DC=curityio,DC=net in AD.


By default, the Curity Identity Server manages its own users for Admin UI access. However, it is possible to leverage an external source for account verification for this purpose. You must first configure a Credential Manager to use AD as the Data Source. Then, that Credential Manager can be used to verify accounts that log into the Admin UI. Though this article outlines steps for using AD, you could also achieve this using any other supported Data Source.