Can't access certain shares at all

  • Is AuthLite MSI not installed on the workstation?  Install it and restart, try again. There is a Windows race condition which can cause your Kerberos ticket not to properly reflect the fact that you logged on with 2FA.
  • Are you accessing the share by IP address?  Kerberos cannot connect this way, so you are forcing the connection down to NTLM, which can't work right with OTPs.  Please use the FQDN (fully qualified domain name) of the server and see if that works.
  • Are you accessing the share by short NETBIOS server name?  Try addressing the share with the FQDN (fully qualified domain name) of the server instead of the short server name, and see if that works.  In some situations the short name doesn't route correctly through the Kerberos protocol.
  • Are you accessing the share by a non-canonical name? By default, Kerberos will only work if accessing the share by the computer's actual hostname/FQDN.  If you are accessing the share by a DNS alias or a DFS/cluster name, then you must use the "setspn -A" command to add a "cifs/..." service principal name matching that hostname.
  • Check Kerberos tickets: After getting the error, have the affected user open cmd.exe and type "klist".  See if any of the resulting lines begin "cifs/" followed by the name of the file server.  If not, then the connection isn't using Kerberos, which is probably causing the problem. 
  • If you have a "cifs/" line matching the file server:  In Control Panel -> Credential Manager -> Windows, see if there are any saved credentials matching the file server.  If so, remove them.  Saved credentials for the user will override the session logon, and since they don't have your current 2FA session, the file server will reject your logon as 1-factor.
  • Are you an admin with NO mapped drives in Explorer? In certain UAC configurations (admin users) the session's initial Kerberos ticket loads into the elevated UAC session instead of the normal session which Explorer uses.  When you first try to access a UNC path, the normal session will try to build its own Kerberos ticket, but it will be "too late" to use the OTP from your session logon time.  If you map (any) network drive in your Explorer and log on again, this may fix the issue.  It will force the non-UAC session to get a kerberos ticket right away when you log on, instead of waiting until you try to connect to your share.

Losing access at specific times

If you get access denied errors that overwhelmingly occur "in the afternoon", "after lunch", "at the end of the day" etc. this indicates your Kerberos ticket is expiring and not being renewed with a 2FA ticket.  This can happen if the session stays "open" all day instead of being locked and unlocked at least once.  Default Kerberos ticket lifetime is 8 hours, hence about 8 hours after logon you might start seeing these problems.

Make sure AuthLite is installed on the client machine, and arrange session locking such that you lock/unlock the session sooner than the Kerberos ticket expires.  If you wait until after you receive the error, it may be too late! Explorer hangs onto open connections and session tokens and may "remember" the bad 1-factor token until you log out in that case.

Workarounds when AuthLite client cannot be installed

Kerberos ticket refresh

  • Open a (normal, not elevated) command prompt or use the Windows run dialog, and run the command "klist purge"
  • Lock and Unlock the session, entering a fresh 2FA credential.  (You may need to perform a Switch User to expose the "Username" field, so you can enter the OTP there)
  • After unlock, try connecting to the share using its FQDN.
  • Note the above works best before you attempt to connect the share.  (If you wait until after receiving an access denied error, you may find Explorer keeps the connection open.  So the following may not work without first "net use /d " the shares from that server, and restarting explorer.exe)

Temporary drive mapping

  • In Explorer map a drive and select "connect using different credentials" but not "reconnect at sign-in"
  • Put the OTP in the username field. I.e. enter a YubiKey value, or username dash OATH token code.  Then enter password as usual.
  • Note if Explorer already has a share open to that machine, this will fail. Find the share with "net use" and disconnect it with "net use /d"

More help

If none of the above items match or address your issue, please open a Support request and we will be happy to troubleshoot with you.