This article contains information about the sign-on and authentication process for the Citrix HDX RealTime Optimization Pack 1.8 for Microsoft Lync / Skype for Business (in Lync UI mode). It describes the mechanism that is used to successfully authenticate with Microsoft Lync and the requirements that this places on the customer's configuration of Microsoft Lync.

Note: This article does not apply to HDX RealTime Optimization Pack 2.x since in this second-generation architecture, authentication to the Skype for Business Server is handled exclusively by the Skype for Business client using the context of the user’s authentication to the Windows operating system on XenApp/XenDesktop.

Background

The important thing to note is that the HDX RealTime Media Engine (RTME) running on the end-user terminal device must successfully authenticate with the Lync Front End or Edge server in order to enable optimized calling.  The job of the RealTime Connector for Lync (RTCL) running in the Windows environment on XenApp/XenDesktop is to collect the user credentials and send them (encrypted) to the RTME.
RTME supports two authentication methods that might result in different user experience with authentication:

• Authentication using a client certificate is the preferred method that mostly results in SSO experience without additional credential prompts to the user. This type of authentication is also the only method supported for Office 365 Lync accounts.
• Authentication using NTLM or Kerberos are the fallback methods that are used by RTME when client certificate authentication is not enabled by Lync administrators.
• Kerberos authentication is supported for Windows endpoints (only).

To enable client certificate authentication, RTCL must interact with the Web Services component of the Microsoft Lync Front end server to create a security certificate for the RTME to use in authentication with Lync. To create this certificate, RTCL must itself authenticate with the Microsoft Lync Web Services using either:

• NTLM
• Kerberos, or
• Explicitly provided credentials

In some cases this requires that the RTCL have access to the user’s username and password.

Sign-On Process with Client Certificate Authentication

The following Sign-in Process Architecture outlines the process architecture and communication flows during the authentication and sign-in process between Lync, the HDX RealTime Connector for Lync, and the HDX RealTime Media Engine, when client certificate authentication was enabled by Lync administrators.

The preceding diagram illustrates the following process:

1. Lync captures the user credentials, authenticates with Web Services and retrieves a client certificate.

2. (Optional) Lync writes the credentials and the client certificate to the credential store and the system registry using secure encryption for storing the password.

3. Lync registers with the SIP Proxy.

4. Citrix HDX RealTime Connector (RTCL) attempts to read the stored Lync credentials from its own location in the registry and from the Windows system.
   Note: Even if no stored credentials are available, RTCL will attempt the next step with built-in Windows authentication. If that fails, RTCL will prompt the user for credentials.

5. If a client certificate for RTME authentication is found in the registry, RTCL skips to step 7. Otherwise, RTCL authenticates the Microsoft Web Services Server to create a new client certificate for use by RTME in authenticating with Lync.

6. RTCL writes this new client certificate to the System Registry.

7. RTCL then passes the client certificate to the RealTime Media Engine (RTME) running on the user device.

8. RTME authenticates with Lync using the client certificate it received from RTCL.

Sign-On Process with NTLM or Kerberos

When client certificate authentication is not enabled by Lync administrators, the result is a slightly different authentication flow that does not involve the Web Services component of Microsoft Lync Front End server.

1. Lync captures the user credentials and authenticates with the Lync Front End Server directly.

2. (Optional) Lync writes the credentials to the system registry.

3. Citrix HDX RealTime Connector (RTCL) attempts to read the stored Lync credentials from its own location in the registry and from the Windows system.
   Note: If no stored credentials are available, RTCL prompts the user for credentials.

4. RTCL writes the credentials to the System Registry using secure encryption for storing the password.

5. RTCL then passes the credentials to the RealTime Media Engine (RTME) running on the user device.

6. RTME authenticates with Lync using NTLM or Kerberos with user username/password credentials it received from RTCL.

Requirements for Successful Sign-On

Achieving optimized calling and successful Sign-On requires the system administrator to configure Lync authentication properly. While the RTME can authenticate with Lync using either client certificate authentication, also known as TLS-DSK,NTLM or Kerberos the preferred method is TLS-DSK. TLS-DSK is the default and recommended login mechanism for Lync.

If your organization does not use TLS-DSK then the RTME must authenticate using NTLM/Kerberos each time it starts up. NTLM/Kerberos authentication requires the RTME to provide the username and password to the Lync server when authenticating. This means that the RTCL must have access to the user’s login information in the Windows environment to pass it to the RTME. If your organization prohibits the storing of encrypted passwords by Lync and RTCL, then the RTCL must prompt the user for their credentials each time the user logs in. This can result in the user being prompted twice for their Lync credentials (once by Lync and once by the RTCL).

When TLS-DSK (client certificate authentication) is enabled, the result also depends on whether the user logs into the virtual desktop where they run Lync with the same Windows domain account as they use to access their Lync account. In most on-premises Lync deployments this will be the case, and in these environments Optimization Pack must be able to provide SSO user experience without the need for stored passwords.
Note that the client computer running Receiver and RTME does not have to be joined to the domain to achieve SSO.
The following table shows the possible combinations of security settings and the resulting behavior of the Lync system and the Optimization Pack:

Combination	Result	Domain account	Save Password	TLS/DSK
1	No prompt	User logs into VDA with correct domain account	Enabled or disabled	TLS/DSK enabled
2	No prompt	Optional	Lync Save Password enabled	Enabled or disabled
3	Prompt on initial login only	Optional	Lync Save Password disabled	TLS/DSK enabled
4	Prompt on each login	Optional	Lync Save Password disabled	TLS/DSK disabled

Option 1 – SSO with client certificate authentication

In option 1 both Lync and RTCL authenticate to the Web Services component of Lync using native Windows authentication and retrieve a client certificate for authentication (two separate client certificates are retrieved). In order for Windows native authentication to work, the user must be logged in to the Virtual Desktop running Lync and RTCL using the same domain account as the one associated with their Lync account.
The certificates are stored in Windows certificate store (Lync) and in the registry (RTCL) and used to authenticate client will collect the user’s credentials on first invocation of Lync. Each certificate is valid by default for 180 days, and when it expires, a new certificate is retrieved by Lync and RTCL automatically.

Option 2 – No prompt

In option 2 the Lync client will collect the user’s credentials on first invocation of Lync.  It will store these credentials securely in the credential store. If certificate authentication is enabled, the RTCL will use these stored credentials to create a TLS-DSK security certificate and will pass that certificate along to RTME for authentication. Otherwise, RTCL will directly pass the stored username and password to RTME for authentication using NTLM or Kerberos.  In either case the RTCL will not need to prompt the user for the password. Following is a screen shot of the Lync login prompt for initial login:

Lync 2010 client:


Lync 2013 client:

Option 3 – Prompt on Initial Login only

In option 3 the Lync client is prohibited from saving the user’s credentials in the credential store. So the RTCL is forced to prompt the user upon initial login for their credentials. From the user perspective this seems like Lync is prompting twice for the username and password. Here is a screenshot showing the Optimization pack prompting for the credentials a second time:

Lync 2010 client:


Lync 2013 client:

Once RTCL has captured the user’s credentials it will interact with the Lync Web Services server to create a TLS-DSK security certificate for use in this and future logins. RTC will persist this certificate in the Windows registry. RTCL will pass this certificate along with the username and password to RTME and RTME will use the TLS-DSK certificate to authenticate with Lync.

On subsequent invocations of Microsoft Lync the RTCL process does not have to prompt for the user credentials. RTCL can retrieve the TLS-DSK certificate from the registry and pass this to RTME for authentication. 

Option 4 – Prompt on each Login

In option 4 the Lync client is prohibited from saving the user’s credentials in the credential store. So the RTC is forced to prompt the user upon initial login for their credentials (preceding screen). From the user's perspective this seems like Lync is prompting twice for the username and password.

Furthermore, since TLS-DSK authentication is disabled in the Lync Server, the RTME is required to have the username/password for the user in order to use NTLM or Kerberos authentication. Thus the RTCL must collect this information from the user each time they login.

Authentication Preference Table

Enabled auth	Endpoint location	Endpoint OS	New behavior
NTLM + Kerberos	Internal	Windows	Using Kerberos authentication
NTLM + Kerberos + Certificates	Internal	Windows	Using certificate or Kerberos (depending on various criteria)
NTLM + Kerberos	External	Windows	Attempting Kerberos authentication, efficiently failing over to NTLM
NTLM + Kerberos + Certificates	External	Windows	Using certificate or failing over from Kerberos to NTLM (depending on various criteria)

Office365 Support

As of version 1.6, the Citrix HDX RealTime Optimization Pack for Microsoft Lync supports Office 365 authentication using Cloud Identities or Active Directory Federation Services. Since Office 365 is a Web Service it supports only TLS-DSK for authentication.

Authentication Flow Diagram:

 

Registry Keys Used

Caution! Refer to the Disclaimer at the end of this article before using Registry Editor.
Microsoft Lync uses the following registry key to control whether or not the password is stored. A value of 1 means that the password will be saved between Lync sessions:
HKCU\Software\Microsoft\Communicator\SavePassword

The RTCL process reads the user's Server Username from the following locations:

HKEY_CURRENT_USER\Software\Microsoft\Shared\UcClient\ServerUsername
HKEY_CURRENT_USER\Software\Policies\Microsoft\Communicator\ServerUsername
HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Communicator\ServerUsername
 
The RTCL process then reads the user's encrypted Password from the following location:
HKEY_CURRENT_USER\Software\Microsoft\Communicator\AccountPassword

If the password is not available in the registry then the RTCL attempts to use the Windows Credential Manager to retrieve the Lync Password.
If the RTCL is configured to save passwords, the RTCL then writes the user’s credentials (Username, encrypted password) into the following location which must be persisted between Lync and RTCL sessions for Single-Sign On to work:
HKEY_CURRENT_USER\Software\Citrix\HDXRTConnectorLC\MediaEngine\SIPRegistration\RegistrarPassword

Please note above registry keys reference a Lync 2010 client. Lync 2013 keys can be found at:
HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\Lync

Troubleshooting Authentication

To verify that the RTME has successfully authenticated with Lync, consult the settings pages to verify that the Status shows Registered as follows: 

1. Choose Tools > Audio Video Settings.

2. Confirm connection attributes (status, connection type, and mode). The following screen shot shows the correct connection values:
   

For further troubleshooting tips, see Citrix Product Documentation - Troubleshooting HDX RealTime Optimization Pack.

More Information

• RTCL uses the Microsoft Windows Data Protection API that reversibly encrypts the password in such a way that it cannot be decrypted on a different computer. Refer to the following link for a detailed technical description of this Data Protection API: Windows Data Protection

• Microsoft Lync 2010 Client Group Policy Documentation 

• User and Client Authentication for Lync Server 2010

Caution! Using Registry Editor incorrectly can cause serious problems that might require you to reinstall your operating system. Citrix cannot guarantee that problems resulting from the incorrect use of Registry Editor can be solved. Use Registry Editor at your own risk. Be sure to back up the registry before you edit it.

This article contains information about the sign-on and authentication process for the Citrix HDX RealTime Optimization Pack 1.8 for Microsoft Lync / Skype for Business (in Lync UI mode).