26

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.
Peter Mounce
  • 1,243
  • 4
  • 16
  • 28
  • 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 https://medium.com/palantir/active-directory-as-code-e9666a2e548d if you're interested to do it). – Peter Mounce Jan 01 '19 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 01 '19 at 14:54

3 Answers3

28

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;
}
Swisstone
  • 6,357
  • 7
  • 21
  • 32
18

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

Greg Askew
  • 34,339
  • 3
  • 52
  • 81
  • 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 01: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 03: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 04: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 04: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 05:40
0

This is a bit old of a thread but I came upon it while looking for a way to create a user's profile folder structure properly during a new image build script for specific customization that were not possible by GPO etc.

If you run a remote powershell Invoke-Command with the user's credentials, it will build the user profile folder under C:\Users if it doesn't already exist and you can then manipulate it and also the HKCU registry keys as needed.

This command does nothing but the exit command, but will create the user's profile if it doesn't already exist:

Invoke-Command -ComputerName $computerVar -ScriptBlock {exit} -Credential $credentialVar

Obviously the user's creds have to have the rights to connect remotely, and the OS firewall can't be blocking said connections but otherwise, this command will do what you are looking for at least.