Security is necessary in today’s world, that’s undeniable, but that doesn’t make it fun.
At my current customer, most everything was going swimmingly well until I went to deploy the first test client. This was a manual install from the command-line — not that that should make any sort of difference though. So, while watching ccmsetup.log like any good ConfigMgr admin, I was greeted with the following major failure as ccmsetup tried to download files from the MP.
Checking the URL 'https://man01.xyz.com:443/CCM_Client/ccmsetup.cab' PROPFIND 'https://man01.xyz.com.com:443/CCM_Client' Got 401 challenge Retrying with Windows Auth... PROPFIND 'https://man01.xyz.com.com:443/CCM_Client' Failed to correctly receive a WEBDAV HTTPS request.. (StatusCode at WinHttpQueryHeaders: 401) Failed to check url https://man01.xyz.com.com:443/CCM_Client/ccmsetup.cab. Error 0x80004005 Accessing the URL 'https://man01.xyz.com.com:443/CCM_Client/ccmsetup.cab' failed with 80004005
The first question of course was why was it failing back to the MP to download the files? Checking the log file a bit further up revealed pretty much the same series of messages for the package on DP at. Per HTTP 401.x-Unauthorized on TechNet, an HTTP error code of 401 means Unauthorized. Correlating this to the IIS log file revealed a 401.3 code which translates to “Access is denied due to an ACL set on the requested resource” per the same article. I also cranked up procmon to watch the process in real time — this revealed much the same: an Access Denied when trying to hit the ccmsetup.cab file.
Given that this was a default install of ConfigMgr and IIS, I couldn’t imagine that the ACLs were actually messed up though and a cursory review up the ACLs validated this. The next and usual suspect was AV (not SCEP). After disabling it, there was no change — this made me sad because I love blaming third-party AV: most of them suck and have caused ConfigMgr admins all kinds of problems in the past and thus deserve to be ridiculed.
The next likely culprit was Group Policy. As it turns out, this customer was using the high-security templates available from Microsoft. These are well-vetted templates and should work for most things Microsoft, but in this case, something was certainly getting in the way. Blocking the GPO applying these security settings from applying to the site system hosting the MP and DP was up next to rule these settings out or confirm them as being the source of the issue. After this (and a reboot for good measure) … ccmsetup ran through like a champ. So now on to comparing each setting one by one to see which could be the source. After an initial review I narrowed it down to either (or both) the “Access this computer from the network” setting or the “Bypass traverse checking” setting and after some trial and error, the latter turned out to be the culprit. Adding the built-in Users group back to this security (along with a reboot) allowed the process to go through.
This makes sense and does line up with the Access Denied as reported by procmon and the 401.3 reported by IIS because the computer account of the system installing the client agent didn’t have explicit read permissions on the folders in the path to the ccmsetup.cab file but did have permissions on the file itself. Time to bribe the GPO admin …
Winter is coming …
I’m finding that adding the USERS back to the permissions doesn’t work, SCCM quickly overwrites the existing permissions. I’m not sure if the customer is going to be willing to rollback this GPO setting. How were you able to get the security ACLS to stick?
SCCM\client NT AUTHORITY\SYSTEM:(F)
NT AUTHORITY\SYSTEM:(OI)(CI)(IO)(F)
BUILTIN\Administrators:(F)
BUILTIN\Administrators:(OI)(CI)(IO)(F)
NT AUTHORITY\LOCAL SERVICE:(R)
NT AUTHORITY\LOCAL SERVICE:(OI)(CI)(IO)(GR)
NT AUTHORITY\IUSR:(R)
NT AUTHORITY\IUSR:(OI)(CI)(IO)(GR)
So the recommendation here isn’t to add Users to the ACL of any object; it’s to modify the security policy and enable bypass traverse checking for Users.