19

I'm creating a (local) user for a Windows service to run as. I've got good reasons for not wanting to use NETWORK SERVICE, LOCAL SERVICE, or LOCAL SYSTEM.

I create the user via net user foobar "Abcd123!" /add - this works fine.

At this point, c:\users\foobar does not exist.

If I create the user's home directory, before the user either logs on (or, more pertinently) or the service that the user is for starts up, Windows creates a user-profile next-door called c:\users\foobar-{gibberish/SID/whatever} - this is not a predictable name.

I need the user's home directory to contain things like a .ssh directory, a .gitconfig - tools like that (not limited to those tools) that make assumptions that it'll be a person using them, and so user-configuration goes inside ~/.... Usually, tools from a Unix heritage.

Actual question

So - is there a programmatic (preferably, PowerShell, or out-of-the-box command-line) way to tell Windows to create the user-profile for a local user?

Or, any other workarounds?

Things I've yet to try:

  • An NSSM start/pre hook that copies files from elsewhere into the user-profile directory that hopefully exists at this point by virtue of Windows starting the service, creating the user-profile then handing control to the NSSM wrapper running the hook before startup.
  • Setting the USERPROFILE environment variable for the service to be somewhere other than the actual user-profile directory. This strikes me as dangerously off-piste but also might work fine.

Other context:

  • Windows Server 2016, desktop experience.
    • Can't use Core/Nano.
  • There is no active directory in play. There won't be.
  • These are local users.
  • I'm doing this via Ansible, which is using PowerShell under the hood for Windows things. Specifically the win_user module, with Ansible 2.7.5.
  • I don't want to create a C:\users\default (the equivalent of /etc/skel), because there are a few different service-users and one size won't fit all. This also doesn't affect when the user-profile is created, just what will be in it when it is.
  • I'm using NSSM to manage the services.

Things I've tried

  • starting the service and allowing Windows to create the directory
    • I don't want to do this, because the service requires secrets before starting up, and so if I do this inside my image-baking process I'll then need to clean them up, and also make sure my service doesn't do any work during the baking phase. I want to avoid both of those fiddly bits.
  • 1
    Have you checked the options net user has (e.g. /HOMEDIR or /PROFILEPATH)? . See net user /help. From my (untested) understanding, you can create a directory for the user, and set this as homedir with the /HOMEDIR switch. – Sven Dec 28 '18 at 14:37
  • May I ask what use case do you have that avoids Active Directory? Things would be much easier with AD. Just curious. – Ondrej Tucny Dec 28 '18 at 17:15
  • I'm avoiding AD because the machines are ephemeral; lifetimes are measured in hours, not days. The machines are hosting clean-room build-environments. Juggling machines in and out of an AD as they come and go is simply not worth it (see also medium.com/palantir/active-directory-as-code-e9666a2e548d if you're interested to do it). – Peter Mounce Jan 1 at 14:51
  • @Sven yes - sadly neither of those cause the profile itself to be created, even if they set the path. – Peter Mounce Jan 1 at 14:54
22

Windows can create a user-profile on-demand, using the CreateProfile API

However, if don't want to create an executable to perform this operation, you can call the API in PowerShell. Others have already done it: example on github.

Relevant part of the code:

$methodName = 'UserEnvCP'
$script:nativeMethods = @();

Register-NativeMethod "userenv.dll" "int CreateProfile([MarshalAs(UnmanagedType.LPWStr)] string pszUserSid,`
  [MarshalAs(UnmanagedType.LPWStr)] string pszUserName,`
  [Out][MarshalAs(UnmanagedType.LPWStr)] StringBuilder pszProfilePath, uint cchProfilePath)";

Add-NativeMethods -typeName $MethodName;

$localUser = New-Object System.Security.Principal.NTAccount("$UserName");
$userSID = $localUser.Translate([System.Security.Principal.SecurityIdentifier]);
$sb = new-object System.Text.StringBuilder(260);
$pathLen = $sb.Capacity;

Write-Verbose "Creating user profile for $Username";
try
{
    [UserEnvCP]::CreateProfile($userSID.Value, $Username, $sb, $pathLen) | Out-Null;
}
catch
{
    Write-Error $_.Exception.Message;
    break;
}
  • Thank you very much, this works for me. Note to others - the Register-NativeMethod and Add-NativeMethods functions are in the linked gist. – Peter Mounce Jan 27 at 15:55
16

All you need to do is run a command as that user, Windows will create the profile:

psexec.exe -u foobar -p Abcd123! cmd.exe /c exit

https://docs.microsoft.com/en-us/sysinternals/downloads/psexec

  • 1
    So what's happening here is psexec supposed to connect to localhost under username and password specified with -u and -p and launch cmd just to exit immediately. Did I miss anything ? This sounds somewhat counterintuitive - connecting to system with nonexistent username and password should be an error. How does that work ? – Sergiy Kolodyazhnyy Dec 29 '18 at 1:13
  • 1
    @SergiyKolodyazhnyy: Why do you think that's a nonexistent username and password? It's the same one used in the question, obviously as an example... – Ben Voigt Dec 29 '18 at 3:41
  • 1
    @BenVoigt Well, I've missed the top part of the question. I thought OP wanted to create the user as well and that's what this answer was supposed to do. So that last part of the comment is a misunderstanding. – Sergiy Kolodyazhnyy Dec 29 '18 at 4:09
  • @BenVoigt Though I do still have a question. OP mentioned " I don't want to create C:\users\default". So where would the user's profile come from when this method is used and how would Windows know to create specific pre-configured directories if not from C:\users\defaults ? – Sergiy Kolodyazhnyy Dec 29 '18 at 4:11
  • 1
    @SergiyKolodyazhnyy: Pretty sure OP means he doesn't want to customize C:\Users\Default ... not that it will be entirely missing. Windows will create the home directory C:\Users\foobar by copying from the plain vanilla C:\Users\default, then once it exists OP can apply his special sauce to C:\Users\foobar where it won't affect any other users. – Ben Voigt Dec 29 '18 at 5:40

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.