Creating Custom Endpoint Policy in Forefront Unified Access Gateway

Recently i was trying to create a custom endpoint policy and was trying to find some online resources. I realized that this topic has not been covered in much detail online or within the product documentation. So, let’s see what we can gather here.

Endpoint policies are required to determine that the Endpoint client machine meets the minimum set of requirements configured by the administrator. There are so many out-of-box Endpoint policies which you may use to determine which clients should and which shouldn’t connect to your portal. You can also use these Endpoint policies to restrict access to the applications published through the UAG portal.

You may create your own VBScripts to determine the state of the machine and then use it for restricting or allowing access to the portal and the applications published through UAG. That’s what we will see below.

To start creating the VBScript, you first need to determine what do you want to check on the client machine and how would you use it. You can do all kinds of crazy things like determining processor Architecture, reading a secret registry key or reading a specific file to make sure it’s a right machine.

Below is an example WMI script which to determine the physical Architecture (x86 or x64) of the machine.

strComputer = "."
Set objWMIService = GetObject("winmgmts:" & "{impersonationLevel=impersonate}!\" & strComputer & "rootcimv2")
Set colSettings = objWMIService.ExecQuery("Select * from Win32_Processor")
For Each objOperatingSystem in colSettings 
        objOperatingSystem.Architecture
Next

To make it work with your scenario, find out which WMI class to gather that information from. Check WMI classes at http://msdn.microsoft.com/en-us/library/aa394084(VS.85).aspx and figure out the property you would like to use.

In the example above I am using the Win32_Processor WMI class to get the value for the property “Architecture”. You may similarly gather the information for any WMI class and supported property of that class.

Your VBScript should something similar to the below example script

You have to use the Results(“YourVariable”) to a Boolean value (True or False) or to a specific value (For data gathering). This is used to create the Endpoint policies.

Once you are done with the script then save it under the /InternalSite/CustomUpdate folder

Then, Copy the Detect.inc file from the /InternalSite/Samples directory and paste it in /InternalSite/Inc/CustomUpdate Folder. Rename the file in the format as <PortalName><0 or 1>Detect.inc

Edit the <PortalName><0 or 1>Detect.inc file and replace the YourFilename.vbs to your actual VBScript file you created above. The file after editing will look as below

<%
g_ScriptList(“/InternalSite/CustomUpdate/<YourScript.vbs>”) = true
%>

Copy PolicyTemplate.xml and PolicyDefinations.xml from /von/Conf to von/conf/CustomUpdate/

Edit the PolicyTemplate.xml as mentioned at http://www.ssl-vpn.de/wiki/Developing%20your%20own%20detection%20scripts.ashx
Edit the PolicyDefinations.xml as shown in http://blogs.technet.com/blogfiles/amolrb/WindowsLiveWriter/CreatingCustomendpointdetectionpolicyand_E17C/image_12.png

Make the necessary changes in the files as shown in http://blogs.technet.com/amolrb/archive/2009/07/03/creating-custom-endpoint-detection-policy-and-script-for-iag.aspx

At this time you should be able to gather the information in the Endpoint Parameters. We are yet check the endpoint based on to this policy

** Check the "Test" variable which is being set by the script shown above**


Now, you are ready to use this endpoint policy for checking the client machines

The script could be a simple one as shown above or you may have more complex scripts as well depending on what you would like to do.

Cheers !!

UAG Team Blog: DirectAccess Resources

Configuring DHCP Relay on ISA Server and Allow VPN connections

I was trying to configure DHCP Relay on ISA Server but wasn’t able to figure out the correct rules. While searching on the internet I came across an article http://www.isaserver.org/tutorials/2004dhcprelay.html which explains the process. I created the two rules mentioned in the article but it dint work.
 
Then after a while I was able to get it working with the set of rules shown below.
 
 
Where, DHCP Server is the actual DHCP server in my internal network. I created a computer object with the IP address of the DHCP Server.
 
Create a custom protocol as below
 
Name: DHCP Relay
Protocol: UDP
Direction: Send Recieve
Port: 67
 
Restart the RRAS service after applying the changes in ISA.
 
Cheers !!!
 

Forefront UAG 2010: Creating Single Sign On for the Remote Desktop Web Access (RDWEB)

I was working with the Forefront UAG 2010 lately and saw that it doesn’t do single sign on for the RDWEB website. I tried to find the Auto Login information but dint find it. So, I thought let’s create it. It’s same as usual what you will do with other custom form authentications. It’s just that you don’t have to look for fields, you can just copy paste in from this blog post. I hope that will help.

1. Publish the RDWEB as generic web application in Forefront UAG 2010 using the “Web > Other Web Application (Portal Hostname)”
2. Then, go to C:Program FilesMicrosoft Forefront Unified Access GatewayvonConfWizardDefaultsFormLogin and copy the FormLoginCustom.xml to C:Program FilesMicrosoft Forefront Unified Access GatewayvonConfWizardDefaultsFormLoginCustomUpdate. If the CustomUpdate folder does not exist, create a new folder.
3. Rename the FormLoginCustom.xml to FormLogin.xml
4. Delete everything from within the file and copy paste the following text.

<WHLFILTFORMLOGIN ver="1.0">
    <APPLICATION>
        <APPLICATION_TYPE>RDWEB</APPLICATION_TYPE>
        <USAGE description="form_login">
       <PRIMARY_HOST_URL4><![CDATA[.*/RDWeb/Pages/en-US/login.aspx.*]]></PRIMARY_HOST_URL>
        <SCRIPT_NAME source="data_definition">FormLoginSubmitStandard</SCRIPT_NAME>
        <USER_AGENT>
            <AGENT_TYPE search="group">all_supported</AGENT_TYPE>
            <POLICY>multiplatform</POLICY>
            <SCRIPT_NAME source="data_definition">FormLoginHandler</SCRIPT_NAME>
        </USER_AGENT>
        <MULTIPLE_LOGIN>true</MULTIPLE_LOGIN>
        <LOGIN_FORM>
            <NAME></NAME>
            <METHOD>POST</METHOD>
            <CONTROL handling="dummy_value">
                <TYPE>USER_NAME</TYPE>
                <NAME>DomainUserName</NAME>
                <DEF_VALUE>sitedomainsiteuser</DEF_VALUE>

            </CONTROL>
            <CONTROL handling="dummy_value">
                <TYPE>PASSWORD</TYPE>
                <NAME>UserPass</NAME>
                <DEF_VALUE>sitepass</DEF_VALUE>

            </CONTROL>
        </LOGIN_FORM>
        </USAGE>
    </APPLICATION>
</WHLFILTFORMLOGIN>

5. Save the file
6. Activate the UAG Configuration from within the UAG console.

 

Additional Resources:

Publishing Desktop Connections
http://technet.microsoft.com/en-us/library/ee441340.aspx 

Cheers !!!

Forefront UAG: Certificate Error when using it with Remote Desktop Gateway (RDWEB)

 
Problem:
 
The below error occurs when you configure the Forefront UAG to publish the Remote Destop (Predefined), Remote Desktop (user defined) OR RemoteApp applications.
 

 
 
Cause:
 
Forefront UAG installs the RD Gateway on the Forefront UAG server as well. The traffic is tunnelled through the RD Gateway installed on the Forefront UAG server to the back-end RD Server.
 
Resolution:
On Your UAG Server;
 
1. Go to start > Administrative Tools > Remote Desktop Services > click Remote Desktop Gateway Manager
2. In side the RD Gateway Manager console, right click the server name in the left pane and click properties
3. On the properties page, go to "SSL Certificate" tab
4. Select the appropriate option to either create the certificate or import an existing certificate
 
Note:
There are couple of options for installing the certificates:
  • You may use the same portal certificate on your internal Remote Desktop Gateway server and the Remote Desktop Gateway installed on the Forefront UAG Server
  • You may install different certificates on both. The Certificate Authority used to issue the certificate for your internal Remote Desktop Gateway server should be trusted by the Forefront UAG Server. And, The Certificate Authority used to issue the certificate for your UAG server (External Certificate) should be trusted by the client machines connecting from outside. Internal certificate can be issued by the internal Root CA.
 
5. Mostly with UAG you will use the certificate for your portal in which you will be publishing the applications
 
The snapshots below shows you the properties page and the certificate dialog box to select certificates from.
 

 
 

6. Click Ok. It will prompt you to restart the services. click Ok
7. You may find some cases where the services are not started and users will get an error complaining about RD Gateway not available. On the UAG Server go to Services.msc and then find the Remote Desktop Gateway service. If the service is stopped, restart it.

Cheers !!!

 

Microsoft Deployment Toolkit Error: No physical adapters present, cannot deploy over wireless

I was helping a customer in deploying the Microsoft Deployment Toolkit 2010 to capture and deploy Windows 7 x64 reference Image. We soon ran into issues where the capture fails immediately after the LTIApply.wsf script tries to apply the WinPE.

On checking the BDD.log file i saw that it is complaining about no network adapters in the machine

<![LOG[No physical adapters present, cannot deploy over wireless]LOG]!><time="20:46:03.000+000" date="01-21-2010" component="Wizard" context="" type="3" thread="" file="Wizard">

And, when I saw the network sharing center in Windows 7 machine, it was blank with no network adapters. So, we started investigating this issue. We found that as per the article http://technet.microsoft.com/en-us/library/dd744512(WS.10).aspx#SysprepProcess it says that until and unless you have <PersistentAllDeviceInstalls></PersistentAllDeviceInstalls> set to true, By default, these device drivers are removed from the system when you generalize the system. So, the sysprep was doing the right thing.

We then again dig deep into the BDD.log file and found something suspicious

<![LOG[LTI applying Windows PE]LOG]!><time="20:46:00.000+000" date="01-21-2010" component="LTIApply" context="" type="1" thread="" file="LTIApply">
<![LOG[Will boot into Windows PE architecture x86 to match OS being deployed.]LOG]!><time="20:46:00.000+000" date="01-21-2010" component="LTIApply" context="" type="1" thread="" file="LTIApply">
<![LOG[Copying \192.168.0.10deployment$BootLiteTouchPE_x86.wim to E:sourcesboot.wim]LOG]!><time="20:46:00.000+000" date="01-21-2010" component="LTIApply" context="" type="1" thread="" file="LTIApply">
<![LOG[ZTI ERROR – Unhandled error returned by LTIApply:  (-2147024784  0x80070070)]LOG]!><time="20:46:01.000+000" date="01-21-2010" component="LTIApply" context="" type="3" thread="" file="LTIApply">
<![LOG[Litetouch deployment failed, Return Code = -2147467259  0x80004005]LOG]!><time="20:46:01.000+000" date="01-21-2010" component="LiteTouch" context="" type="3" thread="" file="LiteTouch">

On, resolving the HEX error code 0x80070070 I got 112. using the NET HELPMSG command, we got the following description:

I checked the available space on C drive and there was ample space in it. I dint notice first that it was actually trying to copy the WIM image from the deployment share to the “E” Drive. As shown in the above logs "Copying \192.168.0.10deployment$BootLiteTouchPE_x86.wim to E:sourcesboot.wim"

When I checked the partitions, I found the following

“E” drive was the “System Reserved” partition which was of 100MB and the WIM file was 163MB so it was here were things were going wrong.

So, what really happened? 

MDT has two Task Sequence variables DestinationDisk and DestinationPartition. They have a default value of 0 and 1 respectively. Which means that the System partition will be the partition 1 and the variable “DestinationLogicalDrive” was being set to “E” as shown in the below log from BDD.log file.

<![LOG[Property DestinationLogicalDrive is now = E:]LOG]!><time="20:44:12.000+000" date="01-21-2010" component="ZTIConfigure" context="" type="1" thread="" file="ZTIConfigure">

** This is applicable if you see the System Reserved partition under “Computer”

~~ Workaround ~~

To set the right DestinationLogicalDrive value you need to define the correct values for DestinationDisk and DestinationPartition. So, we made some modifications to the Capture Task Sequence we created.

1. First, Add two "Set Task Sequence Variables" tasks. Name it as shown below.

2. Next, select the "Set DestinationDisk" task and on the right side in the "Task Sequence Variable" write "DestinationDisk" and in value type "0" as shown below

3. Next, select the "Set DestinationPartition" task and on the right side in the "Task Sequence Variable" write "DestinationPartition" and in value type "2" as shown below.

You may also set the values for the DestinationDisk and DestinationPartition in the BootStrap.ini or the CustomSettings.ini file.

Cheers !!!

UAG SSTP VPN ends immediately when connecting

I recently was trying my hands on Forefront UAG SSTP VPN configuration and followed the article http://blogs.technet.com/edgeaccessblog/archive/2009/07/05/adding-the-sstp-magic-to-the-uag-charm.aspx to configure SSTP on my UAG Server. My Forefront UAG server is also configured as DirectAccess Server. Check the TechNet article http://technet.microsoft.com/en-us/library/ee522953.aspx for more information on the supported scenarios when you have DirectAccess enabled on the UAG server. SSTP is the only VPN connectivity recommended and supported when you have UAG Server configured for DirectAccess connectivity.

My Configuration:

Forefront UAG Server 2010 RTM
Windows 7 RTM Client Machine
Configured the SSTP on the Forefront UAG Server for SSL VPN
CRL Distribution Point: http://uag.contoso.com/crld/ContosoRootCA-New.crl
Delta CRL download Point: CRL Distribution Point: http://uag.contoso.com/crld/ContosoRootCA-New+.crl

The problem I went into was that when I tried to connect using the Application trunk for Remote Access Network, I got the following bubble immediately after the VPN connection tried to connect.

And, looking into the Activity window I could see the SSTP connection as disconnected

So, what really happened?

To track the problem first I started the CAPI2 logging as described in the TechNet article http://technet.microsoft.com/en-us/library/cc749296(WS.10).aspx and then, I tried to connect again to generate some log events in the event viewer.

I saw three error logs straight away when I tried connecting to the SSTP VPN connector in the Portal Trunk

On further investigating, I found nothing suspicious in the CAPI2 events. Although, I admit that I am not an expert in reading the CAPI2 log events.

Then, I started a Microsoft Network Monitor to see what’s going on. I tried connecting to the SSTP connection and That’s when I saw in traces that the client machine is able to resolve the Hostname and is trying to connect to the /crld/ContosoRootCA-New+.crl (Delta CRL). And, in the immediate packet i saw it was getting a HTTP error 404 which means “File Not Found”. I knew the file was there because I can see it in the same folder and also there was no permission issues because I was able to download the Certificate CRL from the same location.

Then, doing a little Bing search, I landed on http://social.technet.microsoft.com/Forums/en-US/windowsserver2008r2webtechnologies/thread/83be4ffb-439e-4d3f-9377-0d23e4307d86 and found the resolution to my problem.

So, particularly the URL was being captured in the Normalization feature of the IIS URLScan which prevents URLs with double-encoded requests. Once I changed the “AllowDoubleEscaping” property to “True” as shown in below snapshots, SSTP worked like a Charm 🙂

For information check http://learn.iis.net/page.aspx/143/use-request-filtering/ 

Change the "False" to "True" for "AllowDoubleEscaping"

Now, when i took traces it showed me the status 200 OK.

So, It wasn’t the UAG this time but it was the IIS 7.0.

Cheers !!

Using the Forefront UAG Server as the RADIUS Server to Authenticate the Portal Trunk Users

Forefront UAG Server installs the Network Policy Server (Earlier known as IAS/RADIUS Server) role while running the UAG setup. It uses it’s RRAS functionality to route the traffic. By default the RRAS functionality is only used and the RADIUS functionality is optional. Though, you may configure it to be used to authenticate users logging onto the Forefront UAG portal, it’s better and easier to place the RADIUS server behind the UAG Server.

it took me a while to figure out the right configuration to make it work when you want to use the Network Policy Server (NPS) installed on the Forefront UAG server to authenticate the users. Below are the steps to configure the same.

1. Forefront UAG installs the NPS server be default so you don’t have to install it specifically
2. Open the Forefront UAG Admin console and click on the portal you which make modifications to. Then, click on the “Configure” button to change the authentication scheme.

image
3. Go to Authentication tab and under “Select Authentication Servers” click Add if you don’t have the RADIUS Authentication server already configured. Assuming you don’t, click Add on the dialog box which says ‘”Authentication and Authorization servers”.

4.  From the “Server Type” select RADIUS

5. Provide a Server Name to identify this Authentication Mechanism. This is not the actual server name to which you want to authenticate the users against.

6. Under the “IP Address/Host” give the IP or the Host name of the RADIUS server you want to authenticate against. Enter the internal IP address of the UAG Server. Do not use the name as "Localhost" otherwise you might see an error.

7. Change the Port number to 1812, this is the default port number used by the NPS Server. Enter a complex Shared Secret key which will be used to create connection to the RADIUS Server.

8. Check the check box saying “Support Challenge-Response Mode”

9. Click OK to close the dialog box. Then, on the ”Authentication and Authorization servers” select the RADIUS Server repository you created in step 4 and click Select

10. Click OK to close the “Advanced Truck Configuration”

11. Open the Threat Management Gateway console and go to the Firewall Policy Rules. On the extreme right hand side, in the side bar, under the Tasks tab click “Edit System Policy”

12. On the “System Policy Editor” Select RADIUS from the left and then on the right hand side select the “To” tab

13. Click Add under the To tab and expand “Networks”. Select “Localhost” and click Add.

14. Click Ok to close and save the System Policy Editor

15. Apply the changes in the Threat Management Gateway and close the console

16. Go back to the UAG Admin Console and Activate the Configuration

17. Once the configuration is activated, now we can configure the Network Policy Server under the hood.

18. Open the Network Policy Server Console (Start > Administrative Tools > Network Policy Server)

19. Expand “RADIUS Clients and Servers” and Right Click RADIUS Clients to select “New”

20. Give a Friendly name to recognize the client where from the RADIUS client request will originate

21. Define the same IP address (internal IP of UAG server) which you defined in step number 6 above

22. Enter the same shared secret which you defined in while creating the RADIUS repository in the Forefront UAG. Enter the Shared secret again to confirm and click OK to save and close the dialog box. The configuration will look similar to the image shown below

23. Now, expand the Policies and go to “Connection Request Policies”

24. Open the properties for the default Connection policy named ‘”Use Windows Authentication for Al Users” and make sure under the settings tab > under Authentication, it’s selected as ‘Authenticate requests on this server”

25. Then, right click network policies and click New

26. Enter the policy name as “UAG User Authentication” (You may choose whatever name you feel like). Click next

27. Under “Specify Conditions" click Add and then from the select conditions dialog box, select the condition you want to check. For example select “User Groups” and then select the Active Directory group you want to give access to. You may add multiple conditions depending upon what all things you want to check. Once you are done adding the condition(s) click Next.

28. On the “Specify Access Permission” page make sure you have “Access Granted” selected. Click Next

29. On “Configure Authentication Methods” page select the mode of authentication you want to use and select “Unencrypted Authentication (PAP, SPAP)”. Click Next.

30. Click Next on “Configure Constraints” page and also click next on “Configure Settings” page

31. Click Finish to create the Network Policy

 

Your Forefront UAG Server is ready to use the Network Policy Server (RADIUS) to Authenticate users.

 

Cheers !!!

UAG DA Error: Failed: Cannot create a file when that file already exists

 

I recently came across this error while working on a UAG DirectAccess deployment in a customer test environment. This error is generated when we apply the policy (.PS1) script created by UAG. This error will still come if you try to execute the PS1 script from the PowerShell Command prompt.

The cause is yet to be known. We got to the bottom of the issue with the help of a Software Developer in UAG team. The problem is caused when the script is unable to remove or modify the Da.wfw file which is ceated under the %userprofile%AppDataLocalTemp folder.

 

The workaround of this problem is as below:

1. Create a C:temp folder
2. Export the PS1 script after you make the modification to the UAG DA Configuration
3. Open the script in Notepad. Leave the first three lines (as shown in below image) and enter a cmdlet as $env:temp = c:temp
4. Save the File
5. Open the PowerShell Command Prompt and run the PS1 script you modified in step 3
6. Open the regular command prompt with Administrative privileges and run GPUPDATE /FORCE 
7. Check the GPOs and it should have now been created

** The UAG product team is still investigating the cause of this issue

The above mentioned steps have to be done every time you make a change to the UAG Server configuration.

***Update**********************************

Date: 1/20/2010

From further investigation it seems like that this issues is caused in scenarios where you are using an admin account with a dot (".") in the username like david.smith or firstname.lastname. Workaround is to use an admin account without a dot (".") in the username. Just a FYI, the concerned teams are looking into the matter and will come up with a fix or the documentation soon (no timeframe yet)

*******************************************

Cheers