Azure AD SSO users unable to access transportation management module

SCM Epicor SCM
, , , , , , ,
1

After migrating our transportation management module to a hybrid cloud environment running ES 10.2.600, users authenticated through Azure AD SSO are getting access denied errors when trying to open the transportation-mgmt workspace. Local accounts work fine, but all Azure AD users are blocked.

The SSO authentication itself completes successfully - users can log into the main SCM system and access other modules like procurement and inventory-opt without issues. It’s specifically the transportation-mgmt module that’s rejecting them.

We verified that the Azure AD groups are syncing to our on-premises Active Directory, and the users have the correct role assignments in Epicor. The error message just says “Insufficient permissions to access Transportation Management” even though these same users had full access before the cloud migration. Has anyone encountered module-specific SSO access issues after a hybrid deployment?

2

Here’s the complete solution for your Azure AD SSO access issue:

1. Azure AD Reply URL Configuration: Add the transportation-mgmt module’s specific endpoint to your Azure AD app registration. Go to Azure Portal > App Registrations > Your Epicor SCM App > Authentication > Redirect URIs and add:

If your transportation module uses a separate subdomain or cloud service, include that specific URL.

2. Role-Based Access Claims Configuration: In Azure AD, configure custom claims to include transportation-specific roles. Go to Token Configuration > Add optional claim > Access token and add:

  • groups (include security groups)
  • roles (include app roles)

Then create a claims mapping policy that includes the transportation management security group. In your app manifest, ensure the “groupMembershipClaims” is set to “SecurityGroup” or “All”.

For ES 10.2.600, you also need to map Azure AD groups to Epicor roles. In your Epicor SCM security configuration, create explicit mappings:

  • Azure AD Group: “Logistics_Team” → Epicor Role: “Transportation_Manager”
  • Azure AD Group: “SCM_Users” → Epicor Role: “Transportation_User”

3. Hybrid AD Group Synchronization: Verify Azure AD Connect is syncing all transportation-related security groups. Check your sync configuration:

  • Open Azure AD Connect on your sync server
  • Go to Configure > Customize synchronization options
  • Verify that OU containing transportation security groups is included
  • Check filtering rules aren’t excluding groups with names like “TMS_" or "Transport_”

Force a delta sync after verification:

Start-ADSyncSyncCycle -PolicyType Delta

4. Validation Steps: After making these changes:

  • Have a test user sign out completely from all Epicor sessions
  • Clear browser cache and cookies
  • Sign in again through Azure AD SSO
  • Verify the access token includes the correct group claims (use jwt.ms to decode the token)
  • Check that transportation-mgmt workspace opens without errors

Why This Works: The issue occurs because hybrid cloud deployments create separate authentication contexts for different modules, especially when they run on isolated subnets. Your Azure AD configuration was only handling the main SCM authentication, not the module-specific security requirements. By adding the proper reply URLs, configuring role claims explicitly, and ensuring complete group synchronization, you create a complete authentication chain that matches what local accounts get automatically through direct AD integration.

This solution addresses all three focus areas: proper reply URL registration for the cloud endpoint, comprehensive role-based claims passing, and complete hybrid AD group synchronization to ensure cloud-authenticated users have the same security context as on-premises users.

3

We added the main cloud endpoint to Azure AD reply URLs, but I didn’t realize each module might need separate entries. The transportation-mgmt module does run on a different cloud subnet for network isolation. Could that be causing the issue?

Looking at our Azure AD app registration, we have the main SCM URL but nothing specific for transportation management.

4

This sounds like a claims mapping issue between Azure AD and your Epicor role-based access system. When you migrated to hybrid cloud, did you update the Azure AD reply URLs to include the new cloud endpoints for the transportation module? Each module can have different authentication requirements in hybrid setups.

5

Yes, that’s definitely part of your problem. In hybrid deployments where modules run on different subnets or cloud services, you need explicit reply URLs for each endpoint. But there’s more to this - you also need to check your role-based access claims configuration.

Azure AD needs to pass the correct role claims that match Epicor’s security model. Transportation management often has specific security groups that differ from general SCM access. Are you passing custom claims for module-specific roles, or just the standard user groups?

6

You’ve identified the core issue - your hybrid AD group synchronization isn’t complete for the transportation module’s security context. When local accounts work but SSO doesn’t, it usually means the cloud authentication path is missing critical group membership information that exists in your on-prem directory.

Check if your Azure AD Connect sync is configured to sync the specific security groups used by transportation-mgmt. Sometimes module-specific groups get filtered out during the initial sync configuration.

7

We’re passing standard group claims from Azure AD. I see in the token that users have “SCM_Users” and “Logistics_Team” groups, but maybe transportation-mgmt requires a specific claim format? The local accounts work because they’re authenticated directly against on-prem AD which has the full group membership details.