- On-premises XenMobile interaction with Active Directory
- XenMobile Deployment
- Sending group enrollment invitations in XenMobile
- Configuring an on-premises Device Health Attestation server
- Configuring certificate-based authentication with EWS for Secure Mail push notifications
On-premises XenMobile interaction with Active Directory
This article explains the interaction between XenMobile Server and Active Directory. XenMobile Server interacts with Active Directory both inline and in the background. The following sections provide more information on the inline and the background operations that involve Active Directory interaction.
메모
This article is an overview of the interaction and does not cover the granular details. For more information about configuring Active Directory and LDAP in the XenMobile console, see Domain or domain plus security token authentication.
Inline interactions
XenMobile Server communicates with Active Directory by using the LDAP settings that an administrator configures. The settings retrieve information about users and groups. Following are the operations that result in interaction between XenMobile Server and Active Directory.
LDAP configuration. Configuration of Active Directory itself results in an interaction with Active Directory. XenMobile Server attempts to validate the information by authenticating the information with Active Directory. The server does so by using the internet protocol, port, and service account credentials provided. A successful bind indicates that the connection is configured correctly.
Group-based interactions.
a. Search for one or more groups during the Role-Based Access Control (RBAC) and delivery group definition creation. The XenMobile Server administrator inputs a search text string in the XenMobile console. XenMobile Server searches the selected domain for all groups that contain the substring that is provided. Then, XenMobile Server retrieves the objectGUID, sAMAccountName, and Distinguished Name attributes of the groups identified in the search.
메모
This information is not stored in the XenMobile Server database.
b. RBAC and deployment group definition add or update. The XenMobile Server administrator selects the Active Directory groups of interest based on the previous search and includes them in the deployment group definition. XenMobile Server searches for the specific group, one at a time, in Active Directory. XenMobile Server searches for the objectGUID attribute and retrieves selected attributes, including membership information. Group membership information helps determine membership between the group retrieved and existing users or groups in the XenMobile Server database. Changes to group membership result in the RBAC and deployment group derivation for the affected user members, which results in user entitlements.
메모
Changes to the deployment group definition can lead to change in app or policy entitlements for affected users.
c. One-time PIN (OTP) invitations. The XenMobile Server administrator selects a group from the list of Active Directory groups present in the XenMobile Server database. For this group, all the users, both direct and indirect, are retrieved from Active Directory. OTP invitations are sent to the users who were identified in the preceding step.
메모
The preceding three interactions imply that group-based interactions are triggered based on XenMobile Server configuration changes. When there are no changes to the configuration, the interactions imply that there are no interactions with Active Directory. They also imply that there are no requirement for background jobs to capture the group side of changes on a periodic basis.
User-based interaction.
a. User authentication. User authentication workflow results in two interactions with Active Directory:
- Used to authenticate the user with the credentials provided.
- Add or update select user attributes to the XenMobile Server database, including objectGUID, Distinguished Name, sAMAccountName, and direct membership to groups. Changes to group membership result in the re-evaluation of the app, policy, and access entitlements.
The user can authenticate either from the device or from the XenMobile Server console. In both the scenarios, interaction with Active Directory adheres to the same behavior.
b. App Store access and refresh. A refresh of the store results in a refresh of user attributes, including direct group memberships. This action allows for a re-evaluation of user entitlements.
c. Device check-ins. Administrators can configure in the XenMobile console the device check-ins on a periodic basis. Every time a device is checked-in, the corresponding user attributes are refreshed, including direct group memberships. These check-ins allow for a re-evaluation of user entitlements.
d. OTP invitations by Group. The XenMobile Server administrator selects a group from the list of Active Directory groups present in the XenMobile Server database. User members, both direct and indirect (due to nesting), are retrieved from Active Directory and saved in XenMobile Server database. OTP invitations are sent to the user members identified in the preceding step.
e. OTP invitations by user. The administrator inputs a search text string within the XenMobile console. XenMobile Server queries Active Directory and returns user records that match the input text string. The administrator then selects the user to send the OTP invitation. XenMobile Server retrieves the user details from Active Directory and updates the same details in the database before sending out the invitation to the user.
Background interactions
One conclusion from inline communication with Active Directory is that group-based interactions are triggered upon select changes to the XenMobile Server configuration. When there are no changes to the configuration, it implies that there are no interactions with Active Directory for groups.
This interaction requires background jobs that periodically sync with Active Directory and update relevant changes to the interested groups.
Following are the background jobs that interact with Active Directory.
Group sync job. The purpose of this job is to query Active Directory, one group at a time, on interested groups for changes to distinguished name or sAMAccountName attributes. The search query to Active Directory uses the objectGUID of the interested group to get the current values of distinguished name and sAMAccountName attributes. Changes in distinguished name or sAMAccountName values for interested groups are updated to the database.
메모
This job does not update user to group membership information.
Nested group sync job. This job updates changes in the nesting hierarchy of interested groups. XenMobile Server allows both direct and indirect members of an interested group to get entitlements. The direct membership of the users is updated during user-based inline interactions. Running in the background, this job tracks indirect memberships. Indirect memberships are when a user is a member of a group that is a member of an interested group.
This job gathers the list of Active Directory groups from XenMobile Server database. These groups are a part of either the deployment group or the RBAC definition. For each group in this list, XenMobile Server gets the members of the group. Members of a group are a list of distinguished names that represent both users and groups. XenMobile Server makes another query back to Active Directory to get only the user members of the interested group. The difference between the two lists gives only the group members for the interested group. Changes in member groups are updated to the database. The same process is repeated for all the groups in the hierarchy.
Changes to nesting results in processing the affected users for entitlement changes.
Disabled user check. This job runs only when the XenMobile administrator creates an action to check for disabled users. The job runs within the scope of a group sync job. The job queries Active Directory to check for the disabled status of interested users, one user at a time.
FAQ
What is the frequency of background jobs run, by default?
- Group sync jobs run every five hours starting at 02:00. local time.
- Nested group sync jobs run one time a day at midnight local time.
Why is a group sync job required?
- The memberOf attribute of a user record in Active Directory provides the list of groups the user is a direct member of. If a group moves from one OU to another, the memberOf attribute reflects the latest value of the distinguished name. The XenMobile Server database also has the last refreshed value. Any mismatch in the distinguished names of the group can result in the user losing access to the deployment group. The user can also lose the apps and policies associated with that deployment group.
- The background job keeps the group distinguished name attribute up-to-date in XenMobile Server database to ensure that users have access to their entitlements.
- Sync jobs are scheduled every five hours because it is assumed that group changes within Active Directory are uncommon.
Can a group sync job be turned off?
- You can turn off jobs when you know that interested groups do not change from one OU to another.
Why is a nested group processing background job required?
- Changes to nesting of groups in Active Directory is not a daily occurrence. Changes to the nesting hierarchy of interested groups result in changes to entitlements of the affected users. When a group is added to the hierarchy, its member users become entitled to the respective roles. When a group moves out of nesting then the member users of the group may lose access to the role-based entitlements.
- Changes to nesting are not captured during user refresh. Since nesting changes cannot be on-demand, the changes are captured through a background job.
- Nesting changes are assumed to be uncommon and therefore the background job runs once a day to check for any changes.
Can a nested group processing job be turned off?
- You can turn off jobs when you know that nesting changes do not occur to interested groups.