The mysterious unknown account: Threat or harmless bug?

In the process of performing the usual necessary cleanup after installing FCU (fixing the various DCOM errors due to improper permission settings) I was reminded of this particular situation again. I was hoping that perhaps the collected expertise in this forum could shed some light on this potentially serious problem.

In a nutshell, it appears that for certain hardware configurations (see below), there is an unusual SID that is being created which the system does not recognize, so it is listed as an "Unknown Account". This could be a minor nuisance, except for the fact that this SID is assigned permissions at top-level registry keys and then propagates down to a vast number of system objects. As a consequence, this unknown account has permissions to a large number of objects and processes, including the permission to launch and activate almost any DCOM object on the system.

The SID of this account is S-1-15-3-1024-1065365936-1281604716-3511738428-1654721687-432734479-3232135806-4053264122-3456934681, and there is some indication (from two posts by Sonya here and here) that these security entries are created during the installation of NVidia video drivers. Now, like I said, this could just be a minor cosmetic nuisance, except it may not be.

First of all, the SID above does not look like a standard, properly formed SID. Second, I have seen some references that Windows allows processes to generate SIDs of that kind "on the fly" for special purposes, such as sandboxing: You create an SID for a non-existent account for a process, which means that such a process does not have access to any of the regular system objects except those with permissions for "Everyone", I think.
If that is correct, and if a process can create such SIDs freely, then the issue we have with this NVidia-generated SID is that it cracks our systems wide open to any process that can generate this SID for itself. In other words, we would be looking at a catastrophic security hole. Indeed, the poster I have quoted above (Sonya) reports that NVidia software seems to be starting all sorts of processes using just this mechanism, including remote connections of all sorts. In one of her posts she goes as far as referring to this as "theft ware".

So, here are my questions:

• Can we confirm that this SID indeed "belongs" to NVidia? Does everyone with NVidia drivers have these? Do others not have them? Also, as far as I can tell this SID is only generated on Windows 10 systems.
• Since the SID in question is defined for top-level registry keys and propagates down from there, it could be fairly easy to get rid of it: Simply remove those permissions from HKLM, HKCU, etc., and the offending permissions should be (almost?) all gone. The question is, will that have any adverse consequences? Note that, since the SID in question is illegal, once I remove those permissions I cannot recreate them. If removing them breaks something, then I'm looking at a reinstall...
• Are my concerns above valid? Perhaps they're not, and other than a cosmetic issue those permissions for the offending SID don't really matter. If Sonya is correct, however, this may not be the case.

Here's hoping somebody knows more about this...

I forgot one additional possibility: Perhaps permissions for that mysterious SID are in fact somehow needed (at least on systems with NVidia drivers?). In that case it would of course be unwise to delete these permissions. Of course, the question still remains if indeed only NVidia-based systems use that entry. Unfortunately the only Windows 10 systems I can get my hands on right now do have NVidia cards, so I cannot check that hypothesis.

I have that SID in registry (values and permissions) and only have Intel HD so it is not to do with NVidea.

I read some speculation that it was due to leftovers from defaultuser0 not being deleted correctly during install. I don't know whether it is a bug or deliberate - it seems unclear.

Interesting. So it's not an NVidia thing. Thanks!

lx07 said:

...I read some speculation that it was due to leftovers from defaultuser0 not being deleted correctly during install. ...

You can get the same leftover (an unknown SID with permissions here, there and everywhere) if you ever created another local user account, then deleted it later. I have often done this, so I see a lot of 'unknown users'.

Remove the unknown account from the permissions or leave it there, either way it has no impact as the SID doesn't represent an actual account any more.

Well, this one may be different. Notice that this particular SID is not a user account SID, it's what is called an "application SID" in order to specify permissions for application containers. Windows 10 is using these all over the place, which can complicate things considerably. The fact that this is listed as an "Account Unknown" does not necessarily mean that it's not needed. As a matter of fact, in the case of the SID above I have seen reports of people having deleted the SID from permissions, only to end up with a broken system (Edge crashing on launch, etc., etc.) Fixing such a system is possible, but not straightforward, and will require some PowerShell wizardry...

Pirx said:

Well, this one may be different. Notice that this particular SID is not a user account SID, it's what is called an "application SID" in order to specify permissions for application containers....

Apparently an Application SID is used during an install if the install needs to restart an app or sevice after completing.

The errors ”Application SID does not match Conductor SID” will be generated whenever the user account the service is being run under does not match the user account used to launch the setup instance. The term “Conductor” refers to the MSI setup engine. It also appears that if the setup is executed with elevated permissions (Run As Administrator), then the SID check is bypassed. This behavior is by design and is intended to prevent the malicious restarting of critical system services.

https://community.spiceworks.com/top...server-2012-r2