I am trying to ignore the certificate warning on remote desktop connection - the one in the image:
So far I have found that when I check the "don't ask again" checkbox it is generating registry key over here:
HKCU:\Software\Microsoft\Terminal Server Client\Servers
A new record is generated with the name of the server and key name CertHash that contains a value that is specific for a machine. The key is the same for a machine - if I delete it and check the checkbox the same value is again generated. There is a new value in case I recreate the virtual machine so I think it is something machine specific.
Can someone tell me how is this hash generated so I can populate the key from command line? Adding certificate is not an option and the machines will be frequently regenerated so I need an option to ignore this automatically as I need to connect a user to the machine and run some programs in it.
I know this is an old question. But this may help someone who is looking for the same solution.
Method 1
You may over ride the certificate check for ALL RDP connections (use it at your own risk)
Just add a new registry key as below.
reg add "HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client" /v "AuthenticationLevelOverride" /t "REG_DWORD" /d 0 /f
Method 2
Considering if you have admin rights on the remote machine, you could actually get the crethash value from the remote machine using the below wmic command. So you could make a small batch file to get this value before you launch the mstsc and add this value in registry. I haven't included the complete batch file but thats the idea.
wmic /node:Testserver /namespace:\\root\CIMV2\TerminalServices PATH Win32_TSGeneralSetting get SSLCertificateSHA1Hash
See this link.
Run Microsoft Management Console (mmc) and add the Certificates snap-in if you don't already have it for the computer you would like to connect to. In the Certificates, find the Remote Desktop folder, and open the certificate in that folder. On the Details tab, scroll down to find the Thumbprint value - this is the value you should copy to the registry.
Related
I turned off (set 0 value in "Enabled") AES 128\128 cipher, and SHA, SHA256, SHA384, MD5 hashes in windows server 2012 R2 registry (hosted on aws).
Then I used command "Restart-Computer" and cannot to login via RDP to my server. How can I restore RDP connection ? and connection at all ?
Thanks in advance.
There is the answer from aws support:
There are 3 methods using which you can revert the registry changes. Request you to follow the Methods in a sequential manner if the current Method fails.
Method 1 - Connecting to the registry of the problematic instance from another instance in the same VPC and revert the changes. (You can launch a test instance temporarily in the same VPC if you don't have any existing instance (s) in the same VPC.)
1. Open Registry Editor from the working instance which is in the same VPC as problematic instance.
2. Click on File->Connect Network Registry.
3. Enter the FQDN of the server and Click on Ok.
4. Enter the credentials and Click Ok.
5. Now Expand the Remote computer (Problematic instance) hive and revert the changes.
Method 2 - Access the problematic instance using TightVNC.
1. Ensure that the non-working instance has IAM role assigned to it with Policy named "AmazonEC2RoleforSSM" attached to the IAM role. To create and Attach an IAM role See Link https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html & https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html#attach-iam-role
2. Now Install TightVNC on a working instance which is in the same VPC and subnet. Link to download TightVNC MSI: https://tightvnc.com/download.php 3. Right click on the MSI > Properties > Under the General Tab > Ensure the file has been Unblocked by Ticking the Unblocked check box.
4. Now copy the msi file on the problematic instance as well. Copy the MSI to C$ on the problematic instance (\\c$). For simplicity sake rename the MSI to TightVNC64.msi 5. Now go to https://console.aws.amazon.com/systems-manager
6. On a Left Pane, Under Actions, Click on Run Command.
7. Click on Run Command and Search for Command Document named "AWS-RunPowerShellScript".
8. Select AWS-RunPowerShellScript and under Command Parameters paste the below command:
Start-Process -FilePath "C:\TightVNC64.msi" -ArgumentList ("/q SET_PASSWORD=1 VALUE_OF_PASSWORD=YouSecurePasswordGoesHere SERVER_ADD_FIREWALL_EXCEPTION=1") -Wait -PassThru
9. Scroll down and Under Targets, Select the Problematic Instance.
10. On the bottom of the page Click Run.
11. Wait for command status to get successful.
12. Launch the TightVNC Viewer on your working instance and provide the IP/FQDN of the problematic instance followed by the credentials that you have provided under command in Step 8.
13. You will be connected to the Instance and can make changes in the registry.
Method 3 (Method will require Stop and Starting of the instance.)
1. For Detaching the Root Volume from the problematic instance and Attach it to the working instance request you to please watch video from 1:47 to 3:40 in following article:
https://aws.amazon.com/premiumsupport/knowledge-center/ec2rescue-windows-troubleshoot/
2. Open Disk Management Console (diskmgmt.msc) and Right Click on the Disk showing Offline status and Click Online.
3. Once the Disk is Online, Go to My computer and make a note of the Drive letter of the disk which you have attached.
4. Open Registry Editor and Select HKLM.
5. Click on File and Load Hive. Provide any name for eg. "Recovery".
6. Expand the "Recovery" key and revert the changes i.e. Enable the value for AES 128\128 cipher, and SHA, SHA256, SHA384, MD5 hashes.
7. Once all the changes are made, Select the "Recovery" Key and Click on File and Unload Hive.
8. Open the Disk Management console and take the disk offline.
9. Now for re-attaching the root volume to your problematic instance, request you to please watch video from 08:02 to 9:28 using the same link: https://aws.amazon.com/premiumsupport/knowledge-center/ec2rescue-windows-troubleshoot/
Additionally, first of all you should ensure that yuor IP-address in range of inbounds-rules of the failured instance.
in my case I, first of all tried to use amazon app "app2rescue" for diagnostic failured instance, bit it didn't show any helpful (did show only few possible issues with firewall, but it's not related to my issue).
Then I tried the first method - but I could not get access to remote registry (I assume that on the target machine was disabled "Remote registry" service).
And finally, I used the third method and it fixed my problem. During this operations I faced only one issue - before failure I was changing the currentControlSet, and when I attached volume to temp server, I was trying to find exactly it, but found out that currentControlSet is enabled only when this registry is used for current OS (when this registry works), so I found my problem-parameters (sha, md5 etc) in the controlSet001 instead of currentControlSet.
I'm trying to connect to an admin server in WLST using config and key files. There are no error messages but I am prompted for a username and password. These files were created (by another developer who is long gone[1]) with the storeUserConfig() command. My call to connect looks something like this: connect(userConfigFile=configFile, userKeyFile=keyFile, url='t3://somehost:7031')).
Is there some restriction in using these files, such as it can only be used on the host where created, or it needs access to the domain's boot.properties file?
Note: I'm trying to connect to an admin server on a different host and non-standard port (e.g. not 7001). The server I am running WLST on and the remote host are the same version of Weblogic.
Some of the things I have tried:
verified that these files appear correct, the key file being binary data and the config file having a line for "weblogic.management.username={AES}..." and "weblogic.management.password={AES}...".
verified that there is a server on the specified port by entering a known login and password that is successful
specified the admin server in the connect parameter
turn on debug(true); the only output is <wlst-debug> connect : Will check if userConfig and userKeyFile should be used to connect to the server and another line giving the path to the userConfig file
turn on Python logging in jython with -Dpython.verbose=debug; nothing relevant to decryption operation
Munging the key or the config files generates no error messages and behaviour as above
[1]: These files are still used today by other existing WLST scripts. However, these scripts are so convoluted and deliberately obfuscated that they are very difficult to reverse-engineer how connect() is being called.
You do not need to access to the domain's boot.properties file. You just need to make sure the configFile and keyFile pointing to the right files. FYI, here is one of the commands we are using:connect(userConfigFile='./user.secure',userKeyFile='./key.secure',url='t3://somehost:7001')
Have you check the network connectity that might be having a firewall in between that troubling you, check the traceroute from the script machine to the Remote machine. Recently I have faced simalar issue. once the routing table updated with allow the WL admin server port everything got set.
Hope this could helps you!
I had this problem too. In a script, I exported the Linux variables userConfigFile and userKeyFile. Then I connected by running:
url='t3://localhost:7002'
userConfigFile='$userConfigFile'
userKeyFile='$userKeyFile'
connect(userConfigFile=$userConfigFile, userKeyFile=#userKeyFile, url=url)
That all worked in a script, but would not work interactively. I changed to doing the following:
url='t3://localhost:7002'
userConfigFile='/users/me/weblogic-2014/weblogic-admin-WebLogicConfig.properties'
userKeyFile='/users/me/weblogic-2014/weblogic-admin-WebLogicKey.properties'
connect(userConfigFile=userConfigFile, userKeyFile=userKeyFile, url=url)
And that worked interactively.
I'm writing a script that periodically checks that certain services are running on remote workstations. I'm having a devil of a time getting an "SC \workst1 query" command working from one test machine to another. Both machines are running XP pro SP3. Neither is part of a domain. Both are in the same workgroup, and the administrator accounts have the same passwords.
I keep getting the "[SC] OpenSCManager FAILED 5: Access is denied" message, from either workstation to the other. I have tried using elevated privileges on both. Windows firewall software is turned off. There are no messages are showing up in the Event security logs. When (as administrator) I try going to "Computer Management" -> "connect to another computer" and access the remote services I get "Error 5 Access is denied".
I can set up a filesystem share between the two machines successfully, and "net use \workst1\IPC$ /user:Administrator" completes successfully, but the SC query still fails. I'm using IP addresses and not hostnames in these commands, but that doesn't help. I don't know what else to try. Thanks for the help.
Try to run the commans as a Administrator
start-> (type cmd in search box), right click on cmd, Run as a administrator -> execute your command
You must have administrative rights on the remote machine.
Moreover you must access the drive before calling "sc".
This can be achieved in command line using
net use \\remotemachine\admin$ <password> /user:<username>
admin$ is a hidden shared drive accessible to administrators that "sc" uses to control services.
I was having the same issue today trying to check if a service is enabled remotely.
I could solve the issue modifying the User Account Control for remote restrictions in windows:
To disable UAC remote restrictions, follow these steps:
Click Start, click Run, type regedit, and then press ENTER.
Locate and then click the following registry subkey: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
If the LocalAccountTokenFilterPolicy registry entry does not exist,
follow these steps:
On the Edit menu, point to New, and then click DWORD Value. Type LocalAccountTokenFilterPolicy, and then press ENTER.
Right-click LocalAccountTokenFilterPolicy, and then click Modify. In the Value data box, type 1, and then click OK.
Exit Registry Editor.
More information about this solution in this site.
Your user should be remote, from Manage and Local users and groups
The UAC issue is obvious you have to pull down the lever for UAC setting
Also while installing the services you can use the following command
SC create SERVICENAME DisplayName= "DISPLAYNAME" binPath= "PATH OF EXE" start= disabled type= share
We are upgrading the server from Windows 2003 to 2008. As part of the process, I need to configure a port with a SSL certificate. When I ran the following command:
netsh http add sslcert ipport=1.2.3.4:8000 certhash=certificatehash appid={someGUID}
I got the following error:
SSL Certificate add failed, Error:
1312 A specified logon session does
not exist. It may already have been
terminated.
When running the command prompt with an administrator does not resolve the issue. Notice that I did not run into this issue on Windows 2003 (using httpcfg) and that things work well there.
Has anyone encountered this issue? Thanks.
the 1312 shows up at several occasions. aside from typos on the commandline, the other most common are:
- the certificate is not in your certificate store at all (check with MMC and 'certificates' snap-in)
- the certificate is in the wrong store: it should be in the store of 'local computer' not 'local user' (remember to choose proper account when activating the snapin inside the MMC)
- the certificate doesnt contain a Private Key (open the certificate and check whether it contains only public, or both keys)
I've spent over 1.5 hours before I found out that I've had generated a certificate succesfully, but misplaced some switches and it got written to a file without the private key:)
Are you running from an elevated command prompt (not just as an admin)?. There's an open source GUI tool that drives the HTTP config APIs directly- I use it on 2008 R2 with no trouble (it auto-requests elevation via UAC). I've had mixed results with netsh/httpcfg. This one always works for me (and it behaves the same everywhere).
I got a CVS connection string, here it is :
:ssh;username=dummy;password=dummy;hostname=repos.mooo.com:/home/projects/repos
How can I get project code using WinCvs, I've just installed it and I can't find howto online, maybe some help, thank you
In WinCVS 2.1, Click the Remote menu item, and select Checkout code.
On this screen click the ... next to CVSROOT, and you should bring up a dialog allowing you to enter the parameters you mention in your question (this is a bit easier to do than trying to enter the string manually).
You'll also need to enter a module name on the server, and a directory to check our the code into, but once you do this and click OK you should start checking out the code.
You have to use WinCVS with the PuTTY SSH tools to be able to connect securely. Check out the description here
The site covers the following steps
Download the required materials (WinCvs, PuTTY).
Install the PuTTY SSH suite.
Install WinCvs.
Generate a SSH key pair.
Upload your SSH key pair.
Configure Pageant (a component of PuTTY).
Test your automated authentication.
Configure WinCvs.
Start using WinCvs