Meraki Spalsh Users across Networks

[vsurresh]

'Meraki Cloud Authentication' based SSID for Guest access.
Self-registration - Allow users to create accounts
Account authorization - Users must click a verification link in their email. (No need for sponsors)

Let's say we advertise the same SSID across different branch offices/networks. The current behaviour is if a user creates an account in one branch, the user is not authorized to connect the same SSID in different locations. Meraki admins need to authorize the user manually.

We have situations where the guests travel across different branches and it is now becoming a hassle to authorize them manually. Is there a way around this? I've looked into using 'Configuration Templates' which says:

"MR access points can be managed and deployed in bulk using network templates. It may be helpful to group into common deployment types, such as retail locations or branch offices, so APs deployed at different locations all use the same SSIDs and authentication methods. This way, a user at one location can seamlessly join wireless networks at another location without needing to provide a different PSK or credentials."

However, it doesn't mention the behaviour of Splash Users. I would appreciate any insights.

[alemabrahao]

You must have to authorize the user on every network.

Network-wide > Configure > Users

[redsector]

same issue. Each buliding is an own network. Roaming works well with automatic connection but not with guest-networks with splash-page.

[alemabrahao]

You must have to authorize the user on every network.

Network-wide > Configure > Users

[vsurresh]

I was speaking to Meraki support and they mentioned that if we use 'Configuration Templates' then the user accounts are synced across the networks that use the same config template. I'm going to test this and see if that actually works. I also tried using the API to automatically authorize the users but if a user creates an account in network-1, the user account doesn't show up on network-2 via the API. It does show up via the dashboard though. 

[Brendan7800]

We have the same issue! We use API calls to automate daily guest MerakiAuthUsers. You'd figure you'd want the same guest SSID and users across the organization or at the very least the ability for them to auto sync across the organization. However, as specified if you make the user on the network 1 via API, it doesn't show in the get Merkai users list for network 2. However, it does show in the GUI Dashboard for network 2! This prevents us from using a second API call to authorize the user for network 2. What is so aggravating is you can auth the user for network 2 in the GUI but not the API. I figured since the user isn't listed in a get Meraki auth user for network 2. That I could then make multiple API calls to make the user on each network......not so fast it says it already exists. So Meraki API doesn't see users from other networks but also does.....

[vsurresh]

I tried the API and got the same results as you described. Looks like using the Configuration Templates is the only way. I tried it and it worked.

[Brendan7800]

So even new accounts that you make after using config templates sync across the networks and are authorized?

[vsurresh]

Correct. Suppose you have 5 networks and you added them to the same Configuration Template, when a user creates an account in one of the networks, the account syncs across other networks under the same template. The user can then travel to different networks and use the same account. I tested them and it works.

[Brendan7800]

That is good to hear, I assume it's the same thing with clients such a mac address clients added to a group policy.

[vsurresh]

I haven't looked into group policies and also not going to use the templates. When you use templates, you lose some flexibility. For example, let's say you want to use a different VLAN ID for some of the networks or do you want to create a specific SSID in just one network. considering all of this, using config templates didn't make sense. Make you you test them properly before proceeding.