Friday, 29 November 2013

How to Install and Configure KB2862152 for a DirectAccess Scenario

Microsoft recently released a security advisory titled Vulnerability in DirectAccess could allow security feature bypass which can be found here. As part of the associated security update KB2862152 which can be found here, a DirectAccess client enforces more checks in IPsec negotiation when using either certificate-based or Kerberos Proxy authentication methods. During IPsec negotiation, the DirectAccess client now checks specific attributes against a set of registry-configured values. Consequently, it is important to realise that the security update is a client-side fix that strengthens how the identity of a DirectAccess server is validated, and aims to prevent a spoof, or rogue attacker-controlled system, from posing as a legitimate DirectAccess server.

Although the information provided in the KB article is very detailed, it has raised some questions from customers that I wanted to try clarify and explain in this blog post. I have written the blog post in FAQ style to try and provide a suitable reference guide for each consideration.

Please Note: Although the advisory references DirectAccess specifically in the title, and this blog post is focused on a DirectAccess deployment, the advisory also applies to other IPsec-related scenarios like client-to-site and site-to-site VPN deployments. Therefore, these scenarios will need to be considered slightly differently, and adapted as appropriate per the KB article.

 

On which computers do I need to deploy the update?

The key thing to realise is that the security update is a client-side fix and for the DirectAccess scenario, only needs to be deployed to DirectAccess client computers. This is likely to cause some confusion as the article talks about Window Server operating systems, but as DirectAccess is client-to-gateway configuration, the update only actually needs to be installed on the DirectAccess client computers. However, given that a Windows Server can also act as a DirectAccess client, the KB article includes references to Windows Server operating systems. This is not a common deployment model in my experience, but I have seen this configuration used for servers located in branch offices in order to communicate with a central data centre resource. So, in summary, the security update needs to be installed on the DirectAccess client computers which will [commonly] be Windows clients, but could also [less commonly] be Windows servers.

If you are using DirectAccess in Basic Remote Access mode using the Getting Started Wizard (also known as KerbProxy mode) you will need to:

You will need to deploy the update on all DirectAccess clients running Windows 8/8.1 and you DO NOT need to install the update on the DirectAccess servers. Once installed, you will then need to make the registry changes discussed in the upcoming section. KerbProxy mode only supports Windows 8/Windows Server 2012 and later operating system versions, so this deployment mode will not need to consider Windows 7 clients.

Please Note: If you are using Windows Server 2012 or 2012 R2 servers running as DirectAccess clients, then they will also require the security update to be installed. 

 

If you are using DirectAccess in Advanced Remote Access mode (also known as certificate-based mode) you will need to:

You will need to deploy the update on all DirectAccess clients running Windows 7 and you DO NOT need to install the update on Windows 8/8.1 DirectAccess client computers or DirectAccess servers. Once installed, you will then need to make the registry changes discussed in the upcoming section.

Please Note: If you are using Windows Server 2008 or 2008 R2 servers running as DirectAccess clients, then they will also require the security update to be installed. 

 

On which computers do I need to make the registry changes?

You will need to make the registry changes on all DirectAccess client computers where the update has been installed. By default, the update remains disabled after installation until specific registry changes are made on the client computer in order to manually enable the update. This will ensure that DirectAccess client computers include the new validation rules. As soon as these rules are set in the registry, the update will automatically start enforcing the new rules when it establishes a tunnel with the remote DirectAccess server. Any errors in the registry configuration will cause the IPsec tunnels connections to fail and consequently break DirectAccess connectivity from the client computer.

 

What registry changes do I need to make?

The registry changes are specific to the DirectAccess client computers operating systems as follows:

For DirectAccess client computers running Windows 7, Windows Server 2008 or Windows Server 2008 R2, you will need to edit the registry configuration to include an IP parameter combined with either a DNS parameter, or an EKU parameter. The following rules are then applied:

  • If only IP and EKU parameters are configured, the DirectAccess client checks that the DirectAccess server IPsec certificate for a matching EKU object identifier (also known as OID).
  • If only IP and DNS parameters are configured, the DirectAccess client checks that the DirectAccess servers IPsec certificate for a matching Common Name (CN) or Subject Alternate Name (SAN).
  • If IP, DNS, and EKU parameters are configured, the DirectAccess client only checks the DirectAccess server IPsec certificate for a matching EKU object identifier. If the DNS parameter is also defined, it is ignored.

For DirectAccess client computers running Windows 8, Windows Server 2012 or Windows Server 2012 R2, you will need to edit the registry configuration to include an IP parameter combined with a Service Principal Name (SPN) parameter. The following rules are then applied:

  • When the IP and SPN parameters are configured, the DirectAccess client checks that the DirectAccess server is using a matching SPN value.

For a DirectAccess scenario, note the following:

  • The <ipaddrv4/ipaddrv6> parameter should reference the Dynamic Tunnel Endpoints (DTEs) of the IPsec tunnels that enable DirectAccess. DTEs represent a collection of IPv6 addresses that each identify a DirectAccess server. In a certificate-based deployment of DirectAccess, there are typically two DTEs, one for the infrastructure tunnel, and one for the intranet tunnel. If using multiple DirectAccess servers, the DTEs will represent virtual IP addresses (VIPs) which are typically used with Windows Network Load Balancing (NLB) or hardware/external load balancer network topologies. An example DTE parameter might be: 2002:836b:1:: 836b:1
  • The <DNS> parameter should reference the DirectAccess server internal fully qualified domain name (FQDN) and the CN/SAN defined in the the DirectAccess server IPsec certificate. If using multiple DirectAccess servers, it is necessary to add each server FQDN to the registry key as denoted by the <DNS1> and <DNS2> references in the KB article. An example DNS parameter might be: daserver.corp.contoso.com
  • The <SPN> parameter should reference the DirectAccess server SPN which will typically be defined as host/FQDN. If using multiple DirectAccess servers, it is necessary to add each server SPN to the registry key as denoted by the <SPN1> and <SPN2> references in the KB article. An example SPN might be: host/daserver.corp.contoso.com

In order to determine the DTE parameters for a Windows Server 2012 DirectAccess deployment, you can use the following PowerShell command:

Get-Item –Path “HKLM:\\SYSTEM\CurrentControlSet\Services\RaMgmtSvc\Config\Parameters”

and look for the DTE1 and DTE2 references in the results. These are the DTE values (IPv6 addresses) that will need to be used in the registry keys. For the DirectAccess scenario, it is only necessary to define the IPv6 addresses in the registry keys as DirectAccess is a pure IPv6 technology when considering the IPsec configuration (connection security rules). Consequently, IPv4 addresses are not relevant for this scenario.

The DNS and SPN parameters should be quite easy to determine based upon the computer name and FQDN of the DirectAccess server(s). The IPsec certificate should also be checked to ensure the DNS name of the certificate will match that defined on the DirectAccess client computer registry entries.

 

Do I need to do anything else?

The security update has a dependency on the DirectAccess server certificate in order to meet the new client-side validation rules. Therefore, if you have used an IPsec certificate on the DirectAccess server that DOES NOT contain an Enhanced Key Usage (EKU) field/property, then you will need to replace the certificate with one that does, before making the registry changes on DirectAccess client computers. The DirectAccess server hosting this certificate can be running Windows Server 2008 R2, 2012, or 2012 R2. In general, if you are using a Microsoft CA and follow the guidance of creating a certificate template that has been duplicated from the default Computer certificate template in order to issue a suitable certificate, then the IPsec certificate should contain the correct EKU values to meet the client-side validation process. More information on these aspects can be found here and here.

 

How do I know if the registry changes have worked?

If after making the registry changes, you can still connect to corporate resources from a DirectAccess client that is located outside your internal network then you should be good to go. This can be confirmed several ways; by looking at the DirectAccess connection status of ‘Corporate Connectivity is Available’ in DCA (Windows 7), a ‘Connected’ state in NCA (Windows 8) or from looking at the client connections view in the Remote Access management console. If you can no longer connect, then something went wrong with the registry changes, or the IPsec server certificate is not configured correctly to match the registry values. The troubleshooting section provided in the KB article can be used to look for errors in IPsec logging information and also the general guidance provided here.

 

Can I see a working example?

So, the best way to understand the configuration is to see how it would be applied to a real-world scenario. So, let’s assume we have the following DirectAccess deployment:

 

 

image

 

This deployment is using the more common Advanced Remote Access model (certificate-based) with the DTE, DNS and EKU values as shown in the diagram. Note that the DNS parameter is NOT the IP-HTTPS FQDN, it is the internal FQDN of the DirectAccess server computer object within Active Directory. The EKU used in this example is the standard EKU OID for Server Authentication (1.3.6.1.5.5.7.3.1) but could in theory be a custom OID that is defined in the DirectAccess IPsec certificate.

This DirectAccess deployment would result in the following registry changes on the DirectAccess client computers:

For DNS approach:

Registry key: HKLM\SYSTEM\CurrentControlSet\Services\IKEEXT\Parameters\IPsecTunnelConfig\AuthIP\Cert
Registry name: Infrastructure
Type: REG_MULTI_SZ
Data: 2002:836b:1::836b:1 daserver.corp.contoso.com

Registry key: HKLM\SYSTEM\CurrentControlSet\Services\IKEEXT\Parameters\IPsecTunnelConfig\AuthIP\Cert
Registry name: Intranet
Type: REG_MULTI_SZ
Data: 2002:836b:2::836b:2 daserver.corp.contoso.com

For EKU approach:

Registry key: HKLM\SYSTEM\CurrentControlSet\Services\IKEEXT\Parameters\IPsecTunnelConfig\AuthIP\Cert
Registry name: Infrastructure
Type: REG_MULTI_SZ
Data: 2002:836b:1::836b:1 EKU:1.3.6.1.5.5.7.3.1

Registry key: HKLM\SYSTEM\CurrentControlSet\Services\IKEEXT\Parameters\IPsecTunnelConfig\AuthIP\Cert
Registry name: Intranet
Type: REG_MULTI_SZ
Data: 2002:836b:2::836b:2 EKU:1.3.6.1.5.5.7.3.1

Please Note: The data separators can be "space" or "tab" or a "new line" but I would personally use a new line for each entry.

Graphically these registry changes can be seen as shown below.

For the DNS approach:

image

For the EKU approach:

image

A similar approach can be used for Basic Remote Access mode deployments (KerbProxy) by simply using the SPN parameter instead of the DNS parameter in the above example. As a Basic Remote Access deployment only uses a single IPsec tunnel, it will only be necessary to define a single registry key value and the registry subkey will defined as Kerberos and not Cert e.g. HKLM\SYSTEM\CurrentControlSet\Services\IKEEXT\Parameters\IPsecTunnelConfig\AuthIP\Kerberos

I hope the above information clarifies and compliments the original KB article and provides some exemplar guidance on configuration of the registry keys based upon an actual working scenario.

Props: Thanks to Ioan Corcodel and Nithin Jose (Microsoft guys) for their assistance with providing a lot of the above information.

Wednesday, 13 November 2013

The Evolution of Collecting DirectAccess Client Diagnostic Log Information

A common administrator question when learning to troubleshoot DirectAccess client connectivity problems is:

“How can you create a client-side diagnostic log which provides specific detail about the DirectAccess configuration, connectivity state and other relevant system information which can be used to isolate the exact problem/issue?” 

Depending on how far along the Windows evolutionary journey you are, the user experience in order to initiate the log capture process is different for specific versions of Windows. In my experience, customers often have a mixed Windows estate and therefore need to be aware of how to collect these diagnostic logs for Windows 7, Windows 8 and potentially even Windows 8.1 DirectAccess clients. Given this need, the following sections define the steps involved to collect/gather the logs for each respective version and associated considerations to be aware of.

 

Windows 7 and the DirectAccess Connectivity Assistant

First introduced as part of the Solution Accelerators series, the DirectAccess Connectivity Assistant (DCA) soon became a common component that was an essential part of any DirectAccess deployment. One of the key benefits of DCA to the administrator was that it would allow the user to create a diagnostic log, with minimal effort, which would collect relevant data and system information. This could then be sent to the administrator for offline review, or used during interactive troubleshooting assistance.

Instructions: Right-click the DCA icon in the System Tray and then select the Advanced Diagnostics option.

 

image

 

Note: If the Advanced Diagnostics option is not available, it may have been disabled by the administrator, or a support/helpdesk email address has not been defined.

Log files will be generated automatically and saved to the following location: %SystemDrive%\Users\%Username%\AppData\Local\Microsoft\DCA\

 

Windows 8 and the DirectAccess Properties Window

With the advent of Windows 8, the DCA was no longer needed as the operating system had been specifically designed to incorporate DirectAccess connectivity status and other key networking information within the View Available Networks (VAN) user interface. This negates the need to install a separate component and provides a consistent user interface where DirectAccess connectivity status can be viewed alongside all other network-related connectivity information. This was a welcome change.

Instructions: Left-click the Network icon in the System Tray to show the View Available Networks (VAN) window. Right-click the DirectAccess network entry from the list of available networks and select the View connection properties option. From the DirectAccess Properties window, click the Collect Logs button.

 

image

 

image

 

Note: If the Collect Logs button is greyed out or not available, it may have been disabled by the administrator, or a support/helpdesk email address has not been defined.

Log files will be saved to the following location: %SystemDrive%\Users\%Username%\AppData\Local\Temp\Microsoft DirectAccess Logs\

 

Windows 8.1 and the DirectAccess Modern UI

With the increased need to provide a touch-friendly interface and adhering to Modern UI design specifications, the user experience of DirectAccess connectivity status provided in Windows 8.1 has been moved to the Networks Modern UI page. This avoids unnecessary switching to desktop and maintains uniformity with the rest of the networking connections like VPN, Wi-Fi etc. The existing DirectAccess Properties windows used in Windows 8 also required the user to switch to the desktop, which could be confusing when using Modern UI applications.

Instructions: Place the mouse pointer into the bottom-right corner of the desktop, select the Settings charm and then select the Change PC settings option. From the list of available PC Settings choose the Network option and then select the DirectAccess icon from the right-hand pane of the Connections window. Finally, click the Collect button under the Logs section.

 

image

 

image

 

image

 

image

 

Note: If the Collect button is greyed out or not available, it may have been disabled by the administrator, or a support/helpdesk email address has not been defined.

Once the logs have been collected, a new email message window titled DirectAccess logs from %COMPUTERNAME%\\%DOMAIN%\%Username% - %Date% should appear. This will be rendered based upon the default email application that is defined on the Windows 8.1 DirectAccess client, and is shown below for Outlook 2013.

 

image

 

The log collection process in Windows 8.1 requires that an email program has been installed and/or a default email association has been defined, otherwise you will receive the error shown below. If the log collection process appears to be taking a long time (spinning circle) it may be necessary to switch to the desktop to actually see any errors related to the log collection process.

 

image

 

An email program and/or email association is required as the collected logs files are attached directly into a new email message window. Log files will not be saved to an obvious file location and will need to be either emailed to an administrator by clicking Send, or copied directly from the new email message window to an appropriate file location of choice. However, a copy of the collected log file can also be found in the following location: %SystemDrive%\Users\%Username%\AppData\Local\Temp with a default filename of %COMPUTERNAME%-%Date% %Time%-DirectAccess Logs.html

Tip: An alternate (easiest) way to access the DirectAccess Options screen in Windows 8.1 is to use the Search charm, typing direct into the search field and then selecting the Change DirectAccess settings option from the displayed search results.

 

image

 

So, there we have it; three different versions of Windows, three different ways to collect DirectAccess diagnostic log information. Happy log collecting DirectAccess troubleshooters!

Tuesday, 2 April 2013

Useful Guide: Troubleshooting DirectAccess Manage Out Connections

I’ve discussed the concept of ‘Manage Out’ for Forefront UAG DirectAccess and also more recently for Windows Server 2012 DirectAccess; both of which can be a cause of pain when implementing and supporting a DirectAccess solution using either platform. One of my MCS colleagues in NYC, Colin Brown has written an excellent troubleshooting guide which provides a shining beacon of light in the darkness of ‘Where do I even start??!!’

Enjoy and great work Colin, I wish I had written it! :)

You can find the guide hosted on Tom’s ‘Building Clouds’ blog here: Troubleshooting DirectAccess Manage Out Connections

Monday, 18 March 2013

Windows Server 2012 DirectAccess Manage Out using Native IPv6


Please Note: The approach provided within this blog post is not suitable when using an External Load Balancer (ELB), Single NIC topology or a multisite DirectAccess topology and you will need to use a more traditional native IPv6 deployment where you define your own IPv6 prefixes which are entered as part of the DirectAccess wizard configuration process.
I wrote a previous blog article titled Limiting ISATAP Services to UAG DirectAccess Manage Out Clients some time ago now which proved to be quite popular as a way to allow manage-out functionality for UAG DirectAccess solutions without effecting the entire network through the use of wide spread ISATAP enablement. That article originated as many people weren't aware that in order to manage DA clients from an intranet machine, it needed to be IPv6 capable (read native IPv6 or using a transition technology like ISATAP). Given the use of ISATAP you needed to be a little careful with how best to enable it for a subset of management clients, otherwise there was potential to impact the entire internal network and bad stuff can happen.
Given the advent of Windows Sever 2012 DirectAccess and the new Unified Remote Access role, Microsoft no longer recommends the use of ISATAP to facilitate manage out scenarios in favour of using native IPv6. This statement is discussed here and appears to be the general MS recommendation given the potential problems associated with ISATAP deployments that can, and often do, go wrong. The likely first reaction to that news is likely to be “…but I don’t understand IPv6 and our intranet doesn’t have it enabled or configured yet, so how do I do that?” or “…why can’t I just stick with ISATAP? It seems easier”. Both of these reactions are understandable, but I wanted to provide an example to show that it isn’t actually that scary and it is potentially even easier to implement than the old ISATAP method, especially for a small number of management clients. Nobody is saying that you can’t use ISATAP; in fact the ISATAP router functionality is still enabled by default on the DA server when using an IPv4 address on the internal network adapter. Although the DA Server is configured as an ISATAP router by default, it should be noted that it will not service clients until the necessary ISATAP DNS A record has been created and the entry removed from the DNS global query blocklist. However, maybe it is time to start thinking about that historic ‘ISATAP or native IPv6’ decision process and the primary reason that I am writing this blog post :)
Please Note: The obvious caveat, or limitation, here is that the communication path (read network infrastructure) between the management client and the DA server will need to support (be able to forward) native IPv6 traffic. This is likely to be very environment specific and may need to be tested, or involve discussions with your network guys to understand if this is a viable option. For example, an IPv4-only back firewall is a good example of something that may prevent the use of native IPv6 for manage out. For networks that cannot support native IPv6, some form of IPv6 encapsulation or transition technology will need to be used (using the method discussed in my previous blog post perhaps).
So, what does it mean to use native IPv6 for managing DA clients from the intranet then? Well, in it’s simplest form it means manually configuring your management clients with static IPv6 addresses from a suitable IPv6 prefix and then providing the appropriate IPv6 routing to reach DA clients by way of the DA server they are connected to. For this blog post, this is the example I am going to use to begin with and is based around the same premise as my last article; namely that the number of management clients involved is usually pretty small, or involves the use of ‘jump hosts’ that are shared by admin/support staff. Hence, the plan is to keep things simple for now and continue with the use of manual IPv6 configuration to describe the overall concept. At this juncture, it may also be useful to know that I wrote a basic overview of IPv6 addressing choices for DirectAccess in a previous blog post here which may also prove useful if you considering a more automated approach to IPv6 configuration.
When DirectAccess is installed, a 6to4-based organisation prefix is created automatically using the following IPv6 prefix format 2002:WWXX:YYZZ:3333::/64 where WWXX:YYZZ are the hexadecimal representations of the primary public IPv4 address octet pairs bound to the external network adapter of the DA server (with the IPv4 address formatted as WW.XX.YY.ZZ). So, using an example where the primary public IPv4 address is: 131.107.0.2 this would result in a 6to4 prefix of: 2002:836b:2:3333::/64 as 131 in hex is 83, 107 is 6b and 2 is 2.
Please Note: If you are using your DirectAccess server behind a NAT device and consequently using private IPv4 addresses on the external network adapter, as opposed to public IPv4 addresses, the IPv6 prefix will be in the form of: FD##:####:####:7777::/96 as per RFC 6147. The DA client IPv6 prefixes for Teredo and IP-HTTPS will also follow a similar structure when using private IPv4 addresses.
Still with me? If so, let’s move on…
Given this IPv6 prefix, we can now use this to generate static IPv6 addresses for the management clients using the format 2002:836b:2:3333::# where # is a manually chosen unique number used by each management client. By default the DA server will automatically use the 2002:WWXX:YYZZ:3333::1 address, so anything above this value should be fine as long as though it is unique and not in use. Furthermore, when defining the static IPv6 address, the subnet prefix length will normally be 64.
So with the static IPv6 address defined, all we need to do now is consider how we ensure that IPv6 traffic can reach the DA clients that are connected to the DA server. This is achieved in two ways; by defining an IPv6 default gateway, or by defining specific individual IPv6 static routes. Focusing on the first option, as mentioned, for our example the DA Server will be assigned a static address of 2002:836b:2:3333::1 so we can simply define this as the IPv6 default gateway on management clients. The final result is shown below:
image
Making the DA server your default IPv6 gateway may not be desirable, or recommended in most cases. Therefore, as an alternative approach you may wish to be more specific and ensure that only IPv6 prefixes that are used by DirectAccess clients are routed to the DA server by way of specific IPv6 static routes. This provides much better control over IPv6 routing and allows for specific DA client management traffic to be considered without impacting on other IPv6 services. This is achieved by defining the static routes, on each management client, to cover necessary DA client IPv6 prefixes, as opposed to defining a global/single IPv6 default gateway. For our example, these include:
IP-HTTPS Clients Prefix: 2002:836b:2:1000::/64
Teredo Clients Prefix: 2001:0:836b:2::/64
Turning these IPv6 prefixes into IPv6 static routes, we get the following respective commands based upon our example above:
netsh int ipv6 add route 2002:836b:2:1000::/64 [Name of Intranet network adapter] 2002:836b:2:3333::1
netsh int ipv6 add route 2001:0:836b:2::/64 [Name of Intranet network adapter] 2002:836b:2:3333::1
Please Note: Sharp eyed readers may have noticed that I have not mentioned 6to4 clients. The reasoning behind this decision is that the 6to4 transition technology only works when the DA client has a public IPv4 address (which is a typically rare scenario nowadays) and issues often occur in networks where the DA client gets a public IPv4 address but cannot actually reach the 6to4 relay due to some form of in-path NAT. For these reasons, it is recommended practice to disable the 6to4 transition technology on DA clients and therefore it is not covered above.
At this point, those of you more familiar with IPv6 may be thinking “…is this guy mad? Why is he defining static IPv6 addresses??!!” Well, firstly, it makes things simple for the given example and in reality if you only have a small number of management clients (or ‘jump hosts’) it is actually quite feasible to use static addresses. This approach requires no additional network infrastructure, or network configuration for IPv6, and is actually pretty quick and easy to do. The obvious problem here is that this admin overhead doesn’t scale well and the IPv6 protocol was specifically designed to use a concept of automatic address selection and static addressing is therefore pretty much a thing of the past. However, as discussed, we are dealing with a very specific example, trying to keep things simple and we are not designing IPv6 for the entire intranet.
In the event that you have a larger number of management clients, or just feel that static configuration is not appropriate for your environment, it is better to use some form of IPv6 auto-configuration mechanism in order to provide management clients with addressing information and route assignment, without the need for human intervention. IPv6 auto-configuration can be performed by any capable Layer 3 network device (which includes a Windows Server) although as discussed, this is out of the scope of this blog post at this time. However, it may be interesting to note that the necessary steps for using a Windows Server to provide IPv6 auto-configuration have been covered in one of my previous blog posts here
Now we have management clients with IPv6 addressing information and the appropriate IPv6 routing table entries, we can hopefully begin managing DA clients from the intranet. At this stage you should be able to ping a remotely connected DA client from a management machine and receive an IPv6 response, assuming there is a route to the destination and ICMP echo requests are enabled in the firewall.
Important: Ping is helpful to verify that basic connectivity is working and validate you management client IPv6 configuration parameters, however, should only ping work but not any other type of connection then it’s most likely to be an IPsec-related issue. This is because ICMP is exempted from the DirectAccess IPsec tunnels and therefore provides limited value when testing connectivity from management clients to DA clients. More discussion on this topic cab be found here.
Before we can have a fully working solution it may also be necessary to consider a few additional steps, which based upon my own experience, are not totally obvious and can easily be forgotten.
If you have defined new IPv6 addresses on System Center Configuration Manager servers, it will be necessary to use the Refresh Management Servers option in the Remote Access Management console, as shown below, in order for the new IPv6 address information to be added to the DirectAccess clients GPO:
image
The same thing is true for Domain Controllers, but I am guessing that you will not be defining these as specific management clients. Furthermore, implementing IPv6 addressing on Domain Controllers introduces additional considerations to Active Directory functionality and operation which are key to ensure services are not impacted.
For all other management clients, it will be necessary to manually add each of them to the Management servers list which can be found in the Step 3: Infrastructure Servers section of the Remote Access Management console as shown below:
image
Once entries have been added, the updated configuration can be committed using the Finish… button.
The final task is to run gpupdate /force on management clients and DA clients to ensure they get updated GPOs which have been modified by the changes described above. Alternatively, you can wait for the next Group Policy refresh cycle but I’m normally kinda impatient!
Please Note: Don’t forget that it will still be necessary to define Windows Firewall with Advanced Security (WFAS) inbound rules on the DA clients to allow for the necessary permitted network access as discussed here.
All being well, you should now be able to initiate outbound management requests to DA clients from management clients on the intranet without necessarily have to resort to ISATAP and hopefully you have a little more confidence that using native IPv6 is not quite so scary after all :)
Now, go manage out with native IPv6!
P.S. Special thanks to Philipp Kuhn for the article inspiration and technical review assistance!

Thursday, 17 January 2013

A New Year and a New Job!

As you may have seen from my biography changes on my blogs and also over at the TechNet forums, I now work directly for Microsoft; specifically, for Microsoft Consulting Services (MCS) in the UK as a security consultant. I have therefore lost my MVP status (which is very sad) as I am now a Microsoft full-time employee (which is very good) and you cannot be both. It is an exciting time and I am very much looking forward to the new role and the challenges it will bring.

Given my new role, I am not sure how much time I will be able to dedicate to this blog (or anything new for that matter!) but I plan to keep it available so it is accessible via search engine results, referenced in a few books (thanks Ben/Ran) or included as links I have put into TechNet forum posts. I will still be replying to comments made on existing posts, so feel free to continue to ask questions or comment as required. I still plan to be very much part of the online community and work at helping people use the Microsoft technology to achieve their security goals, but as ever, I will need to balance this with my day job.  

Once I have settled into my new role, I hope to be back when I can to share notes from the field (subject to NDA) and my experiences along the way…