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
Publié par 13 commentaires:
Libellés : , , , , ,

vendredi 3 mai 2013

[DirectAccess] Part 4: Authenticating DirectAccess clients with certificates

In part 1 of this series, we configured DirectAccess for an IP-HTTPS connection in a simple (home) environment. In part 2, we enabled reporting and improved client settings to reduce connection time. In part 3, we replaced self-signed certificates by certificates generated from our PKI.

I propose to continue to improve security of our DirectAccess environment and to authenticate computer with certificates.

PART 4: AUTHENTICATING DIRECTACCESS CLIENTS WITH CERTIFICATES


1. Configure a client authentication template for auto-enrollment

On the PKI server, open the Certification Authority console
Expand your Certification Authority
Right-click Certificate Templates and select Manage

In the Certificate Templates console, right-click Workstation Authentication and select Properties
Open the Security tab
For Domain Computers, select the checkbox to Allow Autoenroll
Click on OK


In the Certification Authority console tree, right-click Certificate Templates and select New >  Certificate Template to Issue
Select Workstation Authentication and then click OK
Close the Certificate Templates Console.

Notes:
 - You can duplicate the Workstation Authentication template and publish a custom template. However that certificate can be used for a lot of purposes: SCCM HTTPS mode.. So keep that certificate as generic as possible.
 - You can limit the auto-enrollment only to the group containing the DirectAccess computer clients.
 - Certain process recommend to create a custom a template and to add the Server Authentication application policy. On my own experience, that's totally useless !



2. Configure computer certificate auto-enrollment

Open the Group Policy Management Console
Expand your domain
You can create and link a specific GPO or modify an existing GPO (Default Domain Policy...)
In the console tree of the Group Policy Management Editor, open Computer Configuration\Policies\Windows Settings\Security Settings\Public Key Policies
Edit the Certificate Services Client - Auto-Enrollment policy


In Configuration Model, select Enabled
Select Renew expired certificates, update pending certificates, and remove revoked certificates and Update certificates that use certificate templates


Click OK and close the GPMC console



3. Check Client certificate

Tips:
On the Windows 8 Start Screen, simply type cert
Select Settings and click on Manage Computer certificates.
That easier than adding the certificate snap-in in a mmc console !


As soon as your computer receive GPO, "Workstation authentication" certificate is generated




4. Enable Certificate authentication for computers

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


Go to the Authentication step
Select Use computer certificates
Click on Browse



Provide the certificate of your Certificate Autority
Click on Finish




5. Logs and Authentication

Client connection is always totally transparent with DirectAccess. I propose to look at the reporting console:

Before (no certificate authentication):

Machine and User are authenticated with Kerberos.




After (with certificate authentication):

In the Remote Client Status console, you see for Authentication "Machine Kerberos, Machine Certificate & User Kerberos". !?!


To get more information, open the reporting console.
For the first tunnel (to reach Active Directory environment), the machine still uses kerberos authentication.



For the second tunnel, the machine uses its certificate.




You've got now a DirectAccess environment  fully authenticated with certificates and that works with the IP-HTTPS protocol on a Windows 2012 core Edition.

In the next article, I will provide you some recommendations and tips from my own experience to troubleshoot DirectAccess.

See you soon
Julien




Publié par 3 commentaires:
Libellés : , , ,

vendredi 19 avril 2013

[DirectAccess] Part 3: Authenticating IP-HTTPS connections with a PKI certificate

In part 1 of this series, we configured DirectAccess for an IP-HTTPS connection in a simple (home) environment. In part 2, we enabled reporting and improved client settings to reduce connection time.

In the two next parts, I propose to improve the security. In this part, we will remove the self-signed certificate used for IP-HTTPS connections and we will generate a certificate from our PKI.
Next part is dedicated to client authentication.

PART 3: AUTHENTICATING IP-HTTPS CONNECTIONS WITH A PKI


1. Preparing PKI

If you don't have a PKI, Install the AD CS (Active Directory Certificate Services) role on a server (your DC if you want).

You can install it from the Server Manager dashboard (add role...) or with powershell with the command lines :
Install-WindowsFeature AD-Certificate -IncludeManagementTools
Install-AdcsCertificationAuthority -Force

For more information, read the instructions on Basic PKI for Windows Server 2012.



2. Remove the self-signed certificate for IP-HTTPS connections

From a server or a computer with a GUI, open a mmc console
Add the snap-in Certificates


Connect on your DirectAccess server


In the Personal Store, find and select the IP-HTTPS certificates
Its friendly name is normally DirectAccess-IPHTTPS


Remove that certificate
Close the mmc console.




3. Request the IP-HTTPS certificate to your PKI

You can't request and import a certificate with a private key if you're not connected locally on the server. So with a core server, don't try to request the IPHTTPS certificates, with a mmc console from another computer.

So, there are 2 solutions:
 - Autoenrollment : you create the IPHTTPS certificates template on your PKI and you define security options to allow only your DirectAccess server to enroll that certificate automatically. Good idea !
 - Request certificate with command lines. Let's do that !


Open a command line option on you DirectAccess Server
In a temporary folder, create (locally or remotely) the file certRequest.inf with the following content:

[NewRequest]
Subject = "CN=<public domain name of your server. For example da.nomizo.fr>"
Exportable = FALSE
KeyLength = 2048
KeyUsage = "CERT_DIGITAL_SIGNATURE_KEY_USAGE | CERT_KEY_ENCIPHERMENT_KEY_USAGE"
MachineKeySet = TRUE
FriendlyName = "IPHTTPS PKI"
[RequestAttributes]
CertificateTemplate="WebServer"

Generate your request file with the command line
certreq -new certRequest.inf certRequest.req


To check the content of your request, use the command line
certutil certRequest.req


Submit your request to your PKI and get you certificate with the command line
certreq -submit certRequest.req IPHTTPS-Cert.cer

Select the CA you want to contact and click on OK


On your CA, you can see the generated certificate


On your DirectAccess server, you can confirm the RequestID


Now that you've got your .cer file, just accept it
certreq –accept IPHTTPS-Cert.cer


With a remote MMC console, you can watch you new IP-HTTPS certificate


For information, this is the IP-HTTPS certificate generated for my DirectAccess Server



Note that I've got an alert for the CA certificate. That's only because my local machine can't confirm that my DirectAccess server trusts the CA certificate.



You can read certreq references on Technet to get more information :
http://technet.microsoft.com/library/cc725793.aspx



4. Define your new IP-HTTPS certificate in DirectAccess

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


On the Network Adapters screen, click on Browse


Select your new IP-HTTPS certificate


You can ensure that you select the right certificate by clicking on Click here to view certificate properties.
Note that private key information is not shown.


Click on OK to select your certificate. The Common Name of your certificate appears.
Click on Next


Click on Finish




5. Update configuration

At the bottom of the screen, click on Finish


Click on Apply


Click on Close


To monitor your server status, click on Dashboard

You will certainly get several alerts and a message that says "Configuration for server servername not yet retrieved from the domain controller"


Just wait or type the command line gpupdate /force to speed the process


If you still receive an alert that says "Configuration for server servername retrieved from the domain controller, but not yet applied.", that means probably that you made a mistake during the IP-HTTPS certificate creation.
See technet for more information about configuration distribution issues.


6. Certificate for NLS Server

With the same method you can replace the self-signed certificate for NLS (Network Location Server) server by a PKI generated certificate.


You can use the certRequest.inf file with the following content

[NewRequest]
Subject = "CN=<NLS name of your server. For example DirectAccess-NLS.sc.lab>"
Exportable = FALSE
KeyLength = 2048
KeyUsage = "CERT_DIGITAL_SIGNATURE_KEY_USAGE | CERT_KEY_ENCIPHERMENT_KEY_USAGE"
MachineKeySet = TRUE
FriendlyName = "NLS PKI"
[RequestAttributes]
CertificateTemplate="WebServer"


Note : Ensure that your DNS record exists. Especially, if you use the same CN than the self-signed certificate, DirectAccess may remove the DNS record.


You can also set an HTTPS server what you can reach on your network. Be careful, that URL must be available ONLY from your internal network, otherwise your clients will suppose it is locating on your network and won't create a DirectAccess communication.




Now, our DirectAccess server use certificates generated from our PKI. It's really more secure !
In the next part, I will show you how to improve client authentication security with certificates.


See you soon
Julien


Publié par 1 commentaire:
Libellés : , , , ,
Inscription à : Articles (Atom)