vendredi 26 juillet 2013

[DirectAccess] Part 6: Configuring DirectAccess for Windows 7


In previous parts of this series, we configured DirectAccess on Windows Server 2012 for Windows 8 client computers.


Indeed, the current environment accepts only connections from Windows 8 computers. You certainly saw the option "Enable Windows 7 client computers to connect via DirectAccess". Is that all ? Obviously not.
In that article, I propose to configure our DirectAccess environment for Windows 7 clients. We will also discover the impacts on the architecture and how to troubleshoot DirectAccess for a Windows 7 clients.


PART 6: CONFIGURING DIRECTACCESS FOR WINDOWS 7


First thing first :
1. Enable Windows 7 client computers to connect via DirectAccess

Open the DirectAccess Console
In the Step 2 - Remote Access Server Box, click on Edit


 - On the Authentication page, select the option Enable Windows 7 client computers to connect via DirectAccess
 - Click on Finish and apply the configuration on the DirectAccess Server




2.Install the DirectAccess Connectivity Assistant

Download the DirectAccess Connectivity Assistant 2.0 on http://www.microsoft.com/en-us/download/details.aspx?id=29039.
Note that this version apply only on computers running Windows 7 when connecting to internal corporate networks with DirectAccess in Windows Server 2012 (only).

The package contains documentation, admx files for GPO and MSI files.
 - Intall the Microsoft_DirectAccess_Connectivity_Assistant_x64.msi or the Microsoft_DirectAccess_Connectivity_Assistant_x86.msi MSI file depending on your plateform.


The installation is really easy : I Accept, Install and Finish...






3. Set DirectAccess Connectivity Assistant settings

Indeed, parameters for DirectAccess Connectivity Assistant are provided by GPO:

 - Copy the ADMX file and ADML in your environment. In my own lab, I use a CentralStore.
(for more information http://www.microsoft.com/en-us/download/details.aspx?id=23947 and http://support.microsoft.com/kb/929841/en-us)



You can modify directly the DirectAccess Client Settings GPO but the Best Pratice is rather to leave DirectAccess manage that GPO and to configure the DirectAccess Connectivity Assistant with a dedicated GPO.

- Open the report of the DirectAccess Client Settings GPO
- In Computer Configuration > Policies > Administrative Templates > Network > DirectAccess Client Experience Settings, read the properties: Corporate Resources, IPsec Tunnel Endpoints (DTEs) and Support email Address.


- Create and link a new GPO to your Windows 7 computers
- In Computer Configuration > Policies > Administrative Templates > DirectAccess Connectivity Assistant, define the properties: Corporate Resources, DTEs and Support email Address.


 - Force GPO refresh on your Windows 7 computer client and connect it to the Internet.



4. Troubleshooting

In general, if DirectAccess works with Windows 8 computer client, It'll be good for Windows7.
However, if you have problems...


 - Click right on the DirectAccess Connectivity Assistant icon and Select Advanced Diagnostics


 - Logs are automatically generated. Click on the link.


 - Open the text file.


The assistant provides a first analysis and a lot of configuration dumps


Note that Powershell commands provided in Part 5: Troubleshooting guide for DirectAccess are not available in Windows 7. It's nice to have a full automatic tool that can make automatically all tests for you !

In that screenshot, we see the NRPT policy applied on the client.




5. DirectAccess works fine

Congratulation !






6. What are the impacts ?

In that chapter, I propose to show you the impact of adding certificates and enabling Windows 7 support.

Here, is a screenshot of the DirectAccess Client Settings GPO with default DirectAccess configuration (no certificates for clients authentitication).
Computer and User authentications rely only on Kerberos.


Now, a screenshot of the DirectAccess Client Settings GPO, when adding computer client authentication with certificates. User authentication always relies on Kerberos, but computer authentication relies now on Certificate too.
To get more information, read  Part 4: Authenticating DirectAccess clients with certificates §5. Logs and Authentication.


Finally, the DirectAccess Client Settings GPO, when Windows 7 computer clients are allowed.
Kerberos authentication is no longer supported for computer. Only certificate authentication is allowed.
Concerning User authentication, NTLM authentication is available too.




7. Logs and Authentication with Windows 7 computer clients allowed

 Windows 8 computer:
There are 2 tunnels :
 - The first for computer only. That tunnel is opened even if no user has opened a session.
 - The second for user. That tunnel is based on 2 connections:
    * User authentication relies on NTLM when contacting Domain Controller.
    * User authentication relies on Kerberos for all other services.
Computer is always authenticated with its certificate.



Details of the connections for a Windows 8 computer:


User authentication relies on NTLM when contacting Domain Controller.


User authentication relies on Kerberos for all other services.



 Windows 7 computer:
There is only one tunnel containing 4 connections:
 - The first 2 connections for computer only. That 2 connections are opened even if no user has opened a session.
 - The last 2 connections for user.

Computer is always authenticated with its certificate.
User authentication relies on NTLM when contacting Domain Controller.
User authentication relies on Kerberos for all other services.


Details of the connections for a Windows 7 computer:







I hope you enjoy that series concerning DirectAccess.

See you soon !
Julien

mercredi 10 juillet 2013

[DirectAccess] Part 5: Troubleshooting guide for DirectAccess

In previous parts of this series, we configured DirectAccess on Windows Server 2012 (in core edition because that's fun and good for security !).
So now everything works ? Yes ? Perhaps, no ? ... That's right that DirectAccess is not always easy to troubleshoot.

In that article, I'll provide my feedbacks, my recommandations and my ideas to troubleshoot your environment.


PART 5: TROUBLESHOOTING GUIDE FOR DIRECTACCESS


1. IPv4 and IPv6
You now know that DirectAccess relies on IPv6. So what's different with IPv4 ?
Address are not 32 bits long, but 126 bits. That's all ? No IPv6 changes everything. Even ARP protocol is removed and replaced by ICMPv6.

I recommend you read some real good articles/white papers about IPv6 and IPv6/IPv4 transition technologies :

An IPv6 address is represented by a set of 8 groups of 4 hexadecimal digits. For example: 2001:0DB8:0000:2F3B:02AA:00FF:FE28:9C5A
Contrary to IPv4 where in general your interface use only one addresse, with IPv6, your interface use serveral address types for several purposes. Mainly you can see :
 - Global unicast addresses (equivalent to public IPv4 addresses): start with 2000::/3
 - Link local addresses (equivalent to 169.254.0.0/16): start with FE80::/64. Packages are never forwarded by routers
 - Site local addresses (equivalent to 10.0.0.0/8, 192.168.0.0/16...): start with FEC0::/10
 - Unique local addresses (improvement of site local addresses): start with FD00::/8
 - IPv4 compatible addresses: the 64 last bits look like 00:00:WX:YZ (where w.x.y.z is the dotted decimal representation of an IPv4 address).

Here is an example of network settings with DirectAccess enabled :


You certainly understand better now what you see !



2. IPHTTPS Connection Steps

The easiest tool to monitor connection is certainly netstat with the command line:
netstat -n -a
TcpView is also a great tools but for advanced troubleshooting.
So think KISS (Keep It Simple and Stupid) ;o)

  1. First of all, client try to reach the DirectAccess server with the HTTPS protocol (TCP/443)


  2. IPv6 arrives !! Client negotiates tunnel with HTTP protocol.
Question: What is fd5a:b763:7c6b:7777::c0a8:xxxx address ?
fd5a:b763:7c6b is the beginning of the addresses on the DirectAccess LAN
and C0A8:xxxx ? C0=192 A8=168... Obviously... that corresponds in hexa to the IPv4 address of my Domain Controller !!

DirectAccess Server translates in IPv6 format a IPv4 address. This is the mechanism used by directAccess to work with your IPv4 corporate network.


  3. Client contacts DNS server (UDP/53)


  4. You will certainly see other connections with other devices. You know now how to determine the IPv4 of the target device with the IPv6 address used.


Now that you know IPv6 and the connection process, Let's start troubleshooting !



3. Enable Windows Firewall

On my own experience, the most common issue concerns Windows Firewall:

DirectAccess connection is handled by the firewall Service. Windows Firewall must be enabled both on your DirectAccess Server and on your Clients.

On the clients, I recommend you enforce firewall both for Private and Guest networks.
On the DirectAccess server, network interface to check depends on your architecture. You must enable windows Firewall on the network interface where DirectAccess connections arrive.

So be careful: Often, windows firewall is disabled especially on domain networks.


If needed, you can create a GPO to enforce firewall for your server and/or your clients.
Here is my GPO to enable the firewall on my DirectAccess Server.




4.  Check DNS records

Setup Wizard automatically creates several DNS records. However, depending on you DNS scavenging settings (automatic DNS cleanup), records can be removed and It seems that directAccess never recreate them.
I recommend to disable the option "Delete this record when it becomes stale" for records concerning DirectAccess (you need to enabled the advanced mode in the view menu).

If some records have already been removed, you can easily recreate them:
Here is my own configuration. To simplify configuration, I used alias (CNAME) records.
To get the IPv6 address of the directaccess-corpConnectivityHost, you can search in the "DirectAccess Client Settings" GPO (Administrative Templates > Network/Network Connectivity Status Indicator).




5. Check Clients Settings

DirectAccess settings are provided by GPO on the clients and the servers. To check settings applied on your client, follow these steps:

  1. Connect your client on the internal network and force GPO update with the famous command line gpupdate /force

  2. Make sure that the DirectAccess GPO is correctly applied with the gpresult.exe tool.
You can use gpresult /r to get the list of GPO applied, but I recommend you create a full HTML report with the command line gpresult /h gpresult.html /f
Compare time and settings with your GPO to ensure you get all the latest settings from your DC.
If you have trouble to contact a DC see the chapter concerning NLS.

Now that you ensure DirectAccess GPO is correctly applied, you have 3 cmdlets to watch DirectAccess settings. Make sure that parameters are correct regarding your GPO and your infrastructure:

  3. Get-DnsClientNrptPolicy: that cmdlet is made to monitor NRPT Policy. NRPT policy manage DNS resolution that are made in and out DirectAccess Tunnel.
In the following screenshot, NRPT policy tells that name like *.SC.LAB (so my own internal domain) must be solved  and joined with the DirectAccess Server (DirectAccessDnsServer settings). However, the name DirectAccess-NLS.sc.lab must be solved normally.

Important point: If you try to contact a device directly with its IP address, that IP address will never be solved with DNS and NRPT policy. As a consequence your client will try to join that IP address directly on the Internet and not within DirectAccess on your corporate network unless you configure your client to send all connections (Internet and Corporate) in the DirectAccess Tunnel.



  4. Get-NCSIPolicyConfiguration: that cmdlet provide information about the Web Probe Host that is used by DirectAccess client computers to verify connectivity to the internal network.



  5. Get-NetIPHttpsConfiguration: that cmdlet provide information about the DirectAccess IPHTTPS connection.




6. Check HTTPS access and Certificate

Your Client is correctly configured !?! So let's check the IP-HTTPS connection.

  1. Connect now your client to a normal Internet connection, out of your internal network.

  2. In the previous chapter, we used cmdlet Get-NetIPHttpsConfiguration. Type the value of the ServerURL parameter (the public URL of your DirectAccess server) in your web brother BUT remove the last letter.
Normally, you get a HTTP 404 Error (that's normal, because we made intentionnaly a mistake on the URL) but your are now sure your DirectAccess is reachable.


If you get no response, that means certainly that your DNS is not properly configured or that HTTPS (443/TCP) port is not correctly configured.
Check prerequisites described in Part1 - chapter 3 Prepare your Network.


  3. Now, type the correct URL.

Nothing appears and your brother always wait for the page. That's normal !

If you get an error message concerning your certificat, this means that your certificat is not correctly trusted by your client.
Check the certificate and ensure your certificate is correctly trusted.




6. Network settings and DNS

For DirectAccess with  IP-HTTPS, you only have to open and forward the HTTPS (443/TCP) port (Part1 - chapter 3 Prepare your Network).

You must allow the DirectAccess server to reach at least the DNS server, the Domain Controller and the NLS server. By default, the NLS server is the DirectAccess server itself. If you move that role to an external HTTPS server, you must open the 443/TCP port from the DirectAccess server to that external NLS server.
For more information, see the NLS chapter.

Here are some cmdlet you can use to get status information on your client:

Get-DAConnectionStatus: To get the general status of your DirectAccess connection. That cmdlet is really useful to know if your client can reach your DirectAccess Server (proxy, bad network configuration...)



Get-NetIPHttpsStats: To get the status of the connection with IP-HTTPS protocol. That cmdlet is usefull if you suspect your client use other protocol than IP-HTTPS (See Part 2 - Chapter 2 Improve connection time)


Same command exists for other protocols:




7. Check Events

You can get logs from 2 components :

  1. CAPI2
The Capi2 service is in charge of certificates validation.

To get logs of that service, lauch the Event Viewer (Eventvwr.exe) and open Applications and Services logs > Microsoft > Windows > CAPI2 >Operational
By default, logs for that service are disabled. You need to enable them.

On your client, you will be able to ensure everything is ok with the certificates for computer, IPHTTPS connection, NLS...
Normally, you shoudn't see any error.



  2. Firewall logs
If you have trouble with the Windows Firewall, you can also check logs.
By default logs are disabled.

To enable logs :
 - type the command line : auditpol.exe /set /SubCategory:"MPSSVC rule-level Policy Change","Filtering Platform policy change","IPsec Main Mode","IPsec Quick Mode","IPsec Extended Mode","IPsec Driver","Other System Events","Filtering Platform Packet Drop","Filtering Platform Connection" /success:enable /failure:enable
- Restart the firewall service : net stop MPSSVC && net start MPSSVC

To read logs :
 - Lauch the Event Viewer (Eventvwr.exe) and open Windows Logs > Security
 - Click right and create a filter for the EnventIDs 4600-5500

The full process is described here.


8. NLS Server

Many issues also concern NLS Server.
NLS (for Network Location Server) helps the clients to know if they are on the internal network or out. Indeed, if client is able to contact and authenticate NLS, it considers that it is connected to the internal network.

NLS is either the DirectAccess server or an https server (called external server).

If you use the DirectAccess server as NLS server (default configuration) ensure your DirectAccess server can be joined on port 62000/TCP anywhere from your internal network. (for more information, see plan firewall requirement chapter on technet)

If you use an external server be sure:
- External server can be joined anywhere on your internal network (HTTPS port: 443/TCP)
- External server can be joined from the DirectAccess server (HTTPS port: 443/TCP)
- External server can't be joined from the Internet (don't use a public server like your OWA server)

Be careful is you apply changes on your NLS . Indeed, as long as your client is not able to contact the NLS, it considers that the resources on internal network are unavailable. As a consequence, you can't update GPO and DirectAccess configuration. If you completely lose your NLS, you may have to reinstall your clients...
I recommend to plan very carefully operations on NLS.



9. Monitor the configuration distribution status of the Remote Access server

You may experience issues when you udpdate configuration on your DirectAccess server.

I recommend you force GPO update with the command line gpupdate /force each time you apply changes. You will so ensure DirectAccess use right configuration.
To get more information about error messages, read Monitor the configuration distribution status of the Remote Access server on technet.


ADDENDUM 2013/07/24:
I forgot to show you how to generate logs in Windows 8.

 - Open your Network Connections and click-right on your DirectAccess Connection - Click on View connection properties


The  DirectAccess Properties panel opens
 - Click on the Collect Logs button


DirectAccess logs are generated...
 - Click on the View logs link



 - Open the HTML file...


The beginning is great...
Oops !! The following information is... not user friendly ;o)


... its better to open that file with Notepad.



On my mind, the reported information is not really usefull to troubleshoot your connection. The file is not as relevant as in Windows 7 (see next chapter).
However, if you have a remote user with troubles, it's easy to ask him to generate that file and to send it to you.



I hope that article helps you to troubleshoot your configuration and to understand how DirectAccess works.

In the next (bonus) article, I will provide you some feedback about how to configure DirectAccess for Windows 7.

See you soon
Julien