Lync Passive Authentication: Getting Your Hands Dirty

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

 

Lab_outline

 

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)

 

LyncPass01

 

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

LyncPass02

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

Desktop_Client_Passive_Auth03

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)

 

Store_App_Passive_Auth00

 

In the following image you can see the related WebInfrastructure logging

Store_App_Passive_Auth02

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

IPAD_Passive_Auth00

 

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.

IPAD_Passive_Auth03

 

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

Lumia_Passive_Auth00

And more

 

Lumia_Passive_Auth01

 

And a last one

Lumia_Passive_Auth02

 

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) 😀

Lync Passive Authentication

 

Leave a Reply

Your email address will not be published. Required fields are marked *

Time limit is exhausted. Please reload CAPTCHA.