Registry permissions after 1703 update - Unknown Account RRS feed

  • Question

  • Under many registry locations, specifically Computer\HKEY_LOCAL_MACHINE\SOFTWARE, there is a strange account with read access, Unknown Account {S-1-15-3-1024-1065365936-1281604716-3511738428-1654721687-432734479-3232135806-4053264122-3456934681}. This account appeared after I updated my PC to 1703 and is included on any clean install of 1703 I have tested. 

    It does not connect to an active account however when I remove this account from the permissions list (in test systems) Edge ceases to function and crashes before fulling loading. As the account is unknown I cannot add it back to the permissions on the registry key and must reinstall so the account has access again. 

    Where I work security on this and other keys is controlled by Group Policy from 1607/1511 which we have updated with the policies from 1703. The policy sets specific permissions on registry components and inherits them down to some degree. As the account is unknown it cannot be added to the policy and any 1703 install that picks up the policy requires a reinstall to resolve issue with Edge failing to launch. We have creatd a test OU and policy that does not include the permissions changes and that policy implements without issue.

    We use software that requires specific permissions on the above registry component or so I have been told by the admin who manages that software. In order to implement 1703 we need to resolve this issue with the unknown account and the permissions change either by adding the unknown account to the Group Policy or removing whatever it is needed to allow Edge to launch.

    This also leads the deeper questions of what this account is for, when it is created and removed, what other permissions it has, why it is necessary to keep around, and similar. 

    If I am missing something please let me know. I am happy to privide more information about our Group Policy settings, software, and other items.

    • Edited by SP-JCI Monday, April 24, 2017 7:31 PM
    • Edited by Carey FrischMVP Thursday, February 15, 2018 9:31 AM Shorten Title
    Monday, April 24, 2017 7:29 PM

All replies

  • Hi,

    If other App has same issue?

    You may need to enum all ACLs for your C:\Program files folder can see if the account you mentioned has some special permission on which folder. 

    From Systernals you can download this tool: AccessEnum

    Please know that We should have certain SID which refer to Security manager: 


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Friday, April 28, 2017 7:20 AM
  • I have this same issue - home computer, it is NOT supposed to be a client or server.  I am not a developer, or an IT administrator.  I know a little about objects and permissions, enough to know I don't know enough.  I have clean installed with the media creation tool from USB - at one point I even used Samsung Magician to completely erase one of my SSD's before re-installing the OS but nevertheless these strange phantom "users?" i guess with their permissions somehow creep in.  I would appreciate some guidance!
    Thursday, February 15, 2018 9:13 AM
  • I've found the same mysterious 'unknown account' on my Windows 10 laptop (Account Unknown(S-1-15-3-1024-1065365936-1281604716-3511738428-1654721687-432734479-3232135806-4053264122-3456934681).  I've been researching, and trying to fix, 10016 system errors on my laptop for the past week.  I am finally down to 2 or 3 fixes, but during all of my research I've noticed that this 'unknown account' pops up periodically.

    WE ARE NOT ALONE!  I have not kept track of the number of people impacted by this 'unknown account', but I can easily state that this topic has come up a lot.  I'm thinking that the average user has no idea what a 10016 error means, nor would a normal user ever think to fix these error (until they realize their performance is slow, or they have slow startups).  At this point, I think most people will have a technical person perform the cleanup of their device.

    With that said, I'm thinking this 'unknown account' exists in every Windows 10 device that has recently upgraded.  Most people simply have no idea what this is or how to fix the problem.

    IT WOULD BE WONDERFUL, if Microsoft actually acknowledged that the 'unknown account' problem exists on devices that upgraded to Windows 10 xxxx edition, AND actually create a 'fixit' app (or implement some other simple procedure/update)  to help normal, every day users, remove/fix this problem. (This is one of my gripes with Windows 10... A user sees their computer slowing down, and they have no idea what to do, so they spend good money having to have a technician fix and speed up their system).

    I'm not a super techie guy, but I can search online and eventually I can figure things out (or I create a huge mess).  Please, if anyone finds a good, working solution, keep us posted.

    kind regards,

    Wednesday, April 4, 2018 1:21 AM
  • I have identified this exact same account on a fresh install of Windows Server 2016.  This showed up rather early while trying to configure/define a secure baseline for deployment of additional systems.  Unfortunately, having an 'unknown account' in the registry is a violation of several security recommendations.  So Microsoft needs to address this situation.  Why is this account being granted rights to registry settings on a clean server, and if it is needed, why is it not being correctly identified by Microsoft's own tools?
    Thursday, November 8, 2018 7:48 PM
  • All these "strange" SID starting by "{S-1-15-3-1024-" are in fact pseudo accounts created for AppX containers (each AppX has its own SID).

    Unfortunately, there's no simple way to find which AppX is associated to them (you need to check the manifests for each AppX)

    And the Windows explorer UI currently offers no simple resolver that would perform this check automatically).

    Unfortunately as well, these authorizations are often kept on the system, even if the AppX are no longer installed, because they remain on NTFS volumes (and frequently as well in the user's registry) after they were unmounted and then the AppX was uninstalled.

    We lack a way to clean these spurious permissions that are left over: don't blindly delete these permissions, or some of the critical AppX needed for Windows itself will no longer work.

    I think that several cleaner tools (including one made by Microsoft itself) should allow fixing the invalid SIDs found in NTFS volumes or in the registry, that were associated to various AppX that were uninstalled or disapproved.

    And anyway the Windows Explorer and registry editor should recognize these SID and should allow us to identify the AppX containers correctly, instead of lloing them up only in the local users database or in the domain's user database.

    I found a way to kwno which AppX is associated to the SID in this location of the registry:


    Each AppX here has a key containing these values

    - ApplicationFlags (DWORD)

    - AppPackageType (DWORD)

    - CapsSid (BINARY, variable length)

    - EnterpriseID (DWORD)

    - PackageSID (SZ) --->> This is where you'll find SIDs starting by "S-1-15-2-", but this identify the source of the package, and not the local SID of the container where it is installed.

    Apparently we need to look in the user's folders where the package was installed to find their manifest containing the authorizations granted "by the user" when he installed these apps, and each one of these authorizations created a SID for the authorized capability.

    So we need an tool to explore the AppX capabilities: the "S-1-15-3-*" SID are not just identifying the AppX, but a specific capbility in the AppX. Unfortunately, when AppX get updated, some of their previous capabilities get removed (or changed to more powerful capabilities), but the capability SID they used are leaving traces polluting the filesystem and the registry (with some consequences, such as creating deies of accesses or generating failures in system backups, because some user rights could not be archived or some files were unexpectedly not granted any access, not even by the local  system account or the TrustedInstaller account).

    These damned unmanageable SID are creating lot of problems over time, they pollute everything and if AppX were really installed as "containers", the container should sandbox them and should anot pollute the local filesystem or the registry, the container should have its own internal store.

    So this is clearly a design bug in the AppX system of containers: AppX are not really safe containers.

    • Edited by verdy.p Saturday, December 1, 2018 3:20 AM
    Saturday, December 1, 2018 2:58 AM
  • The AccessEnum tool (from Sysinternal) can only identify SID defined in the local users database or in the connected domains database.

    It does not identify the SIDs used by AppX containers: they are just displayed as "???" (i.e. unknown users) or the acces rights are not even identified (we get "Access denied" instead of the list of other local users that have read/write access rights granted or denied !

    • Edited by verdy.p Saturday, December 1, 2018 3:28 AM
    Saturday, December 1, 2018 3:26 AM
  • Thanks for the confirmations Verdy. 

    Doesn't exactly help us out of our concerns, but that is definitely useful info, and also helps validate that I am not being paranoid!  :)

    Monday, December 10, 2018 7:53 PM