Appendix E – Tips for Scripting

Scripting provides a powerful tool for constructing customized solutions. Learning scripting syntax can be challenging, though, so this section is designed to provide some additional information to help explain specific syntax for the scripts used in this document.

• See Netsh Commands for Windows Firewall with Advanced Security for a full description of using Netsh.exe with ADVFIREWALL commands.

• See Netsh Commands for Interface (IPv4 and IPv6) for a list of commands in the netsh interface ipv6 context.

DirectAccess user interface scripting

Script design

DirectAccess UI scripting allows an administrator to use PowerShell scripts to execute a combination of Netsh and PowerShell commands to configure a DirectAccess server.

The DirectAccess Management Console generates an Extensible Markup Language (XML) data file that can be passed as an input to the engine.ps1 PowerShell script. The location for the data file is %WINDIR%\DirectAccess\DirectAccessConfig.xml. This XML data file is generated whenever user saves or applies setup settings inside the DirectAccess Management Console. For more information, see Perform DirectAccess Scripting.

By accessing the tag names inside the XML file, the administrator can both configure the DirectAccess server and all of the required Group Policies.

Here is an example of a data file:

<root>

  <ServerData>

        <CorpPrefix>2002:1111::/48</CorpPrefix>

        .

        .

  </ServerData>

   .

   .

</root>

CorpPrefix can be accessed by a script using the format $xmldata.root.ServerData.CorpPrefix.

Three helper functions provide the ability to:

• Expand variables

• Construct commands

• Execute commands and log output

These are extensible, so more commands can be added as needed. The functions are:

• Executing PowerShell commands:

  pscmdexec(string command, string description)

• Executing Netsh commands:

  netshcmdexec(string command, string description)

• Executing ipsec/firewall related netsh commands:

  netshipseccmdexec(string setstorecommand, string ipseccommand, string description)

Script usage

The script takes in as arguments the data file path and the log file path along with the mandatory mode parameter.

Engine.ps1 –mode <serveronly|gpsettingonly|all> [–data <dataFilePath>] [-log <logFilePath>]

The first option <serveronly|gpsettingonly|all> is:

• Serveronly: This configures only the DirectAccess server. Required settings and policies are not created for Group Policy.

• GPSettingOnly: This creates and configures Group Policy. It does not configure the DirectAccess server.

• All: This configures both the DirectAccess server and the Group Policies. This mode is equivalent to using Apply from the DirectAccess Management Console.

The data and log options are optional; if they are not present, the script will look in the default location and generate the log in the current directory with the default name.

Log file

A log file named DirectAccessLog.txt is generated when the script is run, which contains details of what actions the script performed with timestamps. The log file contents have the following format:

<Time Stamp> Step: <description>

Executing: <the command getting executed>

Output: <output of the command>

Limitation of the scripts

ISATAP registration on the DNS must be done manually in case IPv6 is not deployed on the intranet and Dnscmd.exe is not present on the computer where script is run. There are two ways to solve this:

1. Install Dnscmd.exe using Remote Server and Tools. Scripts will work fine after this step.

2. Add a new A record in DNS server for isatap with the DirectAccess server intranet IPv4 address. This address can be picked up from XML file at <root>-<ServerData>-<TransitionTechnologies>-<ISATAP>-<CorpV4Address>.

Scripting IPsec rules

IPsec rules can be difficult to read and write simply because of the amount of information that must be included in them. Once you understand the basics, though, they become easier to work with. Here is an example:

netsh advfirewall consec add rule name="CorpNet IPv6 Tunnel-Srv" mode=tunnel Endpoint1=2001:4898::/32 Endpoint2=Any LocalTunnelEndpoint=2001:1111::1111 RemoteTunnelEndpoint=Any Action=RequireInRequireOut Auth1=ComputerCert Auth1CA="O=Microsoft Corporation, CN=Microsoft Corporate Root CA" Auth2=UserKerb,UserNTLM

This command is constructing a new Windows Firewall Connection Security rule named “CorpNet IPv6 Tunnel-Srv” using IPsec tunnel mode. This rule would be applied to a Windows Server 2008 R2 gateway and is designed to secure the traffic from the external IP address of the specified gateway that is destined for any external IP addresses (in the DirectAccess scenario this tunnel would be for management traffic from the intranet destined for the external client IP addresses).

Endpoint1 specifies the “Internal Source subnets”, which in this case is an intranet IPv6 address space – 2001:4898::/32. Endpoint2 specifies the “Destination Address”, which in this case is “Any.” The “Any” is a wildcard signifying the remote Client IP addresses, since we don’t know what IP address the client will be using. Finally, we have our LocalTunnelEndpoint, which means “where the IPsec tunnel will originate”, and in this case it is the external IPv6 address of the IPsec Gateway, 2001:1111::1111.

To summarize this first part, we have specified that a tunnel will be created whenever an intranet computer in the 2001:4898::/32 subnet attempts to initiate a connection to an external client by routing through the gateway’s external 2001:1111::1111 interface.

Additionally, for each of those RemoteTunnelEndpoints, we will RequireIn(bound) and RequireOut(bound) authentication, and the authentication we require is a ComputerCert(ificate) issued by the Microsoft Corporate Root CA, plus we will require Kerberos authentication.