Spelunking Group Policy

object001

Windows Server 2008 R2, with PowerShell 2.0 and the GroupPolicy management module allows for powerful administration of Active Directory Domain Services (AD DS) based Group Policy. A question came up during a recent session of the Group Policy course, and then again the following week during a session of a PowerShell course. The distilled-down question is essentially: Scripting the GPMC is good for linking GPOs and other such activities, and the W2K8R2 cmdlets let us examine values if we know the particular registry value we’re looking for, but how can we search, peruse, or report on the settings in one or more GPOs without running either a GPO report of resultant set of policy (RSoP) report?

Have you ever wanted to find what registry values a group policy object (GPO) contains? Indeed, you can get a report of one GPO using the Get-GPOReport, or for all GPOs in a domain by adding the -All parameter to that cmdlet, yet in either case, the output is either in HTML or XML format. There is also a wonderful Get-GPResultantSetOfPolicy cmdlet which also gets the effective policy settings, but again in either HTML or XML format. Sure, a text search or parse of the HTML gives some decent results, and reading the XML output is far better, especially with the built-in XML tools in PowerShell, however there is actually an even easier to work with and more powerful alternative.

Consider the following functions, which use the Get-GPRegistryValue cmdlet to do the actual work.

trap [ParameterArgumentValidationException] {
# placeholder for processing bad key errors
}

if( @(get-module GroupPolicy).count -eq 0 ){
import-module GroupPolicy
}

function global:Get-GPRegistrySubKey( $gpo, $key ){
$val = @(Get-GPRegistryValue $gpo -Key $key )
$val | %{
$_
if( $_. FullKeyPath -ne $key ){
Get-GPRegistrySubKey $gpo $_. FullKeyPath
}
}
}

function global:Get-GPRegistryKey( $gpo, = “Default Domain Policy”, $key = “HKLMSoftware” ){
Get-GPRegistrySubKey $gpo $key | FT ValueName,PolicyState,HasValue,Type,Path,Value -auto
}

That’s it. The trap handler and conditional Import-Module block may be optional, depending on the environment in which you’re using the functions. The first function, Get-GPRegistrySubKey, does then actual work, and the second one, Get-GPRegistryKey, formats the results to be more dense and human readable. With these functions defined in your profile or other appropriate script, dealing with the output is more convenient that using the parsed XML output from Get-GPOReport or Get-GPResultantSetOfPolicy.

In its simplest form, this Get-GPRegistryKey function can be called with no parameters, which will assume the default GPO of the Default Domain Policy, and also assumes the registry key HKLMSoftware (the Policies, Computer Configuration portion of the GPO) as the base for the search/report. This function in turn simply calls the other function, Get-GPRegistrySubKey, with these same values, and then formats the output in table form. Get-GPRegistrySubKey fetches all of the values under that key by calling the Get-GPRegistryValue cmdlet with just the GPO name, this base key, and no specific value. Although the variable $val could be optimized out by rewriting the script to send the Get-GPRegistryValue results directly to the ForEach-Object cmdlet (used with its % alias here) loop, this intermediate step of storing the results in a variable and then passing those results down the pipeline to ForEach-Object was retained for troubleshooting purposes. Within the body of the loop through each of the results, the subkey is emitted and then if the subkey is not the same as the key, then Get-GPRegistrySubKey calls itself recursively in order to traverse down to the subkeys and values.

Specific values for the GPO name and registry key could be supplied to these functions for more focused results. Additionally, a number of GPOs could be reported on by using a technique such as:

get-gpo -all | %{
Get-GPRegistryKey $_.displayName “HKLMSoftware”
Get-GPRegistryKey $_.displayName “HKCUSoftware”
}

The results of Get-GPRegistryKey or this sort of loop which invokes it could be used with filtering mechanisms such as Where-Object. These fairly simple functions not only provide a straightforward way to enumerate and list the settings within a GPO, but also can serve as an example of a more elaborate searching and reporting tools and automation for bringing sanity to GPO management.

Delving into DirectAccess (without Drowning in IPv6)

 

object001

One of the great synergistic cofeatures of using Windows 7 in a Windows Server 2008 R2 network infrastructure is DirectAccess, which Microsoft claims is not a Virtual Private Networking (VPN) technology. These operating systems still support older VPN technologies including PPTP, as well as VPN cousins L2TP (as of Windows 2000) and SSTP (as of Vista SP1 and Windows Server 2008). Just how does DirectAccess compare to those other technologies, such that it can be useful as an alternative to those older VPN technology choices?

Why does Microsoft claim that DirectAccess is not a VPN technology? The technical distinction is that DirectAccess technology is always on. In other words, DirectAccess clients connect into their DirectAccess server as soon as the client machine starts up and the underlying physical network connection(s) become available. Other than that, and marketing spin, it is a VPN technology.

Let’s look a bit deeper at DirectAccess to better understand what it is and is not. To quote Microsoft TechNet “DirectAccess, introduced in the Windows® 7 and WIndows Server® 2008 R2 operating systems, allows remote users to securely access enterprise shares, web sites, and applications without connecting to a virtual private network (VPN).” <http://technet.microsoft.com/en-us/network/dd420463.aspx> More specifically, the DirectAccess client is a feature of the Windows 7 Ultimate and Enterprise editions. Like PPTP, L2TP, and SSTP, DirectAccess also uses tunneling to carry Internet Protocol (IP) traffic encapsulated in the Point to Point Protocol (PPP), however the further tunneling details of these four technologies (PPTP, L2TP, SSTP, DirectAccess) are what makes them unique. There are two aspects to the tunneling distinctions, namely (a) tunnel negotiation, establishment, teardown, and administration, as well as (b) tunnel encapsulation and security for the content – the network traffic carried in IP/PPP across the tunnel.

One of the critical components of DirectAccess is the use of the Internet Protocol version six (IPv6) as the internetworking protocol carried by the tunnel, as well as in two of the three options for how DirectAccess implements the tunnel itself. Two IPv6 to IPv4 interoperability and coexistence technologies which can be used with DirectAccess are 6to4 and Teredo. With 6to4 tunneling, IPv4 traffic is tunneled over IPv4 networks such as the public Internet and private IPv4 networks. However, 6to4 tunneling does not work particularly well with IPv4 network address translation (NAT), luckily we have one of the other IPv6 interoperability technologies, Teredo, as another choice for DirectAccess tunnel foundations. Teredo, named after the “shipworm” mollusk that is known for boring holes into wooden ship hulls, is designed to provide IPv6 over IPv4 tunneling like 6to4, but with the advantage of boring through routers which do NAT. The third choice for the IPv6 over IPv4 tunneling of DirectAccess is use of IP-HTTPS, which utilizes the Hypertext Transfer Protocol (HTTP) over the Secure Sockets Layer or the standardized Transport Layer Security (SSL/TLS), and like regular https for web site access, uses TCP port 443 for the server side of the connection. Whether 6to4, Teredo, or IP-HTTPS is used for DirectAccess, the datagrams tunneled within such conduits is IPv6.

Like any typical VPN server, the DirectAccess server needs to have a publicly addressable network interface (the public or untrusted side) and a separate internal network interface (the private or trusted side). Again, the DirectAccess Server implementation is in Windows Server 2008 R2. An additional requirement which Microsoft specifies that is not universal to all VPN technologies is that the public side of the DirectAccess server have two consecutive public IPv4 addresses configured and accessible. Like many L2TP implementations which use IPsec with public/private key pair authentication, and SSTP which uses SSL/TLS with public/private key pair authentication, so too does DirectAccess require a public key infrastructure (PKI). The baseline requirement is merely to have public key certificates issued to the computers involved (client and server). A variation on the public key certificate for the computer is to issue a smart card which is used in the client. If Network Access Protection (NAP) is also required in your environment, then the public key certificates issued to the computer would be health certificates issued from your NAP authority.

Another Microsoft-specific requirement which is hopefully not too much of a surprise now that Active Directory is over ten years old, is that at least one AD DS domain controller and DNS server running on Windows Server 2008 SP2 or Windows Server 2008 R2 is required in the internal network on the trusted side of the DirectAccess server.

With these technical requirements in mind, what is most important to understand is to not be afraid of IPv6. First of all, IPv6 implementations have been running in production environments and the public Internet for over 10 years. More to the point, with respect to DirectAccess, is that Microsoft took great care in the design of DirectAccess so that you do not need to transition your networks to be fully IPv6-capable in order to use DirectAccess. If your organization is using modern versions of Windows, the requirements for DirectAccess are actually quite modest. If you’re looking for an always-on VPN-like solution for remote client connectivity, consider setting up a DirectAccess testbed and assessing its effectiveness in your organization.

A Certifiable Case of Mistaken Identity – Exchange Server Certificates

object001

A student recently asked the following question (paraphrased somewhat):

“I have Outlook XP clients predominantly, and they’re OK, but I also have some Outlook 2007 clients on my network, and I get an error message each time they open Outlook 2007.”

Outlook 2007 and Outlook 2010, especially with Outlook Anywhere (OA), as well as the Exchange Server 2007/2010 hosted services such as Outlook Web Access/App (OWA), Exchange ActiveSync (EAS), Exchange Web Services (EWS), and POP and IMAP all use the Client Access (CA) server role. Actually, a few scenarios with Exchange Server 2007 still allow Outlook clients to directly access the Mailbox (MB) server role without going through the CA role, however we shall not focus on that scenario here.

If you receive an error such as “Security Alert: The name on the security certificate is invalid or does not match the name of the site,” this can be due to a difference in the internal and external names of your Client Access server(s).

If you have issued a public key (PK) certificate to each of your Exchange Client Access servers, there are two kinds of mistaken identity issues that could arise. Let’s consider just one Exchange Client Access Server for the moment for simplicity. If you organization is using an internal name for the server such as myorgexch.myorg.local and an external name such as webmail.myorg.com, those are the seeds for an identity issue to sprout up.

If you use an internal Active Directory Certificate Services (AD CS) infrastructure to issue a PK certificate to this server and use its internal name (myorgexch.myorg.local) in the subject field of the certificate, web clients using URLs which use the external name (webmail.myorg.com) may receive this error.

On the other hand, if you have payed an external PK certification authority for a certificate for this server, which uses the external name (webmail.myorg.com) as the subject, yet use the internal name (myorgexch.myorg.local) in any of the URLs for clients, this error can also result.

Several services in the Exchange Server Client Access role, such as Outlook Anywhere and Outlook Web Access/App, support both an internal and an external URL. If you included the /ExternalCASServerDomain option during the Exchange Server setup, then both of these URLs might be set appropriately. If not, these external/internal URLs can be reconfigured either via the graphical Exchange management tools, or of course using the Exchange Management Shell (EMS).

For example, the following commands are some examples to accommodate the names listed above, assuming that the myorgexch part of myorgexch.myorg.local is the name of your (first, or current concern) server with the Client Access role.

Set-OWAVirtualDirectory myorgexchOWA* -ExternalURL https://webmail.myorg.com/OWA
Enable-OutlookAnywhere -Server:myorgexch -ExternalHostName:webmail.myorg.com -SSLOffloading $false
Set-ActiveSyncVirtualDirectory -Identity myorgexchMicrosoft-Server-ActiveSync -ExternalURL https://webmail.myorg.com
Set-WebServicesVirtualDirectory myorgexchEWS* -ExternalURL https://webmail.myorg.com/ews/exchange.asmx
Set-OABVirtualDirectory myorgexchOAB* -ExternalURL https://webmail.myorg.com/OAB
Set-ECPVirtualDirectory myorgexchECP* -ExternalURL https://webmail.myorg.com/ECP

As these examples show, there are far more services than just OWA hosted by the CA server role, and therefore the name webmail.myorg.com is not necessarily the best name for your public Exchange presence. There are other complexities as well with a variety of load balancing techniques and such certificates. The critical aspect of PK certificates used for https (and other SSL/TLS-ized access) is consistent names as well as an appropriate web of trust (an aspect of PK infrastructure, or PKI) for such certificates. Consider this general guidelines: For access from public networks such as the public Internet, external publicly-registered names should be used in the certificates and in the external URLs.