Jumping in here after reading this entire thread to give a few comments about JumpCloud and our experience with it for their RaaS. I know it's 5+ months late for your question, but maybe it will help others scavenging this thread for morsels of information. It's important to understand that we have a few different platforms to cover our needs. While there is a fair amount of overlap in our platform choices, they were picked for specific reasons and because of the pricing we received as a non-profit. Our imperfect solution combines: Okta (SSO) JumpCloud (Windows/Apple MDM) Google Admin (ChromeOS MDM) Meraki (Wifi) Powershell scripting to make it "seamless" for Windows users Google Admin policy to make it "seamless" for ChromeOS users I will also apologize for not being nearly as well educated in networking as other members who have posted here already. Okta is our SSO and IdP. We fully left Microsoft AD behind in the great Covid work from home flight. Okta and JumpCloud were the two platforms selected to replace our on-prem AD. Utilizing SCIM, we push our users from Okta to JumpCloud. This also syncs their local logon password from Okta to JumpCloud. For the RaaS, now that they have dynamic groups, users are added automatically to an access group to allow them to use the RaaS. The setup of the JumpCloud RaaS in Meraki was fairly straightforward and didn't present any critical problems that I can recall. Or at least nothing that a little bit of troubleshooting couldn't resolve. So now users could log into the wifi with their SSO creds. Next to make it seamless. Up to this point, you could fully achieve that without using a JumpCloud agent. It could be a very expensive investment to only buy the RaaS feature from JumpCloud considering everything else they can offer now. Since we are using JumpCloud for our MDM, we installed agents and can leverage their remote commands feature. I prepped a wifi profile XML and in that XML I substituted the wifi credentials with $Variables that would pull from the creds they used to log into their laptop, which again are their SSO creds thanks to Okta/JumpCloud SCIM provisioning. That XML file is delivered to their laptop via command and then the actual powershell command will create the wifi profile utilizing that XML. The wifi is set to auto connect, so nearly flawless seamless wifi access via their SSO creds. This worked for 99% of our windows users. Very rarely would we encounter someone that had issues. We would just forget the wifi, delete the XML, and rerun the command in JumpCloud to fix it. The same behavior was achieved for ChromeOS users using Google Admin's policies and setting it up to use variables for the user name and password. I was working on getting a command setup for MacOS / iOS devices, but they are much harder to work with for me and we just lost time and traction. Given the relatively small number of those users, we just connect them manually to the wifi. NOW... The reason I came to this thread... Many months after that aforementioned setup, we came into a position where we needed to save some extra money where possible. We had been inadvertently provisioning ALL our users from Okta to JumpCloud, including those that don't use a Windows laptop. JumpCloud cannot manage, at least to a level we are comfortable with, ChromeOS devices. It is on their radar for better options, but they are being tight lipped about it whenever I ask. So, we decided to remove the ChromeOS users from our JumpCloud. Since JumpCloud charges by user, not device, it made sense. Well, as we discovered, that of course removes their ability to use the RaaS and thusly use the office wifi... As an temporary solution, we have those users connect to a more traditional PSK wifi. The Chromebook users do not visit the office regularly at all since we have maintained a hybrid work model. So this has been an acceptable workaround for the moment. Since Okta offers a cloud LDAP, we thought we might be able to use that with Meraki local auth, but Okta's EAP-TLS cert is not viable for Meraki's certification chain. So now we are stuck in a position of trying to find a solution among the resources we currently have to give all our users seamless and secure access to the office wifi. I was kinda hoping that maybe Azure AD or Microsoft Entra ID could possibly be leveraged since that still exists, but as you might have surmised by this point in this thread, that is a lost cause still.
... View more
