Project Server 2007 with LDAP Authentication

For customers that used Project Server 2003 and made use of the “ProjectServer” accounts (non-Windows authenticated) they have a few choices in Project Server 2007. The first consideration I suggest is “why were you using ProjectServer accounts?”. If the answer is that you don’t have Windows domains but use some other authentication method, and LDAP is that other method – then I have good news! LDAP is a supported authentication provider for Windows SharePoint Services v3, and therefore Microsoft Office Project Server 2007 as well.

I can see this being a popular authentication method for those customers who do not use Windows Authentication but have some other directory as it enables them to re-use the directory they have - rather than have to create a whole new set of users in some other place (such as the ASP.NET SQL Membership Provider database).

For my tests with LDAP I used Microsoft ADAM (Active Directory Application Mode) to be my Lightweight Directory Access Protocol service - but you should be able to use any LDAP compliant service. 

The basic steps once you have a LDAP source to authenticate against is:-

1. Extend your port 80/443 site to another port (and I would strongly recommend this extended site use SSL!) and zone - such as Intranet
2. Set the Authentication Provider for this new zone to LDAPMembership - through Central Administration, Operations, Authentication Providers (this is just a name and needs to match the provider you add to the web.config files
3. Edit the web.config(s) for the SharePoint Central Administration and also our newly extended site to add our membership provider LDAPMembership
4. Add a Windows SharePoint Services user through Central Administration, Operations, Policy for Web Application for our Intranet zone using the format LDAPMembership:User1
5. Add a Project Web Access user with forms authentication again using the format LDAPMembership:User1

There is a blog from Matt at Pointbridge that gives more in-depth details - thanks Matt.  As the trickiest piece I found was getting the format of the addition to the web.config to match the structure of your LDAP directory I will just go into more detail on that step.

The section needs to go into the top level <system.web>...</system.web> section - just make sure not to break any existing XML.  I usually put it at the end, just before </system.web>.  Also be aware that there are some other <system.web> sections that are lower down the hierarchy - under the <location> section I think.  Don't put it in these!

So a sample membership section may look like this:-

<membership defaultProvider="LDAPMembership">
  <providers>
    <add name="LDAPMembership" type="Microsoft.Office.Server.Security.LDAPMembershipProvider, Microsoft.Office.Server, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71E9BCE111E9429C"
    server=“nondomain"
    port="50000"
    useSSL="false"
    userDNAttribute="distinguishedName"
    userNameAttribute="cn"
    userContainer="CN=Users,OU=WSS,O=nondomain,C=US"
    userObjectClass="user" 
    userFilter="(ObjectClass=user)" 
    scope="Subtree" 
    otherRequiredUserAttributes="sn,givenname,cn" />
  </providers>
</membership>

and this would match up to a directory where the LDAP server was called "nondomain" and was set to use port 50000 (port 389 is the default LDAP would normally use) and this would authenticate against any objects in the userContainer that matched the userFilter - and use the distinguished name as the name to match.  So in this case all items in the container defined by CN=Users,OU=WSS,O=nondomain,C=US that have an object class of user.  LDP.exe is a good toll that you can find in the Windows 2003 Support tools that helps to understand the containers and filters.

Another more complex example would be:-

<membership defaultProvider="LDAPMembership">
<providers>
<add server="ps2007ldap" port="50000" useSSL="false"   userDNAttribute="distinguishedName"
userNameAttribute="cn" userContainer="CN=Users,OU=Support,O=fabricam,C=US"
userObjectClass="user" userFilter="(ObjectClass=user)" scope="Subtree"
otherRequiredUserAttributes="sn,givenname,cn" name="LDAPMembership"
type="Microsoft.Office.Server.Security.LDAPMembershipProvider, Microsoft.Office.Server, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71E9BCE111E9429C" />
<add server="ps2007ldap" port="50000" useSSL="false" userDNAttribute="distinguishedName"
userNameAttribute="cn" userContainer="CN=Users,OU=Extranet,O=fabricam,C=US"
userObjectClass="user" userFilter="(&amp;(memberOf=CN=ProjectUsers,OU=Extranet,O=fabricam,C=US)(memberOf=CN=WSSUsers,OU=Extranet,O=fabricam,C=US))" scope="Subtree"
otherRequiredUserAttributes="sn,givenname,cn" name="LDAPMembership2"
type="Microsoft.Office.Server.Security.LDAPMembershipProvider, Microsoft.Office.Server, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71E9BCE111E9429C" />
</providers>
</membership>

and in this case there are two providers (this would be in the Central Admin web.config - each of the 2 extended sites in this case would just have either the LDAPMembership or LDAPMembership2 section) authenticating for two different zones - such as Intranet and Extranet. 

LDAPMembership is authenticating against users in the CN=Users,OU=Support,O=fabricam,C=US container.

LDAPMembership2 is authenticating against users in the same container, but this time using the filter with the filter ="(&amp;(memberOf=CN=ProjectUsers,OU=Extranet,O=fabricam,C=US)(memberOf=CN=WSSUsers,OU=Extranet,O=fabricam,C=US))"  which will only authenticate users in both the ProjectUsers and WSSUsers groups defined in the directory.  Please note the &amp; - which replaces the usual & used in LDAP queries.

You will also see format of these sections is different from the one above - but still contains exactly the same attributes - just in a different order.  This is as a result of editing through the InetMgr interface.  Please be aware of a potential break caused by using the InetMgr UI - the <configuration> element gets re-written as <configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0"> and this will give an application error in WSS.  See KB 917238 for details.

Have fun with LDAP - I think this may be the most popular of the additional authentication providers - and this time the "projectserver" users will be able to get at all the SharePoint content such as risks, issues and documents - as well as the new feature - deliverables. However, like the 2003 "projectserver" users, these forms based users would still need a Windows account to use the Data Analysis (OLAP Cube) features that SQL Server Analysis Services provides.

Technorati Tags: Project Server 2007