Nowadays where cloud services are available from all over the world we cannot (only) rely on trusted networks and on identities protected by usernames and passwords. Conditional access allows you to define granular controls whether an identity can access cloud applications. Based on the positive feedback for my “5 Ways to Screw up your Intune Tenant” post I felt empowered to get conditional access covered as well.
Chose your platform wisely # If you intend to use the device platform filter make sure that you cover all platforms including unknown platforms. Otherwise your might have a lack in your battleship. Also note that platform detection is based on best effort and can be exploited.
Long live legacy # Mind the client apps configuration to ensure that your conditional access policies also apply to non-modern authentication clients. If you have created your conditional access policies in the early days of the product you didn’t have this option available.
Something that has created some confusion is that conditional access policies don’t include legacy authentication clients by default, this means that if you have a conditional access policy enforcing MFA for all users and all cloud apps, it doesn’t block legacy authentication clients (or “Other clients”, as the CA UI refers to them) - Sue Bohn, Microsoft
Recently I read a great article from the Microsoft IAM Director Sue Bohn concerning a Conditional Access Q&A. One question was about the device platform feature - which let’s you apply a policy only to a specific device platform like iOS, Android or Windows 10.
The detection of the device platform relies on the user agent string sent by the application or web browser. Because this one can be spoofed easily better configure your Conditional Access policies wisely.
The problem # As soon as you enable the device platform selection there’s the chance that a user doesn’t catch any Conditional Access policy.
As a result, you should not rely on the User Agent String to be present or to be accurate. Most browsers have a function to set an arbitrary User Agent String for testing purposes. (Microsoft)
Bypass example # To give you an example, here’s a little walk-through:
Conditional Access Policy configured for all cloud apps Windows 10 selected as device platform Access control: Block If we now try to access the azure portal with a Windows 10 app or browser we get the following result:
A colleague recently asked me how to access the Microsoft Graph API using PowerShell without specifying his user account or credentials. So here’s a little post about the required configuration to authenticate against the OAuth 2.0 endpoint of Azure AD with an app registration. This is especially useful for automation services like Azure automation.
At the end of this post you’ll find a PowerShell template.
Gather application information # Create a new client secret for your app and note down the following values:
Client Secret Application ID (client ID) Directory ID (tenant ID) Azure AD App registration ## PowerShell code Request authentication token # In order to use the Graph API we need an authentication token. The information we gathered before is now sent to the Azure AD OAuth 2.0 endpoint.
https://login.microsoftonline.com/{TenantID}/oauth2/v2.0/token In the request supply a body with the following content:
$body=@{ client_id="8f9f420d-606c-4e13-889e-837072dbfb42" client_secret="BlaBlaExampleSecret" #Generated secret scope="https://graph.microsoft.com/.default" grant_type="client_credentials" } The scope and grant_type are required attributes. A full example looks like:
$body=@{ client_id="8f9f420d-606c-4e13-889e-837072dbfb42" client_secret="BlaBlaExampleSecret" scope="https://graph.microsoft.com/.default" grant_type="client_credentials" } $tenantId="7955e1b3-cbad-49eb-9a84-e14aed7f3400" Invoke-WebRequest -Uri "https://login.microsoftonline.com/$tenantId/oauth2/v2.0/token" -ContentType "application/x-www-form-urlencoded" -Body $body -Method Post If everything works we receive an access token object as HTML 200/ok response:
Recently a customer needed a drive mapping solution to access his on premise file shares during his transition phase to a cloud-only workplace. I wanted to share the solution with you because it’s a frequently asked question around a modern workplace migration. The following solution can also be extended or modified for a printer mapping or other PowerShell scripts which need to run on each user logon.
Updated 04.08.2019: I’ve developed an automated solution to generate network drive mapping configurations with an online tool which also migrates group policy network drive mappings. See: next-level-network-drive-mapping-with-intune.
Direct link to the final scripts
Lets assume we have the following scenario:
- Customer with hybrid user-identities (Azure AD Connect) - On premise ressources with legacy file shares - Devices are Azure AD joined ( **not** hybrid joined) - MDM managed with Intune - [Optional] Always on VPN for external on-premise resource access - [Optional] Windows Hello for Business deployment as described [here](https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso) Architecture # With my colleague Alain Schneiter I designed the following solution:
Main PowerShell script stored on Azure blob storage which handles the drive mapping - driveletters, UNC paths and descriptions can be configured within the script Client side script deployed with Intune which triggers the main script during logon. The main script is not stored locally which makes it easy to customize (no updates oder changes needed on client side) Deployment is user targeted via Azure AD group and Intune Azure blob storage configuration # We wanted to store the script within Azure because the customer was already using Azure blob storage. It’s also possible to store the PowerShell script on GitHub if you don’t want to use Azure.
If you are using Azure AD and the time passes you’ll have a lot of old device entries. If you enable the automatic device cleanup rule in Microsoft Intune the device is only removed within MDM and the Azure AD entry still exists.
Intune device cleanup rule For this reason I created a tiny PowerShell snippet to create a report with all devices which didn’t contact your Azure AD tenant since the treshold date specified. If you confirm the operation you can also delete all affected devices.
Please be careful when running the script because when removing a device from Azure AD the stored Bitlocker recovery keys are also removed. I can recommend Roger Zander’s Azure table-based Bitlocker recovery key solution.