Powershell RDP authentication on domain - windows

I'm trying to create a powershell script to start and authenticate an RDP session to multiple machines by IP range.
I'm very new to powershell, and windows/domain scripting in general.
I have written a powershell script using Connect-Mstsc that allows me to enter my username and password, as well as an IP range and it works, opens a session to all machines in the range and uses the credentials to authenticate me to connect to the machines.
My issue is, I'd like this script to perform LOCAL authentication on the machines as well, right now, when it runs, if I give it a range of say, 5 IP addresses, it opens 5 RDP sessions to the machines, which is good, but each session is sitting there at the login prompt. I would like it to automatically log me in on each machine locally using the same user/password I supply, and then hopefully execute a batch file from a network share on login.
I've done quite a bit of research on this, and I've come up empty, and given my beginner experience level I'm not sure I'm even looking in the right places.

Related

Script to Log into several user accounts

We manage several laptops that are used for emergency situations and thus are rarely used (knock on wood).
When we start up these laptops periodically to run windows updates, we also sign in with several user accounts for each laptop in order to keep the profile up to date.
Is there a way to automate the logging in of each account with a script?
For example, I could log in as administrator, run the script and the laptop would do the following:
Log out my administrator account,
sign in with useraccount 1, log out
sign in with useraccount 2, log out
sign in with useraccount 3, log out
I havent had much luck in googling this type of thing and was hoping someone here might have an idea.
I simply cant find a script that logs in with a user account.
The closest I can find is recommending auto signin but that only applies to one account and not what I need for this task.
Globally, you can't do that: it would break security if you were allowed to interact, programmatically, with the login screen.
IF it's possible, I would look to a way to do the login to remote machine through either Telnet (not recommended! but can be done with standard Windows tools) or SSH (will need a SSH server). If you can do the upgrade this way, then you're saved, in particular with SSH because you can avoid passwords' sharing through key exchange - probably won't work with domain accounts, however, but local accounts will be fine.
Otherwise, if you require to really open a Windows session, best you can do, IF your configuration allows it AND if it works (regarding the profile's update) is to connect through RDP (Remote Desktop) to each laptop, with each login.
You'll need to establish a RDP connection to each laptop from a "pilot" PC, save each connexion individually within a .rdp file, saving password inside the connection file.
Then, you can launch the connection with the command mstsc <machine+account>.rdp to establish a connection. A bit later, you can kill the connection (with either taskkill or through a pilot process / tool, I would use AutoIt for this preferably).
If password saving is an issue, then each employee should have its own set of RDP files. Through something like Autoit, in particular, you can input the password once, and fill automatically each password prompt.
The tricky part would be to know when it's time to close the remote desktop. I would try to automatically execute a command to distant computer that would reboot it once done, so your remote desktop would close automatically.
Anyway, it will be a real gas plant to implement all this in a smooth process...

passing username/password to openVPN CLI directly

I want to make a script that asks the user for username and password and uses these for a few things at once, including connecting to OpenVPN without needing to either
store the password on the disk
ask the user for the data many times over
for example you can run net use with user and password to mount shares, however openVPN seemingly only has an option to pass a file with username and password.
On Linux there seemingly are solutions like this, however I don't seem to find anything similar for windows yet.
Is there a solution?

Lost .pem file. Need help connecting to EC2 remote server

My secretary created a new instance in Amazon using their EC2 server but lost the .pem file. Doing research online I was able to go to the instance system settings/get system log and retrieve some type of password there. The instance system log shows something like this:
2019/04/15 12:15:19Z: Username: Username
2019/04/15 12:15:19Z: Password: <Password>
It is a very long code of random characters.
Is there any way I can use this to log in via remote desktop or is there a way to decrypt it? I tried several decryption methods online and they said this was not a valid "hash"...whatever this means. I am not a technical person so I need hopefully a response in layman terms.
It appears that you are connecting to a Windows instance. When a new Amazon EC2 Windows instance is launched, a program on the AMI (disk image) automatically generates a random Administrator password. This is done so that you can access the instance, but nobody else can.
To keep the password secret, the program encrypts the password with the keypair nominated when the instance was launched. The encrypted password is passed back to AWS via the console. That is the string of 'random characters' you saw.
To decrypt the password, you can use the Get Windows Password feature, which requires you to supply the nominated keypair. It will then decrypt the password, which can be used to login to the instance as Administrator.
Since you no longer have the keypair, you cannot decrypt the password and therefore cannot login to the server. This is good! This proves that security works, because you would not want other people to be able to login to the server.
So, can do you regain access?
Refer to the steps on: I need to reset the administrator password on a Windows Server instance in Amazon EC2
Basically, there are two methods:
If Systems Manager is enabled for the instance, you can run a "rescue" script
Otherwise, there is a series of scripts that assist with the process of:
Detaching the disk
Attaching it to another instance
Resetting a configuration on the disk
Reattaching the disk to the original instance
The second process is a bit like plugging a USB disk into another computer to change a file (except that EC2 disks are managed differently).

Create RDP session programmatically

We have a remote support tool that allows us to connect to machines behind a NAT firewall. Once connected, we can choose to either connect to the console session or to any active RDP session from a list. We cannot connect to inactive/disconencted RDP sessions, and the tool has no way to create new loopback/redirected RDP sessions. What we would like to do is find a way to spawn these RDP sessions via a script or a small application so that the support tool can detect them and allow us to connect. The motivation to get this working is to be able to have multiple techs access the same server simultaneously (up to one active console session and two active RDP sessions, all at the same time, for a total of three techs).
If we log on to the console session of the target servers and then RDP to the loopback, we see the new RDP session in our support tool, which we can then select and connect to. The problem is that this RDP session creation depends on the console session. It also gives the console session access to the RDP session, and if the RDP window is minimized then the output/input for that session in our support tool is frozen. I was able to use the PS script Connect-Mstsc (mostly just a wrapper for mstsc.exe but with support for adding creds) to create RDP sessions from another random server on the remote internal network to the target server we want to create a new RDP session on. This works well from an automation standpoint but we have the same limitation described above - it only works if run interactively. If you run this from a SYSTEM shell remotely, the RDP session never appears in our support tool.
The remote support tool in question is ScreenConnect and our servers are all Windows, mostly 2012 R2, all AD environments. I think the core challenges to this solution are getting the RDP sessions created and active in a non-interactive fashion, and then preventing RDP from freezing the session input/output.

Workstation has lost the trust relationship with the domain

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).

Resources