UAG – How to configure a MAC Address Filter to grant or deny access to the UAG Portal

In the last view months when I was doing consulting projects in UAG implementations, there was a high demand for a solution to an apparently very simple problem. Customers asked me to implement a MAC based filter to deny or grant access to clients logging on to a UAG portal. As you probably know, there is no out-of-the-box checkbox-based way get this up and running. However, because UAG is customizable in various and unbelievable ways, I want to give you a basic idea of how to deal with this specific requirement. So let´s have a look on the base scenario, to build a working prototype solution. Please notice, that in production environments, you should carefully review the pieces you get in this article and you double-check the security impacts and possible gaps to improve this proof of concept implementation. But, let´s start now!

The mission:

1. Store a list of allowed MAC Addresses (a simple file in my case)
2. Detect all MAC Addresses during client connection
3. Compare the detected values against the file

I assume you already have a HTTPS-Trunk up and running before you follow the steps below.

1. Store a list of allowed MAC Addresses:

---

I decided to store the MAC Addresses I want to grant access to as a simple text file on the local c: drive of the UAG Server. Therefore I created a folder named MACPolicies and dropped a file called MACAddresses.csv there. The content of the file looks very simple as you can see here:

 

2. Detect all MAC Addresses during client connection:

---

The next part is a little bit more tricky and needs some manual configuration changes using the custom update mechanism built into UAG. We need to built a custom endpoint detection script which runs in the browser context on the user device. You have to pay attention that all the things you are doing here are sandboxed by Internet Explorer and you have to take care about the associated security restrictions. I generated a little VB-Script to query all network interfaces on the client device by using WMI. A very detailed description on how endpoint detections scripts can be used to gather different kind of data I recommend you to read through Ben´s Article Detection Agency. The code I used to detect the MAC Addresses can be examined here:

 

After developing and testing save your script on the UAG Server at the following location:
<UAG Installation Path>\von\InternalSite\CustomUpdate as you can see in my example.



The next step is to let UAG know that our custom script needs to be executed when client detection takes place. To get this done we need to create a new file in <UAG Installation Path>\von\InternalSite\inc\CustomUpdate with the name TrunkName(1:https,0:http)detect.inc, where TrunkName is the name of your trunk, 1 defines a https trunk, 0 defines a http trunk, and detect.inc. The content of the file is as simple as:

<%
g_scriptList("/InternalSite/CustomUpdate/DetectMAC.vbs") = false
%>

This custom include file tells the UAG Server that the DetectMAC.vbs script should also be used for client detection. You can compare your configuration with the following screenshot:



After you placed your files you can activate your UAG configuration and log on to your UAG Portal. You can use the Web-Monitor to check if there is a new session parameter called MACAddressSet which contains all detected MAC Addresses on your client device.



Now we got a string with all MAC Addresses on the client side and we can access this parameter any time we need to.

3. Compare the detected values against the file:

---

To compare the gathered values we need to make sure that the following steps are made. We need a server side place to put in some script code to get access to the session parameter. Further the code needs to open the file and the values there need to match one of the detected MAC Addresses. In my case I decided to use the PostPostValidate-Process to place my code. To achieve this we need to place a second file into <UAG Installation Path>\von\InternalSite\inc\CustomUpdate and name it in the same way we did before so that it looks like:
portaltrunk1postpostvalidate.inc



Let´s look into the content of the file. The script uses the GetSessionParam-Function to access the MACAddressSet variable. The MACAddressSet is split into an array and for each MACAddress in the array a check based on regular expressions is done. Once there is a match between the content of the file and the MACAddress in the array we know the user can get access to the portal. If there is no matching entry the user gets logged out and redirected to logoff page. Of course you can redirect to a second page and present a custom error page to the user. It is up to you. You can look at code here:



Save the file and activate your configuration. Then you can play around with your MAC Address file and test the results. As stated above this is proof of concept and you can feel free to refine the solution. Hopefully you got an impression on how flexible UAG can be and that most things can be done.

UAG–How to access Remote Desktop Web Access using SSO

UAG offers a a very smart way to integrate Remote Desktop RemoteApps into the UAG portal. For different reasons many customers want to publish the Remote Desktop Web Access Application for their portal users as a link in the portal home. However, the Remote Desktop Web Application uses forms-based authentication by default, that means the UAG logon credentials need to be delegated to the RDWeb Application using the Formular Engine delivered by UAG. In this post i like to describe the steps needed to publish RDWeb Acces into the UAG portal and provide single-sign-on to the RDWeb Application using the formular engine. There is a solution to configure RDWeb App to use Windows Integrated Authentication and to delegate Kerberos/NTLM credentials to the RDWeb App, but this is not part of this post at the moment.

The Mission:

1. Setting up RDWebApp to work with UAG
2. Publish RDWebApp as an Other Web Application in UAG portal
3. Analyze the RDWeb App Login Form
4. Configure the UAG Formular Engine
5. See SSO working with RDWebApp

So, let´s rock now!

1. Setting up RDWebApp to work with UAG

---

In my scenario, i installed a Windows Server 2008 R2 and assigned the roles Remote Desktop Session Host and Remote Desktop Web Acces on a single virtual box. After assigning the Remote Desktop Role and installing the Remote Desktop Web Application Role-Service you can notice, that RDWebApp is using a self signed certificate to use SSL encryption when you access the RDWebbApp Website. This leads to a certificate error displayed in the browser window if you try to access the RDWebApp.

So we need to swap the self signed certificate to a trusted certificate issued by a trusted certifiaction authority. For internal resources i used an Active Directory integrated certification authority and i requested a Webserver certificate from there. Keep in mind, that the common name of the certificate needs to match the servername you type into the publishing wizard in UAG! For example, if you use an address like rdserver.home.ahecker.net the common name of the certificate needs to be rdserver.home.ahecker.net. The certification authority issued the certificate needs to be trusted (which is automatically done, if you use an AD integrated CA) as a Trusted Root Certification Authority in the UAG certificate store. If you have difficulties in dealing with certificates, feel free to drop some lines in the comments section beyond this article and i will post a more detailed description in how to setup this.

If you request the RDWebApp from an internal Computer there should be no warings and the website should look like this:

As you can see no certificate warining is displayed anymore.

2. Publish RDWebApp as an Other Web Application in UAG portal

---

Open the UAG Management Console and click the Add button beyond the Applications section. Select Next to bypass the welcome message. In the Select Application Dialog change the default to Web and select the Other Web Application (portal hostname) template.

 

Click Next. In the Application Name Textbox enter a name for the published Application like Remote Desktop Website and enter an Application Type for example RDWEB. We will need the Application Type in later steps and it is used in XML-Files. Remember that XML is case-sensitive so keep the spelling of your Application Type in mind.

Click Next. In the Select Endpoint Policies Dialog change the Access Policy to Always. This is done for testing purposes only and i do not recommend you to use this as an option in your production environment.

Click Next. In the Deploy an Application Dialog select Configure an Application Server because we are using a single webserver. In the Web Servers Dialog select the IP/Host-Option and enter the servername into the Adresses list. The servername entered here needs to match the common name of the webserver certificate that is used by IIS on the Remote Desktop Web Access Website. In the Paths list enter the url path to the Remote Desktop Web Access website. By default this is /RDweb/*. Keep the defaults for HTTP and HTTPS Ports.

Click Next. In the Authentication Dialog enable the Use SSO checkbox and select your authentication source. In my case i configured my Domain Controller as an authentication source for portal and application access. As the Remote Desktop Web Access Website uses HTML-Form authentication select the HTML-Form option to delegate the user credentials.

Click Next. In the Portal Link Dialog click next. In the Authorization Dialog click next. Click Finish to close the Wizard. In the UAG Management Console click the gear icon to activate your configuration. From a client PC logon to the portal an notice, that the Remote Desktop Web Access Website is visible as a new application in your portal.

If you hit the link your browser is redirected to the login page of the Remote Desktop Web Access website.

3. Analyzing the RDWeb App Login Form

---

With the login form opend in the browser we can do some visual analysis about the content of the form. There are two textboxes, one for the userdomain\username and one for the password. Further there is a submit button to send the form. To identify the form elements we need to view the source code of the page. Right-click the form in the browser and select View source to open the source code view. We need to extract some more details to identify each element we need to create a custom form login. That UAG can identify the login page we need the name of the form and the method used to submit the data to the webserver. This information can be found in the <form>-Tag in the source code.

As we can see the name and id of the form is: FrmLogin and the method is: post. Now we need to identify the Textbox-Elements so we can search the source code for “type=text”. We need the id-Element of the User-Textbox and the id-Element of the Password-Textbox.

Once we have found the Username and Password textboxes in the source code we can see that the Username-Textbox-ID=DomainUserName and the Password-Textbox-ID=UserPass. Now we need to identify the submit button so let´s search for an type=submit in the source code.

The id is: btnSignIn. Now we have gathered all information we need to configure the Fromular-Enging in UAG.

 

4. Configure the UAG Formular Engine

---

Locate the folder  \von\Conf\WizardDefaults\FormLogin in your UAG installation path. If there is not already a folder named CustomUpdate create the folder and copy the file FormLoginCustom.xml to the CustomUpdate folder. Rename the file to FormLogin.xml inside the CustomUpdate folder. The structure should look like this:

Open the file and remove all content. Edit the file and enter the xml-Code so that it exactly looks like this:

Or simply cut and paste the content from here:

<WHLFILTFORMLOGIN ver="1.0">
    <!-- app_id added by configurator, dont edit -->
    <APPLICATION>
        <APPLICATION_TYPE>RDWEB</APPLICATION_TYPE>
        <USAGE description="form_login">
        <PRIMARY_HOST_URL><![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>
        <LOGIN_FORM>
            <!-- one of NAME or ID could be used. Value could be blank if no form search required -->
            <NAME>FrmLogin</NAME>
            <METHOD>POST</METHOD>
            <CONTROL handling="dummy_value">
                <TYPE>USER_NAME</TYPE>
                <NAME>DomainUserName</NAME>
                <DEF_VALUE>sitedomain\siteusr</DEF_VALUE>
            </CONTROL>
            <CONTROL handling="dummy_value">
                <TYPE>PASSWORD</TYPE>
                <NAME>UserPass</NAME>
                <DEF_VALUE>sitepass</DEF_VALUE>
            </CONTROL>
        </LOGIN_FORM>
        </USAGE>
    </APPLICATION>
</WHLFILTFORMLOGIN>

As you can see, the information we gathered about the form is used to identify the form itself, the method , the textbox-controls and variables like sitedomain\siteusr and sitepass are used to fill in the values with the credentials of the logged in user. Keep in mind that xml is case sensitive. The <NAME>-Elements must match the form-elements exactly! Save the FromLogin.xml file and in UAG Management Console activate your configuration.

5. See SSO working with RDWebApp

---

Login to your Portal and click the Remote Desktop Web App link. You can see the RDWebApp Login Form by a fraction of second filled with dummy values. Then the form is automatically submitted an you are redirected to the Remote Desktop Website without using your credentials again.

SSO to RDWebApp is done now. Enjoy!

Released - UAG SP1 Direct Access Configuration Guide by Shannon Fritz

 

Shannon Fritz, a high quality UAG Expert has published a great configuration guide to setup Direct Access with UAG Servicepack 1. For all of you who are interested in building a lab solution or plan to implement the technology within the production environment i strongly recommend you to work yourself through this detailed and comprehensive configuration guide.

The guide is available on Shannon´s blog: http://blog.concurrency.com/infrastructure/uag-sp1-directaccess-configuration-guide/

Many thanks for this great work!

Released - Microsoft Forefront UAG 2010 Administrator’s Handbook

If you are looking for hands-on guides, concepts and planning guidelines or step-by-step instructions to configure and administer Microsoft Forefront UAG 2010 then Ben´s Administrator’s Handbook is the right book to start with. You will get in touch with terminology and various illustrations which show you the detailed steps you need to do. Reading this book will help you to improve your knowledge about this product in many ways and saves time to implement the features in your environment.

Here are some of the topics covered in the book:

• Understand how UAG can help your organization with secure remote access.
• Plan and design the integration of UAG into your unique environment.
• Create trunks and publish all kinds of applications on them.
  Enable VPN access for multiple platforms.
• Design and implement DirectAccess for your organization.
• Manage endpoint security with advanced policies.
• Monitor, maintain and secure your Microsoft server.
• Integrate UAG with multiple infrastructures and platforms.
• Discover various types of applications UAG can publish, and how to publish them.
• Learn how to provide remote access to your users or partners using SSL technology.
• Take advantage of single sign-on with low administrative overhead and high security.
• Integrate UAG with existing authentication infrastructure like Active Directory.
• Gain knowledge of advanced endpoint management for ultimate security in a world of unknowns.
• Perform troubleshooting and solve problems like the pros.
  Integrate UAG with AD FS V2 for maximum corporate flexibility and security.
• Discover how to publish Microsoft Office SharePoint Server 2007 and 2010 securely
• Find out how UAG interacts with TMG 2010 (the successor to ISA server 2004)

The book can be purchased here: http://amazon.com/o/asin/1849681627

Many thanks to the authors, great job!

UAG–Enable SSO by passing user credentials to formular based Web Applications

A lot of Web Applications like Sharepoint or Outlook Web Access make use of formular based user authentication. Some of these applications cannot be configured to use other authentication methods like Basic- or Windows-Authentication. In this case the user has to authenticate twice, one time to login to the portal, the second time, if he wants to start the published application inside the portal. Sharepoint for example can be configured to use the ASP.Net Membership Provider to authenticate external users with forms based authentication. UAG can also be configured to use ASP.Net Membership Provider to authenticate external users like i described in my post here. Both applications use the same repository for authentication and we can use a feature called the Form Authentication Engine built into the UAG product to pass the credentials of the logged in user into the authentication form presented by Sharepoint and do an Autosubmit. Done so, we can bring SSO-Experience to our end-users.

The Mission:

1. Setup an Intranet Sharepoint Site using Windows Authentication
2. Extend the Website to external Users using ASP.Net Membership
3. Publish the extranet Sharepoint Website via the UAG Portal
4. Configure the UAG Formular Engine to work with Sharepoint FBA
5. Test the result

 

1. Setup an Intranet Sharepoint Site using Windows Authentication

---

Start the Sharepoint 2010 Central Administration and select Application Management and click on Manage Web Applications. On the following WebSite click the New button to create a new Web Application.

In the Create New Web Application Wizard select Claims Based Authentication.

Scroll down and check if the Authentication Type for this Web Application is set to Windows Authentication because this Web Application will be used by our internal clients and is not published to any external users.

Change the Application Pool Account to Network-Service and click OK to create the Web Application. I did not make any ohter changes and left the defaults. After the Wizard has finished click OK and select Application Management and click on the Create Site Collections link in the Site Collections section.

In the Create Site Collections Dialog make sure the correct Web Application is selected.

Also fill in a title, select a site template and make sure to add an Active Directory user as Primary Site Collection Administrator.

After the processing has finished you can try to access the Homepage by clickin on the displayed link. The default content shows and you are automatically logged in with your actual credentials.

 

2. Extend the Website to external Users using ASP.Net Membership

---

Navigate back to Application Management –> Manage Web Applications. Select the Web Application created in the steps before and click on the Extend button.

In the Wizard create a new IIS Site, fill in a name and set the port number you like.

In the Claims Authentication Types uncheck Enable Windows Authentication and check Enable Forms Based Authentication. Enter the name of the Membership and Role Providers and change the zone to Extranet at the bottom of the dialog.

After the Web Application is extended you can test the url and you should see a Login Formular

The next step is to configure Sharepoint 2010 to use the ASP.Net Membership SQL Instance for authentication. Because this is beyond the scope here you can use this very detailed Step-By-Step Guide in Donal Conlons Blog.
After setting up Sharepoint 2010 and IIS to use the same ASP.Net Membership provider like UAG we configured both products to use the same authentication repository and you can login to both products with the same usernames and passwords stored in the SQL Database.

 

3. Publish the external Sharepoint Website via the UAG Protal

---

I assume that you have already done the steps provided in my article about UAG and SQL Authentication. So there is a portal up and running and we need to publish a new Web Application through the UAG Management Console.In the UAG Management Console click the Add button to start the Add Application Wizard and click Next on the Welcome Screen.

On the Select Application Screen check the option Web and choose Other Web Application (Portal Hostname).

In the Configure Application Screen type in a name for your application and type in an Application type. Keep the application type in mind because you will need this information later.

In the Select Enpoint Policy Screen select the Enpoint Policies you require. To keep things simple i use the option always for all policy settings. This is not my recommendation but i want to focus on the main solution.

In the Deploying an Application Screen select Configure an Application Server and click next.

In the Web Servers Screen enter the name of your Sharepoint Server, set the Path value to / and enter the Port number your external Sharepoint Site is listening on.

In the Authentication Screen check the Use Single-Sign-On checkbox and add the SQLAuthN Repository as an Authentication Server. Select Both for the Client Authentication Method.

In the Poral Link Screen you can accept the defaults and in the Authorization Screen you can authorize all users to access the application. After that you can exit the Wizard by clicking Finish. Please do not forget to Activate your configuration to store the changes you have made. It will take some time until the new configurations becomes active. Now you can log on to the portal using your SQL Credentials and you can see a new accessable application listed.

When you click on your new application the Sharepoint 2010 FBA login form appears. This is expected and if you enter the same credentials again you should be able to access the Sharepoint content.

 

4. Configure the UAG Formular Engine to work with Sharepoint FBA

---

The next step is customizing some configuration files in UAG to set up the Formular Engine. The Engine has to recognize and to identify the form. The Engine also needs information about the input fields of the form so that the users credentials can be inserted. An Autosubmit script needs to detect the submit button of the form and is fired after the credentials are inserted.

Navigate to the <UAG Installation Folder>\von\Conf\WizardDefaults\FormLogin\ Folder and create a new Folder called CustomUpdate.

Copy the FormLoginCustom.xml File in the CustomUpdate Folder and rename it to FormLogin.xml

Clear the content of the File and insert exactly the same content you can see in the next screenshot. If you have entered a different Application type when you created your portal application then enter the exact Application type you defined. Replace my Application type (SharepointFBA) with your one. Keep in mind that XML-Syntax is case sensitive.

The content identifies your Application type, the URL which presents the form, the supported browser for this form application, the formular name, method and the input types as they appear in the HTML source of the login form. The LoginFormHandler Script checks if there is only one <form>-tag in the HTML source and the SharepointFBA Script is a custom script that identifies the submit-button of the login form and autosubmits the form in JavaScript.

To create a custom Autosubmit script open the file FormLoginDataDefinitions.xml in the <UAG Installation Folder>\von\Conf Folder and mark the complete <SCRIPT>…</SCRIPT> section for the FormLoginSubmitSP14AAM script. Copy the section by pressing STRG-C and insert it after the closing </SCRIPT>-Tag.

After you inserted the copy of the script change the name-attribute value to SharepointFBA and the GetElementByID-String to ctl00_PlaceHolderMain_signInControl_login because this is the ID of the submit-button in the SharepointFBA form.

Open the UAG Management Console and Activate the configuration. Wait some time to let the changes become active.

 

5. Test the Result

From a client computer access your portal url and log in as an external user. Click on the Sharepoint External Access link in the portal and see what happens. You can see the Sharepoint Form for a short while with username and password fields already filled out. After a second or shorter the form is automatically submitted and the user is logged in without any interaction.

Have fun with this nice feature in the UAG product!

UAG – How to Authenticate users against SQL Server

There are certain scenarios where the default authentication providers offered by Forefront UAG do not meet the requirements you have to authenticate your users. One example is the use of SQL Server Authentication which is not implemented in the UAG product by default. One of the most powerful features of UAG and/or IAG is the possibility to extend the authentication mechanisms by defining custom authentication repositories. In this scenario i would like to guide you through the process of how to implement an extranet scenario where you can authenticate extranet users against your Sharepoint 2010 installation using SQL Server as  a custom authentication provider

The Mission:

1. Setting up SQL-Express 2008 SP2
2. Configure the SQL-Express Instance
3. Add a custom authentication provider in UAG configuration
4. Add a custom repository.inc
5. Build a custom authentication function
6. Test the authentication against SQL

So, here we go.

1. Setting up SQL-Express 2008 SP2

---

In my environment i installed UAG in a existing Active Directory Domain. I also installed Sharepoint 2010 on a Windows 2008 R2 Enterprise Server and use SQL-Express as the database for Sharepoint. On this server i installed a second instance of SQL-Express 2008 SP2 for authentication. I will use this instance for claim-based FBA authentication in Sharepoint and i also like to use it as a custom repository in UAG. This is the first step to achieve SSO-Experience for external users.

After the installation of SQL-Express 2008 R2 we need to setup the ASP.Net Membership Database. An easy way to get the database up and running is to use the aspnet_regsql.exe tool. Open a command prompt and navigate to the following directory:
%windir%\Microsoft.NET\Framework64\v2.0.xxxx and start the aspnet_regsql.exe from there.

The Welcome to ASP.Net SQL Server Setup Wizard starts. Click next on the welcome screen. On the next screen select the Configure SQL Server for application services option and click next.

In the Select the server and database page enter your server\instance and the name of the database. If you do not enter a database name the default will be aspnetdb.

You can accept the authetication default values at this time because we will change the SQL-Server authentication mode to mixed mode later on. In the Confirm yout setting Dialog click next and the wizard will setup the database.

2. Configure the SQL-Express Instance

---

Run the SQL Server Configuration Manager tool from the SQL Server 2008 Program Group in your start menu. Enable the Shared Memory, Named Pipes and TCP/IP Protocols for your authentication instance and restart the SQL-Service.

Open the SQL-Server Managment Studio an make sure that the server is configured to allow remote connections. Rightclick on the instance node in the left pane and select properties. Select connections in the left pane and click the checkbox Allow remote connections to this server if it is not already selected.

Th next step is to create a SQL-Login and make this login a dbo for the aspnetdb database. In the left pane of the Management Studio expand the Security node and rightclick Logins. Select New Login…

On the General Page enter a Login name select the SQL Server authentication and enter a password. Clear the Enforce password policy checkbox and select aspnetdb as the default database.

Select the User Mapping page and click the aspnetdb checkbox. In the Database role membership for aspnetdb section select db_owner.

You can now create roles and add users to your aspnetdb. I use a tool called MembershipSeeder which you can download here.

3. Add a custom authentication provider in UAG configuration

---

To follow the next steps i assume that you have successfully configured an HTTPS portal trunk in UAG and you can access the portal with an external client. You should see the default login page like this, if you have configured portal authentication to use Active Directory Forest:

Because we want to give external users a way to authenticate without creating Active Directory Accounts for each of the external users we need to add a new instance of authentication servers to our portal configuration. This is done by clicking on the Configure… button in the Trunk Configuration section within your portal management.

In the Advanced Trunk Configuration Window select the Authentication tab and click Add..

In the Authentication and Authorization Dialog click Add… again

In the Add Authentication Server Dialog select Other as ServerType and type a ServerName like SQLServerAuthN in the ServerName textfield.

Click OK –> Select –> OK to close the dialogs. Activate the configuration changes and keep the ServerName you entered in mind.

4. Add a custom repository.inc

---

UAG is looking for a ServerName.inc file, in this case SQLServerAuthN.inc file, in the <Forefront UAG Installation Directory>\von\InternalSite\inc\CustomUpdate folder. I recommend that you copy the Repository.inc file from the <Forefront UAG Installation Directory>\von\InternalSite\samples to the <Forefront UAG Installation Directory>\von\InternalSite\inc\CustomUpdate and rename it to ServerName.inc in this case SQLServerAuthN.inc

The dependency is that the Servername you entered in the Add Authentication Dialog needs to match the Filename in the CustomUpdate folder. You can open the file with notepad and delete the functions ContinueAuthenticateRepositoryUser and ChangeRepositoryUserPassword because we will not use it at this time. The only functions which should be left in the file are the CheckCredentials, CheckChallange and AuthenticateRepositoryUser functions.

5. Build a custom authentication function

---

In this file we will write a custom function to authenticate users against SQL-Server. As an example you can use the following code:

function AuthenticateRepositoryUser(repository,user_name,password)

    'Preparing Variables
    dim oConn,oRecordset,sCommandText,sConnectionString
   
    'Setting up SQL-Command
    sCommandText="SELECT * FROM aspnet_Users INNER JOIN aspnet_Membership ON aspnet_Users.UserID=aspnet_Membership.UserID WHERE UserName='" & user_name & "' AND Password='" & password & "'"

    'Setting up SQL-Connection-String
    sConnectionString="Provider=SQLOLEDB;Data Source=srvmoss02\AuthN;Initial Catalog=aspnetdb;User ID=FormAuthUser;Password=Pa$$w0rd"

    'Setting up SQL-Connection Object
    set oConn=Server.CreateObject("ADODB.Connection")
    oConn.ConnectionString=sConnectionString

    'Open SQL-Connection
    oConn.Open

    'Send the query to SQL
    set oRecordset=oConn.Execute(sCommandText)
    HEAVY_TRACE "Cannot connect to SQL-Server"

    set authenticate_user_out = GetAuthenticatedUserDetails()
    if TypeName(authenticate_user_out) <> "Nothing" then
        ' User already authenticated by the Filter
        HEAVY_TRACE "Skipping authenticate user again"
        set AuthenticateRepositoryUser = authenticate_user_out
        exit function
    end if

    set authenticate_user_out = Server.CreateObject("UserMgrComLayer.AuthenticateUserOut")

    'Check if the recordset contains rows
    if not oRecordset.EOF then
        'User exists, password is ok
        if oRecordset("Password")=password then
            authenticate_user_out.Success = AUTHENTICATE_SUCCESS
            authenticate_user_out.ErrorCode = 0
            authenticate_user_out.Handle = 0
            authenticate_user_out.Message = ""
            authenticate_user_out.FullUserName = user_name
            set AuthenticateRepositoryUser = authenticate_user_out
        end if
    'Recordset contains no rows
    else
        authenticate_user_out.Success = AUTHENTICATE_FAIL
        authenticate_user_out.ErrorCode = ERROR_CODE_FAILED_TO_AUTHENTICATE
        set AuthenticateRepositoryUser = authenticate_user_out
    end if

end function

Save the file in the location as mentioned above.

6. Test the authentication against SQL

---

Open a browser window on a client and enter the URL to your portal. The Login-Screen appears.

Enter the User Name and Password of a user you created in the aspnetdb. Select the SQLServerAuthN in the authetication dropdown list and click Login.

Now you can access your portal authenticated with SQL-Express.

Let´s double check the success by viewing the session details in UAG Web Monitor.

Well done! Everything is fine now.