#Modern Workplace

Credits: Google Microsoft’s shift to the modern Google Android Management API (AMAPI) brings a highly anticipated, low-friction onboarding experience to Android Enterprise Personally-Owned Work Profiles: Web-Based Enrollment. This mirrors the web-first workflow we’ve seen on iOS for a while, completely removing the traditional requirement for end-users to pre-download the heavy Intune Company Portal application from the public Play Store. However, moving to a modern, browser-driven enrollment framework completely changes how security tokens are passed under the hood. So if you are planning to deploy Android Web-Based Enrolment while maintaining a strict Zero-Trust tenant, you will almost certainly run into infinite authentication loops, hidden app blocks, and broken single sign-on (SSO). In this blog post, I’ll break down the architectural reality of Android container sandboxing, uncover the hidden identity dependencies, and detail the exact Conditional Access exclusions you need to m...

When it comes to capturing BitLocker encryption status, there are multiple options available in the Windows compliance policy in Intune. From  Require BitLocker , Require Secure Boot to be enabled on the device , and Require code integrity under Device Health attestation, to  Require encryption of data storage on device which not only captures the encryption status of the OS drive against BitLocker, but even non-Microsoft encryption solutions. However, it is a known fact that due to delays in getting BitLocker encryption compliance to report in a timely and accurate manner, it can rather be challenging in getting the right compliance settings in place. Especially if the device compliance state is being used in Entra ID conditional access policies. Another issue that I have come across is lack of compliance reporting against BitLocker recovery key escrow. This is especially common in Co-management scenarios when the BitLocker Drive Encryption management has moved to Intune an...

Source: Microsoft The memo 22-09  utilizes Microsoft Entra ID as the centralized identity management system when implementing Zero Trust principles and requires employees using enterprise-managed identities to authenticate through multifactor authentication through the means of FIDO2 security keys or Windows Hello for Business to protect against phishing related online attacks. There are multiple options for meeting phishing-resistant multifactor authentication requirements with Microsoft Entra ID. However, the trajectory should be towards implementing modern credentials. Some of the modern approaches are - 1. FIDO2 security keys which according to the Cybersecurity & Infrastructure Security Agency (CISA) is the gold standard of multifactor authentication. 2. Microsoft Entra certificate authentication without dependency on a federated identity provider. 3. Windows Hello for Business as phishing-resistant multifactor authentication Access to Microsoft admin portals like Microsof...

Recently, a customer asked me if there was a way to restrict access to corporate data on Azure AD joined Windows 11 devices only. They didn't want the existing conditional access policy to apply which required a Hybrid joined device to be compliant as they were moving away from Hybrid join identity for good. This intrigued me as there is actually no direct setting in the conditional access conditions & grant controls which covers Windows 11 & Azure AD joined states explicitly. So how do you grant access just to Azure AD joined Windows 11 devices? The answer is by using Filter for devices and specific grant controls.  In case you are unfamiliar with Filter for devices feature then you should know that Azure AD uses device authentication to evaluate device filter rules. For a device that is unregistered with Azure AD, all device properties are considered as null values and the device attributes cannot be determined since the device does not exist in the directory. Therefore,...

Recently, I had published a blog on enforcing MFA using Conditional Access policy for Windows 365 Cloud PCs . Now, in an effort to further improve the security of Cloud PCs, I am now covering the process of enforcing compliance for Microsoft Defender for Endpoint with Conditional Access, based on risk levels for Windows 365 Cloud PCs. Why enforce compliance for MDE in the first place? Short answer is - Why not? Not so short answer is that if you are licensed for MDE and have your endpoints onboarded in MDE and managed for MDE policies using Intune, then you can apply device compliance policies and use Conditional Access to identify threats. Once in place, these policies can help in identifying non-compliant devices which in turn can help in setting restrictions around access of corporate resources. Until the device risk level has fallen under the allowed level in the compliance policy, the restrictions will continue to stay in place. Let's look at the steps for putting the configur...