Disclaimer: I always “eat my own dog food”. Right now I am working on a Packt book and one of the topics is Lync Passive Authentication. Before writing about this topic I have built a complete lab (honestly, more similar to a scaled down production environment) to test it. The following are my finding about the aforementioned feature.
Intro and Scenario
Starting with version 5.2 of the Lync 2013 mobile clients (October 2013), Microsoft has added support for passive authentication to Lync 2013. The aforementioned feature is important because it enables forms based authentication (built on Active Directory Federation Services – ADFS) and it is a starting point for the use of additional authentication mechanisms (for example, two factors authentication).
The basic steps are well outlined in the Jens Trier Rasmussen’s TechNet blog Microsoft Lync 2013 for Mobile and Passive Authentication
A theoretical explanation of the feature is available on the TechNet site Lync Server 2013 Certificate Authentication and Passive Authentication support for Lync 2013 Mobile applications
What I am going to examine here are the real-world challenges I have found, trying to make everything work.
The deployment I used is the one you can see in the following picture
Notes: All the servers are Windows 2012 R2. The IIS Application Request Routing (IIS ARR) used is version 3.0
All the IPs of the DMZ network (in the explanation, I will use address on the subnet 10.0.0.X) are published using a NAT.
Lessons Learned the Hard Way
Certificates
A commonly used solution is to use IIS ARR to publish both Lync “Simple URLs”, ADFS and Office Web Apps (OWApp). It is possible to achieve the aforementioned results in two different ways:
- A SAN certificate including all the FQDN of the aforementioned services and listening on a single IP
- Multiple certificates (for example one for Lync, one for OWApp and one for ADFS) with multiple public IP listening on the IIS ARR for the different services
Other solutions that I do not recommend, may include using a wildcard certificate or listening on non-standard ports on a single public IP (one port for every certificate).
I have preferred using the first solution. I created the CSR with the usual DigiCertUtil and defined it in the following manner
Subject:
- Madhatter.absoluteuc.biz Public FQDN of my Standard Edition (S.E.) Lync server
Subject Alternative Name:
- madhatter.absoluteuc.biz Public FQDN of my Standard Edition (S.E.) Lync server (again)
- adfs1.absoluteuc.biz Public FQDN the AD FS
- lyncdiscover.absoluteuc.biz Public FQDN for the auto-discover service
- meet.absoluteuc.biz Public FQDN for simple URL of Lync
- whiterabbit.absoluteuc.biz Public FQDN for OWApps
Notes:
- Right now I am not going to use the dialin or the admin simple URLs in the lab. In a production deployment you should add (at least) dialin
- I used a public Certification Authotity (C.A.) for my certificates, because testing from mobile clients is always a painful process with a deployment certificated from an internal C.A.
- This certificate is the same I used on the Lync S.E. for the Web Services – External. That is why the FQDN of the S.E. is both in the subject and in the subject alternative name.
AD FS
AD FS setup, using the Windows 2012 R2 wizard is not too complex. A pair of important notes:
- It makes everything simpler to have the aforementioned SAN certificate ready when you are going to enable AD FS on your server. The wizard will require an FQDN and a certificate, so it makes sense to start directly with the solution you will use for real
- The TechNet guide uses two different Relying Party Trusts , one for connections from internal clients and one for external ones (see the following picture from my AD FS, Gryphon)
You CAN’T fool AD FS, pointing the internal and the public FQDN for your S.E. server to the same IP. AD FS actually checks the URLs you insert and is aware of a “duplication”. Solutions are:
o Hairpinning the public FQDN to the internal IP of the IIS ARR
o Poining the public FQDN to the public IP (the one you used to NAT the DMZ’s IP of your IIS ARR).
I have preferred to use the hosts file on the IIS ARR to point it to the public IP. Basically, I tried a few times to hairpin meeting a series of issues, so I have preferred the easier way 🙂
Lync Registration Process
The main caveat here is that using passive authentication is a process you activate at the Lync POOL level. Not all the clients are compatible with passive authentication. I have copied the following table from a really good article Lync Passive Authentication with two-factor authentication – Part I on the Techmikal blog
As you can see, if you need some users to stay with the “standard” authentication, or if you need to keep Android and Mac working, the only solution is to have a registrar (and a pool) not enabled to passive authentication.
A scenario could be having a Director Pool and a couple of S.E. server for Lync. BTW, talking about Director Pool, take a look to my previous post Why I added a Lync Director Pool (also if I don’t like it) 🙂
IIS ARR
If you already have the Lync rules configured as in the TechNet Blog post Using IIS ARR as a Reverse Proxy for Lync Server 2013 , I have to say, quoting IIS Application Request Routing (Part 3) “remember that if you are using the same ARR server to publish multiple services, your rules must be very specific so they only match the URLs they should match! You should use a combination of the Pattern field in the Match URL section together with the {HTTP_HOST} condition to achieve this.” I.E., you have to add an {HTTP_HOST} rule for the AD FS FQDN.
Behavior of the Mobile Clients
Here comes the fun: looking at the list, you could think that Windows Phones are a piece of cake to use with Lync 2013 passive authentication. The answer is: not at all (and it is what took me a LOT of time for this lab)
Lync 2013 “Desktop” Client
This one simply authenticates as usual, no form from the AD FS is shown, also if you use a Windows client coming from the external network and not joined to the domain.
In the picture, you can see the logging for the WebInfrastructure component, that is the most relevant for the passive authentication process
Lync 2013 Store App
The Windows 8 – Lync 2013 Store App works as expected, redirecting you to the AD FS forms page and then allowing you access to Lync (see picture)
In the following image you can see the related WebInfrastructure logging
Lync 2013 for IPad
The IPad clients works well as the Windows store app when we deploy passive authentication. It shows the AD FS authentication page and then works as we expect it to do
Again, there is a capture of the logging. Note that there are 401 (unauthorized) errors for the webticketservice, but it looks like they have no consequence on the client.
Windows Phone 8 – Lync 2013 Client
I have used my good, cheap Lumia 620 phone. It tries to open the AD FS web page, but the result is a white page and there is no way to make it work. Considering that all the other clients work as expected, I suspect some kind of specific problem with the phone / Windows Phone version / client. Again, here are some screenshots of the logging. The errors are the same I have for the IPad, but the result is REALLY different
And more
And a last one
Android – Lync 2013 Client
It is NOT supported, and it goes as you could expect: the client stays stuck in the attempt to authenticate with Lync 2013
Summarizing
My impression is that the whole passive authentication mechanism in Lync 2013 still requires a lot of improvements. The fact that it is a pool level policy, the complex relation between Lync and AD FS, the no consistent errors (and results) I have with different kind of clients seems to point out for a promising but still problematic feature. Looking on the Internet, I see also really few posts / documents talking about this one. This is a good hint about something that not really much companies are using right now.
Logs
In the .zip file here, you will find the logs related to the different clients.
The first one to solve the Windows Phone “problem” will win an original Italian pizza, offered by me (as soon as you are in Rome, of course) 😀
