Fast patching and lack of testing results in bad things.

Scenario:

With the recent release of iOS 6.14.0.224 client we have found that many customers are having all sorts of problems being able to login.  This problem only occurs if a customer uses an HTTP to HTTP redirect.  This is a very common scenario when customers have lots of SIP Domains and doesn’t want to purchase lyncdiscover.domain.com for every domain (because if you have 100 SIP domains that certificate is really expensive!).

So a common practice is to open port 80 (HTTP) and have the initial client request happen to lyncdiscover.domain.com.  The actual request that goes out includes the users SIP Address at the end of the request.  At this point in time, no password or anything else has been sent out, the server sees this message request on 80 and tells the client to instead go to https://extwebservername.domain.com.  That domain may or may not be in the same domain.  This configuration can be found in this TechNet Article:

https://technet.microsoft.com/en-us/library/mt723407.aspx#SupportedTopos

“This should be a straightforward process if you’re requesting the new certs off an internal CA (certificate authority), but public certificates are more complex, and potentially a lot more expensive to re-request, not to mention it may be costly to add a lot of SIP domains to a new public cert. In that situation, there is an approach that’s supported, but not recommended. You can configure your reverse proxy to make the initial Autodiscover service request over port 80, which will use HTTP, rather than port 443, which is HTTPS (and 443 is the default configuration). That incoming request will be redirected to port 8080 on your Front End pool or Director. By doing this, you won’t need to make any certificate changes, because this traffic isn’t using HTTPS for requests. But again, we don’t recommend this, although it will work for you.”

Although it’s listed as “not recommended” there is no good reason to not do this.  Even if you have lyncdiscover.domain.com on your SSL Certificate the auth process is exactly the same.  The client sends it’s SIP Address in the request and the user is redirected to the same https://extwebservername.domain.com address.  Essentially, you are potentially spending 10 of thousands of dollars on a redirect URL.

The latest iOS client simply doesn’t understand this redirect process.  So anyone updating their client will see a failure.  No good at all.

Solution:

UPDATE 4/28/2017 – The fix is out.  Build 6.14.1.229 of the iOS Client will allow you to login again.

Don’t update your client.  There isn’t a fix at this time.  We have an open ticket with Microsoft as they work on reproducing the issue.