Attempting to install an add-in with the "Add from the Office Store" feature with an Exchange 2016 mailbox fails with: “Due to the level of permissions required, your administrator has not allowed you to install this app."

Problem

You have an Exchange Server 2016 CU18 (Version 15.1 Build 2106.2)‎ environment and noticed that when users attempt to install an add-in with the Add from the Office Store feature, it fails with the error:

Due to the level of permissions required, your administrator has not allowed you to install this app.

Attempting to repeat the same procedure through the Exchange Server 2016 ECP’s Organization > add-ins fails with the error:

The app couldn’t be downloaded.

Reviewing the available documentation from Microsoft does not suggest what may be the issue:

Add-in access and installation
https://docs.microsoft.com/en-us/exchange/add-ins-for-outlook-2013-help#add-in-access-and-installation

Specify the administrators and users who can install and manage add-ins for Outlook in Exchange 2013
https://docs.microsoft.com/en-us/exchange/specify-who-can-install-and-manage-add-ins-2013-help

Manage role groups
https://docs.microsoft.com/en-us/exchange/manage-role-groups-exchange-2013-help

Solution

While the documentation wasn’t of much help for a resolution, the following forum discussion where a member presented 4 registry keys to implement did:

https://social.technet.microsoft.com/Forums/en-US/089ec657-bb58-4017-a62b-54a6151657a0/cant-add-office-store-addins-to-exchange-2016-onprem?forum=Exch2016GD

Hey guys,

I had a problem installing any app from the office store as well. In my case my Exchange 2016 was configured to still talk TLS 1.0 instead of TLS 1.2 though TLS 1.2 was already enabled (but not set to default). Obviously Microsoft does no longer accept TLS 1.0.

Therefore I changed some configuration in the registry of my Exchange Nodes by adding some DWORDS. That did the trick.

WinHTTP

WinHTTP provides a high-level server interface to the HTTP/1.1 Internet Protocol that applications and services running on Windows Server can use when establishing secure encrypted HTTPS sessions. Exchange uses it extensively. To ensure that WinHTTP is using TLS 1.2 make sure the following Registry keys are set:

1. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp
“DefaultSecureProtocols”:dword:00000a80

2. HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp
“DefaultSecureProtocols”:dword:00000a80

.NET Framework

The .NET Framework is a core set of code libraries and runtimes that are used by many Windows Server-based services and Applications, including Exchange Server. It’s essential to ensure that the .NET Framework is using TLS 1.2 to encrypt and secure the many API points it provides and uses to communicate. To do this makes sure the following registry keys are set:

1. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319
“SystemDefaultTlsVersions”=dword:00000001

2. HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319
“SystemDefaultTlsVersions”=dword:00000001

With the above registry keys in place, adding the add-in as the user continued to display the error:

Due to the level of permissions required, your administrator has not allowed you to install this app.

However, adding the add-in via the Exchange Server 2016 ECP was successful:

With the add-in added to the organization, users can now choose to install them from the list:

Citrix ADC / NetScaler monitors for Exchange 2019 fails with: "Failure - Time out during SSL handshake stage"

Problem

You’re attempting to publish / load balance your on-premise Exchange 2019 servers behind a Citrix ADC / NetScaler but notice that the health monitors created to check the health of the services (e.g. https://172.16.1.81/owa/healthcheck.htm) fail with the following error:

Failure - Time out during SSL handshake stage

The rest of the monitors are all reporting the same error:

Further troubleshooting reveals that this is due to the fact that the following server hardening registry keys are added to the Exchange 2019 servers:

Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

AllowInsecureRenegoClients
REG_DWORD
0

AllowInsecureRenegoServers
REG_DWORD
0

Removing these entries one of the Exchange servers will correct the error allowing the probe to report that the server is up (note that it is partial because the other server still has the registry key):

Various forum discussions on Citrix points adjusting Deny SSL Renegotiation but none of the configuration settings corrected the issue for the environment I worked with:

https://discussions.citrix.com/topic/388325-netscaler-12-rfc-5746-on-backend-bug-limitation/#comment-1975755

https://discussions.citrix.com/topic/401441-basic-load-balancing-for-owa-exchange-2019/page/3/

Solution

After performing extensive troubleshooting but not able to come to a resolution, I decided to upgrade the Citrix ADC / NetScaler from NS13.0 52.24.nc to the latest build available at the time, which was NS13.0 67.39.nc:

NS13.0 52.24.nc

NS13.0 67.39.nc

This ended up resolving the issue with the services being correctly determined as UP:

Hope this helps anyone who might be facing this same issue as there isn’t much material available and the available solutions did not work for me.

Configuring X-Content-Type-Options and Permissions-Policy for Citrix ADC / NetScaler to score A on Security Headers for Exchange OWA

I’ve recently been involved with a few projects involving security vulnerabilities from penetration scans and one of the clients were asked to secure their Exchange OWA portal load balanced behind a Citrix ADC so that 2 of the 6 headers that are identified to be missing from the Security Headers (https://securityheaders.com/) scan are addressed:

• X-Content-Type-Options
• Permissions-Policy

Please refer to my previous blog post for instructions on how to implement the other headers identified to be present in the scan above:

Securing a Citrix ADC (formally known as NetScaler VPX) to score an A rating on Security Headers - March 2020
http://terenceluk.blogspot.com/2020/02/securing-citrix-adc-formally-known-as.html

X-Content-Type-Options

The X-Content-Type-Options header is fairly easy to implement as it is described in Citrix’s knowledge base article:

How to create rewrite policy for content security headers , XSS protection, HSTS, X-Content-Type-Options & Content-Security-Policy.
https://support.citrix.com/article/CTX233095

The following are the CLI commands:

add rewrite action rw_act_insert_Xcontent_header_Policy insert_http_header X-Content-Type-Options "\"nosniff\""

add rewrite policy rw_pol_insert_XContent_Policy TRUE rw_act_insert_Xcontent_header_Policy

bind lb vserver mail.college.bm_external -policyName rw_pol_insert_XContent_Policy -type RESPONSE -priority 120 -gotoPriorityExpression NEXT

The following is the Rewrite Action in the Citrix ADC / NetScaler GUI:

The following is the Rewrite Policy in the Citrix ADC / NetScaler GUI:

With the Rewrite Action and Policy in place, and having the policy bound to the virtual server, the scan should now return the header as being present:

Permissions-Policy

The Permissions-Policy, which replaces the Feature Policy, isn’t as straight forward as Citrix does not have a KB for the implementation of this header. However, Scott Helme provides a very detailed explanation for this header:

Goodbye Feature Policy and hello Permissions Policy!
https://scotthelme.co.uk/goodbye-feature-policy-and-hello-permissions-policy/

The following are the CLI commands to create the Rewrite Action, Policy and bind it to the virtual server:

add rewrite action rw_act_insert_Permissions_Policy insert_http_header Permissions-Policy "\"vibrate=(self), sync-xhr=(self \'https://<owa.domain.com>\')\""

add rewrite policy rw_pol_insert_Permissions_Policy "HTTP.RES.HEADER(\"Permissions-Policy\").EXISTS.NOT" rw_act_insert_Permissions_Policy

bind lb vserver mail.contoso.com_external -policyName rw_pol_insert_Permissions_Policy -type RESPONSE 110 -gotoPriorityExpression NEXT

The following is the Rewrite Action in the Citrix ADC / NetScaler GUI:

The following is the Rewrite Policy in the Citrix ADC / NetScaler GUI:

With the Rewrite Action and Policy in place, and having the policy bound to the virtual server, the scan should now return the header as being present:

**Note that the reason why the score in the screenshot above is A rather than A+ is because the Content-Security-Policy header configured contains the ‘unsafe-inline’ in the script-src directive. I have yet to successfully omit ‘unsafe-inline’ for sites such as a Citrix Gateway or Exchange OWA without causing the login page to fail to load.

Browsing a Citrix ADC / NetScaler published Exchange OWA displays the warning message: Your connection is not fully secure Your connection is not fully secure NET::ERR_SSL_OBSOLETE_VERSION

Problem

You’ve received reports that browsing a Citrix ADC / NetScaler published Exchange OWA displays the following warning message in Chrome and Edge Chromium:

Google Chrome

Your connection is not fully secure

This site uses an outdated security configuration, which may expose your information (for example, passwords, messages, or credit cards) when it is sent to this site.

NET::ERR_SSL_OBSOLETE_VERSION

Edge Chromium

Your connection isn't secure

This site uses an outdated security configuration that might expose your personal information when it's sent to this site (for example, passwords, messages, or credit cards).

NET::ERR_SSL_OBSOLETE_VERSION

It is possible to proceed in both browsers but a Not secure message will be displayed in the address bar:

Solution

One of the reasons why this warning message would be displayed is because Google Chrome 72 and later versions have deprecated support for legacy TLS versions, which include TLS 1.0 and 1.1. If the Load Balancing Virtual Server for the Exchange OWA configured on Citrix ADC / NetScaler has only TLS 1.0 and TLS 1.1 enabled as shown in the screenshot below then the warning message above will be displayed:

To correct the issue, simply enable TLSv12 in addition to TLSv1, TLSv11:

Or just enable TLSv12 if there are no legacy devices with browsers accessing the website (those should be upgraded if they exist):

Once updated, the site should load and the Security tab of Google Chrome’s Developer Tools should display a message indicating the site is using TLS 1.2:

HTTP ERROR 440 is displayed when using AD FS claims-based authentication with OWA (Outlook on the Web)

Problem

You have AD FS (Windows Server 2019) claims-based authentication configured for Exchange Server 2019 Version 15.2 (Build 464.5) OWA (Outlook on the Web) and has had it working in production for months but received complaints from users that the following error is presented after successfully authenticating at an AD FS portal to access OWA:

This page isn’t working
If the problem continues, contact the site owner.
HTTP ERROR 440

Attempting to access /ECP also throws the same error.

This appears to only happen in Chrome but not Internet Explorer or Chromium Edge (or regular Edge).

The following are versions of Chrome that presents the error above:

Version 85.0.4183.121 and 86.0.4240.75

The following are the version of IE and Edge Chromium that did not exhibit this issue:

Edge Chromium: 85.0.564.70

Internet Explorer 11: 11.1082.18362.0

Solution

A quick search for this issue on the internet returned the following thread on Reddit:

https://www.reddit.com/r/exchangeserver/comments/iyirls/owa_440_error_in_chrome/

It appears the quickest way to load the page in Chrome is to navigate to the following setting:

chrome://flags/#reduced-referrer-granularity

Then set the Reduce default ‘referrer’ header granularity. From default to disable:

This can also be configure via Group Policy via the registry as shown in the following document: https://cloud.google.com/docs/chrome-enterprise/policies?policy=ForceLegacyDefaultReferrerPolicy

Having worked with a lot of clients to implement missing security headers identified by the following popular scan by Scott Helme: https://securityheaders.com/, I felt that there must be a better way of addressing this at the AD FS server level rather than the client level. The Referrer Policy header was familiar to me because I had recently implemented for another client’s Citrix portal and for those who are not familiar with it can find more information at Scott Helme’s site: https://scotthelme.co.uk/a-new-security-header-referrer-policy/

The short description of it as described by Scott is: Referrer Policy is a new header that allows a site to control how much information the browser includes with navigations away from a document and should be set by all sites.

After reviewing the authentication and redirect process between the AD FS portal and OWA, then testing the various Referrer Policy options, it appears the most restrictive one that worked was the no-referrer-when-downgrade because the full URL was passed with this option.

The following is the official Microsoft documentation that explains how headers are configured for AD FS:

Customize HTTP security response headers with AD FS 2019
https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/operations/customize-http-security-headers-ad-fs

The document does not include the Referrer Policy in the list but you can view and configure it as shown in the following cmdlets executed on the AD FS server:

To view the response headers:

Get-AdfsResponseHeaders

To expand the truncated list of response headers:

PS C:\> Get-AdfsResponseHeaders | Select -ExpandProperty ResponseHeaders

Key Value
--- -----
Strict-Transport-Security max-age = 31536000
X-Frame-Options DENY
X-Content-Type-Options nosniff
X-XSS-Protection 1; mode=block
Content-Security-Policy default-src 'self' 'unsafe-inline' 'unsafe-eval'; img-src 'self'; frame-src *.duosecurity....

PS C:\>

To configure the Referrer Policy:

Set-AdfsResponseHeaders -SetHeaderName "Referrer-Policy" -SetHeaderValue "no-referrer-when-downgrade"

Confirm that the Referrer-Policy is configured with the following cmdlet:

Get-AdfsResponseHeaders | Select -ExpandProperty ResponseHeaders

Key Value
--- -----
Strict-Transport-Security max-age = 31536000
X-Frame-Options DENY
X-Content-Type-Options nosniff
X-XSS-Protection 1; mode=block
Content-Security-Policy default-src 'self' 'unsafe-inline' 'unsafe-eval'; img-src 'self'; frame-src *.duosecurity....
Referrer-Policy no-referrer-when-downgrade

To remove the Referrer Policy:

If the Referrer-Policy needs to be removed then the following cmdlet can be executed:

Set-AdfsResponseHeaders -RemoveHeaders "Referrer-Policy"