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:-
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=184.108.40.206, 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=220.127.116.11, 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="(&(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=18.104.22.168, 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 ="(&(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 & - 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
You would'nt happen to have instruction on what the web.config file would like connecting to Sun One Server?
LDAP is standard so the web.config looking at Sun One Server should not need to be any different from one that connects to ADAM or any other LDAP conformant directory. The syntax is very particular though so easy to make typos with any server.
I follow the instuctions as specified but I just could not get my ADAM users authenticated in the project server using the newly created PWA using form authentication. Verify communication with the LDAP directory is fine using the Sharepoint Central Administration.
Do you have any suggestions what I should do to get it work?
If the verification is working OK then your settings in the web.config for Central Admin must be OK - perhaps they are not right in the web.config for your extended site? Or possibly the entry of the user in PWA does not match the providername:username format.
What error do you get?
I am using WSS3.0 and I found from other website that LDAPMembershipProvider is only supported in MOSS. Is that correct? If that is the case how would I proceed with LDAP authentication with Project Server 2007?
Thanks and Best Regards
LDAPMembershipProvider is certainly supported for Project Server 2007 and also for WSS 3.0 - as this forms the backbone of Project. Which site says it is only supported for MOSS? The notes above do not assume MOSS is present and once working the only thing required in Project Server 2007 is to add a user using the format LDAPMembership:Username - assuming LDAPMembership is the term you have used to name the sections in the web.configs as in the above examples. Have you found the recent TechNet article at http://technet2.microsoft.com/Office/en-us/library/e8e4644d-3570-4b7a-a5df-8e1b1d01b5fc1033.mspx which is specific to Project Server?
Thanks for your quick response, All the while I have been following the TechNet article that you referred for the setting up of the project web access site using form based authentication against LDAP (ADAM) store. I have completed all the steps but was having problem with the authentication on LDAP-authenticated site.
The errlog obtained is as follows:
"Event Viewer for ADAM instance:
Internal event: The LDAP server returned an error.
000004DC: LdapErr: DSID-0C09062B, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, vece
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp."
As for the information that LDAPMembershipProvider is only supported in MOSS, I got it from the comments of https://blogs.pointbridge.com/Blogs/morse_matt/Lists/Posts/Post.aspx?ID=2 and http://www.developerfood.com/trouble-configuring-wss3-and-moss-to-use-adam-cannot-find-adam-us/microsoft-public-sharepoint-setup-and-administration/7ed30c44-9692-4d2e-9864-0fb55100110f/article.aspx
After working further, I found that the LDAP(ADAM) server is receiving from a ANONYMOUS_LOGON from the PWA authenication. To proceed further, I enabled anonymous binding in ADAM by modifying the dsHeuristics attribute and tried logging on again, it was still unsuccessful. Now the event log says the following:
Event Type: Information
Event Source: ADAM [ADAMTest] LDAP
Event Category: (16)
Event ID: 1535
Time: 9:31:20 AM
User: NT AUTHORITY\ANONYMOUS LOGON
0000208D: NameErr: DSID-031521D2, problem 2001 (NO_OBJECT), data 0, best match of:
My web.config for the Project Server extension site is as follows:
<add name="ADAMMembership" type="Microsoft.Office.Server.Security.LDAPMembershipProvider, Microsoft.Office.Server, Version=22.214.171.124, Culture=neutral, PublicKeyToken=71E9BCE111E9429C" server="epm2007test" port="389" useSSL="false" useDNAttribute="false" userDNAttribute="distinguishedName" userNameAttribute="cn" userContainer="CN=users,OU=ADAMTest,O=ADAM,C=US" userObjectClass="user" userFilter="(ObjectClass=user)" scope="Subtree" otherRequiredUserAttributes="sn,givenname,cn" />
Would appreciate if you could provide more pointers.
So it does seem to be getting to the LDAP server. Are you using local service accounts perhaps within your Project Server installation that cannot get to the LDAP server? Or perhaps the user has been added to ADAM as an admin. I'm sure as part of the setup for ADAM there are some details on this.
For your info, my ADAM and Project Server are installed on the same machine and the Project Server is run using a local administrator account.
Since the last message, I've finally managed to get the PWA authentication to work. However, it is only after granting read access to ANONYMOUS_LOGON from ADAM (the setup instruction is to grant to Project Server's farm administrator). What puzzled me was that I was using the local (also farm) administrator's account to run Project Server. Yet the communication between Project Server and ADAM was through a anonymous logon. Is there anything wrong with that?
Interesting Ron. So if you look at task manager which accounts are running OWSTIMER, and also the instance of the Project Queue service?
I've checked. Both processes are run by local administrator accounts. Are there any consequences if the communicator is through ANONYMOUS_LOGON account?
Both OWSTIMER and the Project Queue service run using local administrator account.
For your information, I have tried setting up another LDAP server (OpenOLAP) on the PC and the result is similar; need to set anonymous logon to have authentication permission for user password on the OpenLDAP server.
Anyway I think as long as I could setup LDAP for projectserver 2007, that should be fine.
By the way do you know whether Projectserver 2007 support single sign-on with LDAP form-authentication?
I have this working on my server without ANONYMOUS LOGON given any rights in ADAM. The account making the requests in my case is the admin account for the farm, which also happens to be the identity for all the app pools and the admin for the SSP. Take a look at your app pools and see which identity they are running uner.
The other thing I came across today was that by default users added to ADAM are disabled. You need to set the msDS-UserAccountDisabled to FALSE before you can authenticate. Not sure when this changed - I'm sure you didn't need to do this when I first played with ADAM.
For SSO I'm not the best person to ask. The SharePoint blogs may be better - but are you asking if you can log on through LDAP forms and make use of single sign on provider to then go to other places? I would think this should be supported.
Thanks for your continuous support. I am ok with setting the ANONYMOUS LOGON with auth rights in ADAM.
Really appreciate your help and quick response for the past few days.