Settings and Tuning

Learn about settings and tunings for Aurea CRM Web.

Below are some of the required settings:

IIS Application Settings

Content Expiration

To avoid that clients have to download the same static files every time they navigate to Aurea CRM web it is strongly recommended to enable a content expiration on all static content.

Setting the content expiration allows web browsers to cache the content for the specified time period before requesting it again from the server.

Note: You should adapt the value for content expiration to match your upgrade cycle, otherwise clients might be required to manually clear their caches in order to get the most recent scripts, images and CSS styles, see Browser Cache.

If you have installed Aurea CRM web using the setup process, the content expiration is set to one day for the following directories: \images, \scripts, and \styles.

Use IIS Manager to change the content expiration of files or directories. Select the Aurea CRM web directory, open the Properties dialog box, and set the content expiration in the HTTP Respones Headers tab (Set Common Headers action).

Application Protection / Application Pool

If you have installed Aurea CRM web using the setup process, the following web application structure is created in IIS: A new application pool is created by the setup process. By default, the application pool is named "update_CRMweb". You can specify another name during the setup process, see IIS Virtual Directory and IIS Application Pool.

If you want to run more than one Aurea CRM web application on one web server, you have to configure them to use different application pools. If you want to have multiple web applications using the same physical folder, you have to use environment variables %APPLICATIONPOOL% and %PID% (= Process ID) in all paths specified in settings.xml, to ensure that web applications won't block each other by locking files.

Session Timeout

After a certain period of inactivity, a user loses his session and must then log on again. To ensure that the user does not lose his session, you have to increase the default value for the session timeout. Adjust these settings using IIS Manager.

Note: Increasing the session timeout leads to a higher memory load on your server.

Aurea CRM web Settings

Jobs.PollingInterval Configuration Parameter

The Jobs.PollingInterval Web Configuration parameter defines how often Aurea CRM web clients contact the server for new data (e.g. Reminders or To-Dos). By default this setting can be changed by all users in Aurea CRM web (User Configuration > Handling > Check for new records every min.).

The default value of Jobs.PollingInterval checks for new records every 30 minutes. If this value is reduced for a significant number of users, performance decreases as database access rises. It is recommended to set a reasonable interval and to prevent users from changing it (by removing the corresponding option from the mask (UserConfig layout), see Configuration Layouts in the Aurea CRM web Administrator Guide.

Aurea CRM win Settings

Rights Settings

When a user logs on, a new Internet Interest record is created. Therefore, each Aurea CRM user must have "New", "Update" and "Read" rights for the Internet Interest (II) table, otherwise the login fails.

Every Aurea CRM rep is assigned to an Internet Interest at login, therefore, this table must be fully accessible (without conditions). Every rep must have "Read" and "Write" rights for the II table. The same applies to the I9 table.

Number of Visible Reps

If a user has access to too many reps (approximately 300 or more), the rep picker in Aurea CRM web can become rather slow when opened for the first time in a session (this is a known issue).

You can limit the number of reps for a user. It is suggested that users only have access to the reps they really need. This can be accomplished using the Aurea CRM win Rights module.

Configuration Table (MC) Entries

The following entries of the Configuration table (MC) only work as a global setting in Aurea CRM web, but not when defined for a user or group:

  • General Settings > Start of Fiscal Year
  • Country Table > Disconnect Field from Country Table
  • General Settings > RepOff

Configuring Single Sign-On

Aurea CRM web

Aurea CRM web supports single sign-on with the Active Directory. You need to enable single sign-on per user in the Login (US) info area (s. below).

To enable single sign-on for Aurea CRM web:

  • Configure single sign-on in the Login info area (US): For each user enter the appropriate values for Domain and Windows User Name, see Configuring Logins in the CRM.core Administrator Guide.
    Note: You can access the Login info area from Aurea CRM web (Administration > Logins) or from the Aurea CRM win Rights module (Rep > Configure Login).
  • In IIS Manager:
    1. Select the Aurea CRM web site.
    2. Select Authentication.
    3. Set "Anonymous Authentication" to "Disabled" and "Windows Authentication" to "Enabled".

Note: The IIS web server needs to be located in the same domain as the users.

On Windows 2008 Server you need to deactivate the advanced security settings for single sign-on to Aurea CRM web to work.

For information on how to configure a browser for single sign-on, see the article “How to Configure browsers for single sign-on” at https://support.aurea.com.

CRM.bulkloader

For CRM.bulkloader to work with single sign-on, change the configuration file ..\crm.services\web.config as follows:

  • Change the value of the clientCredentialType attribute from None to Windows.

CRM.designer

For information on how to configure single sign-on for CRM.designer, see the article “How to Enable SSO in designer” at https://support.aurea.com.

Start Page Redirect

When using both Aurea CRM web and CRM.mobile, you can define rules for automatically redirecting your users to the appropriate application depending on the device they currently use, i.e. automatically start CRM.mobile if they access Aurea CRM web's URL on a smartphone. For details, see https://support.aurea.com/wiki/index.php?title=Start_Page_Redirect.

The conditions for redirecting to CRM.mobile are defined in the startPageRedirect.xml file (located at .. \system\settings). startPageRedirect.xml is included in Aurea CRM web's settings.xml.

Note: This feature is deactivated by default.

The redirect logic only works if the root of the Aurea CRM website (i.e. default.aspx) is accessed; if the user directly accesses e.g. http://<server name>/updateCRM_web/start.aspx, Aurea CRM web is started regardless of the used device.

Security Settings

Black/White List for External Pages

To prevent phishing attacks when opening an external page, you can define a black/white list ensuring that a RedirectPage or URL action cannot be redirected to a harmful site.

In the <update.web> section of the settings.xml file, define a <NavigationSecurity> element containing black/white listed pages.
<NavigationSecurity unguardedNavigation="Warning">
	<RegexDictionaryEntry>
		<Key>www.my-good-website.com</Key>
		<Value>Allow</Value>
	</RegexDictionaryEntry>
	<RegexDictionaryEntry>
		<Key>www.areyousure.org</Key>
		<Value>Warning</Value>
	</RegexDictionaryEntry>
	<RegexDictionaryEntry>
		<Key>www.buy-me.com</Key>
		<Value>Deny</Value>
	</RegexDictionaryEntry>
</NavigationSecurity>

Available values:

  • Allow: The page is opened (in a new tab).
  • Warning: A prompt asks the user if the page should be opened.
  • Deny: A message is displayed informing the user that the page can not be opened.

Use the unguardedNavigation attribute to define the default behavior for pages for which no entry exists.

Note: The black/white list is not applied to external links opened from within records.

Due to its security handling, Google Chrome displays pages flagged with 'Allow' and pages flagged with 'Warning' differently: If you have defined two URL actions both with target e.g. set to _blank, the URL flagged with 'Allow' is opened in a new window, the URL flagged with 'Warning' is opened in a new tab.

Process End on Application_End

You can define conditions for ending (and restarting) the IIS worker process, e.g. changed file in the ..\bin directory.

In the settings.xml in the <update.web> section define a <TerminateOnApplicationEnd/> element containing the exit reasons.

Example:
	<TerminateOnApplicationEnd>
	<ExitOn>
	<ExitReason>BinDirChangeOrDirectoryRename</ExitReason>
	<ExitReason>BrowsersDirChangeOrDirectoryRename</ExitReason>
	<ExitReason>ChangeInGlobalAsax</ExitReason>
	<ExitReason>ChangeInSecurityPolicyFile</ExitReason>
	<ExitReason>CodeDirChangeOrDirectoryRename</ExitReason>
	<ExitReason>ConfigurationChange</ExitReason>
	<ExitReason>HttpRuntimeClose</ExitReason>
	<ExitReason>InitializationError</ExitReason>
	<ExitReason>MaxRecompilationsReached</ExitReason>
	<ExitReason>None</ExitReason>
	<ExitReason>PhysicalApplicationPathChanged</ExitReason>
	<ExitReason>ResourcesDirChangeOrDirectoryRename</ExitReason>
	<ExitReason>UnloadAppDomainCalled</ExitReason>
	<!-- No exit for the following-->
	<!--ExitReason>BuildManagerChange</ExitReason-->
	<!--ExitReason>HostingEnvironment</ExitReason-->
	<!--ExitReason>IdleTimeout</ExitReason-->
	</ExitOn>
	</TerminateOnApplicationEnd>

For details on all available exit reasons, >> http://msdn.microsoft.com/en-us/library/system.web.applicationshutdownreason.aspx.

Including stack trace reports in Server Channels Exception messages

By default CRM.Web does not include stack trace information along with exception messages generated by a CRM application, in the reports sent to the clients. To enable stack trace reports to be included along with exception messages, you have to set EnableStackTrace option to true in the settings.xml file. The following sample shows the ExceptionSettings element with the EnableStackTrace option set to true.

<update.lib>    
    <ExceptionSettings>
        <EnableStackTrace>TRUE</EnableStackTrace>
    </ExceptionSettings>
</update.lib>

Disabling HSTS (HTTP Strict Transport Security) Policy

HTTP Strict Transport Security (HSTS), a web security policy mechanism is enabled by default in Aurea CRM. HSTS protects Aurea CRM against protocol downgrade attacks and cookie hijacking. It is an IETF standards track protocol and is specified in RFC 6797. Once a client establishes a secure (HTTPS) connection with CRM.Web, the HSTS (HTTP Strict Transport Security) policy is enforced to ensure that the client continues to use SSL or TLS connections and does not switch to a non-secure connection.

If you do not want to enforce HSTS, you can disable it by setting the DisableHSTS parameter to true in the settings.xml file. See the sample code below:

<update.lib>
    <WebSecuritySettings>
        <DisableHSTS>TRUE</DisableHSTS>
    </WebSecuritySettings>
</update.lib>

Using HTTPS to Connect to Aurea CRM.Web Limits the Scope of the Cookies to Secure Channels

From v10.1.0 release of Aurea CRM.Web, when a client uses the https channel then Aurea CRM limits the scope of the cookie to the secure channel, HTTPS (HTTP over Transport Layer Security (TLS) [RFC2818]) in this case. Later, if the same client tries to use HTTP to connect to Aurea CRM.Web, the connection attempt fails until the client clears the cookies. This is because once the scope of an established cookie is restricted to a secure channel, then the cookie is not transmitted over an unsecured channel like HTTP.

Enabling Cross Site Request Forgery (CSRF) Protection

Aurea CRM.Web provides the element <EnableCsrfProtection/> in the settings.xml file that can be set to true to enable CSRF protection. Aurea CRM.Web uses the Cookie-to-Header Token method to prevent cross site forgery attacks. This method relies on the same origin policy, which ensures that JavaScript within the same origin can read the cookie’s values.

This method uses a random header token that is generated by the server when a user logs in and is included by the client in all its request to the server for the duration of this session. JavaScript that belongs to the same origin on the client side can read this token value and include it in the custom header when it sends a transaction request. The assumption here is that the javascript running from a rogue file does not have the X-Csrf-Token header, because it cannot read the Csrf-token cookie, as it is not from the same origin. Consequently its transaction request is not honored by CRM.Web and the CSRF attack fails.

Important: This option is set to false by default. All customer side extension software (including client browsers) that send requests to CRM.Web must be adapted to use the Cookie-to-Header Token method before enabling this option.
For more information, see:

HTTP Post Method for Data Manipulations

Aurea CRM enforces HTTP POST requests for all channel methods to prevent CRSF (Cross Site Request Forgery) attacks that exploit the HTTP GET method. All HTTP GET requests are by default converted to a HTTP POST request. This prevents malicious users from posting HTTP GET requests on channels that manipulate data.

The HTTP POST method is not enforced on the following channel methods:

  • TypesChannel.GetTypes
  • ApplicationChannel.GetStartupData
  • ApplicationChannel.GetLoginSettings
  • SettingsChannel.Find
  • ConfigurationChannel.GetTexts
  • AdministrationChannel.GetSystemInfo
You can disable the HTTP POST request enforcement by setting the DisableHttpMethodTypeProtection option to false for a channel endpoint.
Note: Aurea strongly recommends that you do not disable HTTP POST request enforcement in production environments. Allowing the Http GET method, opens the door to CSRF attacks even when CSRF protection is enabled. For more information on enabling CSRF protection, see Enabling Cross Site Request Forgery (CSRF) Protection.
A sample configuration disabling the HTTP POST enforcement in the settings.xml file is shown below:
<update.web.base>
    <ChannelEndpoint>
        <!--
            If DisableHttpMethodTypeProtection is enabled all Channels start to serve for any Http
            Method type,even it is configured to serve Http POST only. This option is not 
            recommended for production usage.
         -->
        <DisableHttpMethodTypeProtection>
            false
        </DisableHttpMethodTypeProtection>
    </ChannelEndpoint>
</update.web.base>

Enabling X-Powered-By ASP.Net and Other version headers in HTTP response

The following headers are disabled by default in a HTTP response:

  • Server: Details of the web server hosting Aurea CRM. For example, “Microsoft-IIS/7.5”.
  • X-Powered-By: One or more application frameworks being run by site hosting Aurea CRM. For example, “ASP.NET”, “PHP/5.2.17” and “UrlRewriter.NET 2.0.0”.
  • X-AspNet-Version: Header from an ASP.NET. For example, “2.0.50727”, “4.0.30319” and “1.1.4322”.

To enable one or more of the above headers, you can add the application settings key DisableResponseHeaders in the Web.Config file. Add the response headers you want to specifically disable to the key value separated by a “;”. See the examples below:

To enable all three headers:

<add key="DisableResponseHeaders" value=""/>

To enable the Server header:

<add key="DisableResponseHeaders" value="X-AspNet-Version;X-Powered-By"/>

Displaying a Document's Path in System Information

As a security measure, by default, Aurea CRM.Web System Information page (Settings () > System Information) does not display the path on the server where the uploaded documents are kept. See the screenshot below:



To display the document path set the web configuration parameter Security.HidePathInformation to False.

Enabling Protection from Session Hijacking

To prevent a user’s live session from being hijacked, you can ensure that all session requests are originating from the same IP address that the user logged in and the User-Agent String value remains the same during the session.

To enable this protection, set the <SessionHijackingProtection> element in the CRM.Web’s settings.xml file, as shown below:

<update.web>
    <SessionHijackingProtection validateClientIpAddress="true" validateClientUserAgentString="true" />
</update.web>
Note: You can enable one or both of the validation checks for a user’s session.