Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Anchor
top
top
Unable to Launch Yubikey Manager Over Remote Desktop to a Windows Machine

Symptoms

When a user connects via RDP to a Windows machine and then subsequently attempts to launch the Yubikey manager, they may see the following error:

Warning

LoadLibrary failed with error 126: The specified module could not be found.


Cause

This issue is caused (most likely) due to an issue with the AMD video drivers that are present on the Windows machine and the Yubikey software.

Side note: this same issue is known to affect other software, such as AutoCAD. See https://knowledge.autodesk.com/support/autocad/troubleshooting/caas/sfdcarticles/sfdcarticles/LoadLibrary-failed-with-error-126-when-starting-an-Autodesk-product.html

Resolution

  1. Launch Device Manager (devmgmt.msc)
  2. Expand "Display adapters"
  3. Right click the dedicated video card that is present on the machine and click Disable
  4. Re-launch the Yubikey Manager app
  5. Once work is done, the video card can be re-enabled.

Note: This trick of disabling the video adapter seems to allow the Yubikey Manager app to function throughout the entirety of the remote session. If you disconnect and reconnect, it may be necessary to disable the video card again.

(Back to top)

Authentication Error When Trying to Connect to a Windows Machine Via RDP with Yubikey

Symptoms

When a user connects to a Windows machine (server or client) via a non-domain joined machine (or a personal workstation) using their Yubikey, the connection will hang at "securing connection" and then result in an error stating:

Warning

An authentication error has occurred. The Kerberos protocol encountered an error while validating the KDC certificate during smartcard logon. There is more information in the system event log.


Remote computer: <someWorkstation>.ad.rit.edu




Additionally, looking at the System event log on the local workstation will result in an error:

Warning

Source: Security-Kerberos Text: The client has failed to validate the domain controller certificate for maindc<####>.main.ad.rit.edu. The following error was returned from the certificate validation process: A certificate chain could not be built to a trusted root authority.



Cause

This error is caused due to the local workstation lacking the RIT Root CA certificate on the workstation.


Resolution

  1. Navigate to https://certs.rit.edu on the local workstation
  2. Download the "RIT ROOT CA" certificate
  3. Install the certificate – it can either be placed in the Local Machine or Current User stores, but must explicitly be placed in the corresponding "Trusted Root Certification Authorities" store. Selecting the automatic option may cause the cert to be incorrectly placed in the Personal store.
  4. Attempt to connect to the remote workstation


Tip

Note: The combination of installing the RIT Root CA certificate, plugging in the Yubikey, and then connecting to the remote RIT workstation should automatically cause the "RIT AD Signing CA" certificate to be installed in the "Intermediate Certification Authorities" store. If this does not occur, you can also obtain the RIT AD Signing CA certificate by downloading the "RIT Certificate Authorities - p7b Bundle" file from certs.rit.edu and manually installing it.


(22287889Back to top)

Certificates Missing When Attempting to Access Yubikey

Symptoms

When a user attempts to interact with an application that requests their certificates (e.g. when connecting via RDP), one of the certificates that is (or should be) present for selection does not appear. This may occur randomly after a period of working as expected. For example, a yubikey that has certificates for ritchie and ritchie-admin may only present ritchie-admin, or vice versa.

Additionally:

  • (tick) Viewing the Yubikey manager → Applications → PIV → Configure Certificates shows that all certificates are present
  • (tick) Running ykman piv info from a command/powershell prompt properly shows all expected certificates
  • (error) Running certutil -scinfo results in one or more certificates not displaying information (it will present a message indicating that no certificates were pulled from the slot)
  • (error) When viewing the Certificate Manager (certmgr.msc) → Personal store, one or more certificates are missing from the list (e.g. in the example above, ritchie might be missing)
  • (warning)The above behavior persists when connected to a remote machine (in which case, you would have connected via a username/password)

Cause

Thus far, the current belief of the cause of the issue is that during certificate propagation (which occurs automatically when the yubikey is inserted), the actual certificate files stored on disk are somehow "locked". The cause of this lock is yet unknown, however, may be related to errors that can be observed in the System Event Log:

Warning

Smart Card Reader 'Yubico YubiKey OTP+FIDO+CCID 0' rejected IOCTL GET_ATTRIBUTE: The device does not recognize the command. If this error persists, your smart card or reader may not be functioning correctly.


Resolution

This error can be corrected by removing / deleting the certificate file on disk and then re-inserting the Yubikey.


Info

The steps below require the user to know the thumbprint of the affected/missing certificate in question.

This can be obtained via several methods, including the X509 certificate that was initially issued by the CA when the yubikey was set up, or by running the command ykman piv certificates export <slot> <filename>.crt to generate a new X509 certificate for the affected slot and opening it.


  1. Unplug your Yubikey
  2. Navigate to C:\Users\<username>\appdata\roaming\Microsoft\SystemCertificates\My\Certificates
  3. Move the file corresponding with the thumbprint of the missing/affected certificate (this ultimately can be deleted, but for safety, it's best to start with moving it to another location)
  4. Plug the Yubikey back in
  5. This should automatically cause a new file to be written to disk
  6. Open the Certificate Manager (certmgr.msc) and navigate to the Personal store
  7. Confirm that the missing cert now appears
  8. Attempt to perform the initial transaction (e.g. connecting to RDP)
  9. Delete the file you moved in step 3 (if you didn't outright delete it)

If the steps above do not resolve this issue (particularly when the yubikey is being used from a personal machine), try logging into the machine with another user account (if one does not exist, create a new non-administrator user), plugging in the yubikey, and then attempting to use it (e.g. access a machine via RDP). If all certificates appear for selection with the alternate user account, log out of it, and then back into your normal account and re-attempt to use the yubikey.

Pageant Errors on Startup (with auto-load shortcut)

Symptoms

When computer boots and attempts to start up Pageant, you might get the following 2 errors:

Cause

Version of Putty has been installed that doesn't recognize certificates nor the extra option of "certauthprompting".

Resolution 1

Re-install Putty-CAC from Software Center

Resolution 2 (applies to Putty-CAC version 0.82.0.1 and above)

  1. Open run command
  2. Enter "shell:startup"
  3. Look at properties of shortcut "pageant-startup-cert-autoload"
  4. In the target, remove "User\MY\" after the CAPI:
    1. Example: 
      1. CAPI:User\MY\ad3930cf31ac1c9fa135d4e170cdb722d4da02d5 changes to
      2. CAPI:ad3930cf31ac1c9fa135d4e170cdb722d4da02d5

(22287889Back to top)


NLA Errors When Remoting into RIT Machines from Personal Workstations

Symptoms

When attempting to remote into an RIT machine (client or server) using your Yubikey from a personal/un-managed Windows machine, Remote Desktop will hang at "securing connection" and then display the following error:


Warning

The remote computer that you are trying to connect to requires Network Level Authentication (NLA), but your Windows domain controller cannot be contacted to perform NLA. You can try connecting to the remote computer with your username and password instead.


In this scenario, the remote desktop connection will not be configured to use the RD Gateway.


Cause

The personal/non-managed machine cannot contact the KDC to perform NLA, and needs to be configured to contact the KDC proxy server, which is accessible off campus.


Resolution

  1. Create a text file with the following contents and save it as kdcproxy.reg:

    Code Block
    Windows Registry Editor Version 5.00
    
    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos]
    "KdcProxyServer_Enabled"=dword:00000001
    
    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\KdcProxy\ProxyServers]
    "ad.rit.edu"="<https kdcproxy.ad.rit.edu />"
    
    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\KdcProxy\ProxyServers]
    "main.ad.rit.edu"="<https kdcproxy.ad.rit.edu />"
    
    
    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters]
    "NoRevocationCheck"=dword:00000000


  2. Double click the file
  3. When prompted, click Yes to merge the registry changes in
  4. Reboot the machine – note that this is required in order for the KDC proxy settings to take effect
  5. Attempt the remote desktop connection again


Note

Note: This issue will not occur if the remote desktop connection is configured to use the RD Gateway. While the gateway is necessary in certain circumstances (e.g. when remoting into a client machine), this is a sub-optimal configuration when connecting to a tool server, as the point of a tool server is intended to be accessible even if the gateway farm is offline.

(22287889Back to top)


Panel
borderColor#000
bgColor#f0f0f0

On This Page:

Table of Contents