Using Group Policy Preferences to Map Drives Based on Group Membership

A common request we hear is how to automatically connect specific network shares to drive letters based on group membership. Mapping network drives based on group membership requires some programming knowledge– either VBScript or command shell (batch files). VBScript based logon scripts can require hundreds of lines of code to provided a complete solution. And batch files require the assistance of helper applications such as IFMEMBER.EXE and NET.EXE, and introduce many challenges with controlling how Windows processes the script. But Group Policy Preferences removes the programming requirement and awkwardness of scripting mapped drives based on group membership. There are many scenarios in which you may want to map a local drive letter to a specific network share to include public drive mappings, inclusive group drive mappings, and exclusive group drive mappings.

Public drive mappings typically do not require membership to a particular group. However, sometimes public drive mappings do not provide enough granularity. Most organizations have data specific to business units such as accounting, marketing, or human resources.. Inclusive Group Drive mappings solve this problem by allowing a configuration that maps a specific drive letter to a specific network share based on the user being a member of a particular group. This ensures members of the accounting unit receive drive letters mapped for accounting and members of human resources map their respective drives. Exclusive drive mappings are not very common; however, they do provide the flexibility to prevent a user from mapping a particular drive letter to a network share if they are not a member of a specific group. A good example of exclusive drive mappings is to prevent the CIO or other executives members from mapping a drive letter in which they are likely to never use. Let us take a closer look at these scenarios

Public drive mappings

Producing a Group Policy Preference item to create public drive mappings is simple. The GPO containing the preference item is typically linked to higher containers in Active Directory, such as a the domain or a parent organizational unit.

Configuring the drive map preference item.

Figure 1 Configuring mapped drive preference item

Newly created Group Policy objects apply to all authenticated users. The drive map preference items contained in the GPO inherits the scope of the GPO; leaving us to simply configure the preference item and link the GPO. We start by configuring the drive map preference item by choosing the Action of the item. Drive map actions include Create, Replace, Update, and Delete. These are the actions commonly found in most preference items. Create and Delete actions are self-explanatory. The compelling difference between Replace and Update is that Replace deletes the mapped drive and then creates a new mapped drive with the configured settings. Update does NOT delete the mapped drive– it only modifies the mapped drive with the new settings. Group Policy Drive Maps use the drive letter to determine if a specific drive exists. The preceding image shows a Drive Map preference item configure with the Replace action. The configured location is a network share named data; hosted by a computer named hq-con-srv-01. The configured drive letter is the G drive. All other options are left at their defaults. This GPO is linked at the contoso.com domain.

The results of this configuration are seen when using Windows Explorer on the client computer. The following picture shows a user’s view of Windows Explorer. We see there is one network location listed here, which is the G drive that is mapped to \\hq-con-srv-01\data.

Figure 2 Public drive map client view

Later, we’ll see how to use exclusive drive mappings with public drive mappings as a way to exclude public drive mappings from a subset of users.

Inclusive drive mapping

Inclusive drive mappings are drives mapped to a user who is a member of (or included) in a specific security group. The most common use for inclusive drive maps is to map remote data shares in common with a specific sub set of users, such as accounting, marketing , or human resources. Configuring an inclusively mapped drive is the same as a public drive mappings, but includes one additional step. The following image shows us configuring the first part of an inclusive drive mapping preference item.

Figure 3 Inclusive drive mapping

Configuring the first part of an inclusive drive mapping preference item does not make it inclusive; it does the work of mapping the drive. We must take advantage of item-level targeting to ensure the drive mapping items works only for users who are members of the group. We can configure item level targeting by clicking the Targeting button, which is located on the Common tab of the drive mapping item. The targeting editor provides over 20 different types of targeting items. We’re specifically using the Security Group targeting item.

Figure 4 Security group targeting item

Using the Browse button allows us to pick a specific group in which to target the drive mapping preference item. Security Group targeting items accomplishes its targeting by comparing security identifiers of the specified group against the list of security identifiers with the security principal’s (user or computer) token. Therefore, always use the Browse button when selecting a group; typing the group name does not resolve the name to a security identifier.

Figure 5 Configured inclusive security group targeting item

The preceding screen shows a properly configured, inclusive targeting item. A properly configured security group targeting item shows bothGroup and SID fields. The Group field is strictly for administrative use (we humans recognize names better than numbers). The SID field is used by the client side extension to determine group membership. We can determine this is an inclusive targeting item because of the text that represents the item within the list. The word is in the text “the user is a member of the security group CONTOSO\Management.” Our new drive map item and the associated inclusive targeting item are now configured. We can now link the hosting Group Policy object to the domain with confidence that only members of the Management security group receive the drive mapping. We can see the result on a client. The following image shows manager Mike Nash’s desktop from a Windows Vista computer. We can see that Mike receives two drive mappings: the public drive mapping (G: drive) and the management drive mapping (M: drive).

Figure 6 Client view of inclusive drive mapping

Exclusive drive mapping

The last scenario discussed is exclusive drive mapping. Exclusive drive mappings produce the opposite results of an inclusive drive mapping; that is, the drive map does NOT occur if the user is a member of the specified group. This becomes usefully when you need to make exceptions to prevent specific drives from mapping. Let’s add an exclusive drive mapping to our public drive mapping to prevent specific members of management from receiving the public drive mapping.

Figure 7 Configured exclusive drive mapping

The preceding image shows the changes we made to the public drive mapping (from the first scenario). We’ve added a Security Group targeting item to the existing public drive mapping preference item. However, the targeting item applies only if the user IS NOT a member of the ExcludePublicDrives group. We change this option using the Items Options list. The client view of manager Monica Brink shows the results of applying Group Policy.

Figure 8 Client view of exclusive drive mapping

This client applies two Group Policy objects; each containing a drive mapping preference item. One item contains our public drive mapping with an exclusive security group targeting item. The other GPO contains the management drive mapping with an inclusive security group targeting item. The client processes the public drive mapping GPO; however, the exclusive targeting item verifies that Monica is a member of the ExcludePublicDrives group. Monica is also a member of the Management group. Therefore, Monica’s group memberships prevent her from receiving the public drive mapping and include her in receiving the management drive mapping.

Summary

Drive mapping preference items do not require any scripting knowledge and are easy to use. Leveraging targeting items with drive mapping items increases the power in which to manage drive mapping to users and computers. Public drive mappings are typically linked at higher levels in the domain and generally apply to a large subset (if not all) users. Inclusive drive mappings associate as specific subset of data with a specific group of people, often times mapping to logical divisions within an organization such as accounting, marketing, or human resources. Exclusive drive mappings invert the principals of inclusive drive mappings. The user must not be a member of the specified group for the drive mapping to occur.

Best practices

Be sure to link GPOs high enough in Active Directory so the scope of the drive mapping effects the largest group of user accounts. Obviously, not every GPO should be linked at the domain; however, if there is an accounting organizational unit with three child OUs– then linking at the Accounting OU effects that largest amount of users. Allow your inclusive and exclusive targeting item to do the bulk of your work. GPOs hosting inclusive drive mappings are best used when the number of user needing the drive mapping are fewer than the number who do not. Exclusive drive mappings are best used when the number of user not requiring the drive mapping are fewer than the number that do. These rules help prevent users from becoming members of too many groups and increasing the cost of managing drive mappings within the organization.

How to enable BitLocker on Windows Server 2012 R2

Thanks to the improvements of virtualization and storage technologies, it’s not difficult to clone a disk. A great advantage for disaster recovery, but also a potential risk for the security of your information.

Microsoft allows to encrypt the disks of a server with a feature named BitLocker. We are going to see how you can enable BitLocker on a physical or virtual server to protect your company from data theft.

Install the BitLocker Drive Encryption feature with the Add Roles and Features Wizard:

You need to restart the system after the installation:

How to enable BitLocker on a virtual machine (without TPM)

You need the Trusted Platform Module (TPM) in order to take advantage of BitLocker encryption. Virtual machines don’t have the TPM module so you need to follow these two steps BEFORE configuring BitLocker (BitLocker must be installed on the server).

Open the Local Group Policy Editor (gpedit.msc) and go to Computer Configuration/Administrative Templates/Windows Components/BitLocker Drive Encryption/Operating System Drives. Double-clickRequire additional authentication at startup:

Select Enable and check Allow BitLocker without a compatibile TPM:

After a restart, open the Control Panel, you’ll find the BitLocker configuration panel. Open it and clickTurn On BitLocker:

In this tutorial we used a VM, so a system without a TPM, and Windows aks us to configure an additional authentication at startup. We chose a password to protect the data, but we suggest to use a USB flash drive instead. With a flash drive you don’t have to enter the password at every server restart, just leave the USB drive plugged and you’ll be fine:

A recovery key can save you from big troubles. We printed it for security reasons:

Choose the encryption mode more suited for your disks:

Click Continue:

Restart the system:

At the next boot you’ll be “forced” to enter the password or plug the USB flash drive. After the Windows start BitLocker will begin the encryption process:

How to enable Roaming Profiles on Windows Server 2012 R2

Roaming Profiles allow users of an Active Directory Domain to access their desktop and documents from any PC of the domain.

It’s a powerful feature that can improve the productivity of the employees and make their lives easier.

The best thing about Roaming Profiles is how they are easy to set up.

Before configuring a Roaming Profile, we need to create a Share. Open the Server Manager and go to the Shares tab:

Create a new Share:

Click Next:

Specify the path of the Roaming Profiles. Add a $ to the end of the path to make the shared folder invisible:

Click Next:

Enable access-based Enumeration (for better security):

Now it’s time to customize the permissions. We need to allow the access to Domain Users (or another Group). Click Customize permissions:

Click Add:

Select the group (Domain Users in our example) and apply the permissions to This folder only. You need to enable List folders / read data and Create folders / append data:

Confirm and the share will be created:

Now the final step. Open the Active Directory Users and Computers panel:

Open the Properties of a user and go to the Profile tab. Specify the Profile Path:\\server_name\profile_folder_name\%username%

Mission accomplished! Your first Roaming Profile is enabled and active. To create other Roaming Profiles use the copy functionalities or manually specify the Profile Path.

You can also create a policy to automate the process.

How to: Software Restriction policies with AppLocker

We’ve already seen how to restrict software on Windows Server 2012 // R2 using GPOs. There’s another way available since Windows Server 2012, thanks to a feature called AppLocker.

We still use GPOs – AppLocker is a subset of GPOs – to enforce software restriction but it’s easier and more powerful.

AppLocker can manage execution permissions of:

• Executables: files with .exe extension
• Windows installers: Windows installer packages with .msi and .msp extensions
• Scripts: files with .ps1, .bat, .cmd, .cbs and .js extensions
• Packaged Apps: Windows Store apps

Open the Server Manager and launch the Group Policy Management:

Create a new GPO:

Edit the policy:

You will find the AppLocker settings inside the path Computer Configuration\Policies\Windows Settings\Security Settings\Application Control Policies\AppLocker. Click Configure rule enforcement:

Check all the rules if you want to enforce them. By default AppLocker blocks all executables, installer packages and scripts, except for those specified in Allow rules:

AppLocker differs from software restriction policies for the ability to automatically create rules. Right-click in the white box and select Automatically Generate Rules, a wizard will appear:

Specify the users that will be affected and select the path that will be analyzed to automatically create “Allow execute” rules:

You can choose to allow or not-allow the execution of unsigned executables. It’s better to create the rules based on the executable hash rather than the file path, it’s more reliable:

Click Create:

The new rules will appear:

We can also manually create other rules. Right-click on the background and choose Create New Rule:

Click Next:

Specify the users who will be affected by the rule and the rule type (Allow or Deny execution):

There are three ways to specify which applications will be affected by the rule:

• Publisher: identify the applications signed by a specific publisher;
• Path: identify specific files and paths;
• File Hash: identifiy applications based on their digital fingerprint.

In our example we chose Path:

Specify the Path:

You can add exceptions if you need them:

Name your new rule and click Create:

The rule will appear: