The Compliance Policy You Didn’t Know Was Locking Devices

Picture this: You’ve been carefully configuring your Intune policies. Everything looks good, and you’re feeling confident. Then, bam, your devices lock after just a couple of minutes of inactivity. Users are confused, support is blowing up, and you’re left thinking, “I didn’t set any lock settings like this… so what the heck happened?” Surprise, it’s not a bug, and it’s not something you missed in your configurations. The real culprit… a compliance policy that is using the DeviceLock CSP..

What’s Really Happening?

You were right to second-guess yourself. “I didn’t set this up… so what the heck is going on?” If you’re like most admins, you’ve probably been configuring your Intune policies, feeling confident that everything’s under control. But then, all of a sudden, devices across the company start locking after just a few minutes of inactivity. So, what went wrong?

Well, here’s where the wild goose chase begins. We started by checking the usual suspects: Security Baselines, Endpoint security Policies, and device configurations. Everything seemed fine. Nothing out of the ordinary. But then… we noticed something strange on the device itself: registry keys showing up in the PolicyManager\Current\device\DeviceLock path.

We didn’t set those devicelock settings. So, why were they there? That’s when we realized: this wasn’t an accident. It was the clue we were searching for.

The Hunt Continues: Finding the DeviceLock Setting

We dove deeper into the issue, and that’s when it clicked. The registry keys were linked to the DeviceLock behavior. As we investigated further, we found that the DeviceLock CSP relies on the Exchange ActiveSync (EAS) policy engine. That’s right, EAS was silently enforcing security settings.

The DeviceLock CSP utilizes the Exchange ActiveSync (EAS) policy engine. With the DeviceLock CSP relying on EAS, it was clear that the corresponding registry keys in the control\eas\policies path were also showing up.

It wasn’t just syncing email and calendar settings; EAS was also enforcing device security policies, including the MaxInactivityTimeDeviceLock setting, which controls how long a device can stay idle before locking. And just like that, all our devices were locked into a 5-minute inactivity timeout. Users had to enter their PIN far sooner than expected.

The Hidden Culprit

Once we connected the dots, it all made sense. The MaxInactivityTimeDeviceLock setting wasn’t configured manually by us, EAS was pushing it out. Want to know what triggered it? It was automatically deployed the moment a specific Device Security compliance policy was applied.

Take a look at the above compliance policy in question: it had a setting called “Maximum minutes of inactivity before password is required,” set to 1 minute. The second this compliance policy was applied, EAS kicked in and pushed these settings to all devices. Even though you didn’t configure the inactivity timeout yourself, EAS took care of it, syncing the setting across the entire fleet. That’s why all your devices started locking after just a minute of inactivity.

EAS and the DeviceLock CSP

This is where EAS really shines.The DeviceLock CSP uses EAS to enforce device lock settings, like password complexity and inactivity timeouts. When you configure a compliance policy involving device lock settings, EAS doesn’t just check for compliance; it actively pushes and enforces(remediates) those settings across all devices in the fleet.

For example, when you set password length and complexity rules, EAS ensures that all local user and administrator accounts are marked to change their password at the next sign-in to meet the complexity requirements. The same mechanism works with device lock settings, applying those policies to every device in the fleet without requiring manual intervention.

So, while the DeviceLock CSP is all about managing security-related settings on the device, EAS acts as the enforcer, making sure these settings are applied across the board.

Best Practices and How to Avoid Surprises

Now that we’ve solved the mystery, let’s talk about how to avoid this kind of surprise in the future. Here are a few best practices that will help keep your devices secure without triggering unexpected behavior:

1. Review compliance policy settings carefully: Before rolling out any compliance policies, especially those involving security features like lock screens or inactivity timeouts, double-check exactly what they will apply to your devices. Some of them might trigger automatic enforcement.
2. Understand how EAS works with compliance policies: It’s crucial to understand that EAS doesn’t just check for compliance; it can also apply settings to your devices. If your compliance policy involves device lock settings, be prepared for EAS to sync those across your entire fleet.
3. Audit device behavior: If devices are locking unexpectedly, dive into the EAS sync logs and registry settings to see what’s been applied. This will help you understand exactly what changed and why.
4. Test before full deployment: As always, test your compliance policies on a small set of devices before deploying them across the company. This allows you to catch any unexpected behaviors before they affect everyone.
5. Adjust the settings if needed: If you don’t want devices locking after just a few minutes, go back to your compliance policy and tweak the inactivity timeout settings. Make sure they align with your organization’s needs.

Conclusion: Wrapping It Up

So, there you have it, the mystery behind the weird lock screen issue is solved. It wasn’t a bug, and it wasn’t a random glitch. It was a Compliance Policy, quietly enforcing device lock settings pushed by your compliance policies.

The key takeaway here? Don’t just set and forget your compliance policies. Understand how they interact with other features like EAS, and always double-check what settings might be silently enforced in the background. A little upfront knowledge can save you from a lot of user complaints and support tickets down the road.

Stay tuned, there’s always more to uncover when it comes to managing devices in Intune, and who knows what other surprises might be lurking just around the corner!