Enabling SharePoint with SSO through Novell Access Manager

Author : David van der Maas, Network Solutions Nederland

Introduction

Many companies use some sort of web based collaboration platform. And because many companies have Windows services in place, SharePoint is one of the collaboration platfomrs that is widely used.

Most of the SharePoint implementations start of with the "free" basic Sharepoint and they switch over to the (paid) Enterprise version because of it's features.

On the frontend, Sharepoint looks fine, it's intuitive and easy to understand. The backend however is different. It has a management interface that is somewhat peculiar and the used techniques can appear very strange. Also some off the default configuration items might appear somewhat strange.

In this day and age, it is simply not done to expose a server directly to the internet with just a name and password to get in. It is asking for trouble. And as we all know Novell Access Manager is "the" product to use for secure authentication. However Access Manager and SharePoint don't work together very well by default.

In this series of articles i would like to describe how to expose Sharepoint to the outside world through an Access Manager.

• Part one is the basic part, How to enable Sharepoint through AM and how to incorperate single sign on.

• Part two is all about the access to sharepoint when opening documents

• Part three is about using kerberos

• Part four will be about roles... We'll have to wait on some new releases.

   

Test Configuration

The configuration used in this article is based on a few customer sites a POC and a demo system we have build. It works with Access Manager 3.04 and 3.1 (there are some differences which will be described). In all cases Windows Server 2003 SP2 is used and SharePoint Enterprise.

I am not a Sharepoint Expert, i got some help on the Sharepoint configuration from some very good friends and maybe there is a better way to do it. Let us know!!!

In all of these implementations IDM in conjunction with WorkFlows and Role based provisioning is used to provision accounts to the AD that Sharepoint uses. SharePoint has been configured to use that immediately. Of course Sharepoint uses a MSSQL database which can be provisioned directly but this is very hard to do because of the huge amount of different tables that is used.

So let's get too it.

Enabling SharePoint as a protected resource.

This is where the troubles start. SharePoint has some security features build in which force you to some configuration.

The most importent one is that SharePoint requires to be addressed on its own DNS name. If you don't and still get into SharePont the AJAX scripts will not work because they are based on that DNS name.

The following configuration should work with Access Manager 3.04 and 3.1.

Step 1 Configure SharePoint

Sharepoint works with Web Aplications, Sites and Site Collections and of course the Shared Services Administration. You can compare this with JBoss Web Application server and an application such as the User Application.

DNS

There is a Central Administration Web Application with it's base URL and at least one other Web Application (default is Sharepoint - 80 or - 443) wih by default the same base URL as the Central Administration.

You can change this, but be aware of the DNS issues (see the Note below). You can also add another Web Application which runs on a different port. If you want to use the same port i guess you'll need to add another interface but from my view i can't choose the interface ;-(.

Secondly, you can create Site Collections which start of from the Web Application base URL. You can only add one from the base URL directly and any number in different web containers (f.e, sp.dirxml.nl is the base with a site collection and sp.dirxml.nl/sites/anIDM as different sites. This works pretty much the same as the IDM Application within the UserApp.

Any site collection can have a different DNS names (base)/web container. With Access Manager 3.04 you'll need to specify the same DNS name as the public DNS. With 3.1 you can do do a rewrite. (I do not know why that doesn;t work with 3.04)

Note ! Watch out for DNS conflicts! If you add the sites to the internal or public DNS (pointing to Access Manager), the Cental Administration (management interface) will still allow you access but you will not be able to access the site collections. If you use it's own DNS (preferred you'll need to add the DNS names for the Site Collections. Either way choose the DNS names wisely!!!

Warning : It is not possible to change DNS names after creation.... Choose well.

Security

By default, a Web Application works with NTLM, You have the choice to change this to Kerberos. SharePoint and Access Manager don't work together while using NTLM but we need to reconfigure that on a higher level. Kerberos will be handled in part 4.

In order to get things working we need to go to the Application Management,

• Choose Authentication Providers,

• Choose the correct Wen Application,

• Choose the Default Zone (Windows)

• Change the IIS Authentication Settiongs from "Integrated Windows Authentication" to "Basic Authentication"

You can also change the authentication type from "Windows" to "Forms"

And, as a special gift, you can use Web Single Sign on in order to use Federation !! So the Access Manager can be an authentication source for SharePoint using federation !!!!

You do not need to tell SharePoint that a reverse proxy is used. This only works with MS ISA (Yes acccording the MS documentation ISA server can do this).

Step 2 Create the nessecary policies.

We'll first discuss the policies in order to do a quick creation of the protected resource.

Authentication :

Our example is based on windows authentication on SharePoint, so we'll use an Identity Injection.

Of course when using "Forms" as an authentication we can use a Form Fill.

Most important is the account name. We have a couple of choices :

1. If the accountname is the same within the AM Datastore and the ADS we can use : Credential Profile, LDAP Credentials, LDAP User name. (CN or sAMAccountName)

2. If the accountnames are different we can use LDAP Attribute : DIRXML-ADAliasname (userPrincipalName) Both of these choices work if we have only one AD and no trusts.

3. If Trusts are used or if the CN is different we normally use an extra attribute which will be populated when provisioning to AD. This attribute (in this case dsSharePointLogin) contans the direct account name f.e. DOMAIN\UserName,

    

The policy looks like this

Form fills

We need to add some form fills to handle specific issues :

First is a logout policy to handle simultaniously logout. This will match the text on the logout screen, disconnects the AM session and redirect to the logout page .

The second one is a failed login. This only works when using Forms in Sharepoint to login. If Windows Login is used the login windows will popup continuously and there is now way to grab that event and exit. The only way to overcome this is to let the user cancel the login which will result in a HTTP 401.2 error and then we can use a form fill to redirect.

The policy will look like this

Last but not least is to handle the No Access pages.

This is an optional form fill. In all our implementations SharePoint Access Request are handled bij IDM UserApp Workflows or Roles. So in case a user has no access he or she can be redirected to the UserApplication.

It is a very nice feature to redirect directly to the correct Resource Request!!!

For this the User Application must be a protected resource in the User Application and using single sign. It also needs to use the same authentication contract or "Any contrect" The user is already authenticated to the AM so he or she will be redirected.

This policy will look like this :

Step 3 Create a protected resourse

Last but not least we need to create a protected resource : This is the easy part !!

1. Go to the Reverse Proxy you want the protected resource on.

2. Add a proxy service entry.

3. Use for Multi Homing type : "Domain Based"

4. If the published DNS of the sharePoint site is the same as the public DNS use "Forward Received Host Name" for the "Host Header"

   1. If the published DNS of the sharePoint site is NOT the same as the public DNS use "Web Server Host Name" for the "Host Header" and add the Sharepoint Published DNS name in the "Web Server Host Name" field.

1. Open the proxy service and open the HTTP option in the Proxy Service tab. Enable the "Enable X-Forwarded-For"

2. In the "Web Servers" tab enable the "Connect Using SSL" If needed and set the "Web Server Trusted Root" to "Do not Verify". You can also enable "Enable Forwarding of Browser's Encoding Header".

3. In the HTML rewriting tab, Enable HTML rewriting and add the SharePoint DNS name for the Central Adnministration site

4. Open the Protected Resouces tab and add a new protected resource

   1. Choose "/*" as the URL path

   2. Choose a contract. This can be (secure) basic or form. This choice depends on whether or not SSO to the documents are enabled (next part) and the authentication type in SharePoint. You cannot use form authentication in Access Manager without managing the secondary login in MS Office. The form would show up in Word, Excel and would be unusuable.

   3. It is also possible to add contract based on secure authentication!! Make sure you get the right authentication classes.

   4. Enable the Identity Injection we created earlier, when using Windows Logon in Sharepoint.

   5. Enbale the Form Fills (No Access, Login Error, and Logout. When using Forms Login in Sharepoint also enable the Login Form Fill

Save the configuration and update all the effected devices (Proxy, IDP etc)

You will now be able to access SharePoint through the Access Manager and use Single Sign On. Opening a document will generate a secondary Login but we'll handle that in the next part.

Succes, and if you have remarks i would love tio hear them

David

Many thanks to Jacques and Alex for their support on this.

Part two, the next part will be about using documents.

The main concern with this is that any of the office applications will spawn a new session which needs to be validated. When using the configuration described in this article you will get a secondary login. For some reason Microsoft has designed it in such a way that the session if managed by Office in stead of a browser. This is probably because it is possible to write and read from office without using a browser.