SSL VPN - ASA - Active Directory LDAP

Answered Question
Jul 9th, 2009

Hi there,

Scenario: ASA 8.0(3) is running SSL VPN for remote users. LDAP also authenticates access and login to the ASA.

For some reason (We had a power outage but the problem may be caused by other reasons as well), I can not login to the ASA, as my login ID is not working, and remote users are getting login error when trying to authenticate through SSL VPN web gui.

I have reloaded both ASA and AD without any change in the situation. This service was working fine before and the problem happened suddenly. No one did any changes to the configs. Customer do not have a backup config. Any suggestion on what would be next best action to fix this? I am not expert on setting Microsoft LDAP and if someone knows where I can check in Microsoft windows 2003 server for possible LDAP problem that would be greatly appreciated.

Thanks,

rdianat

I have this problem too.
0 votes
Correct Answer by srue about 7 years 5 months ago

the ldap binding account is just a regular user account. it doesn't even need admin permissions. if you want to use ldap for password changes it needs password change permissions, but otherwise just a regular user account - make sure it can't be locked out in AD or the password never expires or any of that stuff. you'll see the name of the ldap account in the ASA config.

ldap-login-password ***

ldap-login-dn ***

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
srue Fri, 07/10/2009 - 05:08

it sounds like yo'ure unable to even login and troubleshoot the ASA, is that correct? if so, your first step would be password recovery.

Also, check the LDAP binding account as its configured in the ASA and make sure nobody changed the password to this account in AD, or its not locked out for some reason.

snooter Fri, 07/10/2009 - 06:58

Not sure how exactly you have your asa setup to talk to ldap, but I'm doing the same here and I'm using IAS on a microsoft server. If you're using the same method, I'd locate the IAS service and restart it.

rdianat Fri, 07/10/2009 - 09:05

Thanks for your replies. I think the next best action is for me to do a password recovery and then find out which server is used to authenticate and authorize and then run some debug command to find where the authentication fails. I have a scheduled maintenance for tonight and I will do it. Meanwhile if you have any other tips to what else I can check would be great.

Thanks,

rdianat

srue Fri, 07/10/2009 - 09:43

snooter, ldap doesn't require IAS. It's much cleaner actually as it requires no special configuration like that aside from creating (or using an existing)an ldap binding account. It also can handle password changes.

I've had good success using 'debug ldap' when troubleshooting so once you get into the asa, i would start there, or if there is a syslog server you could check that. one things for sure, once it's back up and running, create a back up of the config, even if the backup is to flash. (copy running-config flash)

rdianat Fri, 07/10/2009 - 10:03

Hi Srue,

Is the binding username for LDAP like any other user name in "AD users and computers" of "administrative tools" or has its own special location?

So I will check if this account is locked, If the password is changed? and what else?

I assume if I change the password, that is only for binding between ASA and AD and LDAP and has no effect on usernames and passwords which users are using to do SSL VPN. Right?

Thanks,

rdianat

Correct Answer
srue Fri, 07/10/2009 - 10:11

the ldap binding account is just a regular user account. it doesn't even need admin permissions. if you want to use ldap for password changes it needs password change permissions, but otherwise just a regular user account - make sure it can't be locked out in AD or the password never expires or any of that stuff. you'll see the name of the ldap account in the ASA config.

ldap-login-password ***

ldap-login-dn ***

rdianat Fri, 07/10/2009 - 15:50

Thanks a lot for your comments. The problem was resolved very quickly as a result of your comments.

The problem was that the LDAP binding account was "administrator" and because of some bogus application, the administrator account was continously locked out. I changed the LDAP binding account to some other name and all started working fine.

Thanks a lot,

rdianat

Actions

This Discussion