IOS 8 Safari SharePoint 2013 Windows Authentication Support

iosmicrosoft-sharepointsafari

I would like to support SharePoint 2013 with default out-of-box settings on iOS 8 devices. I see a lot of forum discussion on both Apple and Microsoft sites regarding IIS Windows Authentication being broken with Safari in iOS 8. Without bypassing Windows Authentication, I'm looking for details on any scheduled software fix in iOS 8, or workarounds like using Chrome on iOS 8 as mentioned in some of the forum posts. Unfortunately the Chrome workaround is a partial fix as iOS 8 does not allow Chrome to be the default browser for links opened from email or elsewhere on your mobile device. Here are the relevant discussions and links I used while attempting to find a solution or verify the problem.

Cannot see Sharepoint with iOS8 (Apple Support Communities)
iOS 8 Safari not working with […] Windows Authentication (Apple Support Communities)
SharePoint 2013 is not compatible with iOS 8 (Microsoft TechNet Forums)
sharepoint 2013 ios 8 safari (Google Search)

A note regarding Windows Authentication (NTLM/Negotiate) authentication default configuration for SharePoint 2013. For compatibility with various Microsoft products including the SharePoint Search Crawler, Microsoft Field Engineer Brian Pendergrass says "the crawler requires Windows Authentication [NTLM or Kerberos] in whatever zone your [sic] crawl …meaning your Default zone should include Windows Authentication)". Microsoft Office integration also seems to be optimized for SharePoint Windows Authentication. Based on this rationale, the default zone should always be configured for Windows Auth and only alternate zones should be used for alternative authentication like Forms Auth. Our organization chooses to deploy only one zone to require all SharePoint URLs to have the same form (SSL + Fully Qualified Domain Name) – thus we're stuck on a default zone with Windows Authentication.

Best Answer

Have you tried implementing the ADFS solution? Using client certificates

It's described here: https://sharepoint.stackexchange.com/questions/38086/sharepoint-repeatedly-prompting-ipad-users-for-credentials

And goes in to more detail here: https://paddleshift.wordpress.com/2013/03/01/authenticating-to-sharepoint-from-iphone-and-ipad/

Related Solutions

IOS – Does Safari for iOS 4.2.1 support WebGL

Not at this point, no. WebKit, that which Safari for Mac OS and iOS are both based on, is supposed to support WebGL but I have yet to be able to get it work properly on Mac OS 10.6, much less iOS. I get the impression the whole thing is too new (relatively) for proper support.

MacOS – Safari 7 can’t connect to intranet using HTTP authentication

I can confirm that I see the identical problem with Safari 7.0.2 (9537.74.9), with all current Mac OS X Mavericks updates installed. (Thousands of request packets per second with the same kind of content as described above.)

However, while this may or may not help the original poster, I have found that this problem only occurs if the Windows server has Integrated Windows Authentication (also known as NTLM Authentication) and Negotiate Authentication enabled.

The server then sends these two headers:

WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM

Safari will reply:

Authorization: Negotiate YEgGBisGAQUFAqA+MDygDjAMBgorBgEEAYI3AgIKoioEKE5UTE1TU1AAAQAAAAUCiGIAAAAAGAAAAAAAAAAYAAAABgGwHQ8AAAA=

And from there, the loop will get going.

But if Negotiate Authentication is not enabled on the server, there will be only one WWW-Authenticate header:

WWW-Authenticate: NTLM

And Safari's reply will be something like:

Authorization: NTLM TlRMTVNTUAABAAAAB4IIAAAAAAAAAAAAAAAAAAAAAAA=

This will work just fine. Essentially, it seems that Negotiate is broken in Safari, and since the server sends Negotiate first, indicating a preference for it, Safari will try it and enter an infinite loop that prevents it from falling back to NTLM.

So, if the server administrator can be persuaded to turn off Negotiate in the authentication settings, the problem may be solved.

I might add that Firefox sends the "Authorization: NTLM ..." header regardless of whether the server provides Negotiate in addition to NTLM or not. Presumably, Negotiate is not implemented in Firefox.

Update

Safari 7.0.3 (9537.75.14) still exhibits the same problem.

We previously reported the issue as a bug at bugreport.apple.com, but the bug was closed as a duplicate of a previous bug—the contents of which we cannot see, except that it is still marked as open.

Update 2

I can confirm hauns's finding that the authentication works with Safari 7.0.4 (9537.76.4).

Update 3

This issue is back in Safari 7.0.5 (9537.77.4)

Update 4

This issue is still present in Safari 7.0.6 (9537.78.2), as noted by hauns, with cifs or smb volumes mounted.