cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
427
Views
0
Helpful
4
Replies

LEAP Authen with CSACS, Finding Domain Controller Problem?!?

jasonhumes
Level 1
Level 1

Helllo

We are using LEAP with CSACS internal user database to authenticate our wireless users. We are using the latest ACU from Cisco and for some reason when we start the LEAP auth process, it takes up to 3 minutes on the finding domain controller portion of the auth process. Why is it looking for a DC when it is configured for CSACS database user accounts. Any way to bypass this part or maybe speed it up. Thanks

4 Replies 4

jeff.k
Level 1
Level 1

Kind of hard to answer that as you haven't shared how you know what you know or how you have it configured. Hopefully a few general comments will help:

1) The normal process of authentication lookup in ACS is to first look in the local ACS DB

2) If there is no matching user, then it will check to see what the "unknown user policy" is.

3) If the unknown user policy does not allow external db checking, and there is no user in the local ACS db, then the user will fail authen.

4) If the unknown user policy does allow external db checking, then it will check each one of those in the configured order.

From your comments, it does sound like you have an unknown user policy configured to check external DB's, and the Windows SAM or AD, in particular.

Typically, the reason it would try to go to the external DB lookup is because your submitted name doesn't match a name in the local ACS db that you expect it to match - for example, because you are automatically appending or stripping a realm (mycompany/testuser is submitted when you expect "testuser" to be submitted).

One way to check this is to look at the failed authentication logs (which you're probably already doing). However, also compare this information to the detailed logs. Those logs are availabe under Program Files>>Cisco Secure ACS 3.0>>CSAuth>>Logs>>CSAuth. There are similar files for CSRadius that may be helpful. A careful analysis and comparison of these logs and your failed attempts log should isolate the source of the problem.

HTH

Jeff

Nope, all the users are within the local ACS DB...and there is no unknown user policy. All of the users who try to authenticate are being authenticated...it just takes a long time because it seems to try to find a DC....after they are authenticated and have gotten an IP and everything else. While the ACU is trying to find a DC, the user in question is able to use the network...so why would it be trying to find a DC, or for that matter, an IPX frame type. Thanks

We experience the exact same issue regarding the DC find attempt. Our users are all authenticated through RADIUS using NT account credentials. It seems as though I ran across some documentation regarding this issue some time ago, but I have been unable to find it recently. Executives don't like waiting 3 minutes for the login process to finish, nor do they understand why.

I have been having the same issue. We run the "NLTEST" commands to see what DC you are authenticating against, and if it is a DC at the far edges of your WAN you will have this problem. Run the "NLTEST" to release the current DC and allow the ACS to seek a new one (Physically and logically closer to your ACS). Another way to fix this is to run LMHOST file so that your ACS will not look at other than specified DC's.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Review Cisco Networking products for a $25 gift card