Ask the Expert: Configuring and Troubleshooting 802.1X

[ciscomoderator]

            With Javier Henderson

Welcome to the Cisco Support Community Ask the Expert conversation. This is an opportunity to learn and ask questions about how to configure and troubleshoot 802.1X. 

802.1X is an IEEE standard for media-level access control, offering the capability to permit or deny network connectivity, control VLAN access, and apply traffic policy, based on user or machine identity. During this event, Javier Henderson will answer all your questions regarding 802.1X configuration and troubleshooting.

Javier Henderson has been a customer support engineer with the Security Team, specializing in AAA technologies, since 2004. In addition to supporting Cisco customers, he has delivered training to other teams on various AAA products. Javier attended Buenos Aires University and holds CCNA and Checkpoint certifications. 

Remember to use the rating system to let Javier know if you have received an adequate response. 

Javier might not be able to answer each question due to the volume expected during this event. Remember that you can continue the conversation in Security,  sub-community AAA, Identity and NAC discussion forum shortly after the event. This event lasts through December 13, 2013. Visit this forum often to view responses to your questions and the questions of other community members.

[John Ventura]

Hi Javier,

Can you share a basic 802.1X configuration?  thank you for your help.

John

[Javier Henderson]

A basic 802.1X configuration follows:

aaa new-model

aaa authentication dot1x default group radius

!

dot1x system-auth-control

!

interface gigabitethernet 1/1

switchport mode access

dot1x port-control auto

!

radius-server host 10.1.2.3 key cisco123

[hhtyson11]

Javier,

There are some documents that have contradicting 802.1X configuration commands.  Can you please clarify this for me?  Appreciate it.

Thank you,

Henry

[Javier Henderson]

The syntax of 802.1X configuration commands changed after IOS 12.2(46), to accommodate new authentication options.

The old syntax is still permissible, but deprecated and does not appear on the context-sensitive help menus.

Javier Henderson

Cisco Systems

[Mahmoud Abd El-Wahed]

hi Javier,

could you please advise on this case:

https://supportforums.cisco.com/thread/2254843

[Javier Henderson]

Mahmoud,

It would be helpful to look at the output of "debug radius" and "debug dot1x all" (both turned on together at the same time).

Javier Henderson

Cisco Systems

[holger2meyer]

Hi Javier,

wondering how would you recommend to tackle the problem of CUCM not being able to provide certificate revocation information for LCSs of IP phones, which could be used in an fully automated manner by an 802.1x environment to validate that a certificate being presented for authentication is valid in every sence (including revocation), and that that phone is in fact allowed to connect to the voice VLAN?

Thanks,

Holger

[Javier Henderson]

Holger,

I recommend that you open a TAC case with the voice team, since the configuration need centers around the CUCM product, and 802.1X is just incidental in this case.

Javier Henderson

Cisco Systems

[John Ventura]

hi Javier,

Thank you for your help.  I have another question for you.  Can users be assigned a specific VLAN in 802.X deployments? 

John

[edwjames]

Hi John,

Using 802.1X with VLAN Assignment

http://www.cisco.com/en/US/docs/switches/lan/catalyst3550/software/release/12.1_13_ea1/configuration/guide/Sw8021x.html#wp1049882

**Share your knowledge. It’s a way to achieve immortality.
--Dalai Lama**

Please Rate if helpful.
Regards
Ed

[Javier Henderson]

John,

It is indeed posible, the RADIUS server can assign a VLAN after the user has successfully authenticated.

For this to happen, network authorization must be configured on the switch, for example:

aaa authorization network default group radius

Then the RADIUS server has to be configured to send three Attribute/Value pairs:

[64] Tunnel Type needs to be VLAN

[65] Tunnel Medium Type needs to be 802

[81] Tunnel Private Group ID needs to be the name of the VLAN on the switch

Javier Henderson

Cisco Systems

[holger2meyer]

Hi Javier,

Sorry for bothering you again but I’ve another question for you.

Cisco’s “IP Telephony for 802.1X Design Guide” states:

“… the lack of an explicit certificate revocation mechanism means that the

phone is still able to authenticate using 802.1X, because its certificate is still valid as far as the AAA server can determine. To keep the phone with a revoked certificate from gaining network access via 802.1X, use an exception policy in ACS 5 to specifically disallow that phone when it attempts to authenticate.“

Maybe, you can give an example how such a exception policy looks like?

Thanks again and regards,

Holger

[Javier Henderson]

Holger,

I need a bit more context, please. I know earlier you were talking about CUCM and certificate revocation, so I assume you're still refering to that.

Who is signing those certificates? Is that CA able to publish a CRL?

Javier Henderson

Cisco Systems

[holger2meyer]

Hi Javier,

Thanks again for your help. Some more background: the installation covers several thousand phones. The environment for data and voice services must meet highest security standards (similar to military grade). The network (Metropolitan) is protected by IEEE 802.1x NAC. Certificates are used by computers, servers and any other "data" device to authenticate to the network. The CA serving the 802.1x NAC/network is capable of CRLs, SCEP and OCSP, but does not support Intermidiate CRLs. OSCP is used to determine the revocation status of any "data" device's certificate. The identity store for the NAC solution is Active Directory.

The problem: the voice service will be based on Cisco's UCM (CUCM). The phones will be Cisco IP phones, all are running Locally Significant Certificates (LSCs). The LSCs are issued by the CAPF, which is an integral part of the CUCM. The CAPF acts as a root CA for the phones.

The certificate of the CAPF is signed by the CA serving the network/NAC solution. Just like all other "server" certificates used for the voice/CUCM environment, like TVS, tomcat and such.

Unfortunatly, the CAPF (the root CA for the phones) does not support revocation for LSCs (and not for MICs either). Neither does it provide/support CRLs, SCEP or OCSP. Thus, neither the CA serving the network/NAC solution, nor any AAA server can obtain revocation status information from the CAPF about a LSC being presented by a phone when joining the network. Exporting all LSCs from the phones to the identity store is not really an option since there's no automatic way of export. It is a tedious, manual process for each and every phone. With several thousand phones not really a way one would like to follow. Cico points out in its documentation (see my previous post) that revocation can be done in some sort of way by blocking a phone from entering the network by means of a blacklist and an exception policy on the ACS. I assume the blacklist can be kept in Active Directory, maybe by using a group, which every phone who needs to be blocked is added as a memeber to. However, I have no idea how the exception policy would need to look like (what rule). It would be great to get an exampel or idea of how to define the rule. Since the authentication will be based on certificate attributes, I assume that the NAC/ACS would be able to check an LCS being presented by a phone based on the LSC's certificate subject attribute, which contains the commonName of the LCS. So, my understanding is, that the exception policy needs to determine if the commonName presented is contained in the blacklist. If so, the phone presenting the LCS needs to be denied network access based on the exception policy. But, how would the exception policy look like?

Thaks again!

Regards,

Holger