- Community Home
- >
- Networking
- >
- Legacy
- >
- Switches, Hubs, Modems
- >
- Re: 802.1x authentication with IP phones?
Switches, Hubs, and Modems
1748151
Members
3914
Online
108758
Solutions
Forums
Categories
Company
Local Language
юдл
back
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
юдл
back
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Blogs
Information
Community
Resources
Community Language
Language
Forums
Blogs
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-10-2011 01:25 AM
тАО03-10-2011 01:25 AM
802.1x authentication with IP phones?
Hi,
I have a setup like so:
Radius client authentication
Un-auth VLAN 40 (Guest VLAN)
Auth VLAN 11 (Workstation VLAN)
I'm using Microsoft NAP, and i am having some trouble finding out how i should handle all my IP phones. - They are in a separate port, so they cant be authenticated by my radius server, and by default, they will move to VLAN 40 (guest network). I can live with the ip phones getting on VLAN 11, because i have a untagged 11, tagged 10 setup, and it is working fine.
VLAN 10 is VOIP vlan.
Can i some some, mac address match / check from a list of mac, or maybe a mac-addresses pattern?
Thank you!
/Mick
I have a setup like so:
Radius client authentication
Un-auth VLAN 40 (Guest VLAN)
Auth VLAN 11 (Workstation VLAN)
I'm using Microsoft NAP, and i am having some trouble finding out how i should handle all my IP phones. - They are in a separate port, so they cant be authenticated by my radius server, and by default, they will move to VLAN 40 (guest network). I can live with the ip phones getting on VLAN 11, because i have a untagged 11, tagged 10 setup, and it is working fine.
VLAN 10 is VOIP vlan.
Can i some some, mac address match / check from a list of mac, or maybe a mac-addresses pattern?
Thank you!
/Mick
3 REPLIES 3
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-14-2011 02:48 PM
тАО03-14-2011 02:48 PM
Re: 802.1x authentication with IP phones?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-14-2011 02:52 PM
тАО03-14-2011 02:52 PM
Re: 802.1x authentication with IP phones?
or 802.1x supplicant configuration on ip phone same pc
for example ip phone configuration
http://wiki.siemens-enterprise.com/images/archive/c/cb/20080612100423!Layer_2_authentication_on_VoIP_phones_(802.1x).pdf
for example ip phone configuration
http://wiki.siemens-enterprise.com/images/archive/c/cb/20080612100423!Layer_2_authentication_on_VoIP_phones_(802.1x).pdf
cenk
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-14-2011 09:29 PM
тАО03-14-2011 09:29 PM
Re: 802.1x authentication with IP phones?
Altho you can do mac addr authentication for 802.1X, it is less secure compared to a device that has a supplicant.
The issues for mac addr auth:
1) the uid/pw in AD must be the same, unless you can do #2. The issue with uid/pw being the same is it violates the default password complexity rules in AD, but you can configure a specific group pw complex policy to get around that (W2K3/AD did not have this feature!)
2) depending on which HPN switch you have, it may be possible to set a different pw for a mac addr in the switch config, but it requires the phones to stay there, and as you add phones you have to add more entries...it does not scale well. -and you may hit the pw complex rule again, but it can be changed.
3) NAP does not have a way to look at prefix only for basic pattern match, at least not that I have found.
Now, there are some benefits with NAP that can ease some of the less-secureness of mac auth, you can set in the connection profile (I think conn profile, it's been 1+yrs since I've done NAP/NPS this way) that the device must match a manufacturer type and/or device type. So as a device comes in, even if someone trys to spoof the mac addr, other components must match. You can also lock it down to the device must be wired and not wireless.
The other downside to 802.1X auth, it did not (originally) have support to pass back info to a switch to put a port "tagged" into a vlan. RFC-4675 added that functionality, but Microsoft doesn't support it at all, I have been asking then for 2 yrs for it. ProVision ASIC switches from HP-ProCurve have had this for 2yrs: 3500/5400/6200/6600/8200. (FreeRADIUS 2.0+ has it too).
So you could auth a VoIP phone, but you are still required to have the port tagged in the voip-vlan. I would do that and have the port untagged in a "dead" or unused vlan -or- not even untagged in any vlan if it was a VoIP phone only on that port, and the phone was configured to speak 802.1Q upon power-up.
A device without a 802.1X supplicant just doesn't have the same benefits.
hth...Jeff
The issues for mac addr auth:
1) the uid/pw in AD must be the same, unless you can do #2. The issue with uid/pw being the same is it violates the default password complexity rules in AD, but you can configure a specific group pw complex policy to get around that (W2K3/AD did not have this feature!)
2) depending on which HPN switch you have, it may be possible to set a different pw for a mac addr in the switch config, but it requires the phones to stay there, and as you add phones you have to add more entries...it does not scale well. -and you may hit the pw complex rule again, but it can be changed.
3) NAP does not have a way to look at prefix only for basic pattern match, at least not that I have found.
Now, there are some benefits with NAP that can ease some of the less-secureness of mac auth, you can set in the connection profile (I think conn profile, it's been 1+yrs since I've done NAP/NPS this way) that the device must match a manufacturer type and/or device type. So as a device comes in, even if someone trys to spoof the mac addr, other components must match. You can also lock it down to the device must be wired and not wireless.
The other downside to 802.1X auth, it did not (originally) have support to pass back info to a switch to put a port "tagged" into a vlan. RFC-4675 added that functionality, but Microsoft doesn't support it at all, I have been asking then for 2 yrs for it. ProVision ASIC switches from HP-ProCurve have had this for 2yrs: 3500/5400/6200/6600/8200. (FreeRADIUS 2.0+ has it too).
So you could auth a VoIP phone, but you are still required to have the port tagged in the voip-vlan. I would do that and have the port untagged in a "dead" or unused vlan -or- not even untagged in any vlan if it was a VoIP phone only on that port, and the phone was configured to speak 802.1Q upon power-up.
A device without a 802.1X supplicant just doesn't have the same benefits.
hth...Jeff
The opinions expressed above are the personal opinions of the authors, not of Hewlett Packard Enterprise. By using this site, you accept the Terms of Use and Rules of Participation.
News and Events
Support
© Copyright 2024 Hewlett Packard Enterprise Development LP