Group Policy Preferences not mapping network drives in Windows 8

One of the first problems I noticed with Windows 8 is my drive mappings were missing.  I joined a freshly installed Windows 8 workstation to the domain, and with that membership the workstation should be provided some drive mappings based on who I am when I log on to the computer.  I am using Group Policy Preferences and security groups to map drives in this environment.  It works exceptionally well on Windows 7 and Windows XP, but here I am looking at an empty explorer window that should have about 4 mapped drives sitting in it.

After some research, I discovered that this is actually a known issue, and not only is it a known issue, but according to message boards it has been known for quite some time now and nothing has been done to correct it.  From the reading that I did, I determined that if you are a standard user (no administrative rights on the domain or on the local workstation) you will be provided your network drives.  However, if you are an administrator (domain or local), the group policy applies successfully and no errors result, but no drives are displayed in the explorer window.  That seems really backwards to me as a network administrator, but that is what is occurring.

According to posts that I have read on the subject, it would seem that because group policy preferences are applied using the users security context, and the explorer window by default is launched without any administrative privileges, it doesn’t have the rights to display the drives.  I don’t know if I believe that, but the users who were stating that, also provided the workarounds that gave me my drives back.

So, because no one seems to be able to pin-point the exact issue and several changes have provided a workaround, I am just going to list all the possibilities here and they can be attempted at will.

  • “uncheck” the reconnect option in the drive mapping settings.


  • run in logged-on user’s security context (user policy option)


  • It was also suggested that removing Item-level targeting would map the drives, but I don’t think that is something that most people will want to do since Item-level targeting is one of the key features with Group Policy Preferences.
  • Disable Fast Logon: Fast Logon Optimization
  • Check “Always wait for the network at computer startup and logon” policy is enabled under Computer Configuration/Administrative Templates/System/Logon in the Group Policy.


  • and of course there is removal of the user from any administrative groups (not likely to be the first choice)

The first option to “uncheck” the reconnect option worked for me.  I really hope that Microsoft releases a patch shortly to correct this.  I would prefer to have the drives reconnect.

Wireless Authentication with Certificates

I love putting in extra effort if it will make things go more smoothly in the future.  Certificate authentication is one of those things that can really take away a lot  of the headache of wireless network authentication.  In order to really achieve effective usability with certificates, you want to make sure that it will work with all devices.  Simply using certificate authentication for domain joined Windows based PCs is just going to frustrate all involved.  This solution should incorporate all devices in order to be successful.  Recently I had something trip me up for quite a while actually.  When generating a certificate never use another account to request the certificate.

I thought if I used my administrator account it would make things easier and go more smoothly since being an administrator gave me more options when generating certificates.  That was my mistake.  I used an administrator account to log on to the certificate request site (this setup is using Microsoft certificate server), and from there I supplied the Certificate Signing Request (CSR) and I requested a user certificate.  When these were generated, they were using the username of the administrative account I supplied not the username I was creating the certificate for.  When creating a certificate via the web interface, always use the account you are generating the certificate for, or authentication will fail every time as the certificate is associated with the authenticated user.

Linux example:

Since I don’t have a good way to push certificates to a Linux platform, I use a manual process.  Linux requires that you have a certificate, the private key, and the certificate authority.  It is also going to ask for an “identity”.  This identity will be the user that you are using to authenticate this connection.  Ironically, it doesn’t use this identity when validating the certificate.  This became very important when I used an administrative account to generate the certificate for the laptop but Microsoft Network Policy Server identifies the certificate belonging to the administrative account not to the identity supplied when connecting.

So, it is important to remember that when using a Microsoft Certificate Authority to generate your certificates, log on to the website with the account that you will be using to authenticate to NPS server.

When you create a user certificate the following steps work for me.  I began by generating a certificate request and corresponding key using the following command:

openssl req -new -newkey rsa:2048 -keyout server.key -out server.csr

Of course there are many ways that this can be accomplished, this is simply an example.  It is important to note that settting a passcode for this key and csr is important because the wireless connection wizard will not allow you to connect using a key file that is not protected with a password.  It also makes the key file more secure and is a good practice.  Once I had the key file and certificate signing request file, I copied the contents of the certificate request file and using a web browser headed over to my certificate authority web interaction page. (http\s://servername/certsrv) and entered the username and password of the user account that would be using this certificate.

Once you have logged on, this is the page you will be provided.
Once you have logged on, this is the page you will be provided.

I then selected request certificate,

These are the options available. Request Certificate is the link that allows you to obtain a certificate.
These are the options available. Request Certificate is the link that allows you to obtain a certificate.

and advanced certificate request on the next page.

this is the option you want to use when you have a certificate signing request that you need to provide to generate your certificate.
this is the option you want to use when you have a certificate signing request that you need to provide to generate your certificate.

This provides a box to paste the certificate signing request into and allows for a couple other options.

The type of certificate we are looking for is a user certificate.
The type of certificate we are looking for is a user certificate.

One of the options is to set the type of certificate you would like to generate.  “User” should be selected here.  The rest of the defaults should be fine for the certificate creation.

Once you have completed all the information, submit the request to obtain the certificate.
Once you have completed all the information, submit the request to obtain the certificate.

Once you submit the request and the certificate server generates the required certificates, you can save them and get ready to finish setting everything up.

Since Linux only likes certificates in the pem format, and since Microsoft generates them in the cer format, a quick conversion will be necessary to complete the steps.  Using the command below, the certificate will be converted to a new pem file.

openssl x509 -inform der -in certificate.cer -out certificate.pem

Now, when connecting, select your authentication type and make sure you choose TLS for certificate authentication.  You will need to supply the key file, the pem file, and the certificate authority file (which can be obtained from the certificate authority server that you generated the certificate from.  It will also need to be converted to a pem file.  Finally, you will need to provide the identity that will be used to connect.

These are the options that will be presented to you when connecting using certificate based authentication.
These are the options that will be presented to you when connecting using certificate based authentication.

That should be all that you need to successfully authenticate to a wireless network using certificates with a Linux based OS.  Connecting using a Mac platform is very similar, but some of the steps are slightly different.

This is what things will look like with a successful connection (if using Gnome 3 interface)
This is what things will look like with a successful connection (if using Gnome 3 interface)

Use Group Policy to Configure Windows Firewall to allow WMI

Using Group Policy to enable WMI (Windows Management Instrumentation) remote requests through the Windows Firewall

It is always a good idea to enable the Windows firewall under the domain profile. Enabling the firewall can prevent needed functionality as well.  For example, in some scenarios it may be required to be able to interact with client workstations or servers via WMI (which would be a type of unsolicited DCOM request on port 135).  Windows firewall will block this functionality unless you explicitly allow it.  To allow WMI remote requests through the windows firewall using Group Policy,  the “Allow Remote Administration Exception” policy needs to be enabled in the group policy object being applied to the workstations and / or servers requiring this access in the environment.  In order to set this, open up Group Policy Manager, and browse to the following location: Computer Configuration\Administrative Template\Network\Network Connections\Windows Firewall\Domain Profile(if setting this for the domain profile).  The same policy can be found in the “Standard Profile” as well.

Once you enable “Allow Remote Administration Exception” (and the computer objects refresh their policies usually 4 hours), WMI traffic should be allowed.

If you are impatient like me, sometimes it is best to just issue a command from the commmand line and be done.  The following are examples of commands that can be used to enable the same functionality as above.

Allow WMI through the Windows Firewall from the command line


If a connect attempt using wbemtest.exe fails – follow these steps to allow the requests through the firewall.

From the local machine command line, if the platform is Windows XP / Server 2003 (Below are three commands each providing different options)

 c:\> netsh firewall set service remoteadmin enable
 c:\> netsh firewall set service remoteadmin enable subnet
 c:\> netsh firewall set service remoteadmin enable custom,LocalSubnet

Windows7 / Server 2008 (Two commands below provide 2 ways to set the firewall to allow WMI)

 c:\> netsh advfirewall firewall set rule group="windows management instrumentation (wmi)" new enable=yes

You should see something like the following if successful.

Updated X rule(s) (where X is the number of rules updated)

  c:\> netsh advfirewall firewall set rule group="remote administration" new enable=yes

Again, you will see something like the following if successful.

Updated X rule(s).

This should be all that is required to allow WMI remote requests through the Windows Firewall.  The name of the Group Policy Object setting prevented me from getting this to work for quite a while.

Group Policy Filtering using WMI


The purpose of WMI filtering is to allow more control over the Active Directory objects that Group Policy is applied.  WMI filtering can be very powerful when used correctly, and can prevent the complex tree of Organization Units created to try and separate the Active Directory objects correctly.  Microsoft recommended best practice is to leverage filtering and item level targeting (for preferences) to avoid large and complex Active Directory structure.  While OUs can be used to filter, it is also a manual process and requires the interaction of an administrator.  With WMI filtering, if a workstation is upgraded to another operating system, WMI will automatically acknowledge that change, where in the OU structure, the account would have to be moved to a new OU manually.  So WMI filtering can reduce management overhead and prevent errors in policy application.

A couple of things to note when designing Group Policy using WMI filters:

  • The WMI query syntax is similar to an SQL query
  • Complex syntax can be written, but the more complex it becomes the more difficult it will be to manage
  • The more filters are used and the more complex the queries, the greater the length of the logon time
  • Per Microsoft recommended best practice, if a user / computer configuration if it is not being used, it should be disabled.  Every configuration that is processed will add time to the logon process even if it is not being used


By default no WMI filters exist in Active Directory.  The WMI filter container can be found in the Group Policy Management MMC under the Group Policy Objects container.

To create a new filter, right click the WMI Filters container and select “new” from the list.

This will open the WMI filter dialog window.  (shown below)

Type a name and description, and then click the “Add” button to add the query to run (to determine OS version in this case)

This will open a new dialog window and it will prompt for the namespace (which should already be populated and unless you are doing something really strange should not be changed).  It should be defaulted to root\CIMv2.  It will also have a big box to type the query you want to run in.  This is where you put the following:

select * from Win32_OperatingSystem where Version like "6.%" and ProductType = "1"

When you click “OK” on the WMI dialog window you will see the following:

Additional queries can be run (like checking for the presence of a battery, or this query can be modified to include the check for the existence of a battery.  Remember the notes from above, more complexity will lead to more difficulty managing them and it will increase logon times.  Click the “Save” button to save your new filter.

If everything worked out, you will now see something similar to the following:

Where a new filter will be listed under the WMI Filters container.  The last step before testing is associating the filter with the GPO.  To do this, click on the GPO you want to filter, and under the scope tab look for the WMI Filtering section toward the bottom of the window.  Select your newly created filter and you will now be filtering based on OS and only Windows 7 workstations will be affected by this policy. (for this example).


There really isn’t too much that can go wrong with these.  A couple of things that should be verified are the following:

  • Make sure the scope is set accurately, if the computer is a part of a security group, make sure that security group has read and apply rights to the Group Policy Object
  • Make sure that the group policy is applied to the correct OU and that it is enabled
  • Make sure no inheritance blocking is set, or an enforcement rule applied to another GPO that will prevent the settings of this GPO from applying correctly
  • Run the following command from a command prompt to verify that the GPO is applied as expected
gpresult /r

This is a quick way to set Group Policy using a variety of conditions providing the ability to maintain a more “flat” Active Directory structure so less manual processes need to be completed reducing time requirements and avoiding errors.

Authentication Using Kerberos Constrained Delegation

I would like to start off by saying that a large part of this documentation was obtained from MobileIron documentation that can be obtained from the MobileIron support site.  I am simply adding to to it and updating things that I found to be more difficult.

About Kerberos Constrained Delegation and MobileIron

Starting at VSP version 4.5.3 and later and Sentry version 3.3 and later, you can use Kerberos constrained delegation for authentication.  To use Kerberos constrained delegation, you need to already have a Kerberos environment set up that includes the following components:

  • Kerberos Key Distribution Center (KDC) A Kerberos Key Distribution Center (KDC) is a service on the Active Directory server that serves as an authentication service and supplies session tickets and keys to users and computers within the Active Directory domain.
  • Active Directory (AD) and Exchange Server  Active Directory is a directory service that authenticates and authorizes all users and computers in the associated Windows network.  The server that runs Active Directory is also called a domain controller.
  • Exchange Server  The following configurations are supported (however it has been successful with Exchange 2013 as well):
  • Exchange 2007 SP3 with AD 2003
  • Exchange 2010 SP1/SP2 with AD 2008 R2
  • Client Access Server (CAS)  One the server roles for Exchange Server. CAS supports Exchange ActiveSync applications.  It accepts connections to the Exchange server from different clients.
  • Exchange ActiveSync (EAS)  A data protocol for syncing data (email, contacts, calendar, tasks) between mobile devices and Exchange.  These components can exist on separate servers or on one server.

The following diagram shows the flow of information among the servers and MobileIron components.  The majority of these steps happen just one time.  Once the service token is cached on Sentry, the device accesses Exchange without requiring authentication for subsequent communication with Exchange until the token expires.


The steps that correlate with the numbers in the diagram above are listed below with a description of what is happening with each step:

Step Description
1 Configure the VSP for Kerberos and VSP sends Sentry the certificate with the Kerberos
configuration when the configuration is saved. Sentry reboots after receiving the configuration information from the VSP.
2 VSP pushes the SCEP profile that you configured for Kerberos and the trusted root certificate to the device on check-in.
3 After Sentry reboots (step 1), it connects to the KDC and requests a proxyable, renewable, and forwardable service token, configured for the Sentry SPN.
4 The KDC returns the service token for the configured Sentry’s SPN to the Sentry. The Sentry caches this token.
5 A device sends a request for Exchange access along with the cert, received in step 2, to Sentry. Sentry receives the request from the device and extracts the device UPN from the certificate.
6 Sentry sends the service token (received in step 4) and the device UPN to the KDC.
7 The KDC generates a device service token and returns it to Sentry.
8 Sentry inserts the device service token (received in step 7) into the ActiveSync request and forwards the request to the CAS server.
9 Exchange responds by sending the requested information (for example, email) to Sentry and Sentry forwards the requested information to the device.

Notes: Ports 88 (UDP and TCP) and 389 (TCP) between Active Directory and Sentry (or port 636 (TCP) if you are using SSL-enabled Active Directory) need to be opened to allow communication.  Port 88 is used for Kerberos protocol communication.  Port 389 (or 636) is used for the LDAP ping between Sentry and the KDC to verify that the KDC IP is the same as the Active Directory IP.

If Windows Server 2003 is being used, the KDC may listen for requests on port 88 using UDP
instead of TCP.  You can force Kerberos to use TCP instead of UDP by changing the MaxPacketSize
from 0 to 1 in the registry editor.  For information about how to do this, refer to the following
Microsoft KB article:

Configuration Overview

The following steps are required to set up Sentry for Kerberos authentication:
Step Action(s)
1 Verify IP Connectivity Between Sentry, AD, KDC, and Exchange.
2 Verify that Sentry, KDC, and Exchange are Syncing Network Time.
3 Create a Kerberos Service Account on the KDC For Each Sentry.
4 Map the Sentry Service Account to the servicePrincipalName.
5 Configure Constrained Delegation For Sentry Service Accounts.
6 Verify the Group Policy Values.
7 Enable the Kerberos Protocol on the Exchange Server.
8 Set Up SCEP for Kerberos Authentication.
9 Set Up the Exchange Profile for Kerberos Authentication.
10 Configure Device Authentication.
11 Set up Kerberos Notifications.
12 Validate the Kerberos Configuration.

Verify IP Connectivity Between Sentry, AD, KDC, and Exchange

The Active Directory server and the KDC server are typically the same server.  Before you configure Kerberos, ensure that there is IP connectivity between Sentry, the KDC server, and Exchange. For example, verify firewall ports and DNS resolution of the server names.

Verify that Sentry, KDC, and Exchange are Syncing Network Time

Sentry, the KDC, and Exchange servers must not have a time skew of more than five minutes
(the default on the KDC server).  If the time skew is more than five minutes, the Exchange server
assumes that the service token has been spoofed or manipulated and will not accept it.  The best way to avoid a time skew is to set up the servers to sync network time.

To configure Sentry to sync network time:

  1. Log in to the Sentry using the configuration URL (https://<servername>.<companyname>.com:8443).
  2. Select the Settings tab
  3. Select Date and Time (NTP) in the left panel
  4. Set the Primary NTP Server to the same NTP server that KDC and Exchange are using
  5. Click Apply


Create a Kerberos Service Account on the KDC For Each Sentry

To facilitate communication among KDC server, Exchange server, and Sentry, a Kerberos service account is set up for Sentry on the KDC server (usually on the Active Directory server).  If multiple Sentries are being used, it is recommended best practice to set up a service account for each Sentry on the Active Directory server.

MobileIron recommends that you create a separate service account on the KDC for each Sentry.  Having separate accounts for each Sentry assists in auditing and is especially useful in a multidomain configuration, but is not a requirement.

To create a Kerberos service account:

  1. Log in to your KDC server as an administrator
  2. From Start > All Programs, select Administrative Tools > Active Directory Users and Computers.  A browser appears that displays the Active Directory domains
  3. Expand the realm (Kerberos refers to a domain as a realm)
  4. Right-click Users and select New > User
  5. Enter the First Name and Last Name for the Kerberos service account.  The Full Name field is auto-populated.
  6. Enter the User Logon Name, preceded by HTTP/
  7. Choose the realm name from the drop-down list next to the User Logon Name field
  8. Delete the HTTP/ from the User Logon Name (pre-Windows 2000) field.  When you entered the User Logon Name in step 6, the User Logon Name (pre-Windows 2000) field auto-populated with the same string, but the slash (/) is not a valid character for this field.  Remove the slash and HTTP from the string in this input field.
  9. Click Next
  10. Enter and confirm the password
  11. Check (or uncheck) the password and account options depending on the organization’s policies.  If your company password policy allows, select Password Never Expires.  If this isn’t possible, plan a maintenance cycle where you update the password and/or create a new keytab for the
    Sentry configuration on the VSP.  If the passwords take a long time to propagate across the domain, you can use two service accounts per Sentry, rotating the service accounts as their passwords are about to expire.  Because this is a Sentry configuration change, Sentry will reboot causing a disruption of email traffic for a short time.
  12. Click Next
  13. Click Finish

The new user account now appears in the Users list. If you have multiple Sentries, MobileIron recommends that you create a service account for each.  Note that if you change the password for the Kerberos service account after you generate the keytab, Kerberos will not be able to renew the service token.  When the service token expires the user will no longer have access to email.  If the password is changed for the service account, a new keytab must be generated as described in the section titled Map the Sentry Service Account and Create a Keytab and it must be uploaded to the VSP as described in the section titled Configure Device Authentication.

Verify Realm in User Account Properties

Ensure that the realm is specified for each of the newly created service account(s).

The steps to verify the realm for the new service account(s):

  1. Right-click the new account in the Users list
  2. Select Properties
  3. Select the Account tab
  4. Select the realm from the drop-down list, if it is not already there  You can also make changes to the Account Options in this tab.
  5. Click OK

Map the Sentry Service Account to the servicePrincipalName

After you map the Sentry service account to the servicePrincipalName, the Delegation tab appears in the User Account Properties.  The delegation tab is required for the next step, Configure Constrained
Delegation For Sentry Service Accounts.

In this step you use the ktpass command on the KDC to perform one of the following two procedures:

  • Map the Sentry Service Account and Create a Keytab (optional)
    Generating a keytab is optional. A keytab is a file that stores domain credentials so that Sentry can log into Kerberos without being prompted for a password. When you configure Sentry for Kerberos authentication you can upload the keytab file.
  • Map the Sentry Service Account to the ServicePrincipalName (SPN)
    You can map the Sentry service account to the servicePrincipalName without creating a keytab.

Note: If a keytab is not generated, the Realm, Sentry Service Principal, Password, and Key Distribution Center information is entered into the Kerberos Configuration form, as explained in the About Kerberos Constrained Delegation section.

Map the Sentry Service Account and Create a Keytab

When you create a keytab, the Sentry service account is concurrently mapped to the servicePrincipalName.

To generate a keytab:

  1. On the KDC server, open a command prompt window
  2. At the prompt, type the following command:
ktpass /out <filename>.keytab /mapuser <kerberos_account>@<REALM> /princ HTTP/<kerberos_account>@<REALM> /pass <password>

Note: the realm must be in all uppercase.  This is characteristic of Kerberos.
Below is an example:

ktpass /out sentry1_eas_kcd.keytab /mapuser sentry1_eas_kcd@TEXAS.IRONMOBILE.COM /princ HTTP/sentry1_eas_kcd@TEXAS.IRONMOBILE.COM /pass mypassword1

where sentry1_eas_kcd.keytab is the filename that you will upload to Sentry.  The returned information for the above example looks like this:

Targeting domain controller:
Using legacy password setting method
Successfully mapped HTTP/sentry1_eas_kcd to sentry1_eas_kcd.
WARNING: pType and account type do not match. This might cause problems.
Key created.
Output keytab to sentry1_eas_kcd.keytab:
Keytab version: 0x502
keysize 74 HTTP/sentry1_eas_kcd@TEXAS.IRONMOBILE.COM ptype 0 (KRB5_NT_UNKNOWN)
vno 3 etype 0x17 (RC4-HMAC) keylength 16 (0x0d9d8f20b3d46f65b2cdb5cc9ec3167b)

Note: the warning can be ignored.

The keytab (in this example, sentry1_eas_kcd.keytab) is saved in the current working directory or where the command was entered.  To specify another location to save, simply include the full path in front of the filename.  For example, if the file is to be saved in the Desktop folder of the Administror account, sentry1_eas_kcd.keytab would be replaced with c:\Users\Administrator\Desktop\sentry1_eas_kcd.teytab.  This file should be copied to a location that is accessible when configuring Sentry in the VSP.  The file will be uploaded to the VSP.  Repeat this procedure to create a keytab for each Sentry / Sentry Service Account in the system.

Note: If the password for the service account changes, a new keytab file must be created and uploaded to the VSP before the current service token expires.  Failure to upload the new keytab file before the service token expires will result in the KDC failing to renew the token which will prevent users from receiving email.

Map the Sentry Service Account to the ServicePrincipalName (SPN)

To map the Sentry Service account to the servicePrincipalName:

  1. On the KDC server, open a command window
  2. At the command prompt, type the following command:
ktpass /out <filename>.keytab /mapuser <kerberos_account>@<REALM> /princ HTTP/<kerberos_account>@<REALM> /pass <password>

Note: The realm must be in all uppercase.

The following is an example:

ktpass /mapuser sentry1_eas_kcd@TEXAS.IRONMOBILE.COM /princ HTTP/sentry1_eas_kcd@TEXAS.IRONMOBILE.COM /pass mypassword1

The returned information for the above example looks like this:

Targeting domain controller:
Using legacy password setting method
Successfully mapped HTTP/sentry1_eas_kcd to sentry1_eas_kcd.
WARNING: pType and account type do not match. This might cause problems.
Key created.

Note: the warning can be ignored.

Repeat this procedure to map each Sentry / Sentry Service Account name to the servicePrincipalName if multiple Sentry service accounts where created.

Note: If the password for the service account changes, you must remap the service account to
the ServicePrincipalName using the new password before the current service token expires.  Failure to re-map using the new password before the service token expires will result in the KDC failing to renew the token which will prevent users from receiving email.

Configure Constrained Delegation For Sentry Service Accounts

Now the Sentry service account is mapped to the servicePrincipalName, constrained delegation needs to be configured on properties dialog windows for each of the configured service accounts.  The following steps can be used to accomplish this configuration:

  1. Enable Delegation
  2. Configure Allowed Authentication Protocols for the CAS
  3. Select Services

Enable Delegation

To enable delegation:

  1. From Start > All Programs, select Administrative Tools > Active Directory Users and Computers.  A browser appears that displays the Active Directory domains.
  2. Expand the realm
  3. Click Users
  4. Select the Kerberos user account that you created in “Create a Kerberos Service Account on the KDC For Each Sentry ” on page 4
  5. Right-click the account and select Properties
  6. Select the Delegation tab
  7. Select Trust This User For Delegation To Specified Services Only
  8. Select Use Any Authentication Protocol


Configure Allowed Authentication Protocols for the CAS

To configure the allowed authentication protocols for the Client Access Server (CAS):

  1. In the Delegation tab the Properties dialog for the service account, click Add
  2. Click Users or Computers
  3. In the Select Users or Computers dialog that appears, type the name (or the first few characters) of the CAS
  4. Click Check Names, the names of the CAS servers that match the string entered appear in the box
  5. Select the CAS to configure the authentication protocols
  6. Click OK

The Add Services dialog appears and displays a list of all services available on the selected CAS


Select Services

Multiple service types can be selected, but http must be selected at minimum for this functionality.

To select services to use for authentication:

  1. Scroll down to the http service type and select it
  2. Use Ctrl-click to select additional services types
  3. Click OK, the service types selected are added to the Delegation tab
  4. Click OK in the Properties dialog

If multiple CAS servers are in use, add the http service for each of the servers using the steps above.

Verify the Group Policy Values

Verify the group policy settings for Kerberos are set to the default values. MobileIron recommends that the default values are used.

To verify the group policy values for Kerberos:

  1. Log in to the KDC server as an administrator
  2. From Start > All Programs, select Administrative Tools > Group Policy Management
  3. Expand the domain and select Group Policy Objects
  4. Right-click Default Domain Policy and select Edit, the Group Policy Management Editor appears.
  5. Expand Computer Configuration and select Policies > Windows Settings > Security Settings > Account Policies > Kerberos Policy.
    The highlighted values are the default Kerberos values.

    Edit a policy setting:

  1. Double-click the policy
  2. Edit the value in the pop-up that appears
  3. Click OK

Enable the Kerberos Protocol on the Exchange Server

Enable the Kerberos protocol on the Exchange server so that Sentry can use Kerberos to
authenticate with Exchange

Steps to enable Kerberos authentication in IIS:

  1. Log in to your Exchange server as an administrator
  2. From the Start menu, select Administrative Tools > Internet Information Services (IIS) Manager
  3. Expand the Exchange CAS that is configured for the Sentry
  4. Navigate to Sites > Default Web Site > Microsoft-Server-ActiveSync
  5. Double-click Authentication in the middle pane, the Authentication page opens in the middle pane
  6. Select Windows Authentication in the middle pane
  7. Select Providers in the right pane, the Providers dialog displays
  8. If Negotiate:Kerberos is not already in the Enabled Providers list, select it from the Available Providers drop-down list and click Add, Negotiate:Kerberos moves from Available Providers to Enabled Providers
  9. Click OK
  10. Ensure that Windows Authentication and Basic Authorization are enabled in the middle pane


If one or both of them are not enabled, select the disabled authentication type and click Enable
in the Actions pane on the right.  Check that all other authentication types are disabled.  The Exchange server and the Active Directory server are now both set up for Kerberos authentication.

Note: Basic Authentication can be disabled to prevent non-certificate-based authentication.

Set Up SCEP for Kerberos Authentication

Configure SCEP to work with Kerberos constrained delegation. It is important to configure the SCEP profile with the following:

  • enable the proxy
  • set the Subject Alternative Name Type to NT Principal Name
  • set the Subject Alternative Name Type Value to $USER_UPN$

To set up SCEP for Kerberos authentication:

  1. Log in to the VSP Smartphone Manager
  2. If you are setting up a new SCEP profile, select Apps & Files | App Settings | Add New | SCEP
    If you are updating an existing SCEP profile, select the profile name and click Edit in the right panel.
  3. Configure the SCEP settings by filling out the form.  For details on the configuration options, please look here.

4. Click Save.

Note: If the SCEP entry is not valid, you will be prompted to correct it. Partial and invalid entries cannot be saved.

Set Up the Exchange Profile for Kerberos Authentication

Configure the Exchange profile for each of your Exchange servers that are using Kerberos authen- tication. Configure the Password field to pass the $NULL$ variable. Sentry is using identity certifi- cates for authentication so a password is not required.

To set up the Exchange profile for Kerberos authentication:

  1. Log in to the Smartphone Manager.
  2. If you are setting up a new Exchange profile, select Apps & Files | App Settings | Add New | Exchange.
  3. Configure the Exchange profile by filling out the form with the required values.  Explanations of each setting can be found here.  The 2 important settings for Kerberos authentication are going to be ActiveSync Password which should have a value of $NULL$ and Identity Certificate which should have the certificate of the user.
  4. Click Save once everything has been set correctly

Configure Device Authentication

Configuration of device authentication for Standalone Sentry takes place on the associated VSP.

To configure authentication:

  1. Obtain the certificates required for your implementation, this will be the certificate authority certificate
  2. In Smartphone Manager, select Settings | Sentry
  3. Click the edit icon for the existing Standalone Sentry
  4. In the Device Authentication list, select Identity Certificate (Kerberos).
    The following figure shows the form for Kerberos authentication.
  5. Click Upload Certificate
  6. Select the trusted root certificate chain received from the Kerberos administrator
  7. Click Upload
  8. If the certificates presented by the device against the Certificate
    Revocation List (CRL) published by the CA are going to be validated, then the Check Certificate Revocation List (CRL) checkbox should be selected.
    Notes: Only HTTP- and HTTPS-based CRLs are supported. Some CAs create LDAP-based CRLs by default that will not work with Sentry.
    For CRL validation to work, Sentry requires network connectivity to the CRL Distribution Point
    (CDP), usually the CA that issued the certificate, through an HTTP or HTTPS port.
  9. Use the Subject Alternate Name Type list to select the field in the client certificate that will be
    used to identify the user for Kerberos Constrained Delegation.
    Note: The Type is the same type that you specified when generating the client certificate. This type is often the NT Principal Name.
  10. Use the Value list to select the value used in the Subject Alternate Name field.
    Usually, the User UPN (user principal name) is used to identify the user.
  11. If a Kerberos-generated keytab file is used:
    a. Select the Use Keytab File checkbox
    b. Click the Upload File button that displays
    c. Select the keytab file
    d. Click Upload
    The keytab file provides the required Kerberos authentication information. For information
    about generating a keytab, see Map the Sentry Service Account and Create a Keytab.
    e. Optionally configure one or more Key Distribution Centers (see step 12).
    Note: If no KDC is specified, the system auto-detects the KDC.
  12. If no keytab file was uploaded, the Kerberos configuration fields will need to be completed manually. Use the following guidelines:
    • Realm  Enter the Kerberos administrative domain. The realm is usually the company domain name, in all uppercase characters.
    • Sentry Service Principal  The service principal for the Sentry service account, preceded by HTTP/. For example, if the user name of the service account is sentry1_eas_kcd, the service principal would be HTTP/sentry1_eas_kcd.
    • Password  Password for the Sentry service account
    • Key Distribution Center (optional)  The network service that supplies session tickets and temporary session keys. This is generally the Active Directory domain controller hostname.
  13. Configure the ActiveSync Server SPNs:
    • If you used the fully-qualified domain name of the ActiveSync server as the basis for the Service Principal Name of the server in the ActiveSync Server(s) field above, then select Derive SPN From FQDN Of ActiveSync Server.
    • If you configured the IP address or alternate DNS name of the ActiveSync server in the ActiveSync Server(s) field above, then deselect Derive SPN From FQDN Of ActiveSync Server.  Enter the SPNs for each of your ActiveSync servers, separated by semicolons, in the field that appears when this option is deselected. Typically, SPNs are in the form: http/<FQDN>.  For example, http/
      Note that the SPN is case-sensitive. The name of the CAS node that uses Kerberos Constrained Delegation (KCD) must exactly match the name of the node.
    • To view the CAS node:
      • Log on to the Active Directory server as an Administrator.
      • From Start > All Programs, select Administrative Tools > Active Directory Users and Computers.
      • Navigate to the Computers folder for the Kerberos realm (Kerberos refers to a domain as a realm).
      • Note the exact hostname of the CAS.


  14. Click Save

Set up Kerberos Notifications

The VSP can send notifications to one or more email addresses in the following

  • The Kerberos service account is locked
  • The Kerberos service account password is about to expire
  • The Kerberos service account password has expired

Email notifications are sent to the specified email addresses seven, five, two, and one days before the Kerberos service account password expires. For a locked or unavailable Kerberos service account, one notification is sent after you configure Sentry and save the configuration and the VSP detects the unavailable status of the account.
To set up notifications for Kerberos:

  1. In Smartphone Manager, select Settings | Sentry
  2. Click Preferences
  3. Enter the email address(es), separated by commas, to send the notifications.

Validate the Kerberos Configuration

Verify that the Kerberos configuration is valid by viewing information in the Sentry log in VSP.

To validate the Kerberos configuration:

  1. Log in to System Manager on the VSP
  2. Select the Troubleshooting tab
    At the bottom of the Logs page, the associated Sentries appear in the Remote Logs section.
  3. Click the View Logs link for the Sentry to be checked
    A dialog appears that shows the Sentry log
  4. Look for the following string in the Sentry log:
    Informational only: Successfully Received Sentry Service Ticket from KDC

    Although this message appears as a warning in the log, it just provides verification that Sentry
    has received the Kerberos service ticket.

  5. Repeat steps 3 and 4 for additional Sentries.

Debugging Kerberos Certificate Issues

Kerberos certificates aren’t authenticating.

Authentication is failing when:

  • errors like the ones below are present in the sentry.log file
  • Users aren’t receiving email

The logs will show error messages that can indicate possible causes.

ERR_BAD_OPTION (error code 13)

This error code is very generic and requires you to look at the e-data in the packet trace (sentry.log?).
Use the following resource to map the error code with the issue:
Once you have mapped the error code to the issue, look up the issue using the following resource
for an explanation of the issue:


The edata (NT_STATUS_UNMATCH) error means that the Exchange server name is incorrect.
Check the Sentry configuration on the VSP to see if the Exchange host name is the same as the
hostname configured in Active Directory.


Error while getting client service ticket No keytab entry for decrypting data encrypted with key type 23 and kvno 3.

A warning also appears on the KDC:

“The currently selected KDC certificate was once valid, but now is invalid and no suitable replacementwas found. Smartcard logon may not function correctly if this problem is not remedied. Havethe system administrator check on the state of the domain’s public key infrastructure. The chainstatus is in the error data.”

What this means is that after the keytab was generated, the key on the KDC was changed (could
be that the password for the Sentry’s service account was changed on the AD after generating the
keytab). So, the Sentry is no longer able to decrypt the KDC packets and the Kerberos tokens that
Sentry caches can no longer be renewed. The traffic will continue to flow to the client until the client
Kerberos token expires.

To fix this issue, regenerate the keytab on the KDC and upload the new keytab to the VSP.


Power Broker Open(Likewise Open) and Samba


Power Broker Open, what used to be named Likewise Open is a fantastic (mostly) worry free utility for joining Linux systems to a Windows Active Directory domain.  The amount of configuration is minimal and scripts have been created to manage these configurations.  For a cost you can even get additional modules and functionality to allow management of the Linux platform.  One of the more frustrating parts of this software is the lack of documentation, or maybe I should say proper documentation.  The goal of this article is to provide proper documentation on integrating Samba authentication against Active Directory using Power Broker Open.


I have recently discovered how to enable samba integration with this authentication.  It is not enabled by default and it is not the typical method of using winbind.  It may also be tempted to run the following:

net -U <username> ads join

but this just breaks the Power Broker Open functionality.  Success may be achieved with the Samba functionality, but it will be using a different mechanism for authentication now and all the authentication that was provided with Power Broker Open will cease to function.  A utility is included at least from the versions available from 12.04 and up, that adds the required functionality.


If Power Broker Open is installed on the system, all the required executables will be located in the /opt/pbis location in the bin directory.  The code that sets up the Samba integration is the following, and once you run it, that should be all that is required.  You will see a couple of lines, one that will be verifying the Samba version currently installed on the system, and the other one verifying the success / failure of the integration setup.

samba-interop-install --install

It is important to note that this utility must be run as root.  So either sudo or running as the root account will be required.  The error that is displayed when not running with root permissions does not make this obvious.  Once the Samba version is verified and compatabile and the integration was verified successful, from another domain joined workstation, entering the address of the server should provide the shares available.  If you need to setup shares, this can be done in the /etc/samba/smb.conf file.  The file is filled with documentation on how to do this, but all that is needed is to setup the shares in “shares” section of this file.  The official Samba website has really good documentation on setting up shares and the various options.  It can be found here:


Only a couple of things will prevent this from being successfully configured.

  1. Proper elevated credentials were not used when running the executable
  2. An incompatable version of Samba is installed on the system
  3. Power Broker Open has not been properly configured

Fix Active Directory Authentication / Login Ubuntu 13.10 and PowerBroker (Likewise-open)


When attempting to authenticate and logon to a GUI on the Ubuntu 13.10 platform, it appears as if authentication is successful, and the desktop may even appear briefly, but then immediately returns to the logon screen.  Verification of the setup and configuration of PowerBroker shows no issues.  Also, a standard console logon works successfully.  Only seems to affects Active Directory users, local users can still logon successfully and are presented a desktop.

Background / Cause

This bug:

explains what is causing the behavior, at least from a high level.  The details remain unknown.

The same problem seems to manifest itself in Ubuntu 13.10 where after logging in, the $PATH variable is incorrect.



Per the bug listing above, updating /etc/pam.d/common-session by commenting out the following line by adding a (#) in front of it, and adding the line below:

session sufficient

and add:


Successful authentication and access to the desktop as an Active Directory user with PBIS 7.5.2 is now possible.



Clean Up Active Directory Domain Controller Manually (when dcpromo fails or isn’t an option)


There are times a domain controller cannot be removed per Microsoft recommended best practices using dcpromo.  When this occurs the following guide has been the definitive method to properly and cleanly remove a domain controller from active directory.

Background / Cause

There are a number of reasons that a domain controller needs to be manually removed from Active Directory.  For example, if there is an unrecoverable hardware failure, a corrupted virtual machine, or someone just performed the wrong steps, leaving information in Active Directory and DNS.  a failed dcpromo either removing a domain controller or adding a domain controller is also another reason for manual domain controller object clean up.


In the event that the NTDS Settings object is not removed correctly or fails using dcpromo,  you can use the Ntdsutil.exe utility to manually remove the NTDS Settings object.

If a new domain controller with the same name as the failed domain controller is built to be placed back in production, then only need perform only the first procedure to clean up metadata, which removes the NTDS Settings object of the failed domain controller. If the goal is complete removal of the domain controller all the procedures / steps need to be completed: clean up the Domain Controller metadata, remove the failed server object from Active Directory Sites and Services, remove the computer object from the domain controllers container in Active Directory Users and Computers, and clean up DNS.


The following tools will be required to successfully complete all steps: Ntdsutil.exe, Active Directory Sites and Services, and Active Directory Users and Computers.

An account with Enterprise Admins universal group membership is also required.

Caution: Using the Ntdsutil.exe utility incorrectly may result in partial or complete loss of Active Directory functionality.

Step 1: Clean up the Domain Controller metadata

From a command prompt, type Ntdsutil.exe and press ENTER (shown below).


At the Ntdsutil: prompt, type metadata cleanup and press ENTER.

ntdsutil: metadata cleanup
metadata cleanup:

From the metadata cleanup: prompt, type connections and press ENTER.

metadata cleanup: connections
server connections:

From the server connections: prompt, type connect to server <servername>, where <servername> is the domain controller (any functional domain controller in the same domain) from which you plan to clean up the metadata of the failed domain controller. Press ENTER.

server connections: connect to server dc1
Binding to dc1 ...
Connected to dc1 using credentials of locally logged on user.
server connections:

Note: Windows Server 2003 Service Pack 1 eliminates the need for the above step.

Type quit and press ENTER to return you to the metadata cleanup: prompt.

server connections: q
metadata cleanup:

Type select operation target and press ENTER.

metadata cleanup: select operation target
select operation target:

Type list domains and press ENTER. This lists all domains in the forest with a number associated with each.

select operation target: list domains
Found 1 domain(s)
0 - DC=domain,DC=net
select operation target:

Type select domain <number>, where <number> is the number corresponding to the domain in which the failed server was located. Press ENTER.

select operation target: Select domain 0
No current site
Domain - DC=domain,DC=net
No current server
No current Naming Context
select operation target:

Type list sites and press ENTER.

select operation target: list sites
Found 1 site(s)
0 - CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=domain,DC=net
select operation target:

Type select site <number>, where <number> refers to the number of the site in which the domain controller was a member. Press ENTER.

select operation target: Select site 0
Site - CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=domain,DC=net
Domain - DC=domain,DC=net
No current server
No current Naming Context
select operation target:

Type list servers in site and press ENTER. This will list all servers in that site with a corresponding number.

select operation target: List servers in site
Found 2 server(s)
0 - CN=dc2,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=domain,DC=net
1 - CN=dc1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=domain,DC=net
select operation target:

Type select server <number> and press ENTER, where <number> refers to the domain controller to be removed.

select operation target: Select server 1
Site - CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=domain,DC=net
Domain - DC=domain,DC=net
Server - CN=dc1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=domain,DC=net
 DSA object - CN=NTDS Settings,CN=dc1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=domain,DC=net
 DNS host name -
 Computer object - CN=dc1,OU=Domain Controllers,DC=domain,DC=net
No current Naming Context
select operation target:

Type quit and press ENTER. The Metadata cleanup menu is displayed.

select operation target: q
metadata cleanup:

Type remove selected server and press ENTER.

A warning message will be displayed.  It can be reviewed, but pressing Yes will remove the metadata of the server.


metadata cleanup: Remove selected server
"CN=dc1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=domain,DC=net" removed from server "dc2"
metadata cleanup:

At this point, Active Directory confirms that the domain controller was removed successfully. Note:  If an error is received stating the object could not be found, Active Directory might have already removed from the domain controller.

Type quit, and press ENTER until back at the command prompt.

Remove the failed server object from the sites and services mmc

In Active Directory Sites and Services, expand the appropriate site.

Delete the server object associated with the failed domain controller.

Remove the failed server object from the domain controllers container

In Active Directory Users and Computers, expand the domain controllers container.

Delete the computer object associated with the failed domain controller.

Windows Server 2003 Active Directory might display a question window, asking you if you want to delete the server object without performing a dcpromo operation (which, of course, you cannot perform, otherwise you wouldn’t be reading this article, would you…) Select “This DC is permanently offline…” and click on the Delete button.

Another confirmation window will be displayed.  If this is, in fact, the domain controller object to be removed, click Yes.

Remove the failed server object from DNS

In the DNS snap-in, expand the zone that is related to the domain from where the server has been removed.

Remove the CNAME record in the _msdcs.root domain of forest zone in DNS. You should also delete the hostname and other DNS records.  A through discovery of all records should be completed to ensure all references to the missing domain controller have been removed.  This means that expanding all areas of the DNS tree and verifying each section only has valid “live” domain controllers is required.

If you have reverse lookup zones, also remove the server from these zones.

Other considerations

Also, consider the following:

  • If the removed domain controller was a global catalog server, evaluate whether application servers that pointed to the offline global catalog server must be pointed to a live global catalog server.
  • If the removed DC was a global catalog server, evaluate whether an additional global catalog must be promoted to the address site, the domain, or the forest global catalog load.
  • If the removed DC was a Flexible Single Master Operation (FSMO) role holder, relocate those roles to a live DC.
  • If the removed DC was a DNS server, update the DNS client configuration on all member workstations, member servers, and other DCs that might have used this DNS server for name resolution. If it is required, modify the DHCP scope to reflect the removal of the DNS server.
  • If the removed DC was a DNS server, update the Forwarder settings and the Delegation settings on any other DNS servers that might have pointed to the removed DC for name resolution.

Known Issues / Troubleshooting

Problem: | The domain controller doesn’t appear to exist when using the ntdsutil.exe utility

Solution: | It is possible that the metadata for the domain controller was, in fact, removed but other areas (Sites and Services, Users and Computers, and / or DNS) may still have information about the server.  Quitting the ntdsutil.exe utility and reviewing the other areas is recommended.  If no further evidence has been found, it is safe to assume the domain controller was successfully removed.

Problem: | Strange error messages showing up on client machines when authenticating to the domain.

Solution: | This is almost always related to incomplete removal of domain controller information in DNS.  Review all levels of DNS to ensure complete removal of all information regarding the missing domain controller.


Petri IT Knowledgebase


Active Directory Group Policy Preferences


Microsoft released a great new set of tools for Active Directory with the release of Windows Server 2008 called Group Policy Preferences.  Group Policy Preferences was introduced in the 2008 release of Microsoft Windows Server.  It was the opinion of most members of the systems administration community that we should have seen these incorporated into Active Directory much sooner.  They provide a simple GUI  interface to manipulate and control almost any aspect of the Microsoft Windows operating system.


The following document will not only outline Group Policy Preferences and the powerful management tools available but also provide Microsoft best practice surrounding them.  Simple examples will be provided but these examples can be combined to really harness the full power of Group Policy Preferences.

Detailed Information


Probably one of the easiest and most useful tasks that Group Policy Preferences accomplishes is mapping network drives.  The best way to accomplish this is to incorporate existing Microsoft best practice (which should already be in place in a standard  environment) and mesh it together with the new Group Policy Preferences component for ease of administration and improved security.

Security Setup

This example will assume that an Accounting department exists and that a share for the Accounting department is required for collaboration.  Per Microsoft recommend best practice, and found to work most efficiently  across all types of environments is creating domain local security groups for access to shared resources and assigning NTFS permissions to these security groups.  Next domain global groups are created and all the users required to access the resources are placed into these global groups.  Finally, the global groups are associated to the local groups connected to the shared resources.  This is actually a Microsoft recommend best practice but very few organization actually implement this strategy and even disagreed with Microsoft wholeheartedly.  However, when leveraging this configuration it becomes very clear why this method is used and recommended by Microsoft.

The following will provide the details of an example of how this methodology works.  The shared resource name will be simply “Accounting“.  It is recommend to name the folder name identical to the shared name for simplicity, but isn’t necessary.  It is also recommend to create a folder administration group for managing file and folder NTFS permissions.  This will provide very granular control over who has access to all file and folder permissions.  Potentially, user accounts would only be placed into this security group as permissions need to be changed or setup.  A domain global security group is created called “user-file and folder admins” group. This is not necessarily an arbitrary name.  Naming and naming conventions are also critically important when working with Active Directory.  Any IT professional that feels differently has most likely had very little experience managing or administering an Active Directory domain. The naming convention used in this example will follow the format [type]-[description]-[optional details] where [type] is the type of objects that are associated with the group, [description] is a short description of the group like Accounting Department, and the [optional details] could be something like read OR write or manage OR standard detailing the access levels.  For the Accounting department, in order to provide some examples of user security groups, we have 3 security groups; user-Accounting Department-general, user-Accounting Department-managers, and user-Accounting Department-controllers.

In a similar fashion the network resource will have various security groups associated with it.  In order to keep this simple, the following will be used; file-Accounting Share-read and file-Accounting Share-write.  We now have all the groups required to setup a solid environment and provide access controls through NTFS permissions.

We will make user-Accounting Department-managers and user-Accounting Department-controllers a part of the file-Accounting Share-write and the user-Accounting Department-general group a part of the file-Accounting Share-read security group.  This will allow managers and controllers to manipulate the data in the share, but the general accounting users will only be allowed to read the data as we may want them to have access to the data, but we don’t want them to manipulate or change it.  Users will then be placed in the appropriate user global security group.

NOTE:  It is really important that users are never placed directly into the file security groups.

Mapping a network drive using Group Policy Preferences

After testing and verifying the access rights based on the new security groups, the next step involves actually setting up the configuration that will map the drives.  First, a Group Policy Object is created which will contain the preferences.  The reoccurring theme is back with naming of Group Policy Objects.  When creating a Group Policy Object, the name will be important and a standard should be followed per Microsoft.  For this example, the following template is used; [object it applies]-[Short description]-[type], where [object it applies] refers to user, computer, or both, [Short description] provides a quick description of the Group Policy Object‘s goals, and [type] would be policy, preference, or both indicating what methods of configuration are used.

Based on this template for Group Policy Objects the following Group Policy Object is created user-Drive Mapping-preferences.  The name quickly identifies that the Group Policy Object will apply to user objects, it is for the purpose of drive mapping, and it uses preferences to accomplish this task.

Once the Group Policy Object has been created, right clicking the object and selecting the “edit” option will open the policy.  Drilling down under the User Configuration section, then Preferences, then Windows Settings, Drive Maps will be listed.  Right clicking this object will provide a menu, select “New -> Mapped Drive“.  A new “Properties” window will be displayed allowing a configuration to be built for the drive mapping.

All preferences use the same 4 options; create, delete, update, and replace.

  • Create will create the “configuration” if it doesn’t exist, but will not check for changes or update if anything is changed.
  • Delete removes the “configuration” and can be used in conjunction with the other actions.
  • Update will update the “configuration” by creating if needed or updating if required.  A quick note, the update action does not remove an item if the object it is being applied to falls out of scope.
  • Replace is similar to update, but it is the only action that can be used with the “remove when no longer applies” option.  If the “replace” action is implemented and the object (user for example) is no longer in the scope of the preference, replace will remove the preference configuration.

For mapped drives, the most common action used is “replace” as it will add and remove mapped drives as needed.  Once the action has been selected, the path to network resource in this case \\fileserver01\Accounting is provided in the “Location” entry box and the “reconnect” check box is selected if this functionality is needed.  Preferences also allows for the network resource to be named.  This is a great idea to prevent end-users from becoming confused or using the drive letter associated with the network resource.  By placing a check in “Label as“, and in the space provided supply a meaningful name for your network resource (to remain consistent and to keep things simple, the actual shared resource name could be used here (Accounting).  Next the drive letter is selected.  Again, another great option with Group Policy Preferences is the ability to select “User first available, starting at:” which will attempt to map the drive to the drive letter indicated first, but if it is in use continues to attempt to map the drive to ascending letters until an open letter is found.  This functionality displays why naming the shared resource is so important.  If the end-user was calling the network resource the “G” drive for example, but today it is the “J” drive, they would be confused and likely contact the help desk believing they lost access to their network drive.  Of course using “Existing” allows a single letter to be chosen for the mapping.  There are several other options on this Properties page, but they will not be covered in detail here.

The next, and arguably the more impressive page / tab is the “Common” tab.  This is the options that will be configured for how the drive mapping will be used.  This tab contains features like “Run in logged-on user’s security context (user policy option)” which allows preferences to run as the user logging on with the user’s defined rights and permissions.  The “Remove this item when it is no longer applied” option (used only when the “Replace” action is selected) removes the configuration if it no longer applies to the object (user or computer).  “Apply once and do not reapply” is used when a configuration is only needed to be applied one time, similar to “run once” in Windows.  The last option is “Item-level targeting” and is what really makes Group Policy Preferences worthwhile.  It allows fine grain control over what configurations apply and how they apply using almost unlimited filtering.

For this example, we will be assuming that the organization has several sites / locations and the accounting department of each of these sites has individual drive mappings.

By leveraging the “Item-level targeting” the drive can be mapped to the users of the account security groups (created above) who have a IP address in the subnet of the specific location, or using the Active Directory Site.

First it should be understood that adding a single targeting item is completely acceptable, but several items can be used with either AND or OR statements and IS or IS NOT statements.  Several items can be combined into a collection and collections can be evaluated the same way individual items are evaluated.

In order to better understand this, using the example above, a mapped drive definition will be setup that will map the network drive to any user who meets the following criteria:

  • is a member of the user-Accounting Department-managers security group
  • is a part of the “Location A” site in Active Directory Sites and Services
  • has been assigned an IP address in the range of –

To make this happen, a collection is created.  In that collection 2 targeting items are created.  The first item defines that the IP address is between and and the other item defines the object must be a part of the Location A site in Active Directory Sites and Services.  Now, using the item options it can be specified that one of these conditions must be true, or both of these conditions must be true by toggling the And and Or options.  Using “And” will define that both items must be true for the drive mapping to occur while using “Or” will allow for either of the conditions to be met.  The same applies when looking at the “Is” and “Is Not” item options.  These options perform just want you would expect.  By using the “Is” option, the conditions must be true, and conversely by using the “Is Not” option, the conditions must be false.


Once the collection is created and configured to provide expected results, the last task is to provide a single item requiring membership in the user-Account Department-managers.

Again, the item options can be used to require is be true and the collection be true or require that one or the other is true.  In the example, the goal is to have everything match, so the “and” modifier will be used for all items and since we want everything true, the “Is” modifier will also be used for each item.

Saving this new configuration and applying it to an OU that contains the users, the following will be the result of all the configurations made in this example from the security group selections to the item level targeting of the drive mapping preference.

  • Managers of the Account department for the Location A site will receive a mapped drive
  • These users will have read and write access to the drive
  • If they move to another location, they will lose the mapped drive until they return to Location A
  • If a manager is moved to a new role within the organization, simply removing them from the user-Accounting Department-managers will remove the drive mapping from their workstation, but also remove access rights to the network location so manually providing the UNC path to the resource will result in an “access denied” message.

The example above provides a simple and hopefully straight forward example of how Group Policy Preferences can be leveraged and how potentially powerful they can be in administration of rights and delegation of resources.

Known Issues / Troubleshooting

Problem: |  The network resource does not get mapped to a drive even though all settings are correct and user is a member of required security groups.

Solution: |  Due to Group Policy Preferences being relatively new, there are several prerequisites required in order for the instructions of the preferences to interact with older windows systems.  The prerequisites will not be covered here, but a quick search should provide several Microsoft documents that define what each version of Windows require in order for successful use of Group Policy Preferences.

Problem: |

Solution: |

References / Additional Resources