Users and groups synchronization

Observe the following when synchronizing users and groups for the first time.

  • Users and groups must be synchronized together.
  • You must synchronize at least one group.
  • You do not have to synchronize all members of a group, nor is it necessary for all groups containing members to be synchronized. The cloud service can handle references between users and groups that are not actually present in the portal.

To synchronize valid group and user data in the portal, ensure your LDAP data meets the following requirements.

  • If you want to use group and user membership hierarchies, you must ensure the Group Parents, Group Members, and Other Groups fields are populated and return consistent data. For example, for the group/user relationship between GroupA and UserA to work correctly in your cloud security product, GroupA must have a ‘member’ attribute with a value of “UserA”, and UserA must have a ‘memberOf’ attribute with a value of “GroupA”.
  • Group Parents and Group Members attributes must be accurately maintained in the directory for each group, and both attributes synchronized with the DN of the referenced groups.
  • Users must have a MemberOf attribute with the DN of the group or groups of which they are members.
  • Globally unique identifiers (GUIDs) are normally an attribute in each directory object, and are used as the primary key in the portal. If GUIDs are not synchronized, they are automatically generated by the Directory Synchronization Client based on the object’s DN, and loaded into the portal. This is an acceptable solution unless the object’s DN changes (for example, if someone gets married and changes their name, or their object is reorganized in the directory). In this case the auto-generated GUID changes, and the user is treated as a new user. This could mean that their old details on the portal are not picked up, and they have to re-enter passwords and possibly other details. It is recommended that you synchronize GUIDs if possible.
  • There is considerable flexibility in the name attribute used when synchronizing to the portal. Use %CN% in the Name field to return the common name of the object; this is then synchronized. Most directories require the CN to be unique, which ensures the name is also unique on the portal. However, note that this is not enforced in all directories.

    %sAMAccountname, if provided, is also commonly used for the unique name of an object. We recommend that the Name is unique in the portal, although duplicates are tolerated.

  • Each user must have a valid email address, and this must be unique. Any users without an email address are rejected by your cloud security product during the synchronization.
  • For users, the Name attribute can be constructed dynamically to become the NTLM ID for the user object. A typical NTLM ID is domain\username.

    In directory terminology this could be constructed in a variety of ways, for example:

    • ACME\\%CN% would produce an NTLM ID with the domain=ACME, and username=common name of the object—for example ACME\JSmith
    • %DC[-1]%\\%CN% would produce an NTLM ID based on a DC and the CN of the object – for example, in the domain acme.com, this would produce acme\JSmith
    • ACME\\%sAMAccountName% would produce ACME\\JohnSmith. This is used in Active Directory schemas as it is used for the NTLM ID in Windows and is the recommended solution in those environments.

When constructing the NTLM IDs, it is important to ensure a match with the NTLM IDs used by the end users.

On the portal there is also a Name attribute in the Users record. This is always the CN of the object.