Setting up SAML for 2 Meraki tenants, one Azure tenant.

[Brian_Scheele]

We have 2 Meraki tenants and one Azure tenant.  Only some Meraki admins have access to both tenants, and of those admins, they may have read-only in one tenant and full access in the other.  We don't have any granular per-network access configured.

Tenant 1 has SAML SSO enabled.  Tenant 2 does not.  Those of us who are admins in both tenants are using an alternate email address to log into Tenant 2.

I would like to configure Tenant 2 for SAML SSO, but I am not sure how to go about this, as I don't want to just wing it and accidentally break something.  Ideally when someone logs in, if they have access to both tenants I would like for them to choose their tenant after logging in.

• Do I create a separate Enterprise App in Azure, or use the same one?
  • If it is a separate Enterprise App, will Meraki choke on that when I have the same Azure tenant IDs configured for 2 separate Meraki tenants?
• I would assume that I would create additional SAML roles in Meraki, and map them accordingly in the Enterprise/App registrations, considering that AdminJoe might have Full Access in Tenant 1, but Read-Only in Tenant 2.
• Do I need to use a different SSO Subdomain in Tenant 2, or is there a way to reuse the obfuscated value I have below in the first screenshot, so that my admins can log in then choose their tenant?
• Any other valuable insights?

Both tenants do have break-glass non-SAML SSO accounts, just in case something does get messed up with trying to configure Tenant 2.

Tenant 1: 

SP Initiated SAML IdP and X.509 cert SHA1 fingerprint are the same value.

SSO Subdomain is within the SLO logout URL.

Tenant 1 also has these two SAML roles, meraki_read and meraki_write:

On the Azure side:

1 tenant only.

Enterprise Application: Meraki Dashboard

The Thumbprint, App Federation Metadata URL contain the same identifier information for what I have in Meraki Tenant 1.

Also, the Login URL, MS Entra ID, and Logout URL (no screenshot provided) contain the same identifier information that appears in the Meraki tenant.  Everything works.

The Users and Groups for the enterprise app:

The App Registration, which is also named Meraki Dashboard, ties the Role Assigned from above to the roles within the Meraki dashboard.  I did not create msiam_access, but it magically appeared.

[PhilipDAth · Accepted solution]

There are multiple solutions.

First, if you change the "username" attribute from user.email to something like user.displayName, you can log in using SAML even when there is an existing Meraki account using the email.  I do this for 100% of the SAML configurations I do.

If you are happy to say all your users have the same permissions in all Meraki Dashboards you look after, you can make this simpler.  Much simpler.

If you copy, in the Meraki Dashboard, the SHA1 fingerprint and the "SSO Login URL" to any other Meraki Dashboard, and create the same SAML login roles - it will work.  It will allow you to SAML login to any of those orgs.  When you go to login, it will show you a list of all orgs you have permission to access, and you just click on the one you want to use.

No changes in Entra ID required.

Would this nice and simple configuration be sufficient?

[Brian_Scheele]

Changing to user.displayname was a good idea.  Implemented it and it worked.

Tenant 2 is in another country.  Not sure if that somehow messes anything up.

I could not reuse my subdomain and SLO logout URL that I used for Tenant 1, so I supplied different values specific for Tenant 2.  But Meraki did not like that when logging in, since that subdomain was not present in my enterprise app.  So, I added it as a secondary.

Currently, when logging into Tenant 2 using SSO, it brings me into Tenant 1.  I am going to wait 20-30 minutes and just try again.  Sometimes Meraki lags a bit when linking accounts between tenants.

Also after logging in I am not presented with both tenants.  Behavior is like we only have 1 tenant.

Or, maybe I just did something wrong.

[Brian_Scheele]

About 30 minutes after the changes, I am presented with both tenants after logging in.  
I do have separate login links per tenant, where it is https://subdomain.sso.meraki.com (substitute subdomain with what I plugged in separately for each tenant).

The SAML login history does not show my last login (maybe yet?) for tenant 2, but does for tenant 1, even though I used the link to login for tenant 2.

For permissions, Tenant 2 does have the same role names as Tenant 1, but additionally has 2 more roles specific to this tenant.  I really don't want Tenant 1 roles in there, so I plan to remove them and test again.

Not all admins have access, or the same level of access, to both tenants, so I want to use different role names that are tied back to roles in the app registration, then to security groups in Azure.

[Brian_Scheele]

I think you were definitely right about the roles needing to be in both tenants.  

I think I need to rethink the roles.

global_meraki_read (read-only, all tenants)

global_meraki_write (full access, all tenants)

Tenant1Write_Tenant2Read (full access to tenant 1, read only to tenant 2)

Tenant1Write_Tenant1Read (full access to tenant 2, read only to tenant 1)

Then have all 4 of these roles in both tenants.

EDIT:  I never added the Tenant 2 roles to the App in Azure.  Added them now, time to test.

[Brian_Scheele]

Thanks for your help!  That was exactly the solution I needed.  While I do have 2 different login URLs, both of them actually work, since I put the second URL for Tenant 2 here:

I ended up with 4 security groups, applied to both tenants.

• Full Access - All Tenants
• Read-Only - All Tenants
• Read-Only - Tenant 1 / No Access Tenant 2 (note that you don't actually put this in Tenant 2)
• Full Access - Tenant 2 / Read-Only Tenant 1

When logging in, it seems that the SAML login history only appears in Tenant 1.  I can live with that.

[Mloraditch]

I had no idea you could change the username field... that's what prevented me from setting up SAML so long ago, we instead wrote an API tool to manage admins.

I'm going to go bash my head into a wall.