About PaulF

PaulF

@syang-IT : See my post at https://community.meraki.com/t5/Mobile-Device-Management/Pushing-Outlook-settings-to-iOS/m-p/176828/highlight/true#M9783

PaulF

So, let me start with the bad news: O365 / Microsoft deprecated username / password (badly) this year. This left a lot of people with no email access as their accounts / devices were still set to username / password but their Exchange servers / O365 was set to ADAL / Modern Authentication. And here lies the bad news:With Modern Auth / OAUTH you can't just set the username and hope that the user types in their password. The authentication flow is completely different and, at best, setting the username may remove just one of the two places that a user will be requested for their email address Now, the good news: Outlook now (if didn't used to be) has a great set of managed app capability: This allows you to configure a whole host of things. Assuming that you've got the Outlook app added Under Systems Manager > Apps : Go to Systems Manager > Settings Click the Plus (+) Give the profile a name, and add Managed App Config Search for Outlook : Now, if it's Android, then SM will go off to Google Play and get the current managed app config capability. Apple hasn't done this, so you'll have to use https://learn.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/outlook-for-ios-and-android/outlook-for-ios-and-android-configuration-with-microsoft-intune#configuration-keys as a reference You'll be able to automatically populate the email address using the example below: I hope that helps. Let us know how you get on.

PaulF

There isn't, no. You could, of course, remove kiosk mode from the device in dashboard instead: Then the end user would not have any need to know the passcode for kiosk mode disablement

PaulF

No. They can’t. And you can change your iCloud account email address at any time.

PaulF

And if the user who enrolled the device using Windows profile is not logged in, regardless of whether they have the agent or not, you'll get the message.

PaulF

So, windows has two modes (currently) of enrollment. MDM and agent. Because the MDM is tied to a user account on the device, it can't be updated if that user is not logged in, and that's why you are getting this message If you use the Systems Manage agent on the device, you won't get this error. I hope that helps Paul

PaulF

Hi There. So, firstly, you can browse through here: https://developer.apple.com/documentation/devicemanagement/commands_and_queries to determine what your employer can and cannot see However, keeping this much more simpler.... photos, whatsapp chats, emails, messages are NOT available to any MDM. This is the user data most likely to be available Persistent device IDs (serial number, MAC address, IMEI) Phone data (amount of data used, phone number, IMSI / ICCID, etc) Location apps installed. They cannot see if these are in use, however Profiles installed Certificates installed If you are worried about any of the above, I suggest you have a conversation with your employer and discuss your concerns. MDM has been around for nearly 20 years and is used by millions of people around the word. It cannot be used for getting access to your personal data. And it was never intended to do so.

PaulF

Hi @Guac55 and welcome! So, there's a few things we could do here, but none of them involve Intune. Meraki Systems Manager and Meraki MR have a technology called Sentry WiFi. This allows you, with nothing more than a handful of clicks, to provision devices with certificates bound to management (so that if you removed management, the cert would be removed too), which are then used for authentication. What you can do is use the various pieces of inventory and posture that we get back from a device to determine whether it has the right to continue to have the cert: Not compliant, no cert. However, if you were to look at MX in your network, then you could use Sentry Policies: This would allow you to determine the behavior of the device on your network: The posture of the device could be used to force a device onto a particular VLAN if it had a piece of unapproved software installed, wasn't running the latest version of the OS, and a whole host of other use cases https://documentation.meraki.com/SM/Deployment_Guides/Systems_Manager_Sentry_Overview However, we understand that moving MDM providers may not be in your roadmap. So, there's also another technology called Trusted Access that allows you to provision devices with certificates, but without the management. https://documentation.meraki.com/General_Administration/Cross-Platform_Content/Trusted_Access_for_Secure_Wireless_Connectivity However, Trusted Access doesn't completely fulfill your use case, as there's no posture check Anything that doesn't involve the above would be custom development on your side, alas.

PaulF

@Stefb Is there a particular reason you'd like to start enrollment from the SM app rather than email / self service portal? Your use case would be helpful before we look at how to solve the issue Kind regards, Paul

PaulF · ‎10-27-2022

First step is to ensure that there's a PIN on the device. Having just the policy isn't good enough. The PIN needs to be there. No PIN, no certs Secondly, you don't need to do any of the steps below. Just a SCEP policy, as below: And just make sure you've followed the steps here: Signing the Meraki MDM CA with your own - YouTubehttps://www.youtube.com › watch

PaulF · ‎10-13-2022

For security reasons, and to protect users, it may sometimes be required that you prevent unsigned (or unknown) packages from being deployed. If you're downloading a PKG from a vendor's website, then this *shouldn't* normally affect you. But, if you want to build your own packages (custom pre and post flight scripts, for example), or the application vendor hasn't signed their app (you should consider why this is), then here's a simple guide on how to sign a package for deployment using Meraki Systems Manager If you don't know if a package is signed on not, when running the installer manually, you'll see a padlock in the top right: Clicking on this will show you the signing certificate Requirements: You’ll need a developer account at https://developer.apple.com along with a paid for subscription. Part One: Apple Developer Website Log on to: https://developer.apple.com/account/resources/certificates/list If redirected, go to Account > Certificate, IDs & Profiles You should have any certificates already created. Click the + Select Mac Installer Distribution, as shown, and click Continue The site will now ask for your CSR... Part two: Creating a CSR Open Keychain Access on your Mac Click Keychain Access > Certificate Assistant > Request a Certificate from a Certificate Authority. Enter an email address in User Email Address. In the Common Name field, enter a name for the key Leave the CA Email Address field empty. Choose “Saved to disk”, and click Continue, and save this. More details here: https://help.apple.com/developer-account/#/devbfa00fef7 Part 3: Requesting your certificate Go back to your web page at Apple Developer Under Create a New Certificate, click Choose File Select the CertificateSigningRequest.certSigningRequest file you created earlier Click Continue You can now download your certificate Double Click this to add to your Mac’s keychain (You may wish to create a new keychain to keep your developer certs) Part Four: Signing your package You’ll need to know the identity of the signing certificate you created in the first section. You can find installed Identities with: security find-identity -v -p codesigning Open Terminal in the directory where your newly created install package is. We are going to use com.meraki.plistonly.pkg Type: productsign --sign 'Developer ID Installer: Paul Fidler (7H6G5F4D3D)' com.meraki.plistonly.pkg com.meraki.plistonly-signed.pkg You’ll be prompted for the currently logged in user’s password. You should see the following: productsign: using timestamp authority for signature productsign: signing product with identity "Developer ID Installer: Paul Fidler (7H6G5F4D3D)" from keychain /Users/Paul.Fidler/Library/Keychains/login.keychain-db productsign: adding certificate "Developer ID Certification Authority" productsign: adding certificate "Apple Root CA" productsign: Wrote signed product archive to com.meraki.plistonly-signed.pkg And, et voila , you now have a signed installer called com.meraki.plistonly-signed.pkg !

PaulF · ‎10-12-2022

As @BlakeRichardson mentioned, Apple Configurator has the ability to create problems ENSURE that you add a WiFi profile, that is set to AutoJoin when preparing devices with Apple Configurator. Without it, you'll end up with the device losing internet connectivity. You can even build the adding of the wifi profile into a blueprint to ensure a slick enrollment process

PaulF · ‎10-12-2022

Hi I've highlighted this to the engineering team, and that splitting the ability to manage OS updates from Kiosk Mode would help. Paul

PaulF · ‎09-29-2022

There is an issue with iOS 16 enrollments that Engineering is working on. They have a case open with Apple as it *may* be a bug on Apple's side.

PaulF · ‎09-27-2022

So, this particular API is relatively simple to use. In fact, using the link above, you don't even need to write a single line of code! This is a good place to start: https://developer.cisco.com/meraki/api/#!getting-started/base-uri For the lock devices API call: You'll be able to do this through the UI itself... You'll need: API key Network ID device IDs

PaulF · ‎09-27-2022

Not though the UI, although I'll feed that back, but it is available through the API: https://developer.cisco.com/meraki/api-latest/#!lock-network-sm-devices

PaulF · ‎09-27-2022

SM *should* also send out a profile for the PPPC. But, don't forget, SM cannot set the "Screen Sharing" aspect of permissions.... That's an apple limitation!

PaulF · ‎09-27-2022

Connect your iPad to a Mac. Open Apple Configurator, if not already downloaded. This will allow you to create and install a WiFi profile that *should* get you back on the internet. You'll then be able to remove Kiosk Mode from Meraki Dashboard and diagnose the issue

PaulF · ‎09-22-2022

Sadly not. HOWEVER: You *should* be able to enroll over the top of an existing enrollment, BUT only if the MDM profile is identical. This should also cure any issues your device may have.

PaulF · ‎09-22-2022

There is a solution to this that doesn't involve the wiping of the device Assuming that you've got the correct APNS cert now installed in the Meraki Dashboard, and that you've got the correct ADE profile assigned to the device Open Terminal on the device Type: sudo profiles renew -type enrollment You'll be prompted for the currently logged in user's password In the top right hand corner of the screen, you'll see: Click Update Now, open System Preferences, and navigate to Profiles You'll now have the ability to Update the MDM profile, essentially re-enrolling the machine, and fixing your APNS cert issue at the same time NOTE: This is a VERY powerful command, so, be careful!

PaulF · ‎09-21-2022

It is a requirement from Apple that devices are in ADE before this can be used And the only way to retrospectively add devices in ADE is after they've been reset, and are at the start of the setup assistant. Sorry to be the bearer of bad news. Paul

PaulF · ‎09-21-2022

There's 4 different sets of information that Systems Manager uses to infer location: IP address BSSID (Base Station ID of the WiFi Access Point it's connected to) Meraki BSSID GPS Some caveats to this: Only IP address is available through Apple's MDM. Everything else is gathered using the Systems Manager app BSSID is inferred from a database that other companies / users maintain, so it's not guaranteed to be accurate Meraki BSSID can be VERY accurate, but only if the access point is in the same organization as your Systems Manager instance, AND only if you've placed the access point accurately in Meraki Dashboard The SM app has to be running in the background for the information above to be retrieved Okay, so how do we ensure that we get the best information from the device? The first place to start is by having a look at your ADE (formerly DEP) profile.... Where you can skip steps at setup, did you skip Location? If so, your device won't report GPS. And it's such a pain to turn back on retrospectively. So, if you're skipping Location, consider changing this Ensure that the SM app is running in the background, and tat Background app refresh is enabled for it. Sadly, there's no way for us to systematically turn this on using Systems Manager: It's just not available to us using Apple's MDM functionality And, of course, if your using meraki Access Points, ensure that they are in both the same organization as your systems manager instance, and that you've placed them accurately in your dashboard I do hope that helps...

PaulF · ‎09-20-2022

Create a new profile, add the Restrictions payload and untick " Allow modifying account settings " That will prevent users from adding their own Apple ID

PaulF · ‎09-14-2022

This is a limitation of both. Regarding your second question: Also no. Google used to have managed app config capability for Chrome, but with the move to WebKit (the underlying technology for chrome), much of this functionality was removed Sorry to be the bearer of bad news....

PaulF · ‎09-13-2022

Sadly this is not possible with a Web Clip I don't know what your appetite for development is, but you could always deploy a certificate for users and use this for auth instead.... SM supports the dynamic naming of certs, so each user could have their own...

PaulF

Community Record

Badges