Limit RDP connections for certain user groups to IP


Recommended Posts

I have a win 2003 standard edition server running as a web server, with Remote Desktop to admin it. I also have a static IP address at this end.

I know I can IPSec ALL Remote Desktop connections to a set IP address, but can I somehow limit administrator groups to my static IP address, but allow a standard user to connect from any IP address?

Thanks in advance.

huh?

You can control who has access to remote desktop by group or user account. The builtin administrators group has permissions by default, but you can add other groups or users that you want to be able to remote desktop.

As to IPSec all remote desktop connections?? :blink:

You can modify your IP security policies with secpol.msc, you can create IP filters there as well -- is this what your asking?

Edited by BudMan
  tiddlie said:
No - I want to limit the access to remote desktop via remote IP address. I want only my static IP to be allowed to login via a user in the administrator group, but a 'standard' user to have access from any IP address.
This makes NO sense.. So your allowing users from any IP access.. Then all IPs have access.

Sorry but that tool controls access to the PORT 3389, it does not say oh your from IP address X you can login as a USER, but not as an Admin User.

Oh your from IP Y, you can login as Admin.

"Logon screen is only displayed if the connection is established from particular IPs or machines. Computers that do not meet the filter restrictions don't see the logon screen & won't get to try a brute force logon!"

Since your allowing any IP to use remote desktop.. Then any IP will get the login screen -- an if they have a valid user account that can remote desktop, then they can log in.

Here are the filters you can use from that tool;

--

This is the main SecureRDP page. It includes several filters that can be combined to create very complex conditions that must be met in order to be able to logon to your Terminal Server. These filters include:

IP Address: restricts the connection by checking the client IP Address.

Computer Name: restricts the connection by checking the client computer name.

MAC address: restricts the connection by checking the client PC MAC address. Note that this filter works only for computers on the same subnet as your Terminal Server.

Client Version: restricts the connection by checking the Terminal Services Client version. To make this filter more effective you should be using a customized Terminal Services Client with your own version number. This service is available in our website at http://www.terminal-services.NET.

Time Restriction: restricts the connection by checking the logon date and time.

--

What he is asking does not even make any sense to do anyway.. Users that are NOT admin should really not even have remote desktop access to a server. But since your going to allow them access -- yes if they knew the admin password, they would be able to login as an admin. Even if you blocked their remote desktop login - they could just login as a user, then run whatever they wanted as the admin account.

Edited by BudMan

Agreed -- an than can be done with a simple IP security filter using secpol, or your firewall, etc.

No need for the tool -- its pretty much just a gui that puts some settings all in the same place for people that do not now how to use their own OS ;)

Well, I have no direct access to the server. Obviously, leaving RDP open to all IP addresses is a real problem - goes without saying. Hence why I want to limit the admin access to my static IP address.

I do however, work away from time to time, and only have access to the internet via a laptop on a public or hotel lan. Should I need to access the server whilst away to do a simple task such as edit the php.ini file, or reboot IIS, it would be handy to have a somewhat locked down account that allows me these limited functions. Obviously, this needs to be accessed from a public IP addess.

If this is a roundabout way to do it - hey - we all learn, and advice is always appreciated.

And surely Windows 2003 fits into your description of that tool Budman....a 'gui that puts some settings all in the same place' - 2003 seems to be entierly made up of wizards.....

They have had wizards since the first version of windows -- does not mean you have to use them ;)

An I agree -- I would never open up RDP to the public NET.

You should access it thru a VPN or SSH/SSL tunnel, etc. This allows you to move around, just setup TLS auth to the server -- just keep your cert with you. Be it auth to the VPN/SSL or Remote Desktop or private key access to the SSH server.

This prevents bruteforce attacks, an allows you access from anywhere on the planet.

http://technet2.microsoft.com/windowsserve...3.mspx?mfr=true

Configuring authentication and encryption

http://support.microsoft.com/kb/895433

How to configure a Windows Server 2003 terminal server to use TLS for server authentication

For example -- you can only access my home network with OPENVPN or SSH, I keep my keys on my thumbdrive -- so I can access all of my machines from anywhere on the planet either with just putty an tunnel anything I need or with the openvpn client -- an again all services are open to me just as if I was on the local lan -- just a bit slower ;)

Putting up any type of service that only requires a password to access is just asking for trouble!

edit: BTW the IP an or fqdn to access my server along with the cert/key passwords are in my head -- so even if I loose the thumb drive -- the finder does not have access to anything.

Edited by BudMan
This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Posts

    • So, do nothing basically, as long as you deploy Windows Updates? Pretty much yeah. Some Linux distros distribute update the secureboot certs as well, assuming you do use SecureBoot.
    • On one hand, YouTube videos are filled with so much fillers and the Youtubers intentionally speak slowly to increase video time and "engagement" metrics. On the other, Google's asking you to not stay on their site for longer. That's a win-win for viewers. So, I think it'll be axed or de-emphasised in the near future.
    • They'll just repurpose that for their AI trainings. Its never enough for LLMs.
    • Ubuntu gets second-ever snapshot release for Questing Quokka by Paul Hill Canonical has announced the release of Ubuntu 25.10 Questing Quokka Snapshot 2, a monthly development build that gives testers and developers a base from which to work on software for the upcoming release. Snapshot 1 was released at the end of May and Snapshot 3 is scheduled for July 31. Notably, the release date of Snapshot 2 and 3 have moved since last month. The Snapshot 2 update is available for various Ubuntu spins, such as Kubuntu and Lubuntu. To download, head to Ubuntu CD Image and go to the link for the version you want, such as ubuntu/. Once you’ve picked, go to releases/ > 25.10/ > snapshot-2/ and download the appropriate image for your computer - most people will want ‘64-bit PC (AMD64) desktop image’. The announcement mentions that these snapshot builds are not production ready, so you should not be installing them on a machine you use to do your work and daily computing. Canonical said that these builds should be seen as “throwaway artifacts”, whatever that means. If you’re an Ubuntu developer, you should submit your changes in the Ubuntu archive by July 28 to see it in the third snapshot. If you make any changes, Canonical asks you to update the Release Notes with the updates that you have worked on, so everyone knows what changed. Speaking of release notes, Canonical has been updating them incrementally. So far, we know that GNOME 48 is being used alongside the Linux 6.14 kernel. The use of GNOME 48 means that Ubuntu 25.10 only supports Wayland sessions as X.org has finally been dropped. Wayland has been used for a while on Ubuntu, so most people shouldn't have any issues as a result of the switchover. If you want to try out Ubuntu 25.10 Snapshot 2, you can find the download links over on the Ubuntu website. Just remember, these are not intended to be used on production machines!
  • Recent Achievements

    • Week One Done
      Marites earned a badge
      Week One Done
    • One Year In
      runge100 earned a badge
      One Year In
    • One Month Later
      runge100 earned a badge
      One Month Later
    • One Month Later
      jfam earned a badge
      One Month Later
    • First Post
      TheRingmaster earned a badge
      First Post
  • Popular Contributors

    1. 1
      +primortal
      559
    2. 2
      +FloatingFatMan
      177
    3. 3
      ATLien_0
      168
    4. 4
      Michael Scrip
      125
    5. 5
      Xenon
      118
  • Tell a friend

    Love Neowin? Tell a friend!