Adding a virtual service account to a group

[computerquip-work]

(A quick note, I've had to scrub the names so ExampleService is replacing my actual service name.)

I am using Wix 4.0.5.

I have a service named ExampleService. This service is installed like this within a component:

        <ServiceInstall
         Account="NT SERVICE\ExampleService"
         Description="An example service"
         DisplayName="ExampleService"
         Name="ExampleService"
         ErrorControl="normal"
         Start="auto"
         Type="ownProcess"
         Vital="yes">
          <ServiceConfig
           DelayedAutoStart="no"
           OnInstall="yes"
           OnReinstall="yes"
           OnUninstall="no" />
          <util:ServiceConfig
           FirstFailureActionType="restart"
           SecondFailureActionType="restart"
           ThirdFailureActionType="restart"/>
        </ServiceInstall>

        <ServiceControl
         Name="ExampleService"
         Stop="both"
         Remove="uninstall"
         Wait="yes"/>

In the same component, I have this:

        <util:User CreateUser="no" Name="NT SERVICE\ExampleService">
          <util:GroupRef Id="GroupAdministrators" />
        </util:User>

In the package element, I have this:

    <InstallExecuteSequence>
      <ScheduleReboot After="InstallFiles" Condition="1" />
      <Custom Action="Wix4ConfigureUsers_$(sys.BUILDARCHSHORT)" After="InstallServices" />
    </InstallExecuteSequence>

    <util:Group Id="GroupAdministrators" Name="Administrators"/>

Note that I've tried using QueryWindowsWellKnownSIDs which gives me BUILTIN\Administrators which does not work with NetLocalGroupAddMembers.

Anyways, when this executes, the service installs correctly. However, the install fails when it tries to add the user to a group. It provides a message box containing an OK button saying Failed to add user to group. (-2147023509 NT SERVICE\ExampleService Administrators ). I've had to manually type this out.

Since the installer halts everything to provide this message box, I can look at the state of the install.

• The service exists
• It's assigned the NT SERVICE\ExampleService
• The service is runnable
• The service account is not a member of Administrators, it indeed fails.

So... I looked into the code and logs. The related logs are as follows:

InstallServices: Service: 
MSI (s) (24:80) [17:43:48:887]: Executing op: ServiceInstall(Name=ExampleService,DisplayName=Example Service,ImagePath="C:\Program Files\<snip>",ServiceType=16,StartType=2,ErrorControl=32769,,Dependencies=[~],,StartName=NT SERVICE\ExampleService,Password=**********,Description=An example service,,)
InstallServices: Service: 
MSI (s) (24:80) [17:43:48:887]: Executing op: ActionStart(Name=Wix4CreateUser_X64,,)
Action 17:43:48: Wix4CreateUser_X64. 
MSI (s) (24:80) [17:43:48:901]: Executing op: CustomActionSchedule(Action=Wix4CreateUser_X64,ActionType=11265,Source=BinaryData,Target=**********,CustomActionData=**********)
MSI (s) (24:A4) [17:43:48:901]: Invoking remote custom action. DLL: C:\Windows\Installer\MSI6DFC.tmp, Entrypoint: CreateUser
CreateUser:  Entering CreateUser in C:\Windows\Installer\MSI6DFC.tmp, version 4.0.5.0
CreateUser:  Adding user \NT SERVICE\ExampleService to group \Administrators
CreateUser:  Failed to add user: NT SERVICE\ExampleService, domain  to group: Administrators, domain:  with error 0x8007056b.  Attempting to use Active Directory
CreateUser:  Error 0x8007056b: Failed to add user WinNT://NT SERVICE\ExampleService to group 'WinNT://Localhost/Administrators'.
CreateUser:  Error 0x8007056b: failed to add user: NT SERVICE\ExampleService to group Administrators
Error 26403. Failed to add user to group.  (-2147023509   NT SERVICE\ExampleService   Administrators   )
MSI (s) (24!BC) [17:48:19:715]: Product: ExampleProduct -- Error 26403. Failed to add user to group.  (-2147023509   NT SERVICE\ExampleService   Administrators   )

CustomAction Wix4CreateUser_X64 returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)
Action ended 17:48:19: InstallFinalize. Return value 3.

The error 0x8007056b translates to ERROR_NO_SUCH_MEMBER meaning it doesn't think the user exists.

I've tracked this down to this particular piece of code in the Util extension: https://github.com/wixtoolset/Util.wixext/blob/8a8a25695351ee542f08886a9d0957c78c6af366/src/ca/scaexec.cpp#L192

I cannot tell if the error is from NetGroupAddUser or NetLocalGroupAddMembers. In my case, I'm expecting NetLocalGroupAddMembers to be called. Regardless, to test if this works, I wrote this program that mimics what the Util extension does:

#include <windows.h>
#include <lm.h>

#include <wil/result.h>

#include <array>
#include <string>
#include <iostream>

static void wil_log_callback(wil::FailureInfo const& failure) noexcept
{
    std::array<wchar_t, 2048> buffer;

    if (SUCCEEDED(wil::GetFailureLogString(buffer.data(), buffer.size(), failure))) {
        std::wcout << buffer.data() << "\n";
    } else {
        std::wcout << L"failed to format error\n";
    }
}

int wmain(int argc, wchar_t **argv)
{
    wchar_t* groupname = argv[2];
    wchar_t* username = argv[1];
    LOCALGROUP_MEMBERS_INFO_3 lgmi{};
    DWORD error{ ERROR_SUCCESS };

    wil::SetResultLoggingCallback(wil_log_callback);

    if (argc != 3) {
        std::wcout << L"usage: " << argv[0] << " <user> <group>\n";

        return 1;
    }

    std::wcout << L"user: " << username << "\n";
    std::wcout << L"group: " << groupname << "\n";

    lgmi.lgrmi3_domainandname = username;

    error = ::NetGroupAddUser(nullptr, groupname, username);

    if (error != ERROR_SUCCESS) {
        LOG_WIN32(error);
    }

    if (error == NERR_GroupNotFound) {
        RETURN_IF_WIN32_ERROR(::NetLocalGroupAddMembers(
            nullptr
            , groupname
            , 3
            , reinterpret_cast<LPBYTE>(&lgmi)
            , 1));
    }

    std::wcout << L"success\n";

    return 0;
}

Since the installer prompts with that message box, I can run this to see if it works. Running it with AddUserToGroup.exe "NT SERVICE\ExampleService" "Administrators" provides the following output:

user: NT SERVICE\ExampleService
group: Administrators
C:\Users\MyUser\source\repos\AddUserToGroup\main.cpp(44)\AddUserToGroup.exe!00007FF7B5463525: (caller: 00007FF7B5464EB9) LogHr(1) tid(1460) 800708AC The group name could not be found.
    [wmain(error)]

success

This means that the program succeeded. The service account indeed is then part of the Administrator group. Sure enough, despite doing seemingly the same thing as the util extension, this works and the util extension failed.

I've tried a completely different approach as well, where instead of a virtual service account, I create a new user. Unfortunately, nobody should know the password to the service account (and ends up being a security risk potentially). I've tried generating a safe random password specifically for the installer but this doesn't appear to be possible. Even still, I've tried adding such a user to the Administrator group and it still fails with the util extension.

Anyways, I'm at my wits end with this. If anyone has any suggested alternatives, answers to the problems above, or insights, literally any help at this point would be appreciated. Really, all I want is a distinct user with some privileges to run a service. I would have figured this is an extremely common usecase but apparently, I'm either just missing the elephant or I'm doing something more unorthodox than I thought.

If a complete example with project files would help, I can create that as well.

[robmen]

Managed service accounts didn't exist when the User custom action was written, so scenarios using them are "new" (managed service accounts aren't that new but newer than the existing code 😄).

Anyway, I'm pretty sure there was an issue opened about this scenario recently. It wouldd be interesting to have managed service accounts supported.

[bevanweiss]

I think this might be a problem with timing.

I think the CreateUser actions are occurring too early, before the Service itself has been configured (which is when the virtual service account exists).

I think you might need to schedule the CreateUser deferred action to be AFTER the ServiceInstall.
Perhaps have a look in Orca to see what the current scheduling is... and just hand tweak it to re-arrange...
If that resolves the situation, then it could be codified (or XML authored in this case).

Other option you could try is, when the error is thrown. Try to do the group membership change that you're looking to do. I suspect it would fail because the user wouldn't yet exist...

[computerquip-work]

I tried moving stuff around but no matter what I did, I could not get this to work. What I ended up doing is embedding that program above into the MSI and executing it as a type 2 deferred custom action scheduled after InstallServices. I still don't quite understand why that works and util doesn't.

[bevanweiss]

I can reproduce this in something that I'm working on currently.
So I'll see if I can get to the bottom of it this coming weekend.

From your short log of your custom code, it looks like the NetGroupAddUser was NOT working, but the NetLocalGroupAddMembers was working.

[computerquip-work]

From your short log of your custom code, it looks like the NetGroupAddUser was NOT working, but the NetLocalGroupAddMembers was working.

Just for some clarification...

In this case, it's meant to work this way as the Administrators built-in group is domain local. NetGroupAddUser would work if the group was a global group which would be specific to a domain. For example, if I were to add them to the default Domain Admins group made, the first function would work.

This installation was performed on a workstation that's part of an Active Directory installation. It was designed to mimic what Wix does. I'm not sure if that's the best thing to do to be honest but seems reasonable to me.