Extending Project Server 2010 for Extranet Users

by Martin Laukkanen | Jun 3, 2011 | How to, Project 2010, SharePoint 2010

A common requirement for many SharePoint and Project Server deployments is to have an external facing interface using an alternate Forms based authentication method, the most common is using an ASP.NET SQL provider which since the 2007 version is the one of the simplest options. With 2010 however and Claims authentication this requires that you convert your existing Windows authenticated Web Applications to Claims based NTLM authentication, this process is well documented online for SharePoint 2010, however I have recently found that with Project Server 2010 a number of problems can be encountered.

Here is a typical error with the Project Details webpart after conversion:

[Hi Google: (An unknown error has occurred)]

In this blog I’m not going to cover the whole process of setting up Extranet access, I’ll leave it to you to read some of the other excellent blogs on the topic linked below. What I will cover is how to do the not-so-well documented parts.

To Start With: Procedure to Setup Extranet Access

The general procedure for extending a Project Server application for extranet users is something like this:

1. Provision a ASP.NET SQL membership Provider.
2. Extend the Web Application to add an Extranet zone.
3. Configure the Claims membership providers in the web.config files.

References for these steps:

1. MMohanty: http://blogs.technet.com/b/mahesm/archive/2010/04/07/configure-forms-based-authentication-fba-with-sharepoint-2010.aspx
2. Geoff Varosky: http://gvaro.wordpress.com/2011/03/28/planning-and-configuring-extranets-in-sharepoint-2010part-1/
3. Geoff Varosky: http://gvaro.wordpress.com/2011/04/01/planning-and-configuring-extranets-in-sharepoint-2010part-2/

If you have followed those steps discussed in the links, then when you will likely have found that you are seeing all sorts of security issues after changing your Classic Web App to Claims.

In short the error above originates from the procedure used to migrate the application to Claims:

(WARNING: Don’t use the above commands!)

Unfortunately this does not fully migrate the SharePoint application and from my experience will lead to errors such as the first one above.

Migrating the Web Application to Claims Without Issues

Fortunately Microsoft has a well documented procedure: http://technet.microsoft.com/en-us/library/gg251985.aspx

$WebAppName = "http:// yourWebAppUrl"
$account = "yourDomainyourUser"
$wa = get-SPWebApplication $WebAppName

Set-SPwebApplication $wa -AuthenticationProvider `

  (New-SPAuthenticationProvider) -Zone Default

Note: that the above commands migrate ALL Web Applications sharing that URL, it is not possible to only migrate your Extended application!

That command will migrate the web application fully and prepare it for Claims authentication, and don’t forget the TechNet article discusses the need to update your portalsuperreaderaccount and portalsuperuseraccount accounts if they have been set, which can be done easily using the following commands:

$wa.Properties["portalsuperuseraccount"] = "i:0#.w|domainapppool"

$wa.Properties["portalsuperreaderaccount"] = "i:0#.w|domainapppool"

$wa.Update()

Migrating Users to Re-enable Login

Once your Web App is in Claims mode then you will still need to migrate your AD users, this part is not so well documented.

Essentially you need to use the PowerShell command Move-SPUser to move all of your existing “DOMAINusername” users to the new Claims-NTLM identity “i0#.w|domainusername”.

Before you can do this you need to ensure that your admin user has permissions to access this site, this can be done from Central Admin by updating the Web Application Policy:

Add or re-add your user account (DOMAINadminuser) with Full Control to the web application in question, before proceeding with the following steps. (Note: the above Policy should now show your Admin user with the User Name like so; “i:0#.w|domainadminuser”)

Next, here is the command to migrate a single user:

Get-SPUser -web http://server/pwa -identity "DOMAINuser" | Move-SPUser -NewAlias "i:0#.w|domainuser" –IgnoreSID

The command will actually give the following error:

However if you then use Get-SPUser you will note that the account has actually been migrated.

So for my purposes I wrote the following script which will migrate all users without the claims prefix “i:0#.w|” (Yep ignore those errors!):

$UsersToMigrate = Get-SPUser -web http://server/pwa | `

  where {$_.UserLogin –like ‘DOMAIN*’ }

 

ForEach ($user in $UsersToMigrate)

{

  Get-SPUser -web http://server/pwa -identity $user | Move-SPUser `

    -NewAlias ("i:0#.w|"+$user.UserLogin.toLower()) -IgnoreSID

}

After running the above, users should now be able to login to your migrated Web Application with any AD user!

If you see other errors running either that script or the above command by itself, make certain that you can do the following without errors:

Get-SPUser –web http://server/pwa

If not check your web policy again as above.

Finally Adding Your Claims Users to PWA

Now we have a fully migrated Claims-NTLM Web Application in addition to a newly created Extranet Claims Web Application which is attempting to use a Forms membership provider (SQL-MembershipProvider if you following the steps linked above).

The next steps are again well documented in the links above, configure your web.config files and then setup your SQL users.

The final problem you may face when attempting to add your new forms users to PWA, assuming (if using SQL that your ASPNETDB database permissions are correctly set) then adding the users to SharePoint will be easy using Site Actions – Site Permissions – Grant Permission, however what you will may see when attempting to add to Users to PWA is an error like the following:

(Error Message: The NT account specified is invalid. …)

This is because the user has not yet been added to the SharePoint site collection which fortunately is easy enough to fix, just add the user to SharePoint from Site Permissions first!

From Site Actions –> Site Permissions:

As long as SharePoint can find the user (make sure to use the full username!) then once you hit Ok the user identity will be added to the Site Collection, and then you will be able to add the user to PWA!

FYI if like me you like doing things in bulk here’s the PowerShell command to do the above:

New-SPUser -UserAlias "i:0#.f|SQLMembershipProvider|JaneDoe" -Web http://server/pwa -DisplayName "Jane Doe" -Email [email protected]

All done, enjoy your forms membership provider!