prevent users using remote desktop


Recommended Posts

  barteh said:
I've just tried this on an account in AD called 'Test' which isnt a member of the local admins or anything.

I ticked the deny box but RD still loads fine.

I've tried re-logging on a few times as that user, but to no avail.

Does anything else have to refresh?

Your saying it "loads fine". Do you mean to block the act of using mstsc.exe and connecting and logging on to remote computer? Or to block the mere mstsc.exe from even opening?

Again -- what exactly are the users doing that you want to stop? That setting in AD has nothing to do with them running the remote desktop client and connecting to some box running remote desktop, etc.

I am going to take a guess you have users using remote desktop to access machines outside your network to say surf the net, play solitare, etc..

Is this what your trying to stop?

As mentioned you could prevent them from running the exe on their machines -- but there are 3rd party remote desktop clients they could run. Or for that matter why does it have to be remote desktop - they could just vnc to boxes outside your network, etc..

The details of exactly what your users are doing that you want to stop would be most helpful for us to suggest ways to prevent them from doing it.

If the issue is users having remote control of PCs outside of your network then outgoing firewall policies will need to be put in place. But again, there are specific questions and answers needed.

^ and it does not take a rocket scientist to figure out that if you block outbound access on 3389, to just have the machine listen on another port -- say 80 or 443 for remote desktop connections.

Trying to block users from access to things outside of your control is a uphill battle to say the least, its like trying to block spam.. As soon as you block one thing, they figure out a new way to get it paste the filters, etc.

  BudMan said:
^ and it does not take a rocket scientist to figure out that if you block outbound access on 3389, to just have the machine listen on another port -- say 80 or 443 for remote desktop connections.

Trying to block users from access to things outside of your control is a uphill battle to say the least, its like trying to block spam.. As soon as you block one thing, they figure out a new way to get it paste the filters, etc.

Very true, it can get condeluded when talking about blocking outbound traffic. It is very easy to change the port RDP uses. It is of course still an option if he wanted to take that route.

Really the only options I see are:

1. Denying users from using Terminal Services via AD. Applies only in your environment.

2. Block all outbound traffic with the exception of legitimate ports. This could be very maintainence intensive and could get very condeluded, but could also work.

3. Block the mstsc.exe from ever executing in the first place. This would without a doubt stop RDP access regardless of what PC they are connecting to. However other forms of remote control could be used as stated using different ports.

So perhaps a combination of these could best suit you.

Sorry for the long delay.

I've blocked the terminal services in AD, several days on, this had made no difference.

We're using SBS2003, so dont have ISA server to have real control over outgoing ports etc.

Whats the easiest way to block the mstsc.exe in GPO?

I've never made any software restrictions before, so in simple terms would really help :)

  barteh said:
Sorry for the long delay.

I've blocked the terminal services in AD, several days on, this had made no difference.

We're using SBS2003, so dont have ISA server to have real control over outgoing ports etc.

Whats the easiest way to block the mstsc.exe in GPO?

I've never made any software restrictions before, so in simple terms would really help :)

If this is not working there's something wrong and I'd suggest you resolve it in case they work around the software restriction policy.

The Deny restriction applies to the user account that is being used to connect and not to the user launching the terminal services session, could that be the problem?

  barteh said:
i've gone to:

User Configuration\Administrative Templates\System

"dont run specified Windows applications" = enabled

and added: mstsc.exe

Doesn't that policy just compare a filename and/or its path to block the specified EXE? If so, couldn't a user just copy the file elsewhere (and/or rename it) and run it from there?

  bobbba said:
If this is not working there's something wrong and I'd suggest you resolve it in case they work around the software restriction policy.

The Deny restriction applies to the user account that is being used to connect and not to the user launching the terminal services session, could that be the problem?

quite possibly.

What your saying is:

So in AD i tick the deny box which says Bart cannot use Term Services, but so long as I log into another machine with a different account Its letting me?

I've tried the .exe i'll just wait and see what happens.

Scenario for how it works:

Admin creates AD account Bart2, default is allow term services

Admin edits AD account Bart1, deny term services

Bart1 logons on to pc1 opens mstc and attempts to remote desktop pc2

pc2 asks pc1 for a logon

bart specifies his logon (Bart1)

pc2 checks the ad to see whether Bart1 is allowed access, then denies him access

Bart1 tries again:

opens mstc and attempts to remote desktop pc2

pc2 asks pc1 for a logon

bart1 specifies Bart2

pc2 checks the ad to see whether Bart2 is allowed access, then allows him access

So basically the check is all about whether an account is allowed to complete a connection and logon to a remote desktop, not whether an account is allowed to attempt a connection.

If the accounts are setup properly, this should work perfectly well as the user won't know the credentials for other accounts so the restriction works. Restricting the exe and preventing them from launching the client is a really poor workaround except for when the computers they are trying to access are not within the organisation's control (like home pc's over the internet) which is when a firewall with outgoing control should be used.

Sorry bobba, I think I should have explained in more detail earlier.

The Machine the user is connecting to is a home machine.

And like I mentioned earlier, we dont have ISA so we dont have that sort of control, and the admins do use RDP ourselves, so I dont want to completely disable it.

Sounds like you need something like the following:

software restriction policy:

Block the filename of MSTSC

Block the hash values of the various versions of MSTSC

Prevent it from applying to local admins

(if your troublesome users don't have them, use GPO security filtering if they do)

Articles to help:

MS Howto

Tutorial

Those are the technical means of controlling it, the organisation should also have a computer/internet usage policy as well so that they have to consciously break the rules to do something like this and if they do a discipline procedure can be applied.

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

    • No registered users viewing this page.
  • Posts

    • I honestly think this does not make any noticable difference to anyone with a PC with average specs.
    • OpenAI takes down all traces of Jony Ive "io" deal following court order by David Uzondu Early this month, we reported that OpenAI was working on a mobile gadget in the form of a screenless, wearable device, born from a newfound partnership (friendship?) between renowned former Apple designer Jony Ive and OpenAI CEO Sam Altman. The announcement came with a video that had the two men talking about the future of technology. Well, that video has now been made private on YouTube, and the original announcement page has been taken down. The whole thing is on pause because of a simple trademark dispute. OpenAI was forced to pull the materials following a court order. If you visit the original announcement page, it now says: Despite the legal hassle over the name, the actual business deal seems safe. According to Bloomberg's Mark Gurman, the acquisition itself is unaffected by the complaint. So, who is iyO (pronounced eye-oh), the other party in this mess? If the name sounds unfamiliar, its background will not. This iyO company is an independent startup that graduated from X, Alphabet's moonshot factory, and yes, that is the same Alphabet, the parent company of Google. iyO claims to be on a mission to bring "natural language computing" to the masses. A quick look shows two products listed on its website: the Vad Pro, a high-end wired audio device for professionals, and iyO One, a set of AI-powered earbuds the company is calling the "world's first audio computer." A judge reportedly found its trademark lawsuit against OpenAI credible enough to issue the restraining order, suggesting the ChatGPT creator's video could create genuine consumer confusion between the two similarly named ventures.
    • I've set since XP - Best performance in the Performance settings. 11 included. I enable only the show shadows after that, so I can see better fonts and mouse.. But hardly I can say I can see a difference today.
    • Yeah this kinda means nothing to me if it's going to be the same mess as HDMI 2.1 where it was difficult to know what features you were getting. It was way too confusing, designed to fool us into thinking we was getting something better with the higher number when a lot of the times we didn't get anything better because companies can add and remove features at will, which if that is the case for 2.2, then who cares lol.
    • Someone wrote a script to block 'brainrot' content online using an $8 smart plug by Usama Jawad Original image via Neil Chen Many people use smart plugs nowadays due to the various advantages they offer, including automation, integration with mobile software, increased home security, better energy efficiency, and compatibility with other smart products. However, a smart plug customer has gone a step further by enhancing their hardware in a way that it blocks them from viewing "brainrot" content online, or any website, for that matter. As seen in a popular thread over on Hacker News, a person known as "NWChen" has written a script that connects to the $8 Kasa Smart Wi-Fi Plug Mini and utilizes it to restrict access to websites of your choice. In essence, this plug then acts as a physical switch that you can toggle to visit certain websites. NWChen's main motivation behind this initiative was to avoid brainrot, with examples listed as X (formerly known as Twitter), Instagram, YouTube, and Reddit in their blog post. In terms of technical functionality, the smart plug connects to Wi-Fi (obviously) and hosts a physical switch that can be used to turn it on and off. NWChen's script connects to the smart plug via an API and then polls its state. If it's on, websites of your choice get restricted and you can't open them anymore, until you physically get up and turn off the plug, or remove the website from you blocklist. NWChen has recommended plugging in the hardware far away from you so there is sufficient resistance in turning off the plug. In the thread, many have praised this invention, believing that the nature of this mechanism provides enough hurdles where you'd rather just not visit the problematic websites anymore. However, some have noted that "those without self control cannot be trusted if they hold the switch". Some have also highlighted a problem where a user can simply stop the script's execution without much friction. Overall, it's a fairly interesting setup, even if it's fairly rudimentary in nature. Configuring this physical block with a Kasa smart plug is fairly easy. You can simply download the script from the laptop-brick GitHub project here, install it, get the IP address of your smart plug, and then use it when you're executing the script. You can modify the blocklist using a dedicated file present inside the GitHub project.
  • Recent Achievements

    • Conversation Starter
      Brett76 earned a badge
      Conversation Starter
    • One Month Later
      Miguel Batista earned a badge
      One Month Later
    • Dedicated
      moojay67 earned a badge
      Dedicated
    • One Month Later
      Jim Dugan earned a badge
      One Month Later
    • First Post
      Johnny Mrkvička earned a badge
      First Post
  • Popular Contributors

    1. 1
      +primortal
      653
    2. 2
      Michael Scrip
      229
    3. 3
      ATLien_0
      220
    4. 4
      Steven P.
      151
    5. 5
      Xenon
      144
  • Tell a friend

    Love Neowin? Tell a friend!