Monroe406
asked on
Locked out of Windows 2016 server after changing RDP listening port
I just purchased a Dell Windows 2016 server. In trying to tighten down the hatches and bullet-proof the server I did the following:
1) Create a new account with Administrator privileges
2) Rename the original Administrator account to Administrator(off)
3) Create a 3rd, new dummy account and call it "Administrator" and then disabled that account
I did all of this via Remote Terminal Services using the new account created in #1 above.
Everything was fine. But here's went things went awry.
I decided to change the port number from 3389 to 53389 using a REG file that I had export from a Windows 2003 server after performing the same port numbering switch. I suspect that is where my mistake came about. I should have opened the Registry Editor and manually changed the "PortNumber"=dword:0000d08
Problem is, it is impossible to access the new server via Remote Terminal Services. And yes, I did try logging in with the new port number appended to the server's IP:
192.168.1.2:53389
Sadly, there is no response. I tried 192.168.1.2, and 192.168.1.2:3389 just in case the REG import failed, but everything fails.
When I go to the physical server and try to log in using a keyboard, I cannot change the user. The server doesn't offer me the option to log in using the new account I created in #1 above. It's stuck with "Administrator", which of course, I had disabled.
Any suggestions on how to recover from this mess?
1) Create a new account with Administrator privileges
2) Rename the original Administrator account to Administrator(off)
3) Create a 3rd, new dummy account and call it "Administrator" and then disabled that account
I did all of this via Remote Terminal Services using the new account created in #1 above.
Everything was fine. But here's went things went awry.
I decided to change the port number from 3389 to 53389 using a REG file that I had export from a Windows 2003 server after performing the same port numbering switch. I suspect that is where my mistake came about. I should have opened the Registry Editor and manually changed the "PortNumber"=dword:0000d08
Problem is, it is impossible to access the new server via Remote Terminal Services. And yes, I did try logging in with the new port number appended to the server's IP:
192.168.1.2:53389
Sadly, there is no response. I tried 192.168.1.2, and 192.168.1.2:3389 just in case the REG import failed, but everything fails.
When I go to the physical server and try to log in using a keyboard, I cannot change the user. The server doesn't offer me the option to log in using the new account I created in #1 above. It's stuck with "Administrator", which of course, I had disabled.
Any suggestions on how to recover from this mess?
Don't rename and continue to use the administrator account. The Admin SID is well known (default -500). DISABLE the built in admin account and create a new admin account for you.
Don't change RDP port as Cliff suggested. Don't expose ANY RDP to the internet. Require VPN or other remote connectivity (like RDP Gateway) to get in to the system. Setup firewall rules that BLOCK everything EXCEPT the remote addresses that are ok. (If you come in from "anywhere" then that may not be an option - all the more reason for VPN).
Don't change RDP port as Cliff suggested. Don't expose ANY RDP to the internet. Require VPN or other remote connectivity (like RDP Gateway) to get in to the system. Setup firewall rules that BLOCK everything EXCEPT the remote addresses that are ok. (If you come in from "anywhere" then that may not be an option - all the more reason for VPN).
ASKER
>> Don't rename and continue to use the administrator account. <<
Huh? I already explained that this had been already done in #2.
>> The Admin SID is well known (default -500). <<
I don't have a clue what that is supposed to mean. What's an "Admin SID" and what is -500 supposed to do for me?
Huh? I already explained that this had been already done in #2.
>> The Admin SID is well known (default -500). <<
I don't have a clue what that is supposed to mean. What's an "Admin SID" and what is -500 supposed to do for me?
ASKER
>> You can certainly log in to the console session with other accounts. I'm guessing you just aren't quite noticing where to do that. <<
There's nothing except the words "Administrator" above the password field. The only two other options is "Connect to internet" and "Ease of Access" icons at the bottom lower right of the screen. What else is there to choose from?
There's nothing except the words "Administrator" above the password field. The only two other options is "Connect to internet" and "Ease of Access" icons at the bottom lower right of the screen. What else is there to choose from?
ASKER
I should also have added that in step #2 above (Rename the original Administrator account to Administrator(off) ), I also disabled this user.
"Huh? I already explained that this had been already done in #2."
No. Lee is saying that your steps #2 and #3 aren't increasing security. You renamed the admin account. Don't.
You then created a dummy account. Don't.
The word "Administrator" isn't what matters. Windows uses internal "security IDs" (SIDs) to identify accounts. The first administrator account is always the same ID on every system, thus the -500 shorthand. It is well known. Renaming it to "Adminstator(off)" is again faux-security, not real security. It just needlessly complicates things. Anybody an still find that account with the SID, and if you didn't disable it, doesn't help. And the dummy account also doesn't help.
You can't "harden" a server ad-hoc with random wives' tales. None of this was ever good security practice in knowledgeable circles, which makes me think you are getting bad advice from somewhere.
-Cliff
No. Lee is saying that your steps #2 and #3 aren't increasing security. You renamed the admin account. Don't.
You then created a dummy account. Don't.
The word "Administrator" isn't what matters. Windows uses internal "security IDs" (SIDs) to identify accounts. The first administrator account is always the same ID on every system, thus the -500 shorthand. It is well known. Renaming it to "Adminstator(off)" is again faux-security, not real security. It just needlessly complicates things. Anybody an still find that account with the SID, and if you didn't disable it, doesn't help. And the dummy account also doesn't help.
You can't "harden" a server ad-hoc with random wives' tales. None of this was ever good security practice in knowledgeable circles, which makes me think you are getting bad advice from somewhere.
-Cliff
ASKER
>> You renamed the admin account. Don't. <<
>> You then created a dummy account. Don't. <<
I thought I made it pretty clear that these events have already taken place. Telling me not to do something after they've already done doesn't really help the situation.
>> You then created a dummy account. Don't. <<
I thought I made it pretty clear that these events have already taken place. Telling me not to do something after they've already done doesn't really help the situation.
ASKER
>> which makes me think you are getting bad advice from somewhere. <<
I got it from a 500 page book on Windows Server security.
I got it from a 500 page book on Windows Server security.
ASKER
>> which makes me think you are getting bad advice from somewhere. <<
Fine. I've gotten bad advice. But how does all of this finger wagging help my situation?
Fine. I've gotten bad advice. But how does all of this finger wagging help my situation?
As for logging as another user, lower left. I have two 2016 server screenshots side by side so you can see.
The first is a console session when no user is logged in. A list of users is on the left. Even if you set a group policy not remember users, "other user" is an option.
The second is the console session if a user logged in then locked the station. It defaults to the logged in user, but the "switch user" button is available to...switch users. And nobody should be leaving a console session locked like that anyways. Bad physical security there.
Either way, those should be available. If not, something has *really* gone sideways with your install. Sounds like you are early in the process. Wipe and reinstall might be easier than figuring out what else got broken.
The first is a console session when no user is logged in. A list of users is on the left. Even if you set a group policy not remember users, "other user" is an option.
The second is the console session if a user logged in then locked the station. It defaults to the logged in user, but the "switch user" button is available to...switch users. And nobody should be leaving a console session locked like that anyways. Bad physical security there.
Either way, those should be available. If not, something has *really* gone sideways with your install. Sounds like you are early in the process. Wipe and reinstall might be easier than figuring out what else got broken.
It helps you not compound mistakes with more mistakes. But hey. You came here asking for help. Not the other way around. Fine by me. I'm out.
ASKER
>> Either way, those should be available. If not, something has *really* gone sideways with your install. <<
There are no buttons at the lower left of my screen when I turn on the monitor to the server.
The OS install was performed by Dell.
There are no buttons at the lower left of my screen when I turn on the monitor to the server.
The OS install was performed by Dell.
ASKER
>> It helps you not compound mistakes with more mistakes. <<
It is impossible to compound the mistakes you are telling me not to make seeing how the mistakes were already made before I came to EE.
It is impossible to compound the mistakes you are telling me not to make seeing how the mistakes were already made before I came to EE.
Reload the OS - you shouldn't be using a Dell preloaded version anyway. Do you really want to use a system that someone else has configured and potentially installed things on? Dell doesn't necessarily have the reputation lenovo gained with superfish (http://www.slate.com/articles/technology/bitwise/2015/02/lenovo_superfish_scandal_why_it_s_one_of_the_worst_consumer_computing_screw.html) but that doesn't mean they couldn't have done something like it or started to. A clean install YOU have done helps ensure the server is running nothing but what you want and gives you a greater familiarity with both the current version of Windows and the hardware you're installing on. You should also be virtualizing the server (though purchasing the OS with the hardware now limits your disaster recovery abilities since you are not allowed to move the VMs to another server).
If you insist on going with a preloaded system, then you can try to reset the passwords and enable the account using net commands and booting a "hacked" system - follow Scorpion Software's video #105 on "Crack the Cred" - it's 5 minutes long and shows you how to recover a password (it's for a Domain controller but works just fine on non-DCs). https://www.youtube.com/watch?v=Yxq4ifyr8_w
I'd also like to know what book you read that said to do these things.
If you insist on going with a preloaded system, then you can try to reset the passwords and enable the account using net commands and booting a "hacked" system - follow Scorpion Software's video #105 on "Crack the Cred" - it's 5 minutes long and shows you how to recover a password (it's for a Domain controller but works just fine on non-DCs). https://www.youtube.com/watch?v=Yxq4ifyr8_w
I'd also like to know what book you read that said to do these things.
Bottom line is, now you have no option like edit registry.
It's going to be hard since you can't run regedit on this computer.
So you need to run software that will load registry from this computer, long time ago I was using software called Winternals, but I don't think it will support new Windows and raid configuration if you have.
So you need to copy SOFTWARE file from C:\Windows\System32\config
open it on other computer
How to open ?
Open regedit
Select HKEY_LOCAL_MACHINE
go to File
Load HIVE and select SOFTWARE copied from server
and navigate to
[HKEY_LOCAL_MACHINE\SOFTWA
If your old administrator was renamed to let say Admin1 with password 123456 and your domain was called DOMAIN1 you need to edit this entries
"DefaultDomainName"="DOMAI
"AutoAdminLogon"="1"
"DefaultUserName"="Admin1"
"DefaultPassword"="123456"
save, copy over back to server and restart server.
Windows should autologon to Administrator profile, so then you can remove registry entries and revert disaster.
Another think, if your server was part of domain, you can try open registry from other computer in your LAN
Open regedit
Select HKEY_LOCAL_MACHINE
go to File
connect to Network Registry
Navigate or put server name and PRAY to be able to open :)
It's going to be hard since you can't run regedit on this computer.
So you need to run software that will load registry from this computer, long time ago I was using software called Winternals, but I don't think it will support new Windows and raid configuration if you have.
So you need to copy SOFTWARE file from C:\Windows\System32\config
open it on other computer
How to open ?
Open regedit
Select HKEY_LOCAL_MACHINE
go to File
Load HIVE and select SOFTWARE copied from server
and navigate to
[HKEY_LOCAL_MACHINE\SOFTWA
If your old administrator was renamed to let say Admin1 with password 123456 and your domain was called DOMAIN1 you need to edit this entries
"DefaultDomainName"="DOMAI
"AutoAdminLogon"="1"
"DefaultUserName"="Admin1"
"DefaultPassword"="123456"
save, copy over back to server and restart server.
Windows should autologon to Administrator profile, so then you can remove registry entries and revert disaster.
Another think, if your server was part of domain, you can try open registry from other computer in your LAN
Open regedit
Select HKEY_LOCAL_MACHINE
go to File
connect to Network Registry
Navigate or put server name and PRAY to be able to open :)
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
>> So you need to copy SOFTWARE file from C:\Windows\System32\config
Thanks, but it is impossible to get to drive C when you boot from a flash drive. Drive C: simply shows up as a RECOVERY drive.
Thanks, but it is impossible to get to drive C when you boot from a flash drive. Drive C: simply shows up as a RECOVERY drive.
When you boot to an alternate boot media, the existing C: drive might be D: or E: or F: etc. Most people can tell by size and looking at the contents of the drive with DIR in a command prompt.
ASKER
>> and navigate to [HKEY_LOCAL_MACHINE\SOFTWA
This part is unclear. There is no such subkey under the newly opened hive. Here is all that you have well you open the SOFTWARE file as a hive, with "key name" = DELL.
This part is unclear. There is no such subkey under the newly opened hive. Here is all that you have well you open the SOFTWARE file as a hive, with "key name" = DELL.
ASKER
>> When you boot to an alternate boot media, the existing C: drive might be D: or E: or F: etc. <<
Turned out drive C was drive X.
Turned out drive C was drive X.
ASKER
>> If your old administrator was renamed to let say Admin1 <<
But the old (original) administrator account was disabled. It's not an issue of me forgetting the account name or password, but rather, the original administrator account was renamed and disabled and the boot up login window doesn't permit any means to switch users.
But the old (original) administrator account was disabled. It's not an issue of me forgetting the account name or password, but rather, the original administrator account was renamed and disabled and the boot up login window doesn't permit any means to switch users.
ASKER
Perhaps it might be better if I had a virgin key for HKEY_LOCAL_MACHINE\SYSTEM\
ASKER
>> save, copy over back to server and restart server. <<
Unfortunately that is not possible seeing how the SOFTWARE file is in use even when you boot from a flash drive and choose the TROUBLESHOOT > COMMAND PROMPT option.
Unfortunately that is not possible seeing how the SOFTWARE file is in use even when you boot from a flash drive and choose the TROUBLESHOOT > COMMAND PROMPT option.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Dont change RDP ports. Security by obscurity isn't real security. It just makes things harder in a crisis.