UAG 2010: Error “Unknown error 0xc00000403” when adding UAG machine to a Array

You may encounter the following error while joining an array member to a UAG array.

Cause: After entering username, password and Domain UAG Array Manager machine verifies these credentials with the Domain Controller using kerberos. After successful verification, it allows member to join the array. But if Kerberos communication between the domain controller and the UAG server fails, then the credentials will not be verified and UAG throws the above error.

Soultion: Restart either DC or UAG Array Manager or both. It may re-establish Kerberos communication between DC and UAG and thus credentials can be verified sent by member machine.

UAG 2010: “An unknown error occurred while processing the certificate. Contact the site administrator”

A client that is trying to access an SSL enabled application on a backend server (e.g. Exchange) that is published through the Forefront UAG portal gets an error, specifically:

“An unknown error occurred while processing the certificate. Contact the site administrator”.

The cause:

The problem has nothing to do with the UAG certificates themselves, but is most likely caused by an invalid certificate on the backend server. By default, Forefront UAG validates both the certificate and the revocation list of each SSL certificate in the backend server during the TLS handshake procedure. In the event where the certificate or the CRL are not valid, users are denied access to that given backend server. This is also the case if the CRL distribution point is unavailable for any reason. Let’s assume that the certificate is valid, but UAG is not able to reach the CRL distribution point for some reason. As per Microsoft, internet should be enabled in the UAG servers for proper working. Although, we understand that this may not be an appropriate solution for most companies because of their stringent company policies.

There are two ways to do so:

  1. Disable the CRL check in the UAG as mentioned at http://blogs.technet.com/b/edgeaccessblog/archive/2010/03/31/an-unknown-error-occurred-while-processing-the-certificate.aspx
  2. Enable internet on the UAG which will do the CRL check for you. You can do either by allowing internet traffic from UAG or by using a proxy setting in the internet explorer. Internet Explorer proxy settings are system wide, so sometimes they may not work. If not, then configure the UAG to use proxy via the WINHTTP proxy settings. To do so first run the below command to check the current settings:

Netsh winhttp show proxy

It should come-back with “Direct access (no proxy server)”, if no previous winhttp settings were defined.

Then, run the following command:

Netsh winhttp set proxy <proxy name>:<proxy port>

For example:

Netsh winhttp set proxy WebProxy.company.com:8080

Enjoy !!

Forefront UAG 2010: NAP Policies

Microsoft UAG 2010 can be integrated with Windows NAP (Network Access Protection) to make sure that the computers comply with the IT policies before users login into the UAG portal. Windows Network Access Protection is part of Windows 2008 and 2008 R2 servers. No extra hardware or licensing is required to implement Microsoft NAP in an environment. Moreover, there are simple settings in UAG for integrating  NAP to do policy enforcement. The TechNet article at http://technet.microsoft.com/en-us/library/dd857268.aspx provides most of the required information needed to configure this integration. However, there is one piece of information missing and that’s where is HRA (Health Registration Authority) installed.

Anyone who is aware of Microsoft NAP and has deployed in any network without Microsoft UAG integration would know that HRA is required and is an essential component without which Microsoft NAP will not work.

Well, that’s true with the default configuration of Microsoft NAP. However, we don’t need HRA for checking client computers and enforcing end point policies if we are integrating it with Microsoft UAG. Microsoft UAG uses it’s own enforcement method and passes the health statement from a client to the NPS (Network Policy Server) server. Also, you will see that when the client is compliant and connects to the UAG portal, no certificate is issued to the client machine which will be a case with default Microsoft NAP implementation without UAG integration. Microsoft UAG keeps track of the system state and if that changes, it will kick out the user session and user will have to login again (login window will appear only if the user computer complies with the NAP policies).

I have taken few snapshots from my testing and here’s how it looks.

Limited Network Access
==================

Full Network Access
===============

You might need restart the “Microsoft Forefront UAG Quarantine Enforcement Server” service. This is the service  which evaluates the endpoint settings against NAP policies.

**If your Microsoft Network Policy Server is installed on Windows 2008 then you can only enforce policies on Windows Vista and Windows XP. For enforcing the policies also on Windows 7 you will need Windows 2008 R2 based Microsoft NPS server. Non-Winodows machines are not supported with Microsoft NAP so no enforcement is possible on those machines.

Cheers !!

Microsoft UAG Server 2010: Making “Sign Out” link visible in SharePoint Portal

When publishing SharePoint portal through the Microsoft UAG Server it removes the default “Sign Out” link on the SharePoint portal which is otherwise visible when accessing internally (Corporate network without going through UAG). Some people do think this as an issue but really this isn’t an issue rather a feature of UAG. UAG Portal has a “log Off” button which when used logs the user off from the main UAG portal and terminates all connections from UAG to the internal servers. In some scenarios you don’t want to remove the “Sign Out” link. You can do that but there are few limitations to this. And, I will be discussing about them towards the end.

How to do it?

There are two possible ways to do it;

1. Create another portal and use the SharePoint as an initial application without a portal frame
2. Remove the “Hideout” references to logout from the AppWrap templates

For #1, all you need to do is create a new portal, add SharePoint application and then make it the initial application without portal frame as shown below.

Then, copy the file C:Program FilesMicrosoft Forefront Unified Access GatewayvonConfWebSites<Portal Name>confWhlFiltAppWrap_HTTPS.xml into the C:Program FilesMicrosoft Forefront Unified Access GatewayvonConfWebSites<Portal Name>confCustomUpdate folder. Edit the file in notepad and remove the following code.

    <DATA_CHANGE>
    <!-- for sharepoint 2007 conditional appwrap hide log off   -->
    <URL case_sensitive="false">.*.aspx.*</URL>
         <SAR conditional_variable="DontShowLogoff" conditional_var_value="True">
            <SEARCH encoding="base64">U2lnbk91dC5hc3B4Jzsi</SEARCH>
            <REPLACE encoding="base64">U2lnbk91dC5hc3B4JzsiIHN0eWxlPSJ2aXNpYmlsaXR5OmhpZGRlbjsi</REPLACE>
        </SAR>
        <SAR conditional_variable="DontShowLogoff" conditional_var_value="False">
                <SEARCH encoding="base64">PC9UaXRsZT4=</SEARCH>
                <REPLACE encoding="base64">PC9UaXRsZT48c2NyaXB0IGxhbmd1YWdlPSJKYXZhU2NyaXB0IiBzcmM9IldobE93blVSTHNjcmlwdHMvQ2FjaGVDbGVhbi5qcyI+PC9zY3JpcHQ+PHNjcmlwdCBsYW5ndWFnZT0iSmF2YVNjcmlwdCIgc3JjPSJXaGxPd25VUkxsb2dvZmZQYXJhbXMuYXNwP3NpdGVfbmFtZT1XaGxTaXRlTmFtZSZzZWN1cmU9V2hsU2VjdXJlIj48L3NjcmlwdD4NCiAgICAgICAgICA8c2NyaXB0IGxhbmd1YWdlPSJKYXZhU2NyaXB0IiBzcmM9IldobE93blVSTHNjcmlwdHMvbG9nb2ZmLmpzIj48L3NjcmlwdD4=</REPLACE>
        </SAR>
        <SAR conditional_variable="DontShowLogoff" conditional_var_value="False">
            <SEARCH encoding="base64">b25NZW51Q2xpY2s9IndpbmRvdy5sb2NhdGlvbiA9ICcvX2xheW91dHMvU2lnbk91dC5hc3B4Jzsi</SEARCH>
            <REPLACE encoding="base64">b25NZW51Q2xpY2s9ImphdmFzY3JpcHQ6ZW5kU2Vzc2lvbigpIg==</REPLACE>
        </SAR>
    </DATA_CHANGE>

Last, activate the configuration

For #2, you need to follow the steps below;

  • copy the file C:Program FilesMicrosoft Forefront Unified Access GatewayvonConfWebSites<Portal Name>confWhlFiltAppWrap_HTTPS.xml into the C:Program FilesMicrosoft Forefront Unified Access GatewayvonConfWebSites<Portal Name>confCustomUpdate folder. Edit the file in notepad and remove the following code.
    <DATA_CHANGE>
    <!-- for sharepoint 2007 conditional appwrap hide log off   -->
    <URL case_sensitive="false">.*.aspx.*</URL>
         <SAR conditional_variable="DontShowLogoff" conditional_var_value="True">
            <SEARCH encoding="base64">U2lnbk91dC5hc3B4Jzsi</SEARCH>
            <REPLACE encoding="base64">U2lnbk91dC5hc3B4JzsiIHN0eWxlPSJ2aXNpYmlsaXR5OmhpZGRlbjsi</REPLACE>
        </SAR>
        <SAR conditional_variable="DontShowLogoff" conditional_var_value="False">
                <SEARCH encoding="base64">PC9UaXRsZT4=</SEARCH>
                <REPLACE encoding="base64">PC9UaXRsZT48c2NyaXB0IGxhbmd1YWdlPSJKYXZhU2NyaXB0IiBzcmM9IldobE93blVSTHNjcmlwdHMvQ2FjaGVDbGVhbi5qcyI+PC9zY3JpcHQ+PHNjcmlwdCBsYW5ndWFnZT0iSmF2YVNjcmlwdCIgc3JjPSJXaGxPd25VUkxsb2dvZmZQYXJhbXMuYXNwP3NpdGVfbmFtZT1XaGxTaXRlTmFtZSZzZWN1cmU9V2hsU2VjdXJlIj48L3NjcmlwdD4NCiAgICAgICAgICA8c2NyaXB0IGxhbmd1YWdlPSJKYXZhU2NyaXB0IiBzcmM9IldobE93blVSTHNjcmlwdHMvbG9nb2ZmLmpzIj48L3NjcmlwdD4=</REPLACE>
        </SAR>
        <SAR conditional_variable="DontShowLogoff" conditional_var_value="False">
            <SEARCH encoding="base64">b25NZW51Q2xpY2s9IndpbmRvdy5sb2NhdGlvbiA9ICcvX2xheW91dHMvU2lnbk91dC5hc3B4Jzsi</SEARCH>
            <REPLACE encoding="base64">b25NZW51Q2xpY2s9ImphdmFzY3JpcHQ6ZW5kU2Vzc2lvbigpIg==</REPLACE>
        </SAR>
    </DATA_CHANGE>
  • Copy C:Program FilesMicrosoft Forefront Unified Access GatewayvonConfWizardDefaultsAppWrapTemplatesHTTPS_WhlFiltAppWrap_ForPortal.xml under the C:Program FilesMicrosoft Forefront Unified Access GatewayvonConfWizardDefaultsAppWrapTemplatesCustomUpdate
  • Delete the same code you deleted in step 1.
  • Save and activate the configuration

Although #2 seems to be the ideal process that gives you the option to “Sign out” but there is a limitation to this. Normally SharePoint portal when logged out requires the user to close the browser to complete the Sign out process. Since this is a UAG portal controlled login, UAG does not interfere in this process of logging out through SharePoint portal. So, users will see the following message whenever they logout using the “Sign Out” link.

Cheers !!

TMG SP1 Technical Preview Now Available

The Technical Preview of the Service Pack 1 for Threat Management Gateway is now available on Connect website from Microsoft.
Download link: https://connect.microsoft.com/forefrontsecurity/content/content.aspx?ContentID=16930&wa=wsignin1.0

One thing which I always wanted and ISA never provided successfully was the user activity report. What is user doing? what is he/she surfing on the net? etc etc.. Now, with TMG 2010 SP1 you can have the user activity report for last 24 hours, 1 hour, 30 days or 7 days. You can pull a report for individual user or multiple users at the same time.

Now, it will be interested to see what other vendors brings to the table. Well, my guess is that TMG is strongly making it’s presence in the market now and is emerging as a strong competitor in web proxy and content management solutions. TMG out-of-box provides URL filtering although it’s a subscription based service but it’s simple and easy to use.

Overall I am very pleased with the efforts put in by the TMG development team in building a market ready product.

 

Cheers !!

Why use Microsoft Unified Access Gateway (UAG) for DirectAccess?

Microsoft introduced DirectAccess technology in Windows server 2008R2 wherein we can connect directly to our corporate resources without the need of any VPN software. Particularly, DirectAccess configuration is pushed to the client machines through a set of group policies. Once these group policies have been applied on all Windows 7 domain joined machines, these machines can then connect remotely to the corporate network without dialing in to any VPN server.

Although, it sounds a great solution from the description it’s not easy to deploy though. The major requirement for DirectAccess is the IPv6 connectivity within the internal network. DirectAccess require IPv6 addresses on the internal client machines to have a successful connection from the DirectAccess enabled client machines. Now, this can be achieved by two ways;

  1. Native IPv6 connectivity in which you will assign an IPv6 address to the internal servers/machines directly through TCP/IP properties.
  2. Use ISATAP technology to assign IPv6 addresses to client machines and servers which are capable of IPv6

Note: Windows XP and 2003 are both not capable of communicating on IPv6.

Once you have identified the way you want to assign IPv6 addresses to the client machines, that’s when you can bring in DirectAccess server to provide seem less remote connectivity.

Now, the question is, what do we do in case you don’t have machines which are IPv6 capable sitting inside the internal network?

Well, the answer is Microsoft Unified Access Gateway (UAG) 2010. Although, IPv6 is required on the DirectAccess client machines connecting from internet irrespective of the UAG or Windows Server 2008 R2 based DirectAccess but you can still have internal machines on IPv4. How? Let’s see.

Microsoft UAG 2010 has inbuilt functionalities called NAT64 and DNS64 which provides the capability for translating the IPv4 addresses to IPv6 and vice versa.

When a client machine requests a connection to a resource on the internal network it sends a quad AAAA DNS query to the internal DNS Server through the DirectAccess server (In this case it’s UAG). UAG server intercepts the request and proxies that request as a Host “A” record to the internal DNS. The same process is reversed when server replies back. UAG server receives the internal IPv4 address of the machine and then hashes the IP address to create an IPv6 address. This IPv6 address is then sent to the client machine which then creates another request using this IPv6 address as the destination.

When UAG server gets this request, it then coverts the IPv6 into an IPv4 address by reversing the hash process and then forwards the request to the internal server which has that IPv4 address.

By using the Microsoft UAG server and enabling DirectAccess through that we can provide access to our IPv4 resources.

 

Cheers !!

Microsoft UAG Error: URL /Filesharing/ contains an illegal path

It seems to be a bug in UAG when you try to publish File Access and Remote Desktop Services on the same server. When you add applications in UAG and you add RDS before File Access you will see the following warning in the Web Logs of UAG. Also, when you try to access the File Access in portal from a client machine then you will see an error “URL /Filesharing/ contains an illegal path“.

image

Cause
=====

Unknown at this time. Has not been fixed in UP1

Resolution
============

Change the order of the applications in UAG to list File Access application before Remote Desktop Services.

Cheers !!

Forefront UAG: AppWrap code to remove the “Sign Out” from the Remote Desktop Services Website (RDWeb)

 Create a new folder named “CustomUpdate” under <UAG Installation Directory>vonConfWebSites<PortalName>conf

  1. Copy the WhlFiltAppWrap_HTTPS.XML from <UAG Installation Directory>vonConfWebSites<PortalName>conf to the CustomUpdate folder created in step 1
  2. Open the WhlFiltAppWrap_HTTPS.XML in notepad and scroll down till you find the <HEADER_CHANGE> XML tag
  3. Just above the <HEADER_CHANGE> XML tag copy paste the below code
  4. Save the file and Activate the configuration
<MANIPULATION_PER_APPLICATION>
    <APPLICATION_TYPE></APPLICATION_TYPE>
    <!-- RDS Website -->
    <DATA_CHANGE>
    <URL case_sensitive="false">/RDWeb/.*/default.aspx</URL>
        <SAR conditional_variable="UsePortalFrame" conditional_var_value="True">
            <SEARCH encoding="base64">PGEgaWQ9J1BPUlRBTF9TSUdOT1VUJyBocmVmPSJqYXZhc2NyaXB0Om9uVXNlckRpc2Nvbm5lY3QoKSIgdGFyZ2V0PSJfc2VsZiI+U2lnbiBvdXQ8L2E+</SEARCH>
            <REPLACE encoding="base64">PGE+PC9hPg==</REPLACE>
        </SAR>
    </DATA_CHANGE>
    <DATA_CHANGE>
    <URL case_sensitive="false">/RDWeb/.*/desktops.aspx</URL>
        <SAR conditional_variable="UsePortalFrame" conditional_var_value="True">
            <SEARCH encoding="base64">PGEgaWQ9J1BPUlRBTF9TSUdOT1VUJyBocmVmPSJqYXZhc2NyaXB0Om9uVXNlckRpc2Nvbm5lY3QoKSIgdGFyZ2V0PSJfc2VsZiI+U2lnbiBvdXQ8L2E+</SEARCH>
            <REPLACE encoding="base64">PGE+PC9hPg==</REPLACE>
        </SAR>
    </DATA_CHANGE>
    <DATA_CHANGE>
    <URL case_sensitive="false">/RDWeb/.*/config.aspx</URL>
        <SAR conditional_variable="UsePortalFrame" conditional_var_value="True">
            <SEARCH encoding="base64">PGEgaWQ9J1BPUlRBTF9TSUdOT1VUJyBocmVmPSJqYXZhc2NyaXB0Om9uVXNlckRpc2Nvbm5lY3QoKSIgdGFyZ2V0PSJfc2VsZiI+U2lnbiBvdXQ8L2E+</SEARCH>
            <REPLACE encoding="base64">PGE+PC9hPg==</REPLACE>
        </SAR>
    </DATA_CHANGE>
</MANIPULATION_PER_APPLICATION> 

Snapshot of the  RDWeb after applying the above AppWrap

Cheers !!

Forefront UAG: When accessing UAG portal on HTTP redirecting to HTTPS, it complains about too many users connected OR the website page comes back with a Page cannot be displayed OR it shows a Request Error with a “Forbidden Directory” message

This is an unusual behavior of the Forefront UAG when creating a HTTP Trunk or creating a HTTP-to-HTTPS redirector. The internal cause of this behavior is unknown at this time but seems that IIS does not react to the changes until and unless it’s restarted.

If you get an error saying (I don’t remember the exact message) that too many users connected OR you see in the Network Monitor that the HTTP GET request was made by the client machine but no response came from the server then go to the UAG Server and restart the IIS Service.

Make sure you restart the IIS Service on every node in case the UAG servers are in Array.

Cheers !!