Util User: Not able to create Domain user in standard usage

bevanweiss commented 2 months ago

WiX Version

5.0.0+41e11442

.NET or MSBuild or Visual Studio Version

8.0.400-preview.0.24324.5,

HeatWave Version

1.0.4.5

Windows Version

Win11 22H2 22621.3737

Repro Repo

No response

Repro Steps

When an MSI with the below component is run by a Domain Administrator on a domain joined workstation, the installation fails when the CreateUser custom action is run.

<Component Id="Component1" Guid="09624A9A-4BBC-4126-BBF9-0713C5217DB1" Directory="INSTALLFOLDER">
    <File Source="$(sys.SOURCEFILEPATH)" KeyPath="yes" />
    <util:User Id="TEST_USER1" Name="testName1" Domain="TESTDOMAIN" Comment="testComment1" Password="test123!@#" PasswordExpired="yes" CreateUser="yes" RemoveOnUninstall="yes" />
</Component>

This is because whilst the Domain Administrator has adequate permissions to perform the domain action to create the user, the custom actions to actually CreateUser / RemoveUser (and RollBack) are performed without Impersonation of the Domain Administrator (and hence run as LocalSystem, not a valid user for domain actions)

<CustomAction Id="$(var.Prefix)CreateUser$(var.Suffix)" DllEntry="CreateUser" Impersonate="no" Execute="deferred" Return="check" HideTarget="yes" SuppressModularization="yes" BinaryRef="$(var.Prefix)UtilCA$(var.Suffix)" />
<CustomAction Id="$(var.Prefix)CreateUserRollback$(var.Suffix)" DllEntry="CreateUserRollback" Impersonate="no" Execute="rollback" Return="check" HideTarget="yes" SuppressModularization="yes" BinaryRef="$(var.Prefix)UtilCA$(var.Suffix)" />
<!-- RemoveUser is a type commit action because it is not possible to rollback the removal of a user -->
<CustomAction Id="$(var.Prefix)RemoveUser$(var.Suffix)" DllEntry="RemoveUser" Impersonate="no" Execute="commit" Return="ignore" HideTarget="yes" SuppressModularization="yes" BinaryRef="$(var.Prefix)UtilCA$(var.Suffix)" />

If these are changed to

<CustomAction ... Impersonate="yes" ... />

Then things work fine for creation of Domain Users. I'm unsure what things might break without the LocalSystem elevated aspect for CreateUser / RemoveUser / User Group memberships.

Actual Result

Installation failed. er = 5 (ERROR_ACCESS_DENIED) No user created in domain.

Expected Result

Installation succeeded. Domain user testName1 created on TESTDOMAIN domain.

Acknowledgements

[X] I acknowledge that this is a fully completed bug report. It is not a question or attempt to get help debugging my issue (because those should be sent to Discussions).

robmen commented 1 month ago

I'm unsure what things might break without the LocalSystem elevated aspect for CreateUser / RemoveUser / User Group memberships.

It would break all installs that do not launch from an elevated process. Therefore, you cannot change the Impersonate bit on the existing CustomActions. New CustomActions could be created that are Impersonated but they will fail unless the package is launched from an elevated process which is not something you can control from within the MSI package.

Installing domain users is not a bug fix. It's a feature.

bevanweiss commented 1 month ago

I thought I'd been testing as non-elevated already. But I'll double check.

My original plan was to create new Custom Actions which would just be Impersonated versions, and they would call the exact same functions. The sched would then use either the CreateUser or CreateDomainUser as applicable based on whether the target user had an assigned domain or not. However it would have been a relatively big change for the UserGroup assignments, since they are currently done in the same CA deferred execution, and for a domain user, they might be joining a domain group.. which would need impersonation, or a domain user might be joining a local group, which as you say requires no impersonation (to elevate)

barnson commented 3 weeks ago

@bevanweiss - do you want this issue assigned to you, since you're working on the PR?

bevanweiss commented 3 weeks ago

@bevanweiss - do you want this issue assigned to you, since you're working on the PR?

@barnson that sounds like a plan. My concept for the User domain stuff is still very much in line with (and would leverage some of the items in..) what I've got already 'ready for review' for the Group domain stuff.

barnson commented 3 weeks ago

Rob and I are both behind on PR reviews but we haven't forgotten! :)

wixtoolset / issues