09-20-2018 01:56 PM
09-20-2018 01:56 PM
Some clarification required on when to use Config Policy vs Compliance Policy or both.
Is there any point in creating a device config policy when a similar compliance policy is set to do the same, such a passwords?
09-21-2018 12:32 PMSolution
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.
09-21-2018 03:00 PM
01-15-2019 07:43 AM - edited 01-15-2019 07:46 AM
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?
01-15-2019 08:21 AM
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.
01-15-2019 08:26 AM
Thank you....that is how I have it set in CA. So to confirm....if a user tries to for example setup an outlook profile or OneDrive on their office PC or BYOD/home PC....CA will tell that they cannot do it because their PCs are not compliant, and by default (because I see no specific setting for this), they cannot comply with the policy until the PC is joined to Azure AD and/or Intune? Is this by default or a specific setting somewhere?
01-15-2019 08:34 AM
Yes you need to have a device object that can be marked as compliant and you get this device object only during register/join/enroll. The only setting for the default behavior of marking as compliant is about compliance policy is assigned or not, see here:
01-15-2019 09:00 AM
So if I have it sent to "Not Compliant" in the section you sent me and have MDM user scope set to All per this link:
Then users will NOT be able to use or setup outlook/onedrive/Office apps on their devices UNLESS it is marked compliant, correct? FYI, I also have MFA enabled to enroll in Intune/Azure for extra security.
01-15-2019 09:09 AM
Basically yes but you need to make sure the user is only using modern authentication and not legacy auth because legacy auth will not be handled by CA. So SPO must be configured to use modern auth and in addition you need a policy to control EAS which uses legacy auth as well, see here: https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/conditional-access-for-ex...)
To block legacy authentication see here: https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/block-legacy-authenticati....
01-15-2019 09:12 AM
Thanks! I was told by MS Support that Modern auth is not enabled on my tenant (but I thought it was enabled by default?), and if I enabled that and disable Basic Auth, I would have to recreate everyone's Outlook profile even thouogh they are all on Outlook 2016+
01-15-2019 09:21 AM
the default of the tenant is depending on the time of creation. Newer tenants have it disabled by default, older tenants not.
01-15-2019 09:22 AM
Got it...last question (for now), so since I do have to enable Modern and disable Basic....is it true I will have to recreate Outlook profiles and/or reinstall Office?
01-15-2019 09:24 AM
if you are using Office 365 ProPlus (2016) and EXO and the default Office settings with Autodiscover etc. your clients should already use modern auth and you don't need to re-create anything.
01-17-2019 12:06 PM
Ugh, not liking Intune right now.....we have a password policy set up in Compliance policy (12 characters, 1 non-alpanumeric required, 15 minute timeout), applied to a user group....we do not have any password policy set it configuration policy.
For some reason, MANY devices are giving an error of password length not being long enough even though it is over 12 characters (again, happening to many users).
So I am a bit confused on password policies....does it apply to ALL users account on a PC? We have some users that are logging into their PCs using local AD or local PC accounts, but PCs are joined to Intune. For some users, their local AD accounts for example are less than 10 characters (but again, their O365/Azure accounts are over 12), and it shows Compliant! But for others...it shows password is too short.
UGH, and thanks in advance.
04-08-2019 12:40 AM
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.
@Arnab Mitra 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.