Group Policy Object Autopsy

object359

It has been a phenomenal amount of time since my blog post about “Spelunking Group Policy,” and although I have thought of several other topics to write about in the intervening months, I thought it fitting to resume posting here with another article relating to both Group Policy and my good friend, Windows PowerShell.

Two of the most exciting cmdlets in the Windows PowerShell 2.0 GroupPolicy module (included in the Remote Server Administration Tools (RSAT) or also available on Active Directory Domain Services Domain Controllers) are Set-GPRegistryValue and Set-GPPrefRegistryValue. I refer to them as exciting because after the initial joy of using New-GPO to create one or thousands of new Group Policy Objects, the thrill wears off and the temptation to do one of things might set it.

For some of you, the temptation to resort to comfort of the Graphical User Interface (GUI) Group Policy Management Console (GPMC), pointing and clicking (or touching and tapping if you’re connected in via an iPad, Android Tablet, or one of those recently end-of-lifed HP TouchPads) on the GPO and choosing “Edit” from the menu to invoke the also very graphically-oriented Group Policy Management Editor (GPME) can lead you to stray from the realm of automation and scripting and into the imperative touch-and-tap (do you really still point-and-click?) interface of the GUI GPME.

Others of you might fall to another temptation. Yes, creating a Registry.POL file directly from scratch to represent the settings you would like to have configured in your precious GPO. That technique is not for the feint of heart.

The middle way, a potentially more Zen approach, let’s you use the GUI and PowerShell to get into the anatomy of a GPO with the precious settings you need and transplant some of these good and easy to understand settings into another body, namely another GPO. The best part of it is that you can use PowerShell to inject these settings into other GPOs either by cloning from an example, or by learning the representation of the settings you need and crafting brand new instances of those settings and grafting them into a new GPO.

Let’s start with a simple but useful setting which allows script execution in Windows PowerShell. If you know how to find this setting in the GPME, then you can learn how to use PowerShell on a management station to automate configuration of this setting. In the GPME, navigate to Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Windows PowerShell. Within that category (key), the yellow folder called “Windows PowerShell,” there should be a setting (value) on the right-hand pane of the GPME called “Turn on Script Execution.” If you edit that policy setting graphically, you will see that it can either be Disabled or Enabled, or the tristate default Not Configured. Disabling this setting is like locally assigning “Set-ExecutionPolicy Restricted” which is no fun. Secure perhaps, but not fun when you need to run scripts. Enabling the “Turn on Script Execution” setting provides three possible values for the Execution Policy option: Allow only signed scripts, Allow local scripts and remote signed scripts, and Allow all scripts. These correlate to execution policy values in the shell (e.g. with Set-ExecutionPolicy) of AllSigned, RemoteSigned, and Unrestricted, respectively. As an example, let’s assume that we have configured this as Enabled and “Allow local scripts and remote signed scripts” and applied this change to the GPO.

Once you have configured such a Group Policy setting in the GPM Editor in this way, you can go back into Windows PowerShell and investigate what setting was actually configured. You don’t even have to look up the setting in the administrative templates .ADMX and .ADML files (or classic .ADM either). And better still, you don’t have to manually dig through the Registry.POL file to determine what settings have been configured (although that is always educational). The easier way is to use the Get-GPRegistryValue cmdlet. Assuming that you have done an “Import-Module GroupPolicy” and are ready to use this cmdlet, you could refer back to my blog post about “Spelunking Group Policy” to find the values. Let’s assume that you have done such spelunking and navigated down to the proper key and found that the key “HKLMSoftwarePoliciesMicrosoftWindowsPowerShell” now has some values.

Get-GPRegistryValue "Enable PowerShell Scripting" -Key "HKLMSoftwarePoliciesMicrosoftWindowsPowerShell"

The above incantation in PowerShell should reveal the following information:

KeyPath : SoftwarePoliciesMicrosoftWindowsPowerShell
FullKeyPath : HKEY_LOCAL_MACHINESoftwarePoliciesMicrosoftWindowsPowerShell
Hive : LocalMachine
PolicyState : Set
Value : 1
Type : DWord
ValueName : EnableScripts
HasValue : True
KeyPath : SoftwarePoliciesMicrosoftWindowsPowerShell
FullKeyPath : HKEY_LOCAL_MACHINESoftwarePoliciesMicrosoftWindowsPowerShell
Hive : LocalMachine
PolicyState : Set
Value : RemoteSigned
Type : String
ValueName : ExecutionPolicy
HasValue : True

This quick technique enables you to find values within existing GPOs which could then either be cloned or assigned from scratch into a new GPO. That is the topic of the next article.

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.

Who’s NAPping on Your Network? – Network Access Protection (NAP)

object001

In a recent article, we described a high-level overview of 802.1x authentication. Now, let’s dive a bit deeper into the use of 802.1x as a foundation for Network Access Protection (NAP) enforcement of health policies in a Windows Server 2008 network infrastructure.

Recall that 802.1x can be used with Ethernet switches and Wireless Access Points (WAPs) which support that feature, with the purpose of authenticating the devices (e.g. servers, workstations, tablets, phones, etc.) which are connected to them. Generically, we could refer to Ethernet switches, wireless (i.e. 802.11) APs, VPN servers, and dial-in servers as Network Access Points (NAPs) or Network Access Servers (NASs), yet because Microsoft uses the term NAP for their access protection mechanism which we’ll discuss shortly, we’ll use the term NAS when referring to an Ethernet switch, WAP, VPN server, or dial-up host.

Whether the NAS supports 802.1x, or some other authentication scheme, it can be configured to relay such authentication using the RADIUS protocol. There are actually RADIUS authentication and accounting protocols. Thus each NAS could be configured as a RADIUS client, whereas a Windows Server running Microsoft’s Network Policy Services (NPS) performs the role of RADIUS server. Several NPS servers could be used for redundancy and load distribution. Additionally, in larger environments, NPS servers could optionally act as RADIUS proxy servers as a front-end from regional NAS points of presence to more centralized NPS RADIUS servers. Network Connection Policies can be checked on the NPS servers to determine if the end-station client devices ought to be allowed on the network via the NAS to which they are connecting. Thus, centralized policy-based access control of Ethernet, wireless, VPN, and dial-in clients is supported by proper integration of these elements. But that was somewhat supported in Windows 2000 Server, and as described above (with a couple of name changes) in Windows Server 2003.

Now we have a clear foundation that Network Access Protection (NAP) can build upon. Beyond mere authentication checks to determine whether to allow a client on the network, NAP’s advantage is its support of health policies. With respect to health policies, NAP offers an elaborate extensible framework which computer vendors such as HP or Dell, and security vendors such as Symantec or McAfee (Intel) could leverage to provide NAP system health agents (SHAs) and system health validators (SHVs). Included with NAP is one default Microsoft Security Health Validator (WSHV) which runs on the NPS on Windows Server 2008 or 2008 R2, and one default Microsoft Windows Security Health Agent (WSHA) that runs in NAP clients on systems such as Windows XP ≥SP2, Vista, and Windows 7. This built-in SHV/SHA pair can be configured to check if the clients’ firewall is enabled, antivirus is enabled, antivirus is up-to-date, antispyware is enable, antispyware is up-to-date, and if critical (or other level) of updates have been applied (i.e. from WSUS).

Microsoft also offers a System Center Configuration Manager SHA (SCCM SHA), and a ForeFront Client Security SHA (FCS SHA). Other vendors such as Avenda Systems, Computer Associates, McAfee, and Symantec offer their own extensions including SHA/SHV pairs which can extend NAP health checking capabilities beyond the built-in WSHA/WSHV pair. For example, the Avenda Windows Universal System Health Validator can scan for specific registry values that you configure. You can configure this validator to check for particular registry values that must be present, and if they are not, the Avenda Universal SHV will command the corresponding Universal SHA to create or update the proper registry values you have indicated. Additionally, this Universal SHV can confirm that another list of registry values are not present (i.e. must be absent), and request the Universal SHA to delete such keys from the offending client if they are present. In other words, third-party, Microsoft (second-party), and your own custom (first-party) extensions to NAP can check and offer remediation to enforce particular client configuration as a part of authorizing such client machines to be allowed on the network, or not.

One of the great benefits of the Windows Server 2008 R2 version of NAP beyond the first version in Windows Server 2008 is that multiple configurations of a SHV can be configured as a part of the health policies. While it’s minorly exciting that W2K8R2’s NAP supports having different update criticality requirements for hot fixes for different sets of machines with the WSHV, it can be majorly exciting if differentiated SHV configuration allows you to specify different sets of registry parameters or different sets of specific updates which must be a part of the compliance specification of sets of machines with unique security and compatibility requirements.

Who’s NAPping on Your Network? – 802.1x as a NAP Foundation

object001

How do you really know that the computers on your network are valid and legitimate? The flip-side of the coin asks how do those machines know that they’re connected to the proper network? Those are both good questions that we often look at in the course “Configuring and Troubleshooting Windows Server 2008 Network Infrastructure,” but have addressed in many other security courses as well over the past several years.

For many years, since the days of Windows XP and Windows Server 2003, Microsoft has included support for the network authentication mechanism 802.1x in recent versions of Windows. This built on the Remote Authentication Dial-In User Service (RADIUS) and Remote Access Policies which have been built in to Windows since Windows 2000 Server. Use of 802.1x in wired (e.g. Ethernet) and wireless (e.g. 802.11 WiFi) networks requires some prerequisites in your network infrastructure. With Windows Server 2003 Service Pack 1 (SP1), Microsoft added a virtual private networking (VPN) quarantine feature. Windows Server 2008 included a renaming and repackaging of many of these features, along with some more powerful enhancements built around this framework, namely Network Access Protection (NAP). Windows XP SP2 and later, Windows Vista, and Windows 7, as well as the server versions can be NAP clients. Windows Server 2008 R2 adds the ability to have a greater mix of distinctive NAP policies for checking system health without adding as many NAP servers into your infrastructure.

Security and networking can have a great synergistic relationship. Both are essential as lifeblood in today’s computer environments, like the white blood cells (security) and red blood cells (networking) help keep our bodies alive. The complexity of deploying 802.1x, or a more ambitious use of NAP depends on the size and diversity of your networks, however we can look at the building blocks in an elementary way. We will start with simple concepts and build up to the reality of such deployments.

Imagine that you have a user whose workstation is connected to your organization’s network via Ethernet. The workstation has an Ethernet interface, typically connected via appropriate cabling into a port on an Ethernet switch. This could be a legitimate workstation within your organization, or a rogue uninvited visitor. How can the Ethernet switch decide whether to allow this workstation on the network or not? This is where the use of classic point-to-point protocol (PPP) dial-up mechanisms meet local area networking (LAN) technologies, or in this case, Ethernet specifically. If the operating system on the workstation and the firmware in the Ethernet switch both support the industry standard 802.1x, the workstation can prove its identity or the identity of one of its users (i.e. authenticate) to the Ethernet switch by using what were originally PPP-based authentication protocols such as the extensible authentication protocol (EAP). Without getting into the details of EAP, let’s assume that the workstation proves its identity to the Ethernet switch, without getting into many of the details.

How does the Ethernet switch check and confirm the credentials, and decide to allow that workstation on the network? The Ethernet switch does not possess a local hard-disk-based nor FLASH-based database of computer accounts nor user accounts. Therefore the Ethernet switch asks another machine on the network if this computer should be allowed on the network. Rather than have the Ethernet switch speak either the Kerberos authentication protocol or the Lightweight Directory Access Protocol (LDAP), the switch uses another industry standard called RADIUS which originated in dial-up networks around 1991, and was first submitted for standardization circa 1992. Microsoft started using providing a RADIUS server implementation as their Internet Authentication Service (IAS) in Windows 2000 Server. This service was still called IAS in Windows Server 2003, and repackaged into the Network Policy Service (NPS) in Windows Server 2008 (and 2008 R2).

Imagine that you have implemented a NPS server in your environment. You could configure the Ethernet switch as a RADIUS client to speak to the NPS server. But the problem of authenticating the workstation is usually deferred again, as the NPS server may not have user accounts locally resident. Instead, the NPS (RADIUS) server translates or at least reencapsulates the authentication request to an Active Directory Domain Services (AD DS) domain controller. Hopefully the domain controllers have a valid computer account for the workstation in question.

In summary, the 802.1x authentication functions like a game of hot potato. The workstation authenticates using EAP over Ethernet as a part of the 802.1x scheme. The Ethernet switch conveys this authentication request over the RADIUS protocol to the NPS server, and the NPS server requests confirmation from AD DS that there is a valid computer account that is allowed to connect to the network. Policies on the NPS server can also allow or limit the ability for a machine to connect, and this is the foundation for the bigger NAP service with 802.1x enforcement. If the domain controller suggests to accept the workstations connection, and the NPS server agrees, then the Ethernet switch will receive confirmation and if successful, allow this workstation on the network, perhaps with packet filters, virtual LAN assignment, and the upper-layer address negotiation such as via DHCP.

NAP can use several different enforcement techniques, including 802.1x as one of the options. We shall revisit this topic with a focus on NAP itself shortly.

DirectAccess – a VPN but not a VPN (“to VPN or not to VPN”)

Windows NT 4.0 included an implementation of the Point to Point Tunneling Protocol (PPTP) for both the NT4 Workstation and NT4 Server products, with a client for Windows 95 OSR2, and PPTP is still supported in Windows and other operating systems. Virtual Private Networking (VPN) technologies have evolved since then. In fact, could they have perhaps evolved so much that they don’t exist any more?

While 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 VPN technology, these operating systems still support 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, and how can it be useful as an alternative to those older VPN technology choices?

Why does Microsoft claim that DirectAccess is not a VPN technology? To understand this, let us first look at what some of the other VPN technologies are, then the similarities and differences between these and DirectAccess, and the distinction should become clear.

Many hardware and software vendors offer VPN implementations, yet from a Microsoft perspective, the PPTP, L2TP, and SSTP VPN solutions in Microsoft Windows are coupled with Routing and Remote Access Services (RRAS) on the server side, and dial-up networking (DUN) on the client side. The way most people use these VPN technologies in Windows, the end-user on the client machine either explicitly “dials” into the VPN server after they have logged on, or perhaps as a part of the logon process. The first real distinction between these technologies and DirectAccess is that this supposedly non-VPN 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.

The ramifications of this, and if we merely focus on the benefits of this for a moment, are significant with respect to applying Active Directory Domain Services (AD DS) based Group Policies to such client machines, applying updates via Windows Update Automatic Updates (WUAU) and Windows Server Update Services (WSUS), and ability to perform other forms of remote administration of these client systems at any time. We do not have to wait for a user to log on and dial into the VPN in order to have centralized management ability and control over the constituent systems. To Microsoft, perhaps this is construed as a key distinction which casts DirectAccess as a non-VPN technology, however from my humble perspective, as it has always been possible to have a startup script dial into a VPN connection using particular user credentials, I’m not 100% clear why they would consider that a distinction other than a variation from the average end-user expectation of how VPNs are typically used. To me it doesn’t make DirectAccess a non-VPN technology, but that’s just my opinion.

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.

Although, like with many new technologies, there are requirements specific to DirectAccess that are not needed for other VPN technologies, establishing a DirectAccess Server based on Windows Server 2008 R2, the necessary infrastructure, and as many DirectAccess clients as you need, running Windows 7 Ultimate or Enterprise, is a fairly straightforward endeavor. The benefits are many for this always on VPN technology, primarily the ability to support always manageable systems in remote offices, home offices, and in mobile Windows 7 machines the field. DirectAccess allows private, controlled access, over tunneled virtual network interfaces of Windows 7 machines which need to be connected into their main office whenever they have public Internet access available. To VPN or not VPN, is not really a relevant question anymore. What’s in a name? Beside the fact that you might be used to dialing up your VPN connection after you log on, whereas DirectAccess is always on, does it really matter whether you call it a VPN technology or not?

SharePoint 2010 Cmdlets for Administration

As I mentioned in a previous article, SharePoint Server 2010 comes with 531 sharepoint-specific PowerShell cmdlets — little commands for sharepoint management — built in to the SharePoint 2010 Management Shell. Now, let’s take a quick survey of some of these cmdlets as well as some tips on how you can get up-to-speed with managing SharePoint with PowerShell.

Like all PowerShell cmdlets, these little SharePoint specific management tools are named with a verb-hypen-noun style. With these 531 cmdlets, there are 197 unique nouns, or different aspects of SharePoint that can be managed, and 38 unique verbs, or ways in which these parts of SharePoint may be administered. Certainly, it is not necessary to learn or memorize all of these cmdlets, but recommended that you focus on the areas of SharePoint you need to manage. Cmdlets such as Publish-SPServiceApplication and Ping-SPEnterpriseSearchContentService are some of the more esoteric.

If you start with just four verbs—get, set, new, and remove—you have 405 of the 531 cmdlets covered, and can focus on which aspects of SharePoint (nouns) you need to manage. Obviously, the remaining 126 cmdlets are used for something, but if they’re not applicable to your daily management needs, you could likely save learning about them until later.

As an example of learning related cmdlets, SharePoint’s dependence on SQL databases services as a good starting point. The generic noun to refer to these is SPDatabase, as used in the Get-SPDatabase cmdlet, while the other nouns are specific to a particular kind of SharePoint database, namely: SPConfigurationDatabase, SPContentDatabase, SPEnterpriseSearchCrawlDatabase, SPEnterpriseSearchPropertyDatabase, SPSingleSignOnDatabase, and SPStateServiceDatabase. Not all verbs work with all of these different types of databases (nouns). Although the most common verbs are Get, Set, New, and Remove, there is no Get nor Set cmdlet for either SPConfigurationDatabase or SPSingleSignOnDatabase.

In fact, while SPConfigurationDatabase has New and Remove cmdlets, yet no Set and Get, it also has Connect, Disconnect, and Backup cmdlets. Each kind if SharePoint database, like many other managed objects, has particular operations which make logical sense to meet their unique characteristics and management needs. The specific characteristics of the SPConfigurationDatabase and its cmdlets relate to the association of a SharePoint configuration database with a farm. The Connect-SPConfigurationDatabase cmdlet associates the current server with the specified configuration database, and therefore the farm. To move a server from one farm to another, first use the Disconnect-SPConfigurationDatabase to dissociate the server from its current farm, then use Connect-SPConfigurationDatbase cmdlet to associate the server with its new farm.

For example, to move the current server from the FINANCE farm to the MARKETING farm, use the following:

Disconnect-SPConfigurationDatabase
Connect-SPConfigurationDatabase -DatabaseServer clarityPRIMARYSERVER `
-DatabaseName SharePoint_Config

Another cmdlet associated with SPConfigurationDatabase is Backup-SPConfigurationDatabase, which backs up the specified configuration database, essentially backing up the farm configuration associated with that configuration database. A shared folder is specified as the backup destination. The content databases would be backed up independently, for example using the Backup-SPFarm cmdlet.

The configuration database for a farm is a tangible aspect of the management of a SharePoint deployment, yet its relationship to the SharePoint servers within a farm is not often reconfigured on a daily basis, yet when you add or remove servers to the farm. We’ve chosen this fairly static aspect of a SharePoint Server 2010 deployment as a starting point for further discussion. The SharePoint 2010 Management Shell can provide a wealth of opportunities for day-to-day administration automation, as perhaps we’ll address in future articles.

SharePoint 2010 Management Shell

Web-based administration via a web browser enables secure, remote, flexible administration of many services. SharePoint Server 2010, unlike many other Microsoft products is not managed with a Microsoft Management Console (MMC) snap-in, but with such a web interface.

It might seem that this management motif has it all. A farm of servers may be managed from a phone, tablet, or regular computer via a web browser from virtually anywhere in the world. When you upgrade your servers, the web management component(s) are upgraded at each managed server without a need to change anything on the management (browser) side.

Why would you want any other kind of management interface? Seriously. Think about it. Click, tap, or touch your way through the interface, and when necessary, type a few names or values in a dialog before hitting the (web-based) “make it so” (OK) button. What could be more efficient? Well, telepathy maybe, but we’ll work on that and maybe discuss it sometime in the future. For now, the web-based Graphical User Interface (GUI) is still state of the art, thirteen years after webmin’s initial release.

But there is another way. Yes, that’s right, Windows PowerShell. Are you thinking “doesn’t that involve a lot of typing?” Are you worried that it’s hard to learn? Maybe. But you can effectively manage parts of SharePoint via PowerShell without knowing all of the possible management tools.

SharePoint Server 2010 comes with 531 sharepoint-specific cmdlets — little commands for sharepoint management. But that’s not all. When it is necessary to dive under the hood and check or adjust something in the Internet Information Services (IIS) underpinnings or other Windows Server configuration, including networking or Active Directory Domain Services (AD DS), hundreds more PowerShell cmdlets and functions await your beck and call.

But why? Why would you choose to use PowerShell when you already have the web administration interface? Automation. Reproducibility. Engineering. The same reasons we typically use PowerShell for many tasks. Let’s go back to an earlier concern you might have had: do you have to be a touch-typist to be allowed entry into the “PowerShell club?” No. Being a decent typist doesn’t hurt with PowerShell. Typing is required sometimes, as with the GUI, but in some cases, just once. There are several aspects of the SharePoint Management Shell that can be used to make administration easier. A few of these are remote administration, pipelines, scriptability, and good old fashioned copy-and–paste (or select-and-execute really).

PowerShell Logon Scripts Revisited

Just about a year ago, I posted an article here about using Windows PowerShell for logon scripts. <http://microsoftblog.globalknowledge.com/2009/09/14/power-to-the-people-windows-powershell-logon-scripts/>

As noted in that post, to start you off, I presented a “Basic” example (and I’m not referring to VisualBasic script here) in quoting a Microsoft example. Also in that post were several other tips such as “the scripts must be accessible at a path visible to the client” and (although I could have been more clear in my choice of words by adding “if”) “unqualified, therefore in the local folder – that PowerShell script will run at the same location as the VBscript.” In other words, I intentionally drew the dots yet didn’t connect them for you. But now I think it’s time that I spell it out and be more clear. Here’s a recent request from someone regarding last years post:

“Unfortunately, that sample is as useless as every time people quote it. It seems to be the standard accepted non-functional answer. The problem: c:scriptslogon.ps1
[…] The location of the logon script is never a mapped drive. It’s something like: %userdomain%sysvoldomain.comPolicies{AAD5280F-A3B7-4F65-B15B-27E6F92BA431}UserScriptsLogon.
So, the .vbs script mentioned is not going to know where it is and presumably the .ps1 script will be in the same location. Now please, it would be great if you could show us how one could actually run a logon script using powershell.” (ellipsis mine)

Indeed, I think that’s a great idea. Thanks for asking. Let’s start with one slight modification of that earlier example, and then go with the even more beautifully straightforward answer to the question without any fancy explicit paths.

Let’s treat the following as a proof of concept on which we’ll improve once you have it working in a test environment. Success with simple examples is often good prior to getting into realistic solutions. I hope this helps. If you have assigned the following VBscript as a logon script via Group Policy, it will reveal several things.

’ logon.vbs – brief example
set objShell = CreateObject( “Wscript.Shell” )
objShell.run( “powershell.exe -noexit c:scriptslogon.ps1” )

Before getting into what running that can reveal, let us consider a change from my earlier post. Assume that the contents of this c:scriptslogon.ps1 is as follows:

“Hello, world!”
“Thus is redirected at $(get-date)” >logon.$($(get-date).ticks).txt

What do you get when you run it? Two things. First, due to the -noexit parameter used when logon.vbs launches logon.ps1, the shell window stays open and reveals the current path to be that of the folder with the logon.vbs script. In other words, this is typically a UNC file sharing path into the GPO’s UserScriptsLogon folder. For example, for a certain GPO in the domain sp.wernerconsulting.com the path is:

sp.wernerconsulting.comSysVolsp.wernerconsulting.comPolicies{C7872F8D-79E0-4770-BCC4-8A4B6E1A6C33}UserScriptsLogon

Secondly, even though the logon.ps1 ran from the c:scripts folder, its current location is also in the GPO’s UserScriptsLogon folder. For example, the file created when the script runs is stored in that folder (if you have permissions to it).

So why does that basic example use the local path c:scriptslogon.ps1? Signing. If the PowerShell execution policy is set to RemoteSigned, the script will not run from the remote UNC path, even if you are testing this locally on a domain controller. For instance, if we changed logon.vbs to simply use either a relative path .locallogon.ps1 or implicitly local path locallogon.ps1 as follows, we would get a PSSecurityException “cannot be loaded … is not digitally signed. The script will not execute on the system.”

’ logon.vbs – same path example
set objShell = CreateObject( “Wscript.Shell” )
objShell.run( “powershell.exe -noexit locallogon.ps1” )

So we see in reality the .vbs script does intrinsically know where it is running and can easily launch a PowerShell script residing in the same location. Again, my older post included suggestions regarding not using -noexit yet including other parameters. But which remedy would you choose for the execution policy issue? We have several choices.

Option 1. Code sign the script file(s) used as logon scripts and use the “same path example” shown above for the .vbs glue. Alternately, another UNC path could be used beside that of the GPO’s subfolder, however the code signing would still be necessary.

Option 2. Adjust the execution policy. This approach also requires adjustment of the options used to run the script.

Option 3. Adjust the trusted locations relative to the code signing and execution policy.

Option 4. Use a local path for the script file repository and use the “basic example” referenced earlier as the .vbs glue. Note that Group Policy Preferences may be used to create the local script repository and populate it. Alternately, the script repository could be deployed using Group Policy software deployment. Note that in this is a local path rather than a mapped drive.

There are several other options, as well as permutations, details, rationale, ramifications, and possibilities for PowerShell logon script execution. I hope this helps. Please let me know of any further questions.