Configuring Big IP APM with sharepoint integration.

Hi fellow Nordic friends!

At my customers, the sites normally differ by hostname. Typically I use latest SharePoint iApp to create a starting config, then finetune/customize manually. Note that some adjustments may need to be done on the SharePoint side, too, for example AAM settings (Alternate Access Mappings).

If you apply iApp for each site, then each site normally has its own virtual server and config. This leads each site having its own APM access profile, too. Then you have to decide whether to publish a webtop or allow direct access to the site after authentication. Obviously you would want the user to go directly to the site he/she wrote to the browser.

For multiple sites/applications, it is possible to use a single common access profile, ie. one VPE flow for authentication, and even a single virtual server for publishing those sites. I have used both and combinations of those, too.

Using single virtual server in your case should be fairly straightforward if the site hostname is the only differing element and the SharePoint server pool is the same, but I think you need to match the site FQDNs with your ssl certificate in the clientssl profile. Easiest is request a wildcard cert if the domains are the same. It then allows expansion, to add 3rd site..

For the APM side the main difference might be the SSO method. If using Kerberos, then you might use %h (hostname) parameter in the SPN Pattern, to allow multiple hostnames to use the same Kerberos SSO configuration object. If you need to restrict access within the authenticated users, you might need to apply APM ACLs, too.

So quite a lot depends on the actual requirement/details.

One customer I have has over 15 different sites and applications (not only SharePoint) having their own virtual servers but authenticated via a single APM VPE. For a single common authentication VPE I have used domain cookie SSO method. The VPE acts as an IdP for the customer providing strong authentication if the backend requires it and then applies required SSO mechanism. SSO can be different per site/backend application. Using SAML is possible, too, but may restrict some SSO methods to backend.

Tricky things come typically from the backend application, especially some Intranet applications may be legacy, using shortnames (Non-FQDN), may have hardcoded absolute links, require some specials in SSO, may need to use ACLs to restrict access to underlying platform engine, etc. So far managed to get them working with F5, proving its flexibility.