I often refer to DEP as “Autopilot for iPads”, and Autopilot as “DEP for Windows”. The Device Enrolment Program allows you to register your devices with Apple so that when they are reset and go through activation, any DEP-assigned configuration is enforced onto the device.
DEP (and Volume Purchasing Program) have since been rebranded into Apple School Manager (or Apple Business Manager), which I think is a good move by Apple as I find it a lot easier than having to remember the special VPP store URL whenever I want to get some new apps, and having to remember the DEP URL to alter any device assignments.
Assigning devices to DEP is something that traditionally the reseller/supplier needed to do – you’d give them your DEP ID when placing the order and put their reseller ID into your DEP portal, and the devices would appear – however you can now add other devices yourself using Apple Configurator 2. This is particularly useful for older devices that you didn’t get set up on DEP, or if someone else in the organisation has randomly purchased some devices without speaking to you first from a supplier you don’t have an existing relationship with. You’ll need a Mac computer to run this – I use a Mac Mini – and it’ll need to be a fairly recent version. In this post I’ll go through how to set up AC2 to add devices to DEP, and then get them in to Intune for management. I’ll be referring to Apple School Manager in this post but the steps for Apple Business Manager are the same.
Windows Hello is Windows 10’s biometric authentication system which allows users to sign into their device using facial recognition (if the device has an IR camera), fingerprint (if the device has a fingerprint reader) and PIN. The data for these is stored on the device itself rather than transmitted to the authentication provider (i.e. Azure AD) so is more secure than a password as an attacker would need the device as well as the face/finger/PIN of the person they are trying to impersonate. In this case a PIN is more like a password, as we can define the minimum and maximum length, and allow/forbid/require lower case, upper case and special characters. The default setting permits numbers, lower and upper case letters but does not allow special characters.
At a basic level it works by using a public/private key pair or certificate based authentication. The private key and other biometric data is stored in the device, either in the TPM chip (if present) or in the file system. Windows Hello for Business is the enterprise version of Windows Hello and can be configured using Group Policy or a modern MDM such as Intune.
If configured correctly it can also be used to authenticate to on-premise resources such as from a domain-joined or hybrid-joined device. My preferred method of working here is to move things to use modern authentication and as such the devices I use to test this are just Azure AD joined (and provisioned using Autopilot), so I won’t be setting up the certificate for on-premise authentication. Continue reading “Intune: Windows Hello for Business”
Whilst Endpoint Protection can be suitably managed for traditional Active Directory-joined devices using Group Policies, you’ll need an alternative to protect your Azure AD joined devices. Luckily Intune can do this for us by way of a device configuration profile.
It’s something that isn’t recommended but sometimes there’s not really much you can do otherwise – we have a set of iPad minis which are shared between multiple pupils and at the moment they are on Meraki MDM, connected to the 8021X Enterprise wireless network using a username/password which is set via the MDM profile. I really want to move these devices to Intune but you can’t create a WiFi profile with embedded credentials on Intune – presumably this was never an option for obvious reasons.
The only other option I can see is to set up SCEP and have the devices issued with certificates, and then use those to authenticate, presumably I’d also need to enable device writeback so that the NPS server can see the devices in AD. Due to the way our AD is configured (single forest with lots of domains, synced to multiple Azure AD tenancies) device writeback is unsupported, so let’s look at embedding the credentials into Intune instead. Continue reading “Intune: iOS Wireless Profile with embedded credentials”
In this part of the Intune series of posts I’m looking at getting iPads enrolled and managed, and deploying apps. In my case I’m looking to migrate some iPads from an existing MDM into Intune, so I’m assuming you already have an Apple ID set up to create the push certificates and already have Apple School Manager (or Business Manager) set up.
Today I’m going to look at deploying applications to devices managed by Intune. Back in part 1 I looked at enrolling devices, setting up Autopilot, some basic configuration policies and also created a few Azure AD groups containing the devices.
There’s quite a lot of different application types in Intune, covering iOS, Android and Windows devices. As this series is focussed on Windows I’m not going to look at the iOS or Android ones at this time.
This post will go through the steps for installing/deploying the following:
Microsoft Store Apps – primarily Store for Business/Education apps, including linking Intune to the Store for Business/Education, but you can also deploy without setting up the Business/Education store.
As we plan to move towards 1:1 mobile device deployment I decided to take a look at how this would actually work – I don’t want to be unboxing devices and having my team run each one through an OS Deploy task sequence. Pretty much all our services have moved to the cloud (“My Documents” are in OneDrive, “Shared drives” are in Teams) I thought it’d be a good idea to look at Intune and Autopilot, with the devices being Azure AD domain joined, rather than local AD or hybrid. In this post I’ll go through what I’ve done and how far I’ve got things set up.
As a pre-requisite you’ll need to have either a fully cloud based domain, or have set up AzureAD Connect to sync your user accounts. On our network we have AADConnect syncing the user accounts and ADFS for authentication, with password writeback enabled to support self-service password reset.
My aim here is to be able to hand the sealed box to the end user, for them to unwrap, power up and configure without any intervention from us.
The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.