Account Lockout - Group Policy Management. Will the policy affect the original user?

Question

One day I was going through the event log for a client of ours due to reduced performance during their RDP Connection. The Event log I was reviewing was that of the Office PC of which the user connects to from their home. There were no issues with the device, however, I saw that there was disconnect from the RDP by a multitude of IP addresses that did not belong to any of the machines owned by the office. We our in the process of creating a custom port once we install a Sonicwall TZ300 rather then using the standard Open port 3389 for RDP. One of the other provisions I wanted to consider was implementing an account lockout policy, but I'm curious as to whether or not this would lock out the original user. Hopefully this was informative enough.

Answer 1

Yes, as this is applied per-user, as in, the account will be locked, if it reaches the lockout threshold that you've set it to.

Just as an aside, you should move to other more secure ways of RDP. Changing the default RDP port is only security through obscurity (assuming this is indeed your goal).

Answer 2

First: The account lockout policy only applies to the string-based value that's supplied for the username. If the other connection attempts are supplying the same username, then yes, this will effectively create a denial of service for that user account. Additionally, assuming it isn't a Terminal Service licensed machine, then the server will only support 2 simultaneous connections before kicking off any other users--legitimate or otherwise.

Second: If this device is directly internet connected, this is a huge security foul. You're likely being hit by a brute force attack trying to find a username/password combination to break into the system. You can tell by looking at the security log to see what username(s) is/are being supplied. If they are random, then you are very likely under attack.

Thirdly: While @happy_soil is right that changing the RDP port only stops the most novice of attacker, the fact that you have any server directly connected to the internet is the problem. You need to move to a more secure remote connectivity mechanism (e.g. a VPN). Once a remote user is connected, they can access the network over an encrypted IPSEC tunnel to gain network access. However, even this has it's flaws (user's home computer is infected with malware and connects to corp VPN and infects corp from home)--but it's certainly better than directly internet-connecting a server.