12-06-2018 04:19 AM
12-06-2018 04:19 AM
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:
and the device is then overall marked as non-compliant:
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.
01-30-2019 01:51 PM
Did you ever get any response or resolution to this issue? we are having the same problem, doesn't seem to be any obvious resolution to the problem.
01-31-2019 08:30 AM - edited 01-31-2019 08:31 AM
Hope you are well. Unfortunately I have now left the company were I was deploying the above solution. However, as per the engineers onsite they have advised the issue is resolved with the January update to 1709.
Microsoft related the fault to this issue: https://support.microsoft.com/en-us/help/4469342/november292018kb4469342osbuild17763167
Despite this being an 1809 quality update:
"Addresses an issue with Microsoft Intune that causes devices to be incorrectly marked as not compliant because a firewall incorrectly returns a 'Poor' status. As a result, the affected devices will not receive conditional access compliance approval and may be blocked from access to corporate resources such as email."
So upgrade to the latest version of 1709 and see if it resolves the problem.
My issue was sporadic so I am guessing you will probably need to patch 50+ machines to truly see results.
01-31-2019 08:38 AM
Our workstations are all on 1803, rapidly upgrading to 1809. Interestingly, even though we already knew about the firewall issue and opted to exclude the check from our CA policies for the moment, most of the non-compliant machines are failing the AV check for the "System Account", even though the same check shows compliance under the user identity.
Perhaps, as is often the case, the code base will fix that as well for the machines that haven't yet upgraded to 1809, have to wait a few weeks to know for sure.
Thanks for the response though.
02-28-2019 02:21 AM
I also have issue, where we deploy Intune "Compliance policy" to "All Users", and is also effecting the integrated "System Account" and overall device compliance status.
Example is also, for shared devices (shared meeting room windows pc etc.)
We have latest Windows 10 - 1809 with all further updates
02-28-2019 06:56 AM
Going to +1 this, while Microsoft's own documentation does state that non-compliance for the System Account will not impact a machines' overall compliance, it can make proactively addressing compliance issues more difficult. For example, the Machine compliance report in InTune seems to be correctly ignoring machines where the non-compliance is the System Account identity, but the Power BI report pack that leverages the InTune data warehouse does not.
Ideally, if the compliance state of the System Account doesn't matter, it would be preferable that InTune ignore the identity entirely and didnt report on it.
03-18-2019 12:55 AMSolution
@Baljit Aujla I have figured out the solution.
When you have Compliance policy, assigned to All Users, it will reflect all your Azure AD users with those logins. But what about other (local accounts), like "system account" etc.., they are not compliant.
Resolution is to have another additional (same) compliance policy, assigned to Azure AD security group, and add those (shared) windows 10 devices to the group.
In that case, Compliance policy is assigned on device level to the specific device, and then "system account" does not cause the problem.
It is poorly documented, but this is something that Microsoft Support given to me...
03-21-2019 12:08 PM
05-09-2019 01:07 AM - edited 05-09-2019 01:10 AM
I also have this problem. Devices are set to AD security group "windows 10 only" devices.
When adding the laptops to Azure AD, they will get both the system account and user account.
Sometimes, there's no problem, but other times, things like "require bitlocker" only fail on the system account, and the entire devices gets marked as non-compliant!
Laptops are on 1809.
Still no fix?
06-06-2019 02:57 AM
I've had this problem too and I'll share my experience here:
If you assign policies to a device it applies the policies to all accounts on that device, including the system account (which will usually bring trouble for the compliance and such). I've not had any cases in which the system account was actually needed in Intune.
In most cases it is better to just assign the policies to the users and I usually use a dynamic group with all enabled users in it instead of 'All users'. If they then change device it will automatically migrate all policies and apps to that device as well, which will save us some time. Only when you work with special shared devices is assigning them to the device itself useful in my opinion (and even then there are some good cases for user assignment).
Simply reassigning the policies to users instead of devices won't make that system account go away in the portal though. You will have to delete the policy and make a new one, then assign it to the users only, then there won't appear a system account.
This is what I have found out from experience. I might be wrong but it has worked for me in the past. If someone wants to correct me about my policy assignment best practices, feel free to do so. I'm relatively new to Intune.
06-12-2019 01:32 PM
In my opinion there is a major!! flaw in compliance reporting by Intune. The problem we encounter with shared devices forced us to completely disable all compliancy checks for those devices.
The only solution is... let User 1 sign in again and remediate the device under User 1....
In my opinion this is absolutely unacceptable.... The solution is called DEVICE compliance. So how the beep is it possible that the DEVICE wont be set to compliant when a different user logs on to the device and remediates the issue that marked the device to be non compliant.....
For another customer of ours, an admin needed to logon to a users device and marked that device as non compliant. Result was the user wasn't able to access resources that required a compliant device.
Especialy with shared devices we cannot trust the Device Compliance solution the way it works now. This is a huge issue in a world where compliancy is one of the key components to secure access to resources.
06-13-2019 10:25 PM
@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.
08-28-2019 11:14 AM
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....
09-16-2019 03:11 AM
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.
12-04-2019 08:10 AM
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.
01-06-2020 12:43 PM
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.
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.
01-07-2020 06:58 AM
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!!
01-08-2020 01:16 AM
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.
01-08-2020 01:37 AM
@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.
01-08-2020 03:37 AM
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.
01-08-2020 03:57 AM - edited 01-08-2020 03:58 AM
The Admin Account Compliance problem wouldn't be solved when using bitlocker via user and not via computer assignment, isn't it?
01-08-2020 04:09 AM
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.