VPN LDAP Authorization Failure

Unanswered Question
Sep 11th, 2010
/* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-qformat:yes; mso-style-parent:""; mso-padding-alt:0in 5.4pt 0in 5.4pt; mso-para-margin:0in; mso-para-margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:11.0pt; font-family:"Calibri","sans-serif"; mso-ascii-font-family:Calibri; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:"Times New Roman"; mso-fareast-theme-font:minor-fareast; mso-hansi-font-family:Calibri; mso-hansi-theme-font:minor-latin;}

I have set up VPN certificate authentication/authorization on an ASA5520.  I am not having any problems with the authentication part, but, I am having an issue with authorization.  Users get authorization through LDAP to our AD network, however, we have some users which get “%ASA-6-113005: AAA user authorization Rejected : reason = User was not found : server =”.  This is just happening to some and not all users.

I have captured the log files and compared the username being sent via ldap is the same as what is listed for their username on the DC.  The users are able to log onto the domain with no problem they are just unable to get authorization through VPN, they have dial-in permissions and what I have been able to tell the basic groups are the same.  They have attempted to log on through different computer systems, it makes no difference.

What could be the problem where some are able to get authorization and others are not? 

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
matthew.rand Sat, 09/11/2010 - 12:47

Solved the problem.

The configuration of the ldap-base-dn statement under the aaa-server policy was not pointing at a high enough OU level.  Once I changed it users were able to connect.

brettmoore99 Sun, 01/16/2011 - 11:20

I found this discussion when I was having the exact same problem, it turned out that in the ldap server configuration page is was looking for SAMAccountName and the certificate was passing userPrincipalName, I changed the relevant field to now look for the UPN and all is working perfectly now...

Just in case anyone else should have the same problem! The logs where showing that the asa was trying to authenticate [email protected] and the LDAP server was returning user does not exist, this makes sense as SAMAccountName only has the testuser attribute, not the full [email protected]...


This Discussion