Tips for finding Knowledge Articles

  • - Enter just a few key words related to your question or problem
  • - Add Key words to refine your search as necessary
  • - Do not use punctuation
  • - Search is not case sensitive
  • - Avoid non-descriptive filler words like "how", "the", "what", etc.
  • - If you do not find what you are looking for the first time,reduce the number of key words you enter and try searching again.
  • - Minimum supported Internet Explorer version is IE9
Home  >
article

KB-30546: When using the Centrify Client for Windows™ why must network level authentication (NLA) be disabled?

Privileged Access Service ,  

20 March,20 at 10:25 PM

Question: When using the Centrify Client for Windows™ why must network level authentication (NLA) be disabled

Background
What is Network Level Authentication (NLA)?
“Network Level Authentication (NLA) is a feature of Remote Desktop Services (RDP Server) or Remote Desktop Connection (RDP Client) that requires the connecting user to authenticate themselves before a session is established with the server.
Originally, if a user opened an RDP (remote desktop) session to a server it would load the login screen from the server for the user. This would use up resources on the server and, was a potential area for denial of service attacks as well as remote code execution attacks. Network Level Authentication delegates the user's credentials from the client through a client-side Security Support Provider and prompts the user to authenticate before establishing a session on the server.
Network Level Authentication was introduced in RDP 6.0 and supported initially in Windows Vista. It uses the new Security Support Provider, CredSSP, which is available through SSPI in Windows Vista. With Windows XP Service Pack 3, CredSSP was introduced on that platform and the included RDP 6.1 Client supports NLA; however CredSSP must be enabled in the registry first” – Source: Wikipedia (see below).

What is NLA used for?
To prevent denial of service or remote execution attacks.

What are the limitations of NLA?
Today, NLA only works with one security support provider (CredSSP), this does not allow 3rd party providers of controls like MFA to add additional functionality unless NLA is disabled.  For example, the CIS 18.9.59.3.9.4 Windows server guideline states the following:
“Note: Some third party two-factor authentication solutions (e.g. RSA Authentication Agent) can be negatively affected by this setting, as Network Level Authentication will expect the user's Windows password, and once successfully authenticated, pass the credential along to the Windows session on the RDP host (to complete the login). If a two-factor agent is present and expecting a different credential at the RDP logon screen, this initial connection may result in a failed logon attempt.”
In the case of the Centrify Client for Windows™ working with workgroup-based systems, NLA also impedes the just-in-time provisioning of the directory-based user.

What does this mean to my organization or implementation?
Depending on the risk profile to mitigate in your environment, you may be adopting standards from Microsoft, CIS or even Security Technical Implementation Guides (STIG) that prescribe the use of NLA depending on the context.  Examples:
  • STIG from IIS 7.0 states:  Test C-32735r1_chk: “If Allow connections only from computers running remote desktop with Network Level Authentication is not selected, this is a finding.”
  • CIS Windows Server 18.9.59.3.9.4: “(L1) Ensure 'Require user authentication for remote connections by using Network Level Authentication' is set to 'Enabled'”
This means that a vulnerability scanner or audit tool may find this and identify it as an audit comment.

Recommendations
You’re likely reading this article because you have found incompatible requirements:
  • Implement Network Level Authentication on RDP.
  • Enforce Multi-factor authentication.
In this scenario any MFA vendor will ask you to disable NLA and Centrify is no different.  However, as a security organization we recommend that you implement these compensating controls:
  • Understand the scenario:  If you are only using Privileged Access Service and only require break/glass with a shared account, you don’t need the Centrify Client for Windows™.
  • If you only need the AAPM (or CLI tookit utilities) you can install the client and not enable the “AgentAuth” feature only enable the AAPM feature.
  • If you still require MFA or conditional access (perhaps you are working with a non-domain joined system in a public cloud or DMZ), here are the recommendations:
    • Basic: Don’t expose Windows Servers to the internet unprotected.
    • Intermediate: Establish access control lists at the network level to only allow RDP traffic (TCP 3389 default) from trusted sources.
    • Intermediate: Monitor traffic attempting RDP traffic to systems with NLA disabled from unauthorized sources.
    • Advanced:  Establish other network controls like IPSec.
  • Discuss with your security lead or auditor to set the expectation that compensating controls have been put in place to reconcile the MFA requirement with the controls to limit the risk for denial of service or remote execution.

Answer:
Network Level Authentication affects the Centrify Client for Windows™ ability to perform its MFA authentication just as it affects other 3rd party two-factor MFA applications for the reasons outlined above.



References
Attachments:

Still have questions? Click here to log a technical support case, or collaborate with your peers in Centrify's Online Community.