030514_1750_Extradium2012.png

Extradium 2013 and ForeFront UAG Integration

Following up on our latest recommendation for Microsoft ForeFront UAG configuration with Extradium 2010, this blog post will lay out the configuration steps necessary to make SharePoint 2013 and Extradium 2013 work together through UAG.

But first, let me talk about the infrastructure that was used to validate our SharePoint 2013/UAG configuration in a Hyper-V environment:

  1. DEMODC is the Active Directory domain of the demo.company.com domain (DEMO is the NetBios domain name). DEMODC also hosts the Certificate Authority we’ve used to issue the SSL certificate used on the UAG box (we won’t delve into that specific part of the configuration though)
  2. SharePoint 2013 and Extradium 2013 are set up on a single SharePoint server, called SPDEV1
  3. ForeFront UAG with Service Pack 3 is set up on a single server, called UAG1 and a *.company.net certificate has been issued by DEMODC to the UAG1 server

    Note: Service Pack 3 is required for SharePoint 2013 integration

  4. A SharePoint web application has been set up at https://extranet and an extranet CNAME entry is present the DEMODC DNS (pointing to the SPDEV1 server).
  5. The external url of the SharePoint portal should be https://partners2013.company.net and the external url of the UAG Portal is https://uag.company.net (note that it is impossible that those urls be the same – the UAG secure trunk url must be different from the SharePoint external url even if UAG only exposes that one single SharePoint site)

Below are the configuration steps we took in order for this configuration to work with external clients (simulated with the Hyper-V hosts and other machines on the same external network as the UAG1 server – we used the hosts file of each client to point uag.company.net and partners2013.company.net to the UAG1 server).

But first, let’s acknowledge that there are multiple ways to configure SharePoint and UAG together. More precisely, the Microsoft folks have identified 4 different ways, as highlighted by Ben Ari and Scott Kyser:

If we had to match the table above with “real world” examples, this is what we could have with our configuration

Scenario #2 is not very realistic as it opens SharePoint through non-secure ports and scenario #3 is rather easy (though not trivial) to implement so we’re not going to specifically cover them. However, the bulk of the configuration steps below will allow you to configure your SharePoint/UAG environment for scenarios #2 and #3.

We haven’t found a way to implement Scenario #1, so we’re unfortunately not going to talk about it for now (if you have any idea on how to implement it, please let us know!).

Scenario #4 is probably the most interesting one, because it basically offloads SSL to the UAG server, which can be useful if you already use SSL on one of your other internal web applications (in which case you can’t use SSL on the standard 443 port for another web application, even with a different host name). On the contrary, in scenario #3 you must deploy a certificate on both the SharePoint server and the UAG server, which can be inconvenient.

Enough with the overview, let’s dive into the actual configuration, broken down in 2 parts (SharePoint and UAG).

SharePoint Configuration

  • At this stage, https://extranet runs with only Windows Authentication and we’re not going to change the authentication on that zone (unless internal users must add Extradium users or assign them to People fields, in which case you will need to activate Extradium FBA on that zone and potentially use our Auto Sign In feature to avoid the Extradium Sign In screen and allow seamless authentication in the internal network). Instead, we’ve extended the web application to the Extranet zone with the http://partners2013.company.net url (note the HTTP prefix, not HTTPS, this is very important!). Here is a screenshot of the critical parameters when extending the application:

  • Also, because UAG will need to forward requests to this https://partners2013.company.net url, we created a company.net Forward Lookup Zone in the internal DEMODC DNS and added partners2013 CNAME entry pointing to SPDEV1.

There might be other ways to achieve this (for instance, by using the host name file on the UAG server), but that’s how we’ve done it in our test environment.

  • Next, UAG will need a fake url (read Scott Kyser’s blog post for more info) in order to work in this mixed HTTP/HTTPS environment, so we’ll go ahead and add it as an Internal Url of the Extranet zone (we’re using http://uagsp as the fake url and it doesn’t have to resolve in the whole domain at all):
  • Here’s the screenshot of our resulting Alternate Access Mappings configuration:

  • Since IIS also needs to know about this fake host name, open IIS Manager and add the uagsp binding to the IIS site that maps your Extranet zone.

  • Next, enable Extradium FBA on the Extranet zone (Central Administration è Extradium è Extradium Forms-Based Authentication (FBA) Configuration). Note that we will leave Anonymous access to Off in order to allow UAG to perform the Single Sign On operation without a glitch.

  • If partners2013.company.net resolves in your internal domain, go ahead and test that you can indeed sign in with an Extradium user at https://partners2013.company.net . If you cannot sign in, you’ll need to fix this issue before you move on to the UAG configuration step.
  • When Extradium is configured on a web application’s zone, the Sign In Page URL property of that zone is updated to point to “/_layouts/exs/SignIn.aspx” (as shown in the screenshot below), which is a custom sign in page Extradium provides.

    This allows Extradium to display a more user-friendly sign in page:

    compared to the default SharePoint Forms Sign In page that is available at /_forms/default.aspx :

    The problem is that UAG only seems to kick off its SSO trick (through a custom JavaScript that’s inserted on the Sign In Page) on the default sign in page (/_forms/default.aspx) so for UAG to work seamlessly with Extradium, you must set the Sign In Page URL back to “Default Sign In Page” in the Authentication Providers menu of your web application:

  • Of course, the drawback of this approach is that you now have to use the (meager) functionality offered by SharePoint’s default sign in page. However, if you really love the Extradium Sign In Page or you want to/must benefit from its unique features (such as forcing users to reset their passwords after they’ve been reset by an administrator), then you can copy the SignIn.aspx file from C:\Program Files\Common Files\microsoft shared\Web Server Extensions\15\TEMPLATE\LAYOUTS\EXS and paste it to the _forms folder of your Extradium zone, something like C:\inetpub\wwwroot\wss\VirtualDirectories\[ZoneUrlPort]\_forms. Then, rename the Default.aspx page to _Default.aspx and rename SignIn.aspx to Default.aspx.
    After UAG is fully configured (see below), when you try to access your Extradium-enabled SharePoint site with the Default Sign In Page, you will see the Extradium custom Sign In Page for a few tenths of seconds (or even less):

UAG Configuration

On the UAG side, we’ll assume that no trunk has been configured, but before creating the trunk we must configure the Extradium authentication.

  • Starting with Extradium 2013 v3.1.0.0, you will find an Extradium2013.inc file inside the Extradium_Standard_2013.zip archive. Copy this file to your UAG server and put in inside the C:\Program Files\Microsoft Forefront Unified Access Gateway\von\InternalSite\inc\CustomUpdate folder.
  • Edit the Extradium.inc file and on line 22 replace the following highlighted value with the internal url of the SharePoint zone where FBA will be enabled:

    strSharePointFBAWebAppUrl = https://partners2013.company.com

  • Edit the FormLogin.xml file from the C:\Program Files\Microsoft Forefront Unified Access Gateway \von\Conf\WizardDefaults\FormLogin folder and identify the SharePoint15 section (we strongly recommend that you back up the FormLogin.xml file before updating it).
  • Before the closing </LOGIN_FORM> tag, insert the following 2 <CONTROL> tags:

        <CONTROL handling=dummy_value>

          <TYPE>USER_NAME</TYPE>

          <NAME>ctl00$PlaceHolderMain$ucLogin$loginControl$UserName</NAME>

          <DEF_VALUE>siteusr</DEF_VALUE>

        </CONTROL>

  • Save and close the FormLogin.xml file.
  • Navigate to the C:\Program Files\Microsoft Forefront Unified Access Gateway \von\Conf folder and edit the FormLoginDataDefinitions.xml file and identify the FormLoginSubmitSP14AAM script section.
  • Right below the following lines:
if (submitbtn)
  submitbtn.click();

insert the following lines:

else {
        var submitbtn = document.getElementById('ctl00_PlaceHolderMain_ucLogin_loginControl_login');
        if (submitbtn)
           submitbtn.click();
       }
  • Save and close the FormLoginDataDefinitions.xml file.

    Note: Those 2 files (FormLogin.xml and FormLoginDataDefinitions.xml) are responsible for the Single Sign On. Note that at this stage, and contrary to our SharePoint 2010 UAG integration, they only work both with the default SharePoint Forms Sign In page (/_forms/default.aspx) and not with the Extradium Sign In Page. If you choose to keep the Default Sign In Page without overriding it with the Extradium Sign In Page, the user will first have to select the proper authentication method (Windows or Forms) in a mixed authentication scenario (where both Windows and FBA authentication schemes are enabled on the same zone).
    In that case only, once Forms is selected, the SSO script will be triggered and the user will be seamlessly redirected to the SharePoint site.

  • Open the ForeFront UAG Management Console and select Admin è Authentication and Authorization Servers in the top menu. In the Authentication and Authorization Servers window that opens, click Add.
  • Select Other and type Extradium2013 in the Server name text box (this should match the name of the Extradium2013.inc file)

  • Press OK, Close and save the configuration (don’t publish it right away though)
  • Next, right-click HTTPS Connections and select New Trunk.
  • Press Next and select Portal trunk. Press Next again.
  • Enter a Trunk name and enter the public host name of the UAG server (not the SharePoint public host name!). In our case, it’s uag.company.net . Press Next.

  • In Step 3 – Authentication, press Add, highlight Extradium2013 and press Select

  • Press Next. In Step 4 – Certificate,
    select your certificate (we recommend a wildcard certificate). In the screenshot below, we have obviously already deployed the certificate on the UAG server.

  • Press Next. In Step 5 and Step 6, leave the default options and complete the Create Trunk Wizard.
  • Under Applications, press Add

  • Press Next and in Step 1 – Select Application, select Microsoft Office SharePoint Server 2013

  • Press Next and in Step 2, enter an Application Name (for instance “Partners Extranet”)
  • In Step 3, select the SharePoint 2013 Upload and Download policies

  • Press Next twice and in Step 5, enter the host name of the internal SharePoint zone exposed through Extradium. In our case, it’s partners2013.company.net.
    The Public host name is also partners2013.company.net, so enter partners2013 in the Public host name field.
    We leave the 80 port selected as we are forwarding the requests to a non-secure internal url.
    Don’t forget to check the “Replace the host header with the following” check box and enter the fake host name we used in the SharePoint configuration, i.e. uagsp.

  • Press Next. In Step 6 – Authentication, press Add and select Extradium2013. Also, check the Allow rich clients…
    and User Office Forms Based Authentication for Office client applications check boxes at the bottom of the screen
    .

  • A pop-up window might open. Press Yes and then Next.
  • In Step 7 – Portal Link, adjust any necessary field (except the Application URL field) and press Next

  • In Step 8, leave the Authorize all users check box checked and press Next. Then press Finish.
  • Save your configuration and activate it by using the corresponding buttons in the UAG Management Console toolbar:
  • Now, sign in through UAG with an Extradium account:

  • Select your SharePoint 2013 site

  • Right after you click on your SharePoint 2013 link, you should see a sign in form flicker in your browser with ‘siteusr’ in the Username field. This is a (good) sign, as it shows that the UAG SSO actually works!
  • After you’ve landed on the home page of your SharePoint site and if you’re not convinced that you’ve just signed in through ForeFront UAG, check out the Welcome menu (the menu displayed right under your name in the right-hand corner of the page). You will notice that there is no ‘Sign Out’ link, which is a customization UAG includes:

    You can indeed only sign out (or “log off”) from the UAG main page:

As you may have noticed, the configuration for SharePoint 2013 and Extradium 2013 is slightly different from the SharePoint 2010/Extradium 2010 configuration, insofar as we haven’t yet found a way to instruct UAG to perform the SSO on the Extradium custom sign-in page. But it’s also a bit simpler, so hopefully you won’t mind too much (especially since we found a workaround!).

facebooktwitterredditlinkedinmailby feather