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

Hi Mike,

You may wish to investigate:

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

http://www.cisco.com/en/US/products/sw/secursw/ps2086/products_configuration_example09186a00801df0ea.shtml

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

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

2. 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
http://www.bradreese.com/cisco-big-iron-repair.htm
1293 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
http://www.bradreese.com/cisco-power-supply-inventory.htm

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.

http://www.informit.com/articles/article.asp?p=653377&seqNum=3&rl=1

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