Automatically assign Windows AutoPilot deployment profile to Windows AutoPilot devices

This week another (short) blog post about Windows AutoPilot. More specifically, about automatically assigning a Windows AutoPilot deployment profile to Windows AutoPilot devices. That makes it a lot easier for administrators, as this prevents the administrators from potentially forgetting to assign the deployment profile to newly imported devices. Great improvement. Also, I have to say that this subject is documented pretty good, but it could be easier to find. This post is mainly for creating awareness regarding this subject. I’ll provide the options regarding to grouping Windows AutoPilot devices and I’ll show how those options can be used to create a dynamic group.

Options

Let’s start by having a look at the configuration options regarding the grouping of Windows AutoPilot devices. The imported Windows AutoPilot devices are pre-created in Azure AD and, during that creation process, a few values are automatically set for those devices. Below is an overview of those different values.

Value Devices Explanation
[ZTDId] All Windows AutoPilot devices A unique value assigned to all imported Windows AutoPilot devices
[OrderID]:{YourOrderId} All Windows AutoPilot devices with a specific order Id An optional Id that can be specified when importing Windows AutoPilot devices
[PurchaseOrderId]:{YourPurchaseOrderId} All Windows AutoPilot devices with a specific purchase order Id An Id that is set by the OEM when importing Windows AutoPilot devices

Those different values can be used to create dynamic device groups within Azure AD. Below is an overview of the required queries per grouping of Windows AutoPilot devices.

Devices Query
All Windows AutoPilot devices (device.devicePhysicalIDs -any _ -contains “[ZTDId]”)
All Windows AutoPilot devices with a specific order Id (device.devicePhysicalIds -any _ -eq “[OrderID]:{YourOrderId}”)
All Windows AutoPilot devices with a specifc purchase order Id (device.devicePhysicalIds -any _ -eq “[PurchaseOrderId]:{YourPurchaseOrderId }”)

Note: These values can be seen by simply using Graph Explorer, querying https://graph.microsoft.com/v1.0/devices and looking for the physicalIds value.

Configuration

Let’s continue by having a look at how to use these different values and queries for actually grouping all Windows AutoPilot devices. The following 3 steps walk through the creation of a dynamic device group that can use the different queries mentioned earlier.

1 Open the Azure portal and navigate to Intune > Groups or navigate to Azure Active Directory > Groups to open the Groups – All groups blade;;
2 On the Groups – All groups blade, click New group to open the Group blade;
3a

AAD_DD_GroupOn the Group blade, provide the following information and click Create.

  • Group Type: Select Security;
  • Group name: Provide a valid name for the group;
  • Group description: (Optional) Provide a description for the group;
  • Membership type: Select Dynamic Device;
  • Dynamic device members: See step 3b;
3b

AAD_DD_RulesOn the Dynamic membership rules blade, select Advanced rule, provide one of the mentioned queries (depending on the type of AutoPilot devices selection) and click Add query;

Note: The example on the right is showing the query for all AutoPilot devices.

Once the dynamic device group is created it can used for assigning Windows AutoPilot deployment profiles. That enables the administrator to automatically assign a Windows AutoPilot deployment profile to all Windows AutoPilot devices.

Result

Let’s end this post by having a look at the results. Below, on the left, is a quick overview, via Microsoft Graph, about the device information of CLDCLN879139238. That shows the name of the device and the value related to all imported Windows AutoPilot devices. Below on the right is an overview of that same device, showing it as a member of the earlier created dynamic device group.

AAD_DD_Example2 AAD_DD_Example1

More information

For more information regarding the latest Windows AutoPilot features and the configuration steps, please refer to the following articles:

Conditional access and legacy authentication

This week is still all about conditional access. More specifically, the recently introduced feature to create conditions based on the use of legacy authentication (including older Office versions), which is currently still in preview. By now, I’ve done my fair share of posts regarding blocking legacy authentication (see for example here and here), but now it’s literally getting super easy. And no need for AD FS anymore. This helps with easily closing another backdoor, as previously legacy authentication simply bypassed any conditional access policy. In this post I’ll walk through the required configurations followed by the end-user experience.

Configuration

Before going through the configuration let’s start with a quick reminder about legacy authentication. Very simplistically said, legacy authentication is basic authentication that uses a single authentication factor in the form of a username and password and cannot force a second authentication factor (think about protocols like, POP3, IMAP, SMTP, MAPI and EWS and apps like, Office 2010). As I have no need for legacy authentication in my environment, I will block all legacy authentication to my apps. The following seven steps walk through the simple configuration to create a conditional access policy that blocks the access to all cloud apps for all users when using legacy clients.

1 Open the Azure portal and navigate to Intune > Conditional access > Policies or to Azure Active Directory > Conditional access > Policies;
2 On the Policies blade, click New policy to open the New blade;
3 AAD_CA_UsersAndGroups02On the New blade, select the Users and groups assignment to open the Users and groups blade. On the Users and groups blade, select All users and click Done;
4 AAD_CA_CloudApps02On the New blade, select the Cloud apps assignment to open the Cloud apps blade. On the Cloud apps blade, select All cloud apps and click Done;
5 AAD_CA_ClientApps02On the New blade, select the Conditions assignment to open the Conditions blade. On the Conditions blade, select Client apps (preview) to open the Client apps (preview) blade. On the Client apps (preview) blade, click Yes with Configure, select Mobile apps and desktop clients > Other clients and click Done and Done;
6

AAD_CA_Grant02On the New blade, select the Grant access control to open the Grant blade. On the Grant blade, select Block access and click Select.

Note: Make sure that there are no apps within the environment that still need basic authentication, as this configuration will block all of it.

7 Open the New blade, select On with Enable policy and click Create;

Note: It can take up to 24 hours for the policy to take effect.

End-user experience

One of the best use cases is an old Office version. Office 2010 and the default configuration of Office 2013, both use basic authentication. Office 2016 and later use modern authentication by default. Due to the way basic authentication works the end-user experience is not pretty and will not be pretty. Below is an example of the end-user experience when using Outlook 2010 for connection to Exchange Online. As mentioned, it’s effective and not pretty.

BlockOutlook

More information

For more information about conditional access and device state, please refer to this article about Conditions in Azure Active Directory conditional access | Client apps.

Join us at Experts Live Netherlands in Ede

A bit more than a week from now, June 19, Experts Live Netherlands will be in Ede. Experts Live Netherlands is the biggest Microsoft community event of the BeNeLux, with over a 1000 visitors. Together with my finest colleague, Arjan Vroege, I will deliver a session about your ultimate hybrid workplace. And we hope to see you there!

EL_social_tempate_speakers_Arjan

About our session

During this session we will take you into the world of the hybrid workplace. The modern workplace is a great story, for cloud only organizations, but the reality is often that there are a lot of components still on-premises. During this session we will touch the different delegate subjects from identity until apps and from management until connectivity. That means, a lot of ground to cover and a lot of choices to be made. Besides that we will have a couple of cool demos, here is a small list with a sneak preview of subjects that will be part of our session:  Pass-through authentication, Co-management, MSIX and Azure AD Application Proxy. Make sure that you don’t miss this!

Additional giveaway

As my employer, KPN ICT Consulting, is one of the Gold Partners of Experts Live Netherlands 2018, we also have a partner session. During that sessions my colleagues, Arjan Vroege and Nicolien Warnars, will explain how we internally migrated to a Microsoft 365 workplace for over 12.000 users. Very interesting for organizations that are looking for a great reference case.

Conditional access and device state

This week back in conditional access again. More specifically, the recently introduced feature to exclude devices based on the device state, which is currently still in preview. This enables organizations to exclude managed devices (Hybrid Azure AD joined and/ or compliant) from a conditional access policy. That means that the conditional access policy will only be applicable to unmanaged devices. This enables new scenarios and makes existing scenarios easier. Think about using session controls to enable a limited experience within cloud apps, for unmanaged devices only. In this post I’ll show the very simply and straight forward configuration, followed by the end-user experience.

Configuration

The configurations that make the most sense for using the device state are related to the access controls. At least, in my opinion. All other scenario’s can also be created by using the already available options. It just makes it a bit easier. By looking at the access controls, the session related controls are the most obvious configuration to start with. The Use app enforced restrictions session control enables organizations to enable a limited experience within a cloud app, for, in this case, unmanaged devices and the Use proxy enforced restrictions session control enables organizations to sent the user sign-in information to Microsoft Cloud App Security, also for, in this case, unmanaged devices. That enables additional actions based on the users sign-in activity. The following seven steps walk through the simple configuration to create a conditional access policy that uses the proxy enforced restriction session control.

1 Open the Azure portal and navigate to Intune > Conditional access > Policies or to Azure Active Directory > Conditional access > Policies;
2 On the Policies blade, click New policy to open the New blade;
3 AAD_CA_UsersAndGroups01On the New blade, select the Users and groups assignment to open the Users and groups blade. On the Users and groups blade, select All users and click Done;
4 AAD_CA_CloudApps01On the New blade, select the Cloud apps assignment to open the Cloud apps blade. On the Cloud apps blade, select All cloud apps and click Done;
5

AAD_CA_DeviceState01On the New blade, select the Conditions assignment to open the Conditions blade. On the Conditions blade, select Device state (preview) to open the Device state (preview) blade. On the Device state (preview) blade, click Yes with Configure, click Exclude, select Device Hybrid Azure AD joined and Device marked as compliant and click Done and Done;

Note: Think about the easier scenarios that can be created by using the option to exclude domain joined devices from the conditional access policy.

6

AAD_CA_Session01On the New blade, select the Session access control to open the Session blade. On the Session blade, select Use proxy enforced restrictions (preview) and click Select.

Note: Optionally configure additional a Cloud App Security Access policy or Cloud App Security Session policy to enable additional behavior based on the sign-in information of the user. For example, block the sign-in for a specific cloud app.

7 Open the New blade, select On with Enable policy and click Create;

Note: Basically the Azure AD conditional access policy and the Conditional Access App Control access or session policy will work together to perform real-time monitoring and control.

End-user experience

Let’s end this post with the end-user experience, followed with the administrator experience. As I only have connectors for Office 365 and Microsoft Azure in my Cloud App Security, I can only create access policies for the connected apps. These access policies can be used to simply monitor the activity or to actually block the session and display a custom block message. Besides that, the policy can also create alerts. In the dashboard, via email and via text message.

I created a policy that would block the session of the end-user with a custom message as shown below. Yes, I could have blocked the session already with conditional access itself, but this provides me with some more information about the sign-in.

CloudAppSecurity_Blocked01

When I’m now looking in the Cloud App Security dashboard, I can already see the alerts. When I navigate to either Investigate > Activity log or Alerts, I can look at the information as shown below. That provides me with the source, which, in this case. is Azure AD conditional access, the matched policy and information about the user and the device (as shown below). Pretty nice.

AppDashboard01

More information

For more information about conditional access and device state, please refer to this article about Conditions in Azure Active Directory conditional access | Device state.