EmailRSS

Monthly Archives: March 2019

Who can shutdown your servers?

Posted on by

Have you accidentally shut down a server or your own workstation? While you meant to just reboot, that device is now shutting down. It is even worse if it was a physical machine – at a remote location.

Not that I’m speaking from personal experience or anything…

Your task today is to prevent accidental shutdowns for your important machines. Let’s control who can shut down the system, using Group Policy[note]not to be confused with shutting down the system using Group Policy[/note].

I could have sworn I hit restart…

Often, every user that can log on interactively to a server also has permission to shut that server down. Open gpedit.msc on a server and browse to Local Computer Policy\Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment. If you have any shared client machines (such as a jump machine/management VM), you will see Users listed. On a server OS, you won’t see Users listed by default. But ask yourself, do you really trust all of your administrators not to hit the wrong button? 🙂

Don’t edit the local computer policy. First, decide what accounts should have access to shut down[note]Does anyone else feel that shut down should be a single word? Like shutdown.[/note] a server. I limit this to the domain admin account, elevated admin accounts, and a few service accounts. Add these users to a security group named something like Security – URA – Shut down the system

Next, make your changes in the Group Policy Management Console. There are two common approaches to take. Either:

  • Create a new GPO named something like Security – URA – Shut down the system ; edit the setting pictured above, and link it to your servers / domain controllers OU.
  • Edit an existing general server GPO to restrict the shutdown permissions. If you do this route, make sure any server OUs with blocked inheritance and your domain controller OU is included.

Either way, be sure to comment why these changes were made, who made them, and when they were made. That is all that you need to do! With accidental shutdowns stopped, you won’t have to make the drive of shame to turn on that remote server.[note]Not that I’m speaking from personal experience or anything… [/note]

Making Life Hard for a Phisher – How to Report a Phishing or Malicious Website

Posted on by

When you receive an email with a phishing or malware link in it, what do you do? If your answer doesn’t get that site blocked across all major browsers, you aren’t going far enough!

In less than two minutes, you can essentially take a malicious website offline and make life a bit harder for a phisher and safer for everyone else. Here are the steps that you need to do:

Step 1: Check the Website

The quickest and safest way to verify that a link is malicious or designed for phishing is to run it in a sandbox service.

For a phishing website:

Enter the URL on this page: https://checkphish.ai/. You should see a screenshot of the website and any phishing flags (ex: if the website is impersonating another site’s login page).

Please don’t report my website…

For a website with malware:

Enter the URL on this page: https://www.virustotal.com/#/home/url. You can also upload suspicious files or attachments to VirusTotal for analysis.

Step 2: Report the Website

Now that you know what you are dealing with, report it by using these links. Each will take only 30 seconds to complete.

Report a Phishing Website

Report a Malicious Website

And that is it! In a couple of minutes, that website should be flagged as a phishing or malicious URL. This protects everybody using those browsers. Occasionally, it might take 15 or 20 minutes to start being flagged.

It is incredibly satisfying to see a malicious website that you reported being prevented from loading! If you are interested in more tools or additional information on reporting, see this page for inspiration.

Background Info (BGInfo) for Chromebooks

Posted on by

Before we go any further, let me show you a screenshot of the wallpaper that is generated when a user logs into a Chromebook.

Edited slightly to remove domain information.

Tucked into the bottom right corner of the desktop, users can see their Chrome OS version, username, IP address, serial, location attribute, and asset ID attribute.

This makes troubleshooting Chromebook issues so simple because you can ask end-users to look at their wallpaper for information that you need. If you push information into the location field for your devices, you can also see which room or cart the Chromebook should be in.

Setting this up is super easy!

  1. Deploy this extension to your users in Google Admin. The author of this extension, Jay Lee is the same guy that created GAM.
  2. Download this text file. Rename the file so that it ends with .json instead of .txt.
  3. Deploy that JSON file to your users. See these instructions for more details.

Log into the Chromebook as a user targeted with the extension and config file. You should see a new extension loaded if you open Chrome. You should also see an updated background within a minute.

For more information, see Jay’s page on this awesome tool!

Concurrent Remote Desktop for Windows 10 with RDPWrapper

Posted on by

If you have never used concurrent remote desktop to support your Windows clients, this post is about to make your day! Concurrent remote desktop can allow you, as an admin, to interactively use a client OS while the main user is still actively logged in.

I’ve written about concurrent remote desktop before. The method that I used five years ago is completly different than the method that I prefer now.

Where the old version was a cumbersome and very OS version specific, this newer method is simple and scalable. With more than two million downloads, it also has a wide user base to provide some support. Today, we are going to deploy RDPWrapper in about ten minutes.

Start by downloading these two files:

Place the MSI on a network share and deploy it with Group Policy / SCCM / etc. As a general rule, do not deploy it to any computer where the primary user remotes in as it can lead to some strange session issues. For example, I deploy this MSI to my student and teacher machines, but I do not deploy it to IT computers. If you have used an alternative CRDP method in the past, you will want to ensure that the original termsrv.dll file is restored to the computer.

Once the MSI is installed, you’ll see just two new files in \Program Files\RDP Wrapper\. RDPWrap.dll sits between terminal services and provides concurrent use abilities. RDPWrap.ini contains the instructions and support for each client OS.

If you scroll to the bottom of RDPwrap.ini, you will see that it does not have information for the latest Windows 10 versions. That information is stored in the rdpwrap-master.zip file that you downloaded earlier.

Open the rdwrap-master.zip file and navigate to the res subfolder. Copy the rdpwrap.ini from that folder to your network share. Deploy it to your clients to enable support for the latest Windows 10 versions. Personally, I use Group Policy File preferences to deploy the ini file.

Set the preference action to replace and use Item Level Targetting to ensure that the newer file replaces the default file. While you are in the common options tab, set the preference to just apply once.

When future Windows 10 client versions are released, just grab the updated INI file and deploy it. It really is that easy! To test RDPWrapper, reboot the client machine and log on to that computer as a standard user. From your admin machine, launch a remote desktop session to that computer and you should be able to log on as well. If you open taskmgr, you should see that two users are actively logged in.

In the game Civilization, there is a quote that says, “Don’t reinvent the wheel. Just realign it.” At times, it might seem silly to go back and find another solution to the same problem. Those realigned solutions, such as using RDPWrapper, are simply so much better!