EAP-TLS machine authentication with ACS server

Hello,

I'm working on a limited 802.1x rollout, and was hoping to use Cisco ACS server as my RADIUS server / Authentication Server.

Initial testing went fine using more basic EAP mechanisms, however when we started trying to use EAP-TLS, we ran into some problems. From what I can see in the Cisco ACS documentation, it's almost as if the ACS server requires an AD to talk to for authentication to complete - it can't simply rely on the a valid cert for authentication. Am I correct in understanding this? Unfortunately, the machines involved in this limited rollout have access to PKI infrastructure and a CA, but are not AD members - possibly an unusual set of circumstances.

Two questions, assuming this reliance on an AD is real, and not just us misunderstanding what we're seeing:

1 - Is this reliance on having an AD part of the IEEE EAP-TLS standard? This is the first I've seen of a requirement for a directory such as this in my readings about EAP-TLS.

2 - If not, does anyone know of a product (maybe Steel-Belted RADIUS?) that doesn't have this requirement and can do the auth based solely on the validity of the cert?

Cheers for any help, Mike

Reply to
Mike
Loading thread data ...

Hi Mike,

You may wish to investigate:

Cisco Secure ACS for Windows v3.2 With EAP-TLS Machine Authentication

formatting link

----------------------------------------------

In the CiscoSecure ACS for Windows version 3.x, the CSUtil is not able to add other NAS vendors to the GENERIC EAP.dll

This problem was first seen with CiscoSecure ACS for Windows version

3.2(1.20).

This issue occurs due to the presence of Cisco bug ID CSCec26584.

CiscoSecure ACS for Windows currently supports EAP for only four RADIUS types ( Internet Engineering Task Force [IETF], Cisco IOS/PIX Firewall, Cisco VPN 3000, and Cisco Aironet ).

The only way to add EAP support for other RADIUS types is through the registry.

When an imported RADIUS Vendor-specific Attribute (VSA) is used as the Network Access Server (NAS) type for 802.1x, EAP requests are rejected.

The CiscoSecure ACS for Windows logs show that there is no association between X vendor and the GenericEAP.dll.

----------------------------------------------

As a workaround, verify that the IETF RADIUS NAS type is used.

If so, everything works fine.

If it is not used, create an association in the CiscoSecure ACS for Windows registry between the NAS vendor and the Generic EAP.dll, as such:

  1. Locate the NAS vendor number:

HKEY_LOCAL_MACHINE\\Cisco\\CiscoAAAv3.2\\NAS Vendors

  1. Add this number to this directory:

HKEY_LOCAL_MACHINE\\SOFTWARE\\Cisco\\CiscoAAAv3.

2\\CSRadius\\ExtensionPoints\\002\\AssociateWithVendors

----------------------------------------------

Hope this helps.

Brad Reese BradReese.Com - Cisco Repair

formatting link
Hendersonville Road, Suite 17 Asheville, North Carolina USA 28803 USA & Canada: 877-549-2680 International: 828-277-7272 Fax: 775-254-3558 AIM: R2MGrant BradReese.Com - Cisco Power Supply Headquarters
formatting link

Reply to
www.BradReese.Com

Hi Brad,

Thanks for the reply, but as it turns out, the issue I was having is by design - this excerpt from a Cisco Press book tells me that Machine Authentication (machines performing 802.1x authentication in an automated fashio before login) is only supported for Windows systems, and requires an AD - there's no Machine Auth for local databases with ACS. I don't think I explained the problem properly before - I only got involved with the testing in a hands-on way yesterday.

formatting link
I'm not certain WHY it was designed like this, but there you go. I'm now trying to figure out if Machine Auth would work with Steel-Belted without a directory. I can see directory membership offering some additional security, but am surprised it's not optional.

Cheers, Mike

Reply to
Mike

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.