Note from Fred ESNOUF : This article has been written by Hicham Bardawil (Hicham.Bardawil@vNext.fr) UAG expert working for Vnext. I am just hosting his article since he used some of my previous posts to finalize his configuration. Congratulations Hicham !

You’ve seen in previous articles how to implement Web SSO through UAG for applications that do not have an “Optimizer” by default (reminder : an optimizer is for a Web application : 1) all the “application layer” firewall rules 2) WebSSo parameters 3) “on the fly” rewriting if needed.

In this post, I will explain the methodology I used to publish Microsoft SCOM, and activate webSSO.

 

Publish SCOM in UAG

Below is the SCOM login page.

scom1

First of all, we will publish SCOM in UAG. To do so, we will use the “Other Web Application (application specific hostname)” template the UAG GUI.

scom2

Follow the steps in the wizard and note carefully the «Application type » you specify (we will use it in a configuration file used for Web SSO).

scom3

On the authentication Tab, activate the single sign-on checkbox, select an authentication server (the one that contains the login/pwd you want to inject in the SCOM form) and choose “HTML form” as the authentication method.

scom4

Once the configuration is done and activated via UAG console, the SCOM form login website will be accessible either via the Portal URL, or directly via it’s own URL. At this stage, you will have to login manually since we have not yet explained to UAG how to do SSO with SCOM. Let’s do it now.

How to describe a FORM in UAG web SSO engine

Since there is no “optimizer” for SCOM, we need to explain UAG how to provide webSSO. To do so, we need to create a Custom XML (named FormLogin) file that will describe the SCOM form to the UAG SSO engine. Once described, the engine will know in “which repository” it has to take the login/password (publishing wizard), how to detect this form and how to inject WebSSO magic.

Your FormLogin.xml has to to be copied in this directory  « C:\Program Files\Microsoft Forefront Unified Access Gateway\von\Conf\WizardDefaults\FormLogin\CustomUpdate\ »

Below is the custom formlogin.xml file that was created for SCOM (I advise to copy one from the samples, put in in the right directory, and modify it. Copy and paste from a blog post can introduce some crazy characters). in Bold the parameters that are important :

 

<WHLFILTFORMLOGIN ver="1.0">

 

<APPLICATION>

<APPLICATION_TYPE>ScomWI</APPLICATION_TYPE>

 

<USAGE description="form_login">

 

<PRIMARY_HOST_URL>.*login\.aspx.*</PRIMARY_HOST_URL>

 

<SCRIPT_NAME source="file">Autosubmit_Scom.js</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>

 

<LOGIN_FORM>

 

<NAME>form1</NAME>

 

<METHOD>POST</METHOD>

 

<CONTROL handling="real_value">

 

<TYPE>USER_NAME</TYPE>

 

<NAME>Login1$UserName</NAME>

 

<DEF_VALUE>siteuser</DEF_VALUE>

 

</CONTROL>

 

<CONTROL handling="real_value">

 

<TYPE>PASSWORD</TYPE>

 

<NAME>Login1$Password</NAME>

 

<DEF_VALUE>sitepass</DEF_VALUE>

 

</CONTROL>

 

<CONTROL handling="real_value">

 

<TYPE>submit</TYPE>

 

<NAME>Login1$LoginButton</NAME>

 

<DEF_VALUE>Log In</DEF_VALUE>

 

</CONTROL>

 

</LOGIN_FORM>

 

</USAGE>

 

</APPLICATION>

 

</WHLFILTFORMLOGIN>

 

As you can see there are some important sections in this XML :

<APPLICATION_TYPE> must be the same as the application type entered during the Publishing phase, via the wizard.

so <PRIMARY_HOST_URL> must be equal to URL to reach the form. In my case the URL is https://scom.xxx.fr/login.aspx?ReturnUrl=%2fdefault.aspx, through REGEX syntax the address can be reduced to .*login\.aspx.*.

<SCRIPT_NAME source="file">Autosubmit_Scom.js</SCRIPT_NAME> is the JavaScript that will be added to the page. Once arrived on the client machine, IE will auto execute this script, and it will simulate the “click” on the Login button (see below in this post for more details.).

 

<NAME>form1</NAME> must be equal to the form’s name

 

<TYPE>USER_NAME</TYPE> and <TYPE>PASSWORD</TYPE> contains the name of the username and password field.

 

Where do we get these values ?

 

Reading the XML, we can understand easily “why” we need to provide these value to UAG Web SSO engine. To get the value, edit the HTML generated by the login form (in IE, View, source). These parameters can be found by browsing the web page’s source code for the following element:

Here is the FORM (Form1)name :

<form name="form1" method="post" action="login.aspx?ReturnUrl=%2fdefault.aspx" onsubmit="BLOCKED SCRIPTreturn WebForm_OnSubmit();" id="form1">

 

Here is the “username” field (Login1$UserName :

<td align="right"><label for="Login1_UserName">Domain\User Name :</label></td><td><input name="Login1$UserName" type="text"

Here is the “password” field :

<td align="right"><label for="Login1_Password">Password :</label></td><td><input name="Login1$Password" type="password"

 

Here is the “button” field :

 

This parameter can be found by browsing the web page’s source code for the following element:

<<td align="right" colspan="2"><input type="submit" name="Login1$LoginButton" value="Log In"

 

 

At this level we have explained to UAG when (application type, URL, Form name) and how (fields names) to do webSSO.

Once those parameters filled correctly, the Autosubmit_Scom.js script must be edited and copied to the correct location. This script will simulate the “click” on the page to provide a full WebSSO experience.

The default Autosubmit.js provided by UAG usually works great. If not, which is the case for SCOM, next section will give you more details.

How to simulate the click to automatically connect the user

The “click” is in fact generated by a script injected by UAG SSO engine in the HTML code, and linked to the LOAD event of the form. So when the page arrives on the client side, automatically the browser execute this script, and “click” the Login button for the user. Most of the time, the default script works fine, but depending on the structure of the FORM, we may have to modify it. This is the case for SCOM.

 

Take the sample located in the following directory

 « C:\Program Files\Microsoft Forefront Unified Access Gateway\von\Conf\WizardDefaults\FormLogin\ »

It must be copied to « C:\Program Files\Microsoft Forefront Unified Access Gateway\von\Conf\WebSites\extranet\conf »  (Extranet is the name of my trunk) and renamed as autosubmit_Scom.js as specified in the formlogin file. Modify this script to interact with the page appropriately. Here are a few examples :

Default Example1 Example2

function FormLoginSubmit()

{  

            document.forms[1].submit();

            return false;

}

function FormLoginSubmit()

{  

            logon();

 

           return false;

}

 

function FormLoginSubmit()

{  

 

 document.form1.Login1$LoginButton.click();

 

            return false;

}

In the case of SCOM, example 2 worked well for me.

 

After activating the UAG configuration, if you click the application on the portal, UAG will :

* See the login page because the Application Type is ok, and the URL described in the XML is correct

* Detect that the page is the one it has to handle, because the “FORM” name is good

* Know where to inject the login name and password, from which repository (GUI).

* Inject the “click” script

… so for the user, “UAG will fill out the form and provide SSO”

 

Troubleshooting

This section contains several techniques that could help you during a debug phase. Ususally when you play for the first time with this “deep” part of UAG, it does not work. Best way to fully understand is then go in debug.

The tools to use in this case are httpwatch or fiddler. They are capable of capturing HTTP(s) traffic, so you can see “inside” the data flow.

Problem 1 – The XML file is not well structured.

Rule of a thumb : all configuration files in UAG use XML files. If for any reason the structure of the XML is not correct, UAG will not use it during activation phase (but will not raise errors !!). So good advice : always double click an XML file before activation. IE will start, XML parser will read the file, and will raise an alert if not good (you will save hours). If no error, you can activate the configuration.

Problem 2 -      The SCOM page is not filled out at all

In this case, the form is displayed on the client machine but nothing happens. Step 1 of the debug will be to make sure that the XML you created is activated (so check if XML structure is ok

Step 2 is to validate the data in this XML. Capture the traffic with tools and check each parameter :

1) the application type has to be the same in the UAG GUI and in the XML

2) the URL of the FORM has to be the good one. A very common mistake is to provide a wrong URL in the “portal link Tab” of the application, “Application URL” field. By wrong I mean that it will work (you see the form) but UAG can’t detect it as a page it is supposed to handle. For SCOM we said ” .*login\.aspx.*”. If in this url field you say “http://scom.internalnetwork.com”, even if the default page in SCOM is “login.aspx”, the HTPT traffic will not contain that “login.aspx”. So SSO will fail. So good parameter in the URL has to be “http://scom.internalnetwork.com/default.aspx”.

3) the name of the FORM has to be ok

4) login/password fields have to be ok too

=> I advise “copy and paste” method (rather that typing it) which prevent errors.

In this capture below, you can see the “POST” that is sending the authentication values to the application.

scom5

Of course, also make sure that you have activated SSO for this application.

Once you have adapted your configuration, activate the configuration, wait for activation monitor to say “activate” (be patient) and test again.

 

Problem 3 -    The Page is filled out, but no “click”

In this case, this means that the UAG default script injected in the page to create that “click” do not work (we assume that when you capture the traffic, you see the default script in the page, which means that UAG SSO engine did his job. Screenshot below shows that injection in the page).

scom6

So if the script is there, this means that the  “logic” in the JS code is not compatible with the structure of the page.

Usually with HTML page we don’t have problems, default UAG script works fine. If it is not the case you need to check the structure on the page, and adapt the script accordingly.

Conclusion

Even if we don’t have optimizers for all applications, as you can see it is very easy with UAG to publish an application (so take advantage of all the features, especially Authentication and Security), and configure it to provide Web SSO. The First time you configure an XML you feel a little bit lost, but then the logic is crystal clear. If you have any questions, feel free to ask.

Hicham Bardawil

Hicham.Bardawil@vNext.fr