Modern Device Management

There are many options available for deploying Windows Hello for Business, ensuring compatibility with various organizational infrastructures. For cloud-only organizations, the implementation is simple and works straight out of the box. However, for Hybrid based models, where most organizations operate, there are can be some additional configurations requirements. Out of the available trust types - Cloud Kerberos, Key or certificate, Cloud Kerberos is the easiest and also the Microsoft recommended trust type. It allows users to authenticate to Active Directory by requesting a TGT from Microsoft Entra ID, using Microsoft Entra Kerberos. This way the on-premises domain controllers remains responsible for Kerberos service tickets and authorization. Which brings me to the reason behind writing this blog post. I recently assisted a customer with an issue involving Windows Hello for Business authentication while accessing on-premises resources like file shares. The end user experience was so...

When it comes to implementing least privilege model for Intune permissions, the most common way is to use the role-based access control (aka RBAC). As a focus for this article, I wanted to touch upon the permissions required for managing endpoint security related settings in Intune, but configured using Defender. Consider a scenario where security and endpoint teams are different. While Endpoint team will normally focus on the administration of managed enterprise devices using Microsoft Intune admin center, security analysts will focus on security aspect of resources using the Defender portal. The real challenge comes, when the two roles start to merge or overlap. This is where strong governance for access permissions can play a crucial role. While implementing RBAC in the respective administration portals is the recommended way to address this, in the off chance that an organization has not implemented this, the relevant permissions, for endpoint security in Intune in particular, can ...

Enrolment time grouping for Android Enterprise is finally here. I had been using it for Autopilot Device Preparation (APDP) and now that it supports Android OS, I wanted to experience it first hand and capture all the caveats or gotchas. For those who are not familiar with the feature, enrolment time grouping was first introduced for Windows OS as part of Autopilot Device Preparation to speed up app and policy provisioning during device enrollment. The feature allows enrolment time grouping when you can add a Microsoft Entra security group in the enrolment profile so that devices are added to the group during enrolment, rather than after. This pre-knowledge of the security group that the device will become member of after enrollment enables Intune to deliver the configurations to the device quickly on enrollment, not only reduces post-enrolment latency but also improves productivity. If you don't configure enrolment time grouping, then Microsoft Intune can only determine the apps a...

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...