You might not face this particular issue, but it could be helpful to troubleshoot similar on how the mobile clients communicate with the external web services.
Everything was running normal on this customer, until the day we plan to implement a two factor authentication (TFA) engine. To understand the nature of the issue here’s the background design:
- In a standard deployment the ‘reverse proxy role’ will forward the external web services [public IP]:443 to the [front end pool]:4443
- The TFA solution replaces this roles and ‘intercepts’ the web services data (the components are installed on the Edge servers, work separately for mobile client devices). Besides DoS protection it validates user/device pairing
- For a high availability solution, hardware load balancers are used. Since these are web services, cookie passive affinity is used (a HLB cookie is inserted if the server response adds is own cookie). We could use MS recommendation of source IP affinity, but since there’s a lot of locations (with internet access through NAT) with thousands of users we want to ensure an equal load distribution for the TFA services.
Everything looks good and ready to go, but then this interesting behaviour start occurring:
- Windows and Android clients worked fine;
- but iOS (iPhone and iPad) start fail to sign-in;
- bypassing the ‘TFA filter’ will made all devices connect okM
- configuring the HLB to send all traffic to one node only, will also made iOS clients sign-inM
- With HLB Source IP affinity, all worked fine;
- Cookie insert affinity will still fails for iPhones and iPads;
- The latest Lync server and HLB firmware updates would not solve the issue.
You (and at the beginning I) would assume that the problem is somewhere related to the HLB on the TFA, right?
Well… troubleshooting the iPhone client give an additional surprise:
- When the client authentication process starts, the TFA component returns the server response to the client adding his cookie. The HLB will then also includes is cookie so the remain authentication process and traffic will be sent to the same server.
- but then I just notice the next client POST request is ignoring the HLB cookie and is only sending the TFA cookie !
The reason of the failure is that, without the HLB cookie, all client traffic requests are distributed across the two TFA and the other Front-end servers that didn’t participate on the initial negotiation and… the sign-in process fails.Looking at the same process for the Windows (Skype for Business) and Android (Lync 2013), all the cookies are sent.
After several reconfigurations attempts and troubleshooting, the issue was solved by defining on the HLB the cookie path (‘/’ instead of empty) , and the iPhone client start acting as it should:
- This time the HLB cookie is appending the path
- And the iPhone client send all the cookies on the next POST request
So at the end, it looks like that there is some sort of undocumented behaviour on Lync 2013 client for iOS.
Update: the issue is the same on the new Skype for Business version