ADAM in ECTS

Topics: General/Misc.
May 6, 2008 at 2:48 PM
I am wondering why the design decision was made to use ADAM in the External Collaboration Toolkit for SharePoint (Community Edition)? Wouldn't using SQL Server as the authentication store made the deployment/setup/configuration much simpler?
Developer
May 7, 2008 at 1:49 PM
Hello Kevin,

It probably would have made things easier. But, there are many forward-compatibility advantages of basing the solution on ADAM. For instance, and we see a lot of interest in this, if you ever decide you want to use RMS for protecting docs that you share outside your organization then you will need to have your external users authenticate with AD. Since ADAM and AD are compatible at level we use the directory services, it is a simple matter to remove ADAM and drop a full-blown AD in the extranet.

Another advantage of using ADAM that we've already seen someone move forward with is using the logon redirect capabilities of ADAM. The scenario is that an internal user can hit the same external URL that the external users use. In ADAM, you create shadow accounts for each internal AD user. When logging on ADAM sees that this is a special kind of ADAM account and redirects the bind to AD. This is an elegant solution that keeps the actual sites and URLs to a minimum while maintaining only one account for your internal users to manage.

You can certainly make arguments that SQL would be better if you don't have these kinds of requirements (many won't), but we wanted to create something that was as flexible as possible and ADAM seemed to be the way to go. The price we are paying is that installation and management of ADAM is less understood.

Dave



kevingriffie wrote:
I am wondering why the design decision was made to use ADAM in the External Collaboration Toolkit for SharePoint (Community Edition)? Wouldn't using SQL Server as the authentication store made the deployment/setup/configuration much simpler?