15

I have a Windows account that is used for running services (ie. it's not intended that any person should log in as that account). Turns out one of the services needs to access a remote network share that's on a machine in a different Windows domain, and so needs to supply remote credentials to get to that share.

Now if it was me needing to access the remote share, I would simply open Credential Manager, and save the required credentials. But it's not me, and my understanding of credential manager is it only saves credentials to be used by the logged in user.

I can of course solve this problem. I temporarily elevate the privileges of the service account to allow interactive logins, then I login as that user and use credential manager to store the correct remote credentials. Then I remove the interactive login privileges. But that feels very hacky and not the kind of thing I ought to be doing.

So my question is: Is there another way to save remote credentials for an account other than the one you're logged in as? Any better way to solve my problem.

LondonPhantom
  • 959
  • 3
  • 10
  • 16
  • Turns out Credentials Manager is irrelevant anyway, as it's entirely up to the app whether it uses it or not - and in my case it seems the service I'm running doesn't. Lee's answer that I've accepted is great because it sidesteps credentials manager altogether. – LondonPhantom Jan 18 '13 at 16:12

4 Answers4

35

Although it turned out to be irrelevant to your situation, for the benefit of future searchers, the answer to the actual question "Manage another user's credentials for network access" is:

runas /user:serviceaccountname "%windir%\system32\cmdkey.exe /add:server.domain.com /user:username /pass:password"

This will create a credential in serviceaccountname's credential vault for server.domain.com using username/password.

/user also supports domain\username and username@domain styles.

agentnega
  • 733
  • 5
  • 10
3

If you can access the remote computer, you could add your service account to the local Users group and match the username/password to what you would use. Don't forget to give it administrative privileges.

Then goto the remote login tab in the system menu, and add that user as someone who is allowed to remotely login. This is what I do when I need to hit certain machines that are on our network, but not part of the domain for whatever reason.

Lee Harrison
  • 2,119
  • 13
  • 13
  • That's exactly what I wanted. I hadn't realised that if you had the same login and password, Windows would accept the credentials even if the login was coming from a different machine (and so had a different SID). Thanks Lee! – LondonPhantom Jan 18 '13 at 16:10
0

The simplest way to setup credentials for another user remotely using cmdkey, is to create a scheduled task, that is run under the user account for which you want to add the credentails via cmdkey.

Connect to the machine in question using an admin account via Enter-PSSession -ComputerName target_machine (or run the commands via Invoke-Command).

With SeBatchLogonRight already set

If the user account for which you want to add credentials via cmdkey already has the SeBatchLogonRight set (usually only admins), then it is fairly simple:

$job = Register-ScheduledJob -ScriptBlock {
     cmdkey /add:target_machine:target_port /user:target_domain\target_user /pass:target_user_password
} -Name "Add user credentials" -Credential (New-Object System.Management.Automation.PSCredential("source_domain\source_user", (ConvertTo-SecureString "source_user_password" -AsPlainText -Force))) -RunNow

Unregister-ScheduledJob -InputObject $job

Without SeBatchLogonRight already set

If the user account for which you want to add credentials via cmdkey does not have the SeBatchLogonRight set already, then you need to (temporarily) grant it the right. A simple way to do this remotely is to use the PowerShell module from Tony Pombo:

Invoke-WebRequest https://gallery.technet.microsoft.com/scriptcenter/Grant-Revoke-Query-user-26e259b0/file/198800/1/UserRights.psm1 -OutFile UserRights.psm1

# You might need to setup at least the following execution policy, if you haven't already:
# Set-ExecutionPolicy AllSigned

Import-Module .\UserRights.psm1

Grant-UserRight -Account "source_machine\source_user" -Right SeBatchLogonRight

$job = Register-ScheduledJob -ScriptBlock {
     cmdkey /add:target_machine:target_port /user:target_domain\target_user /pass:target_user_password
} -Name "Add user credentials" -Credential (New-Object System.Management.Automation.PSCredential("source_domain\source_user", (ConvertTo-SecureString "source_user_password" -AsPlainText -Force))) -RunNow

Unregister-ScheduledJob -InputObject $job

Revoke-UserRight -Account "source_machine\source_user" -Right SeBatchLogonRight

The following placeholders have been used in the scripts above:

  • source_domain = The domain source_user belongs to.
  • source_user = The user for which the cmdkey command will be executed (cmdkey runs in this user's context).
  • source_user_password = The password of the source_user account.
  • target_machine = The target computer used in the cmdkey command.
  • target_port = The target port used in the cmdkey command (optional). (E.g. use 1433 for Windows Authentication in conjunction with SQL Server.)
  • target_domain = The domain target_user belongs to.
  • target_user = The target user account used in the cmdkey command. source_user will impersonate this user, when connected to target_machine.
  • target_user_password = The password of the target_user account.
lauxjpn
  • 149
  • 6
0

As a further alternative, I am using the PsExec:

psexec -u otheruser -p otheruserpassword cmdkey.exe /add:server.domain.com /user:username /pass:password

Daniel
  • 111
  • 4