jartef
asked on
IIS 6 authentication problem from iPad mobile Safari browser
I have an intranet site running on SBS 2003. Authentication used is IWA. The site also has a public IP assigned to it so users can connect over the internet by providing their usernames and passwords when prompted. The problem we are seeing is when a user tries to connect to the site via iPad mobile Safari. The user is intermittently prompted to enter credentials repeatedly even though authentication has already been successfully completed. The frequency of the prompts is fairly random, sometimes allowing them to use the site uninterrupted for 15-20 minutes and other times prompting at nearly every request to the server. This is obviously very frustrating.
I have already tried a few things but nothing seems to be working. I tried updating the value of AuthPersistSingleRequest to false so that the authentication would not be required with every single request. I tried enabling Basic Authentication (over SSL) because I'd read that there might be issues with the NTLM handshake. I'm not sure exactly what is the problem here.
Looking at the IIS 6 logs I do see a number of 401 errors logged, but strangely these get logged even when the requests are successful. I imagine that has to do with there being an attempt to authenticate anonymously first before passing the credentials. I usually in these cases see a 401.2 followed by a 401.1 and then a 200 status code.
I would like to leave IWA enabled if possible because the users on the LAN should not need to prompted for credentials when they are already logged in to the domain. Any suggestions or referrals to resources on this matter would be greatly appreciated.
Thanks,
Anthony
I have already tried a few things but nothing seems to be working. I tried updating the value of AuthPersistSingleRequest to false so that the authentication would not be required with every single request. I tried enabling Basic Authentication (over SSL) because I'd read that there might be issues with the NTLM handshake. I'm not sure exactly what is the problem here.
Looking at the IIS 6 logs I do see a number of 401 errors logged, but strangely these get logged even when the requests are successful. I imagine that has to do with there being an attempt to authenticate anonymously first before passing the credentials. I usually in these cases see a 401.2 followed by a 401.1 and then a 200 status code.
I would like to leave IWA enabled if possible because the users on the LAN should not need to prompted for credentials when they are already logged in to the domain. Any suggestions or referrals to resources on this matter would be greatly appreciated.
Thanks,
Anthony
ASKER
Thanks for the link. I am unable to access my logs right now but will do so soon and get back to you.
ASKER
As I mentioned above, my IIS logs frequently show a 401.2 followed by a 401.1 even when all works fine without prompting for re-authentication. What I did notice is that when it seems to work the 401.2 has a win32 status code of 2148074254, which from what I gather means 'logon failed due to server configuration'. I believe that these items in the log simply indicate that any initial attempt to serve the request using the disabled anonymous account would fail. These cases are usually followed by a status code of 200 and the user is not prompted to re-authenticate.
Narrowing down the log to the specific requests that did seem to re-prompt for authentication I am seeing a 401.2 with a win32 status of 1236 which seems to indicate that the network connection was somehow aborted. It seems that the ipad is in this case having trouble persisting the connection and is thus requiring a new authentication. I thought that setting the AuthPersistSingleRequest metabase value to false would handle this problem but perhaps I am misunderstanding what this value means. A technet article I read states that this setting is only honored when the following two conditions are met: Integrated Windows authentication is set to NTLM and Integrated Windows authentication is set to Negotiate, and NTLM authentication is used. I am not exactly sure how to verify that these statements are true.
I suppose another solution would be to somehow use cookies to store the session data and check whether the user has already been authenticated but I am not sure how to use this method in conjunction with IWA and NTLM. Is it possible to specify different modes of authentication or different directory security altogether based on whether the user has connected to the page over the intranet or from the internet? I do have an SSL certificate and can pretty safely use basic authentication over the internet, but I do not want to lose integrated authentication for intranet users. Then again I am not really sure that switching to basic auth would persist if it appeared that the connection had been reset.
Narrowing down the log to the specific requests that did seem to re-prompt for authentication I am seeing a 401.2 with a win32 status of 1236 which seems to indicate that the network connection was somehow aborted. It seems that the ipad is in this case having trouble persisting the connection and is thus requiring a new authentication. I thought that setting the AuthPersistSingleRequest metabase value to false would handle this problem but perhaps I am misunderstanding what this value means. A technet article I read states that this setting is only honored when the following two conditions are met: Integrated Windows authentication is set to NTLM and Integrated Windows authentication is set to Negotiate, and NTLM authentication is used. I am not exactly sure how to verify that these statements are true.
I suppose another solution would be to somehow use cookies to store the session data and check whether the user has already been authenticated but I am not sure how to use this method in conjunction with IWA and NTLM. Is it possible to specify different modes of authentication or different directory security altogether based on whether the user has connected to the page over the intranet or from the internet? I do have an SSL certificate and can pretty safely use basic authentication over the internet, but I do not want to lose integrated authentication for intranet users. Then again I am not really sure that switching to basic auth would persist if it appeared that the connection had been reset.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
While there are some 3rd party browsers currently available on the iPad, they are not really a viable option at this point.
I am definitely seeing the 2148074254 win32 status with 401.2, but as I said that seems to happen all the time even when connecting from browsers that are not having the reauthentication issue. From what I gather this is not part of the problem but is normal behavior when the browser initially attempts an anonymous connection for the request.
I do understand that the 1236 is a network issue and I can confirm that the problem is less prevalent when connecting over wifi than when connecting via 3G. Basically I assume that there is a momentary drop in the connection between the ipad client and the web server and thus the server assumes that there is a new connection which requires reauthentication. I think that this is just a fact of life given the nature of the device.
I guess what I am looking for is some way to force IIS to recognize that the re-established connection from the same device should re-use the authentication that had already been provided. The best method that I could come up with to accomplish this would be to allow for basic authentication over SSL where the encrypted credentials could just be passed along with the request each time. What I am not sure of is how to best configure basic authentication to run alongside IWA or how to restrict basic authentication to only be permissible over SSL. I want to be able to force basic auth over SSL whenever a connection to IIS is initiated over the internet and keep IWA available to local traffic to IIS.
I am definitely seeing the 2148074254 win32 status with 401.2, but as I said that seems to happen all the time even when connecting from browsers that are not having the reauthentication issue. From what I gather this is not part of the problem but is normal behavior when the browser initially attempts an anonymous connection for the request.
I do understand that the 1236 is a network issue and I can confirm that the problem is less prevalent when connecting over wifi than when connecting via 3G. Basically I assume that there is a momentary drop in the connection between the ipad client and the web server and thus the server assumes that there is a new connection which requires reauthentication. I think that this is just a fact of life given the nature of the device.
I guess what I am looking for is some way to force IIS to recognize that the re-established connection from the same device should re-use the authentication that had already been provided. The best method that I could come up with to accomplish this would be to allow for basic authentication over SSL where the encrypted credentials could just be passed along with the request each time. What I am not sure of is how to best configure basic authentication to run alongside IWA or how to restrict basic authentication to only be permissible over SSL. I want to be able to force basic auth over SSL whenever a connection to IIS is initiated over the internet and keep IWA available to local traffic to IIS.
ASKER
What wound up working in the end was to accept basic authentication over SSL and pass around the credentials with all of the http requests. Never quite did determine why the iPad browser has such a hard time maintaining state with NTLM auth to IIS but the above workaround is suiting us fine. Comments from Rovastar definitely helped point me in some educational directions regarding this matter so I am awarding points even though the question at hand never was really answered.
http://blogs.msdn.com/b/david.wang/archive/2005/07/14/howto-diagnose-iis-401-access-denied.aspx
Wha do your IIS logs say?