Account Unknown(S-1-15-3-65536-1888954469-739942743-1668119174-2468466756-4239452838-1296943325-355587736-700089176)

Hi, Chow. This particular sid is probably legit, it looks similar to “capability sid”. But I strongly agree that there must not be “Unknown” actors in the system security configuration.

If you are willing to change this, please vote for the ticket(s) I created on FeedBack Hub (link in the comment above, on 18 May), or create your own ticket(s)

By the way, I completely agree with your estimate of Dave's words.

What a bunch of BS, sounds pretty scripted DAVE!! Having this on my pc is giving someone such as yourself 100% access to my pc anytime they wanted to look at whatever they wanted undetected. Special access...pfffft. The owner of the unit should be the only one with any access at all. I've even had the remote access removed and blocked from my laptop and sure enough, 2 days later it was back on...can you explain that? What would happen if this "safety program" was removed? Never mind, I know your answer...why was this "safety program" not installed with windows prior to 10 and 11?

I have created tickets on Microsoft Feedback Hub for this issue yesterday. Please upvote if you want this to be fixed.

1. Stop adding “Account Unknown” in security ACLs (https://aka.ms/AAkv45y)
2. Ntfs Audit misses some “Change permissions” events (https://aka.ms/AAkvbq6)
3. Windows reverts user-directed security ACL for c:\ on the quiet (https://aka.ms/AAkvia0)

I've noticed a few fascinating details you may want to know, folks.
.

1. the sid in question comes with windows 11 22H2 installation image.

How to verify. Extract windows from Win11_22H2_English_x64v1.iso/sources/install.wim, on disk, say, v:\ :

> Dism /apply-image /ImageFile:install.wim /index:6 /ApplyDir:v:\

… then S-1-15-3-65536-1888…9176 will already be in v:\ ACL. Image index doesn't matter: home/pro/edu/…, all have S-…9176 in the root of system drive.

So any PC with windows 11 22H2 should have this sid in a system drive root.
. 2. I removed S-1-15-3-65536-1888…9176 from system drive ACL four of five times, but each time it resurrects after reboot.
. 3. You may wonder, who reverts S-…9176 back into the system drive root. Me too. I've set up audit entry in c:\ ACL to track "Change permissions" events.

Guess what? The audit shows me removing S-…9176 from the system drive root, but does not show who and when adds S-…9176 back.

.

So, we have three independent problems here:

1. MS pollutes security space with “Account Unknown (S-…)” SIDs since … windows 8?

This wasn't so apparent until win11 22H2, when some MS guy sticked such eye-catching unknown directly into the root of system drive.

The problem with unknowns is: the legit and not legit unknowns are undistinguishable. And even legit unknowns are impossible to audit.
. 2. MS fools us when we click “Remove” ACE button in the ACL editor. If “remove” succeeded then the windows promise is: ace has been removed. That is not the case for S-…9176 in the root of system drive.
. 3. NTFS audit is either broken or also fools us, because it does not show who adds S-…9176 into the system drive.

.

Applicable screenshots attached.

Setting up audit, pic.1:

Setting up audit, pic.2

Audit result, after two S-…9176 removal and two reboots. Two events:

authpolchg is a custom view with “Microsoft-Windows-Security-Auditing” source and not related to permissions change events excluded.

Both events are identical, showing only removing S-…9176 from ACL:

Windows version: Windows 11 Pro, English, x64, 22H2, build 22621.1635:![Image](https://learn-attachment.microsoft.com/api/attachments/41dcc235-5e95-4e1b-85c7-0eda7c50eb4d?platform=QnA

Here's some additional info on this subject.

Some SIDs do not resolve into friendly names | Microsoft Learn
https://learn.microsoft.com/en-us/troubleshoot/windows-server/windows-security/sids-not-resolve-into-friendly-names