Skip to content
Avanet

Sophos Protected Browser: Set up users and sign-in

Sophos Workspace Protection

Every Sophos Protected Browser user needs three things: a user object in Sophos Central, an appropriate sign-in method and access to the Sophos Self Service Portal (SSP). The safe sequence is therefore to select the user source, provision the users, configure federated sign-in for a cloud identity provider, choose the Sophos sign-in method and only then enable SSP access.

Prerequisites, licence and roles

Before making the first change, check the following:

  • Product access: Protected Browser must be available in the intended tenant under My Products > Protected Browser. A separate SKU or trial licence process is not documented here. If the menu item is absent, stop and have the tenant entitlement checked rather than assuming a licence.
  • SSP: All Protected Browser users need access to the Sophos Self Service Portal.
  • User source: Manually managed users can supplement a directory-backed user population, for example for people who are not in the directory service. However, users in the same domain must not be synchronised from both AD and Entra ID at the same time.
  • Role: A Super Admin is required to verify a federated domain and set up an identity provider. A Sophos Central console administrator sets up directory sources. A Super Admin is also required if an administrator role is to be assigned when manually creating a user. The User role is sufficient for users who only use Protected Browser; it provides access to the SSP only. Assign Sophos Fusion administration roles correctly explains the administrative role boundaries.
  • Pilot: Prepare one test user with a reachable email address. In Entra ID, Email and User principal name must match. Protected Browser does not support Google Directory.

If you use Okta, synchronise the Okta users with Active Directory first, and then AD with Sophos Central. General identity and ZTNA dependencies remain in Set up Sophos ZTNA: overview and sequence; this article covers only the user and sign-in chain required for Protected Browser.

Select a user source and provision users

Option A: Create individual users manually

This option is suitable for a small pilot or for people who are not in the directory service.

  1. Open My Environment > Users & Groups.
  2. Click Add user.
  3. Under First and last name, enter the name without a domain name.
  4. Under Role, select User for a standard Protected Browser user. An administrative role is appropriate only if the person will actually administer Central.
  5. Enter the Manager if required.
  6. Add the email address and save the user with Save.

The freely chosen name of the pilot user is not a technical key. A correct, reachable email address is what matters for the invitation and sign-in.

Option B: Synchronise Active Directory

Full AD synchronisation is a shared identity task and is not rebuilt as a second procedure in this article. The following boundaries are, however, important for the Protected Browser decision:

  • .NET Framework 4.6.2 must be installed on the synchronisation computer.
  • Sophos API credentials with the API role Service Principal Active Directory Sync are required. Keep access as narrow as possible.
  • Every user to be synchronised needs an email address. The firewall or proxy must allow the domains required by Sophos.
  • Users and email addresses must be unique within each Sophos Central account. Multiple AD clients from the same domain or subdomain are not supported.
  • Users and user groups are synchronised together; it is not possible to synchronise only one of these object types.

Operational note: Sophos recommends removing inactive users and devices from AD. An AD filter can prevent inactive users from being synchronised, but it does not eliminate the security risk of the AD account that still exists. Changes to search bases or filters can also move previously created Central users and groups outside the search scope and therefore remove them from Sophos Central. Check the planned scope before making the change.

Option C: Add Microsoft Entra ID

Entra ID requires a Sophos Central console administrator, a Microsoft Azure subscription with Entra ID, the Directory.Read.All permission and an Azure application. Record the Tenant domain, Application ID, the client secret Value and its expiry date.

Important boundaries before you start:

  • Office 365 GCC High is not supported for this synchronisation.
  • Only one Entra ID source is possible per domain.
  • Users or email addresses must not be synchronised with multiple Sophos Central accounts.
  • User synchronisation for the same domain must not run from AD and Entra ID in parallel.
  • Existing Central users and groups without a corresponding Entra ID object must be managed manually.

To add the source:

  1. Open Global Settings > Platform > Directory service.
  2. Click Add Microsoft Entra ID.
  3. Enter the source Name and Description, and its Domain.
  4. Click Next.

Further directory synchronisation remains the responsibility of the central identity team, using the Azure values checked earlier. If an existing Azure application only has the older Microsoft Entra ID Graph Directory.Read.All permission, Microsoft Graph Directory.Read.All must be added before changing the synchronisation.

Configure federated sign-in

Use this section when users sign in through a cloud identity provider. Perform the steps as a Super Admin. Before switching, ensure that all administrators and users are assigned to a domain and have an identity provider. Otherwise, federated sign-in must not yet become a sign-in option.

1. Verify the federated domain

  1. Open Global Settings > Access Control > Sign-in and Identity > Sophos Sign-in.
  2. Click Verify domains.
  3. Under Federated domains, select Add domain.
  4. Enter the Domain name and Description, then click Save.
  5. In Verify domain ownership, use Copy to copy the displayed TXT record, then select Cancel.
  6. Publish the TXT record in DNS. Propagation can take up to 24 hours.
  7. Return to Sign-in and Identity > Sophos Sign-in > Verify domains. For the relevant Verification Status, click Verify domain ownership, check the details and select Verify.

This step is successful when the domain appears under Federated domains with a verification date. Verification is valid for one year and can be repeated within that year.

2. Add an identity provider

Open Global Settings > Access Control > Sign-in and Identity > Federated identity providers and click Add identity provider. Assign a name without special characters such as ., @ or #; the configuration cannot be saved with these characters.

Then select the appropriate option:

  • Microsoft Entra ID: Under Type and Vendor, select Microsoft Entra ID in each case, enter the Tenant ID under Configure Entra ID settings, and select the verified domain under Configure domains.
  • OpenID Connect, for example Okta: Select OpenID Connect and the provider. Under Configure OpenID Connect settings, enter the Client ID, Issuer, Authz endpoint and JWKS URL. Then select the verified domain.
  • Microsoft AD FS: Select Microsoft AD FS, the provider and the AD FS metadata URL. Then select the domain, save with Save, and transfer the displayed Entity ID and Callback URL to the AD FS configuration.

You can add several domains to a provider, but each user can be assigned to only one domain. Also specify who enforces MFA:

  • IdP enforced MFA: The identity provider enforces MFA.
  • No IdP enforced MFA: Sophos Central enforces MFA after successful IdP authentication.

Click Save, select the provider in the list and click Turn on. Central allows activation only when setup is complete and the information is valid.

3. Select the Sophos sign-in method

  1. Open Global Settings > Access Control > Sign-in and Identity > Sophos sign-in settings.
  2. Select exactly one option:
    • Federated credentials only if only a cloud identity provider is used and no users were created manually in Sophos Central.
    • Sophos Fusion Admin or Federated credentials if manually created users exist alongside the cloud identity provider.
  3. Click Save.

The second option is not a generally “more secure” mode; it is the necessary choice for a mixed user population. Before switching additional users, record the previous mode and test the pilot user first.

Enable SSP access

Choose the access method to suit the rollout. To give all synchronised users SSP access, enable general access before directory synchronisation. If only a selected group should start, synchronise first and then send the setup email specifically to that group.

Access for all users

  1. Open Global Settings > Access Control > Sign-in and Identity > Sophos Sign-in.
  2. Under User Access, enable Sophos Fusion Self Service Portal access.

This gives all users, including people synchronised from a directory service, SSP access and a welcome email with sign-in information.

Access for selected users only

  1. Open My Environment > Users & Groups > Users.
  2. Select the intended pilot users and click Email Setup Link.
  3. Under Other Emails, select Sophos Fusion Self Service Welcome/Setup Email.
  4. Click Save.

The selected users also receive a welcome email with sign-in information in this option.

Validate with a pilot user

Check the chain in the same order in which it was configured:

  1. The user appears exactly once under My Environment > Users & Groups > Users and has the expected email address.
  2. For federated sign-in, the domain appears under Federated domains with a verification date and the identity provider is active.
  3. Under Sophos sign-in settings, the mode appropriate for the user population is saved.
  4. The pilot user receives the SSP welcome email and can use the sign-in path described in it.
  5. Only after this succeeds should the same method be enabled for additional users.

Do not expand the rollout if any of these results is missing. First check the immediately preceding component; successful domain verification, for example, does not prove that the identity provider is active or that SSP access has been granted.

Troubleshooting by symptom

The federated domain cannot yet be verified

Check that the copied TXT record was published exactly in the correct DNS zone. Then allow the documented propagation time of up to 24 hours and start Verify domain ownership again. A missing verification date is not a reason to proceed with IdP activation.

The identity provider cannot be saved or activated

If saving fails, remove special characters such as ., @ or # from the name. If Turn on is unavailable, setup is incomplete or contains invalid information. Depending on the type, check the Tenant ID, OIDC endpoints or AD FS metadata URL, and the selected domain.

The Entra connection test reports an invalid client ID

Check that the Azure application’s Application ID was actually entered as the Client ID. Sophos also identifies disabled user sign-in in the Microsoft Entra ID Admin Center as a possible cause. Correct these two points first; do not create a second source for the same domain as a precaution.

Users are missing or appear twice

For AD, first check whether the account is active, has an email address and is within the selected search base or filter. In Entra ID, existing Central objects must have a corresponding Entra ID object. Duplicate users can occur if the UPN synchronised from Entra ID does not match the user sign-in at the endpoint. Correct the source, UPN and email mapping first instead of enabling SSP access for both objects.

The user does not receive an SSP welcome email

Check which of the two access options was used. For general access, Sophos Fusion Self Service Portal access must be active; for a targeted pilot, Sophos Fusion Self Service Welcome/Setup Email must have been saved for that specific user. Then check the email address stored for the user. If these states are correct and no email arrives, the verified diagnostic path ends here; escalate delivery rather than changing sign-in or role values speculatively.

Safe rollback and offboarding

A general procedure for removing Protected Browser access and a complete rollback after a federation change are not documented here. Therefore, proceed in a limited and reversible way:

  1. Before the change, record the existing value under Sophos sign-in settings and the pilot scope.
  2. If the pilot cannot complete sign-in, stop the rollout. While a working administrator session still exists, restore the documented previous sign-in mode in the same dialogue and save it.
  3. Test the previous sign-in path again. Do not remove the federated domain or identity provider until their dependencies have been reviewed outside this guide.
  4. When offboarding from AD, remove inactive users and devices from the authoritative directory. Filtering them out of synchronisation reduces the transferred data but does not remove the inactive AD account or its security risk.
  5. This procedure provides no verified rollback for revoking SSP access from individual or all users. Stop here and confirm the current procedure in the tenant or with Sophos Support rather than guessing at a deletion or deactivation action.

Ongoing operation

Check these points regularly:

  • Federated domain: Monitor the verification date; verification is valid for one year and can be renewed beforehand.
  • Entra ID: Record the client secret expiry date. Before making changes, ensure that the Microsoft Graph Directory.Read.All permission is present.
  • AD: Regularly find and remove inactive accounts and devices in the authoritative directory. Check filter changes in advance for unintended removals from Sophos Central.
  • Identity coverage: Ensure that every affected administrator and user remains assigned to exactly one domain and a valid identity provider.
  • SSP access: For every joiner, mover or leaver, check that the user source, sign-in mode and SSP access still align.
  • Pilot before broad change: Test changes to the source, domain, IdP or sign-in mode with a limited user first and roll out only after the expected result.