User registry considerations

Supported LDAP user registries

• Security Directory Server
• IBM z/OS Security Server LDAP Server
• Novell eDirectory Server
• Sun Java System Directory Server
• Microsoft Active Directory Lightweight Directory Services (ADLDS)

Name limitations for supported registries

• Avoid forward slashes (/) in names for users and groups when defining that name with distinguished names strings. Each user registry treats this character differently.

• Avoid leading and trailing blanks in user and group names. Each user registry treats blanks differently.

LDAP configuration information

• Security Verify Access requires no configuration steps to support LDAP's password policy. It does not assume the existence or non-existence of LDAP's password policy. ISAM enforces its own password policy first. ISAM attempts to update password in LDAP only when the provided password passes ISAM's own password policy check. ISAM tries to accommodate LDAP' password policy with the return code that it receives from LDAP during a password-related update. If ISAM can map this return code without any ambiguity with the corresponding ISAM error code, it does so and returns an error message.

• To take advantage of the multi-domain support in ISAM, use an LDAP user registry.

• With an LDAP user registry, the capability to own global sign-on credentials must be explicitly granted to a user. After this capability is granted, we can remove it.

• Leading and trailing blanks in user names and group names are ignored in an LDAP user registry in an ISAM secure domain. To ensure consistent processing regardless of the user registry, define user names and group names without leading or trailing blanks.

• Attempting to add a single duplicate user to a group does not produce an error in an LDAP user registry.

• The IBM ISAM authorization API provides a credentials attribute entitlements service. This service is used to retrieve user attributes from a user registry. When this service is used with an LDAP user registry, the retrieved attributes can be string data or binary data.

LDAP data format

The following LDAP data formats are available for user and group tracking information.

Minimal

Minimal format uses fewer LDAP objects to maintain user and group tracking information. Using this format reduces the size of our user registry information because minimal user and group tracking information is stored.

Standard

Standard format uses more LDAP objects to maintain user and group tracking. This format was also used in versions of IBM Tivoli Access Manager for e-business before version 6.0.

If the user and group information in the LDAP registry is used by other ISAM products, such as IBM Tivoli Access Manager for Operating Systems or the Federation Runtime, the same LDAP data format must be used for all products.

Sun Java System Directory Server look-through limit

When the directory server is installed, the default value for look-through limit is 5000. If the user registry contains more entries than the defined look-through limit, the directory server might return the following status that Security Verify Access treats as an error:

LDAP_ADMINLIMIT_EXCEEDED

We can modify this value from the Sun Java™ System Directory Server Console:

1. Select...
   Configuration > Data entry > Database Settings LDBM Plug-in Settings tab

2. In the Look-through Limit field, type one of the following responses:
   • The maximum number of entries that we want the server to check in response to the search, or type
   • -1 to define no maximum limit.

   If we bind the directory as the Directory Manager, the look-through limit is unlimited and overrides any settings that are specified in this field.

Microsoft Active Directory Lightweight Directory Services (AD LDS)

Review this information before configuring a Microsoft AD LDS registry for the environment.

• For IBM Security Access Manager version 9, there is no option for standard or minimal data model. Standard data model is only available for a migrated policy server. Because AD LDS requires a single naming attribute for creating LDAP objects, AD LDS requires the minimal data model. Regardless of which data model we choose, ISAM always uses the minimal data model if we select AD LDS as the user registry.

  The common name (cn) attribute is a single-value attribute and can store only one value. The AD LDS registry requires the value of cn to be the same as the cn naming attribute in the distinguished name (dn) attribute. When you create a user or group in ISAM, specify the same value for cn as the cn naming attribute in the dn. ISAM ignores the value of the cn attribute if it is different from the value of the cn naming attribute in the dn. For example, we cannot use the following command to create a user because the value of the cn attribute, fred, is different from the cn naming attribute in the dn, user1:

  pdadmin user create user1 cn=user1,o=ibm,c=us fred smith password1

Parent topic: User registry server installation