I've been trying to get the 802.1x working with our IP phones without success. I've followed the instructions found in the IBNS phased implementation plan at http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6586/ps6638/Whitepaper_c11-532065.html
It appears that the ACS is trying to authenticate the phone using EAP-TLS.
This is however a red herring as I don't have any hits on the policy for the phone...
I have a rule which should match the phones...
There is an internal user created to the following format...
Identity Group: All Groups
Under Access Policies> Access Services> 802.1x > Authorization
I have a rule using the following condition:
System:IdentityGroup in All Groups
This rule doesn't seem to get hit yet it is defined exactly as described in the above document?
Anyone got this working?
Are you seeing any entries at all for the phone in the RADIUS authentication log?
If so, look at the details (click on the magnifying glass for the relevant entry) to see what policy is being hit and why.
I've simplified my config so that I only have the default permit policy defined under Authorization in the Access Policy.
I've got to the stage now where I'm getting EAP-FAST failures in the log from the phone with the following message...
Authentication failed :
I've tried various configurations for EAP-FAST on ACS5.1 but nothing seems to work.
The thing that's confusing me is that I'd be happy to use EAP-MD5 on the phone as I do with our Avaya phones. This should be supported according to all the documentation I've read and yet the phone only requests EAP-FAST (I know this as I've sniffed the converstion between the phone and the switch)
Yet on the phone itself, I only see the option to set an EAP-MD5 password? No mention of EAP-FAST, PAC provisioning, EAP-TLS etc which should all be supported. All documentation I've read also says these three EAP methods are all supported yet I cannot find any documentation on how they configure them. Also the inner auth methods supported on the ACS are EAP-MSCHAPv2 and EAP-GTC, not EAP-MD5 that I assume the phone wants to use.
The phones are 3rd Generation (7962G), and are running Skinny 8.5.2 (SCCP42.8-5-2SR1S).
I'm having a similar issue instead with a C7945G phone. ACS5.1 Access Service configured to allow EAP-MD5 & PEAP, C7945G configured with MD5 user credentials, Window 802.1x clients with PEAP. Win client auth OK using PEAP, but C7945G decides it want to use EAP-FAST (as per packet capture) and fails auth.
I've found that the issue lies within the phone's firmware from 8.5 onwards, the same version that EAP-FAST was introduced as "supported". I'll rolled the phone's firmware back to version 8.4(4)S and could successfully authenticate the phone using EAP-MD5 and Win clients using PEAP.
As a side note, if my ACS5.1 Access Service was only configured to allow EAP-MD5, the C7945 phone would auth OK when running firmware above 8.5.
I'm awaiting a response from the TAC.
This may help.
its the firmware, take a look at the bug cscsz59661.
I have the same problem, my log msgs in the ACS say: "EAP type not configured"
I've set up dot1x with MDA so i can authenticate phones and workstations behind the phones. I had to make sure that i was not insane so i tryed authenticate a computer with the phone username, it worked and i also have a TAC open.
The basic solution is to upgrade the firmware, but my callmanager doesnt support... so im waiting.
I recommend try that out ... try authenticate a workstation.
PS. I'm 90% sure that phones only are doing MD5 and you cannot use AD to authenticate them, you need to use the local ACS db
I utilized as base to configure dot1x the following documents
Cisco couldn't get EAP-FAST or EAP-MD5 to work so in the end opted for EAP-TLS using the MIC for authentication. This works pretty well so for those of you looking for a solution to this issue try this...
The steps to configure this would be done all on ACS 5.1:
- import the Cisco root CA and manufacturing CA in the ACS trust list:
* the certificates are located here:
How to import those CA certs in ACS 5.1 (make sure to select also "Trust for client with EAP-TLS"):
- create a certificate authentication profile, using the "common name"
as the principal username x509 attribute, with no binary cert comparison, as described here:
- On the access policy you eventually have to:
* allow EAP-TLS in the Access Service (you can also disable EAP-FAST
* make sure you select the above created certificate authentication profile in the Identity policy:
- last but not least, you have to create a user on the ACS local DB where the username matches the IP phone MIC common name. The password is totally irrelevant as it's not used for the authentication.
The username is in the format "CP-
Thank you Rhodri for sharing the knowledge.
However I failed to understand the last step. What's the purpose to define Phone common name in ACS local DB?
I had 802.1x working with MD5 with IP Phone 7942. I followed your steps to add the CAs and defined Identity store. I also modified the 802.1x rules that if it match Certificate Dictionary:Common Name starts with CP, then do Phone Authorization, which is basically identify it as phone and put in voice vlan.
However my ACS logs always shows that the Phone is trying to do MD5 authentication (doesn't matter if I have MD5 password set or not). Do I need to do additional settings on the phone as well? It currently has 802.1x enabled. (Mind you that it works with MD5 802.1x).
Cisco told me that from Firmware version 8.5.2 onwards (at least on the 7962G) only support EAP-FAST and EAP-TLS. EAP-MD5 is no longer supported even though the option to set the MD5 password is still there. I'm guessing you have older firmware running on your phone than 8.5.2?
Yes, we are running old firmware 8.3.2. But I doubt if that's preventing EAP-TLS from working.
Can you please share the details of your access policies for the phones?
Here is what I have:
Match-802.1x to look for "RADIUS-IETF:Service-Type match Framed" condition, and the result is 802.1x service.
In 802.1x service, the identity store has both Certificate Based and password based authentication method enabled. Certificate Based should be used for phones, and password based should be used for user AD authentication.
And in authorization, I defined a rule to match "Certificate Dictionary:Common Name starts with CP", then result in Phone-Authz Authorization profile.
However there is no hit to this rule. I'm wondering if I missed anything.
I have the same Match-802.1x service selection rule. Under Identity in the 802.1x Service I'm using an Identity Store Sequence with Certificate Nased (CN Username) selected and AD1 and Internal Users selected for password based.
Currently my phones are hitting the default permit rule at the end as I'm not enforcing any policy as yet.
I'm having a similar issue to you with regards to not hitting the Authorization rule however the difference being, I'm attempting to match System:IdentityGroup in All Groups:IPPhones. (I think you've seen another post from me re this matter).
Now this is where things get interesting...
I was instructed by TAC that I'd need to configure an Internal User for the phone for this to work. As I'm hitting a default permit Access rule, I thought I'd try deleting the Internal User for a phone and try to re-authenticate assuming it would fail. It didn't! The only reason this was working for me is that I trust the MIC certificate. In a nutshell, I'm having exactly the same issue as you in that the rule doesn't get hit.
So I think I need to go back to Cisco and try and figure out how the CN Username can be used in an Authorization rule.
When I get to the bottom of this I'll post back here/
I would like to clarify that the phones support following authentication mechanisms with load 8.5.2 and higher
-> EAP-FAST, EAP-TLS, and EAP-MD5
please refer to
When the server is advertising all 3 mechanisms, the phone will try to authenticate using EAP-FAST
There is no way on the phone to control what mechanism to use.
This may lead to issues when on the server the endpoints are configured to use another method like EAP-MD5
Can you please clarify the sequence of the EAP-FAST, EAP-TLS, and EAP-MD5 authentication? I'm running an old version of firmware 8.3.2. It's seems even if I enabled EAP-TLS on the ACS, the phone is only trying MD5.
Try creating an Identity Store Sequence and add internal users to Authentication and Attribute Retrieval Search List and also the Additional Attribute Retrieval Search List.
I did this then I was able to hit my auth policy for phones.
PS I've discussed EAP-MD5, FAST and TLS with ACS 5.1 and IP phones and they've acknowledged there is an issue with EAP-MD5 when using post 8.5.2 Cisco IP Phone firmware with ACS5.1. They are currently bench testing this to solve these issues.
Thanks for your information.
However I still failed to understand the need to creat internal user groups for phones. If all the phones have the same policy, can I just define a policy based on something common in the certificate?