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 platforms 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.
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 to it.
This is where the troubles start. SharePoint has some security features build in which force you to some configuration.
The most important 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.
Sharepoint works with Web Applications, 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.
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/IDM 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 a rewrite. (I do not know why that doesn't;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.
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,
Settings 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 according the MS documentation ISA server can do this).
We'll first discuss the policies in order to do a quick creation of the protected resource.
Our example is based on windows authentication on SharePoint, so we'll use an Identity njection. 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 :
The policy looks like this.
We need to add some form fills to handle specific issues:
The policy will look like this.
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 contract" The user is already authenticated to the AM so he or she will be redirected.
This policy will look like this:
To finalize this we need to create a Proxy Service: This is the easy part!!
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
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.
Success, and if you have remarks I would love to hear them
Many thanks to Jacques and Alex for their support on this.