When logging on windows server to check uptime and services, I am being logged through gateway, both server and gateway are require different credentials.
I am working on powershell script that does this automatically, but I can not find way how to use multiple credentials when invoking command.
I am not sure if there is solution on this in powershell
When doing that manually, I am logging directly on server and gateway automatically pops up, asking for credentials, when I enter them, another prompt to server credentials pops up, then I logon on server.
Thanks for advice :-)
$Cred1 = [pscredential]::new($User1,$Password1) #service account to target server
$Cred2 = [pscredential]::new($User2,$Password2) #gateway credentials
Invoke-Command -ComputerName xxx-ScriptBlock { xxx } -credential $Cred1
...is not working with $Cred1, cause gateway requires $cred2.
Related
I have a Windows 2019 container started with a valid CredentialSpec from a valid working gMSA account. It currently hosts a .NET 4.x application on IIS with Windows Authentication working just great. I can also execute nltest commands successfully and communicate to the domain controller.
I want to run a Job or Process as a domain user (MyDomain\UserABC). All of my attempts have failed:
Execute start-process with a credential object errors out with:
he security database on the server does not have a computer account for this workstation trust relationship.
Using a scheduled job as NT AUTHORITY\NetworkService fails to access the web because it is not using the gMSA credentials but the Network Service credentials.
Create a scheduled job with a Domain User results in the same error as above:
he security database on the server does not have a computer account for this workstation trust relationship.
Any other ideas?
Sounds like cached credentials. Maybe you can take a look on this link:
Site single Domain
I fell into a double-hop issue while trying to deploy BizTalk apps(msi) to remote machines via powershell. The only way out of this(double-hop) is to use CredSSP authentication for remote session. The deployment needs to be unattended, but if I try to use CredSSP authentication it asks for credentials in a prompt. Is there any way to bypass this manual input of credentials when using CredSSP? If not, is there any other way delegation of credentials can be done without keeping the credentials in the script file?
You can get around the second-hop issue by using remote delegated sessions.
here is a link to an MSDN article describing how to create these.
Basically, it is the same mechanism that Exchange uses for their remote management sessions. A remote session configuration is created on the target machine, and whatever runs in that session executes under a set of credentials specified in the RunAs parameter of the configuration. When you run something in one of those sessions, you can make one more hop from that machine to another machine without CredSSP because the credential that's actually executing the commands hasn't made a hop yet.
You can get very granular about what scripts, functions, and cmdlets can be run in that session so you can limit it to only being used for a specific purpose. Once you have it set up, you then limit who has permission to use the session by granting the Execute permission for the session to specific groups or users.
I am trying to prepare our environment consisting of Windows XP / 7, Windows 2003 / 2008 for PowerShell remoting. I have configured the WinRM service and listeners as well as a firewall inbound rule through Group Policy following Microsoft Procedures. However, I used the GP Editor on my admin station (RSAT) rather than the one on the DC and it offered one additional configuration option which should have never been configured. Namely the credentials under which the service would run. Untouched it automatically picked up my domain admin account. Now the WinRM service is configured under the wrong account and it won't start up on any of the machines. Server or client. When I try to manually start the service on any machine, I get the following error message:
Windows could not start the Windows Remote Management (WS-Management) service on Local Computer.
Error 1079: The account specified for this service is different from the account specified for other services running in the same process"
After some research and tinkering I learned that the service is supposed to run under the Network Service account with a blank password by default. When I manually change the credentials on any machine to Network Service and clear the password boxes, I get a confirmation popup:
The account NT AUTHORITY\Network Service has been granted the Log On As A Service right.
After that the WinRM service starts up just fine. I need to find a way to remotely change the credentials for this service on multiple machines. Obviously I cannot use PowerShell as the service is a prerequisite for PSRemoting. I did try sc.exe in a startup script through GPO on a test OU with one machine like so:
sc.exe config "WinRM" obj= "Network Service" password= ""
net stop WinRM
net start WinRM
Unfortunately however, it did absolutely nothing. I have UAC enabled on all win7/win2008 machines I also have WinXP and Win2003 boxes.
Does anyone out there have any idea for a solution? Maybe a script that might work? I am not much of a cripting guy, so if you are kind enough to help me out with a script can you also tell me how to use it?
All responses will be appreciated.
To add to this post. the following command will work for accomplishing the above.
sc.exe config "WinRM" obj= "NetworkService"
In testing I found that the NetworkService account actually has no space between the two words, but in GUI it does show space.
I'm a few months late, but hopefully this can help someone. I just resolved this issue in both my test and production environments by configuring the Group Policy preference for the WinRM service and manually entering:
User: NT AUTHORITY\NetworkService
Password: <space>
Exactly. You have to manually enter the account name as I wrote it, and the password is a single space. Other combinations of username and password have not worked for me. If other combinations work, I'd love to know.
I want to run a few scripts on a few servers but the issue is that all of them are on different domains.
If they are on the same domain then I am able to run it is Powershell but across domains how would I do that? Can anyone throw some light on this?
On the server side
Enable-PSRemoting
On Client Side, Execute the following commands:
cd wsman:localhost\Client
Set-Item AllowUnencrypted -Value $true -force
Set-Item TrustedHosts -Value * -force
Then to create session in the server machine from client machine use the following commands:
$cred=get-credential
$Session= New-PSSession -computername Server01 -credential $cred -Port 5985
Enter-PSSession $Session
(Valid Credential on Server machine should be given)
This might be a good application for PS constrained sessions with delegation.
You can designate the credentials that will be used to run the commnads in the session configuration, and limit what can be run in the session, so you can create a session you can connect to without having domain credentials, and within that session you can run just those scripts and they will be automatically run using credentials that are set in the session configuration.
http://ramblingcookiemonster.wordpress.com/2013/07/20/granular-access-via-powershell-remoting/
I don't know if you're talking 2, 20 or 200 servers here (or the number of admins), but what I would do (if I had administrative access to the domains) would be to implement some kind of "administrative execution account" on each domain. I would then build logic to save creds to file on the workstation/management server initiating the connection (if the password is the same across domains it would be very easy - maybe too easy)
It should be easy enough to build logic to pick up the correct credentials file based on the computer domain, construct a credential object, and connect with it -basically some proxy functions for the most common remoting CmdLets like new-pssession and the like.
This would ensure that each operator would have to type in the username/password to each domain manually before using the script (saving the creds to file), which should help prevent unauthorized access.
We're developing a set of applications that need to communicate with each other on the user's session. These applications do not require any administrative privileges to run, but as soon as one of them tries to open an http listener - it fails due to lack of the administrative credentials. On the other hand, since user doesn't have any admin rights, he can't configure an HTTP ACL as well.
Is there any way to allow http/REST communication between the processes on a localhost inside the non-administrative user session?
Example of the apps: a tray app plays a role of a service and multiple sticky-note apps talking to it to save data.
Does it means that Microsoft forces me to use ONLY Named Pipes for IPC in the local user session if the user doesn't have admin rights (can't install with the admin rights)?
I have not personally done this, but I would think that you'd need to do the HTTP namespace/ACL registration in an installer which is running with administrative priviledges.
Use the dos command:
netsh http add urlacl url=http://+:8083/path1 user=USERNAME
NOTE: replace the port, the path and the USERNAME with your own