Federated registry support

Consider the following points when we configure federated registry support.

The federated registry support feature provides the following benefits:

• It provides the ability to use Security Verify Access with a user registry without requiring the addition of ISAM schema changes, accounts, and access controls in the user registry. These are instead stored in an separate registry leaving the user registry untouched.
• Multiple user registries can be federated into one common Security Verify Access registry.
• It introduces a method to support Active Directory for policy servers running on the appliance.

The following limitations apply to supported federated registries:

• IBM Security Directory Server nested groups are not supported for foreign user DN members.
• Dynamic groups are only supported for user DNs in the same registry in which the group exists. Each domain in Active Directory Forest is considered a different registry.
• IBM Security Directory Server supports foreign member DNs. This means that Active Directory native users could be added to ISAM registry groups such as su-admins. However the nested group limitation applies.
• Active Directory:
  • Active Directory groups do not support adding foreign user DN members. For example, users in the ISAM registry such as sec_master can not be made members of Active Directory groups.
  • When a native Active Directory user is removed by a process outside of ISAM, and that user was also an ISAM enabled user, Security Verify Access does not automatically detect and remove the ISAM component of this user.
  • Active Directory Forest: The Global Catalog is not an option for locating user credentials, only the ISAM principalName is used.
  • The connection to the registry must be over SSL/TLS for password operations to be permitted by Active Directory.

• Security Verify Access must be provided with an account (bind-dn) with sufficient privileges for the operations required on the suffixes of registry being federated to it. In some cases the actual users being federated need certain privileges.
• The bind-dn account is shared by all Security Verify Access processes on the same appliance. Thus it requires the permissions that will satisfy all these processes. For example, if both WebSEAL and the policy server are on the same appliance, then the bind-dn account needs all the permissions required by both.
• For all registry types and use cases: The bind-dn account needs permission to read attributes from the root DSE entry ("").
• Password Change:

  • If options bind-auth-and-pwdchg = yes or enhanced-pwd-policy = yes are set, then Security Verify Access managed federated users need permission to modify their own password. For example, the IBM Security Directory Server LDAP server requires an ACL to be attached, such as:

    aclEntry: access-id:cn=this:at.userPassword:grant:w

• If bind-auth-and-pwdchg = no, enhanced-pwd-policy = no, auth-using-compare = yes, and auth-using-compare is supported for the LDAP server, then the bind-dn account needs permission to be able to do an LDAP compare operation on the user's userPassword attribute.

• If neither of the previous two configurations are in force, then the bind-dn account needs password reset permissions discussed as follows.
  • The configuration property bind-auth-and-pwdchg is configurable per federated registry stanza and for the ISAM registry itself. It defaults to FALSE for all federated registries except Active Directory.
  • The configuration property enhanced-pwd-policy is a single global setting common to all federated registries and the ISAM registry itself. The Active Directory federated registry implementation does not provide all the features of enhanced-pwd-policy.

Password Reset:

If you reset the password with the pdadmin> user modify <user> password <password> command, then the bind-dn account needs permission to be able to set or reset a user's userPassword attribute (or unicodePwd for Active Directory).

Credential Construction:

• Active Directory:
  • The bind-dn account needs permission to be able to read the memberOf attribute of a user.

  • If dynamic-groups-enabled = yes, then bind-dn account needs permission to read the authorization store containing the groups with attribute groupType=34 and read the group attribute msDS-AzLDAPQuery, which contains a search filter. The bind-dn account then needs permission to search for user entries under the specified suffixes using this search filter.

• IBM Security Directory Server: The bind-dn account needs permission to be able to read the ibm-allGroups attribute of a user.
• Oracle Sun Directory Server: If dynamic-groups-enabled = yes, then bind-dn account needs permission to search under the specified suffix for group entries with an objectClass=groupOfURLs. It also needs permission to read the group attribute memberURL, which contains a search suffix, scope, and filter. The bind-dn account then needs permission to search for user entries under the specified suffix using this search filter and scope.
• For other supported registries, the bind-dn account needs permission to search for group entries under the specified suffixes and read their member entries.Notes:
  • The configuration property dynamic-groups-enabled is configurable per federated registry stanza and for the ISAM registry itself. It defaults to FALSE except for IBM Security Directory Server, which automatically provides dynamic group memberships using the ibm-allGroups attribute.
  • Read access to additional user entry attributes might be required if Security Verify Access is configured to fetch and add their values to the credential.

Import User or Group: The bind-dn account needs permission to read the user or group objectclass attribute.

If we do not plan to view, add, remove, or modify the federated registry native user and group accounts, then no additional permissions are required.

Federated registry native user and group administration via pdadmin: The bind-dn account must have permission to view, add, remove, and modify users and groups and modify group memberships under the specified federated registry suffix.

• AD registry support configuration
  Follow these steps to set up the ISAM to support federated registries.

Parent topic: LDAP concerns