ACS cannot Authenticate Aironet Users against Exernal DB (LDAP)

dopenfield · ‎02-14-2005

Can anyone point me to a technical explanation of why this is true?

All I have found so far is one small note in a help file and something that might be related under EAP-FAST explanation.

I have posed this question to our Cisco account team but no response yet.

Just need to have a good explanation when explaining to mgmt why we need to have a special setup for WLAN users.

paddyxdoyle · ‎02-14-2005

It works OK here, the Uni i'm working at has been using Novell E-directory to store their user credentials and MAC addresses of devices associated with these users.

The ACS server has been configured to talk to the e-direcory via LDAP and using AAA on the access points users can authenticate using credentials and/or using MAC address plus whatever encryption mechanism they use.

PD

dopenfield · ‎02-14-2005

Hmmm... We still get this error in the Failed Attempts log on ACS...

Auth type not supported by External DB

The LDAP issue is mentioned in the ACS doc if you look in just the right place.

We are using Oracale for our LDAP but I don't believe there should be a difference with Novell implementation.

bmountfo · ‎02-14-2005

Hi Doug,

The limitation stems from what authentication protocol LDAP can handle in relation to the protocol that your wireless authentications are using. LDAP is limited to PAP for authentication and most wireless authentication protocols use some flavor of CHAP or MS-CHAP. The good news is that PAP is used in an encrypted tunnel with PEAP (EAP-GTC), EAP-TLS, and EAP-FAST (if the PAC is manually provisioned) so LDAP can be used with these protocols. Here is a link to documentation that shows the protocol-database compatibility matrix:

http://www.cisco.com/univercd/cc/td/doc/product/access/acs_soft/csacs4nt/acs33/user/o.htm#wp792728

Hope this helps!

-Bradley

dopenfield · ‎02-15-2005

Do I need to do anything special to make it work with the manual PAC provisioning? I have tried that on one ID and it didn't seem to make a difference.

Distribibuting the PACs manually will need some thought.

And if the User-IDs aren't already on the ACS how do I do manual provisioning? This is a University environment so users change quite frequently.

I don't have a totally Cisco Client environment, in fact most clients won't be Cisco.

I appreciate any tips on how others have dealt with these issues.

bmountfo · ‎02-15-2005

Manual provisioning does require that the users already be in ACS so that may not be the best option in a highly dynamic environment. I have attached a document that I put together that provides step-by-step instructions for EAP-FAST deployment including automatic and manual PAC generation. In a dynamic environment with LDAP, I would say your best bet will be the EAP-GTC version of PEAP which uses PAP over an encrypted tunnel to send username and password to the LDAP database via ACS. The only major drawback to EAP-GTC is that it requires either the Cisco ACU or another third party EAP supplicant to be installed on the client computer since the Microsoft EAP supplicant uses EAP-MSCHAPv2. EAP-FAST has the same requirement, however, so this should not be much of an adjustment if your were already headed down the EAP-FAST path. I have attached another guide for PEAP that has proven very useful.

dopenfield · ‎02-17-2005

Attached files were very helpful. Am trying to do PEAP now.

The 1024K thing I hadn't noticed mentioned anywhere else.

Tried the self-signed cert first and got the wierd Microsoft error so went through the steps to get the fix your document mentioned. Didn't change the error so I've now gotten an actual certificate and gotten it installed (I think).

I'm still not getting authenticated and would like some help with debug commands on the APs

I've got debug aaa authentication and debug radius verbose running but the only message I get says my MAC address failed to authenticate. How can I get some detail on where in the process the authentication is failing?

bmountfo · ‎02-17-2005

Hmmm....you should be getting more than that from debug radius and debug aaa authen if your AP is truly attempting EAP authentication. The debugs I generally use for this are 'debug aaa authen', 'debug radius', and 'debug dot11 aaa dot1x all' coupled with gathering the detailed support logs from ACS. A warning about 'debug dot11 aaa dot1x all'....it is VERY verbose and cryptic if you don't have alot of experience looking at it so it may be best to open up a TAC case. With these debugs turned on, you should see an EAPOL logon show up from the client (usually says 'received EAPOL packet...') and then a request for identity from the switch and a response from the client with a username and password. Then a series of RADIUS challenge/response packets will be passed which consists of the server cert being passed to the client for validation and then the client sending the username and password to the server. Then you will finally get an access-reject or access-accept packet from the RADIUS server. The failed and passed attempts logs in ACS can also provide good info as to what the source of the failure may be. Do you get any passed or failed attempts for these authentications?