The intranet portal is specialized to operate within a local area network and to take advantage of Windows integrated authentication. The intranet environment provides improved security and conveniences such as automatic sign-in and single sign-on. Since users of the intranet portal are authenticating with Active Directory domain accounts, the portal is able to use impersonation to access personal CRM content such as activities and protected content such as restricted web pages.

Solution Package Requirements

The following solution packages must be installed on the CRM Organization prior to running the Basic Portal.

  • Adxstudio Portals Dependencies
  • Adxstudio Portals Base or Adxstudio Portals Complete

See Solution Packages for more details regarding the solutions. For more information regarding installation, see Installation Instructions.

Website Data Requirements

The Adxstudio Portals installation package includes an XML backup file that can be used with the WebsiteCopy utility to import the necessary website and related data into your CRM Organization. The location of the file can be found in the Adxstudio Portals installation directory (C:\Program Files (x86)\ADXSTUDIO\XrmPortals\<version number>\Samples\Intranet.xml)

Web Application Project

The code necessary to run an ASP.Net Website leveraging the Adxstudio Portals framework is contained in the Intranet Portal's Visual Studio Web Application project. This project is included in the Adxstudio Portals installation and can be found in (C:\Program Files (x86)\ADXSTUDIO\XrmPortals\<version number>\Samples\HowTo\Intranet\). For instructions on getting the website running in IIS, see Set Up Sample Websites.

Configuration

Administrators should ensure that the IIS website hosting the intranet portal have Windows Authentication enabled and Anonymous Authentication enabled.

NameStatus
Anonymous Authentication Enabled
ASP.NET Impersonation Disabled
Basic Authentication Disabled
Digest Authentication Disabled
Forms Authentication Disabled
Windows Authentication Enabled

If Internet Explorer does not detect the portal as being in the local intranet zone, the portal can be manually added to the list of recognized intranet websites. Specifying NetBIOS names (computer names) instead of fully qualified domain names may also determine the zone that Internet Explorer uses.

  • Local intranet websites

Sign-in

Since the intranet portal is a fully protected website (ie. anonymous access is not permitted), the first action for any visitor to the site is to authenticate. By default, Internet Explorer is configured for automatic sign-in which results in the visitor being authenticated as the identity of the current domain account. Users that wish to be prompted for their credentials instead may modify this setting under the browser settings. In this case, the visitor is authenticated under the identity of the provided credentials.

Be aware that IIS performs a loopback check when browsing a site directly on the web server itself. The result is an HTTP 401.1 status code.

Intranet sign-in dialog

To disable automatic sign-in in Internet Explorer, open Internet Options > Security > Local intranet > Custom level > User Authentication > Logon. Select Prompt for user name and password.

Security settings

Authenticated intranet users fall under two main categories:

  1. System users - domain users with an account in CRM
  2. Unregistered (non-system) users - users without an account in CRM but are otherwise valid domain users

Any valid domain account (ie. all authenticated users) is permitted to enter the site and view shared content. Shared content includes web page and web files that have not been restricted by access control rules. Such users have similar access to anonymous users in a standard (non-intranet) portal and the shared content can be thought of as anonymous content.

Attempting to access protected content results in an access denied response. Domain accounts that are registered system users may be authorized to view protected content depending on the current access control rules. Such users are the equivalent of authenticated users in a standard (non-intranet) portal. Administrators may assign system users to web roles and in turn be assigned to access control rules; thus, granting these users access to protected content.

Activities

A consequence of impersonation is the ability to retrieve user related content and to take advantage of the CRM security model. The activities component of the intranet portal utilizes the user views (saved queries) feature in order to retrieve activity related views. In turn, these views are invoked to return activity content that is directly related to the authenticated user.

Federated Authentication

The intranet portal can be reconfigured to replace Windows integrated authentication with federated authentication. Under this scheme, the user credentials are managed by an external identity provider such as Active Directory Federation Services (ADFS). The sign-in experience is determined by the identity provider. For instance, ADFS may be configured to provide a forms-based sign-in page or a Windows integrated authentication dialog.

ADFS forms based sign-in

To enable federated authentication, CRM must be configured for claims-based authentication and a trust relationship must be setup between CRM, the identity provider, and the intranet portal.

Federated authentication enables single sign-on between all websites that share a common identity provider. For system users registered in CRM, this allows quick navigation between the intranet portal and CRM.

Single sign-on

Since Adxstudio Portals sites are written for, and best views on, the latest web browers, ensure that Internet Explorer compatibilty view mode is disabled. This can be done by navigating to Tools > Compatibility View settings. Uncheck the Display intranet sites in Compatibility View option.

Configure Single Sign On with ADFS

Configure IIS

Since ADFS requires relying party websites to run on HTTPS, the first step is to ensure that an HTTPS binding is added to the website.

  • Type: https
  • Host Name: intranet.crm2011.contoso.com
  • Port: 443
  • IP Address: *

Specify an SSL certificate for the binding.

Update the authentication settings for the website and disable Windows Authentication (all options should now be disabled).

Configure CRM and ADFS

Start by enabling IFD on Microsoft Dynamics CRM Server 2011 by completing this article.

At this point there should be at least two relying party trust entries corresponding to the internal access authentication endpoint and the external access authentication endpoint. The next step is to add the intranet portal as a new relying party trust.

Start the Add Relying Party Trust Wizard and click Start

  • Select Data Source: Enter data about the relying party manually
  • Specify Display Name: https://intranet.crm2011.contoso.com/
  • Choose Profile: AD FS 2.0 profile
  • Configure Certificate: <next>
  • Configure URL: Enable support for the WS-Federation Passive protocol
    • Relying party WS-Federation Passive protocol URL: https://intranet.crm2011.contoso.com/
    • Note: do not specify a specific endpoint such as /federation.axd since the Intranet portal is configured to use the WSFederationAuthenticationModule
  • Configure Identifiers: <next>
    • There should already be a single value under Relying party trust identifiers for https://intranet.crm2011.contoso.com/
  • Choose Issuance Authorization Rules: Permit all users to access this relying party
  • Ready to Add Trust: <next>
  • Finish

Edit Claim Rules for https://intranet.crm2011.contoso.com/

  • Add a rule
  • Claim rule template: Transform an Incoming Claim
  • Claim rule name: Transform Windows account name to Name ID claim
    • Incoming claim type: Windows account name
    • Outgoing claim type: Name ID
    • Outgoing name ID format: Unspecified
    • Pass through all claim values
  • Finish

Configure Portal

Edit the web.WIF.config transform file to provide values specific to the ADFS environment. Build and publish the web application.

	<microsoft.identityModel
		xdt:Transform="Insert">
		<service>
			<audienceUris>
				<add value="https://intranet.crm2011.contoso.com/"/>
			</audienceUris>
			<federatedAuthentication>
				<!--
				Authentication Types
				- Forms Authentication: urn:oasis:names:tc:SAML:1.0:am:password
				- Windows Integrated:   urn:federation:authentication:windows
				-->
				<wsFederation
					passiveRedirectEnabled="true"
					issuer="https://adfs.crm2011.contoso.com/adfs/ls/"
					realm="https://intranet.crm2011.contoso.com/"
					requireHttps="true"
					authenticationType="urn:federation:authentication:windows" />
				<cookieHandler requireSsl="false" />
			</federatedAuthentication>
			<applicationService>
				<!--
				ADFS Claim Rules
				- Required: Transform 'Windows account name' claim to 'Name ID' claim
				- Optional: Pass through 'Name' claims
				-->
				<claimTypeRequired>
					<claimType type="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier" optional="false" />
					<claimType type="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name" optional="true" />
				</claimTypeRequired>
			</applicationService>
			<issuerNameRegistry type="Microsoft.IdentityModel.Tokens.ConfigurationBasedIssuerNameRegistry, Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35">
				<trustedIssuers>
					<add thumbprint="[ADFS signing certificate thumbprint]" name="https://adfs.crm2011.contoso.com/adfs/services/trust"/>
				</trustedIssuers>
			</issuerNameRegistry>
			<certificateValidation certificateValidationMode="None" />
		</service>
	</microsoft.identityModel>