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.