Subscribe to PortalGuard's Quarterly Newsletter for News & Updates on the Latest Release! Click to Subscribe
PortalGuard always rejects OTPs generated by a mobile authenticator app (e.g. Google Authenticator, Authy, Microsoft Authenticator). This could occur during initial enrollment of the mobile app or well after it was enrolled.
There are a few reasons why a PortalGuard server will reject Time-Based One Time Passwords (TOTPs) from a mobile app. If the user's mobile app is generating TOTPs for PortalGuard, the simplest thing to check first is to ensure the user's PG User Profile actually contains data related to a mobile authenticator. For an end-user, this can be done by logging into the PG Account Management page (this may only be possible if they have alternate 2FA methods). If PG has mobile app data for the user, the "Mobile Authenticator" section on the Account Management page will appear with a timestamp in the Enabled On field as shown below:
Administrators and IT Help Desk can use the User Detail Lookup available in the Admin Dashboard to see this information as well:
After eliminating the lack of server-side mobile app data as a possibility, you can move on to the more involved troubleshooting which involves possible clock skew on the PG server.
Mobile authenticators like Google Authenticator, Authy and others generate TOTPs based on an internet standard described in RFC 6238. The relevant point is that the current time is part of the algorithm to generate and verify TOTPs. Clock differences as little as 30 seconds between the PG server and mobile phones will cause the algorithm to produce different TOTP values, resulting in failed verifications.
Mobile phones receive the current time from their phone providers so it can be safely assumed that the time on the mobile phone is accurate. The use of virtualization has made clock skew of VMs commonplace (link1, link2, link3). This is countered by having servers continually update their system clock from a Network Time Protocol (NTP) server. For Windows servers joined to an Active Directory domain, they automatically pull their time from domain controllers. However, if domain controllers are not able to set their own time from an externally accurate source (e.g. time.windows.com or us.pool.ntp.org), it is possible for an entire domain of machines to have incorrect time!
First check the PortalGuard server's clock against an authoritative source like https://www.time.gov. If the PG server clock is 30 or more seconds off (slow or fast), then it will need to be corrected using the following steps:
NOTE: The procedure below will cause your PG server to synchronize its time from an external NTP server. If the root problem is an incorrect clock on a domain controller (DC), the following steps can be performed on DCs as well but you should check with your system administrators before making any changes to DCs.
The time on the PortalGuard server should now match what is shown on https://www.time.gov. Try to submit a TOTP from the mobile authenticator again and PortalGuard should be able to verify it.
If the steps in this article do not resolve the problem, please contact us at email@example.com to work with an engineer.
REV. 01/2020 | PortalGuard