Using AD for Admin UI 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 → +, give it a name and then choose ldap as the type. Add the needed details to connect to AD. Make sure the Ldap Server Type is set to active-directory.

Credential Manager

When the AD Data Source is created, its possible to configure a Credential Manager to use that Data Source. Go to Facilities → Credential Managers →, click +. Set Algorithm Type to plaintext and select the previsouly created Data Source.

Admin Service

With the Credential Manager created, the account verification for the Admin Service can be changed to use the Credential Manager.

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 be possible to log in using an AD user.

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.

Permissions

By default, The Curity Identity Server will look for any groups returned as part of the account verification using the Credential 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.

Summary

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.