The default User Store
The primary user store that is configured by default in the
user-mgt.xml file is a JDBC user store, which reads/writes into the internal database of the product server. By default, the internal database is H2 for all WSO2 products excluding WSO2 Identity Server. This database is used by the Authorization Manager (for user authentication information) as well as the User Store Manager (for defining users and roles). In the case of the WSO2 Identity Server, the default user store is an LDAP (Apache DS) that is shipped with the product.
Note that the RDBMS used in the default configuration can remain as the database used for storing Authorization information.
Follow the given steps to configure an external Active Directory as the primary user store:
Step 1: Setting up the external AD user store manager
Before you begin
- If you create the
user-mgt.xmlfile yourself, be sure to save it in the
classattribute for an external AD is
ActiveDirectoryUserStoreManagerclass in the
<PRODUCT_HOME>/repository/conf/user-mgt.xmlfile by uncommenting the code. When it is enabled, the user manager reads/writes into the Active Directory user store.
Note that these configurations already exist in the
user-mgt.xmlfile so you only need to uncomment them and make the appropriate adjustments. Also ensure that you comment out the configurations for other user stores which you are not using.
The default configuration for the external read/write user store in the
user-mgt.xmlfile is as given below. Change the values according to your requirement. For more information on each of the properties used in the user-mgt.xml file for configuring the primary user store, see Properties of User Stores.
When working with Active Directory;
It is best to enable the
GetAllRolesOfUserEnabledproperty in the
AuthorizationManageras follows. See the documentation on configuring the Authorization Manager for more information.
Although using the user store manager does not depend on this property, you must consider enabling this if there are any performance issues in your production environment. Enabling this property affects the performance when the user logs in. This depends on the users, roles and permission stats.
If you are using
ldaps(secured LDAP) to connect to the Active Directory as shown in the example below, you need to import the certificate of Active Directory to the
client-truststore.jksof the WSO2 product. For information on how to add certificates to the truststore and how keystores are configured and used in a system, see Using Asymmetric Encryption.
You also need to enable connection pooling for LDAPS connections at the time of starting your server, which will enhance server performance.
For Active Directory, you can use
<Property name="Referral">follow</Property>to enable referrals within the user store. The AD user store may be partitioned into multiple domains. However, according to the use store configurations in the
user-mgt.xmlfile, we are only connecting to one of the domains. Therefore, when a request for an object is received to the user store, the
<Property name="Referral">follow</Property>property ensures that all the domains in the directory will be searched to locate the requested object.
Set the attribute to use as the username, typically either
uidfor LDAP. Ideally,
<Property name="UserNameSearchFilter">should refer to the same attribute. If you are not sure what attribute is available in your user store, check with your LDAP/Active Directory administrator.
In WSO2 products based on Carbon 4.4.x, you can set the
LDAPConnectionTimeoutproperty: If the connection to the LDAP is inactive for the length of time (in milliseconds) specified by this property, the connection will be terminated.
ReadGroupsproperty to 'true', if it should be allowed to read roles from this user store. When this property is 'true', you must also specify values for the
GroupNameAttributeproperties. If the
ReadGroupsproperty is set to 'false', only Users can be read from the user store. You can set the configuration to read roles from the user store by reading the user/role mapping based on a membership (user list) or backlink attribute as shown below.
To read the user/role mapping based on a membership (This is used by the
GroupSearchBaseproperty to the directory name where the Roles are stored. That is, the roles you create using the management console of your product will be stored in this directory location. Also, when LDAP searches for users, it will start from this location of the directory. For example:
Set the GroupSearchFilter and GroupNameAttributes. For example:
MembershipAttributeproperty as shown below:
To read roles based on a backlink attribute, use the following code snipet instead of the above:
Step 2: Updating the system administrator
The admin user is the super tenant that will be able to manage all other users, roles and permissions in the system by using the management console of the product. Therefore, the user that should have admin permissions is required to be stored in the user store when you start the system for the first time. Since the Active Directory user store can be written to, you have the option of creating a new admin user in the user store when you start the system for the first time. Alternatively, you can also use a user ID that already exists in the user store. For more information on setting up the system administrator and the authorization manager, see Configuring the User Realm.
- These two alternative configurations can be done as explained below.
Find a valid user that already resides in the user store. For example, say a valid username is AdminSOA. Update the
<AdminUser>section of your configuration as shown below. You do not have to update the password element as it is already set in the user store.
Since the user store can be written to, you can add the super tenant user to the user store. Therefore,
<AddAdmin>should be set to
trueas shown below.
Step 3: Starting the server
Start your server and try to log in as the admin user you specified.