Sophos Mobile: Distinguishing users, Self Service, and AD integration

Documentation-based guidance — not a production-validated operating procedure. This article distinguishes the Mobile People view from identity management in Sophos Fusion. The menus and prerequisites below reflect the documented behavior, not an outcome verified in a production tenant; changes and edition-specific visibility require separate checks before operational approval.

Establish ownership and edition first

Do not create identities in Mobile: The People list reflects relevant Fusion accounts. An account missing from the list has not necessarily been deleted or left uncreated; first check the edition and assignments. Account creation, account editing, group creation, and group membership remain in Fusion. General Fusion Self Service access is separate from the Mobile SSP configuration that determines eligible groups and enrollment options. Assigning a group to a Mobile SSP configuration does not grant administrative roles.

Assign Mobile Self Service deliberately

Before any group reassignment or LDAP Apply, confirm the tenant’s actual license and edition (MDM-only or combined Sophos Mobile versus MTD-only), the operator’s effective Mobile Administrator settings-write role, and change authorization. A Mobile SSP user group grants no administrator role; Helpdesk and Read-only cannot save settings. Record the approved prior configuration and arrange an authorized pilot and observed restoration before operational approval; these steps do not establish an LDAP disable or rollback procedure.

1. Check the edition, the existing Fusion account, and the intended device assignment for a pilot user. In the full version, consider Apple Business app assignments separately; do not assume this additional reason to appear in People applies to Threat Defense.

2. Check the intended user group and membership in Fusion, or manage them through the responsible Fusion process. Do not “create” the group in Mobile People.

3. Open Setup > Self Service Portal. On Self Service Portal configurations, open the intended configuration for editing, or select Create and set Name for a new one. Full platform configuration is deliberately outside this group-assignment procedure: prepare device type, ownership mode, enrollment package, texts, device limit, and safe actions using the Avanet Mobile SSP configuration guide before assigning the group; group assignment does not replace these prerequisites.

   Only after the assignment, edition, and Default checks below, under User groups > Add, select the intended pilot group. Before Save, tightly restrict the group and actions, because saving can enable permissions for users already assigned. Select Save on Edit Self Service Portal configuration; then use the arrow icons beside the configuration on Self Service Portal configurations to check and, if needed, change its priority. Before assigning the group, check whether it is already assigned to a Mobile SSP configuration; the same group cannot be assigned to multiple configurations. Plan any reassignment rather than adding the group to a second configuration. In the intended configuration, check the device types eligible for enrollment and the device actions available in that edition. Assigning the group alone does not restrict the rollout to that group: The always-present Default configuration has the lowest priority and applies to users without another matching SSP configuration. Check its permitted device types and actions too. If a user belongs to multiple groups with matching configurations, the configuration with the highest priority applies; check the priorities of the other matching configurations before the pilot. Group membership alone proves neither portal sign-in nor successful device enrollment.

4. Before a broad rollout, use an eligible pilot account and a user excluded from the target group who has no other matching SSP configuration to check the enrollment options and device actions actually offered; if multiple groups match, also test a user belonging to those groups. For the eligible pilot account, verify actual Self Service sign-in and, after a test enrollment, the device assignment in People. Do not assume the excluded user will be denied portal access: check whether Default still permits enrollment or actions. Claim that access is limited to the target group only after checking the effective configurations and pilot results. If results differ, diagnose Fusion identity and group membership separately from Mobile SSP configuration and priority; do not change production assignments solely because of a list entry.

LDAP for AD accounts during automated device provisioning (full version)

The documented Mobile LDAP connection applies to Fusion user accounts originating in Active Directory. During automatic provisioning of Apple Business-managed iPhones, iPads, and Macs, Google zero-touch Android devices, or Samsung KME Android devices, Mobile authenticates the user against AD only when the AD sign-in path is selected. Depending on the device type, documented alternatives include Fusion credentials and, for Apple Business iPhones and iPads, federated sign-in; an Apple Business profile can also enroll without user authentication, in which case it does not automatically assign a user. This is not an alternative procedure for creating a Fusion account. Sophos documents this LDAP page for the full version of Mobile; the Threat Defense People navigation reviewed here does not include a corresponding LDAP page. This does not establish that Threat Defense can never technically use AD: check availability in the specific tenant before applying these instructions to it.

Before making a change in the pilot, ensure that the Fusion user account originates in AD, the Fusion email address matches the AD mail attribute, the directory server supports LDAPS, and the firewall permits the necessary inbound connections to the AD server from the Sophos addresses for the Fusion region. For the AD sign-in path, set up AD synchronization in Fusion; Sophos recommends running it regularly. After identity changes, recheck that the Fusion email address matches the AD mail attribute, since authentication fails if they differ. The synchronization and its effects have not been tested in the tenant for this article. LDAP uses TCP 636. First determine the region in Fusion via My Products > Mobile: the browser address bar shows it in the first URL component immediately after smc-user-if-cloudstation-. Example only: smc-user-if-cloudstation-eu-west-1.prod.hydra.sophos.com means eu-west-1; use the actual tenant region shown for your rule. Immediately before applying the firewall rule, look up that region’s current source addresses in the Sophos list of addresses for AD and SCEP connections. Bounded live lookup: This external link is solely for checking current addresses during the firewall change, because Sophos maintains its cloud addresses; the configuration method is explained here. Permit inbound connections only from those regional Sophos sources to the intended AD server on TCP 636, restrict both source and destination, and do not allow unrestricted access. Do not copy addresses from another region. TCP 443 belongs to the separate SCEP feature and is not an additional LDAP requirement. Use an account without directory write permissions for the LDAP bind. Without a configured LDAP connection, users taking the user-authenticated setup path with Fusion credentials need an invitation to the Fusion Self Service Portal and must activate their accounts; this does not rule out Apple Business enrollment without user authentication.

For the documented full-version path, open Setup > Sophos setup > LDAP connection, select Configure external LDAP, and on the Server details page enter the IP address or name of the primary directory server in Primary URL. Optionally, enter the IP address or name of a second directory server in Secondary URL; Sophos Mobile uses it as a fallback if the primary server is unavailable. Sophos specifies <domain>\<user name> and <user name>@<domain>.<domain code> as bind-user formats; enter the bind user in User and its password in Password on Server details. Then move to the Search base page and enter the distinguished name (DN) of the search base object there. This object determines where the LDAP search starts in the directory. Select Apply. For AD sign-in, also explicitly select Yes - LDAPS authentication under Assign user to device in the Apple Business profile used for iOS or macOS; for KME, select User authentication in the enrollment settings. Google zero-touch assigns users automatically only on the user-authenticated path: the Zero-touch enrollment settings have a User authentication checkbox; clearing it enrolls a user-less device without assigning a user. On macOS, Yes - LDAPS authentication also permits Fusion email and password; selecting it alone does not prove AD credentials were used. The LDAP connection alone does not switch an Apple Business profile to AD sign-in. During pilot-device setup, observe the selected authentication, correct email mapping, and subsequent Mobile assignment. Merely saving the connection does not prove that enrollment succeeds. Before changing or disabling the connection, check whether already planned Apple Business, zero-touch, and KME provisioning depends on the AD path, and document the previous connection state and firewall rules; this article provides no rollback procedure for changes to Fusion accounts.

Outstanding approval checks

Operational approval pending: Edition and visible actions in a real tenant, group authorization for Mobile SSP, test sign-in and device assignment, and the LDAP connection and safe rollback have not been validated in a lab. The separate handling of Mobile device assignments when a Fusion user is deleted is outside this procedure; do not infer from account deletion that the device has been unenrolled or deleted.