Configure a VirtualBox VM for a different VLAN than its Host

Scenario: You need a new staging VM to test out some Group Policy settings for a domain that resides on a different VLAN than the host that will store your staging VM. For example, let’s say that you wanted to run this VM using VirtualBox on your local machine. Your machine is on the I.T. Department VLAN (5), but the target domain resides on VLAN 3.

Example network diagram

Your machine is running Ubuntu — any recent version (I used 15.10 for this post) will work for this example. The 10,000ft view of what needs to be done is as follows:

  1. Ensure that the switchport that your workstation is connected to is a member of both VLANs. In my scenario, I have the following settings:
    switchport trunk native vlan 5
    switchport trunk allowed vlan 3
    
  2. Install the vlan package on your machine
  3. Configure a virtual interface with the appropriate VLAN info
  4. Configure your VM to use that interface exclusively

This post assumes you already have the VM up and running — in this example we’re using VirtualBox but pretty much any virtualization software should work. Go ahead and install the vlan package:

you@localhost:~$ sudo apt-get install vlan
you@localhost:~$ sudo modprobe 8021q
you@localhost:~$ sudo echo "8021q" >> /etc/modules

Add the virtual interface(s). On my machine, I have one interface named enp9s0; yours will probably be different. Adjust as necessary.

you@localhost:~$ sudo vi /etc/network/interfaces

Add your configuration. Mine is as follows:

auto lo
iface lo inet loopback

auto enp9s0
iface enp9s0 inet dhcp


## Target hosts/domain VLAN
## FYI: IPv4 addressing scheme is 10.0.3.0/24
auto vlan3
iface vlan3 inet dhcp
vlan-raw-device enp9s0


## Example VLAN w/ static IP assignment
auto vlan99
iface vlan99 static
address 10.10.10.10
netmask 255.255.255.0
gateway 10.10.10.1

See The basic syntax of “/etc/network/interfaces” for more information on the available configuration options for /etc/network/interfaces

I did run into some trouble during this configuration, mainly because there are some conflicting instructions on the net. You do not have to use vconfig to create the interface before adding it to /etc/network/interfaces … you can if you like, but it isn’t necessary. During this process, if you run into issues with interfaces not being brought up, you should take a look in /sys/class/net to see which interfaces have actually been created:

you@localhost:~$ ls /sys/class/net
enp9s0  lo  vlan3  vlan99

To remove any of your virtual interfaces, simply run the following command (where ‘vlan99’ is the interface you wish to remove):

you@localhost:~$ sudo vconfig rem vlan99
Removed VLAN -:vlan99:-

Now that you have your VLAN interface configured on your local host, we need to tell your VM to use it. This is trivial — in VirtualBox, navigate to the network settings of the VM and make sure that:

  • “Bridged Adapter” is selected in the “Attached to:” dropdown box
  • Select the appropriate adapter in the “Name:” dropdown box

Note: the VM can either be running or not … it makes no difference):

Staging Workstation - Settings

Then check your network settings in the VM (assuming DHCP — if not you’ll have to reconfigure them manually):

Staging Workstation [Running] - Oracle VM VirtualBox

If all goes well, you should now have a VM that will act behave like any of the workstations on the other VLAN with regards to networking.

Deploying Adobe Acrobat DC via Group Policy

This post assumes that you’ve already downloaded the Adobe Acrobat DC package from Adobe LWS and you’ve downloaded and installed the Acrobat Customization Wizard DC if not, go do those first.

  1. Once you’ve downloaded the package, double click it to extract its contents — do not run the installer after the package has been extracted.15-07-2015_000115-07-2015_0002
  2. Assuming you’ve extracted the package contents to C:\Users\Administrator\Desktop\Adobe Acrobat, you’ll have a directory within that directory, titled Adobe Acrobat, in addition to some other files that we won’t concern ourselves with for the purposes of this post:15-07-2015_0003
  3. Now start the Acrobat Customization Wizard DC:15-07-2015_0004
  4. Navigate to File -> Open Package and select the AcroPro.msi file.15-07-2015_0005
  5. Configure your deployment options. For example, enter the package’s serial number in the Serial Number field, under the Personalization Options category. Please refer to Adobe’s documentation for details on all of the available configuration options and their uses. One particularly frustrating issue I ran into had to do with the installer looking for Visual C++ x64 2013 Runtime (VC); if this package wasn’t installed, the installation would fail and the only thing logged in event viewer would be a group policy failure. The total lack of useful error messages made this issue a pain to overcome, but after reading every single option and description (more or less) on this page I eventually figured it out. I needed to set an attribute in the Property table via the Direct Editor function in the Customization Wizard.Add AttributeI had to add this attribute manually (just right-click anywhere in the attributes pane), as it does not exist in the Property table by default. The attribute name needed to be IGNOREVCRT64 and it’s value needed to be 1.IGNOREVCRT64You can probably guess at what this does but for the official explanation, refer to Adobe’s Documentation on Property attributes and values. The short explanation is that I needed this installation to succeed regardless of whether the target machine already had the Visual C++ x64 2013 Runtime package installed. As of this writing, here is the explanation, for posterity:

    Since Acrobat looks for Visual C++ x64 2013 Runtime (VC) by default, set IGNOREVCRT64 to 1 if it is not present AND not needed. IGNOREVCRT64 need only be used when all of the following are true:

    • During Acrobat installs on 64-bit machines
    • When Visual C++ x64 2010 SP1 Runtime is not installed
    • Installation is NOT done via setup.exe.
    • The following functionality is NOT needed:
      1. Acrobat PDF Creation add-on (PDFMaker plugin) for Microsoft Office 64-bit applications (viz. Word, Excel, PowerPoint & Outlook) and
      2. sending emails or resolving addresses via 64-bit Microsoft Outlook.

    Since Acrobat looks for Visual C++ x64 2013 Runtime (VC) by default, set to 1 if it is not present AND not needed. During non-setup.exe installs when VC is not present, installation behavior is as follows:

    1. Command line installs abort if IGNOREVCRT64=1 is not passed.
    2. UI installs display a dialog asking the user whether they would like to continue or cancel.
    3. Setup.exe installs succeed. Installs never abort as the property is passed while spawning the MSI.

    For MSI installs, use Require64BitVC10RT in the Setup.ini file under the Startup section.

  6. Once you’ve configured all of your desired options, navigate to File -> Save Package. This will create a transform (.mst) file (… in addition to doing a few other things): 15-07-2015_0007
  7. To deploy this package, it will need to be accessible from the network. Create a network-accessible directory — something like:
    \\domain.local\sysvol\Deployed Files

    and copy the entire Adobe Acrobat directory — the one containing the transform file created in the previous step — to that directory.

  8. Open GPMC and create a GPO (or modify an existing GPO):
    15-07-2015_00102
  9. Right click on any blank space in the right panel and create a new package: 15-07-2015_0010
  10. Select Advanced deployment method:15-07-2015_0009
  11. Navigate to the network accessible location of the package and select it (note: it might take a while for any dialogs to appear after selecting the file … just be patient): 15-07-2015_0011
  12. Then add your transform (.mst) file in the Modifications tab of the package properties (the transform file will be in the same directory as the package file.) Then click OK: 15-07-2015_0012
  13. Bonus! Configure some administrative templates.
    1. First, download the templates from Adobe.
    2. Save them somewhere on your computer and unzip them.
    3. Open GPMC and edit the GPO you’d like to use with the templates.
    4. In the policy editor, navigate to Administrative Templates in either Computer or User configuration
    5. Right click on the Administrative Templates folder and select Add/Remove Templates Add/Remove Templates
    6. Navigate to the directory where you unzipped the templates and select the file named AcrobatDC.adm Select the .adm file AcrobatDC
    7. Then configure your options:Adobe "Computer Configuration" options

      Adobe "User Configuration" options

apcupsd pcnet and different subnets

Scenario:

  • Subnet A: 192.168.0.0/24
  • Subnet B: 10.10.10.0/24
  • No firewalls blocking communication between them

Problem: An apcupsd instance running on a machine residing on subnet “B” cannot communicate with the APC NMC that resides on subnet “A”

Solution (probably): Make sure to specify the port in your DEVICE declaration in /etc/apcupsd/apcupsd.conf:

DEVICE 192.168.0.5:username:password:3052

Snippet from the default apcupsd.conf:

# pcnet ipaddr:username:passphrase:port
# PowerChute Network Shutdown protocol which can be
# used as an alternative to SNMP with the AP9617
# family of smart slot cards. ipaddr is the IP
# address of the UPS management card. username and
# passphrase are the credentials for which the card
# has been configured. port is the port number on
# which to listen for messages from the UPS, normally
# 3052. If this parameter is empty or missing, the
# default of 3052 will be used.

The question is: Why does explicitly defining something that is supposed to be the default (even when left undefined), change the behavior of the program? I do not have an answer at present. Good luck though!

Event ID 4098 / 0x80070005 Access is denied when Copying files via Group Policy

Event ID 4098 logged in Event Viewer "Application" log.

Event ID 4098 logged in Event Viewer “Application” log.

This scenario is common enough — you’d like to copy a file to each user’s Desktop/My Documents/etc. without having to do it manually for each user. So you use Group Policy. You’ve done everything correctly (or so you think):

  • The file you’re trying to deploy has been shared and the GP preference item’s “Source file(s)” input box has been pointed to the file via the UNC path (not the local filesystem path) to the file.
  • If your GP Preference that copies the file resides in the “User Configuration” branch, you’ve ensured that the “Domain Users” group has read access to the directory that contains the file (NTFS permissions) and the Share.
  • If your GP Preference that copies the file resides in the “Computer Configuration” branch, you’ve ensured that the “Domain Computers” group has read access to the directory that contains the file (NTFS permissions) and the Share.
  • You’ve ensured that the policy has been linked to the correct OU (i.e., the OU that contains the “target” users or computers.)

But did you remember to specify the full path — including the filename in the “Destination File” input box?

You must include the destination filename, specifying the target directory by itself is not sufficient.

You must include the destination filename, specifying the target directory by itself is not sufficient.

Yeah… it happens to the best of us. But don’t beat yourself up over it. This is a problem that shouldn’t exist; it’s counter-intuitive and different from the way “copy” commands (which is basically what this is) normally work.

Not receiving (or intermittently receiving) notifications via GravityForms

Scenario:

You have a website hosted on Rackspace (for our example; this applies equally to most other hosting providers) and your e-mail is hosted by Google Apps (again, this could apply to any other mail host.)

You’ve configured GravityForms to send you (admin@example.tld) a notification whenever a visitor submits a form. Sometimes you receive the notification; sometimes you don’t.

Your website has a proper SPF record:

example.tld descriptive text "v=spf1 mx a ip4:50.57.219.119/32 ip4:50.57.219.120/30 include:_spf.google.com ~all"

You can see that we’ve authorized our MX, A, and our web hosting provider’s (the IP addresses specified by the “ip4” directive) servers to send mail on behalf of our domain (example.tld), in addition to configuring the recommended SPF setting for Google Apps.

So naturally you look at the mail headers of one of the notifications that you did receive (… assuming you got one; all of this may still apply if you aren’t receiving any notifications at all) and you notice the following message, regarding SPF:

X-Original-Sender: website_visitor@somemailhost.tld
X-Original-Authentication-Results: mx.google.com; spf=softfail (google.com: domain of transitioning website_visitor@somemailhost.tld does not designate 50.57.219.123 as permitted sender) smtp.mail=website_visitor@somemailhost.tld

If you refer back to the SPF record, you see that the IP address, 50.57.219.123 is authorized to send mail for our domain (example.tld) but obviously we can’t set an SPF record for a domain we don’t own — somemailhost.tld, in this example, so somewhere in our form submission process, we must be attempting to send mail on behalf of somemailhost.tld (a fact made clear by the X-Original-Sender header), otherwise we wouldn’t be seeing this message. Time to take a look at how our GravityForms notifications are configured:

Incorrectly configured notification attempts to send e-mail on behalf of (i.e., spoof/impersonate) the visitor who submitted the form. Address spoofing is exactly the thing that SPF is designed to combat.

Incorrectly configured notification attempts to send e-mail on behalf of (i.e., spoof/impersonate) the visitor who submitted the form. Address spoofing is exactly the thing that SPF is designed to combat.

In the picture above, you can see that the “From” address is configured to be whatever the visitor submits. This means that your webserver will spoof that user’s address whenever sending the notification. Once the notification is relayed to your mail server (provided any intermediate relays don’t stop it first), it is likely being tagged as spam or discarded altogether because the origin of the message — 50.57.219.123 — is not permitted, according to the SPF record for your visitor’s e-mail domain (somemailhost.tld), to send e-mail on behalf of said domain.

Fixing this is quite simple; all you need to do is set the “From” address to an e-mail address within your domain (i.e., one that is validated by your SPF record):

Set the "from" field to an e-mail address within your domain, and set the "reply-to" address to the user-submitted value.

Set the “from” field to an e-mail address within your domain, and set the “reply-to” address to the user-submitted value.

Test your changes and verify that your form isn’t trying to spoof mail anymore by taking a look at the headers of one of the notifications that you receive:

X-Original-Sender: admin@example.tld
X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of admin@example.tld designates 50.57.219.120 as permitted sender) smtp.mail=admin@example.tld