Failure on invalid user context with DCM permission evaluation

  • [アーティクル]

I’m a huge fan of the Desired Configuration Management (DCM) feature of ConfigMgr.  However, I found that it can be quite literal with the input data, and the result is not always very user friendly.  For example, I created a new General Configuration Item (CI) with a single object rule to evaluate just the exclusive permissions on %WinDir%\System32\cmd.exe (no instance count or attribute verification).  The expected permissions were that Administrators and SYSTEM have Full Control, but nothing else.

The interface enforces entry of the user or group prefaced with the context (e.g., domain\username), but doesn’t provide any additional guidance.  The available documentation notes that, "If you are specifying the name of a built in group or user, use the form BUILTIN\USER."  So I added two entries: BUILTIN\Administrators and BUILTIN\SYSTEM.  I then added the CI to a baseline, assigned it to a target collection, and updated policy to receive and evaluate the configuration.

The evaluation report from the client control panel showed an evaluation failure:

Source: /system/schema/ScopeID_2DF32CAA-6275-4EFD-98D4-1A1C4B24B826_BusinessPolicy_8092b0b8-27e6-4696-a33c-7b5262e4a0e1_2
Category: RuleProcessingError
Severity: ERROR
Message: Exception 'System.Xml.Xpath.XpathException' occurred while evaluating the expression 'mssmltrans:sdEquals(@RealSD,concat('D:',mssmltrans:sdTranslate('(A;;0x1F01FF;;;{BUILTIN\Administrators})'),mssmltrans:sdTranslate('(A;;0x1F01FF;;;{BUILTIN\SYSTEM})')), 'Access', 'ocsj')': Function 'mssmltrans:sdEquals()' has failed.

The Application event log on the client shows an error of event ID 11864 from source SmsClient with the description: "Baseline content ScopeID_..., version 2 has model violations."  The same message appears as a status message from the client on the primary site server.

All of this had me quite stumped, but some of the text inside of the error (A;;0x1F01FF;;;) looked like security descriptor definition language (SDDL), and with the names of functions like sdTranslate and sdEquals, I decided to take a look at the security descriptors on the file.

I ran the following command on the client to display the SDDL

cacls c:\windows\system32\cmd.exe /s

which yielded:

"D:(A;;0x1200a9;;;IU)(A;;0x1200a9;;;SU)(A;;FA;;;BA)(A;;FA;;;SY)(A;;FA;;;BA)(A;;0x1200a9;;;S-1-5-21-2037546026-41271002)"

So I knew I was on the right track.  As I was working with this I happened to run cacls without the /s parameter, which yielded:

NT AUTHORITY\INTERACTIVE:R
NT AUTHORITY\SERVICE:R
BUILTIN\Administrators:F
NT AUTHORITY\SYSTEM:F
BUILTIN\Administrators:F
SRV03\TelnetClients:R

It was at this point that I smacked my forehead.  I revised the CI replacing "BUILTIN\SYSTEM" with "NT AUTHORITY\SYSTEM" and upon re-evaluation, no more failures.  (The client was non-compliant with the CI, but at least was able to successfully evaluate the setting.)

This was most certainly user error; I should have known better to use the NT AUTHORITY context for SYSTEM instead of BUILTIN.  However, in my opinion, the client did not do a good job of reporting the error, the CI interface did not do a good job of providing context-sensitive help, and the product documentation did not provide a broader scope of available options.  The client reporting an error such as, "User BUILTIN\SYSTEM not found" (perhaps with the additional debugging detail) would have been more useful.

Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of included script samples are subject to the terms specified in the Terms of Use.

Comments

  • Anonymous
    July 26, 2013
    The comment has been removed