Forefront Security at myITForum : Forefront UAG

Provide access to your Partner on your UAG Portal with ADFS 2.0

forefrontsecurity — Tue, 16 Aug 2011 07:58:00 GMT

Hi,

As Hicham already demonstrate, you can add Claims Provider Trust on your Federation Server. His example is a Federation with Azure services, but you can do the same with a Federation Partner. Have a look at this article : http://myitforum.com/cs2/blogs/forefrontsecurity/archive/2011/08/05/authenticating-to-your-network-through-your-online-credentials.aspx

Let’s assume that the Labiam Corporation wants to allow access on his UAG Portal to the UAG.com company. Both have a Federation Service.

As you can see on the above schema, we have to create a Claims Provider Trust on the LABIAM Federation Server, and add this Federation Server as a Trusted relying Party on the UAG.com Federation Server.

With the FederationMetadata URL, it is easy to add this provider

Add the necessary claims to the Provider (Windows Account Name, Role …)

On the other side, create the Relying Party Trust, and accept the required claims.

Now, when a user access the UAG Portal, he can choose his repository, and your Partner can access your publications.

Then you can filter the access to specific application, using the Role Type of Claims (developed in a previous article : http://myitforum.com/cs2/blogs/forefrontsecurity/archive/2011/08/16/ad-fs-2-0-and-uag-set-authorization-on-application-in-uag-based-on-claims-roles.aspx)

AD FS is a very great feature. No matter Network considerations, Active Directory Trust Relationships, just use HTTP(s) Exchange to Federate your Business Partners.

Published by Olivier DETILLEUX

AD FS 2.0 and UAG : Set authorization on application in UAG based on Claims Roles

forefrontsecurity — Tue, 16 Aug 2011 07:12:57 GMT

Hi all,

AD FS 2.0 provide transparent authentication on the UAG Portal. Hicham and I have already deal with this great feature. Today, I will show how we can set authorization, based on claims, on the application published through UAG.

With the regular Form Based Authentication against an Active Directory, it is easy to set authorization for an application :

But with an ADFS authentication, how can we query Active Directory groups ? We have to enrich (add additional claims value) the SAML2 ticket with this information.

To achieve that, it is pretty simple.

Let’s assume that only the GGS_Director group can access the web application “Application”, and that James Kirk, as the Enterprise Director, is a member of this Active Directory group :

To add claims value in a SAML ticket, we must ask the Claims Provider to search the value in Active Directory, and send this value to the Relying Party.

On the Claims Provider (Active Directory), add a claims as a Role. In our case : If the user is a member of the GGS_Director group, then a GGS_Director as Role :

For the relying party, just pass through this value

On the UAG Side, specify that only Owner of the GGS_Director Role can access the application.

Now, when James open the portal, he can see the application, as Janice Rand cannot.

Easy, isn’t it ?

But you can say that it is not very convenient, if we must define a rule for each group.

You can also create a custom rule that query the Active Directory to return all groups that a user is directly member of.

Published by Olivier DETILLEUX

Authenticating to your network through your online Credentials

forefrontsecurity — Fri, 05 Aug 2011 13:54:31 GMT

Now off to another subject: ADFS!

Active Directory Federation service v2.0 is the newest trend. Using your Live ID or Google ID to Log into your domain, and access your domain resources is a great new topic that very exciting to work with.

In this example I will show you how to use your Live ID to logon to your UAG server and then access your resources and application that way. I’ll add to that a small ADFS custom Store so that you can see the possibilities lying behind all of that.

What you need to do that:

· UAG 2010 SP1

· ADFS 2.0

· Domain Controller

· Windows Azure Account

· SQL DB

Here is a small architecture design of what you could have:

Let me explain what going on here:

A user wants to access his corporate application; he goes to his UAG portal URL. UAG was configured with ADFS as an authentication method and redirects all users to the ADFS home page which asks the users about what authentication method they want to use.

The user chooses Live ID and authentication to the UAG portal through his Hotmail or MSN account.

Once on the portal he needs to access his resource, some technical stuff go on, ADFS turns the LiveID into something your domain might understand and UAG will map this info to a shadow account and through KCD will log you into your application ! Cool ain’t it?

Now let’s see how to do that:

First you need to have an ADFS server configured

This is how I configured mine but you could have anything here

Next is to configure the ADFS trust with UAG as per my previous article: http://myitforum.com/cs2/blogs/forefrontsecurity/archive/2011/01/07/uag-sp1-transparent-logon-with-adfs-v2.aspx

This first step will get you to the first milestone where you can logon to your UAG with ADFS.

However until now ADFS was configured to get your SAML ticket info from Active Directory only.

Let’s set up the link with other services such as Microsoft’s Live ID authentication.

In ADFS it’s basically a new Claim provider trust that you’re adding:

You then need to tell your claim rule to transmit the information that it gets from the claim provider as let’s say an account name.

Technically this means that the SAML ticket will have the Live ID or Google ID you logon in as an account name attribute.

Now that the link is set between your UAG ADFS and Azure you need to tell the relaying party trust you created between your UAG and your ADFS server to transmit to UAG the information it got form the provider to the relying party (in that case it’s UAG).

That can be done by editing the relying party claim rule and telling it to transmit to UAG an account name, or in that case create a custom rule like I did :

In my ADFS console I had added an SQL Database to which I added each user’s Live ID and mapped it to an Active Directory account (or group).this can of course be any data storage system (Active Directory, Oracle DB).

What we’ll do here is access the relaying party trust we created between ADFS and UAG and write down a custom rule that will give us the AD account to which the live ID is mapped!

Check it out:

Edit your claim rule and create a new Custom claims rule:

This rule will look like that:

c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"] => issue(store = "SQL Attribute Store", types = ("http://schemas.microsoft.com/ws/2008/06/identity/claims/role"), query = "SELECT Role FROM URT WHERE UserName={0}", param = c.Value);

This rule will access the SQL DB store you created and get the role from the table where username = you live ID account.

When you access your UAG portal you will be given the choice to logon with your usual Active Directory ADFS SAML ticket or with your windows Azure à live ID account!

Here is what it looks like (note that this page is completely customizable)

You first get a choice between your usual active directory Provider and now you have a new one: AZURE!

And once you select azure:

Once you enter your Live ID credentials ADFS will process the information and send it to the UAG portal and you will be logged in as anything you set in your rule J in my case the group it retrieved from my sql database !

However this account will allow you to access the portal only and unless your application is claims aware, you will need to map this account to an active directory shadow account to be able to access non claims aware applications.

And now let’s configure your application to turn your SAML information intro a Kerberos Ticket:

Access the application you to give access to and go the authentication TAB:

Choose the KCD option and choose the claim type value to turn into a Kerberos ticket: I chose the name since this is where my info is stored in my SAML ticket.

The last part is to enable KCD on the application:

UAG will create an LDIF file for you through this menu

Apply this file to your UAG computer domain and you will have enabled KCD.

And now you can access you application by using your windows Live ID account !

Very cool!

Cheers

Published by Hicham Bardawil

Want to display a disclaimer when accessing your UAG Portal Home Page ?

forefrontsecurity — Wed, 15 Jun 2011 15:08:10 GMT

This is a request of one of my customer. Can I show a popup containing a disclaimer after the authentication on the UAG Portal ? The answer is yes of course, because you can do whatever you want with UAG . Here is the way I have solved this request.

My idea is to show the popup during the access to the portal HomePage. To add some content to the portal homepage, you need to customize the standard.master file.

Create a dedicated html page (for example disclaimer.html) in the von\PortalHomePage\CustomUpdate directory. This file will contain the text of your disclaimer. “The information contained in this Portal is the property of …”. You can also add an “OK” button or other feature.

Copy the standard.master file from the von\PortalHomePage to the von\PortalHomePage\CustomUpdate directory.
At the end of the file, in the ResizeContent() function, add the following line :

window.open(‘CustomUpdate/disclaimer.html’, ‘disclaimer’)

Don’t forget to add a specific URL Set for your disclaimer.html page :

The regular expression is something like that, depending of your URL :

/(secure)?[^/]+portalhomepage/(customupdate/)?(disclaimer\.html)

Published by Olivier DETILLEUX

UAG and ADFS v2.0 : Transparent authentication inside and outside of your corporate network

forefrontsecurity — Wed, 15 Jun 2011 12:08:33 GMT

My colleague Hicham has already write about the implementation of the transparent logon against the UAG portal using ADFS v2.0 and UAG SP1. Have a look here : http://myitforum.com/cs2/blogs/forefrontsecurity/archive/2011/01/07/uag-sp1-transparent-logon-with-adfs-v2.aspx

This scenario is well when your are inside the intranet. But what happened when you are outside your corporate network ? Does this transparent authentication always work ? And what happens if I try to connect from a non corporate computer (home workstation for example) ?

By design, it is not working. You can only have a transparent logon from the inside of your corporate network, when you are using a corporate workstation. To do that, you have to add the URL of your ADFS logon page to the local intranet security zone.

When you are outside with your workstation, you are experiencing this issue : Nothing happens, but a blank page. If you make a trace with httpWatch, you can see the 401 request, but no response from the web browser.

The way to solve this problem is to change the order of the providers on the LS site of the ADFS server :

To summary :

Add your adfs url to the local intranet zone
Change the order of the providers to set NTLM as first provider

You can now authenticate transparently inside and outside your network with a corporate workstation. During logon from a non corporate workstation, you will be prompted to authenticate.

Published by Olivier DETILLEUX

Global Out-Of-The-Box Rules Troubleshooting

forefrontsecurity — Fri, 08 Apr 2011 08:13:46 GMT

Hi all,

This morning, I wanted to download a pdf file from our website, published with Forefront UAG. The link to the pdf is the following :

http://www.vnext.fr/vapps/ci/Documents/UAG%20Mobile%20Portal/[vNext]%20UAG%20Mobile%20Portal.pdf

I was very disappointing to get an error like “You have attempted to access a restricted. The URL is blocked by on or more Forefront UAG out-of-the-box rules”.

I check the event monitor of the UAG Server, and I see this message :

Global Out-Of-The-Box Rules - The error code is illegal character – ([).

It seems that the “[“ character is not allowed. To fix this issue, you have to add this character to the list of the “legal character” for your website using the URL Inspection tab of the Trunk Configuration panel.

Published by Olivier DETILLEUX

How to use your corporate proxy when you are connected with DirectAccess ?

forefrontsecurity — Tue, 15 Mar 2011 22:53:15 GMT

Most of our customers wants to force their users to use the internal proxy when they are connected to the corporate network through DirectAccess.

Force Tunneling

There are different ways to provide this service. The first one is the “force tunneling” option. With this option activate, all the traffic is routed inside the corporate network (excepted local ip addresses). This UAG SP1, configuring Force Tunneling is very easy, as you can see with the following print screens.

Activate the force tunneling option :

Specify the proxy server :

An that’s it. There are benefits and disadvantage to activate force tunneling. Have a look on this article by the Edge Man (Tom Shinder) : More on DirectAccess Split Tunneling and Force Tunneling

What we can retain is :

When Force Tunneling is enabled, all traffic is sent over the DA client tunnel using the IP-HTTPS protocol, but IP-HTTPS is the slowest transition technology protocol for DA
When Force Tunneling is enabled, user cannot use the “local name resolution” option.

So, I found that this not the right think to do if you only want to route web traffic through the corporate proxy.

Automatic Proxy Configuration Script

Let’s say that your corporate has a Forefront TMG proxy. You can use the automatic proxy configuration script provided by TMG to configure your clients when they are inside the company. This script is automatically created during TMG configuration. The default URL is : http://proxy.vnext.lab:8080/array.dll?Get.Routing.Script.

In order to configure your clients, you use a Group Policy to force the proxy configuration. But when the users come back home, they say that internet isn’t working. The reason is that this script return the static ipv4 address of the proxy to the browser when there is a request. You can that see in the following capture. The ipv4 address of my proxy is 192.168.1.10, and the local ipv4 address of my DA client 192.168.100.101. Of course, the remote ipv4 address is unreachable.

Have a look inside the script. Proxy list is build with the ipv4 address :

A workaround is to create you own proxy.pac. In this script, put the proxy dns name instead of the ipv4 address. Forefront TMG doesn't support ipv6 for the moment. But if the internal network card as an ipv6 address, you can also return this ipv6 address. You can add some conditions (for example the source Ip) to return different addresses. But my advise is : When you are using DirectAccess, always use full qualified domain name. UAG will translate this dns name into an ipv6 address.

With the automatic configuration script you can :

Force the configuration of the proxy with a proxy.pac for DirectAccess users. Whatever they are inside or outside the network, it will be working.
DA Clients are still using teredo or 6to4 when it’s possible
Users can use “local name resolution” if the DA server is down. Therefore, the proxy is unreachable. If the proxy is unreachable, the browser switch to direct connection (no proxy).

The WPAD entry and wpad.dat file

You can also use your DNS to store the address of the proxy as a WPAD entry. Don’t forget to unblock this kind of entry in dns (dnscmd /config /globalqueryblocklist), and remember that you can only request the wpad server which publish the wpad.dat file on tcp port 80. You cannot set the 8080 port for example with the dns entry.

Be careful, have a look inside the wpad.dat file. You can also find some ipv4 entry :

And if you don’t want to force the proxy ?

Let’s assume that you want to force the use of the proxy for the users when they are inside the network, but not when they are outside, connected with DirectAccess. I think that the best way is to use WPAD entry within DHCP.

An other way is to use the WPAD entry in the DNS, and add an exception in the NRPT for wpad.vnext.lab. Thanks to Tom Shinder for this nice idea

Published by Olivier DETILLEUX

UAG, FIM and an encrypted SQL repository–part 2

forefrontsecurity — Wed, 23 Feb 2011 10:39:56 GMT

Hi all,

In the previous post, we have seen how put an encrypted value in an SQL database with FIM Password Management.

We now want to :

Connect to the SQL database with UAG
Secure this connection
Get the encrypted password
Decrypt the password
Add the password to the user session

Securing the SQL connection

It is necessary to encrypt the sql connection, otherwise we can find the password in the TCP frame. Below is the details of a captured frame :

We can clearly view the password of jkirk user.

To secure the connection, the easiest way is :

Create a server certificate for the SQL server
Put the certification authority certificate in the Trusted Root Certification Container of the UAG server
Activate the Secure Only connection

Create the certificate

Create a server certificate with you private certification authority :

type : server authentication
name : sql server name (or fqdn, depends of what you set in the connection string)

Activate the Secure Only connection

On the SQL server, open the SQL Server Configuration Manager. Edit the Protocols Properties, and set the ForceEncryption to Yes

Restart the SQL connection

Now, you can see that all frame are encrypted.

Getting and decrypting the password with UAG

If you don’t have read the previous post (Publishing internet web site through UAG – part 3), here is the actual postpostvalidate.inc file :

' get lead user

set user_vec = getsessionuservec(g_cookie)

for each user in user_vec.uservec

user_name = user.User

Next

' sql connection

' variable initialization

dim oconn, oRecordSet, scommandText, sconnectionstring

scommandText = “select * from <your database/table name> where leaduser=’” & user_name & “’”

' setting up SQL-connection-string

sconnectionString = “Provider=SQLoLEDB; Data Source=<SQL server Name>\<instance>;Initial catalog=<table>;user ID=<sql user>;Password=<user password>’

' Setting up SQL-connection object

set oConn=Server . createobj ect ( ADODB.connection”)

oconn. connectionString=sconnectionString

' open SQL—connection

oconn. Open

' Send the query to SQL

set oRecordSet = Server, createobject (“ADoDB.recordset”)

oRecordSet. open scommandText, oconn

' add secondary session to the user

if not oRecordSet.EOF then

do while not oRecordSet.EOF

addsessionuser g_cookie,oRecordSet(”appLogon”) ,oRecordSet(”appPassword”) ,oRecordSet(”application”)

oRecordSet. moveNext

loop

end if

Previously, the SQL Database was on the UAG Server. We now want to connect to a remote database. The SQL Connection String is not different, just use your remote server name.

In order to decrypt the encrypted password, it is necessary to open the key. Add the following line in the postpostvalidate.inc file :

‘ open the symmetric key

scommandText = “open symmetric key SSN_KEY_01 decryption by certificate UserRepositoryCertificate”

oRecordSet.open sCommandText, oConn

To get and decrypt the password, change the commandText line :

scommandText = “select appLogon, application, convert('varchar, DecryptByKey(appPasswordEncrypt)) appPasswordDecrypted from <your table name> where leaduser=’” & user_name & “’”

And the addsessionuser is now :

addsessionuser g_cookie, oRecordSet(“appLogon”), oRecordSet(“appPasswordDecrypted”), oRecordSet(“application”)

You can make the same changes in the CustomRepository.inc file.

Published by Olivier DETILLEUX

UAG, FIM and an encrypted SQL repository–part 1

forefrontsecurity — Sun, 20 Feb 2011 21:32:31 GMT

Here is the deal :

I have a web application that doesn’t support Active Directory authentication.
I want to use the active directory password to authenticate the user in this application
I want to publish this application with Forefront Unified Access Gateway
I want to secure all the connections and data

Enable security within the SQL repository

Previously, we have seen how :

Synchronize password between Active Directory and SQL with PCNS : Synchronize Active Directory Password to an SQL database with FIM and PCNS
Create a custom SQL repository and use advanced sso mechanism : Publishing internet web site through UAG – part 3

Here is the schema of my infrastructure

We have to :

Encrypt the password in the User Repository
Secure the connection between UAG and the UserRepository Database

Database encryption

I have added a new column in my table to store the encrypted password : appPasswordEncrypt. The format of this column is varbinary(256)

Now, we have to create the keys. For the purpose of this article, I use symmetric key.

create master key encryption by password = ‘password’;

create certificate UserRepositoryCertificate with subject = ‘User Repository Password Encryption Certificate’;

create symmetric key SSN_Key_01 with algorithm = AES_256 encryption by certificate UserRepositoryCertificate;

Symmetric key is created. Have a test :

open symmetric key SSN_Key_01 decryption by certificate UserRepositoryCertificate

Update repositoryTable set appPasswordEncrypt = ENCRYPTEDKEY(Key_GUID(‘SSN_Key_01’), ‘toto’) where OBJECTID = 17;

select * from userRepositoryTable where ObjectID = 17;

And now, let’s try to decrypt the data :

open symmetric key SSN_Key_01 decryption by certificate UserRepositoryCertificate

select *, convert(varchar, DecryptByKey(appPasswordEncrypt)) from userRepositoryTable

Encrypt password within the FIM Password Extension dll

Back to the SQLPwdChange.dll. We have to add the encryption sequence in our code :

First, open the symmetric key :

String SQLEncryptionString = “open symmetric key SSN_Key_01 decryption by certificate UserRepositoryCertificate

Then, encrypt the NewPassword

String SQLString = “UPDATE UserRepositoryTable set appPasswordEncrypt = EncryptedByKey("Key_GUID(‘SSN_Key_01’), ‘” + NewPassword + “’) where ObjectID = ‘” + DN + “’”;

And now, when an user changes his password in Active Directory (for example tmosby) :

Next episode : Encrypt the connection between UAG and the SQL Database, and read the encrypted password.

Published by Olivier DETILLEUX

Why my logo customization is broken after UAG SP1 ?

forefrontsecurity — Wed, 16 Feb 2011 08:56:59 GMT

Forefront UAG 2010 is an amazing software that allow lot of customization. For example you can change the icon of the PortalHomePage, change the banner of the InternalSite and so on.

When you apply hotfix or update, customizations are not deleted. But some times, update includes changes in some configuration files, and your customization is broken. An example is the InternalSite customization.

Before UAG SP1

If you want to change the internalSite design, you have to create your own templace.css file. For example, here is our custom Login Page :

As you can see, I have changed the colors and the banners. To do that :

In internalSite\ccs, copy the template.css in the CustomUpdate folder
In order to change the top header, create your own InternalSite\Images\HeaderTopBG.gif in InternalSite\Images\CustomUpdate
Modify your custom HeaderTopBG.gif file
Edit the custom template.css and change the location of the HeaderTopBG.gif file

.headerTop
{
    BACKGROUND:url("/InternalSite/images/CustomUpdate/HeaderTopBG.gif") center;
    BACKGROUND-REPEAT: no-repeat;
    BACKGROUND-POSITION: top;
    WIDTH: 100%;
    HEIGHT: 125px;
}

You can do that for all the css parts.

After UAG SP1

After the SP1 update, the banner has changed. Is not only a .gif image, but the concatenation of :

A left image : headertopl.gif

A repeated middle image : headertopm.gif

A right image : headertopr.gif

You can see this in the login.asp file

What you see here means that Header images are not defined in the template.css file.

If you look in the inc folder, you can find a logo.inc file. Here is the content of that file :

Red : here are the content of the login.asp. Smells good
Green : Check if a custom logo.inc file exist

So, what you have to do :

Create your own headertopr.gif in the InternalSite\Images\CustomUpdate folder
In the internalSite\inc\CustomUpdate, copy the logo.inc file.
Named the new logo.inc file as usual : <trunkname><issecure 0 / 1>logo.inc
Add your own definition. For example :

<tr >
    <td id="companyTD" width="100%" colspan="3" style="position:relative;">
    <span class="header1 header1pos">
        <%=GetString(2, "Application and Network Access Portal")%>
    </span>
        <table width="100%" cellpadding="0" cellspacing="0">
            <tr>
                <td width="32px">
                    <img src="/InternalSite/images/headertopl.gif" align="absmiddle">
                </td>
                <td style="background-image: url('/InternalSite/images/headertopm.gif'); background-repeat: repeat-x">
                     
                </td>
                <td width="520px" style="background-image: url('/InternalSite/images/CustomUpdate/headertopr.gif');">
                </td>
            </tr>
        </table>
    </td>
</tr>
<tr>
    <td width="100%" colspan="3" style="position:relative;">
    <span   style="position:absolute;margin-left:20px;">
        <%=g_logo_header_text%>
    </span>
        <table width="100%" cellpadding="0" cellspacing="0">
            <tr>
                <td width="30px">
                    <img src="/InternalSite/images/headerbottoml.gif" align="absmiddle">
                </td>
                <td style="background-image: url('/InternalSite/images/headerbottomm.gif'); background-repeat: repeat-x">
                 
                </td>
                <td width="30px" style="background-image: url('/InternalSite/images/headerbottomr.gif');">
                </td>
            </tr>
        </table>
    </td>
</tr>

That’s it !

Published by Olivier DETILLEUX

UAG SP1 Transparent Logon with ADFS V2

forefrontsecurity — Fri, 07 Jan 2011 15:40:49 GMT

Forefront UAG’s Service pack 1 was recently released and with it the ability to automatically login to your UAG portal without the need to manually authenticate. This feature is activated when configuring ADFS V2 as an authentication repository.

Pretty exciting since those two technologies are pretty recent and fun to work with.

I’ll show in this post how to configure ADFS to work with UAG.

Begin by installing and configuring ADFS on a server in you LAN, I used my domain controller and installed the ADFS V2 package I found here: http://www.microsoft.com/downloads/en/details.aspx?FamilyID=118c3588-9070-426a-b655-6cec0a92c10b&displaylang=en

The integrated ADFS Role doesn’t work as well for some reason…

I’ll let you install and do the basic ADFS configuration on you own, it’s pretty simple and there are lots of resources on the net.here’s one that should help :

http://technet.microsoft.com/en-us/library/adfs2-how-to-setup-lab-environment-for-federated-collaboration-07(WS.10).aspx

Once the installation is complete you’ll have a federation service web address of the type https://adfs2_server/FederationMetadata/2007-06/federationmetadata.xml that you will need to use when configuring UAG.

In the ADFS 2.0 MMC go to the certificates folder and import the token encryption into the ADFS Server and the UAG’s local Certificate store.

1- UAG Configuration:

Create a new Trunk

Choose to create a portal trunk and not an active directory federation service as you might be inclined to do. (The latter is for the old ADFS V1).

Set up the trunk as you usually do

When choosing the authentication repository

Select ADFS V2,

The URL of the federation metadata file will be the one you created when installing ADFS V2:

https://adfs2_server/FederationMetadata/2007-06/federationmetadata.xml

click Retrieve Metadata and select Name in as a claim value to be used as a lead value.

Complete the “create trunk wizard” and copy the federation metadata link displayed at the bottom of the page.

Finish and activate the configuration.

To make my configuration easier what I did was copy this file directly to the ADFS Server:

The file is called federationmetadata.xml and is in here:

“C:\Program Files\Microsoft Forefront Unified Access Gateway\von\InternalSite\ADFSv2Sites\extranet\FederationMetadata\2007-06”

2- ADFS configuration

Next step is to configure ADFS to allow active directory users to authenticate to the UAG portal.

In the ADFS V2 console, add a relying party trust:

In the select data source window, either paste the link you got form the UAG trunk creation wizard or point to the federation metadata file you copied to the server as I did below.

Proceed with the default remaining settings and finish.

Finally you need to configure the rule template you would like to apply to your trust.

Basically here you are telling you ADFS which value to get from your active directory users and to send to the UAG portal.

You select to send LDAP attributes as claims.

You choose active directory as your attribute store and select the attributes you would like to put in your outgoing claim.

Once you are done, the transparent authentication should work perfectly.

3- Troubleshooting:

ADFS troubleshooting is not straight forward, you will need to monitor you web traffic using a software such as fiddler or http watch and see what is being transmitted.

Published by Hicham Bardawil

Forefront UAG SP1

forefrontsecurity — Sun, 05 Dec 2010 12:09:04 GMT

Je relaie l’information déjà publiée sur pas mal de blogs concernant la mise à disposition de la version finale du SP1 de Forefront UAG.

Vous trouverez les liens pour le téléchargement du SP1 seul ici : http://www.microsoft.com/downloads/en/details.aspx?FamilyID=980ff09f-2d5e-4299-9218-8b3cab8ef77a

Toutes les nouveautés sont présentées ici : http://technet.microsoft.com/en-us/library/gg295322.aspx

Si comme moi , vous aviez une installation de test avec UAG SP1 RC, vous pouvez installer le SP1 seul “in place”.

Publié par Olivier DETILLEUX

Uninstalling a UAG Update

forefrontsecurity — Wed, 17 Nov 2010 14:48:14 GMT

Ever Wondered how to uninstall a newly installed UAG update ?

here’s the simple way to do that:

go to C:\Program Files\Microsoft Forefront Unified Access Gateway\common\bin and run the "UninstallUagUpdate.exe"

published by Hicham Bardawil

Upgrade your Forefront UAG installation to UAG SP1 RC

forefrontsecurity — Mon, 25 Oct 2010 15:54:33 GMT

I have got a Direct Access lab environment with an UAG RTM, and I want to upgrade to UAG SP1.

So I have downloaded the upgrade package (http://www.microsoft.com/downloads/en/details.aspx?FamilyID=980ff09f-2d5e-4299-9218-8b3cab8ef77a) and launch it on my platform. During the prerequisite installation, there was an error :

“Setup failed UAG during Prerequisites installation”

After a manual installation of Forefront TMG SP1, installation was successfull.

A restart later, here is the new management console :

You cannot generate and activate the configuration right now, because some features needs some configuration.

There are an other issue : If you allready have an HRA server in your organisation, he’s automatically added to a custom servers groups : “NAP”. I recommand to move this server into the HRA predefined group. The connectivity was KO until I move the server.

Published by Olivier DETILLEUX

Implementing SSO for the SCOM Login Page through UAG

forefrontsecurity — Tue, 05 Oct 2010 08:48:00 GMT

I’d like to mention that this article was co-Written with Frederic Esnouf whom i thank for his help.he also published it on his blog: http://blogs.technet.com/b/fesnouf/archive/2010/10/01/implementing-uag-sso-with-scom.aspx.

I decided to write this article after trying to follow a small post that he’d made earlier and encountering few problems.

We’ve seen in previous articles how to implement SSO through UAG for non-default websites. Those solutions however do not apply for all encountered form login website and you might encounter some issues implementing this solution for some forms.
We will go through the implementation of the SSO solution for the SCOM Form login website and walkthrough the troubleshooting process that could be followed in case of problems.

1- Web publishing

Below is the SCOM forms login page that we need to avoid manually login on to.

We will start by creating a new “Other Web Application (application specific hostname)” publishing

Follow the wizard’s steps and note the «Application type » specified.

On the authentication step, activate the single sign-on checkbox, select an authentication server and choose “HTML form” as the authentication method.

Once the configuration is done and activated, the SCOM form login website will be accessible on this address: https://scom.xxx.fr/, you will have to authenticate and login manually though.

Next step is to create the Custom XML file that will enable the SSO access to the SCOM page,

The file should be called formlogin.xml and stored in the following folder:

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

Below is the custom formlogin.xml file that was created for the SCOM page SSO:

<APPLICATION_TYPE>ScomWI</APPLICATION_TYPE>

<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>Login1$UserName</NAME>

<DEF_VALUE>siteuser</DEF_VALUE>

</CONTROL>

<TYPE>PASSWORD</TYPE>

<NAME>Login1$Password</NAME>

<DEF_VALUE>sitepass</DEF_VALUE>

</CONTROL>

<TYPE>submit</TYPE>

<NAME>Login1$LoginButton</NAME>

<DEF_VALUE>Log In</DEF_VALUE>

</CONTROL>

</LOGIN_FORM>

</USAGE>

</APPLICATION>

</WHLFILTFORMLOGIN>

<APPLICATION_TYPE> must be the same as the application type entered during the Publishing.

<PRIMARY_HOST_URL> must be equal to the Forms’ web address to which you would like to apply the script.in our case the address 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 file that will allow us to submit the filled out form and login. We will view it in more details later on.

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

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

<NAME>Login1$UserName</NAME> must be equal to the form’s field that the script will fill with the Username.

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

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

<DEF_VALUE>siteuser</DEF_VALUE> this value is a constant and will automatically fill the above field with the correct info.

<NAME>Login1$Password</NAME> must be equal to the form’s field that the script will fill with the Password.

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

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

<DEF_VALUE>siteuser</DEF_VALUE> > this value is a constant and will automatically fill the above field with the correct info.

<NAME>Login1$LoginButton</NAME> must be equal to the form’s login button name.

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"

<DEF_VALUE>Log In</DEF_VALUE> must be equal to the value that the login button has.

Once those parameters filled correctly, the Autosubmit_Scom.js script must be edited and copied to the correct location.

The default Autosubmit.js provided by UAG usually submits the filled out form without any problem.

It is 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 » and renamed as autosubmit_Scom.js as specified in the formlogin file.

After activating the UAG configuration, accessing the https://scom.xxx.com/ link, we fill out the UAG authentication form and submit the request.

Troubleshooting :

Implementing this solution requires a little knowledge of HTML and Javascript, there are however some tools that can help out troubleshoot problems you might encounter.

Among the issues that might happen:

1- The Scom page is not filled with any login information:

The problem in this case is most probably with the formlogin.xml file that was not filled correctly.

HTTPWatch is a browser plugin that can help you trace the script execution.

By recording the ongoing events you can check and see if the script was executed or not.

In the snapshot below, we located the post event and by looking at the post data noticed that the requested data is being sent to the Scom Form.

Additionally when looking at the Content tab you should see the « FormLoginOnLoad » function at the top and bottom of the HTML code.

var gSafeOnload = new Array();

function FormLoginOnload()

{

for (var i=0; i < gSafeOnload.length; i ++)

{

gSafeOnload();

}// for i

}// FormLoginOnload

if (window.onload)

{

gSafeOnload[0] = window.onload;

gSafeOnload[gSafeOnload.length] = FormLoginSubmit;

window.onload = FormLoginOnload;

}

else

{

window.onload = FormLoginSubmit;

} // if window.onload

</SCRIPT>

If either one is missing, then the formlogin.xml was not detected by UAG because of some incorrect information.

2- The form was successfully filled but was not submitted:

The problem in this case lies in the autosubmit_Scom.js script

The submit function can vary from an HTML page to another, meaning that the default submit code might not always work.

In order to trace the behavior of the SCOM login page during the script’s execution we will use internet explorer’s Developer tools which are now integrated with IE 8.

Enable the tools, access SCOM login page and ask the developer tools to monitor the login button’s behavior.

The HTML code will be displayed and by selecting the script tab, you will be able to execute the autosubmit.js content and see the page’s reaction live.

The following functions are but few of the possible functions that could make the HTML page execute a submit.

In our case the example 2, simulating a click on the button was the one that worked, and executing the function in the developer tools script windows allowed us to identify that.

Par default

Exemple 1

Exemple 2

function FormLoginSubmit()

{

document.forms[1].submit();

return false;

}

function FormLoginSubmit()

{

logon();

return false;

}

function FormLoginSubmit()

{

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

return false;

}

Published By Hicham Bardawil