* Updated 2014-04-17
Added two-factor authentication explanation and updated the image showing the mobile sign in experience. Thanks to Shawn Harry (@shawnharry on twitter, you want to follow him) for pointing this out
Welcome back to part II in this series about “Lync Passive Authentication with two-factor authentication”. In part I we looked at the configuration of passive authentication both on the Lync server and on the AD FS side. Today we’ll take a look at how to add two-factor authentication to this.
Lync passive authentication cannot do two-factor authentication by itself. It relies on AD FS to do the actual authentication. In turn AD FS requires a third-party authentication solution to bring two-factor authentication to the table. Let’s set the table!
First we need to set up a Security Token Service (STS) that can do the authentication and get the correct claims and pass them to the AD FS which in turn will send us to Lync with claims that is trusted by the Lync 2013 server. In this setup I’m using PointSharp Identity Federation which includes an STS which I have installed on the AD FS server. Please note that the actual STS configuration depends on the STS you use but it should be similar for many.
The configuration of this STS is done in the IIS Management console in a “snap-in” on the PointSharpSTS web application.
There’s a few settings you need to configure for this to work. In this case we need to tell the STS where the authentication server is, which authentication method to use, who the issuer of the claims is, the URI of the issuer, the relying party URL and a signing certificate that the AD FS trusts.
By looking at the above image and at the network topology image from part I of the series you will know what names should be put where. In my case the STS is installed on the AD FS server itself so the certificate used for signing the claims is the same as the AD FS uses.
We also need to configure the claims the STS should create and pass on to the AD FS. Lync 2013 wants the primarySID claim. In this case we tell the STS to collect the attribute values of userPrincipalName and objectSID from the authenticated user and send the values as claims to the AD FS.
The next step is to tell the AD FS that the STS is a trusted claims provider. The steps to do this differs a little between different STS’s. You can either use the <code>Add-AdfsClaimsProviderTrust cmdlet<code> in powershell or the AD FS management console. In my case the only thing I had to do was to point out the URL to the STS and give it a name (PointSharp ID in my setup for reference).
When the STS is added it will be listed as a claims provider. We now need to make a claim rule to pass the primarySid claim through. This can be done in the management console but the below example is for powershell.
1. Create a text file on your AD FS server using your favorite editor and paste the lines below into it.
@RuleTemplate = "PassThroughClaims"
@RuleName = "Pass through primary SID"
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid"]
=> issue(claim = c);
2.Save the file as C:\ClaimsProviderRules.txt.
3. Start Windows PowerShell.
4. Attach the claim rule to the claims provider.
Set-AdfsClaimsProviderTrust –TargetName "PointSharp ID" -AcceptanceTransformRulesFile "C:\ClaimsProviderRules.txt"
The final step is to force users who want to use Lync to use the STS that we just configured. This is done by modifying settings on the relying party which is the Lync server.
1. Start PowerShell on the AD FS server
2. Modify Lync relying party (note that “PontSharp ID” is the name of my claims provider in the AD FS console).
Set-AdfsRelyingPartyTrust -Targetname Lync-Ext -ClaimsProviderName @("PointSharp ID")
Set-AdfsRelyingPartyTrust -Targetname Lync-Int -ClaimsProviderName @("PointSharp ID")
The table is now set and this is what it looks like when the dinner is served:
Lync mobile client:
1. Enter SIP-address.
2. Enter username and app-password (not domain password)
3. Enter a valid OTP (One-Time Password)
4. Logged in!
In the above example a hardware token was used to generate the OTP that provides the second factor in our two-factor authentication. As Shawn mentions in his comment, an SMS could also be used to provide the OTP.
The sign in process is the same as on mobile clients, only the graphics differ.
I hope you have enjoyed this series about Lync passive authentication with two-factor authentication”. This part concludes the series but stay tuned for more Lync security.
Bit confused here. Exactly what did you use to provide the 2FA? If Pointsharp is its own STS that sits on top of ADFS what additional authentication type did you use to authenticate the user? SMS? RSA?
What are the options and ‘how’ would you integrate say RSA with Passive Auth/ADFS? Does your plugin act as a broker of sorts to do this? As your STS serves another forms based page the same as ADFS normally does which presumably still requires AD credentials. So im not entirely sure what the additional benefit here is of your plugin unless it provides the broker between the STS and 2FA to provide 2FA without having to enter AD credentials?
Thanks for pointing out the lack second factor explanation in the post. I have updated the post accordingly and I will also answer the questions here in the comment.
In this case the first factor is the username and application specific password (no AD password) and the second factor is a One-Time Password generated from a hardware token.
The PointSharp STS sits on top of ADFS but the actual authentication is done towards the PointSharp ID server. Upon a successful authentication the STS gathers the configured claims and passes the request to ADFS who does final transforms or pass-throughs before redirecting the client to the application.
I dont have any experience with RSAs STS (if they have one) so I cant say for sure how to set it up or if it works.
I hope this explains it a bit more. If not, let me know!
Thanks @Techmikal. One last question just for my own clarification. Is your product a requisite then for integration to provide a 2FA solution between ADFS/Passive Auth and for sake of argument RSA? Or can that integration be done ‘natively’ without the requirement for your plugin?
Hello Shawn. Natively ADFS can not provide a passive 2FA without a 3rd party authentication solution and definitely not without AD credentials. In this case the PointSharp products act as that authentication solution. Passive auth can be done with any STS that supports ADFS passive auth, this example shows a 2FA scenario without domain passwords. The choice of STS/authentication solution is the one I personally have access to.
Hi Techmikal. I know ADFS cannot provide 2FA. But what i’m trying to understand is is ‘where’ does your plugin fit in? So if i was to use ADFS & RSA (for example) would i need your plugin to enable the 2FA functionality? So in other words RSA would need to provide their own STS that could integrate with ADFS in order to provide the 2FA correct?
Hello Shawn. Sorry, I misunderstood. You are correct, if you were to use another authentication solution they would have to provide their own ADFS compliant STS and authentication server. “In the field” I find that most look for an active solution instead. Like the one you’ve commented on before on my blog.
Thanks. Does PointSharp have any plans to get their plugin to work with RSA? You said you used a hardware token. What token/product was this?
As PointSharp has their own authentication solution (PointSharp ID) support for RSA authentication isn’t likely except for scenarios where RSA is being phased out. The token used in this scenario is a credit card token and PointSharp ID is the product responsible for the actual authentication. You can see the token options here: http://www.pointsharp.com/products/pointsharp-id/tokens
Thanks for answering all my questions! 🙂
My pleasure. Thanks for reading, pointing out the flaws in my post and letting me explain. Much appreciated. You know where to find me if more questions arise 🙂