Active Directory Synchronisation Explained
- Active Directory connections are shared across all licensed products. Think carefully about whether you need multiple Active Directory connections as doing so could lead to duplicate objects being synchronised to licensed products, thus consuming more licenses than required. Generally, if multiple connections are required, you should filter each one using attribute, group or DN paths, such that each connection is handling a subset of your users.
- On-premise Active Directory connections require installation of the AD Connect client. The AD Connect client will check for changes every 15 seconds and then synchronise them to the USS account.
- Azure Active Directory connections require a trust relationship with Microsoft Azure/Graph API. The Azure AD will be polled for changes every 15 minutes.
- Using "Only sync users with this attribute set" will limit the synchronisation of user objects into the USS cloud account and as a result, limit the user objects synchronised with all licensed products. If you intend to use extension attributes with Azure AD, you will need to synchronise them with Azure AD using the Microsoft Azure Active Directory Connect tool. It is possible to use multiple values, separated by semi-colon
; with this attribute filter.
- The "Only sync groups with this attribute set" only limits the synchronisation of groups. Users will not be excluded unless the "Only sync users with this attribute set" option is also used in conjunction. This group filter is purely for excluding group objects. It is possible to use multiple values, separated by semi-colon
; with this attribute filter. This option is currently only available for Azure AD connections.
- Deleting an Active Directory connection will delete all of the objects and any reference to them will be removed from any licensed products e.g. Web Security rules, Email Security rules, MFA rules.
- If a user is a member of nested groups in Active Directory, the group membership list will be flattened when synchronised to USS.
- It is not possible to specify a custom attribute to obtain email address and phone number values from when using Azure AD.
- If synchronising phone numbers, the user object must have a valid phone number, without a leading zero and of the correct length for the country code in use.
Synchronisation with Web Security
- The Web Security Cloud Gateway requires SAM account names for user authentication. Native (cloud-only) Azure Active Directory (AAD) does not support SAM account names however AAD can be synchronised with on-premise Active Directory to obtain SAM account names if required. This is a hybrid AAD environment.
- If hybrid AAD is in use, the Netbios Name in the connection must match the USS Gateway Active Directory Netbios name (used for Kerberos authentication) or the samaccountname will not match and filter rules based on AD User will not apply. Please request this change via your service provider if you do not see the NetBIOS option in the Settings tab of your Azure Active Directory connection.
Synchronisation with Email Security
- The account must have an email domain configured.
- The user objects must have an email address that matches the configured email domain.
Please note that email addresses should conform to 7-bit ASCII. Special characters introduced with the RFC 6531: SMTP Extension for Internationalized Email (SMTPUTF8) are not supported.
- If the above conditions are met, user email addresses will appear in the Mailboxes view. If the email address is not in the Mailboxes view (or existing as an alias to an existing mailbox) then mail will be rejected.
- Exchange distribution lists will be visible in the "Everything" section of the Active Directory view
- User objects must appear in the Active Directory view before they can be synchronised with the Email Security product.
- The service will poll for changes to Active Directory objects every minute and then attempt to synchronise them with the Email Security product.
Synchronisation with MFA Powered by IntelliTrust
- The account must have sufficient licenses to synchronise the user objects.
- If the Active Directory connection is configured to synchronise MFA users that belong to a particular security group, then the license count must cover the number of members of the group. If the synchronisation fails due to insufficient licenses, you must make a change to a member of the security group in order to trigger the synchronisation attempt again.
- Avoid the use of special characters.
- The user object must have a first name and last name, these attributes cannot be blank.
- The user object must have a valid email address.
- The user object must have a valid phone number, without a leading zero and of the correct length for the country code in use.
- If a group filter is used to limit the MFA user synchronisation, the users to synchronise must be a member of the specified group. This is not the same as a group attribute filter, which controls synchronising of groups to the USS account. Changing the MFA Group filter will cause existing users to be deleted, new users to be synchronised and Soft Tokens will require re-provisioning.
- If a user fails to synchronise due to one of the above conditions not being met, the user must be modified in some way to trigger another synchronisation attempt.
- Nested group memberships are supported. If User X is a member of "Group B" and Group B is a member of "Group A" and the connection is limiting synchronisation to users belonging to "Group A" then "User X" will synchronise. If more groups are added as members of "Group A" then those users will synchronise also.
- User objects must appear in the Active Directory view before they can be synchronised with the MFA product.
- The service will poll for changes to Active Directory objects every minute and then attempt to synchronise them with the MFA product. If there are a large number of users to synchronise, it may take multiple polls for all users to be synchronised.
- It is possible to override the default phone number prefix in the connection settings by specifying the prefix in the Active Directory user attribute for the mobile number e.g. connection prefix can be +44 but an individual user can have a different +33 prefix if it is set explicitly in their user object.