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.
Create the Data Source in
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
Client ID formatThe Client ID should be in the format of:
When you create the AD Data Source, you can configure a Credential Manager to use that Data Source. Go to
Credential Managers ->
Algorithm Type to
plaintext and select the
Data Source you just created.
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.
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
Commit the changes.
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.
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.
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 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
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.