Microsoft Active Directory Server concerns

Edit online

The following concerns are specific to Microsoft™ Active Directory Server:

  • Users that are 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 Verify Identity Access queries for a list of group members, the result does not include any members who belong to the primary group. When Verify Identity Access 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 a Verify Identity Access group as the Active Directory primary group for Verify Identity Access users.
  • Verify Identity Access does not support cross domain group membership or universal groups. Verify Identity Access does not support importing these types of groups.

  • When Verify Identity Access 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 Verify Identity 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 Verify Identity Access credentials.

    Manually removing the read permission while Verify Identity 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:
    • Verify Identity Access is configured to use the Active Directory user registry, and
    • Verify Identity Access blade servers use LDAP APIs to communicate with the Active Directory server
    then Verify Identity 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 you use an Active Directory user registry in a Verify Identity Access configuration with blade servers that use LDAP APIs to communicate with the Active Directory server, Verify Identity Access supports user password change requests by using either the Policy Server or LDAP APIs. Change user password requests by 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 installed and configured on a Windows operating system.

  • When you 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 that the sAMAccountName attributes be unique within an Active Directory domain.
  • When you 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 Verify Identity Access.
  • The following items are ignored when you use Microsoft Active Directory Server as the user registry in a Verify Identity Access 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.
  • Verify Identity Access supports the use of an email address or other formats of the userPrincipalName attribute of the Active Directory registry user object as a Verify Identity Access user identity. When the option is enabled, both the default and the email address or another userPrincipalName format can co-exist in the Verify Identity Access 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 Verify Identity Access user identity corresponding to the registry user in this example is eitherjohndoe@example.com or johndoe. It depends on whether Verify Identity 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 Verify Identity 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 Verify Identity Access runtime environments. Doing so ensures that Verify Identity 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 Verify Identity 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.