Using AD for Admin UI Users
On this page
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.
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
Client ID format
The Client ID should be in the format of:
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.
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.
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:
- Start the shell:
<IDSVR_HOME>/idsvr/bin/idsh -u <someAdminUser>
- Enter the configure mode:
- Delete the configured Credential Manager for the Admin service:
delete environments environment admin-service credential-manager
- Commit the changes:
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 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
Delete privileges. You can also control whether the permissions apply to
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.
Join our Newsletter
Get the latest on identity management, API Security and authentication straight to your inbox.
Start Free Trial
Try the Curity Identity Server for Free. Get up and running in 10 minutes.Start Free Trial