Local Group Policy Order of Evaluation Gotcha

It's once again PCI time here at my workplace. While implementing the whitelisting strategy for Windows Apps I described in a previous post, we discovered that while a default state of "Disallowed" blocks things like Notepad from running when you click them in the Start menu, you can still open them either from the Run dialog, or by double-clicking the .exe directly. This is obviously not acceptable from a PCI/whitelisting standpoint, so we had to find some combination of the new Software Restriction Policy (SRP) method and the old User Configuration GPO method to block everything not on the whitelist.

So, we started with our old GPO-based whitelist, and applied the SRP settings on top. To our surprise, when we logged out and back in, we found that while the SRP was blocking apps correctly, it was behaving as if the User GPO was not there at all! Why would this be, when both are turned on at the same time? Does the Computer-level GPO override the User-level GPO?

On a hunch, I tried it the other way around: I started with the SRP settings, then added the User-level GPO on top. This time, it worked! Apps are blocked by the SRP, and .exes are blocked by the User-level GPO.

Why does this happen? These are local GPOs, so the normal Local-Site-Domain-OU precedence rules do not apply as such in this situation. I have not found any documentation describing the order of evaluation/precedence for local GPOs, but it looks like local GPOs are evaluated in the order you create them.

At least in this case. I can't speak for all combinations of GPOs, but if one order doesn't work for you, it may be worth it to try it another way around to see if that makes the precedences line up to do what you want.

Don't forget the simple stuff: HP multi-function printer automatic document feeder malfunction

This morning, a user reported that their HP LaserJet Pro MFP M277fdn would not scan from the automatic document feeder (ADF) on the top of the scanner. This is the tray that you load paper into for sequential copying or scanning. They reported that when they inserted a piece of paper, the screen displayed a message reading "Document loaded", but then when they went to scan it, the printer instructed them to load the document feeder. So, it appeared that the printer both knew and did not know that paper was inserted.

After verifying that this was true, I started down the troubleshooting ladder. I restarted the printer (no change), hard restarted it by shutting down, removing the power cable, and holding the power button (worked once, but then refused to scan the second time), and cleaned within the top door of the ADF (no change). From here, my mind jumped to software or configuration corruption, so I performed a factory reset of the printer. (This led to the discovery that we have no documentation on how this printer was set up, other than phone pictures I took, which provided us with an opportunity to rekindle our tribal knowledge on the subject.) Alas, after everything was set back up, this too was met with no success.

In the smalltalk that the user and I shared while I was working on the problem, she happened to mention that she was somewhat unhappy with the printer anyways, as the scanner platen often gets dirty. It was then that I realized there was one place I didn't clean: the AFD scanning window on the platen. This area is shown in the picture below, taken from HP's support forum.

Image source: Alex-TATS on HP support forum

I had glanced at this area before, and seen a small line of dirt on the window, but thought nothing of it in this instance; usually, if that area is dirty, you'll get bad print quality, but it has never before interfered with scanning. However, since I was running out of ideas, I decided to go ahead and clean that window, and to my surprise, that appears to have fixed the issue.

Why did that help? The scanner clearly knows it has paper loaded, thanks to the microswitch in the AFD that displays the "Document loaded' message, and yet when it comes time to scan, it thought it was empty. I surmise that there must be some optical sensor mechanism (maybe the scanning head itself?) that checks for the presence of paper in the AFD scanning window, regardless of the microswitch status. Thus, when it tried to check for paper, the dirt on the window prevented it from detecting it, and so the printer was confused.

Whatever the cause, this is a good reminder not to forget to check all of the simple stuff first before going to the hard stuff, even if there's not a large chance that it's causing the problem - because it might just be it.

Outlook 2016 Not Loading Images on Windows 8

A user today ran into an issue with Outlook 2016 where it would display HTML emails correctly, but almost all images in those emails were broken links, with the red X in the top-left corner in typical Internet Explorer style. We directed her to instructions on how to set Outlook not to block images in messages, but she sent us a screenshot showing that these were not set, which I confirmed when I visited her.

On Google, I found and attempted some solutions, including clearing the Outlook secure temp folder and confirming that Internet Explorer was not set not to save encrypted pages to disk, but these had no effect.

On a hunch, I copied the link to a broken image out of Outlook into Chrome, and found that it loaded the image without issue. Then, I copied the link into Internet Explorer, and lo and behold, received an error message that IE could not connect to the webpage.

This computer was imaged at a time when TLS 1.2 (and, in this user's case, 1.1) were not enabled by default on Windows 8 in Internet Explorer. Chrome loaded the images without issue because it supports these newer versions by default, but Internet Explorer (and therefore, by extension, Outlook) were not so set, so the hosting servers were refusing their connections, and so not serving the images. Once I set IE to enable TLS 1.1 and 1.2, Outlook began loading images immediately.

Ultimately, we will resolve this issue more thoroughly by refreshing the user's computer with one that runs Windows 10, but as a stopgap until that time, this works.

Unsolved Mysteries: The time Wireshark actually *solved* the problem

We just got back from a ticket for an issue to do with a new lighting control system for one of the theaters on campus. The system includes a layer-3 switch, and the setup process involves assigning a static IP to a laptop that is directly connected via Ethernet to the switch. The theater techs followed the steps in the setup guide to the letter, but no matter how much they would adjust the settings, and even after 45 minutes on the phone with the vendor's tech support, the laptop still could not ping the switch. That's when they called us.

We repeated the setup process, and did our normal network troubleshooting - verifying IP addresses, switching to another network cable, even switching to another laptop - but we didn't have any better luck than they did. Even Nmap couldn't see anything. So, we opened up Wireshark to try to see what the computer and switch may have been trying to send to each other.

Lo and behold, as soon as Wireshark began capturing packets, the laptop and switch could connect to each other, and we were able to use the lighting control program to send configurations to the switch and other equipment. As soon as we stopped the Wireshark capture, though, the problem returned. The only way that these two pieces of hardware can communicate is if Wireshark is running.

This works well enough for what the theater techs need it for, as once the program is uploaded to the equipment, it operates as a self-contained unit. We forwarded our findings on to the vendor's support, and advised the techs to make sure Wireshark is capturing packets if they ever need to connect to the system.

There's no way that Wireshark should help in this way, right?

Downloading GarageBand loops for Munki deployment using appleLoops.py

Among other applications, we deploy Apple's GarageBand using Munki. GarageBand can be installed without too much trouble, but on first run, it prompts the user for an administrator password so that it can download and install a set of instrument loop packages. Of course, if the user isn't an administrator - for example, a student in a lab - they won't be able to allow this installation, and will therefore be unable to launch GarageBand.

So, to avoid this problem, it's standard practice to download the loop packages for deployment through something like Munki or Jamf. The traditional way to do this involved opening GarageBand and, before entering your administrator credentials, copying the installer packages out of a path located deep within /var/folders/.... Unfortunately, at least with our modern version of GarageBand 10.3.2, this doesn't seem to be good enough: the set of packages that are downloaded, when installed onto another computer with a fresh install of GarageBand, don't satisfy the application, and it prompts to download them again. It's possible that I made some mistake, but I tried it twice, and it didn't work either time.

Fortunately, some Googling turned up a GitHub repository for a project called appleLoops.py, by Carl Ashley, that ultimately solved our issue. appleLoops.py makes it easy to download loop packages for GarageBand, Logic Pro X, and MainStage 3, and can optionally install these packages in deployment mode, usable from products like Munki and Jamf. It even lets you specify a local cache location that clients will use to download packages so that you can avoid slow or expensive transfers over the Internet.

For our purposes, simply downloading the packages is good enough, so here's how I did it:
1. Download the appleLoops.py project from GitHub.

2. Create a folder to store the loops that you will be downloading. I made this folder as a subdirectory of the appleLoops project folder, but it can be anywhere on your computer, or even a network location to which you have write access.

3. Run the appleLoops.py script:
sudo ./appleLoops.py --apps garageband --destination ./loops --mandatory-only
(If you also want the larger set of optional loops, add --optional-only to the command line. Despite both flags saying "only", they actually do combine without issue.)

4. After the loops have finished downloading, configure your management system of choice to deploy them to clients. If you don't use a management system like Jamf or Munki, you can easily write a shell script to install all of the loops packages manually:
#!/bin/bash

for pkg in $( ls *.pkg ); do
    echo "Installing $pkg"
    installer -pkg $pkg -target /
done

5. After the loops have installed, GarageBand should open without prompting for administrator credentials.

Whitelisting Windows Store applications on Windows using secpol.msc

As part of PCI compliance, we are required to restrict the applications which users are able to access on our payment office PCs to those on a specific whitelist. One wrinkle we've run into as part of migrating from Windows 7 to Windows 10 is that our older GPO-based method of restricting applications does not apply to newer Windows Store/Modern apps, including Microsoft Edge and Skype. This wrinkle has, so far, kept our payment PCs on Windows 7 for PCI compliance reasons.

Luckily, I discovered that it is possible to use a different method to whitelist applications: secpol.msc.  This is the Local Security Policy editor, reminiscent of the Local Group Policy editor gpedit.msc, and it allows you to create a software restriction policy to control what applications can and cannot run on a PC.

To create a software restriction policy to create an application whitelist, including Windows Store/Modern apps, follow these steps:

1. Open secpol.msc.

2. Right-click on "Software Restriction Policy", then on "New Software Restriction Policies."

3. In the "Security Levels" folder on the left, right-click on the "Disallowed" setting, then on "Set as default." This sets Windows to disallow access to all applications by default, except for those specifically whitelisted in the "Additional Rules" section below.

4. Right-click in the empty space in the "Additional Rules" folder, then on "New Path Rule...".

5. Enter the path of the application or folder that you wish to control. In this example, I am adding a rule to disallow all applications and apps in the C:\Program Files\WindowsApps folder, which includes things like the Calculator and Notepad apps. Click OK.

6. Add more rules to cover all of the applications you wish to control. As you can see in the screenshot below, I have also added a rule to disallow C:\Windows\SystemApps\*Edge*, in order to block the Microsoft Edge web browser from running. 

Note: You most likely do not want to block C:\Windows\SystemApps as a whole, because Microsoft has app-ified various parts of the operating system, including the Start menu and File Explorer. If you disallow this folder, you will lose access to these parts of the operating system until the policy is relaxed.

That's pretty much it! As you can see in the screenshots above, there are two entries that are automatically created when you create the software restriction policy: one for %HKLM [...] ProgramFilesDir%, and one for %HKLM [...] SystemRoot%. 

%SystemRoot% includes vital parts of the operating system, so it is not advisable to disallow access to this folder on a blanket level. %ProgramFilesDir% covers everything in the Program Files directory, meaning that by default some applications will still be allowed to run, even with the default policy set to disallow - Microsoft Office is an example of this. If you want to block these applications, simply change that entry from unrestricted to disallow.

In order to whitelist an application, you would do the same thing: create a new additional rule, but instead of specifying that it should be a "disallow" rule, choose "unrestricted" instead.

To make your changes take effect, log out and back in.

Windows User Profile Migration with Profwiz

At my new place of employment, we migrate Windows user profiles from one machine to another using the ForensiT Domain Migration User Profile Wizard, or Profwiz for short. This tool works somewhat differently to the Windows Easy Transfer tool, which handles user profile creation and data migration for you, in that Profwiz only configures profiles in-place to work with data copied from another computer. This means that you are free to use whatever format you wish to store the transferred data, versus the Easy Transfer tool, which uses its own proprietary .MIG format, which in the past I have found can become corrupt and unrecoverable over a certain size. Profwiz also does not create the user profile for you, so you need to do that yourself, but once you run Profwiz, everything "just works." An additional plus to Profwiz is that, in order to use the Easy Transfer tool, you must be able to boot and log into the computer, but Profwiz will work as long as the hard drive is readable.

The Profwiz user guide explains in detail the many capabilities of the tool, along with how you can set up a distribution file with many settings pre-entered to save time during the actual migration process. However, if you're just doing a few migrations, it is easy enough to run the tool manually. To perform a user profile migration on Windows with Profwiz, follow these steps:

1. Create a local profile on the new computer with the same username as on the old computer. If the profile on the old computer was a domain account, don't worry, as Profwiz will take care of that.
2. Copy the user's profile data from their old hard drive or a backup location to the profile on the new machine that you just created. Make sure to copy AppData and any other hidden folders as well to make sure that things like browser bookmarks and application configurations are migrated correctly. (Be sure to keep the old hard drive for at least a little while as an additional backup!)
3. Download Profwiz. Note that even though it downloads as an .MSI, it doesn't really install anywhere, and rather just dumps the .EXE in the same directory. You could probably just re-use the same .EXE for future migrations.
4. Run Profwiz: (Screenshots may be found starting on page 29 of the user guide)
1. Select the computer to which you are performing the migration. For most cases, you will probably choose "Local Computer", though it is possible to perform migrations over the network. In this guide, I will focus on local migrations. [Next >]
2. Select the user profile(s) to be migrated. The free Personal edition of Profwiz only allows a single profile to be migrated at a time, but the paid Corporate edition allows you to select several. You will want to select the profile(s) you created and copied data to in the steps above. You may also check the boxes for "Disable Local Accounts" or "Delete Local Accounts" if you wish to remove the local accounts you created after the migration is complete. (This is useful if your environment mandates that only domain accounts be used.) Check the box(es) next to the profile(s) to migrate, and then [Next >].
3. Enter the name of the domain to which the new user profile belongs. If the computer is not already joined to the domain, you can click the "Join Domain" checkbox below the domain box. If the computer will not be joined to a domain, click the drop-down arrow for the box and select the local computer name. (Azure AD accounts are also supported, but are outside the scope of this writing - please refer to page 38 of the user guide for that information.)
4. Below the domain box, enter the name of the account that should be used for the new profile. This will usually be the same as the username you gave the new profile when you created it. If desired, check the box for "Set as default logon" (useful for single-user scenarios), then [Next >].
5. Profwiz will run through several steps to set the appropriate access control list (ACL) settings for the new profile to allow the specified domain user account to access the files and folders contained within, to join the domain, and anything else you specified for it to do. When done, click [Next >].
6. You will be prompted to reboot the computer after Profwiz is finished.

After the computer reboots, you should be able to log in as the migrated user (assuming that you have their credentials), and everything should be as it was on the old computer. Profwiz does not migrate things like printers or applications, so you will still need to install those by hand, but it does greatly simplify the task of moving a user profile from one machine to another.