Making automatic user provisioning for forms-based authentication work

Статья
03/05/2014

This blog post will help identify and resolve common problems related to making automatic user provisioning for forms-based authentication work for Ax2012R2.

Environment: Environment is assumed to look something like this:

One intranet-facing Enterprise Portal using integrated Windows authentication, configured as the default Enterprise Portal in AX
One internet-facing claims-aware Enterprise Portal using Forms authentication, set up using the instructions on technet.microsoft.com/en-us/library/hh575253.aspx
The User request workflow contains the automated task Automated provision user

When creating a new vendor request, from System administration > Common > Users > User requests, there several things can go wrong without additional environment configuration.

Issues and resolutions

Invalid attempt to call sysEPWebPageDefinition.getDevelopmentSite

In AX2012R2, the task Automated provision user will fail with the following error:

Stopped (error): Stack trace: Invalid attempt to call sysEPWebPageDefinition.getDevelopmentSite running in CIL on the client.

Opening the class sysEPWebPageDefinition in the development environment gives the answer pretty quickly:

This class is only possible to invoke from a client – but the workflow runs in server context.

Changing this property to the default value Called from resolves this particular error.

SoapException

In AX2012R2, after correcting the class metadata, the Automated provision user task still does not work. Submitting a user request yields the following error:

Stopped (error): Exception of type 'Microsoft.SharePoint.SoapServer.SoapServerException' was thrown.

A SoapException is a very generic exception with little useful information. If the Sharepoint trace logging level is Medium or higher, a more useful error message can be spotted in the Sharepoint logs:

SOAP exception: System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.Configuration.Provider.ProviderException: The connection name 'FormsDB' was not found in the applications configuration or the connection string is empty.

This exception is thrown from a service, EPDeploymentService, which is invoked on the default Enterprise Portal site, because it is missing a connection string to the ASP.NET database. The default Enterprise Portal does not need to support forms authentication, but in order to create new users it needs to know what database to update.

Configuring the connection string

The connection string needed is actually already configured – but not for any of the Enterprise Portal instances, it is configured only for the forms-based authentication provider. To resolve the problem, this connection string needs to be configured for the default Enterprise Portal as well.

The connection string can be found in the web.config file for the STS, which is typically located in %CommonProgramFiles%\microsoft shared\Web Server Extensions\14\TEMPLATE\LAYOUTS\FormsSTSTemplate

The section should look like this:

Adding the above section to the web.config for the default Enterprise Portal can be done with the Sharepoint Management Shell:

$Section = New-Object Microsoft.SharePoint.Administration.SPWebConfigModification
$Section.Path     = "/configuration"
$Section.Name     = "connectionStrings"
$Section.Sequence = 0
$Section.Owner    = "Connection string for ASP.NET DB"
$Section.Type     = [Microsoft.SharePoint.Administration.SPWebConfigModification+SPWebConfigModificationType]::EnsureSection

$Mod = New-Object Microsoft.SharePoint.Administration.SPWebConfigModification
$Mod.Path     = "/configuration/connectionStrings"
$Mod.Name     = "add[@name='FormsDB']"
$Mod.Sequence = 1
$Mod.Owner    = "Connection string for ASP.NET DB"
$Mod.Value    = '<add name="FormsDB" connectionString="Data Source=.;Initial Catalog=aspnetdb;Trusted_Connection=true" />'
$Mod.Type     = [Microsoft.SharePoint.Administration.SPWebConfigModification+SPWebConfigModificationType]::EnsureChildNode

$WebApp = Get-SPWebApplication "SharepointServer:Port/ "
$WebApp.WebConfigModifications.Add($Section)
$WebApp.WebConfigModifications.Add($Mod)
$WebApp.Update()
$WebApp.Parent.ApplyWebConfigModifications()

Replace the URL SharepointServer:Port/ with the URL for the web application that hosts the default Enterprise Portal. If a custom connection string was used when setting up the ASP.NET database, that value will be present in the configuration file instead of the default value used here. If this is the case, enter the custom connection string in setting the property $Mod.Value.

After updating the configuration, the User request workflow will execute without errors.

Other caveats

Because the workflow executes a service on the default Enterprise Portal, there are a few other things that can go wrong.

The workflow might stop with one or more of the following errors:

Stopped (error): The request failed with HTTP status 401: Unauthorized.

This happens because the AOS runs as a service account and is therefore not allowed to access the Sharepoint site. Granting the service account read access to the Sharepoint web application that hosts the default Enterprise Portal will resolve this error.

Stopped (error): Server was unable to process request. ---> Object reference not set to an instance of an object.

In this case, the Application event log holds the key to figuring out this error. From the event source, Microsoft Dynamics AX Enterprise Portal,there should be a message like this:

The log on attempt to the server from user [AOS Service Account] failed, when using Dynamics Adapter LogonAs from process w3wp and thread id 37.

Microsoft.Dynamics.AX.ManagedInterop.LogonFailedException

at Microsoft.Dynamics.AX.ManagedInterop.Session.LogonAs(String user, String domain, NetworkCredential bcProxyCredentials, String company, String language, String objectServer, String configuration, String tenant)

at Microsoft.Dynamics.Framework.BusinessConnector.Session.DynamicsAdapter.LogonAs(String user, String domain, NetworkCredential bcProxyCredentials, String company, String language, String objectServer, String configuration, String partitionKey)

The workflow tried to invoke the web service but the user it executed as did not exist in AX. To resolve this, the AOS service account must exist as a user in AX with role System Administrator. (Please note that if the service account does not have the System Administrator role, the workflow will still fail with an object reference exception but no useful error message will be logged.)

Resolution summary

Enabling automated user provisioning for forms-based authentication requires the following environment modifications:

The connection string to the ASP.NET database must be added to the web.config for the default Enterprise Portal
The service account the AOS runs as must exist as an AX user with System administrator role
For AX2012R2, the property RunOn on class sysEPWebPageDefinition must be changed to Called from

Comments

Anonymous
March 11, 2014
hi I need to redirect my STS portal for the claimlogonselector (I have regenerated my CSS portal and now the FBA site is pointing to the old site) how do I fix this?
Anonymous
March 13, 2014
Wayne, It seems that your question is unrelated to this specific post.

It relates to CSS. If your scenario is something like this:

You have set up Customer Self-Service, and configured EP to use Forms authentication
You have re-generated it somehow, and apparently it has a new address
When you browse to the ‘new’ site you are redirected to a Forms-based login page (the STS)
When entering credentials you are then redirected to the ‘old’ site

There are two ways to address it:
1. Create a new STS for the new site (it can even share the same user database as the old one)
2. Reconfigure the existing STS to redirect to the new site

Hope it helps.

If this is not your scenario or the 2 solution options do not Work, then please contact your partner or MS support.

Поделиться через