Passive authentication requires establishing trust between the AD FS Server and the Lync Server (because user credentials will be forwarded by the latter service). Lync mobility policies require customization too. We will see the steps to configure passive authentication now.
Based on the schema of our lab environment, we will use madhatter.wonderland.lab as the internal FQDN of the Lync 2013 Standard Edition (SE) Server. The madhatter.absoluteuc.biz is the public name for the pool, while gryphon.wonderland.lab is the internal FQDN of the AD FS server, and adfs1.absoluteuc.biz is the public name for the same service.
Note
If we have no AD FS server available, the first step will be to add the role from Server Manager and configure it (for example, we can follow the steps outlined in the TechNet post How To Install ADFS 2012 R2 For Office 365 at http://blogs.technet.com/b/rmilne/archive/2014/04/28/how-to-install-adfs-2012-r2-for-office-365.aspx).
- We have to configure trust relations between the AD FS server and the Lync Server so that Lync will accept the account information sent from the AD FS server on behalf of the user. This is done by creating a relaying party trust and appropriate Issuance Authorization and Transform rules (more details about AD FS relying party trust are in the How it works… section of this recipe).
- AD FS trust relationships are based on the server names stored in the SSL certificates. It is required to have two separate trusts, one for the public name of our Lync pool and one for the internal one. We will call them
Lync-Ext-PassiveAuth(based on the external name) andLync-PassiveAuth(based on the internal name).Note
We is not allowed to create two trust relations that point to the same IP (in this scenario, the one used by the Lync 2013 SE Server), and we have to use the reverse proxy for both Lync mobile clients that connect from the external network and from the internal network. We can split the trusts, one on the external interface of IIS (Lync-Ext-PassiveAuth) and the other hair pinning on the internal interface of IIS (Lync-PassiveAuth).
- In the following steps, we will define the transform rules and trusts. We have to define the authorizing claims requesters (Authorization Rules) to control which users have access to the relying party:
$IssuanceAuthorizationRules = '@RuleTemplate = "AllowAllAuthzRule" => issue(Type = "http://schemas.microsoft.com/authorization/claims/permit", Value = "true");'
- The next step is to define Issuance Transform Rules to issue claims to the relaying party:
$IssuanceTransformRules = '@RuleTemplate = "PassThroughClaims" @RuleName = "Sid" c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid"]=> issue(claim = c);'
- Now, we are able to define the Relying Party Trust (Lync-Ext-PassiveAuth) between the AD FS server and the internal name of the Lync Server:
Add-ADFSRelyingPartyTrust -Name Lync-PassiveAuth -MetadataURL https://madhatter.wonderland.lab/passiveauth/federationmetadata/2007-06/federationmetadata.xml
- The next step is to apply the previously defined Authorization and Issuance Transform Rules to the Lync-PassiveAuth Relying Party Trust:
Set-ADFSRelyingPartyTrust -TargetName Lync-PassiveAuth -IssuanceAuthorizationRules $IssuanceAuthorizationRules Set-ADFSRelyingPartyTrust -TargetName Lync-PassiveAuth -IssuanceTransformRules $IssuanceTransformRules
- The steps that we performed for the Lync-PassiveAuth trust will be repeated for the Lync-Ext-PassiveAuth (that is based on the public name of the Lync Server):
Add-ADFSRelyingPartyTrust -Name Lync-Ext-PassiveAuth -MetadataURL https://madhatter.absoluteuc.biz/passiveauth/federationmetadata/2007-06/federationmetadata.xml Set-ADFSRelyingPartyTrust -TargetName Lync-Ext-PassiveAuth -IssuanceAuthorizationRules $IssuanceAuthorizationRules Set-ADFSRelyingPartyTrust -TargetName Lync-Ext-PassiveAuth -IssuanceTransformRules $IssuanceTransformRules
- The result is seen in the following screenshot (taken from the ADFS Management Console):
- It is required to disable other authentication methods on Lync 2013 (we mentioned them in the introduction of this chapter) because the server uses them before using the passive authentication. We have to disable Kerberos and NTLM on three Lync services: Lync Autodiscover WebServer, Front End WebServer and Front End Registrar. The first two will use certificate and passive authentication, while the Front End Registrar will only use certificates.
- We are going to define a new web service:
New-CsWebServiceConfiguration -Identity webserver:madhatter.wonderland.lab -WsFedPassiveMetadataUri https://adfs1.absoluteuc.biz/federationmetadata/2007-06/federationmetadata.xml
- On the new web service, we will enable certificate and passive authentication and disable Kerberos and NTLM:
Set-CsWebServiceConfiguration -Identity webserver:madhatter.wonderland.lab -UseWsFedPassiveAuth $true -UseWindowsAuth none –UseCertificateAuth $true
- We will define a new registrar configuration with Kerberos and NTLM disabled:
New-CsProxyConfiguration -Identity registrar:madhatter.wonderland.lab -UseKerberosForClientToProxyAuth $false -UseNtlmForClientToProxyAuth $false
- By looking at the Registrar and Web Service tabs, we can verify the result of the previously mentioned configuration from Lync Server Management Shell or inside Lync Server Control Panel | Security:
- Passive authentication for Lync 2013 mobile clients does not support the Exchange server. To enable the passive authentication feature for users, we will set AllowExchangeConnectivity to
$falsein CsMobilityPolicy to suppress the error messages related to the Exchange Web Services (EWS). In our example, we will assign it to the wonderlandfab user in thewonderland.labdomain:New-CsMobilityPolicy -Identity PassiveAuthUsers -AllowExchangeConnectivity $false Grant-CsMobilityPolicy -PolicyName PassiveAuthUsers -Identity wonderlandfab
- It is now possible to test passive authentication from a mobile client, like the one for iPad. The logon phase should redirect us to an AD FS form-based authentication page, like the one in the following screenshot:
To explain how the AD FS Relying Party Trust works, we have to introduce some of the following basic concepts:
- Claim: This is information about a user from a trusted source.
- Trusted source: This confirms that the content of the claim is true. A trusted source has verified the information with an authentication method.
- Claims provider: This is the source of the claim (in our scenario, Active Directory).
- Relying party: This is the destination for the claims (in our scenario, Lync Server).
- Relying party trust: This is the trust between the AD FS server and the relying party.
Based on a set of rules (Acceptance Transform Rules), the claims from the claim provider will be filtered or passed to the Relying party trust. AD FS controls which users have access to the relying party based on the Issuance Authorization Rules. AD FS issues the claims to the relaying party by using the Issuance Transform Rules. In the schema shown in the following screenshot, we have a high-level overview of the mechanism inside the AD FS server that converts the incoming claims from the Claims Provider Trust and transmits them over the Relying party trust:
Note
Right now, Lync clients for Android and Mac are not able to sign in using passive authentication (see Sign-in, Push Notifications, and General Features in the Mobile client comparison tables for Lync Server 2013 TechNet post at http://technet.microsoft.com/en-us/library/hh691004.aspx). Clients with no support for passive authentication will hang in the attempt to authenticate with Lync 2013.
How Lync passive authentication works is explained in two blog posts: Jens Trier Rasmussen's TechNet blog Microsoft Lync 2013 for Mobile and Passive Authentication at http://bit.ly/1ujMcSK and on the TechNet site Lync Server 2013 Certificate Authentication and Passive Authentication support for Lync 2013 Mobile applications at http://bit.ly/1rzopKJ.
In a recent post on my blog Lync Passive Authentication: Getting Your Hands Dirty at http://bit.ly/WywjJi, I tried the various clients and tested their behavior with passive authentication.