Forum Discussion
Device Config Policy vs Device Compliance Policy
Hi Stuart,
compliance settings are mostly used in combination with conditional access to check a device for certain settings and then set a compliant flag or not. It can also be used just for reporting if certain settings are set like BitLocker. So it's a kind of simple check and remember if several compliance policies have the same setting, they are evaluated and the most restrictive value counts. Pin 4 and Pin 6 in two compliance policies, then pin length 6 is enforced.
Configuration policies instead are the way to configure and not to check. E.g. set creation of something like passwords to deny simple passwords. Its not a check, it will enforce the setting in the password example during creation of the password. If two configuration policies have same setting they are in conflict and the setting will not be applied.
Hope this helps in you decisions.
best,
Oliver
Hi Stuart,
compliance settings are mostly used in combination with conditional access to check a device for certain settings and then set a compliant flag or not. It can also be used just for reporting if certain settings are set like BitLocker. So it's a kind of simple check and remember if several compliance policies have the same setting, they are evaluated and the most restrictive value counts. Pin 4 and Pin 6 in two compliance policies, then pin length 6 is enforced.
Configuration policies instead are the way to configure and not to check. E.g. set creation of something like passwords to deny simple passwords. Its not a check, it will enforce the setting in the password example during creation of the password. If two configuration policies have same setting they are in conflict and the setting will not be applied.
Hope this helps in you decisions.
best,
Oliver
- arnabmitra
Microsoft
Important note - During a policy conflict, If the conflicting settings are from an Intune configuration policy and a compliance policy, the settings in the compliance policy take precedence over the settings in the configuration policy. This happens even if the settings in the configuration policy are more secure.Thanks, this was helpful. I have a few more questions...
1) How do I create a compliance policy that the device MUST be Azure or Intune joined to be able to used the Desktop Apps?
2) In general, I think Compliance Policies vs Configuration Policies are confusing....so I plan on just using Compliance Policies with Conditional Access....so how do I make it so that they cannot access resources unless they are compliant?
Hi reditguy,
I think what you are looking for is a set of Conditional Access policies to ensure your devices are compliant before accessing your cloud services. There is a checkbox to grant access only for compliant devices. This way you can create a Conditional Access policy to protect your services and allow access only to devices marked as compliant.
The evaluation to be compliant is simple the device needs to be Azure AD joined and Intune enrolled (i would recommend MDM auto-enrollment). As soon as the device gets joined and enrolled it receives the compliance policy and evaluates its status, e.g. Require Password, enforce encryption, OS version etc. sends the result back and get the flag for compliant or not depending on the evaluation.
The configuration policies are mainly for configuration, for example to turn on or off certain features of Windows 10. As an example: Turn of camera or Cortana or configure a start menu.
best,
Oliver
arnabmitra - In our Intune environment, we have the same password settings in compliance policies and in device configuration profiles. I made a change to the compliance policy and not to the device configuration profile, but the change did not hit my device until I made the change to the device configuration profiles. In my case, compliance policy settings did not take precedence, it was the other way around. Can you explain?
Roy_Kang Compliance policies always take precedence over configuration profile settings. Changing the password requirements for the compliance policy only affects whether or not the device is marked as compliant, plus any additional actions you've defined in the policy.
Once the device is marked accordingly, refer to this link to see how it affects each platform:
If a device is marked as non-compliant...
For iOS/iPadOS it is remediated. The device operating system enforces compliance.
For Android it is quarantined. The device operating system doesn't enforce compliance.
Hope this helps.
I find it confusing that not all compliance policy settings are "simple check" as you say. Example is "Maximum minutes of inactivity before password is required" (Android). Rather than just checking if the configured time is within the value set for compliance, the setting acts like a configuration and applies a restriction in the "Lock screen" menu.
arnabmitra is correct that settings in the compliance policy, applying the configuration rather than just assessing, take priority over the equal settings in the configuration profile (you get "Not applicable" for the configuration if it is in a conflict with the compliance setting).
That I believe can easily be a source of frustration, because the compliance policy assignment scope can be different to the configuration profile and it can be overwriting settings.
