In Microsoft Lync 2013 for Mobile release 5.2 we are introducing support for passive authentication via Active Directory Federation Services (AD FS). It enables customers to sign in using other authentication methods than Active Directory including support for users, who don't know their Active Directory password. Kaushal gives a great overview about the feature in his post here. In this post I will describe the sign-in experience for passive authentication user on Microsoft Lync 2013 for Mobile and how to configure your environment to support passive authentication.
Kaushal shows the sign experience on the mobile device using AD FS forms based authentication in his Figure 3. In this section I'll describe when the user has to sign in using passive authentication and when it is not necessary based on different scenarios.
There are 3 elements relevant for the sign in experience:
The Save Password setting is not used when using Passive Authentication. Table 1 lists the passive authentication sign in experience behavior in different scenarios.
Passive Authentication needed
Initial sign in
Sign in after previous sign out
User is signed out by server failure or other event
Administrator revokes the Lync client certificate or it expires, while the user is signed out of the mobile app
Administrator revokes the Lync client certificate or it expires, while the user is signed in on the mobile app. Web ticket is still valid
Administrator revokes the Lync client certificate or it expires, while the user is signed in on the mobile app. Web ticket is expired or not valid
Yes. This is needed to authenticate to get a new valid web ticket
The user is signed in to the mobile app and the web ticket expires. Lync client certificate is valid
No. The web ticket is renewed by using the Lync client certificate without the user having to do passive authentication
WP8: The user is signed in to the mobile app, press Home button and selects the mobile app in the jump list or starts it from the program list. Web ticket is valid
WP8: The user is signed in to the mobile app, press Back button and starts the app again from the program list. Web ticket is valid
WP8: The user is signed in to the mobile app and reboots the device. Mobile app is auto-started
iOS: The user is signed in to the mobile app, press Home button and selects the mobile app in the multi-tasking list or starts it from the program list
iOS: The user is signed in to the mobile app, press Home button and remove the mobile app from the multi-tasking list and starts it from the program list
iOS: The user is signed in to the mobile app and reboots the device. Mobile app is auto-started
WP8 and iOS: The user is signed in to the mobile app and it is in the foreground, the device goes to lock screen and the user unlocks the device
Table 1 Sign in experience
The following versions of the device operating systems are recommended for use with passive authentication
In order to implement passive authentication for Microsoft Lync 2013 for Mobile users it is necessary to disable some of the other authentication methods supported by Lync 2013 Server. Lync 2013 Server offers a list of authentication methods to clients, and others methods take precedence over passive authentication. If you are not disabling these other methods they will be used to authenticate instead of passive authentication.
Table 2 shows the service type, server role and the authentication methods, which needs to be enabled and disabled for passive authentication for mobile users. Please note that these settings are NOT on a per user basis, but rather on a per pool basis. That means all users homed on a specific pool will use the settings.
Disabled Authentication Methods
Enabled Authentication Methods
Kerberos and NTLM
Certificate and Passive Auth
Set-CsWebServiceConfiguration -Identity WebServer:<FQDN> -UseWindowsAuth None -UseCertificateAuth $true -UseWsFedPassiveAuth $true
Set-ProxyConfiguration -Identity Registrar:<FQDN> -UseKerberosForClientToProxyAuth $false -UseNtlmForClientToProxyAuth $false -UseCertificateForClientToProxyAuth $true
Table 2 Authentication Methods
Note1: The pool running the Lync Autodiscover service, i.e. the pool pointed to by lyncdiscover.<SIP domain> and lyncdiscoverinternal.<SIP domain>, authenticates the users based on its own authentication settings and not those of the users home pool. If there is a discrepancy between the authentication methods supported on the Lync Autodiscover pool and the user home pool, the sign in experience might be non-optimal and might not work. In such scenarios it is recommended to use manual discovery configuration for either the passive authentication users or for the default authentication users.
Note2: Table 2 does not list configuration of Registrar for Edge servers. This needed for passive authentication for Microsoft Lync 2013 desktop clients, but Edge is not used by the Microsoft Lync 2013 for Mobile clients.
The Microsoft Lync 2013 for Mobile clients contains the following functionality dependent on Microsoft Exchange:
The Microsoft Lync 2013 for Mobile clients does not support passive authentication against Microsoft Exchange, and therefore the device is not able to use Exchange Web Services (EWS) to connect to Microsoft Exchange and get information about meetings and voice mails. Unified Contact Store (UCS) continues to work, since the connection to Microsoft Exchange is happening via the Lync server.
It is recommend to set the AllowExchangeConnectivity parameter to $false in the CsMobilityPolicy for the passive authentication users. This will make sure that the meetings and voice mail environments are not shown on the device and that errors related to the failed communication to Microsoft Exchange are not shown on the device.
Haven discussed the sign in experience, topology requirements and Microsoft Exchange related features it is now time to explain how to configure passive authentication end-to-end. To illustrate this I will use a fictitious environment and in it I am using AD FS as the passive authentication provider.
For the purpose of explaining the configuration of passive authentication assume the lab configuration shown in Table 3.
Reverse Proxy using ARR
sts2012r2-ext.contoso.dk (same IP address as rp-ext.contoso.dk)
Lync 2013 July 2013 or later CU pool
lync-ext.contoso.dk (Web Services FQDN – same IP address as rp-ext.contoso.dk)
Lync Discover running on Lync 2013 July 2013 or later CU pool
lyncdiscover.contoso.dk (same IP address as rp-ext.contoso.dk)
Table 3 Servers in the environment
All users on lync-int.contoso.dk will be configured to use passive authentication.
For configuration of ARR as a reverse proxy for Lync Server 2013 please see this http://blogs.technet.com/b/nexthop/archive/2013/02/19/using-iis-arr-as-a-reverse-proxy-for-lync-server-2013.aspx. Remember to change port numbers before you click Add for the server.
Table 4 shows the Server Farms and Servers defined in ARR.
Table 4 ARR Server Farms and Servers
Table 5 shows the DNS records in the internal and external DNS servers that has been configured in the environment.
Contains the external IP address of Reverse Proxy
Contains the internal IP address of Reverse Proxy
Contains the internal IP address of lync-int.contoso.dk
Contains the internal IP address of lync2-int.contoso.dk
Table 5 DNS records
The environment supports hair pinning, that is the ability of internal computers to access external available resources via the reverse proxy. As an example internal Lync servers can connect to the AD FS server using its external DNS record.
The environment has been configured with mutually trusted certificates containing the appropriate FQDN's as subject alternate names (SAN). The certificate used on the reverse proxy is from a public trusted root CA.
The AD FS server has been configured for base functionality and forms based authentication has been enabled. We need to configure AD FS to have a trust relationship with Lync Server 2013. This is done by creating a Relaying Party Trust and appropriate Issuance Authorization and Transform rules. Information about the trust partner is contained in the federation metadata document.
The trust relationship means that Lync will trust credentials coming from AD FS. AD FS could have obtained them from a number of authentication providers, but in this environment we use Active Directory as authentication provider via the AD FS forms authentication.
The following section describes how to configure Active Directory Federation Services to support passive authentication with Lync Server 2013.
$IssuanceAuthorizationRules = '@RuleTemplate = "AllowAllAuthzRule" => issue(Type = "http://schemas.microsoft.com/authorization/claims/permit", Value = "true");'
$IssuanceTransformRules = '@RuleTemplate = "PassThroughClaims" @RuleName = "Sid" c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid"]=> issue(claim = c);'
Add-ADFSRelyingPartyTrust -Name Lync-PassiveAuth -MetadataURL https://lync-int.contoso.dk/passiveauth/federationmetadata/2007-06/federationmetadata.xml
Set-ADFSRelyingPartyTrust -TargetName Lync-PassiveAuth -IssuanceAuthorizationRules $IssuanceAuthorizationRules
Set-ADFSRelyingPartyTrust -TargetName Lync-PassiveAuth -IssuanceTransformRules $IssuanceTransformRules
Add-ADFSRelyingPartyTrust -Name Lync-Ext-PassiveAuth -MetadataURL https://lync-ext.contoso.dk/passiveauth/federationmetadata/2007-06/federationmetadata.xml
Set-ADFSRelyingPartyTrust -TargetName Lync-Ext-PassiveAuth -IssuanceAuthorizationRules $IssuanceAuthorizationRules
Set-ADFSRelyingPartyTrust -TargetName Lync-Ext-PassiveAuth -IssuanceTransformRules $IssuanceTransformRules
The trust between AD FS and Lync has been created on the AD FS side. We now need to create it on the Lync side. This is done by using the following command:
New-CsWebServiceConfiguration -Identity webserver:lync-int.contoso.dk -WsFedPassiveMetadataUri https://sts2012r2-ext.contoso.dk/federationmetadata/2007-06/federationmetadata.xml
After the trust now has been established from both sides we need to set the required authentication methods as shown in Table 2. From the Lync Management Shell command-line interface issue the following commands:
Set-CsWebServiceConfiguration -Identity webserver:lync-int.contoso.dk -UseWsFedPassiveAuth $true -UseWindowsAuth none –UseCertificateAuth $true
New-CsProxyConfiguration -Identity registrar:lync-int.contoso.dk -UseKerberosForClientToProxyAuth $false -UseNtlmForClientToProxyAuth $false
Final server configuration element is to create the Mobility Policy disabling Exchange connectivity. From the Lync Management Shell command-line interface issue the following command:
New-CsMobilityPolicy -Identity PassiveAuthUsers -AllowExchangeConnectivity $false
Make sure your users are homed on lync-int.contoso.dk and then grant them the PassiveAuthUsers mobility policy. From the Lync Management Shell command-line interface issue the following command for all the relevant users:
Grant-CsMobilityPolicy -PolicyName PassiveAuthUsers -Identity <user>
The environment is now setup to support passive authentication. However since Lync Autodiscover points to a Lync pool, which has not been configured to support passive authentication, the users on lync-int.contoso.dk needs to manual configure the discovery address on the mobile device. The settings will be:
These addresses needs to be set in the Microsoft Lync 2013 for Mobile clients by clicking on more details on the home screen, setting auto-detect server to Off and entering the relevant addresses. The relevant fields are in Figure 1.
Figure 1 Manual Discovery configuration
In order to troubleshoot the passive authentication between Microsoft Lync 2013 for Mobile, AD FS and Lync Server 2013 the best starting point is looking at the https communication between the client and the servers.
You can use the Fiddler tool for this. The tool does not run on the mobile device, but by running it on a desktop or laptop in the network, you can look at the communication. You can use similar steps as the ones here for Windows Phone 7 to do it. Please understand that the only way to remove that certificate on Windows Phone 8 is to reset the mobile device.
You can also use the Lync 2013 desktop client and Fiddler on a desktop/laptop. You start Fiddler and the Lync client, enter the SIP URI of a passive authentication user and make sure to click 'Delete my sign-in info' before clicking 'Sign in'. Based on your environment you might need to manually configure the internal and external server names (to overcome the Lync Autodiscover issue mentioned earlier).
Some things to look at in the Fiddler trace related to sign in:
On the Lync server side the relevant trace component is WebInfrastructure.
What about Lync Online?
Jens>AFAIK this is for on-premises only.
Jens, great article and along with Kaushal's which gives the inner technical details, its really to cool.
I am going to wait for that date when Exchange will do passive authentication as well, if that's customizable for required tenants in O365 Exchange Online, this cant get any better. I am sure the Exchange and Lync team are already working to do this collaboration. Lync mobility is such a great business productivity tool and without EWS integration, its loses some of its best feature esp.,Join Meeting (I love that)
Thanks for this article, however some points remain unclear: for example Lync phone edition devices. If I disable NTLM and Kerberos, how this does affect Lync Phone Edition clients? Can these also work with passive auth?
Jens>No, the Lync Phone Edition client does not support passive authentication. The same is the case for other clients, so please check the clients you use before enabling this feature.