802.1x & IP Phones

[Brad_199]

Objective:

1.   Authenticate workstations based on domain membership using 802.1x (wired) with NPS
2.   If the workstation is a member of the domain, then place the workstation into VLAN 1.
3.   If the workstation is not a member of the domain, then place the workstation into VLAN 2.
4.   Do not authenticate IP phones

Problem:

Objective 1-3 is fine (using Open VLAN) but it's the phone situation I am having some problems with.

The phone is tagged in the right VLAN and we use DHCP (vendor options) to assign an IP address. This is working successfully on the test switch providing the phone is connected to a port that isn't an 'authenticator'.

As soon as the phone is connected to a port authenticator, the phone will boot up and fail to obtain an IP address.

I'm not sure if it's the phone that has the problem or the switch configuration but I've browsed the web/forums for hours and each and every article I read, details the same switch config that I am using.

Do you have any suggestions??

UPDATE:

WireShark capture of phone port shows the DHCP discover packet tagged in the correct VLAN

WireShark capture of the uplink port doesn't see the DHCP discover packet

Uplink port is in the Voice VLAN

Move phone to non 802.1x authenticator port on same switch and phone boots up successfully, with WireShark captures on phone port & uplink port capturing all the DHCP packets.

[Michael Patmon]

Hello.  Just to clarify, you want the IP phone and PC on the same autheticated port but you don't want to authenticate the phone?  I don't believe this is possible, you cannot have a partially authenticated port.  When 802.1x fails on the phone the switch will place it in the unauth VLAN.

Can you run mac-auth for the phones via Radius or Local auth?  I think that's the only way it will work when you are running this all on the same port.

I'm checking on your LLDP/2610 question also.

[Brad_199]

Hi Michael,

You are correct - that is exactly what I am trying to achieve.

The IP phones in question are Avaya 9620's which have a feature that allows the phone to by-pass the authentication requests but passes on the EAP requests to a PC connected to it's dual port.  

Section taken from official Avaya site:

• Standalone telephone (Telephone Only Authenticates) - When the IP telephone is configured for Supplicant Mode (DOT1X=2), the telephone can support authentication from the switch.
• Telephone with attached PC (Telephone Only Authenticates) - When the IP telephone is configured for Supplicant Mode (DOT1X=2), the telephone can support authentication from the switch. The attached PC in this scenario gains access to the network without being authenticated.
• Telephone with attached PC (PC Only Authenticates) - When the IP telephone is configured for Pass-Through Mode or Pass-Through Mode with Logoff (DOT1X=0 or 1), an attached PC running 802.1X supplicant software can be authenticated by the data switch. The telephone in this scenario gains access to the network without being authenticated.

I thought about MAC-auth but I am trying to avoid having to create or administer user accounts or MAC address lists as the number of IP phones in use is in the hundreds.

[Michael Patmon]

I don't think there's any way around not authenticating the phones if you are running 802.1x on the port, otherwise that would defeat the purpose of running any port security at all.  

To reduce the administrative overhead of adding all the MAC address you could authenticate based on the MAC OUI.  Since the phones are all from the same vendor you shouldn't have that many accounts to create.  You could authenticate via Radius or use the switch's Local Mac Auth to do that.

Or if the phone supports 802.1x supplicant you could do everything via 802.1x with one account.

[Brad_199]

Thanks for the suggestions Michael.

I still have reservations about mac-auth not only because of the administration part I mentioned, but also because it seems the phone's support MD5 authentication or PKI certs.  PKI certs is definitely not an option for me right now and MD5 was removed in newer server OSes by Microsoft for security reasons. 

I have read it's possible to re-instate MD5 by copying a DLL etc, but I'm not so keen on re-instating something that was purposely removed (for a reason).

Thinking beyond that, the mac-auth operating rules that I've read states that after the client authentication, the port is assigned to an untagged VLAN.

Regardless of whether that was assigned by RADIUS, auth-vid or the ports static config, the phones need to be tagged so unless I'm missing something, I can't see that implementation working either......

[Michael Patmon]

I'm not familiar with how MD5 or PKI would affect mac-auth but you can assign VLAN membership, tagged or untagged, via an attribute returned in the Access-Accept packet from the Radius server.  LMA will do it also.

But that does not alleviate the overhead you mentioned, which I can appreciate.  If you choose to proceed with mac-auth I can help find the specific attributes to pass.  The LMA section in the "Access & Security Guide" has an example config for tagged VLAN membership as well.

[Brad_199]

Perhaps I got my wires crossed re: PKI & mac-auth.  

I got the MD5 part from this though (admittedly it is an old doc):

http://downloads.avaya.com/css/P8/documents/003945646

[Brad_199]

Michael - In your earlier message you mentioned to authenticate using the MAC OUI.

How can you limit the amount of characters used during the authentication process?

f

[Michael Patmon]

For Radius that would depend on the server vendor.  I'm not sure with NPS but with ClearPass you can use regular expressions.  The switch still tries to auth the full mac, it's up to the server to auth it based on a mask. 

The switch's LMA will let you do a full mac-address, mac-oui, or a mask of bits.

(config)# aaa port-access local-mac mac-group temp
 mac-addr              Associate a MAC Address to the current MAC-group.
 mac-mask              Associate a MAC Mask to the current MAC-group.
 mac-oui               Associate a MAC Organizational Unique Identifier to the current MAC-group.
 <cr>

[Brad_199]

Michael,

MAC-Auth via RADIUS - does that still require Active Directory user accounts for each MAC address or is it controlled by a RADIUS attribute?