1. Home
  2. How To...
  3. NCX
  4. Configure Authentication
  1. Home
  2. NetConnect X
  3. Configure Authentication

Configure Authentication

This page is applicable to NetConnect X 1.5 and above

Overview

In order to authenticate to a NCX application, several conditions must be met. Successful authentication can be impacted by any one of:

  • NLA configuration on the destination server/workstation.
  • Specific group policies in place on the destination server/workstation.
  • The Authentication Stage used within NetConnect.
  • The configuration of the NCX application.

An incorrect combination of these configurations will prevent NCX applications from being launched. The purpose of this page is to provide guidance to avoid such scenarios.

NLA

What is NLA?

Network Level Authentication (or NLA) is a technology used in Remote Desktop Services  or Remote Desktop Connection that requires the connecting user to authenticate themselves before a session is established with the server.

Without NLA, users opening an RDP session to a server would be able to load the login screen from the server for the user. This uses up resources on the server and creates potential security risks, such as denial of service attacks.

Why does NLA impact NetConnect ?

If a destination server/workstation is configured for NLA, applications launched by NetConnect require a mechanism to authenticate the connection prior to the user being presented a session. The two methods available in NetConnect to achieve this are:

If you destination server/workstation has NLA enabled, but your NCX application does not have either of the above configured your connection will fail.

How does Single Sign-on work with NLA enabled endpoints?

As established, endpoints with NLA require valid user credentials before allowing a session to be started. Single Sign-on meets this requirement by passing the credentials the user logs into NetConnect with to the endpoint as part of the RDP connection initiation.

What if my destination server has NLA configured, but I don’t want to use SSO?

In the event that single sign-on is not possible or not required (for example, the credentials being used to log in with NetConnect differ from the account you wish to log into an endpoint with), you can configure your application with User Provided Credentials. Applications configured with this feature will present users with a username and password field when an application is launched; these credentials are then passed through to the endpoint and used to establish as connection.

Single Sign-On (SSO)

Single Sign-on uses the credentials a user authenticated to NetConnect with and passes them through to the application endpoint.

Why use SSO?

If your back end application servers/workstations require users to enter credentials for access, you can simplify the log in process by setting up SSO. With SSO configured, once users log in they can access back end application servers using the credentials they signed into NetConnect with, removing the requirement to reenter credentials at the point of connection for a easier and faster connection.

When should I not use SSO?

If you wish to connect to an endpoint using different credentials to those which you logged into NetConnect with, SSO should not be used. An example of this scenario is if you are testing applications with your Master Admin account. Instead, you should configure an application with User Provide Credentials or, if your endpoint is not utilising NLA you can simply disable SSO and login to the endpoint once the session is initiated.

Group Policies

What Group Policies affect NetConnect?

 

<< NCX App Config                                                                                                     Printing >>

Updated on July 16, 2019

Was this article helpful?

Related Articles