SOLVED

Device Compliance

Copper Contributor

Hi All,

 

Is anyone else see incorrect reporting of device compliance due to the "System Account"? As per Microsoft documentation:

 

"Windows 10 devices that are Azure AD joined may show the System Account as a non-compliant user. This is expected behavior and doesn't affect the overall device compliance."

 

This seemed to be working OK until about 2 weeks ago. We are using:

 

Hybrid joined device in a co-managed state - Windows 10 1709 and SCCM 1806. The slider for device compliance is set completely to Intune.

 

We end up with results like this:

 

compliance.png

 

and the device is then overall marked as non-compliant:

 

compliance2.png

 

This example is just ridiculous, as everything is actually compliant yet the System Account is marked Not Compliant and the device is as well.

 

Seems to be so inconsistent... and we are using CA policies which are locking out users.

 

35 Replies

@RobdeRoos 

 

Apart from this, Intune Device compliancy is way too unstable for me to use it as a conditional access.

Luckily we don't have thousands of users so I can manually check if one of the devices becomes incompliant. Usually it's just an intune bug.

@SamTeerlinck In many cases customers of ours have allready Intune implemented or partialy implemented. If I would be building an enviroment based on user assignment it would also impact devices that are allready in use by users.

 

Another case where I don't want user assignments is when we have a customer that has BYOD devices. Those devices are personaly owned and most of the times policies for BYOD and corporate owned devices will deffer from eachother.

 

A third example is development users versus "standard" users. But in that case it's not the policies that we don't want to target to users but just the applications.\

 

As long as we can't exclude devices on policies that are assigned to users, I need to have policies applied to devices most of the time.

Same issue here as well. We assigned the device compliance policy to a Windows 10 device group. Because we have multi user devices we cannot switch to user groups. Very often devices are marked as non compliant because of the system account. This is really annoying and we can't use Device Compliance within CA. Already opened support ticket but no help from there yet....

In our environment we use device assignment, too. (For device compliance and for device configurations.)

Some of the devices are only showing the compliance and configs for the user, some devices are showing them for user AND system account.

I really have no idea why. Anyone else?

 

And of course we have the same issues as everyone in here:

Some device configs are compliant for user AND system account, some configs are only compliant for the user.

BUT: When i have a device with user compliance marked as compliant and system account as non compliant, the whole device is marked as compiant in the GUI nevertheless.

@PatrickF11 

Hi, no I can't come up with any ideas either but I just wanted to post my screaming frustration with this scenario, it really is not good enough. We use device policies and fortunately we don't have that many machines, but we have compliance failures for System Accounts that should have no bearing on the situation. We also have situations where the System Account is Ok and the user account isn't! Go figure. 

@PatrickF11 

Same here - we thought device compliance was the best way to go, since we are cloud only, joined to AzureAD and other users could theoretically log in to other devices even though they hardly ever do that.  Win10 is at least v1803 on our machines.

 

But, like you and a few other posters here mentioned, some devices report complaint with both 'system' and user account, then others are marked non-compliant with either the 'system account' or user account not compliant.

 

@microsoft: 

being that we as system admins have no control over this 'system account', I'd like to request it officially removed from compliance checking, or at least see a check-box in the policy to exclude it.  Additionally, if assigning most policies to devices is not the preferred method, update the documentation to include explanations that system admins can understand, then we can make an informed decision as to which way we'd like to go for our organization.  Also add some explanation as to what the 'system account' is and how it is controlled/administered/used.

 

@Peter Osborne 

I have had some advice from MS Intune support and they say that in my case (a Bitlocker policy) it should be applied to the User and not the machine to solve the issue. It seems counter intuitive (to me anyway) to apply a policy which really only can apply to machines (it is encrypted or it isn't), to users who aren't going to be encrypted. Anyway, I am going to test this advice and see what happens, but it does feel like a 'fudge'.

If I remember correctly (and I might not), it seems a System A\C is created when the machine is added to the system (Intune?) before the primary user is created. The trouble is this System A\C can either be compliant or not, depending on something as yet unknown. One way to get rid of it is to remove the machine from AAD and re-join it. Simple enough in AD but not so in AAD, and anyway there is the extra gotcha in making sure that you've not named your machine with over 15 characters, which is allowed, (maybe 16, but just to be on the safe side) as it makes the process of creating a local admin that you need to log into when off the domain, impossible. Believe me, I have stumbled into that one which took days and was solved by accident and luck. 

Overall I can see the point of Intune, especially if you need to back up your security principles/management of devices with some sort of verifiable evidence. However, every policy is a complex slog and I have now started to create policies with only one or the minimum changes possible to keep things simple. Plus, on advice, I am now testing things that directly and obviously affect the user, one at a time, which makes it an even bigger slog. For example, I'm testing a policy to block access to Defender settings, so no-one can switch them off. One setting, which according to Intune has worked, but on the machine no change. Spotted in the (awful) documentation that for this setting the machine requires a reboot. Rebooted it, no change. So Intune says the policy is successful but the machine has clearly not got the message. Incidentally the 'Disable Autoplay' setting doesn't make any visible changes and the Autoplay button remains 'on' in the Settings panel. You would think this would be fairly easy to test before it is shown the light of day!!

@AJRoy Did you already tested assigning the bitlocker policy to users?

@PatrickF11 

Hi, just in the throes of testing it now. Although as most of our machines have Bitlocker installed, to properly test it I'll have to remove it and then see what happens. Currently it has succeeded on the two active machines that I'm the primary user on where Bitlocker is installed, so the process looks like it works. No sign of a System A\c but wasn't expecting one. I'll and keep you informed as things progress, remind me if I haven't. Regards.

@AJRoy I can imagine this would solve the system account issue because the policy isn't applied to the system account. But what if, on a shared device, 1 user breaks compliance and another user logs on before remediation can me done for that one user? I recon the device would still be marked as non compliant even though the second user is marked as compliant again.

 

That is the issue I have ran into in the past.

 

I believe what MS states is not the solution to the issue but a workarround.

@RobdeRoos 

Agreed. However I have just written a longish reply which, when posted, disappeared and I hadn't had the foresight to make a copy just in case! Hugely frustrating as I didn't really commit it to memory and it just goes to show how we lazily rely on everything working properly and not building in contingency when it unexpectedly fails. This is the modern way, as building in fail safes and stress testing is expensive and time consuming, Boeing could well be an example of this, we shall see. Anyway, I digress.

 

Whilst we are gradually building up the way we use Intune to manage our devices, I am finding it very frustrating. The casual approach to compliance\non-compliance is perplexing. In my particular case I fundamentally only need to know whether Bitlocker is on or off as this is a device centric issue. Getting a non-compliance because of a spurious System A\c is frustrating and cannot be left as a 'false positive' as any auditor would rightly flag it.

 

The way of managing devices in the modern world is changing especially around the security of data which, in Europe, the GDPR regulations have rightly highlighted. It is difficult enough getting users to modify their mindsets about data without the management systems being a little vague, as fundamentally I want to set up the device to a set of security principles, I want it to be monitored to ensure that it stays that way and I want it to be flagged if somehow it isn't, plus I want sensible error messages if things don't work, is that too much to ask?? 

 

With devices that are predominantly off site, reliance on the accuracy of monitoring tools is paramount, and it just doesn't feel that that's in mind.

 

 

 

 

 

The Admin Account Compliance problem wouldn't be solved when using bitlocker via user and not via computer assignment, isn't it?

@PatrickF11 

Hi, good point and I don't know. I'm only following instructions that I haven't completed yet. I'm getting into a real plate spinning exercise where all my attempts to apply some sort of MDM hit some sort of issue, usually in the area of confirming what I've asked is actually done. I spend a lot of my time dealing with MS Intune support, who are very nice, but can't really help when the product is not helping them, in my opinion of course, but it is frustrating. 

 

@PatrickF11 I believe it depends on if the policy is targeted to the admin user.

 

I still see devices showing as non-compliant and when I drill down to see I see User A as compliant for the Built-in Device Compliance Policy and User B non-compliant for the same Built-in Device Compliance Policy and also compliant for another policy.  So in a Pandemic world, I have to some how get this PC back to the User  B  so they can logon to clear the non-compliance they triggered a month or so ago when I enrolled them before I defined any policies?  Tell me it is not so.

 

-John

 

@RobdeRoos 

@John Greble 

 

Just found the same problem with a BitLocker Configuration Profile.  Machine is sitting next to me, and manage-bde says it is 100% encrypted.  For my user account, the status of the machines is succeeded however, for the same machine and the System Account it shows error so then the overall status is error.  Other machines have the system account and the user account as successful while one other machine just has the user account in error.  Other machines do not have any system account status listed.  And this is with just 6 machines targeted, 5 different states.  :)  I am targeting by a device group because I figured machines are encrypted, not people.

 

-John