Outgoing emails are not working in SPS2016 after Security Update May 2017

This article has inform you previously there may be some concequences after May 2017 Security Update for SharePoint in some special configurations.

There is a security update May 9,2017 for SharePoint Server 2016
You can find details in following KB
https://support.microsoft.com/en-us/help/3191880/description-of-the-security-update-for-sharepoint-server-2016-may-9-20

Well it is confusing, as you may know, out of the box mail configuration for SharePoint always anonymous. Thats correct.
But in some special configuration applied by customers to force SharePoint processes (w3wp or owstimer) to authenticate with their identities to Exchange server;  If aspnet:AllowAnonymousImpersonation settings was disabled for Authenticated users (well it doesn’t work for anonymous users at all) it may work.

<appSettings>
<add key=”aspnet:AllowAnonymousImpersonation” value=”false” />
</appSettings>

More details explained for this.
https://support.microsoft.com/en-us/help/2686411/sharepoint-impersonates-the-iusr-account-and-is-denied-access-to-resources
Security Warning : Well the suggested action for this settings , this should be enabled. Otherwise anonymous request will have higher rights with Application Pool Identities does.

The problem of this kind of authentication is incorrect ,not expected  for SharePoint and Microsoft considered this is a Security Issue. As Microsoft said by design it has to be anonymous. With that Security fix will prevent this. SharePoint will be always use anonymous authentication through SMTP servers.

For customers who interested force authentication , well there’s no way to disable the anonymous-only behavior but we have valid workaround for that:

  1. If you are using Exchange, you can set up a separate receive connector configured as externally secured, and restricted to the IP addresses of the SharePoint server(s) in their environment.  This will allow SharePoint to send e-mails anonymously through this receive connector, but the connector will treat the e-mails as if you were authenticated.  All other SMTP clients will continue using the regular receive connectors and any authentication policies associated with those receive connectors.
  2. Set up a smarthost SMTP relay that will accept e-mails anonymously from the SharePoint server(s), and then relay them to the company’s SMTP infrastructure using authentication.

Can not connect to SharePoint Store via Proxy

You have a SharePoint 2013 farm and you have configured apps as defined following articles;

Configure an environment for apps for SharePoint (SharePoint 2013)
https://technet.microsoft.com/en-us/library/fp161236.aspx

Enable apps in AAM or host-header environments for SharePoint 2013
https://technet.microsoft.com/en-us/library/dn144963.aspx

http://www.nothingbutsharepoint.com/2013/02/13/configure-an-environment-for-apps-for-sharepoint-2013-aspx/

(In this article we have assume that you dont have any configuration problem)

After you have enabled SharePoint Store Access , you have facing when we go to Apps and click on Purchase app’s we see an error “Sorry we cannot seem to connect to the SharePoint Store. Try again in a bit later” .

but when you check from Browser there is no Access issue for the Office.microsoft.com

You have suspecting that it may be a Proxy issue ; Good news thats very likely you right.

In normal condition we should see a credential prompt because of the Proxy Auth request but it is not happening well because it is worker process making that request not the browser.

To able to handle this issue , you should add https://store.office.com and https://office.microsoft.com to IE trusted sites because of automatic logon option should provide concurrent user credentials when proxy ask.

Another problem;

Proxy authentication can not be done by IIS Worker Process (where sharepoint run) even we have configured <defaultproxy> settings correctly in related web application web.config. we have seen in network traces SharePoint Worker Process somehow could not passing the credentials (we are expecting Application Pool Identity should in use) to proxy server making like an anonymous request so the Proxy server so it has been rejecting authentication . In our last log analysis and session we have identified the root cause of the problem : One of The IIS Site web.config settings is causing the issue <appSettings>
<add key=”aspnet:AllowAnonymousImpersonation” value=”true” />
</appSettings>

https://msdn.microsoft.com/en-us/library/hh975440(v=vs.120).aspx

To enable this setting, you must have IIS 7 or IIS 7.5 or upper running in Integrated mode (which SharePoint works like this)  When this setting is enabled, the application runs under the security context of the IUSR identity. Additionally, creating a Forms-based Authentication Web Application (Which Sharepoint in Claims mode we have to enable forms auth)  will enable the setting and set it to true.

This is a design issue of how IIS works. The issue happenning because of the application runs under the security context of the IUSR identity and the <defaultproxy>  useDefaultCredentials ”true” it passes IUSR’s credentials to proxy which is anonymous , it is not a real domain user.

For resolution:

– We can remove this from WFE servers but it is require to make some tests that you don’t facing the problem of “SharePoint impersonates the IUSR account and is denied access to resources” and verify your sites and sharepoint components are working correctly. To workaround the issues, you need to determine if the setting is mandatory for your environment, and if not, you can set it to ‘false’. https://support.microsoft.com/en-us/kb/2686411

Important
 : if you disable this feature, then anonymous users are impersonating the application pool account. Which would be an elevation of priviledge.

– You can add an exclusion on Proxy server from SharePoint Server internet requests may not required any authentication .

– You can test to create a simple proxy module (which requires custom code development and IIS module integration) handle the proxy authentication.