Microsoft Active Directory Server concerns

The following concerns are specific to Microsoft Active Directory Server:

• Users created in Active Directory might have an associated primary group. The Active Directory default primary group is Domain Users. However, the Active Directory does not add the primary group information to the user memberOf or the group member attribute. When ISAM queries for a list of group members, the result does not include any members who belong to the primary group. When ISAM queries for all the groups where the user belongs, the result does not display the primary group of the user. For this reason, do not use an ISAM group as the Active Directory primary group for ISAM users.
• Security Verify Access does not support cross domain group membership or universal groups. Security Verify Access does not support importing these types of groups.

• When ISAM imports a dynamic group, the ivacld-servers and remote-acl-users groups apply read permission on each authorization store to which the dynamic group belongs.

  The read permission enables Security Verify Access blade servers, such as WebSEAL, to read permission to the registry authorization store. Thus, the blade server reads dynamic group data, such as group membership for building Security Verify Access credentials.

  Manually removing the read permission while Security Verify Access is configured to the Active Directory registry results in adverse behavior, such as inaccurate group membership.

• If the option to change the user password by using LDAP APIs is enabled in an environment where:
  • Security Verify Access is configured to use the Active Directory user registry, and
  • Security Verify Access blade servers use LDAP APIs to communicate with the Active Directory server

  then Security Verify Access must be configured with Secure Socket Layer (SSL) to allow connections between the LDAP client and the Active Directory server. The Active Directory environment must also be enabled to accept LDAP connections over Secure Socket Layer (SSL).

• When we use an Active Directory user registry in an ISAM configuration with blade servers that use LDAP APIs to communicate with the Active Directory server, ISAM supports user password change requests by using either the Policy Server or LDAP APIs. Change user password requests using the LDAP APIs do not require the Policy Server to run.

  The use of LDAP APIs to communicate with the Active Directory Server for blade servers is a multiplatform support that allows blade servers to be installed on systems that are not clients of the same domain as the policy server. In this configuration, the policy server must be configured on a Windows operating system.

• When we use an Active Directory user registry, each user name and each group name in a domain must be unique. User and group short name values that are stored in the sAMAccountName attribute of Active Directory user objects and group objects. Active Directory user objects and group objects both have the sAMAccountName attribute as one of their attributes. Microsoft requires the sAMAccountName attributes be unique within an Active Directory domain.
• When we use a multi-domain Active Directory user registry, multiple users and groups can be defined with the same short name if they are in different domains. However, the full name of the user or group, including the domain suffix, must always be specified to ISAM.
• The following items are ignored when we use Microsoft Active Directory Server as the user registry in an ISAM secure domain:
  • Leading and trailing blanks in user names
  • Group names

  To ensure consistent processing regardless of the user registry, define user names and group names without leading or trailing blanks.

• ISAM supports the use of an email address or other formats of the userPrincipalName attribute of the Active Directory registry user object as an ISAM user identity. When the option is enabled, both the default and the email address or another userPrincipalName format can co-exist in the ISAM environment.

  The default format of the userPrincipalName registry attribute is user_id@domain_suffix, where domain_suffix is the Active Directory domain where the user identity is created.

  For example, johndoe@example.com is the value of the userPrincipalName; example.com is the Active Directory domain where the user identity is created. The Security Verify Access user identity corresponding to the registry user in this example is eitherjohndoe@example.com or johndoe. It depends on whether Security Verify Access is configured to use Active Directory with multiple domains or a single domain.

  The alternative format of the userPrincipalName attribute is user_id@any_suffix. any_suffix can be any domain (Active Directory or non-Active Directory) other than the Active Directory domain in which the user identity is created.

  For example, if the registry user johndoe@other_domain.com is created in Active Directory example.com, and the registry user johndoe@example.com is created in Active Directory domain child_domain.example.com. Both users can be Security Verify Access users, and their user identities are johndoe@other_domain.com and johndoe@example.com.

  Enable the alternative user principal name (UPN) support in all Security Verify Access runtime environments. Doing so ensures that Security Verify Access user identities work properly with alternative UPNs.

  When the use of alternative UPN format as user identity is enabled, it cannot be reversed without breaking Security Verify Access functions.

• Although users and groups can be created with names that use a distinguished name string, subsequent operations on the object might fail. A distinguished name string contains a forward slash (/) character. Some Active Directory functions interpret the forward slash character as a separator between the object name and the host name. To avoid the problem, do not use a forward slash character to define the user.

Parent topic: LDAP concerns