Hello everyone (and a special hi to Tom if you’re reading this)!
As I mentioned in my post about increasing lync security there is another option to enable two-factor authentication or application specific passwords for Lync, apart from passive authentication. For most of you who attended Lync conference 2014; you have most likely already heard of this option. Why do we need another option? Well, for some organizations this option might be a better fit. There are some limitations to the passive authentication solution that this option does not have; like the below examples.
Passive authentication is site wide
When Lync passive authentication is enabled, it is enabled site wide, more correctly it is set on the Lync web services level (
Exchange integration is not supported
The integration between Lync and Exchange is lost which in turn means that features are lost in the clients, for instance the meeting calendar.
Some clients does not support passive authentication such as the Mac client or several conferencing hardware products.
AD FS must be deployed and configured
While this isn’t a problem itself, it is quite a task to add to a Lync deployment if AD FS is not deployed already within the organization.
Enter the PointSharp authentication module. This is a third-party solution that integrates into the Front-End server’s IIS and takes over the authentication of the users. To get a bit more technical this solution protects the Webticket application externally and/or internally by presenting either a custom NTLM authentication or a SOAP based authentication. It uses the Windows APIs to create a Windows identity and then presents a valid user token to the Lync server.
While keeping the Lync sign-in experience intact it provides the option for an application specific password or a true two-factor authentication using tokens.
I was asked to do a demo with Lync and two-factor authentication without using domain passwords and in this case the passive authentication was not an option. There was also a requirement that only external clients have to use two-factor authentication. On top of this they also wanted to make use of the EWS integration. To get all this working I had to get a little creative. Let’s walk through it!
I’ll start with a network overview as I believe that will make my ramblings easier to understand. For those of you who read lync passive authentication with two-factor authentication will recognize the image with some small changes. Specifically that the AD FS server is gone and an Exchange server is added for Exchange web services integration.
First I had to install the authentication module on the Lync Font End server and configure it on the WebTicket web application on the Lync external web site. The configuration is done in the IIS management console and basically consists of pointing out the authentication server, to use NTLM and enable Lync support. Lync part done, on to the exchange integration.
Since the Lync client uses the credentials entered for both the access to Lync, Autodiscover and EWS all three had to accept the authentication being sent by the client (yes, I know there is an exchange credentials option but it isn’t very user friendly). I didn’t want to “disturb” any internal clients so I used the same approach as Lync does and created an external website on one of the CAS servers. I configured the bindings to be host based using a name that isn’t DNS resolvable on the LAN.
I then learned the hard way that creating new virtual directories for the autodiscover and EWS service by default points them to the same location as the original one, meaning that changes made on the external web application is also set on the original one. You don’t want to do this, trust me.
So instead I needed to create new virtual directories, completely separated from the original ones. I first copied some directories.
C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\ews -> C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\ext-ews
C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\autodiscover -> C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\ext-autodiscover
Then I created the virtual directories using the –Path switch.
New-WebServicesVirtualDirectory –Server cas01.domain.com –Path “C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\ext-ews” –ExternalUrl “https://ext-ews.domain.com/EWS/Exchange.asmx”
New-AutodiscoverVirtualDirectory –Server cas01.domain.com –Path “C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\ext-autodiscover”
Then I installed the authentication module and used the same configuration both virtual directories as I did on the Lync server, except that I didn’t enable the Lync features.
When this was done I had to configure the ARR to handle requests for the EWS and autodiscover and proxy these request to this newly created external web site on the CAS. First and foremost I had to add ext-web.domain.com to the host file of the ARR and point it to the IP-address of cas01.domain.com.
Then I created two new server farms, one for autodiscover and one for the EWS.
autodiscover.domain.com -> ext-web.domain.com
ext-ews.domain.com -> ext-web.domain.com
I also needed the ARR to rewrite the host header to match the configured binding. This is done in the URL rewrite module.
First I had to add a server variable named HTTP_HOST. Then I edited the autodiscover rule to rewrite the header like in the image below.
After this I did the same host rewrite change to the EWS rule and I was all set! The demo went perfect and everyone who does demos knows how good it feels when everything is spot on.
Phew! long post, I guess i need one of these.
TL;DR I configured stuff, made Lync authentication more secure, demo went perfect.
For those of you who actually read all of it; thanks for your time, I hope you enjoyed it!