IdP Initiated SAML SSO for Meraki Dashboard

[rhbirkelund]

Lately, SSO login for Meraki Dashboard has been a huge nuisance for me, as I'm getting access to more and more customer organisations that use SAML SSO in their organizations.

If unsuccessful in convincing their IT teams to add me directly as a local admin to their Org, I have to go through having my account created in their Azure tenant.

Which by all means is probably also the correct way, IT security wise.

But as an MSP with access to many customers, SSO is a PITA. Many customers followed the guides on the Meraki Documentation on how to setup SSO for their org in Meraki, but this has also resulted in many organisations' lack of consideration of the different SAML attributes in Azure.

An easy fix would be to set the username attribute to something else than userprincipalname, which for some reason equates to their email address. In my tests, using employeeid is usually the best alternative, since chances are that this is more unique between customers and organisations, and especially for external consultants like myself. 

I'm curious as to how others handle SAML SSO from an MSP stand of view? Do you also spend days during first time onboarding in just trying to get access, by having to make the customer reconfigure their Dashboard App, which by all means works for them?

What are you tips&tricks for when setting up SAML SSO? Or is there a simple Meraki setting that I'm just not aware of, that will fix everything, without having to touch their Azure tenant?

[rhbirkelund]

And well, this also goes to SP-initiated SAML SSO.

[rhbirkelund]

The SAML SSO configuration guide, clearly states that one should set the username attribute to email, but also clearly warns against it.

This really messes things up for MSPs and those of us who are external consultants.

[PhilipDAth]

I've never done a SAML deployment where I used the email address.  It just doesn't work in practice.  I usually make it "user.displayname".

[PhilipDAth]

Do you know the dashboard can support multiple SAML providers at the same time?

You should add your Idp to customers that you manage, so you can log in with the username in your tennancy.

[rhbirkelund]

Yes, but I tend to prefer not to do any major changes to customers dashboards, just in order to give me access.

[PhilipDAth]

A minimal config requires only two fields to be filled in - the "X.509 cert SHA1 fingerprint" and "SSO login URL".

That's the same number of fields to add a local Meraki user ...

I personally like having my own SAML roles (instead of using the Customers), and if you like that too - that is just two more fields, "Role" and "Organization access".

[rhbirkelund]

What would be the best course of action then, for an MSP with access to many customers?

If we add our company tenant as IdP to the customers' organizations, we'd need to then set up a Dashboard application per customer. WOuldn't that then result in many different customer apps on the myapp.microsoft.com page?

Or in the case of SP-initiated, they'd have to set a unique subdomain for their SSO login?

[PhilipDAth]

Negative.  Let me give you the link for SAML configuration for MSPs:
https://documentation.meraki.com/General_Administration/Managing_Dashboard_Access/Configuring_SAML_S...

"SAML does support the use of multiple organizations. Similarly to traditional logins, it needs to determine that the user is identical across the affected organizations. Thus, for this to occur, the following must be identical across the designed organizations:

• X.509 cert fingerprint for the organization (case sensitive)
• SAML administrator role (as only one role attribute can be used in the token)
  • The permissions granted can be different in each Organization, but the role name must be identical

When this occurs, the user will be directed to the MSP portal and receive the desired permissions in each organization. The Consumer URL for any of the MSP organizations can be used, as they will all direct the user to the MSP portal."

[PhilipDAth]

When you set it up - you only set it up for your own companies dashboard.  However you load the same SHA certificate hash into every customers Meraki Dashboard - and that gets you the access automatically.

[rhbirkelund]

So by using the same SHA certificiate (thumbprint) across different organizations, we'd be able to get the same Dashboard experience with a Organization Dropdown, and switch between organizations?

[PhilipDAth]

Same SHA certificate thumbprint and SAML role name.  Correct.

[rhbirkelund]

When I set up the Dashboard App in Azure, the identifier (Entity ID) needs to be my SSO url <subdomain>.sso.meraki.com.

If use the generic URL, SSO fails with the error that the identifier was not found.

 

The identifier (and Sign-on URL) are configured in Azure on a per organization basis, as I see it. So to have multiple organizations, I'd end up with many different dashboard applications in Azure. Unless I'm misunderstanding something?

[PhilipDAth]

Don't use a sub-domain (so you are doing Idp initiated login).

[PhilipDAth]

This is what the SAML configuration looks like for one of our clients.

[rhbirkelund]

Okay. So I add the same SHA thumbprint to another lab dashboard that I have. The consumer url on this Org is different to that of my first Org. In the Dashbord Application on Azure it still referes to the Consumer URL of the first Org. Where should I then reference the Consumer URL for the second org?

[PhilipDAth]

> Where should I then reference the Consumer URL for the second org?

You don't.  It is unused.  As soon as you have two configured it then takes you to the MSP portal.

I just onboarded another brand new org.  On the Meraki Dashboard org settings side, it just needed the config below.  Onboarding is super simple!

[PhilipDAth]

One thing I will mention - if you are onboarding a new org on a different shard there seems to be a delay before it appears in your MSP portal.  Maybe a 5-minute wait.

Once you have enough orgs onboarded, it is near instant.

[rhbirkelund]

Aha! Interesting. I'm now getting both orgs with the SAML SSO.

I think I've read through the SAML SSO guides on Meraki Docs hundreds of times, but I think these few details were really missing.

[PhilipDAth]

Perfect.  So you see how simple that is to onboard a new customer?

Put in your certificate hash, your SAML role name, finished.

[rhbirkelund]

Yes, it is simple and I see that we will still get the "easy" switching between organizations. Although, instead of simply browsing to dashboard.meraki.com, we'd now have to jump in through myapplications.meraki.com, and from there jump into the dashboard.

However, it still creates those issues where one has a local login somewhere in Meraki, which conflicts with SAML SSO.

E.g. my lab at home is a CMNA kit (from when you could get a full stack) with a couple other devices I scoured up over the years. This is an organization I'd prefer not having ties to my employers AD, however I still use my company email on it, to switch back and forth between lab networks and customers when needing to do changes.

Addtionally, SAML users can not create API Keys, so we'll have to add a local user to their dashboard anyway if needing to use Meraki API. Then from my perspective, I'd expect to run into the same troubles, since the API user cannot be a SAML user, but must a local user, and theres a match on the email address.

But I suppose, this is where user.displayname as the username attribute, comes into play?

[PhilipDAth]

>Although, instead of simply browsing to dashboard.meraki.com

I mostly live in my web browser.  For me it is about three clicks.  From webmail I click on the 9 dots in the top left hand corner, type "me" which brings up "Meraki Dashboard", and then click on it.  Pretty quick to get in huh?

>still creates those issues where one has a local login somewhere in Meraki, which conflicts with SAML SSO

On every SAML deployment I have done (and I have done a few) I always change the username attribute to user.displayname.  Problem solved.

>Addtionally, SAML users can not create API Key

Yet...  Watch this space.

[jimmyt234]

You should be able to copy the link of the application from the myapps page, add this to your bookmarks toolbar and then you're only a button press away from logging in 😊

[jimmyt234]

We have a single enterprise app in Entra and then use the same certificate fingerprint configured in all our customer Meraki orgs - this allows IdP initiated login for us as the MSP to all. We have two roles, one for read only and one for full.

The customer can then optionally setup their own alongside this.

[PhilipDAth]

Another way you could attack this (I have not tested this) would be to get the customer to add your email address to their Entra ID as a guest user.  Then grant that guest user access to the Meraki Entra ID app.  It should work.

You could make it smoother by having the customer create an Entra ID B2B relationship between their Entra ID tennancy and yours to trust your MFA.  This requires your customer to have an Entra ID P1 licence or better.
This would allow you to do seemless sign in to your customers Meraki environment.

But personally, I prefer direct SAML to the dashboard from your environment ...

And more specifically, I prefer Cisco Duo as the SAML Idp because it is so much easier to setup and manage ...

[rhbirkelund]

Having the customer adding med as a Guest User in their tenant, is usually where it goes badly. I'm added with my company email as a guest to the customers tenant, and as my email is already known as local account on many other customers organizations, I end up getting redirected to the Meraki "true" page with a SAML login failure in the dashboard logs.

[Arthamon]

@PhilipDAth great content and discussion. This is what these boards are for. Way better than just links to the KB articles.