Objective
To explain Automox single Entity ID limitations for SAML/Single Sign-On (SSO) and provide alternative configuration options when integrating with Identity Providers (IdPs) like Azure AD / Microsoft Entra ID across multi-zone organizations.
Overview
When configuring SAML Single Sign-On across multiple Automox child zones, certain Identity Providers (such as Microsoft Azure AD / Entra ID) require a unique Service Provider Entity ID (or Audience URI) for each application instance.
Automox uses a single, global Service Provider Entity ID (https://console.automox.com/saml/metadata) across all organizations and zones. Because Automox cannot generate unique or custom Entity IDs per zone, multi-zone SSO configurations must utilize one of the supported architecture workarounds outlined below.
SAML Architecture Workarounds
Method 1: Parent-Zone Unified SSO Access (Recommended)
Rather than creating separate SAML applications in your IdP for every child zone, configure a single SAML integration at the Parent Zone level and manage child-zone access via Automox zone switching:
1.Configure SSO on the Parent Zone:
Set up SAML SSO exclusively on your primary/parent Automox zone using the standard Automox Entity ID (https://console.automox.com/saml/metadata).
2.Assign Parent Zone Read-Only Access:
Grant child-zone users Read-Only (or higher) permissions within the parent zone. This enables the user account to authenticate successfully through the parent zone's SSO trust relationship.
3.Remove Child Zone SAML Configurations:
Delete any standalone SAML SSO configurations configured on individual child zones to eliminate Entity ID conflicts.
4.Instruct Users to Switch Zones:
Users log in via the parent zone's SSO link. Once authenticated inside the Automox Console, users click their profile dropdown in the top-right corner and switch directly to their assigned child zone.
💡 Important Note for Managed Service Providers (MSPs):
Method 1 is strongly recommended for MSP environments. If a child org belongs to a customer with their own separate IdP/SAML provider, direct child-zone SAML setup will require the MSP provider to have user access within the customer's SAML instance (or vice versa). Using Method 1 allows MSP technicians to authenticate once via the MSP parent zone and seamlessly switch into client child zones without cross-tenant IdP dependency.
Method 2: Multi-App Shared Entity ID or Secondary SAML Instance
If your security policy mandates direct, isolated SAML logins for individual child zones, choose one of the following approaches:
IdP Supporting Shared Entity IDs: Deploy or route SAML authentication through an Identity Provider (such as Okta, PingIdentity, or OneLogin) that permits multiple SAML application instances to share an identical Entity ID / Audience URI (
[https://console.automox.com](https://console.automox.com)).Secondary Paid SAML Provider / Instance: Utilize a secondary paid SAML provider instance or enterprise IdP tenant dedicated to child-zone authentication. This allows distinct IdP tenant endpoints to handle isolated SAML assertions while fulfilling the unique application binding requirements.
Configuration Summary
| Solution Approach | IdP Support | User Experience | Administrative Overhead |
| Method 1: Parent Zone SSO + Zone Switch | All IdPs (Azure AD / Entra ID, Okta, Ping) | Authenticate to Parent → Switch to Child Zone | Low (Best for MSPs and internal IT) |
| Method 2: Shared Entity ID or Paid SAML Instance | Okta, Ping, OneLogin, or secondary paid IdP tenant | Direct login to specific Child Zone | Medium to High (Requires separate SAML app/tenant per zone) |