Problem: A SharePoint 2010 Web Application viewed on Safari on an iPad randomly prompts for login credentials in the same browser session even though the user has already been authentication once.
This issue has ONLY been found on a Web Application with the following characteristics:
- It uses NTLM (Active Directory) Authentication
Solution: It turns out there is no OOTB solution to this issue. There are only workarounds.
Any one of the workarounds described below should resolve this issue:
Workaround #1) The same site that does not work well with Safari on an iPad has been found to work seamlessly in the Chrome Browser on the iPad. You can either ask users to always use that site on Chrome by typing the Url or deploy a native iPad app that launches the Url of the SharePoint 2010 Web App in Chrome automatically, giving the users a more seamless experience. In the desktop world we call these shortcuts.
Believe it or not, creating the shortcut for Chrome is not as easy on an iPad as it is on a Desktop. Apple forbids iPad users from making Chrome as the default browser, preventing any shortcut from opening Chrome. There are other solutions that have been suggested, such as the one in this link, but it still requires a user to manually set up the link. For Enterprise users, many of whom might not be very tech savvy, it might be a hard solution.
Both the Chrome app and the native iPad app suggested in this workaround could be deployed remotely to Enterprise iPads if you have an MDM solution in place, making the experience seamless for Enterprise Users. The code for the Xcode project can be downloaded here.
Once you download the project, you will need to modify the bundle identifier, upload the App Icon for your App, modify the Url to open in Chrome in the AppDelegate.m file, Build the Xcode Project, test and distribute based on your preference (Ad Hoc distribution, MDM, App Store etc.).
I got the code for the project from the following link provided by Google on how to open Urls in the Google Chrome App automatically.
https://developers.google.com/chrome/mobile/docs/ios-links
Workaround #2) Extend the Web Application to use FBA (whether you use it or not), create a different URl and have users navigate to the different Url from iPads.
You can do so using the steps outlined below:
· Zone-1: A URL that uses NTLM, good for use on internal users/desktops machines within the office. So you can utilize the pass-through authentication of NTLM (no prompts for any password or authentication method).
· Zone-2: A secondary zone/URL for use specifically for the iPad (so the user is prompted for an authentication method and their username/password).
· It will not be possible to simply have one URL that will work seamlessly between internal users/desktop computers and iPad users, unless the internal users do not mind the hassle of selecting an authentication method and then typing in their password every time they want to access the portal.
· However, you can devise a redirect page on the main URL that will detect the user’s device (desktop, tablet, smartphone) and redirect the user to the appropriate URL (you will however still need to setup two webzones/two URLs to see this solution through). OR, you could have some sort of automatic redirect at the Firewall that determines from the device accessing the portal and then redirects the user to that url. But SharePoint will need to have 2 Urls and 2 Zones for this to work.
Workaround #1) seemed to be a better solution that Woraround #2) because of the following reasons:
a) Requires less communication to users about 2 different Urls for the same Web Application.
b) Does not require making architecture changes to the SharePoint Web Application by creating two zones, one with FBA authentication and the other one with NTLM Authentication,
c) Since the problem is specific to iPad safari, the solution should be specific to the iPad and not force us to modify the Architecture of the Web Application we set up originally.
d) If an Enterprise has a strong MDM platform, which many organizations do these days, the App developed in Workaround #1) can be deployed remotely along with the Google Chrome App and make the experience seamless for users.
Workaround #3) If there is an option to use claims based authentication, you could use that and use Integrated Windows Authentication along with it. That has seemed to work the best on Safari, although not without issues. It often randomly prompts for login twice and works on Chrome better than Safari. However, it works much better than a web application with NTLM Authentication.
This issue has ONLY been found on a Web Application with the following characteristics:
- It uses NTLM (Active Directory) Authentication
Solution: It turns out there is no OOTB solution to this issue. There are only workarounds.
Any one of the workarounds described below should resolve this issue:
Workaround #1) The same site that does not work well with Safari on an iPad has been found to work seamlessly in the Chrome Browser on the iPad. You can either ask users to always use that site on Chrome by typing the Url or deploy a native iPad app that launches the Url of the SharePoint 2010 Web App in Chrome automatically, giving the users a more seamless experience. In the desktop world we call these shortcuts.
Believe it or not, creating the shortcut for Chrome is not as easy on an iPad as it is on a Desktop. Apple forbids iPad users from making Chrome as the default browser, preventing any shortcut from opening Chrome. There are other solutions that have been suggested, such as the one in this link, but it still requires a user to manually set up the link. For Enterprise users, many of whom might not be very tech savvy, it might be a hard solution.
Both the Chrome app and the native iPad app suggested in this workaround could be deployed remotely to Enterprise iPads if you have an MDM solution in place, making the experience seamless for Enterprise Users. The code for the Xcode project can be downloaded here.
Once you download the project, you will need to modify the bundle identifier, upload the App Icon for your App, modify the Url to open in Chrome in the AppDelegate.m file, Build the Xcode Project, test and distribute based on your preference (Ad Hoc distribution, MDM, App Store etc.).
I got the code for the project from the following link provided by Google on how to open Urls in the Google Chrome App automatically.
https://developers.google.com/chrome/mobile/docs/ios-links
Workaround #2) Extend the Web Application to use FBA (whether you use it or not), create a different URl and have users navigate to the different Url from iPads.
You can do so using the steps outlined below:
· Zone-1: A URL that uses NTLM, good for use on internal users/desktops machines within the office. So you can utilize the pass-through authentication of NTLM (no prompts for any password or authentication method).
· Zone-2: A secondary zone/URL for use specifically for the iPad (so the user is prompted for an authentication method and their username/password).
· It will not be possible to simply have one URL that will work seamlessly between internal users/desktop computers and iPad users, unless the internal users do not mind the hassle of selecting an authentication method and then typing in their password every time they want to access the portal.
· However, you can devise a redirect page on the main URL that will detect the user’s device (desktop, tablet, smartphone) and redirect the user to the appropriate URL (you will however still need to setup two webzones/two URLs to see this solution through). OR, you could have some sort of automatic redirect at the Firewall that determines from the device accessing the portal and then redirects the user to that url. But SharePoint will need to have 2 Urls and 2 Zones for this to work.
Workaround #1) seemed to be a better solution that Woraround #2) because of the following reasons:
a) Requires less communication to users about 2 different Urls for the same Web Application.
b) Does not require making architecture changes to the SharePoint Web Application by creating two zones, one with FBA authentication and the other one with NTLM Authentication,
c) Since the problem is specific to iPad safari, the solution should be specific to the iPad and not force us to modify the Architecture of the Web Application we set up originally.
d) If an Enterprise has a strong MDM platform, which many organizations do these days, the App developed in Workaround #1) can be deployed remotely along with the Google Chrome App and make the experience seamless for users.
Workaround #3) If there is an option to use claims based authentication, you could use that and use Integrated Windows Authentication along with it. That has seemed to work the best on Safari, although not without issues. It often randomly prompts for login twice and works on Chrome better than Safari. However, it works much better than a web application with NTLM Authentication.
