Configuring the runtime to authenticate basic users

Basic users are users in the registry that are not imported in to Security Access Manager. Edit the ldap.conf file so that basic users can authenticate in Security Access Manager.

Before you begin

The following limitations apply to basic users:
  • Basic users work in minimal registry mode only.
  • Basic users cannot use global sign-on.
  • You cannot set access control lists for individual basic users. However, basic users can be members of a Security Access Manager group with access control lists.
  • Registry direct Java API does not support basic users.
  • Account and password valid settings are set to yes. You cannot modify them for basic users.
Warning: Basic users are not subject to any Security Access Manager account and password policies. They always have their account-valid and password-valid values set to yes. Basic users do not record the last login or last password change even if [ldap] enable-last-login is set. You must use the underlying registry equivalents for these capabilities.

About this task

Configure the run time so that basic users can authenticate to Security Access Manager. Basic users have limitations.

When basic-user-support is enabled, basic and full users are located by using the basic-user-principal-attribute suffix in the LDAP native user entry. If the located native user entry has full Security Access Manager user metadata then it is treated as a full user. The value of the basic-user-principal-attribute is used for the user ID even if the Security Access Manager full user metadata has a different principalName.

Basic users are managed in the corporate user registry by using LDAP management tools. These users are not managed through Security Access Manager, except when you change and reset passwords for basic users.

When searching for basic or full users, Security Access Manager:
  • Uses the configured basic-user-principal-attribute and the user-search-filter values to locate users in the registry.
  • Searches all suffixes that are defined by basic-user-search-suffix entries and in the order that they are defined, unless basic-user-suffix-optimizer is enabled. If no basic-user-search-suffix entries are specified, all suffixes are searched in an unspecified order.
  • If basic-user-suffix-optimizer is enabled, a hit count is kept for each suffix that is used to search for users. The suffix search order is based on a dynamic most-used suffix order. This dynamic search order is not used if basic-user-no-duplicates is enabled since in that situation, all suffixes must be searched to ensure that there are no duplicates, thus the order is irrelevant.

Procedure

  1. Log in the local management interface.
  2. From the top menu, select Secure Web Settings > Manage > Runtime Component.
  3. Click Manage > Configuration Files.
  4. Select ldap.conf.
  5. Add the following lines under the [ldap] stanza.
    basic-user-support = yes
    Set this option to yes to support basic users.
    basic-user-principal-attribute = <uid>
    This attribute is the principalName of the basic and full users.
    basic-user-search-suffix = <DN>
    Set this option for each suffix to search for full and basic users. This must include suffixes to search on the primary LDAP server and all federated registries.
    If basic-user-support is enabled and one or more basic-user-search-suffix values are configured, the ignore-suffix entries are disregarded. The basic-user-search-suffix configuration entries determine the suffixes that are searched.
    Note: When there are no basic-user-search-suffix entries, the system searches all available suffixes, except for those specified by the ignore-suffix entries. If you do not specify any basic-user-search-suffix values, you can use ignore-suffix entries to specify one or more suffixes to exclude from the search.
    If basic-user-search-suffix is not set, then all suffixes are chosen in an unspecified order.
    If you choose to specify one or more basic-user-search-suffix entries, ensure that you include an entry for every suffix that must be searched. Ensure that you include the primary suffix for Security Access Manager accounts. For example, secAuthority=Default. If you specify one or more basic-user-search-suffix entries, but you do not include this suffix, the search does not return the full Security Access Manager accounts. In this case, you are not able to authenticate to pdadmin with the sec_master account or any other Security Access Manager accounts.
    basic-user-no-duplicates = {yes | no}
    If set to yes, the search for basic users covers all suffixes to ensure that no users with the same name are found. If set to no, the search for basic users stops immediately and ignores possible duplicates.
    Avoid configuring your environment to include suffixes that contain duplicates. Ensure that the basic-user-principal-attribute is unique for all accounts across the specified suffixes. If there are no duplicates in the environment, you can set basic-user-no-duplicates to no to improve search efficiency. However, if duplicates exist in your environment, set basic-user-no-duplicates to yes so that the system can return an error if it encounters more than one account with the same principal attribute value.
    basic-user-suffix-optimizer = {yes | no}
    If set to yes and basic-user-no-duplicates is set to no, the search order of suffixes is sorted, with the most hit of the basic user suffix at the head of the search suffix list. If set to no, the search order is provided by the basic-user-search-suffix order.
    Note: If basic-user-no-duplicates is set to yes, the basic-user-suffix-optimizer entry is disregarded. In this case, all suffixes are searched to check for duplicates.
  6. Add the following line under the [server:<fedreg>] stanza. 
    basic-user-principal-attribute = <uid>
  7. Click Save.
    Note: For the changes to take effect, they must be deployed as described in Configuration changes commit process.