I’m trying to copy some files from a domain-joined computer, to a non-domain-joined server (it is not on a domain at all). Using PowerShell 5.1.
I want to do this with a script run from a scheduled task, so prompting for the password won’t work. To deal with this I have created a PSCredential object with the Username and Password fields populated. For the username I am using ‘servername\username’ as it is an account local to the remote system. The password is being retrieved dynamically from a PIM solution and is already in PSCredential format. The credential object is created using:
New-Object System.Management.Automation.PSCredential -ArgumentList (“servername\username”, <System.Security.SecureString value>).
I am trying to do this as simply as possible. I looked at just using Copy-Item, as well as New-PSSession and New-PSDrive. I landed on using:
New-PSDrive -Name “DriveName” -PSProvider Filesystem -Root “\\server\path” -Credential <PSCredential object>
Once that completes, I can use Copy-Item to copy files to the remote system without having to authenticate again. (Note that I don't directly reference the PSDrive here, it was just a way for me to create a transient, authenticated session to the remote computer.)
Copy-Item -Path <local source path> -Destination "\\server\path" -Recurse -Force
All of this actually does work – however the issue is that before logging in using the user/pass stored in the PSCredential object, the system first tries an NTLM login using my local domain account (the one running the script). After that tries about 3x and fails (the remote server has no way of validating my domain account), only then does it use the creds in the object.
Not necessarily the end of the world, but it does waste some time, and on top of that it also fires all kinds of alerting within our SOC team as it generates a bunch of failed logins to the off-domain computer, all coming from my domain account.
Is there a way to avoid that initial NTLM auth attempt with the domain account, and just jump straight into using the ‘servername\username’ account that is local to the remote system? Or, am I doing this completely wrong and there’s a better way? :)
Thanks!
(P.S. Also posted here: https://forums.powershell.org/t/copy-item-to-non-domain-computer/16721/4)
Related
if i change my password in my domain join computer to sync we need to lock and unlock with the new password.
How can I sync the password without having to do that?
I am trying:
$securepwd = ConvertTo-SecureString $pass -AsPlainText -Force
$Credential = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList domain\$pass, $Securepwd
Start-Process "notepad.exe" -WorkingDirectory "C:\Windows\system32" -Credential $Credential
Please let me know if this
To the best of my knowledge, you can't do this.
Here's why:
A decent amount of information is attached to a few low-level windows objects that are initialized either at boot or session start.
What's a session? Well, a session starts when a user logs into or unlocks a given system.
When the session starts, a good amount of information will be cached, like, say:
Your permissions as a user
Your authentication information
When your password expires
etc (actually listing all of these things would make it a massive answer).
To complete a change that involves both your box and the domain controller, you'll need to refresh this information. It would be incredibly bad security to allow two different versions of you to talk to the domain controller. The 'old' session with an out-of-date credential needs to be killed.
So you need to lock and unlock the computer to refresh your session, or otherwise force a reauthentication.
If you try to stop any of the processes that control authentication, such as lsass.exe, your computer will force a reboot immediately.
I have a windows vm and have created an Admin user, let's say - AdminUser. I have mounted an azure file share to that user to Z: drive. The share can be accessed by unc path or the drive path. I also have a c# utility that checks if path exists and it returns true when I run it. This is all good. Now when I created a windows service with that utility and with same user credential, it throws an error that the path doesn't exist.
Things to note -
The service user or the user I used to login is a local adminstrator user and while creating the service, I had provided as "./AdminUser" to CreateService. Also provided password to config.
The VM is also connected to a domain. So I have users from default-domain\* and connected-domain\*. The connected-domain linked to an azure active directory.
Is there any other type of user I need to set as log on to service?
I can see here it says the local user can't access network resources but I am wondering since I mounted the path with proper credentials, does this matter?
Update:
Got the same issue when using running as with the exe.
runas /user:USERNAME “C:\full\path\of\Program.exe”
We have to use cmdkey to store the credentials that can be used by SMB later. Launch a cmd.exe with the user that you want to use for the service using either context menu or command e.g.
runas /user:default-domain\domainServiceUser cmd
Then in the new command shell use cmdkey
cmdkey /add:<storagteAccountName>.file.core.windows.net\<shareName> /user:AZURE\<storageAccountName> /pass:<storageAccountKey>
Rerun the service and it should work.
If you want to also mount this as a persistent drive, you can use
Command Prompt
net use z: \\<storagteAccountName>.file.core.windows.net\<shareName> /persistent:yes
Powershell
New-PSDrive -Name Z -PSProvider FileSystem -Root "\\<storagteAccountName>.file.core.windows.net\<shareName>" -Persist
Make sure that the user is exactly the same that would be used for the windows service including the domain i.e. use default-domain\domainServiceUser or ./AdminUser for running the cmdkey.
Though the user account is same, when the windows service runs as a 'user' the logon session that it gets is different than the interactive user session (which has the Z drive). Unless you programmatically load the Azure fileshare as a network drive in your code that is part of the Windows service, you won't be able to access it.
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.
Ok here is a tuffy.
I know that to rebuild the trust relationship you have to logon to the workstation as a local administrator and disjoin, then rejoin the domain.
My question is, is there a way to rebuild the trust relationship remotely? Does anyone have a script, utility, application or command that will rebuild a lost trust relationship?
Frequently (for us) the source of the problem behind "trust relationship" issues is that the machine account AD password is out of sync (the machine believes it to be one thing, the domain controller(s) believe it to be something else) and the machine is unable to authenticate to AD.
There's no need to disjoin first if the only thing that needs to change is the password. This can be fixed relatively easily by invoking the JoinDomainOrWorkGroup method of the Win32_ComputerSystem class. The catch is that the process must be run from the machine you wish to (re)join to the domain (otherwise, the machine account password won't get updated).
It can be done easily enough in PowerShell. Something like this (adapted from this TechNet contribution) would suffice:
$CS = Get-WmiObject Win32_ComputerSystem
$CS.JoinDomainOrWorkgroup($Domain,'','',$null,33)
That will join the machine to the domain using an existing machine account. You may have to specify a user and password, depending on how you get shell access to the remote machine.
Running it remotely does not have a one-size-fits-all solution. I usually use PSExec to get remote shell access and invoke the PowerShell command (using -EncodedCommand to negate the need for quoting).
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.