Jens Trier Rasmussen

The odd bit of information about Lync Server 2013, Lync 2010, Exchange 2013, SharePoint Server 2013, Exchange 2010 SP1, OCS 2007 R2, Exchange 2010 and OC 2007 R2

Microsoft Lync 2013 for Mobile and Passive Authentication

Microsoft Lync 2013 for Mobile and Passive Authentication

  • Comments 3
  • Likes

Introduction

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.

How is the sign in experience?

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:

  • Authentication token issued by AD FS after the user has authenticated
  • Web ticket. The web ticket is used by the mobile app to authenticate the communication with the UCWA component on Lync Server 2013 and is issued by the Lync server after the app has presented the AD FS authentication token. The web ticket has 8 hours expiration time
  • Lync client certificate. The Lync client certificate is issued by the Lync Certificate Provisioning Service to the mobile app after it has obtained a web ticket. As an administrator you can see and revoke the certificates by using Get-CsClientCertificate and Revoke-CsClientCertificate. The default Lync client certificate has a 6 month expiration time. It can be changed by setting the MaxValidityPeriodHours value on the WebService configuration.

 

The Save Password setting is not used when using Passive Authentication. Table 1 lists the passive authentication sign in experience behavior in different scenarios.

Scenario

Passive Authentication needed

Initial sign in

Yes

Sign in after previous sign out

Yes

User is signed out by server failure or other event

Yes

Administrator revokes the Lync client certificate or it expires, while the user is signed out of the mobile app

Yes

Administrator revokes the Lync client certificate or it expires, while the user is signed in on the mobile app. Web ticket is still valid

No

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

No

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

No

WP8: The user is signed in to the mobile app and reboots the device. Mobile app is auto-started

No

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

No

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

No

iOS: The user is signed in to the mobile app and reboots the device. Mobile app is auto-started

No

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

No

Table 1 Sign in experience

Device Operating System versions

The following versions of the device operating systems are recommended for use with passive authentication

  • Windows Phone 8: It is recommended to use version 8.0.10211.204 or later
  • iOS: 6.1 or later

 

Topology Requirements

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.

Service Type

Server Role

Disabled Authentication Methods

Enabled Authentication Methods

Configuration cmdlet

WebServer

Lync Autodiscover

Kerberos and NTLM

Certificate and Passive Auth

Set-CsWebServiceConfiguration -Identity WebServer:<FQDN> -UseWindowsAuth None -UseCertificateAuth $true -UseWsFedPassiveAuth $true

WebServer

Front End

Kerberos and NTLM

Certificate and Passive Auth

Set-CsWebServiceConfiguration -Identity WebServer:<FQDN> -UseWindowsAuth None -UseCertificateAuth $true -UseWsFedPassiveAuth $true

Registrar

Front End

Kerberos and NTLM

Certificate

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.

Functionality dependent on Microsoft Exchange

The Microsoft Lync 2013 for Mobile clients contains the following functionality dependent on Microsoft Exchange:

  • Unified Contact Store (UCS)
  • Meetings environment
  • Voice Mail environment

 

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.

End-to-End configuration

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.

Role

Internal FQDN

External FQDN

Reverse Proxy using ARR

rp-int.contoso.dk

rp-ext.contoso.dk

AD FS

sts2012r2-int.contoso.dk

sts2012r2-ext.contoso.dk (same IP address as rp-ext.contoso.dk)

Lync 2013 July 2013 or later CU pool

lync-int.contoso.dk

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

lync2-int.contoso.dk

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.

Reverse Proxy Configuration (ARR)

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.

Server Farm

Servers

sts2012r2-ext.contoso.dk

sts2012r2-int.contoso.dk

lync-ext.contoso.dk

lync-int.contoso.dk

lyncdiscover.contoso.dk

lync2-int.contoso.dk

Table 4 ARR Server Farms and Servers

DNS

Table 5 shows the DNS records in the internal and external DNS servers that has been configured in the environment.

FQDN

Internal DNS

External DNS

sts2012r2-ext.contoso.dk

Contains the external IP address of Reverse Proxy

Contains the external IP address of Reverse Proxy

rp-int.contoso.dk

Contains the internal IP address of Reverse Proxy

N/A

rp-ext.contoso.dk

Contains the external IP address of Reverse Proxy

Contains the external IP address of Reverse Proxy

lync-ext.contoso.dk

Contains the external IP address of Reverse Proxy

Contains the external IP address of Reverse Proxy

lync-int.contoso.dk

Contains the internal IP address of lync-int.contoso.dk

N/A

lyncdiscover.contoso.dk

N/A

Contains the external IP address of Reverse Proxy

lyncdiscoverinternal.contoso.dk

Contains the internal IP address of lync2-int.contoso.dk

N/A

Table 5 DNS records

Hair pinning

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.

Certificates

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.

AD FS Configuration

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.

  1. Log in to sts2012r2-int.contoso.dk using a Domain Admin account
  2. Launch Windows PowerShell
  3. Make sure sts2012r2-ext.contoso.dk is set as the Federation Service Name
    1. Get-AdfsProperties | fl HostName
  4. Establish a trust partnership with the Lync Server 2013 Pool that will be enabled for passive authentication. For pools add the trust for both internal and external Web Services FQDN. In this environment we need to add it for lync-int.contoso.dk and lync-ext.contoso.dk. Configure it by running the following command: 

 

$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

Lync 2013 Server configuration

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:

  1. Log in to lync-int.contoso.dk using a Lync administrator account
  2. Launch the Lync Server 2013 Management Shell
  3. From the Lync Management Shell command-line interface, create a new Web Service configuration for lync-int.contoso.dk by running 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

User configuration

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>

Manual Discovery configuration

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

Troubleshooting

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:

  • Is the client being re-directed to the AD FS in the sign in sequence via a 302 re-direct to the AD FS url? If this is not happening check the WsFedPassiveMetadataUri and that UseWsFedPassiveAuth has been set to true. The Lync server will report any errors in communicating with AD FS in the event log
  • Does the returned MEX document contain the expected WsFedPassive_policy? If it lists the wrong combination check the enabled authentication methods on the WebServiceConfiguration for the pool
  • Does AD FS return a reference back to the Lync pool on the virtual directory PassiveAuth/PassiveAuth.aspx after the user has signed into AD FS? If not, check the relaying party trust on AD FS
  • Any 5xx errors coming back
  • Are cookies disabled on the mobile device?

On the Lync server side the relevant trace component is WebInfrastructure.

Comments
  • 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.

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment