Assign group policy by device type NOT working whatsoever

ronnieshih75
Building a reputation

Assign group policy by device type NOT working whatsoever

Have been trying to get this feature to work literally for years.  We need to block iphone and android devices on 2 SSIDs.  The SSIDs are configured through a template with the template assigned to over 200 wireless networks.  I can obviously see iphones with specific IOS versions being detected under Monitor/Clients but these devices are not getting blocked at all according to the policy I configured.  I've called Meraki support about this in the past and was given a fudge-over type of vague answer why this feature does not work and they are working on a different method to make this work.

Advise on whether anyone has this working at all.

ronnieshih75_0-1713535185506.png

 

19 Replies 19
alemabrahao
Kind of a big deal
Kind of a big deal

This is a bit complicated as client identification may not be accurate.

 

Note: Some clients may misidentify themselves when specifying the User-Agent string field of an HTTP GET request. Device type policy enforcement is done on a best-effort basis, dependent upon the information that the client provides. When needing to enforce security-focused policies based on device type, please leverage solutions such as Meraki Systems Manager, or Cisco ISE. 

 

https://documentation.meraki.com/MR/Group_Policies_and_Block_Lists/Applying_Policies_by_Device_Type

 

 

 

I am not a Cisco Meraki employee. My suggestions are based on documentation of Meraki best practices and day-to-day experience.

Please, if this post was useful, leave your kudos and mark it as solved.
ronnieshih75
Building a reputation

So the solution is to spend another half a million dollars?!  I am looking to block personal mobile devices from getting on wifi, not MDM enterprise managed devices.  None of these personal devices would be managed whatsoever with MDM software but needs to be blocked off specific wifi networks.

Because we deployed Forescout and it has its shortcoming is cannot fingerprint mobile devices properly either.

alemabrahao
Kind of a big deal
Kind of a big deal

Unfortunately yes. 😞

I am not a Cisco Meraki employee. My suggestions are based on documentation of Meraki best practices and day-to-day experience.

Please, if this post was useful, leave your kudos and mark it as solved.
mlefebvre
Building a reputation

Mobile device fingerprinting is difficult for any platform, because it relies on how the mobile device works and in the case of some vendors like Apple they are often taking steps to prevent this sort of fingerprinting because it is a privacy risk. What I would recommend instead is whitelisting your approved enterprise devices and blocking other devices by default

PhilipDAth
Kind of a big deal
Kind of a big deal

> I am looking to block personal mobile devices from getting on wifi

The #1 deployed solution for this is to use certificates.  Most companies have Active Directory, so there is nothing to buy.  It is just a configuration exercise.

RaphaelL
Kind of a big deal
Kind of a big deal

Have you considered WPA2-Enterprise with 802.1X and only deploy the certificate to your managed devices ?

ronnieshih75
Building a reputation

We already have a SSID using RADIUS servers with 802.1X auth using internal CA issued certificates, for all windows machines.  I will be turning off PEAP authentication off that network then personal devices with no enterprise issued certs can get on that network.  However, I have 1 PSK based network that I cannot readily change the preshared key on, that is why I'm looking for this feature to work.   My question is that if Meraki is detecting some clients properly under the "device type,os" field, then why isn't the feature at least working for those identified devices?  I get the whole user agent string thing through DHCP request and I've been down this path with meraki support.  I usually get a fall-off-the-cliff answer with support but noting this problem to them at the Cisco corporate office in Chicago only gets me pulled into a small room so I don't embarrass them in front of a large crowd red faced.  If this feature does not work at all, then by all means it should be taken off the dashboard completely.

alemabrahao
Kind of a big deal
Kind of a big deal

In fact, it is a two-way process, the device itself is the one sending the information to Meraki. So it depends more on the device than on Meraki itself.

I am not a Cisco Meraki employee. My suggestions are based on documentation of Meraki best practices and day-to-day experience.

Please, if this post was useful, leave your kudos and mark it as solved.
ronnieshih75
Building a reputation

I opened a Meraki support ticket and they played it as a firmware update as always, using v30.6 .  But this really doesn't fix the problem either after I upgraded ap firmware for some 40 wireless networks.  They did note that this feature does not work for 802.1x authenticated wireless network, and I accept that.  He did state that this should work for a PSK wireless network but it is not, no matter what firmware version the AP's are sitting on.

Once again, I have a PSK network that I cannot get rid of and readily change password on as many IoT devices are connecting to it.  We just need to block personal mobile apple and android devices not MDM managed.

alemabrahao
Kind of a big deal
Kind of a big deal

Unfortunately, this is a feature that doesn't work well precisely because it depends on the device sending the correct information. ISE or MDM are the key.

I am not a Cisco Meraki employee. My suggestions are based on documentation of Meraki best practices and day-to-day experience.

Please, if this post was useful, leave your kudos and mark it as solved.
MSakr
Getting noticed

HI

Did anyone manage to have this feature working? or Does Meraki plan to remove it from the dashboard, since a non working feature is misleading..

ronnieshih75
Building a reputation

It still does not work properly for us, even with most apple devices properly identified by meraki via dhcp user agent string.

MSakr
Getting noticed

It didn't work at all for us.. as if the settings are not there.. I totally never expected that from Meraki

Mojo
Conversationalist

Anyone figure this out? I am also experiencing this issue and getting the run around from meraki support.  Or is it still a broken "feature"

ronnieshih75
Building a reputation

This feature is still not working on AP firmware v30.7, a ton of months after I posted this originally.

alemabrahao
Kind of a big deal
Kind of a big deal

Unfortunately, this is a feature that doesn't work well precisely because it depends on the device sending the correct information. ISE or MDM are the key.

I am not a Cisco Meraki employee. My suggestions are based on documentation of Meraki best practices and day-to-day experience.

Please, if this post was useful, leave your kudos and mark it as solved.
alemabrahao
Kind of a big deal
Kind of a big deal

In fact, it is a two-way process, the device itself is the one sending the information to Meraki. So it depends more on the device than on Meraki itself.

I am not a Cisco Meraki employee. My suggestions are based on documentation of Meraki best practices and day-to-day experience.

Please, if this post was useful, leave your kudos and mark it as solved.
alemabrahao
Kind of a big deal
Kind of a big deal

This is a bit complicated as client identification may not be accurate.

 

Note: Some clients may misidentify themselves when specifying the User-Agent string field of an HTTP GET request. Device type policy enforcement is done on a best-effort basis, dependent upon the information that the client provides. When needing to enforce security-focused policies based on device type, please leverage solutions such as Meraki Systems Manager, or Cisco ISE. 

 

https://documentation.meraki.com/MR/Group_Policies_and_Block_Lists/Applying_Policies_by_Device_Type

 

I am not a Cisco Meraki employee. My suggestions are based on documentation of Meraki best practices and day-to-day experience.

Please, if this post was useful, leave your kudos and mark it as solved.
ronnieshih75
Building a reputation

Apple devices are sending accurate information down to the IOS version.  We verified this by talking to users in person and comparing their device types to meraki dashboard.  So why can't Meraki at least make that work?  It's virtually completely non-working since many months ago, it used to work "just a little bit" and now not at all.  

 

I literally manually block these by hand on a daily basis.

 

Let's not go down the path of talking about using 802.1.x auth and getting away from PSK SSID to prevent personal devices from getting onto a wireless network, we already talked about this above.  We have several reasons why we cannot change the password readily for our legacy PSK based SSID, that's why I went down this path hoping this feature would work.

 

Meraki should come out clean on why this doesn't work and kill this feature already.  I've opened at least 3 tickets on this over the years and it has gone nowhere.

 

ronnieshih75_0-1728486079596.png

 

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.
Labels