Authentication Issues: Microsoft Word for Mac

Update 2016-07-21:

Since originally drafting this blog, the slow launch issue detailed below has been fixed with version 15.24 of the Microsoft 2016 applications. The proxy pop messages still occurring as per the below.

Hi all. In this post I’ll share some information I’ve found whilst working with Microsoft Office 2016 at a client’s site with high security requirements.

Background Information

The client in question has only just started supporting Macs internally. The Macs in question are running El Capitan (10.11.4 at the time), joined to AD and utilise a Kerberised proxy solution, configured to fall back to NTLM (the ‘proxy authentication popup’) if the device is not authorised for the HTTP/HTTPS traffic in question.

The Problem

Amongst other applications, the client was deploying Microsoft’s Office for Mac 2016 suite using a site-license for all Macs. This deployed and installed without complaint.

When first launching any of the ‘core three’ Office applications (Word, PowerPoint and Excel, but strangely not Outlook), these took between 2-5 minutes to launch. Once they did, a window as per the below, was shown to the end user:

cut down

If the user entered their Proxy username and password the application would load and run fine, but the same message would appear (along with the delay) the next time one of the core three applications are launched.

If the user dismissed the window by using the red ‘X’ button, another 4-5 windows would appear, one at a time. This procession of popup windows would repeat another 2-3 times depending on what options users selected within the application (e.g. “New”, “Open” etc).

After working the issue with the client, we found that the Office application in question was correctly using the Kerberised authentication initially, but almost immediately fell back to an authentication request, and prompted the user for these details.

The Solution

After some work, we found the URLs that the Office applications reach out to (all 443) on launch:

  • nexus.officeapps.live.com
  • ocos-office365-s2s.msedge.net
  • config.edge.skype.com
  • officeclient.microsoft.com
  • odc.officeapps.live.com
  • store.office.com
  • omextemplates.content.office.net
  • nexusrules.officeapps.live.com
  • templateservice.office.com

In the end, the client had to configure  these URLs as allowed ‘unauthenticated’ through the proxy to resolve the issue. The client reached out to Microsoft support who confirmed that this was the correct resolution to the issue.

Additional Information

Since my own journey of discovery, Paul Bowden (Microsoft Software Engineer for Office for Mac / iOS) on the MacAdmins Slack instance (goes by the handle ‘pbowden’ in the #microsoft-office channel) posted a PDF called “Network Requests in Office 2016 for Mac“.

This details a number of URLs that the Office for Mac 2016 apps reach out to and why. Additionally, it also provides details on ways to reduce the network requests and traffic.

I have yet to test these in the same restrictive environment as I found at the specific client’s site, but I imagine it would certainly help reduce the URLs listed above, and the requirement to allow them through unauthenticated.

Summary

There you go, hopefully that’ll give other Mac Admins a helping hand with trying to use Microsoft Office 2016 in a locked down environment. 

As always, if you have any questions, queries or comments, let us know below and I’ll try to respond to and delve into as many as I can.

The usual Disclaimer:

While the author has taken care to provide our readers with accurate information, please use your discretion before acting upon information based on the blog post. Amsys will not compensate you in any way whatsoever if you ever happen to suffer a loss/inconvenience/damage because of/while making use of information in this blog.

3 Replies to "Authentication Issues: Microsoft Word for Mac"

  • Why can’t Microsoft simply use the system network stack like all good applications thus removing the need for whack-a-mole adding URLs to a global anon list

    Bad MS. Shame. Shame. Shame.

  • Dan Hodge

    Hi Darren,

    Great article, and great share, this appears to have changed with the release of Sierra and possibly an update from MS. The “template window does not open anymore, but you get a message at the end “There is a problem with your account. Please try again later.” Turning off the https proxy solves it, but one can not have a https proxy turned off, still looking for the solution.
    Dan

    • Darren Wallace

      Hi Dan,
      Thanks for the update. I’ve yet to have to go back to this so I’ve not tested it with Sierra yet.
      It sounds like there are more URLs that need to be whitelisted. I would suggest working with your proxy administrator to see what ports the client is being blocked from (should be visible in the Proxy logs) and whitelisting them.

      Good luck!

      Darren

Leave a Reply

Your e-mail address will not be published. Required fields are marked *