Troubleshooting Direct Access Teredo connectivity on Forefront UAG 2010

I encountered a problem on one of my installations for DirectAccess where all the clients were able to connect to DirectAccess using HTTPS only. After several investigations and with the help of senior Microsoft Engineers we noticed that the Teredo IPV6 route is missing on the server. When the server is trying to respond to Teredo requests, it uses the default Route (6to4) instead of the server Teredo Adapter due to the following route entry:

To fix this issue you need to manually add the Teredo route as follows:

1. We need to obtain the Teredo Adapter interface index (IDX) from running the following elevated command on the UAG server “netsh int ipv6 show int”
2. Add the route manually (using the obtained IDX from the earlier step) as follows:

Read More

Certificate CRL and Delta CRL are not copied automatically to the HTTP Path

A common problem noted on several implementations of Active Directory Certificate Services is the CRL and Delta CRL copies to the HTTP Path.  By default Microsoft Enterprise CA only publishes CRL automatically to LDAP path defined in the CRL Distribution Point (CDP). Normally CA administrators could define CDP in many locations as LDAP and HTTP (Inetpub Folder). Since it’s only copied to LDAP, the HTTP location gets expired and the user would encounter this error.

The certificate will try to retrieve the CRL and Delta CRL from each defined location (LDAP and HTTP) when system check the revocation status of certificate. If it can get the CRL from one and only one of these locations then it will pass the revocation process and function normally even if the CRL is not copied to the HTTP location. However it will give the above Expired Status for CRL and Delta CRL HTTP Location.

To solve this issue you have two options:

1. Copy them manually from the CERTSRV folder to the Inetpub folder
2. Create a batch file to copy them automatically and add this batch file to the daily scheduled tasks.

The Batch file should be something like this

Xcopy c:\windows\system32\certsrv\CertEnroll\*.crl  C:\Intetpub\

Read More

Manual Install of UAG 2010/Remote App and RDS Portal Components

Microsoft UAG 2010 main functions are Application Publishing and Enhanced DirectAccess deployment. The Application publishing allows you to publish several applications on either HTTP or HTTPS trunk. Application publishing includes Web applications, Non-Web applications, Remote Desktop Services (RDS), RemoteApps and VPN services.

When accessing the UAG portal for the first time from your computer using one of the supported browsers (Please check the Client requirements and Supported browsers in http://technet.microsoft.com/en-us/library/dd920232.aspx) the user will be prompted to download and install the UAG endpoint components, these components are used in many things among them checking device (Endpoint detection), SSL tunneling……………etc. This installation is done once per computer.

Some clients have restricted Internet Explorer settings (Using Group Policies) that prevent them from installing MSI or EXE files from the Internet and they need to install the Endpoint components manually.

There are two types of clients that you need to install manually to fully utilize the UAG portal.

1.    UAG Client Components, these are available on the UAG server under

 C:\Program Files\Microsoft Forefront Unified Access Gateway\von\PortalHomePage

 

Several files are available under this location for each component or you can just take the WhlClientSetup-all.msi from this location and have your users install it manually (Of course they need to have admin rights on their computer). Make sure you are running the latest UAG version on your server. The current latest version is 4.0.1773.10110 http://support.microsoft.com/kb/2647899

 

When manually installing the WhlClientSetup-all.msi, the users will be given the choice for Typical installation or Custom Installation to pick specific components as per the below screenshot.

 

2.    Remote Desktop Services (RDS) and RemoteApp need the latest Remote Desktop Connection 7.0 client update for Remote Desktop Services (RDS) for Windows XP SP3, Windows Vista SP1/SP2 which can be downloaded from the following site  http://support.microsoft.com/kb/969084  

This RDC 7.0 client is already installed by default on Windows 7 systems. If you using Network Level Authentication (NLA) on the RDS servers then you need to check this article http://support.microsoft.com/kb/951608 since the NLA is disabled on XP service pack 3.

 

Once both components (UAG and RDS) are installed manually, the user will be prompted to approve running the ActiveX and adding the portal site to the browser trusted sites.

Read More

DNS64 Not Healthy after Applying UAG SP1 Update 1 Rollup 1

After applying the latest Rollup 1 for UAG SP1 Update 1 released on Jan 12, 2012 I noticed that the DNS64 is unhealthy under the Direct Access Monitor/Current status as shown in the below figure.

I did a reboot to the UAG/Direct Access server (although it’s not required by the fix) however the DNS64 component still showed unhealthy. I disabled/enabled direct access as follows:

1.     Disabled Direct Access

2.     Saved/Activated the configuration

3.     Enabled Direct Access

4.     GPupdate /force on the UAG Server

5.     Applied the policy

6.     Activated the configuration

After that it all worked fine. I am not sure about the reason (Will try to check with Microsoft Team) however that workaround fixed my problem.

Read More

Publishing Direct Access Web Monitor on UAG Portal

Recently I tried publishing the UAG Web Monitor on my External HTTPS Web Portal, the UAG web monitor is very useful monitoring and reporting web application which gives you the ability to view different UAG sessions, applications, Direct Access and the UAG event viewer.

When the UAG Web Monitor is published on the UAG Portal Trunk everything works fine except the Direct Access section (Current Status and Active Sessions). When you try to open the Current Status or Active Sessions you get the below error screen.

This issue looks like a bug with the UAG and I opened a support case with Microsoft and they are considering a permanent fix. Currently to fix this issue you need to add 5 rules as follows:

1. Go to the Trunk Configuration - Configure Trunk Settings - Configure - URL set.
2. Copy any Web Monitor default rule and paste it 5 times
3. Modify/Add the URL in the 5 rules as follows:
1. /damonitor\.asp
2. /damonitorcurrentstatus\.asp
3. /damonitorcurrentstatusrefresh\.asp
4. /damonitoractivesessions\.asp
5. /damonitoractivesessionsrefresh\.asp
4. Save- Activate and this should fix the issue.

Here is a Screen shot of how these rules should be added and modified.



Read More

Passed EC-Council CHFI (Computer Hacking Forensics Investigator)

Last week I passed the EC-Council CHFI exam (312-49). This is my second certification with EC-Council after taking the CEH exam. From my point of view The CEH exam was harder than the CHFI as it covers broad range of technical areas. The CHFI lays a good foundation for the Forensics domain, however if you are taking the Forensics as a job then I would recommend going to CHFI plus GIAC Forensics Certification or Guidance Software (EnCase).

Read More

Teredo with UAG SP1 Direct Access not working

This problem was reported on a standard DirectAccess implementation scenario where all clients aren’t able to connect using Teredo and they all fall back to IPHTTPS which is the last resort for any DirectAccess connection.

Symptoms:

1.       When checking the Teredo Interface state, the following was displayed.

Netsh int teredo show state

Client Type             : teredo host-specific relay

The Client type should have been Teredo Client for a successful Teredo connection.

2.       I disabled the IPHTTPS interface to ensure it won’t fall back to the IPHTTPS option, opened wf.msc (windows Firewall with advanced security mmc) and navigate to monitoring – Security associations – Main Mode and Quick Mode. Both displayed nothing as shown in the figure below. This indicated IPSEC connection failure

3.       After capturing both server and client logs and with the help of a Microsoft senior engineer we noticed the following error

 Windows error 13887(ERROR_IPSEC_IKE_CERT_CHAIN_POLICY_MISMATCH)

Resolution:

1.       A recent KB was released from Microsoft to address this specific Certificate problem with a recommended fix. This fix needs to be applied on both the DirectAccess Server and Client.

 http://support.microsoft.com/default.aspx?scid=kb;EN-US;2615847

2.       It turned out that the DirectAccess server has an Antivirus solution which seems to load several modules like NAC and others although it was configured to run normal AV file protection.

 After applying the Fix and removing the AV from the UAG server the clients were able to connect normally using Teredo.

Read More