Ad hoc Apple App distribution IIS7 Windows Authentication IOS 5?

That sounds like you need to use one of those Apple support tickets.

I'm really glad you mentioned this, DJ. I've been troubleshooting the same problem for several days.

Our company had successfully implemented enterprise apps for over a year, but our employees have been unable to download any updates after the OS release. Our situation sounds nearly identical to yours: our apps are hosted on a secure Sharepoint server running IIS7, we no longer get a credentials challenge upon clicking the manifest link, and we get a 401 error in the console log.

I agree with your conclusion that this is a problem with iOS, and I'm interested to hear if Apple has any answers for you.

Our problems may be different after all. It seems that the apps are now simply unable to be installed while our employees are on our network.

• App hosted on internal server, user connected to company Wi-Fi: installation fails
• App hosted on external (non-company) server, user connected to company Wi-Fi: installation fails
• App hosted on internal or external server, user connected to 3G or public Wi-Fi: installation succeeds

You may want to verify that you aren't experiencing the same thing.

Has anyone been able to find a solution for this? We are also experiencing the same issue:

We have a windows authentication site set up in IIS 6. We have granted a small set of users rights to download and install the applications. We are currently testing using our internal networks, we have not been able to try external networks like _lucas has suggested.

iOS 4 - The application installs fine with the double authentication prompts.

iOS 5 - The application does not install, with the error "SSErrorHTTPStatusCodeKey=401, NSLocalizedDescription=Cannot connect to [our domain here]"

iOS 5 - The application installs fine if we convert our IIS site to Anonymous authentication.

Our IIS logs show 401 unauthorized as well. This is holding up our development efforts and planned rollout of our applications to our executives.

Our best guess is the iPhone/iPad hands off the URL now to some other process but does not take the authentication cookies with it. If this is true, this is a horrible regression.

DJRoadStar,

I am experiencing the same issue. Please post here when anyone find a solution.

Lucas,

I have tested this within our network and then by connecting through a public wi-fi and installation on iOS 5.0 fails in all the cases. YOUR CASE IS DIFFERENT.

If it can install via a public wi-fi it means that:

Apple says "If the devices are connected to a closed internal network, you should allow iOS devices access to these sites." in articlehttp://developer.apple.com/library/ios/#featuredarticles/FA_Wireless_Enterprise_ App_Distribution/Introduction/Introduction.html The wifi is on your work environment and is possibly preventing access to these two sites apple mentioned:

1) ax.init.itunes.apple.com\

2) ocsp.apple.com

On a seperate not, I can not search for Problem '9794546' on https://bugreport.apple.com. I guess apple doesnt allow you to see bugs opened by others, right?

any news on the subject ?

For us it's worked properly until last week ... and now it's working in 10% of the case ... still don't know why !

Hate to pile on, but we seem to be having the same issue here. Just started to use OTA to allow our employee's to install applications to their iOS devices. When the user connects using the itms-services url to our site (which is using SiteMinder for authentication and authorization) they are getting prompted over and over and over again and never able to download and install the app.

This isn't happening to everyone - but once it starts happening to a device, it seems to never work again on that device. It almost seems as though once the app is installed, the user is no-longer able to re-install the app (after deleting it) using the OTA method. So, first time might work but subsequent installs after deleting the app don't seem to work.

We've had our users delete cookies, purge cached data and website data in Safari but none of that seems to help. On our SiteMinder server, we are seeing messages that indicate that an expired authentication cookie is hitting the server so that's what's causing the credentials prompt to happen over and over again. When we navigate to the site used to host the OTA app using a standard https:// url, users authenticate fine and are able to hit the site. That does no good for us because you can download the file but not cause an install using teh https: URL format.

If anyone has seen a work-around for this or more information from Apple, please post. We're growing a little desperate.

I think we made progess today on this ...

are you using cookies? do you have more than one environement with the same cookie name?

the "installer" don't use the same user-agent as Safari and there is no way to clean the cookie...

and by the way it's why we've the double prompt

try to change the name of the cookie and it'd fix the issue ...

Yeah, we use cookies for authentication and we are getting the dbl-prompt the first time someone tries to install the app. After that first time, however, they can never install it again.

There's truly no way to delete the installer user-agent cookie cache?

Once itms-services link is tapped, a new process (with different user agent) is spawned. The new process doesn't contain authentication cookie/token while requesting the plist file, that's why you will get 403 error like: SSErrorHTTPStatusCodeKey=403, NSLocalizedDescription=Cannot connect to ###.

Yeah, of that (the separate user-agent that performs the install, kicked off from the itms-services call) I am aware - the so-called itunes user agent (you can find that out from the user-agent string exposed during TCP traces.

That user-agent is where the "bug" resides about handling the auth cookies. Once it gets its hands on an auth-cookie, that cookie cannot be deleted or refreshed and there is no way from the OS level to purge cookies (unlike Safari which provides this functionality throught its settings dialog on the device).

So, you get the cookie and you are able to install the app. Then the cookie expires (probably 60-120 minutes unless set differently by your admins) and because of the bug, it cannot be removed so you cannot authenticate again, the calling environment always gets an expired cookie.

The only way I've seen to get around this is to wipe the device - this removes the old auth cookie allowing you to authenticate again (but only once) so you can download an app.

Apple has gone through several iOS iterations and has still not resolve this issue. My ticket, and others I've heard about, have been closed as duplicates and from what I can tell, they've all been marked as a "serious bug" and all refernece back to the same original ticket.

None of us can see the original ticket (aside from the organization that created it, I suppose) and Apple either isn't updating all of the related tickets that were closed or they haven't done anything to resolve this issue yet.

I get 3 authentication promts:

• When first loading the site
• When clicking the itms-services link
• After the browser has closed and the app is downloading

Has anyone found a workaround for supressing all these excess prompts?

We faced similar issue recently. We were able to fix it by adding "Allow HEAD" to the protected resource in siteminder. Siteminder admins may have only enabled "GET and POST" as allowed operations.

The same may be true with other methods used for authentication.