diff --git a/en/docs/administer/managing-users-and-roles/managing-user-stores/configure-primary-user-store/configuring-a-read-only-ldap-user-store.md b/en/docs/administer/managing-users-and-roles/managing-user-stores/configure-primary-user-store/configuring-a-read-only-ldap-user-store.md index a2b74dc878..18f760f509 100644 --- a/en/docs/administer/managing-users-and-roles/managing-user-stores/configure-primary-user-store/configuring-a-read-only-ldap-user-store.md +++ b/en/docs/administer/managing-users-and-roles/managing-user-stores/configure-primary-user-store/configuring-a-read-only-ldap-user-store.md @@ -1,25 +1,15 @@ # Configuring a Read-Only LDAP User Store -User management functionality is provided by default in all WSO2 Carbon-based products and is configured in the `deployment.toml` file found in the `/repository/conf/` directory and the changes will be automatically applied to `user-mgt.xml` file in `/repository/conf/` directory as well. This file is shipped with user store manager configurations for all possible user store types (JDBC, read-only LDAP/Active Directory, read-write LDAP and read-write Active directory). The instructions given below explains how to configure a read-only LDAP as the primary user store for the WSO2 server. - -!!! info - 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 the Identity Server. - - - 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 a read-only LDAP/AD as the primary user store: -- [Step 1: Setting up the read-only LDAP/AD user store manager](#ConfiguringaRead-OnlyLDAPUserStore-Step1:Settinguptheread-onlyLDAP/ADuserstoremanager) -- [Step 2: Updating the system administrator](#ConfiguringaRead-OnlyLDAPUserStore-UpdatingthesystemadministratorStep2:Updatingthesystemadministrator) -- [Step 3: Starting the server](#ConfiguringaRead-OnlyLDAPUserStore-Step3:Startingtheserver) +- [Step 1: Setting up the read-only LDAP/AD user store manager](#step-1-setting-up-the-read-only-ldapad-user-store-manager) +- [Step 2: Updating the system administrator](#step-2-updating-the-system-administrator) +- [Step 3: Starting the server](#step-3-starting-the-server) ### Step 1: Setting up the read-only LDAP/AD user store manager !!! info - API Manager is compatible with multiple user store. In WSO2 Identity Server, the embedded user store is LDAP. Instead of using the embedded user store, you can set your own user store as the primary user store. + API Manager is compatible with multiple user stores. Instead of using the embedded user store, you can set your own user store as the primary user store. Before you begin - Navigate to `/repository/conf` directory to open `deployment.toml` file and do user_store_properties configurations according to the LDAP user store provider. Following is the sample read-only user store configurations: diff --git a/en/docs/administer/managing-users-and-roles/managing-user-stores/configure-primary-user-store/configuring-a-read-write-active-directory-user-store.md b/en/docs/administer/managing-users-and-roles/managing-user-stores/configure-primary-user-store/configuring-a-read-write-active-directory-user-store.md index aa5f747cde..c4ee91e49e 100644 --- a/en/docs/administer/managing-users-and-roles/managing-user-stores/configure-primary-user-store/configuring-a-read-write-active-directory-user-store.md +++ b/en/docs/administer/managing-users-and-roles/managing-user-stores/configure-primary-user-store/configuring-a-read-write-active-directory-user-store.md @@ -1,12 +1,5 @@ #Configuring a Read-Write Active Directory User Store -!!! info - 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. - - 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](#step-1-setting-up-the-external-ad-user-store-manager) diff --git a/en/docs/administer/managing-users-and-roles/managing-user-stores/configure-primary-user-store/configuring-a-read-write-ldap-user-store.md b/en/docs/administer/managing-users-and-roles/managing-user-stores/configure-primary-user-store/configuring-a-read-write-ldap-user-store.md index 8ae7f551a7..5b0a2dcc44 100644 --- a/en/docs/administer/managing-users-and-roles/managing-user-stores/configure-primary-user-store/configuring-a-read-write-ldap-user-store.md +++ b/en/docs/administer/managing-users-and-roles/managing-user-stores/configure-primary-user-store/configuring-a-read-write-ldap-user-store.md @@ -1,126 +1,424 @@ # Configuring a Read-Write LDAP User Store -User management functionality is provided by default in all WSO2 Carbon-based products and is configured in the `deployment.toml` file found in the `/repository/conf/` directory and the changes will be automatically applied to `user-mgt.xml` file in `/repository/conf/` directory as well. This file is shipped with user store manager configurations for all possible user store types (JDBC, read-only LDAP/Active Directory, read-write LDAP and read-write Active directory). The instructions given below explains how to configure a read-write LDAP as the primary user store for the WSO2 server. - -!!! info - The default User Store - - The primary user store that is configured by default in the user-mgt.xml file of WSO2 products is a JDBC user store, which reads/writes into the internal database of the product server. By default, the internal database is H2. 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 a read-write LDAP as the primary user store: - -- [Step 1: Setting up the read-write LDAP user store manager](#ConfiguringaRead-WriteLDAPUserStore-Step1:Settinguptheread-writeLDAPuserstoremanager) -- [Step 2: Updating the system administrator](#ConfiguringaRead-WriteLDAPUserStore-Step2:Updatingthesystemadministrator) -- [Step 3: Starting the server](#ConfiguringaRead-WriteLDAPUserStore-Step3:Startingtheserver) - -### Step 1: Setting up the read-write LDAP user store manager - +It is assumed that you have already setup your read-write LDAP user store. Follow the given steps to configure it as the primary user store in WSO2 API Manager: + +- [Step 1: Configure the read-write LDAP user store manager](#step-1-configure-the-read-write-ldap-user-store-manager) +- [Step 2: Updating the system administrator](#step-2-updating-the-system-administrator) +- [Step 3: Starting the server](#step-3-starting-the-server) + +### Step 1: Configure the read-write LDAP user store manager + +The following are the minimum configurations that are needed to be provided to configure the read-write LDAP userstore manager. + + + + + + + + + + + + + + + + + + + +
Configuration NameDisplay NameDescription
typeuserstore TypeThis is the type of the userstore manager being used. For read-write LDAP userstore manager, this value +should be `read_write_ldap_unique_id`. +
base_dnUser Search BaseThis denotes the DN of the context or object under which the user entries are stored in the userstore. When the userstore searches for users, it will start from this location of the directory.
+Sample values: ou=Users,dc=wso2,dc=org
+ +Following are the minimum userstore properties that are needed to be provided to configure Read-Write LDAP userstore manager : + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Property IdPrimary Userstore PropertySecondary Userstore PropertyDescription
ConnectionURLconnection_urlConnection URL

Connection URL to the user store server.

+

Sample values:
+ldap://10.100.1.100:389
+ldaps://10.100.1.102:639
+
+If you are connecting over ldaps (secured LDAP)
+Need to import the certificate of userstore to the client-truststore.jks of 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.
+Using asymmetric encryption
+
+If LDAP connection pooling is used, see enable connection pooling for LDAPS connections.
+performance tuning ldaps pooling)

ConnectionNameconnection_nameConnection Name

The username used to connect to the userstore and perform various operations. This user does not need to be an administrator in the userstore or have an administrator role in the WSO2 product that you are using, but this user MUST have permissions to read the user list and users' attributes and to perform search operations on the userstore. The value you specify is used as the DN (Distinguish Name) attribute of the user who has sufficient permissions to perform operations on users and roles in LDAP

+

This property is mandatory.
+Sample values: uid=admin,ou=system

ConnectionPasswordconnection_passwordConnection PasswordPassword for the ConnectionName user.
+ + +Replace the default `user_store` configuration in the `/repository/conf/deployment.toml` file as per your LDAP server configuration. A sample configuration is given below. + +``` toml +[user_store] +type = "read_write_ldap_unique_id" +base_dn = "ou=system" +connection_url = "ldap://localhost:10389" +connection_name = "uid=admin,ou=system" +connection_password = "admin" +``` +Apart from above properties, WSO2 API Manager also supports advanced LDAP configurations. -Before you begin +--- -- Navigate to `/repository/conf` directory to open `deployment.toml` file and do user_store_properties configurations as follows: - ```toml - [user_store.properties] - TenantManager= "org.wso2.carbon.user.core.tenant.CommonHybridLDAPTenantManager" - ConnectionURL="ldap://localhost:10390" - ConnectionName="uid=admin,ou=system" - UserSearchBase="ou=Users,dc=wso2,dc=org" - GroupSearchBase="ou=Groups,dc=wso2,dc=org" - ConnectionPassword="admin" - AnonymousBind= "false" - WriteGroups= "true" - UserEntryObjectClass= "identityPerson" - UserNameAttribute= "uid" - UserNameSearchFilter= "(\u0026amp;(objectClass\u003dperson)(uid\u003d?))" - UserNameListFilter= "(objectClass\u003dperson)" - DisplayNameAttribute= "" - GroupEntryObjectClass= "groupOfNames" - GroupNameAttribute= "cn" - GroupNameSearchFilter= "(\u0026amp;(objectClass\u003dgroupOfNames)(cn\u003d?))" - GroupNameListFilter= "(objectClass\u003dgroupOfNames)" - MembershipAttribute= "member" - BackLinksEnabled= "false" - SCIMEnabled= "true" - IsBulkImportSupported= "true" - UsernameJavaRegEx= "[a-zA-Z0-9._\\-|//]{3,30}$" - RolenameJavaRegEx= "[a-zA-Z0-9._\\-|//]{3,30}$" - PasswordHashMethod= "PLAIN_TEXT" - ConnectionPoolingEnabled= "false" - LDAPConnectionTimeout= "5000" - ReplaceEscapeCharactersAtUserLogin= "true" - EmptyRolesAllowed= "true" - kdcEnabled= "false" - defaultRealmName= "WSO2.ORG" - StartTLSEnabled= "false" - UserRolesCacheEnabled= "true" - ConnectionRetryDelay= "2m" - ``` -- The `class` attribute for a read-write LDAP is `` - ```toml - [user_store] - class="org.wso2.carbon.user.core.ldap.ReadWriteLDAPUserStoreManager" - type = "database" - ``` +### Properties used in Read-write LDAP userstore manager +Any of the following properties can be configured for the `PRIMARY` userstore by adding them as follows to +`/repository/conf/deployment.toml`. -Once the above points are made note of and completed, you can start configuring your external read-write LDAP as the primary user store. +``` toml +[user_store] + = +``` +For example : -!!! note - Note that these configurations will automatically applied to the `user-mgt.xml` file so you do not need to edit it. - - -The configuration for the external read/write user store in the `user-mgt.xml` file looks as follows. For more information about each of the properties used in the `deployment.toml` file for configuring the primary user store , see [Properties of User Stores](https://is.docs.wso2.com/en/5.10.0/setup/configuring-a-read-write-ldap-user-store/#properties-used-in-read-write-ldap-user-store-manager) . - -``` xml - - true - 100 - , - admin - false - true - org.wso2.carbon.user.core.tenant.CommonHybridLDAPTenantManager - ou=system - (&(objectClass=groupOfNames)(cn=?)) - true - true - (&(objectClass=person)(uid=?)) - 5000 - uid - cn - [a-zA-Z0-9._\-|//]{3,30}$ - true - false - uid=admin,ou=system - ldap://localhost:10390 - ^[\S]{3,30}$ - [a-zA-Z0-9._\-|//]{3,30}$ - ^[\S]{5,30}$ - PLAIN_TEXT - ou=system - true - true - 120000 - member - Password length should be within 5 to 30 characters - 100 - ^[\S]{5,30}$ - false - Username pattern policy violated - true - (objectClass=groupOfNames) - false - SHA-256 - (&(objectClass=person)(!(sn=Service))) - [a-zA-Z0-9._\\-|//]{3,30}$ - false - +``` toml +[user_store] +read_groups = true ``` -1. To read and write to an LDAP userstore, it is important to ensure that the `ReadGroups` and `WriteGroups` properties in the `/repository/conf/deployment.toml` file are set to `true`. +!!! note + In the table given below, the `Primary userstore Property` column has the `PRIMARY` userstore properties that can be configured in the `deployment.toml` file. The `Secondary userstore Property` column has the properties that can be configured for a secondary userstore through the Management Console. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Property IdPrimary Userstore PropertySecondary Userstore PropertyDescription
UserEntryObjectClassuser_entry_object_classUser Entry Object ClassObject class used to construct user entries.
+Default: identityPerson( Is a custom object class defined in WSO2 Identity Server)
UserNameAttributeuser_name_attributeUsername Attribute

A uniquely identifying attribute that represents the username of the user. Users can be authenticated using their email address, UID, etc. The value of the attribute is considered as the username.

+

Default: uid
+
+Note: email address is considered as a special case in WSO2 products, if you want to set the email address as username, see Using email address as the username

UserIDAttributeuser_id_attributeUser ID Attribute

The attribute used for uniquely identifying a user entry. The value of the attribute is considered as the unique user ID.

+

Default: scimId

UserNameSearchFilteruser_name_search_filterUser Search FilterFiltering criteria used to search for a particular user entry.
+Default : (&(objectClass=identityPerson)(uid=?))
UserNameListFilteruser_name_list_filterUser List FilterFiltering criteria for searching user entries in the userstore. This query or filter is used when doing search operations on users with different search attributes.
+
+Default: (objectClass=identityPerson)
+In this case, the search operation only provides the objects created from the person object class.
UserDNPatternuser_dn_patternUser DN Pattern

The pattern for the user's DN, which can be defined to improve the search. When there are many user entries in the LDAP userstore, defining a UserDNPattern provides more impact on performances as the LDAP does not have to travel through the entire tree to find users.

+

Sample values: uid={0},ou=Users,dc=wso2,dc=org

DisplayNameAttributedisplay_name_attributeDisplay name attributeThis is an optional property. The Display Name Attribute is the name by which users will be listed when you list users in the management console. +

Default: blank

ReadGroupsread_groups +Read GroupsWhen WriteGroups is set to falses, this Indicates whether groups should be read from the userstore. If this is disabled by setting it to false, none of the groups in the userstore can be read, and the following group configurations are NOT mandatory: GroupSearchBase, GroupNameListFilter, or GroupNameAttribute.
+

Default: true +
+Possible values:
+true: Read groups from userstore
+false: Don’t read groups from userstore

WriteGroupswrite_groupsWrite GroupsIndicates whether groups should be write to the userstore.
+

Default: true +
+Possible values:
+true: Write groups to userstore
+false: Do not write groups to userstore, so only internal roles can be created. Depend on the value of ReadGroups property, it will read existing groups from userstore or not
+

GroupSearchBasegroup_search_baseGroup Search Base

DN of the context or object under which the group entries are stored in the userstore. When the userstore searches for groups, it will start from this location of the directory

+

Default: ou=Groups,dc=wso2,dc=org

GroupEntryObjectClassgroup_entry_object_classGroup Entry Object ClassObject class used to construct group entries.
+Default: groupOfNames
GroupNameAttributegroup_name_attributeGroup Name AttributeAttribute used for uniquely identifying a group entry. This attribute is to be treated as the group name. +
Default: cn
GroupNameSearchFiltergroup_name_search_filterGroup Search Filter

Filtering criteria used to search for a particular group entry.

+

Default: (&(objectClass=groupOfNames)(cn=?))

GroupNameListFiltergroup_name_list_filterGroup List Filter

Filtering criteria for searching group entries in the userstore. This query or filter is used when doing search operations on groups with different search attributes.

+

Default: ((objectClass=groupOfNames)) In this case, the search operation only provides the objects created from the +groupOfName object class.

RoleDNPatternrole_dn_patternRole DN Pattern

The pattern for the group's DN, which can be defined to improve the search. When there are many group entries in the LDAP userstore, defining a RoleDNPattern provides more impact on performances as the LDAP does not have to traverse through the entire tree to findgroup.

+

Sample values: cn={0},ou=Groups,dc=wso2,dc=org

MembershipAttributemembership_attributeMembership Attribute

Defines the attribute that contains the distinguished names (DN) of user objects that are in a group.

+

Default: member

MemberOfAttributemember_of_attributeMember Of AttributeDefine the attribute that contains the distinguished names (DN ) of group objects that user is assigned to.
+Possible values: memberOf
BackLinksEnabledback_links_enabledEnable Back LinksDefines whether the backlink support is enabled. If you are using MemberOfAttribute attributes this should be set to 'true'. +
Default : false
UsernameJavaRegExusername_java_regexUsername RegEx (Java)The regular expression used by the back-end components for username validation. By default, strings with non-empty characters have a length of 3 to 30 allowed. You can provide ranges of alphabets, numbers and also ranges of ASCII values in the RegEx properties.
+Default: [a-zA-Z0-9._\-|//]{3,30}$
UsernameJava
ScriptRegEx		username_java_
script_regex		Username RegEx (Javascript)The regular expression used by the front-end components for username validation.
+Default: ^[\S]{3,30}$
UsernameJavaReg
ExViolationErrorMsg		username_java_reg_
ex_violation_error_msg		Username RegEx Violation Error MessageError message when the Username is not matched with UsernameJavaRegEx
+Default: Username pattern policy violated
PasswordJavaRegExpassword_java_regexPassword RegEx (Java)The regular expression used by the back-end components for password validation. By default, strings with non-empty characters have a length of 5 to 30 allowed. You can provide ranges of alphabets, numbers and also ranges of ASCII values in the RegEx properties.
+Default: ^[\S]{5,30}$
PasswordJava
ScriptRegEx		password_java_
script_regex		Password RegEx (Javascript)The regular expression used by the front-end components for password validation.
+Default: ^[\S]{5,30}$
PasswordJavaReg
ExViolationErrorMsg		password_java_reg
ex_violation_error_msg		Password RegEx Violation Error MessageError message when the Password is not matched with passwordJavaRegEx
+Default: Password length should be within 5 to 30 characters
RolenameJavaRegExrolename_java_regexRole Name RegEx (Java)The regular expression used by the back-end components for role name validation. By default, strings with non-empty characters have a length of 3 to 30 allowed. You can provide ranges of alphabets, numbers and also ranges of ASCII values in the RegEx properties.
+Default: [a-zA-Z0-9._\-|//]{3,30}$
PasswordHashMethodpassword_hash_methodPassword Hashing Algorithm

Specifies the Password Hashing Algorithm used the hash the password before storing in the userstore.
+Possible values:
+SHA - Uses SHA digest method. SHA-1, SHA-256
+MD5 - Uses MD 5 digest method.
+PLAIN_TEXT - Plain text passwords.(Default)

+

If you just configure as SHA, It is considered as SHA-1, It is always better to configure algorithm with higher bit value as digest bit size would be increased.
+
+Most of the LDAP servers (such as OpenLdap, OpenDJ, AD, ApacheDS and etc..) are supported to store password as salted hashed values (SSHA)
+Therefore WSO2 APIManager just wants to feed password into the connected userstore as a plain text value. Then LDAP userstore can store them as salted hashed value. To feed the plain text into the LDAP server, you need to set PasswordHashMethod to “PLAIN_TEXT”
+But; if your LDAP does not support to store user password as hashed values. You can configure WSO2 server to hash the password and feeds the hashed password into the LDAP server. Then you need to configure PasswordHashMethod property with SHA (SHA-1), SHA-256, SHA-512. Please note WSO2 server cannot create a salted hashed password (SSHA) to feed into the LDAP.

MultiAttributeSeparatormulti_attribute_separatorMultiple Attribute SeparatorThis property is used to define a character to separate multiple attributes. This ensures that it will not appear as part of a claim value. Normally “,” is used to separate multiple attributes, but you can define ",,," or "..." or a similar character sequence
+Default: “,”
MaxUserName
ListLength 		max_user_name
_list_length		Maximum User List LengthControls the number of users listed in the userstore of a WSO2 product. This is useful when you have a large number of users and don't want to list them all. Setting this property to 0 displays all users.
+Default: 100
+
+In some userstores, there are policies to limit the number of records that can be returned from the query. Setting the value 0 it will list the maximum results returned by the userstore. If you need to increase that you need to set it in the userstore level.
+Eg : Active directory has the MaxPageSize property with the default value 1000.
MaxRoleName
ListLength		max_role_name
_list_length		Maximum Role List Length

Controls the number of roles listed in the userstore of a WSO2 product. This is useful when you have a large number of roles and don't want to list them all. Setting this property to 0 displays all roles.
+Default: 100
+
+In some userstores, there are policies to limit the number of records that can be returned from the query, Setting the value 0 it will list the maximum results returned by the userstore. If you need to increase that you need to set it n the userstore level.

+

Eg: Active directory has the MaxPageSize property with the default value 1000.

kdcEnabledkdc_enabledEnable KDCIf your userstore is capable of acting as a Kerberos, Key Distribution Center (KDC) and if you like to enable it, set this property to true.
+Default: false
UserRoles
CacheEnabled		user_roles
_cache_enabled		Enable User Role CacheThis is to indicate whether to cache the role list of a user.
+Default: true
+
+Possible values:
+false: Set it to false if the user roles are changed by external means and those changes should be instantly reflected in the Carbon instance. +
+Default: true
ConnectionPooling
Enabled		connection_pooling
_enabled		Enable LDAP Connection PoolingDefine whether LDAP connection pooling is enabled
+Possible values:
+True: Enable connection pooling. Enabling it will improve the performance
+False: Disable connection pooling +
+Default: false
LDAPConnectionTimeoutldap_connection_timeoutLDAP Connection TimeoutTimeout in making the initial LDAP connection. This is configured in milliseconds.
+Default: 5000
ReadTimeoutread_timeoutLDAP Read TimeoutThe value of this property is the read timeout in milliseconds for LDAP operations. If the LDAP provider cannot get a LDAP response within that period, it aborts the read attempt. The integer should be greater than zero. An integer less than or equal to zero means no read timeout is specified which is equivalent to waiting for the response infinitely until it is received. +
+Default: not configured
MembershipAttributeRangemembership_attribute_rangeMembership Attribute Range

This is to define the maximum users of role returned by the LDAP/AD userstore. This does not depend on the max page size of the userstore.

+

Default: not configured

RetryAttemptsretry_attemptsRetry AttemptsRetry the authentication request if a timeout happened +

Default: not configured

+ +--- +Following are some key points to consider : + +1. To read and write to an LDAP userstore, it is important to ensure that the `ReadGroups` and `WriteGroups` properties in the `/repository/conf/deployment.toml` file are set to `true`. ``` WriteGroups = "true" ReadGroups = "true" @@ -177,7 +475,7 @@ The configuration for the external read/write user store in the `user-mgt.xml` f MembershipAttribute = "member" ``` - To read roles based on a backlink attribute, use thefollowingcodesnipetinsteadofthe above: + To read roles based on a backlink attribute, use the following code snipet instead of the above: ``` ReadGroups = "false" @@ -191,23 +489,28 @@ The configuration for the external read/write user store in the `user-mgt.xml` f ### 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 LDAP 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 LDAP. For information about the system administrator user, see [Configuring the System Administrator]({{base_path}}/reference/config-catalog/#super-admin-configurations) . +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 userstore when you start the system for the first time. Since the LDAP userstore can be written to, you have the option of creating a new admin user in the userstore when you start the system for the first time. Alternatively, you can also use a user ID that already exists in the LDAP. For information about the system administrator user, see [Configuring the System Administrator]({{base_path}}/reference/config-catalog/#super-admin-configurations) . These two alternative configurations can be done as explained below. -- If the user store is read-only, find a valid user that already resides in the user store. For example, say a valid username is 'admin'. Update the `[super_admin]` 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. +- If you are using a user that is already in the LDAP. Find a valid user that already resides in the userstore. For example, say a valid username is AdminSOA.Add the following configuration to the `deployment.toml` file as shown below. You do not have to update the password element as it is already set in the userstore. + ```toml [super_admin] - username = "admin" - password = "admin" + username = "AdminSOA" + admin_role = "admin" create_admin_account = false ``` -- If the user store can be written to, you can add the super tenant user to the user store. Therefore, `create_admin_account` should be set to true as shown below. - ``` - username = "admin" - password = "admin" +- if you are creating a new admin user in the userstore when you start the system. you can add the super tenant + user to the userstore. Add the following configuration to the `deployment.toml` file as shown below. + + ```toml + [super_admin] + username = "AdminSOA" + admin_role = "admin" create_admin_account = true + password = "admin" ``` ### Step 3: Starting the server diff --git a/en/docs/administer/managing-users-and-roles/managing-user-stores/configure-primary-user-store/configuring-the-primary-user-store.md b/en/docs/administer/managing-users-and-roles/managing-user-stores/configure-primary-user-store/configuring-the-primary-user-store.md index 2fb53c8b88..6be0f74056 100644 --- a/en/docs/administer/managing-users-and-roles/managing-user-stores/configure-primary-user-store/configuring-the-primary-user-store.md +++ b/en/docs/administer/managing-users-and-roles/managing-user-stores/configure-primary-user-store/configuring-the-primary-user-store.md @@ -2,10 +2,13 @@ This documentation explains the process of setting up a primary user store for your system. -!!! info - **The default User Store** +User management functionality is provided by default in all WSO2 Carbon-based products and is configured in the `deployment.toml` file found in the `/repository/conf/` directory and the changes will be automatically applied to `user-mgt.xml` file in `/repository/conf/` directory as well. This file is shipped with user store manager configurations for all possible user store types (JDBC, read-only LDAP/Active Directory, read-write LDAP and read-write Active directory). The instructions given below explains how to configure a primary user store for the WSO2 server. - The primary user store that is configured by default, is a JDBC user store, which reads/writes into an internal database. By default, the internal database is H2. This database is used by the Authorization Manager (for user authorization information) as well as, the User Store Manager (for defining users and roles). +!!! info "The Default User Store" + + The primary user store in of WSO2 products is configured by default as a JDBC user store in the user-mgt.xml file, which reads/writes into the internal database of the product server. This internal database is typically H2 by default. This database is used by both the Authorization Manager (for managing user authentication data) and the User Store Manager (for defining users and roles). + + Please note that the RDBMS used in the default configuration can remain as the database used for storing Authorization information. Instead of using the embedded database, you can set up a separate repository and configure it as your primary user store. Since the user store you want to connect to might have different schemas from the ones available in the embedded user store, it needs to go through an adaptation process. We do the necessary adaptations depending on the user store type. We support the following primary user store types.