Problem: Receiving Access Denied error when trying to access a file share or open a drive mapped in Explorer
Can't access certain shares at all
- Is AuthLite missing from 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.
- 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.
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.