Reset Search
 

 

Article

KB23391 - [SBR] EAP-TLS Helper with secondary authorization fails with the 'EAP-TLS protocol succeeded, but no authentication method claimed XXXXX user' error message

« Go Back

Information

 
Last Modified Date8/1/2015 8:44 PM
Synopsis
This article describes the issue of authentication failure, when the TLS Helper method authentication method is used, along with secondary authorization.
Problem or Goal
Even though users have a valid certificate on their computers, they are unable to authenticate, by using the EAP-TLS automatic helper method. The following errors are noticed in the SBR debug logs:
 
"03/28/2012 18:43:25 EAP-TLS authentication succeeded
03/28/2012 18:43:25 EAP-TLS performing secondary authorization for user Administrator
03/28/2012 18:43:25 Authenticating user ADMINISTRATOR with authentication method Native User
03/28/2012 18:43:25 EAP-TLS protocol succeeded, but no authentication method claimed XXXXX user
03/28/2012 18:43:25 User Administrator ultimately failed challenge sequence"
Cause
  • The username attribute, which is sent by the TLS helper method, does not match the username in the SBR database; which is used for secondary authorization.
 
  • The fixed password configured for secondary authorization and the user password on SBR database are not the same.
 
  • The external database (LDAP, SQL) is not correctly configured to call the profile, which is created in the SBR admin GUI.
Solution
In the TLS Helper authentication method, under the Secondary authorization tab, the Convert Username to option has 2 radio buttons:
 
  • Subject CN
 
  • Principal Name





If Subject CN is selected:

The user certificate's (installed on the end user's computer for TLS authentication) Subject attribute CN value should match the username configured on the SBR database (Native user, LDAP, SQL), which is configured for Authorization.

For Example, if the Subject attribute on the cert contains the CN=labadmin value and the Native user is the database, which is used for authorization, then the labadmin user should exist in the Native user database.




If Principal Name is selected:

The user certificate's (installed on the end user's computer for TLS authentication) Subject Alternative Name attribute's Principal Name value should match the username configured on the SBR database, which is configured for authorization.

For example, if the Subject Alternative Name attribute on the cert contains the Principal Name=labadmin@slash.com value and the Native user is the database, which is used for authorization, then the labadmin@slash.com user should exist in the Native user database.




Note:
 
  • If the fixed password is configured on TLS EAP Helper secondary authorization, then the password set for the Native user should be the same as the 'Fixed password'.
 
  • If fixed password is not configured, then the password check is ignored.
Related Links
Attachment 1 
Created ByData Deployment

Feedback

 

Was this article helpful?


   

Feedback

Please tell us how we can make this article more useful.

Characters Remaining: 255