windows-itpro-docs
windows-itpro-docs copied to clipboard
MicrosoftDocs
Resetting service ACLs is dangerous!
[Enter feedback here] In step 4b, the article claims it will reset the ACLs for the services BITS and Windows Update to their default value. I just checked Windows Server 2016 and Windows Server 2019 default values and both deviate from the alleged "default values" in the article. So it will not reset the ACLs to the default values but instead it will change the default values. I think the risk is higher to break something by changing the service ACLs. Not sure if Microsoft would support changing from default values.
Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.
- ID: 886426b5-8548-1cfc-ccd2-fd03e549c967
- Version Independent ID: 599aea76-47e4-dccc-799c-2d8acf549546
- Content: Windows Update - Additional resources - Windows Deployment
- Content Source: windows/deployment/update/windows-update-resources.md
- Product: w10
- Technology: windows
- GitHub Login: @jaimeo
- Microsoft Alias: jaimeo
@arcarley @Alice-at-Microsoft can either of you advise? Or connect with someone who can?
Unfortunately outside of my area as well...
From: Alice-at-Microsoft @.> Sent: Friday, November 5, 2021 9:41 AM To: MicrosoftDocs/windows-itpro-docs @.> Cc: Aria Carley @.>; Mention @.> Subject: Re: [MicrosoftDocs/windows-itpro-docs] Resetting service ACLs is dangerous! (Issue #10076)
@jaimeohttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fjaimeo&data=04%7C01%7Carianna.carley%40microsoft.com%7Cb70304fcd57344a3547808d9a07b1114%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637717272719986541%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=rrzJ6D4gqPl51M8T6Y19hpJhMdxHCo7Mejl9lCclu40%3D&reserved=0 @arcarleyhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Farcarley&data=04%7C01%7Carianna.carley%40microsoft.com%7Cb70304fcd57344a3547808d9a07b1114%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637717272719996507%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=a6j1DJ8vQ2FtUfJZXUcoZFdPwHCT6qyLvJ1%2FTP7lBpk%3D&reserved=0 Unfortunately, I don't know.
You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoftDocs%2Fwindows-itpro-docs%2Fissues%2F10076%23issuecomment-962047216&data=04%7C01%7Carianna.carley%40microsoft.com%7Cb70304fcd57344a3547808d9a07b1114%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637717272720006467%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=unxoT6%2FMN4d5%2BQFDQznZasVFtDahfnvLLzX6G6ACArw%3D&reserved=0, or unsubscribehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAMNY66LIABJXMUS6XNUCIM3UKQJLHANCNFSM5HNLDKOQ&data=04%7C01%7Carianna.carley%40microsoft.com%7Cb70304fcd57344a3547808d9a07b1114%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637717272720006467%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ecv4CXC0B3ZS0qVIy8Rf4OMyYxPRAtl86bMrz1AEPyc%3D&reserved=0. Triage notifications on the go with GitHub Mobile for iOShttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapps.apple.com%2Fapp%2Fapple-store%2Fid1477376905%3Fct%3Dnotification-email%26mt%3D8%26pt%3D524675&data=04%7C01%7Carianna.carley%40microsoft.com%7Cb70304fcd57344a3547808d9a07b1114%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637717272720016419%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=GFm0xqukvKIkX9hdbT%2Fipt%2FH8JdGza9hXZyhvVlqNQU%3D&reserved=0 or Androidhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fplay.google.com%2Fstore%2Fapps%2Fdetails%3Fid%3Dcom.github.android%26referrer%3Dutm_campaign%253Dnotification-email%2526utm_medium%253Demail%2526utm_source%253Dgithub&data=04%7C01%7Carianna.carley%40microsoft.com%7Cb70304fcd57344a3547808d9a07b1114%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637717272720016419%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ZPEmmZNf0wLMUMke5E2N%2Bc9sO7c%2FF4MjpWA86tIdMDU%3D&reserved=0.
Let me just add some more details. A service ACL controls which user account can for instance can stop or start a service or change the service configuration (https://docs.microsoft.com/en-us/windows/win32/services/service-security-and-access-rights#access-rights-for-a-service).
Let's check the Windows 10 default ACL for the Windows Update service. I am running Windows 10 Enterprise 21H1:
PS > Get-CimInstance -ClassName Win32_OperatingSystem | Select Caption
Caption
Microsoft Windows 10 Enterprise
PS > [System.Environment]::OSVersion
Platform ServicePack Version VersionString
Win32NT 10.0.19043.0 Microsoft Windows NT 10.0.19043.0
The default ACL looks like this in SDDL format:
PS > sc.exe sdshow wuauserv
D:(A;;CCLCSWRPLORC;;;AU)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SY)
Let's convert it to a readable format:
PS > $WuauservSddl = (sc.exe sdshow wuauserv)[1] PS > $WuauservAcl = New-Object -TypeName 'System.Security.AccessControl.CommonSecurityDescriptor' -ArgumentList $false,$false,$WuauservSddl
PS > $WuauservAcl.DiscretionaryAcl | Select SecurityIdentifier,@{Name='NTAccountName';Expression={((New-Object -TypeName System.Security.Principal.SecurityIdentifier($_.SecurityIdentifier)).Translate([System.Security.Principal.NTAccount]).Value)}},AceType,AceFlags,AccessMask,@{Name = 'AccessMaskString';Expression={[Flags()] Enum EnumAccessMask{SERVICE_QUERY_CONFIG=1; SERVICE_CHANGE_CONFIG=2; SERVICE_QUERY_STATUS = 4
SERVICE_ENUMERATE_DEPENDENTS=8; SERVICE_START=16; SERVICE_STOP=32; SERVICE_PAUSE_CONTINUE = 64 SERVICE_INTERROGATE = 128 SERVICE_USER_DEFINED_CONTROL = 256 DELETE = 65536 READ_CONTROL = 131072 WRITE_DAC = 262144 WRITE_OWNER = 524288 SERVICE_ALL_ACCESS = 983551
} [EnumAccessMask][int]$_.AccessMask} }
SecurityIdentifier : S-1-5-11 NTAccountName : NT AUTHORITY\Authenticated Users AceType : AccessAllowed AceFlags : None AccessMask : 131229 AccessMaskString : SERVICE_QUERY_CONFIG, SERVICE_QUERY_STATUS, SERVICE_ENUMERATE_DEPENDENTS, SERVICE_START, SERVICE_INTERROGATE, READ_CONTROL
SecurityIdentifier : S-1-5-18 NTAccountName : NT AUTHORITY\SYSTEM AceType : AccessAllowed AceFlags : None AccessMask : 983551 AccessMaskString : SERVICE_ALL_ACCESS
SecurityIdentifier : S-1-5-32-544 NTAccountName : BUILTIN\Administrators AceType : AccessAllowed AceFlags : None AccessMask : 983551 AccessMaskString : SERVICE_ALL_ACCESS
So we can see the ACL includes three Access Control Entries (ACEs). Administrators and SYSTEM have full control to the service and regular users (Authenticated Users) can read the configuration and start the service (but not stop it or change the service configuration.
Now let's have a look at the ACL for the Windows Update service from the article:
D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;AU)(A;;CCLCSWRPWPDTLOCRRC;;;PU)
Convert it to a readable format:
PS > $WuauservSddlFromArticle = 'D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;AU)(A;;CCLCSWRPWPDTLOCRRC;;;PU)' PS > $WuauservAcl = New-Object -TypeName 'System.Security.AccessControl.CommonSecurityDescriptor' -ArgumentList $false,$false,$WuauservSddlFromArticle PS > $WuauservAcl.DiscretionaryAcl | Select SecurityIdentifier,@{Name='NTAccountName';Expression={((New-Object -TypeName System.Security.Principal.SecurityIdentifier($_.SecurityIdentifier)).Translate([System.Security.Principal.NTAccount]).Value)}},AceType,AceFlags,AccessMask,@{Name = 'AccessMaskString';Expression={[Flags()] Enum EnumAccessMask{SERVICE_QUERY_CONFIG=1; SERVICE_CHANGE_CONFIG=2; SERVICE_QUERY_STATUS = 4
SERVICE_ENUMERATE_DEPENDENTS=8; SERVICE_START=16; SERVICE_STOP=32; SERVICE_PAUSE_CONTINUE = 64 SERVICE_INTERROGATE = 128 SERVICE_USER_DEFINED_CONTROL = 256 DELETE = 65536 READ_CONTROL = 131072 WRITE_DAC = 262144 WRITE_OWNER = 524288 SERVICE_ALL_ACCESS = 983551
} [EnumAccessMask][int]$_.AccessMask} }
SecurityIdentifier : S-1-5-11 NTAccountName : NT AUTHORITY\Authenticated Users AceType : AccessAllowed AceFlags : None AccessMask : 131469 AccessMaskString : SERVICE_QUERY_CONFIG, SERVICE_QUERY_STATUS, SERVICE_ENUMERATE_DEPENDENTS, SERVICE_INTERROGATE, SERVICE_USER_DEFINED_CONTROL, READ_CONTROL
SecurityIdentifier : S-1-5-18 NTAccountName : NT AUTHORITY\SYSTEM AceType : AccessAllowed AceFlags : None AccessMask : 131581 AccessMaskString : SERVICE_QUERY_CONFIG, SERVICE_QUERY_STATUS, SERVICE_ENUMERATE_DEPENDENTS, SERVICE_START, SERVICE_STOP, SERVICE_PAUSE_CONTINUE, SERVICE_INTERROGATE, SERVICE_USER_DEFINED_CONTROL, READ_CONTROL
SecurityIdentifier : S-1-5-32-544 NTAccountName : BUILTIN\Administrators AceType : AccessAllowed AceFlags : None AccessMask : 983551 AccessMaskString : SERVICE_ALL_ACCESS
SecurityIdentifier : S-1-5-32-547 NTAccountName : BUILTIN\Power Users AceType : AccessAllowed AceFlags : None AccessMask : 131581 AccessMaskString : SERVICE_QUERY_CONFIG, SERVICE_QUERY_STATUS, SERVICE_ENUMERATE_DEPENDENTS, SERVICE_START, SERVICE_STOP, SERVICE_PAUSE_CONTINUE, SERVICE_INTERROGATE, SERVICE_USER_DEFINED_CONTROL, READ_CONTROL
This ACL includes four ACEs and the additional ACE allows member of the Power Users group to stop and start the service. At least Power Users are not allowed to change the service configuration and thus can elevate their privileges to Administrator but it changes the default ACLs on Windows 10. The ACL from the article is probably the default from an older Windows version, maybe 7 or 8 but I would guess the Windows product group had its reasons to change that for Windows 10, Windows Server 2016 and 2019 and so I would say it's not a very good idea to change that value (possibly also results in supportability issues). In addition, the service ACL has nothing to do with the Windows Update agent not working properly. If the service ACL might get corrupted, you may not be able to start or stop the service but it does not affect the inner workings of the Windows Update agent. I would remove changing the ACL completely from the article.
@joachimme I've tested on 2 fresh VMs (Windows 11 and Windows Server 2019) and found the following default security descriptors for BITS and Windows Update service.
sc.exe sdshow wuauserv D:(A;;CCLCSWRPLORC;;;AU)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SY)
sc.exe sdshow bits D:(A;CI;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;IU)(A;;CCLCSWLOCRRC;;;SU)
Hence i've created a PR to change the values to these.
I am just wondering if it might be better to remove resetting the ACL from the script at all. You would need to handle the differences between the OS versions to do it properly and if the ACL changes in the next Windows build, you have the same problem again. How often does it happen that the ACL of the services is broken? Probably a seldom fringe case anyway.
@joachimme Good point and I thought about that before doing the PR. I did it because I saw that the article applies only to Windows 10/11 and Server 2016/2019, which have those default security descriptors.
Until the "applies to" changes and the newer versions will have different default security descriptors, I think we should be good. But let's see what the author thinks about it.
I'm no longer working in this area; author metadata not assigned yet.
@arcarley can you direct to someone on the technical side to advise this person? @dougeby FYI.
A little investigation reveals that it is possible for Windows Update service to be set such that authorized users do not have permission to search for and install updates. This can happen due to a GPO. Resetting the ACLs might only be necessary under this circumstance. I suggest modifying the PR to have 4b as an optional step in cases where there is a permission issue.
If this permission issue is a corner case, it might be worthwhile to link over to a different article that discusses resetting ACLs as a solution if the steps provided here do not work, or if it is a known permission problem.
I think I have some people with expertise that I can ask about this.
@e0i & @joinimran FYI I reviewed this with our team's update SME @mestew and recommendation is to remove this article and/or put in a request to migrate it to docs.microsoft.com/troubleshoot. While the article gets a lot of PVs (32k in June 2022), a lot of the content is very out of date. I wanted to check with you if you had another plan in mind? (Personally I think migrating to troubleshooting is the best path at this point.)
@aczechowski
The best next step for us would be to move forward with Greg's advice as commented above. We couldn't have any plans if the article is meant to be removed afterwards as we only handle corrections.
