Meraki Single Sign-On (SSO) integration with Azure AD. Including granular rights assignment.

SOLVED
AdamSedar
Conversationalist

Meraki Single Sign-On (SSO) integration with Azure AD. Including granular rights assignment.

Hi all.

 

I have recently implemented single sign-on of the Meraki dashboard with Azure AD.

Here is the article I have just written about it;

 

https://www.linkedin.com/pulse/meraki-dashboard-sso-azure-ad-services-microsoft-identity-adam-sedar/...

 

I found a little stumbling block when I first did this work, that I did not include in the article.

Firstly. If you enable group-based claims within Azure AD, you need to be running an up to date version of Microsoft AD connect software.

Only the more recent versions of the software provide the ability to replicate on-premise group names (rather just the GUID) to Azure AD.

This is only required if you want to use on-premise AD groups, to give access to the SSO Meraki portal.

 

Secondly, I found (and tested multiple times) that when the SAML token is sent to Meraki, yes the AD groups are also listed under the role claim.

However, the problem is that all the groups that the user is a member of, are sent.

From what I can tell the Meraki dashboard only reads the first role claim entry, not all of the lines.

 

In the article above, I have documented using Azure RBAC function within the Azure enterprise application, thus you can map an RBAC role (by value) to a group role claim, which enabled the SSO to work.

Also enabling you to give different Meraki rights based on user or group, the same as ADFS.

 

What is nice (in my opinion) is that you don't need to place a non-SAAS service dependency on your Meraki SAAS management.

 

I hope this helps people.

All the best.

Adam.

1 ACCEPTED SOLUTION

Thanks very much Philip.

 

I found that there seemed to be a functionality gap here and I couldn't find any simple, full guides on how to achieve something which I thought made sense.

 

Regards,

Adam.

View solution in original post

7 REPLIES 7
PhilipDAth
Kind of a big deal

Well done!  That is impressive!

Thanks very much Philip.

 

I found that there seemed to be a functionality gap here and I couldn't find any simple, full guides on how to achieve something which I thought made sense.

 

Regards,

Adam.

View solution in original post

stevebyatt
Meraki Employee

Thanks for sharing this Adam. 

No worries Steve. What's the chances of getting something like this documented officially within Meraki, Microsoft Azure's Identity Services become commonplace now. 🙂

Not sure Adam, but between Paul and I we will try to find out 🙂

c53e
Conversationalist

No matter what I try to do when editing the JSON I get

 

"Failed to update Meraki Dashboard application. "Error detail: One or more properties contains invalid values.""

 

The JSON now also has more attributes than it used to:

 

  "allowedMemberTypes": [
                "User"
            ],
            "description": "msiam_access",
            "displayName": "msiam_access",
            "id": "xxxxxx-yyyy-ffff-nnnn-jgjgjgjg",
            "isEnabled": true,
            "lang": null,
            "origin": "Application",
            "value": null
 
 
For some reason this SAML implementation has been a pain in the ass compared to all the other apps we use. 
 
The full JSON looks like this when it throws the error
 
"appRoles": [
{
"allowedMemberTypes": [
"User"
],
"description": "msiam_access",
"displayName": "msiam_access",
"id": "<Default Guid>",
"isEnabled": true,
"lang": null,
"origin": "Application",
"value": null
},
{
"allowedMemberTypes": [
"User"
],
"description": "Meraki Admin",
"displayName": "Meraki Admin",
"id": "randomly created GUID",
"isEnabled": true,
"lang": null,
"origin": "Application",
"value": "Meraki Dashboard Admin SAML Group name"
}
],

Hey man, no idea if you ever figured this out, but if not, remove "origin": "Application", from all custom roles.  That is what AzureAD doesn't like

Get notified when there are additional replies to this discussion.
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.