Edit

User can't authenticate or must authenticate twice

  • Article

This article addresses several issues that can cause problems that affect user authentication.

Access denied, restricted type of logon

In this situation, a Windows 10 user attempting to connect to Windows 10 or Windows Server 2016 computers is denied access with the following message:

Remote Desktop Connection: The system administrator has restricted the type of logon (network or interactive) that you may use. For assistance, contact your system administrator or technical support.

This issue occurs when Network Level Authentication (NLA) is required for RDP connections, and the user isn't a member of the Remote Desktop Users group. It can also occur if the Remote Desktop Users group hasn't been assigned to the Access this computer from the network user right.

To solve this issue, do one of the following things:

Modify the user's group membership or user rights assignment

If this issue affects a single user, the most straightforward solution to this issue is to add the user to the Remote Desktop Users group.

If the user is already a member of this group (or if multiple group members have the same problem), check the user rights configuration on the remote Windows 10 or Windows Server 2016 computer.

  1. Open Group Policy Object Editor (GPE) and connect to the local policy of the remote computer.

  2. Go to Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment, right-click Access this computer from the network, and then select Properties.

  3. Check the list of users and groups for Remote Desktop Users (or a parent group).

  4. If the list doesn't include either Remote Desktop Users or a parent group like Everyone, you must add it to the list. If you have more than one computer in your deployment, use a group policy object.

    For example, the default membership for Access this computer from the network includes Everyone. If your deployment uses a group policy object to remove Everyone, you may need to restore access by updating the group policy object to add Remote Desktop Users.

Access denied, A remote call to the SAM database has been denied

This behavior is most likely to occur if your domain controllers are running Windows Server 2016 or later, and users attempt to connect by using a customized connection app. In particular, applications that access the user's profile information in Active Directory will be denied access.

This behavior results from a change to Windows. In Windows Server 2012 R2 and earlier versions, when a user signs in to a remote desktop, the Remote Connection Manager (RCM) contacts the domain controller (DC) to query the configurations that are specific to Remote Desktop on the user object in Active Directory Domain Services (AD DS). This information is displayed in the Remote Desktop Services Profile tab of a user's object properties in the Active Directory Users and Computers MMC snap-in.

Starting in Windows Server 2016, RCM no longer queries the user's object in AD DS. If you need RCM to query AD DS because you're using Remote Desktop Services attributes, you must manually enable the query.

Important

This section, method, or task contains steps that tell you how to modify the registry. However, serious problems might occur if you modify the registry incorrectly. Therefore, make sure that you follow these steps carefully. For protection, back up the registry before you modify it so that you can restore it if a problem occurs. For more information about how to back up and restore the registry, see How to back up and restore the registry in Windows.

To enable the legacy RCM behavior on an RD Session Host server, configure the following registry entries, and then restart the Remote Desktop Services service:

  • HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services
  • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\<Winstation name>\
    • Name: fQueryUserConfigFromDC
    • Type: Reg_DWORD
    • Value: 1 (Decimal)

To enable the legacy RCM behavior on a server other than an RD Session Host server, configure these registry entries and the following additional registry entry (and then restart the service):
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server

For more information about this behavior, see Changes to Remote Connection Manager in Windows Server 2016.

User can't sign in using a smart card

This section addresses three common scenarios where a user can't sign in to a remote desktop using a smart card.

Can't sign in with a smart card in a branch office with a read-only domain controller (RODC)

This issue occurs in deployments that include an RDSH server at a branch site that uses a RODC. The RDSH server is hosted in the root domain. Users at the branch site belong to a child domain, and use smart cards for authentication. The RODC is configured to cache user passwords (the RODC belongs to the Allowed RODC Password Replication Group). When users try to sign in to sessions on the RDSH server, they receive messages such as "The attempted logon is invalid. This is either due to a bad username or authentication information."

This issue is caused by how the root DC and the RDOC manage user credential encryption. The root DC uses an encryption key to encrypt the credentials and the RODC gives the client the decryption key. When a user receives the "invalid" error, which means the two keys don't match.

To work around this issue, try one of the following things:

  • Change your DC topology by turning off password caching on the RODC or deploy a writeable DC to the branch site.
  • Move the RDSH server to the same child domain as the users.
  • Allow users to sign in without smart cards.

Be advised that all of these solutions require compromises in either performance or security level.

User can't sign in to a Windows Server 2008 SP2 computer using a smart card

This issue occurs when users sign in to a Windows Server 2008 SP2 computer that has been updated with KB4093227 (2018.4B). When users attempt to sign in using a smart card, they're denied access with messages such as "No valid certificates found. Check that the card is inserted correctly and fits tightly." At the same time, the Windows Server computer records the Application event "An error occurred while retrieving a digital certificate from the inserted smart card. Invalid Signature."

To resolve this issue, update the Windows Server computer with the 2018.06 B re-release of KB 4093227, Description of the security update for the Windows Remote Desktop Protocol (RDP) denial of service vulnerability in Windows Server 2008: April 10, 2018.

Can't stay signed in with a smart card and Remote Desktop Services service hangs

This issue occurs when users sign in to a Windows or Windows Server computer that has been updated with KB 4056446. At first, the user may be able to sign in to the system by using a smart card, but then receives a "SCARD_E_NO_SERVICE" error message. The remote computer may become unresponsive.

To work around this issue, restart the remote computer.

To resolve this issue, update the remote computer with the appropriate fix:

If the remote PC is locked, the user needs to enter a password twice

This issue may occur when a user attempts to connect to a remote desktop running Windows 10 version 1709 in a deployment in which RDP connections don't require NLA. Under these conditions, if the remote desktop has been locked, the user needs to enter their credentials twice when connecting.

To resolve this issue, update the Windows 10 version 1709 computer with KB 4343893, August 30, 2018-KB4343893 (OS Build 16299.637).

User can't sign in and receives "authentication error" and "CredSSP encryption oracle remediation" messages

When users try to sign in using any version of Windows from Windows Vista SP2 and later versions or Windows Server 2008 SP2 and later versions, they're denied access and receive messages like these:

An authentication error has occurred. The function requested is not supported. ... This could be due to CredSSP encryption oracle remediation ...

"CredSSP encryption oracle remediation" refers to a set of security updates released in March, April, and May of 2018. CredSSP is an authentication provider that processes authentication requests for other applications. The March 13, 2018, "3B" and subsequent updates addressed an exploit in which an attacker could relay user credentials to execute code on the target system.

The initial updates added support for a new Group Policy Object, Encryption Oracle Remediation, which has the following possible settings:

  • Vulnerable: Client applications that use CredSSP can fall back to insecure versions, but this behavior exposes the remote desktops to attacks. Services that use CredSSP accept clients that have not been updated.

  • Mitigated: Client applications that use CredSSP can't fall back to insecure versions, but services that use CredSSP accept clients that have not been updated.

  • Force Updated Clients: Client applications that use CredSSP can't fall back to insecure versions, and services that use CredSSP will not accept unpatched clients.

    Note

    This setting should not be deployed until all remote hosts support the newest version.

The May 8, 2018 update changed the default Encryption Oracle Remediation setting from Vulnerable to Mitigated. With this change in place, Remote Desktop clients that have the updates can't connect to servers that don't have them (or updated servers that have not been restarted). For more information about the CredSSP updates, see KB 4093492.

To resolve this issue, update and restart all systems. For a full list of updates and more information about the vulnerabilities, see CVE-2018-0886 | CredSSP Remote Code Execution Vulnerability.

To work around this issue until the updates are complete, check KB 4093492 for allowed types of connections. If there are no feasible alternatives, you may consider one of the following methods:

  • For the affected client computers, set the Encryption Oracle Remediation policy back to Vulnerable.
  • Modify the following policies in the Computer Configuration\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Security group policy folder:

    • Require use of specific security layer for remote (RDP) connections: set to Enabled and select RDP.

    • Require user authentication for remote connections by using Network Level authentication: set to Disabled.

      Important

      Changing these group policies reduces your deployment's security. We recommend you only use them temporarily, if at all.

For more information about working with group policy, see Modifying a blocking GPO.

After you update client computers, some users need to sign in twice

When users sign in to Remote Desktop using a computer running Windows 7 or Windows 10, version 1709, they immediately see a second sign-in prompt. This issue happens if the client computer has the following updates:

To resolve this issue, ensure that the computers that the users want to connect to (as well as RDSH or RDVI servers) are fully updated through June 2018. This includes the following updates:

Users are denied access on a deployment that uses Remote Credential Guard with multiple RD Connection Brokers

This issue occurs in high-availability deployments that use two or more Remote Desktop Connection Brokers, if Windows Defender Remote Credential Guard is in use. Users can't sign in to remote desktops.

This issue occurs because Remote Credential Guard uses Kerberos for authentication, and restricts NTLM. However, in a high-availability configuration with load balancing, the RD Connection Brokers can't support Kerberos operations.

If you need to use a high-availability configuration with load-balanced RD Connection Brokers, you can work around this issue by disabling Remote Credential Guard. For more information about how to manage Windows Defender Remote Credential Guard, see Protect Remote Desktop credentials with Windows Defender Remote Credential Guard.