Hello @dstranathan and @shawn-ev,
I found this answer, can you tell us if it helps, please?
⚠️ Verify before relying on this — I found relevant material, but it may not fully cover your specific issue, so please confirm this against current Fortinet documentation.
Recommended approach
For a cloud-only Microsoft 365 organization, use Microsoft Entra ID integration in EMS together with MDM-managed macOS enrollment—not LDAP—as the primary model for macOS.
The documented macOS requirement in the cited EMS guidance is specifically that macOS does not use native Entra ID integration in the same manner as Windows, and that the integration requires the Mac to be managed through Intune or Jamf and enrolled in Company Portal with Entra ID. Your described Jamf Pro + Intune/Company Portal setup aligns with that prerequisite.
Do not choose LDAP for this use case
LDAP/domain authentication is not the appropriate option for a 100% cloud-based Entra ID tenant with Macs that are not domain joined. It would introduce a dependency on a directory/LDAP service that is not part of the stated identity model. The retrieved Fortinet material instead describes EMS Entra ID integrations as Microsoft Graph/API integrations and requires appropriate application permissions and tenant admin consent. It also notes that EMS supports commercial Entra ID subscriptions, not GCC, GCC High, or EDU tenants. [1]
Do not substitute EMS SAML SSO for endpoint registration
SAML is useful, but for a different purpose. The Fortinet documentation describes the EMS SAML configuration as allowing users to access EMS when EMS acts as the service provider (SP) and a third-party identity provider validates credentials. [2] In other words, configure SAML with Entra ID if you want Entra-based SSO for the EMS administrative/user portal login.
SAML should not be treated as the primary replacement for the Entra ID + MDM macOS registration workflow. There is a separate documented scenario in which an EMS invitation code uses a SAML verification scope; this can be relevant when users must authenticate during an invitation-based registration flow. [3] However, that is an interactive registration-verification mechanism, not documentation of equivalent seamless device- and user-level enrollment for Jamf-managed Macs.
Practical model for your environment
Use the following split of responsibilities:
Requirement Preferred mechanism
Import/synchronize Entra users and groups into EMS Existing Entra ID authentication server/domain integration
Mac device deployment and required macOS approvals Jamf Pro deployment and configuration profile
Mac eligibility for the Entra workflow Enroll the Mac in Company Portal using the user’s Entra ID, as required by the EMS macOS Entra guidance cited in the question
EMS registration protection / unattended registration Deploy a FortiClient package generated by EMS with the telemetry connection key embedded
EMS portal/admin SSO SAML SSO with Entra ID, optionally
Manual/invitation registration that requires user sign-in Invitation with SAML verification scope, if required
Registration and deployment considerations
For hands-off FortiClient registration, use an EMS-generated FortiClient installer rather than a generic installer downloaded from Fortinet Support. Fortinet states that if a FortiClient package is generated by EMS, the telemetry connection key is embedded and FortiClient does not prompt the user for it during registration. A generic Fortinet Support download does prompt for the key when a fresh registration is initiated. [4]
For macOS deployment through Jamf, ensure the Jamf configuration profile provides the required permissions. Fortinet documents that silent/efficient macOS deployment requires a Jamf Pro custom configuration profile to handle Full Disk Access, FortiTray network-extension permissions, and trust/import of the ZTNA CA and DNS root CA certificates. [5] Jamf is also documented as able to deploy FortiClient and associated VPN/SSL settings to macOS and iOS. [6]
Entra configuration checks
Because your existing Windows Entra/domain integration works, retain that integration and validate the following before expanding to Macs:
Use the client secret value, not the secret ID, in EMS.
Configure Microsoft Graph permissions as Application permissions, not Delegated permissions, and grant tenant admin consent. [1]
Fortinet lists User.Read.All and optionally Directory.Read.All among the permissions to review, subject to the integration’s required access.
Verify the EMS authentication-server connection using Test and confirm the imported domain’s synchronization is current in Endpoints > Manage Domains.
Confirm that the Entra tenant is a supported commercial subscription type.
Important limitation / what cannot be verified from the supplied documents
The retrieved material does not provide the precise FortiClient EMS 7.4.5 procedure that maps a Jamf-managed, Company Portal-enrolled macOS device to the exact EMS registration mode, nor does it explicitly confirm that this produces the identical user-level and device-level registration behavior seen on Entra-joined Windows devices.
Therefore, the supportable conclusion is:
Use Entra ID + Jamf/Company Portal enrollment for the macOS prerequisite.
Use Jamf to deploy the EMS-generated FortiClient package and required macOS configuration profile.
Use SAML only for EMS SSO and, if needed, invitation-code verification—not as the main Mac endpoint-registration replacement.
Do not use LDAP/domain authentication for this cloud-only Mac scenario.
The exact EMS screens and workflow for macOS registration should be confirmed against the current 7.4.5 Adding an Entra ID server and Jamf deployment documentation, or through Fortinet Support, because those specific steps are not included in the retrieved documents.
