Windows BitLocker and passcode policy conflicts with Google Workspace or LDAPSolved

Hello @ame-lie ,

For the BitLocker issue, Windows built-in Device Encryption must be turned off before applying the BitLocker policy from Hexnode UEM. BitLocker cannot take over properly while Device Encryption is already active.

On the Windows device, navigate to the Settings or Control Panel and turn off any active Device encryption.

After that, reapply the BitLocker policy from Hexnode UEM so encryption can be enabled and the recovery key can be escrowed correctly.

Regarding the Passcode policy:

• Removing the Passcode configuration from the assigned policy stops future password change prompts once the device receives the updated policy.
• It does not revert passwords that users already changed while the old policy was active.
• Devices showing Pending for the previous policy generally did not execute that passcode payload yet. If they receive the updated policy without the Passcode configuration, they should not be prompted to change passwords because of that removed payload.

Regards,
Simon Scott
Hexnode UEM

Okayy got it. Also, does removing the local passcode policy affect Google Workspace sign-in at all? The devices use Google Workspace as the identity provider, and I don’t want to break that login flow.

Removing the local Passcode policy does not change Google Workspace credentials. It only removes the local Windows account password requirements enforced by that Hexnode policy, such as complexity or expiration rules.

If authentication is handled through a cloud IdP such as Google Workspace, the cloud credentials remain managed by the IdP. Hexnode’s local Passcode policy does not sync password changes back to Google Workspace.

In our setup, Google Workspace login is enabled, but LDAP password synchronization is not configured for macOS. Would users have one password or two?

On macOS, if LDAP password synchronization is not configured, users will typically have two separate passwords:

• Google Workspace password: Used for cloud IdP authentication, such as the initial Hexnode Access login flow.
• Local macOS password: Used for local system actions, FileVault unlock, screen unlock, preference changes, and other macOS account-level authentication.

A macOS Passcode policy in this setup applies only to the local macOS account password requirements. It does not update, sync with, or enforce changes on the Google Workspace password.

The main reason I was using Passcode policy was compliance. I need Windows devices to lock automatically after a few minutes of inactivity, but I don’t want to interfere with LDAP/domain credentials. Is there a cleaner way to do that?

For that use case, use the Windows Screensaver policy instead of the Passcode policy.

In Hexnode UEM under Windows policies, go to: Configurations > Screensaver. Then configure:

• Start screensaver after required minutes of inactivity, such as 5 minutes.
• Require Password to unlock screen.

This enforces an inactivity lock without changing password complexity, expiration, or credential rules. It is the recommended approach when the goal is idle-time locking and you want to avoid conflicts with LDAP/domain authentication.

You can keep the macOS Passcode policy if your goal is to manage local macOS password requirements, but for Windows idle lock compliance, the Screensaver policy is usually the better fit.