Frequently asked questions

Edit online

Are there extra details on the configuration entries for attribute synchronization?
The configuration is used by Directory Sync to create User and Group SCIM REST API calls to update the tenant registry. The configuration is thus similar to the input to these APIs so the documentation of this API can help with the understanding. See the POST, PATCH, and PUT operations for /v2.0/Users and /v2.0/Groups, for example https://docs.verify.ibm.com/verify/reference/createuser .
Which to use, urn:ietf:params:scim:schemas:extension:ibm:2.0:User.realm and unqualifiedUserName or just userName with @realm?
urn:ietf:params:scim:schemas:extension:ibm:2.0:User.realm and unqualifiedUserName are ignored and are removed from the sample configuration file. Use the userName with @realm. For example, if your userName is the attribute userPrincipalName with value testuser@adomain.com and the Verify realm is "verify-realm", set the userName by using the following example.
{
  "ldap": "userPrincipalName",
  "tweaks": {
    "append": "@verify-realm"
  }
  "new-attr":{
    "scim":{"userName":"{{value}}"}
  },
  "mod-attr":{
    "scim":{
      "add":{"op":"add","path":"userName","value":"{{value}}"},
      "remove":{"op":"remove","path":"userName"},
      "replace":{"op":"replace","path":"userName","value":"{{value}}"}
    }
  }
}
Which results in the userName being set to "testuser@adomain.com@verify-realm" for the preceding example values.
Note: If the IBM® Verify Bridge agent is also being used against the same on premises registry, then the @realm set on userName must match the identity source that is associated with the Bridge agent.
The "ldap-base-dn" configuration is not fine grained enough when Active Directory is used. What alternative solutions are there?
Active Directory provides an operational attribute that allows matching specific groups of DNs, "msDs-parentdistname". This attribute can be added to the "ldap-search-filter" configuration string to restrict the user and group matching to specific areas of the directory. "msDs-parentdistname" is true for all the immediate children of the matched DN. This matching is not a subtree match, rather a one-level match. For example, 
"ldap-base-dn": "DC=adomain,DC=com",
"ldap-search-filter":"(|(&(objectClass=user)(msDs-parentdistname=CN=SyncUsers,DC=adomain,DC=com))(&(objectClass=group)(msDs-
parentdistname=CN=SyncGroups,DC=adomain,DC=com))"
This filter matches only users like cn=testuser, CN=SyncUsers, DC=adomain, DC=com, and groups like CN=testgroup, CN=SyncGroups, DC=adomain, DC=com.
Can the users that are being synchronized be identified only by a group membership?
Yes, but never use group membership as an "ldap-search-filter" condition. When a user entry in Active Directory is initially created, its group membership is not present. It is added after the creation step. Thus, the user creation event is ignored and lost when it is used in "ldap-search-filter". The solution is to use the "user-sync-filter" configuration entry. See The cloud-bridge JSON object . This configuration item is not limited to just memberOf. Other user attributes can also be used in a similar way.
Is the upn attribute in Verify SaaS mandatory?
While the UPN (User Principal Name) attribute is not technically mandatory for Active Directory (AD) integrations, it is recommended. If an application or integration, such as Azure AD or a specific SAML or OIDC service provider, explicitly requires the UPN attribute, you can configure it as a custom attribute within IBM Verify. It is only necessary when your use case involves SSO assertions or attribute mappings that depend on the UPN, especially when:
  • Using a custom login page that routes based on UPN
  • Supporting multiple domains or realms
  • Implementing SSO scenarios
Is the separation of bridge instances (Users, Admins, Groups) recommended?
No, this separation is not the recommended approach according to IBM best practices. IBM Verify Bridge for Directory Sync is designed to handle both users and groups in a single instance. The standard deployment model is one Directory Sync bridge per directory source, with standby redundant instances for high availability. Also separating by function (users, groups) is not recommended as it increases complexity and can lead to synchronization issues.
Why are there two username attributes in IBM Verify (preferred_username and username) and what’s the difference?
IBM Verify uses two distinct username-related attributes.
  • userName is the primary identifier that is used for authentication and system operations. It serves as the primary unique identifier for the user in the system and must be unique within a realm. It is used for authentication processes, user lookups, and system operations. It is often mapped to the userPrincipalName (UPN) from Active Directory and is critical for system functions.
  • preferred_username is an alternative username that is typically used for display purposes. It is used primarily for display purposes in the user interface and it provides a more friendly display name. It can be shown in user profiles and UI elements. It is not used for authentication or system lookups and can be changed without affecting core authentication.
Which type of users is better for Directory Sync to create when it is combined with a Bridge agent for password authentication, federated users or regular users?
Federated users are the correct option. Federated users in IBM Verify support SSO capabilities. They maintain the on-premises registry as the authoritative source for identity information. They authenticate against the external identity source (on-premises Bridge agent) and their attributes are synchronized from the on-premises registry.