Bug: RADIUS Server Realm's 2FA Does Not Read an OATH Seed Without a Mobile Number Present

Follow
    Applies to:
  • SecureAuth Identity Platform
Deployment model:
  • Cloud
  • Hybrid
  • On Premises
  • Version Affected: RADIUS Server early 2.x.x releases
    Bug Number: Not provided in source
    Bug Status: Closed - Fixed
    Fixed in Version(s): Later RADIUS Server 2.x.x releases

     

    Overview

    Some devices can't be used for two-factor authentication against a RADIUS Server realm. This happens whether the OATH Seed was registered through the OATH enrollment realm, the Mobile QR enrollment realm, or any other realm that writes an OATH Seed. Devices that can enroll but then can't authenticate include Google Authenticator, the SecureAuth Passcode App, and the SecureAuth OTP Chrome Extension. The SecureAuth Authenticate App can both enroll and authenticate without issue.

    If a user first authenticates successfully with the working SecureAuth Authenticate App, the other devices then start working too — but this isn't a viable workaround, since it depends on the user already owning and using that specific app.

     

    Cause

    In early RADIUS Server 2.x.x releases, a bug meant the RADIUS Server realm's two-factor authentication would not properly read an enrolled OATH Seed unless a mobile number was also written to the user's profile. The mobile number itself didn't need to be valid — any value in that field was enough to let the OATH Seed be read. Even though OATH enrollment completed successfully, affected devices couldn't have their OATH Seed read after enrollment without a mobile number value present.

     

    Resolution / Workaround

    Upgrade RADIUS Server to the latest version. This is fixed in later RADIUS Server 2.x.x releases.

     

    SecureAuth Knowledge Base Articles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.

    Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.

    0 out of 0 found this helpful

    Comments

    0 comments

    Please sign in to leave a comment.