With disruptive flag enabled

Archives mensuelles : avril 2013

In normal condition, each computer with DirectAccess enabled must be checked for all prerequisites before leaving the company office. That’s a wise advice. With Windows 7 Operating systems, the IPSEC certificate must be present in the computer certificate store. With Windows 8 you can have the same problem if your DirectAccess infrastructure require Certificate for IPSEC tunnel authentication.

Maybe because my customer was so happy with his new DirectAccess laptops that he forgot this wise advice to perform basic prerequisites checks.

Problems began with laptops shipped overseas. DirectAccess Connectivity Assistant reports shows that the required certificate for DirectAccess was missing. Two simple tests can be performed with PowerShell or « CertUtil.Exe ».

Problem, how to recover these clients without ship computers back to the office for recovery. That was the challenge.

My solution

My solution was to use a computer to request a certificate on behalf-of DirectAccess clients to recover. To perform such operating some prerequisites are required:

Local administrator privilege will be required on DirectAccess clients to recover

A temporary certificate template will be required

Create the temporary certificate

This step aim to create and publish a new certificate based on existing « DA Certificate » template. This is required for multiple reasons:

So let start with the DA Certificate duplication. This certificate will be used only by computers compatible with V3 certificates. This means we can select « Windows Server 2008 Enterprise » option.

This new certificate template will be named « Offline of DA Certificates ». This certificate template will be dedicated to recovery scenario. For this reason, you can reduce validity period.

In the « Request Handling » tab, we configure this certificate template to allow private key export. This is required because certificate request won’t be performed on the computer requiring the certificate.

In the « Subject Name » tab, we select to use information that will be provided in the certificate request to generate the subject name of the certificate. It’s also required because certificate request will not be performed by computer witch require the certificate.

This certificate must be published in Active Directory and available for certificate request through the Microsoft Management Console certificate snap-in.

Requesting the certificate

Certificate request can be performed on any client computer that can reach perform the request (connected on LAN or DirectAccess). With the classic Certificate snap-in of the Microsoft Management Console we start the request certificate wizard. This request must be performed at computer store level, not user.

Here begin the tricky steps. Even if our new certificate template is available, we need to provide additional information to complete the certificate request. We must click on the « More information is required to enroll for this certificate. Click here to configure settings ».

In the subject tab, we need two information. First the subject name, then the DNS Name. Theses information must be provided with this format:

CN=<Computername>.<Active Directory FQDN>

<Computername>.<Active Directory FQDN>

In illustration bellow, I provided these inputs for « CLIENT7.DIRECTACCESSLAB.LOCAL » computer and click to the « Add > » button.

Certificate request is not yet complete. From my point of view, this certificate usage is limited to recovery scenarios, so limited in time. At the end of the recovery process, this certificate will no longer be required. That’s why I put a comprehensive description.

At last, I check that the certificate private key option is checked. Otherwise, we won’t be able to export private key.

Now certificate request is complete, we can send it to the Active Directory certificate Services for processing.

At the end of the enrollment process, we have a certificate witch name does not match our computer name. This certificate must be exported.

Most important, this export must include the private key. Option is available because the certificate template allow it.

The PFX file will include all required information. Export process will delete certificate from our computer. We don’t need it here.

Because our PFX file include sensitive information (private key), package must be protected with a password (A strong password will be a good idea).

Now you’re ready to send this PFX file to the DirectAccess computer to recover. You can send it by mail but just send the PFX file and provide the required password by an alternate communication path for security reason.

Import

Once we import the PFX file on the DirectAccess computer to recover we can restart the IP Helper Service. If your certificate subject name match computer DNS name, DirectAccess will be operational as illustrated bellow:

That’s great but we need to fix the problem and use the Certificate snap-in of the Microsoft Management Console to perform a certificate enrollment. We will request the missing certificate: « DA Certificate ».

At the end of the enrollment process we have two certificate in the computer store. We must delete the temporary certificate. If we have a look at the certificate, it’s easy to recognize witch certificate to delete because it’s another certificate template.

Once we delete the temporary certificate, we just have to restart the IP Helper service a last time to force DirectAccess to use the only remaining certificate in the computer store to initiate IPSEC tunnels.

Even with Windows 8 and Unified Remote Access, performing some basic tests before shipping DirectAccess computers to users remain an excellent idea. The certificate missing case, is easy to solve. It’s to the case if the Group Policies were not applied to computers

After a warn-up with the TMG can be a good friend of DirectAccess post, let’s raise the level and try to publish our IPHTTPS protocol on an alternate public port. But why do we need to do such a thing? Maybe we already have an application published on the 443 external port of my TMG box. In my case, it is just another IPHTTPS publishing rule (Why do-I need two DirectAccess, that’s a good question I will answer in another blog post. It’s a part of a future DirectAccess Challenge). So it’s just again a non-Web Server protocol that need to be published. Let’s start the wizard.

First action, choose a name for our new rule. In my lab, I wanted to introduce an additional Unified Remote Access Server that will be located in a branch office. Don’t ask why I need it, it’s a challengeJ. This new URA Server has been configured with a single Network Adapter and will have its IPHTTPS protocol published on Internet.

In my lab, my Unified Remote Access Server is located in a branch office. We just provide its internal IPv4 public address.

It’s a « HTTPS server protocol »yes, but not published on its default port. For this reason, we must customize protocol definition.

This protocol will be published on the same external interface as my first IPHTTPS protocol. This would not cause conflict because we won’t be using the default port.

That almost terminated. Now it’s time for magic tricks.

And now two magic tricks. First one, we must customize rule to reconfigure how network frames will arrive to the URA. They must appear to come from the TMG box. Otherwise, it will not work.

Second magic trick, we must instruct the DirectAccess client to use this new port for IPHTTPS protocol. This information is provided in the Client-Side GPO generated for my branch-office URA Server. Let’s have a look at the IPHTTPS configuration with a Get-NetIPHTTPSConfiguration PowerShell CommandLet.

Note that I had to specify a domain controller because my lab environments include RODC at branch office. Updating a GPO on a RODC is not a magic trick. If I can retrieve the IPHTTPS protocol configuration from a GPO, I can pass this object to a Set-NetIPHTTPSConfiguration PowerShell Command to reconfigure the ServerURL parameter.

Now let’s see if the magic trick work on a Windows 7 DirectAccess-enabled computer connecting to the URA Server in my Branch-office. And Yes, IPHTTPS interface is operational and using my alternate port.

Yes, even if today, Threat Management Gateway 2010 is not longer available from Microsoft product line, there still have in production, and some of them will remain online because they do the job. But why TMG can be a DirectAccess good friend?

As a matter of fact, it’s may be Unified Remote Access (URA) good friend because a new feature was introduced to Windows Server 2012 that make DirectAccess so easy to deploy : Publishing DirectAccess behind an Edge device

And in my case, my Edge device is a Forefront Unified Access Gateway. Let’s have a look at this in a TMG Management console :

When you configure your URA Server to operate behind an edge device, Teredo protocol wont be available (No consecutives IPv4 public addresses), neither 6to4. Only IPHTTPS will be available. But it’s not a web site. Technically the only thing that IIS and IPHTTPS protocol share is the HTTP.SYS stack at kernel level. We wont be publishing a web site but a non-web protocol.

First required parameter, the private IPv4 interface of my Unified Remote Access server. In my case, my URA server is configured with a single Network card.

That protocol will be published on the external Network card of my TMG server, but only on one IPv4 public address

In my case, this is 131.107.0.10.

So IPHTTPS interface of my URA server will be available on Internet on this IP address.

Our TMG configuration is now terminated. It’s time to activate the new configuration and test that out.

A simple “Get-DARemoteAccessConnectionStatistics” PowerShell command will show to that my client is connected with IPHTTPS. In my case, this was a Windows 8 client, but this also work with Windows 7 if you enable the legacy client support feature.

So don’t underestimate the value of your existing TMG investment, it can be used with DirectAccess if you choose Unified Remote Access included in Windows Server 2012.

Final question : Is it possible to publish Unified Remote Access server on an alternate public port? Technically speaking yes but I won’t explain this in this blog post. This will be a subject for the DirectAccess Challenge series. Stay tuned and get an aspirin tube ready for that journey to DirectAccess in SDI scenario.

Even if DirectAccess is now much more easier to deploy with Windows Server 2012, there still have some “cases” where Microsoft help is required. Jason Jones (Former Forefront MVP) updated his “Hot list” recently. Keep a bookmark on this list. This can save a lot of time during your next DirectAccess deployment.