Lync Passive Authentication with two-factor authentication – Part I

Hello and welcome to this two part series about Lync passive authentication with two-factor authentication. Passive authentication is a feature of Lync server 2013 which, simply put, makes Lync AD FS claims aware. This in turn means that Lync 2013 server can be integrated with Microsoft AD FS for authentication purposes. In this post we will go through the configuration of Lync passive authentication as well as how to configure Microsoft AD FS to require two-factor authentication for Lync 2013.

So why do you want this? Well, you want to get better security for your Lync 2013 environment. For more information read my post about increasing Lync security.

Lync passive authentication requires support in the Lync client to handle the redirect to the AD FS login. This is something that has to be taken into consideration before deploying passive authentication. Refer to the list below for whether a specific client supports passive authentication as of 2014-02-20.

Lync client support for passive authentication

Now that we’ve considered supported clients, let’s get started. To set all of this up you need to have a few things ready. Call it prerequisites before you can complete the rest.

  • A working Lync 2013 standard or enterprise server.
  • A reverse proxy publishing the Lync installation to the internet.
  • Microsoft AD FS installed configured.

In this environment I’m using the IIS Application Request Routing (ARR) as a reverse proxy. If you plan on using the ARR, I recommend this guide: Using IIS ARR as a Reverse Proxy for Lync Server 2013.

This is a simple network overview which I believe will help during the configuration.

lync_adfs_demo

AD FS configuration
We’ll start by preparing the AD FS server by setting up the Lync server as a relying party and apply some rules to it.

1. Log in to adfs.domain.com with an account with AD FS administrative permissions.
2. Start PowerShell.
3. Add relying party trusts.
Add-ADFSRelyingPartyTrust -Name Lync-Int -MetadataURL https://lyncfe01.domain.com/passiveauth/federationmetadata/2007-06/federationmetadata.xml
Add-ADFSRelyingPartyTrust -Name Lync-Ext -MetadataURL https://lyncweb.domain.com/passiveauth/federationmetadata/2007-06/federationmetadata.xml

4. Create authorization and transform rules.
$IAR = '@RuleTemplate = "AllowAllAuthzRule" => issue(Type = "http://schemas.microsoft.com/authorization/claims/permit", Value = "true");'
$ITR = '@RuleTemplate = "PassThroughClaims" @RuleName = "primarySid" c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid"]=> issue(claim = c);'

5. Configure relying party trusts
Set-ADFSRelyingPartyTrust -TargetName Lync-Int -IssuanceAuthorizationRules $IAR
Set-ADFSRelyingPartyTrust -TargetName Lync-Int -IssuanceTransformRules $ITR
Set-ADFSRelyingPartyTrust -TargetName Lync-Ext -IssuanceAuthorizationRules $IAR
Set-ADFSRelyingPartyTrust -TargetName Lync-Ext -IssuanceTransformRules $ITR

That’s it, for now, on the AD FS server. We’ll come back to it later in part II.

Lync server 2013 configuration
Now we must configure the Lync to use passive authentication and to trust claims issued by our AD FS server (adfs.domain.com).

1. Log in to lyncfe01.domain.com as a user who is a Lync universal server administrator.
2. Start the Lync Server Management Shell.
3. Create a new Lync WebService Configuration.
New-CsWebServiceConfiguration -Identity webserver:lyncfe01.domain.com -WsFedPassiveMetadataUri https://fs.domain.com/federationmetadata/2007-06/federationmetadata.xml

4. Disable default authentication mechanisms.
Set-CsWebServiceConfiguration -Identity webserver:lyncfe01.domain.com -UseWsFedPassiveAuth $true -UseWindowsAuth none –UseCertificateAuth $true

New-CsProxyConfiguration -Identity registrar:lyncfe01.domain.com -UseKerberosForClientToProxyAuth $false -UseNtlmForClientToProxyAuth $false

5. Change the mobility policy so it suits passive authentication
Set-CsMobilityPolicy -Identity Global -AllowExchangeConnectivity $false

At this point Passive authentication is set up! In part II of the series we’ll configure the two-factor authentication and make it mandatory. Stay tuned for part II.

Lync authentication process

This is my first blog post about Lync, more will come but since most of them probably will be about authentication in one way or another this post seems like a good start.

I started to look into the Lync authentication process after getting a lot of questions from customers who wanted to know if and how they could increase the security of their planned Lync environment. Specifically how to handle mobile clients. However, before we go into how to make the Lync environment more secure we need to understand how authentication works.

Microsoft Lync Server 2013 supports A LOT of different clients, it is clearly one of its strengths. There’s a client for PCs, Macs, smartphone, tablets and IP-phones to name some of them. Depending on the type and version of the client being used you gain access to a different set of features from the plethora of Lync features. There is, however, one thing all these clients have in common. To enjoy the wonderful world of unified communications each and any of these clients have to tell the server who is connecting. Simply put, anyone connecting to a Lync server has to authenticate themselves. This is neither shocking nor surprising in any way but it is a very important part of any system using digital identities.

Diving into the authentication process I quickly realized that the authentication process differs depending on the client and its network location. Digging even deeper (thank you Wireshark), I started looking at the actual requests and responses that takes places during a Lync sign-in. Whatever authentication protocol the client uses there are a few steps that each client does before it reaches to the stage where it actually authenticates to the server.

1. Lync discover
This works similar to the Exchange autodiscover. It is used mainly to figure out if the client is an internal or external client and where to connect.

2. Metadata Exchange (MEX)
When the client knows where to connect it makes a connection the MEX service. The MEX service exposes metadata about the service, essentially it provides information about how the server is configured. It tells a client how and where it should do authentication.

3. Acquire a webticket
What each Lync client want is a webticket. The webticket is used throughout the whole Lync experience. It’s the master ticket, the one ticket to rule them all, the… You get it. To acquire this ticket the client connects to the webticket service which then prompts the user for authentication. This is where it starts to differ between the clients.

Lync 2013 supports many authentication protocols and this post will not discuss all of them but the following list shows the authentication protocol being used by some Lync clients in a default installation.

Client Authentication protocol
PC-client (internal network) Kerberos
PC-client (external network) NTLM
Windows Phone NTLM
iOS NTLM
Android NTLM (Versions prior to 5.4 use SOAP)
Lync Web App (domain user) SOAP
Lync Web App (guest) SOAP (Anonymous)

My next post about Lync will discuss what can be done to increase the security for Lync 2013.