Deploy an Enterprise Portal site that uses AD FS authentication
Important
This content is archived and is not being updated. For the latest documentation, see Microsoft Dynamics 365 product documentation. For the latest release plans, see Dynamics 365 and Microsoft Power Platform release plans.
Applies To: Microsoft Dynamics AX 2012 R3
This topic describes how to deploy Enterprise Portal for Microsoft Dynamics AX in an Active Directory Federation Services (AD FS) environment. AD FS simplifies access to systems and applications by using a claims-based authorization mechanism to help maintain application security. AD FS supports web single sign-on technologies that help IT organizations collaborate across organizational boundaries. AD FS is a server role in Windows Server 2008 R2 and Windows Server 2012. For more information about AD FS, see Active Directory Federation Services.
This topic includes the following sections.
Before you begin
Pre-installation tasks
Install Enterprise Portal binaries
Enable SharePoint Claims to Windows Token Service
Create a claims-aware Enterprise Portal site
Register an SSL certificate on the AD FS server
Install Active Directory Federation Services 2.0
Add a trusted relying party
Manage the AD FS token-signing certificate
Specify the claims provider in SharePoint
Register the AD FS signing certificate as a trusted root authority with SharePoint
Create a new user for AD FS authentication
Assign security roles for users
Validate AD FS configurations
Troubleshooting AD FS issues
Specify which trusted identity provider is available for users at logon
Before you begin
Complete the following tasks before you install Enterprise Portal.
Task |
Details |
---|---|
Install Microsoft Dynamics AX hotfixes for claims-mode authentication (required for Microsoft Dynamics AX 2012 R2 or earlier; not required for Microsoft Dynamics AX 2012 R3). |
|
Create a domain account |
Create a domain account for the Microsoft Dynamics AX .NET Business Connector proxy. Warning The account should not be a member of the Microsoft Dynamics AX system administrator group or a member of the Windows administrator group on the Enterprise Portal server. The login should not be used for standard logon purposes. Only those individuals who are responsible for deploying and configuring Microsoft Dynamics AX should know the credentials for this login. If a malicious user gained access to the credentials for this login, that person could potentially impersonate any Microsoft Dynamics AX user. Enter the account in the Microsoft Dynamics AX client on the System administration > System > System service accounts form. |
Install SharePoint |
After you install SharePoint on the web server, run the SharePoint configuration wizard. Specify the Microsoft Dynamics AX .NET Business Connector proxy account on the Specify Configuration Database Settings > Specify Database Access Account page of the SharePoint configuration wizard. |
Compile Microsoft Dynamics AX if you installed any non-SYS layer mode files |
If you installed a non-SYS layer model file in the Microsoft Dynamics AX environment, compile Microsoft Dynamics AX before you install Enterprise Portal. If you do not compile Microsoft Dynamics AX, the Enterprise Portal installation might fail. |
Download and deploy language packs |
If you want to deploy Enterprise Portal in multiple languages, download and deploy the SharePoint language packs on the Web server before you install Enterprise Portal. You must create a unique Web application in SharePoint for each language. You can download language packs from Microsoft.com. |
Verify the server name |
Verify that the name of the server that will host Enterprise Portal does not include an underscore, for example EPserver_1. If an Enterprise Portal server includes an underscore in the server name, lookups and web pages might display errors. |
Verify prerequisites and system requirements |
On the computer where you will install Enterprise Portal, run the prerequisite validation utility to verify that system requirements have been met. For information about how to run the prerequisite validation utility, see Check prerequisites. For more information about the hardware and software requirements for Microsoft Dynamics AX, see the system requirements. |
Verify permissions |
Verify that you have the appropriate permissions to install Enterprise Portal. If you are installing Enterprise Portal on a server that already hosts an Enterprise Portal deployment and you want to overwrite that deployment, you must have Full Control permission in SharePoint for the existing Enterprise Portal site collection. If you do not have Full Control permission, you will not be able to delete the existing site collection by using Setup. For more information about permissions, see Verify that you have the required permissions for installation. |
Verify SSL settings |
For Secure Sockets Layer (SSL) encryption, you cannot install Enterprise Portal on a web application that is already configured to use HTTP and HTTPS bindings. You must remove the HTTP binding from the site by using Internet Information Services (IIS) Manager before you install Enterprise Portal. |
Pre-installation tasks
Perform the following tasks to verify that you can deploy Enterprise Portal on the web server.
Verify that you can open SharePoint Central Administration on the Enterprise Portal server.
Verify that you have the appropriate permissions to create sites by using SharePoint Central Administration to create a SharePoint team site.
Verify that you can browse the team site without prompts and resolve the URL without proxy errors or other problems.
If you intend to deploy or configure Enterprise Portal at a command prompt, verify that you can start the SharePoint Management Shell.
Install Enterprise Portal binaries
This section describes how to install Enterprise Portal binaries by using Setup. During this initial install, you will not install create an Enterprise Portal site. You will create the site later in this document.
Start Microsoft Dynamics AX Setup. Under Install, select Microsoft Dynamics AX components.
Advance through the first wizard pages.
If the Setup Support files have not yet been installed on the computer, the Select a file location page is displayed. The Setup Support files are required for installation. Enter a file location or accept the default location, and then click Next. On the Ready to install page, click Install.
If you’re installing AX 2012 R3, in the Select an installation option page, click Microsoft Dynamics AX.
On the Select installation type page, click Custom installation, and then click Next.
On the Select components page, select Enterprise Portal (EP) and .NET Business Connector, and then click Next.
On the Prerequisite validation results page, resolve any warnings or errors. For more information about how to resolve prerequisite errors, see Check prerequisites. When no warnings or errors remain, click Next.
On the Select a file location page, select the location where you want to install 32-bit versions of Microsoft Dynamics AX files, and then click Next.
On the Specify a location for configuration settings page, specify whether you want Enterprise Portal to access configuration information from the registry on the local computer or from a shared configuration file. If you select to use a shared configuration file, you must enter the network location of the file. Click Next.
On the Connect to an AOS instance page, enter the name of the computer that is running the Application Object Server (AOS) instance that you want to connect to. If necessary, verify name of the AOS instance, the TCP/IP port number, and the WSDL port for services before you click Next. If the AOS details are correct, click Next.
On the Specify Business Connector proxy account information page, enter the user name and password for the proxy account that is used by the .NET Business Connector. Click Next.
On the Configure a Web site for Enterprise Portal page, select the SharePoint – 80 (SharePoint Web application). If no web applications are available in the list, you must cancel Setup, create a web application by using SharePoint Central Administration, and then try the installation again.
Warning
Do not select any other options on this page. Verify that you specified the SharePoint – 80 web application and that all other options are cleared before you click Next.
Click Next.
On the Prerequisite validation results page, resolve any errors. When no errors remain, click Next.
On the Ready to install page, click Install.
After the installation is complete, click Finish to close the wizard.
Important
Before you proceed to the next section, verify that the .NET Business connector proxy account was added to the WSS_WPG group on the web server computer: From a command prompt type net localgroup wss_wpg and press Enter.
Register an SSL certificate on the AD FS server
For testing, you can create a self-signed SSL certificate. If you create self-signed certificates, we recommend that you have one self-signed SSL certificate for the Enterprise Portal server (SSLCert1) and one self-signed SSL certificate for the AD FS server (SSLCert2). For more information, see Create a Self-Signed Server Certificate in IIS 7.0. For production servers, you must register an SSL certificate from a certification authority on the AD FS server. The certificate will help make sure that the user’s claim was not changed in transit. We recommend that you register separate SSL certificates for the AD FS and Enterprise Portal servers. After you have created self-signed certificates or acquired certificates, complete the following procedure.
On the Windows Server that will host the claims-based Enterprise Portal site, click Start > Run, type mmc, and then click OK.
Click File > Add/remove snap-in.
Click Certificates, and then click Add.
When the system prompts you to specify which type of account to manage certificates for, click Computer Account, and then click Next.
Click Local computer, and then click Finish.
In the Add or Remove Snap-ins dialog box, click OK.
In MMC snap-in, click the Certificates (Local Computer) node.
Right-click Personal, and then click All tasks > Import. The Certificate Import Wizard opens. Click Next.
Browse to the certificate, and then click Next.
Enter the password for the certificate, and then click Next.
Select the Mark this key as exportable option, and then click Next. The Certificate Store dialog box appears.
Click Next.
Click Finish.
Enable SharePoint Claims to Windows Token Service
You must enable the SharePoint claims to Windows token service (C2WTS) for claims-based authentication. Use the following procedure to start this service.
In SharePoint Central Administration, under System Settings, click Manage services on server.
Locate the Claims to Windows Token Service.
In the Action column, click Start.
In Windows, click Start > Run, type services.msc and press Enter.
In the Services console, verify that the Claims to Windows Token Service is running.
Note
Do not use the services.msc to start the C2WTS because the service will be automatically disabled after a period of time. You must use SharePoint Central Administration to start this service.
Create a claims-aware Enterprise Portal site
This section describes how to create a claims-aware Enterprise Portal site by using a Microsoft Windows PowerShell cmdlet. The cmdlet in this section first creates a claims-aware web application in SharePoint, and then deploys an Enterprise Portal site on that web application. If you are not familiar with Windows PowerShell cmdlets for Microsoft Dynamics AX, see Administering Microsoft Dynamics AX by using Windows PowerShell for more information. You can also create a claims-aware Enterprise Portal site on an existing SharePoint web application. Complete one of the following procedures.
Create a claims-aware site on a new SharePoint web application
Create a claims-aware site on an existing SharePoint web application
Create a claims-aware site on a new SharePoint web application
Note
Windows PowerShell includes a security setting called the execution policy that determines how scripts are run. By default, the execution policy is set to Restricted, which prevents any scripts from running. To run the installation scripts for Microsoft Dynamics AX components, we recommend that you set the execution policy to RemoteSigned by using Set-ExecutionPolicy cmdlet. This setting allows you to run scripts that you’ve written and scripts that have been signed by a trusted publisher.
Open the Microsoft Dynamics AX 2012 Management Shell with administrator privileges. Click Start > Administrative Tools > right-click Microsoft Dynamics AX 2012 Management Shell and click Run as administrator.
Enter the following command and press Enter.
$Cred=Get-Credential
When prompted, enter the credentials for the .NET Business Connector proxy account. The credentials must be the .NET Business Connector proxy account and password that were specified when Enterprise Portal binaries were installed earlier in this document. If you specify an account other than the .NET Business Connector proxy account, then the cmdlet overwrites the existing .NET Business Connector account, which can cause existing Enterprise Portal installations to stop working. Also note, this cmdlet designates the .NET Business Connector proxy account as the Enterprise Portal site administrator.
Execute the following command, replacing “PathToSSLCert1” with the path to SSLCert1, which you imported earlier in this document.
$SSLCert = Get-PfxCertificate "PathToSSLCert1"
When prompted, enter the password that you specified when you exported the SSL certificate.
On the Enterprise Portal server, execute the New-AXClaimsAwareEnterprisePortalServer cmdlet. For descriptions of the required parameters and syntax, see New-AXClaimsAwareEnterprisePortalServer on TechNet.
The following example shows the cmdlet with the required parameters. Note that the port value of 8000 is a user-defined value. You can specify any available port number. If you specify port 443, then you do not need to specify the port number when you type the web site URL.
new-AXClaimsAwareEnterprisePortalServer -Credential $Cred -Port 8000 -SSLCertificate $SSLCert
This cmdlet can take several minutes to be completed. After the cmdlet is completed, you can access a new instance of Enterprise Portal at the following URL: https://ServerName:PortNumber/sites/DynamicsAx.
Browse this site to verify that the command was executed properly. If you viewed the site, then you skip to the section titled “Install Active Directory Federation Services 2.0” in this topic. If you were not able to view the site, see the section titled “Troubleshooting issues with a claims-aware site”.
Create a claims-aware site on an existing SharePoint web application
If you want to create a new claims-aware site on an existing SharePoint web application, note the following requirements.
The web application must be configured for Integrated Windows/NTLM authentication in SharePoint Central Administration. This is required even if the web application is already configured as a claims-mode web application.
You must be a member of the site collection administrator group in SharePoint to perform the following procedures.
Important
We recommend that the web application be configured with SSL to enhance data security.
Verify that the existing web application uses the Windows authentication provider
Use the following procedure to verify that the existing web application uses the Windows authentication provider.
In SharePoint Central Administration, click Application Management.
Under Web applications, click Manage web applications.
Click the application and then click Authentication Providers.
Verify that the Zone lists Default and the Membership Provider Name lists Windows.
Click the Zone link.
In either the IIS Authentication Settings section or the Claims Authentication Types section, verify that Integrated Windows and NTLM are selected.
Save your changes.
Create an Enterprise Portal site on the web application
Choose one of the following options to create an Enterprise Portal site on the existing web application.
Use Microsoft Dynamics AX Setup
Use Microsoft Dynamics AX 2012 Management Shell
Use Microsoft Dynamics AX Setup
To create an Enterprise Portal site on the existing web application by using Microsoft Dynamics AX Setup, complete the procedure described earlier in this topic under “Install Enterprise Portal binaries”. However, when you perform that procedure, you must select the existing web application and select the following options: Configure for Windows SharePoint Services, Create Web site, and Restart IIS after installation is completed.
Use the Microsoft Dynamics AX 2012 Management Shell
You can create an Enterprise Portal site on the existing web application by using the Microsoft Dynamics AX 2012 Management Shell.
Determine the name of the web application where you want to create the site. In SharePoint Central Administration, click Manage web applications. Find the name of the application. For example, SharePoint – 443.
On the Enterprise Portal server, execute the New-AXClaimsAwareEnterprisePortalServer cmdlet by using the following parameters.
new-AXClaimsAwareEnterprisePortalServer -Credential $Cred –WebApplication “ExistingWebApplicationName”
For example: new-AXClaimsAwareEnterprisePortalServer -Credential $Cred –WebApplication “SharePoint - 443”
This cmdlet can take several minutes to be completed. After the cmdlet is completed, you can access a new instance of Enterprise Portal at the following URL: https://ServerName:PortNumber/sites/DynamicsAx. Browse this site to verify that the command was executed properly. If you viewed the site, then you skip to the section titled “Install Active Directory Federation Services 2.0” in this topic. If you were not able to view the site, see the section titled “Troubleshooting issues with a claims-aware site”.
Troubleshooting issues with a claims-aware site
Error: A specified logon session does not exist.
This error is caused by incorrect certificate information. Verify that you selected Mark this key as exportable when you imported the certificate.
Error: Setup could not find the IIS virtual server by using the name you specified.
This error occurs when the web application and Enterprise Portal site already exist on the server, so that the Windows PowerShell cmdlet detects a conflict.
To resolve this issue:
Click Start > Administrative Tools > Internet Information Services (IIS) Manager.
Expand the server node, and then expand the Web sites node.
Click the Enterprise Portal site.
In the center pane, under IIS, double-click Authentication.
Click ASP.NET Impersonation, and then, in the Actions pane, click Disable.
Use Microsoft Dynamics AX Setup to install Enterprise Portal on the web application created by the New-AXClaimsAwareEnterprisePortalServer cmdlet. For more information, see Install Enterprise Portal on TechNet.
Note
On the Configure a Web site for Enterprise Portal page of the Setup Wizard, clear all options. You will configure SharePoint and create the website later in this procedure.
After you install Enterprise Portal on the web application, click Start > SharePoint Central Administration.
Click Application Management.
Under Site Collections, click Create site collections.
Under Select a template, click the Custom tab.
Select the Microsoft Dynamics Enterprise Portal template.
After SharePoint creates the site collection, select the Enterprise Portal site in IIS Manager.In the center pane, under IIS, double-click Authentication.
Enable ASP.NET Impersonation authentication.
Install Active Directory Federation Services 2.0
This section describes how to install AD FS on an Enterprise Portal server.
Download AD FS, and run Setup.
When prompted to select a server role, click Federation server.
After the installation is completed, restart the server as recommended by Setup, and then run the AD FS 2.0 Management tool. In Windows, click Start > Administrative Tools > AD FS 2.0 Management.
Under Configure This Federation Server, click AD FS 2.0 Federation Server Configuration Wizard.
Click Create a new Federation Service, and then click Next.
Click Stand-alone federation server, and then click Next.
Specify the SSL certificate that you created earlier in this document, and then click Next.
Complete the wizard. AD FS creates a new application named adfs on the Default Web Site in IIS.
Add a trusted relying party
A relying party trust is a trust object that is created to maintain the relationship with a Federation Service or an application that consumes claims from the Federation Service. This section describes how to configure a trusted relying party in AD FS 2.0 Management.
In AD FS 2.0 Management, click Require: Add a trusted relying party. The Add Relying Party Trust Wizard opens.
Click Start.
Click Enter data about the relying party manually, and then click Next.
In the Display Name field, enter a name, such as ADFS Sign-on, and then click Next.
Click ADFS 1.0 and 1.1 profile, and then click Next.
In the WS-Federation Passive URL field, enter the URL of the claims-aware Enterprise Portal site. The URL must use the following format: https://ServerName:portnumber/_trust/. The server name and port must be the values that you specified earlier in this document when you created the claims-aware Enterprise Portal site.
For example: https://TestServer:8000/_trust/
Type an identifier in the format urn:ServerName:ProviderName, and then click Add.
For example: urn:TestServer:ADFSProvider
Remove the following entry from the list of providers: https://ServerName:PortNumber/_trust/
Click Next.
Click Permit all users to access this relying party, and then click Next.
On the Ready to Add Trust page, click Next.
On the Finish page, click Open the Edit Claim Rules for the relying party trust.
Click Add Rule.
Select the Send LDAP Attributes as Claims claim rule template, and then click Next.
Enter a claims rule name, such as ADFS sign-on.
In the Select an attribute store section, click Active Directory.
Click LDAP Attribute, and then click SAM-Account-Name.
In the Outgoing claim type section, click E-mail address.
Click Finish.
Manage the AD FS token-signing certificate
In AD FS 2.0 Management, expand Service, and then click Certificates.
In the center pane, in the Token-signing section, right-click the CN=ADFS Signing certificate, and then click View Certificate.
Click Details, and then click Copy to file.
Save the file as Name.cer by using the DER Encoded Binary X.509 option and then copy it to a directory on the Enterprise Portal server. For example, you could save the certificate as adfs-TokenSigningCert.cer and save it in a cert directory on the C:\ drive of the Enterprise Portal server.
Note
Users must specify a valid email address for their account logon.
Specify the claims provider in SharePoint
In Windows, click Start > Administrative Tools.
Click Microsoft Dynamics AX 2012 Management Shell.
Execute the following command, replacing “path-to-token signing certificate from the AD FS server” with the path of the Name.cer file that you configured in step 4 of the previous procedure.
$SigningCert = Get-PfxCertificate "path-to-token signing certificate from the AD FS server"
On the Enterprise Portal server, execute the Add-AXSharepointClaimsAuthenticationProvider cmdlet. For descriptions of the required parameters and syntax, see Add-AXSharepointClaimsAuthenticationProvider on TechNet.
The following example shows the cmdlet with the required parameters.
Add-AXSharepointClaimsAuthenticationProvider -Type ADFS -Name ADFSProvider -SigningCertificate $SigningCert –ServerUrl "https://ServerName/adfs/ls/"
You can specify any name for the provider. In this example, the name is ADFSProvider. The server URL must be the FQDN of the server that runs AD FS, followed by /adfs/ls/.
On the Enterprise Portal server, execute the Add-AXEnterprisePortalClaimsAuthenticationProvider cmdlet. For descriptions of the required parameters and syntax, see Add-AXEnterprisePortalClaimsAuthenticationProvider on TechNet.
The following example shows the cmdlet with the required parameters.
Add-AXEnterprisePortalClaimsAuthenticationProvider -URL "https://ServerName:PortNumber" -Name ADFSPROVIDER
This cmdlet adds the AD FS-based authentication trusted identity provider to the claims-aware Enterprise Portal site. The URL must be the URL of the Enterprise Portal site that you created earlier in this document: https://ServerName:PortNumber. The name of the provider must be the name that was used to create the provider in the previous procedure. Users should now see this provider in the providers list when they browse the site (https://ServerName:PortNumber/sites/DynamicsAx).
Register the AD FS signing certificate as a trusted root authority with SharePoint
Click Start > All Programs > Microsoft SharePoint Products > SharePoint Management Shell.
Execute the following commands, replacing <Path-to-certificate>\Name.cer with the path and name of the AD FS signing certificate.
$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("<Path-to-certificate>\Name.cer")
$spcert = New-SPTrustedRootAuthority -Certificate $cert -Name "ADFSSigningCert"
Note
“ADFSSigningCert” is a user-specified value.
Create a new user for AD FS authentication
The New-AXUser cmdlet creates a new user in Microsoft Dynamics AX. You can specify the type of user to add. If you are creating a claims user, specify the name of the claims provider in the UserDomain parameter, as described in the following procedure.
In Windows, click Start > Administrative Tools.
Click Microsoft Dynamics AX 2012 Management Shell.
On the Enterprise Portal server, execute the New-AXUser cmdlet. For descriptions of the required parameters and syntax, see New-AXUser on TechNet.
The following example shows the cmdlet with the required parameters. AXUser, UserName, and UserDomain are user-specified values. The value of UserDomain is the same value that you specified in Step 4 of the “Specify the Claims Provider in SharePoint” procedure earlier in this document.
New-AXUser -AccountType ClaimsUser -AXUserId april -UserName aprilbuckley -UserDomain ADFSProvider
Assign security roles for users
You must assign security roles for each user who was created by using the New-AXUser cmdlet. For information about how to assign security roles in the Microsoft Dynamics AX client, see Assign users to security roles. For information about how to assign security roles by using PowerShell, see the Add-AXSecurityRoleMember cmdlet Help on TechNet.
Validate AD FS configurations
Open a web browser, and browse the Enterprise Portal site: https://ServerName:PortNumber/sites/DynamicsAx
In the list of providers, select the AD FS provider. For example, ADFSProvider.
Log on to Enterprise Portal by using the credentials that you created in the previous procedure. You should be able to log on to Microsoft Dynamics AX as a system user.
Troubleshooting AD FS issues
Error: Users see a blank page after logging on to Enterprise Portal by using the AD FS provider.
This error occurs when the logon URL for the AD FS provider (for example, https://TestServer.contoso.com/adfs/ls/) cannot be opened in a web browser. To resolve this issue, you must update the hosts file on the server.
Open the hosts file. By default, the file is located in the following directory: C:\Windows\System32\drivers\etc folder
Add an entry for the AD FS provider in the form <IP address of AD FS server> <AD FS Server Name> <FQDN of AD FS server>
For example: 10.10.50.215 TestServer TestServer.contoso.com
In Internet Explorer, open Internet options.
Click the Connections tab, and then click LAN settings.
Clear the Automatically detect settings option. You might have to instruct all Enterprise Portal users to change this setting in their web browser.
Error: Users select the AD FS provider on the logon page, and then receive a “404: Page not found” error.
To resolve this issue, use IIS Manager to verify that Default Web Site or the site that hosts the AD FS provider is running.
Error: There was a problem accessing the site.
To learn more about this error, view the details in the AD FS 2.0 Admin event log. If you need more details about this issue, you can enable the AD FS debug log, as described in the following procedure.
In Event Viewer, click View > Show Analytic and Debug Logs.
To view events in the debug log, click AD FS 2.0 Tracing > Debug.
Right-click the Debug log, and then click Enable Log.
Error in the AD FS Admin log: An error was encountered during a federation passive request.
Exception details:
Microsoft.IdentityServer.Web.InvalidScopeException: MSIS7007: The requested relying party trust 'urn:ServerName:Provider' is unspecified or unsupported. If a relying party trust was specified, it is possible that you do not have permission to access the trust relying party. Contact your administrator for details at: Microsoft.IdentityServer.Web.FederationPassiveAuthentication.SubmitRequest(MSISRequestSecurityToken request
To resolve this issue:
In AD FS 2.0 Management, click Trust Relationships > Relying Party.
Double click ADFS Sign-on.
Click the Identifiers tab.
In the Relying party identifiers field, verify that the address matches the address shown in the error message. Addresses are case sensitive.
Specify which trusted identity provider is available for users at logon
You can select which flexible authentication provider is available in the Sign-in list when a user accesses the Enterprise Portal site.
In SharePoint Central Administration on the Enterprise Portal server, click Manage web applications.
Click the claims-aware Enterprise Portal site.
Click Authentication providers.
Click Default.
In the Claims Authentication Types section, select the providers that you want to appear in the Sign-in list.
Click OK.
See also
Deploy an Enterprise Portal site that uses forms-based authentication