NT Authority\System & SDDL Error

Question

A customer installing my companies software package has no problem installing the package silently when running as an admin account. The software and the service both install correctly and start up post installation. However - they need to push this application to all the computers in a particular group.

They are using SCCM (I do not know the version) and the software package is a InstallShield .exe packaged .msi.

When they try to use the NT Authority\System user to push the package to their test device, the installation fails soon after the 3rd party software package that is included completes. The error log displays that it is a SDDL error 1943. Any idea why this would occur on the NTA\System account and not on a local admin account for a given machine?

The silent install string we are using is setup.exe /s /v" /qn AgreeToLicense=Yes SetupType=Typical"

I'm not a dev, so I dont have direct access to any code in the software, simply a tier 3 tech support working with customers.

Answer 1

Sounds like your MSI is using the MsiLockPermissionsEx table to specify an SDDL string on some resource its installing or configuring (either file, directory, service or registry entry). Either the SDDL string is misconfigured (unlikely if it works from one account but not another) or the ACL on the target directory/service/registry key have become corrupted, which isn't completely unheard of.

You could try getting the customer to deploy a domain account as local admin to the computers and then set SCCM to run the package with this account. I wouldn't recommend this though as it carries inherent security risks of its own.

I'm afraid this may be one that your developers (or whoever created the MSI) need to work out with the customers to find out which resources are at fault and progress the diagnosis.

Sorry I couldn't be of further help.

Answer 2

I think I have found the issue. During install the .msi writes a file to the desktop to be read for configuration settings for the service as being installed. I had the file (and I am sure the customer did as well) already written to the desktop when I tried to invoke the System User for install. This does seem to be an ACL issue, in reference to the System User read/writing to a local user desktop. When the file was deleted, I received error 1406, that it could not write the value of a key. Looking on the desktop, the file had also never been written to the local desktop. When the file was already there (as such with a previous install) I get the error in the original post. At this point I am moving forward testing this as an ACL error and notifying the devs of my findings.