|
1/28/2009 8:36:34 AM
|
abeats
Posts 5
|
As a technology implementation consultant for various large customers who have been deploying 802.1X, my experience with Beacon is that it tends to ensure the success of the overall project by providing location data for all endpoints that will or will not participate in 802.1X. Although I've helped customers implement 802.1X without Beacon, I have invariably been faced with the problem of "my spreadsheet says that the printers are named/connected as shown here", but the reality is that the spreadsheet becomes outdated by normal day-to-day dynamic changes that occur on the network - the type of changes that can wreak havoc on those attempting to turn on 802.1X on very specific ports (any inaccuracy of where endpoints are connected only causes delay in turning up 802.1X on ports where we don't know what is actually connected, and can open security holes where we don't want them). Anyone else have thoughts on this? I'm happy to share further details if there's interest.
|
|
4/1/2009 11:01:10 AM
|
sacRyan
Posts 2
|
Beacon has been a great investment for knowing what was actually plugged in where on the network. Just like you said about your spreadsheets, our network diagrams were outdated and it could have caused a lot of grief to have to track down those issues with the desktop support team. However, with beacon in play, what devices are you seeing 802.1x not being enabled for? I ask as we are planning a global 802.1x role out using Beacon to authenticate any device that can't have the UAC client installed. --Thanks.
|
|
4/21/2009 1:10:58 PM
|
abeats
Posts 5
|
sacRyan, I was describing the few sites a while ago where Beacon had not been implemented (and also non-UAC sites) and where the customer wanted to specifically disable 802.1X on a few ports where non-EAP endpoints were deployed. Though we advised them - and they undertstood the ramifications - of the security hole this would open, the requirement remained on the table in order to ensure that these endpoints were granted some form of network access. Beacon certainly could have addressed this issue (as you suggested) by profiling these endpoints and MAC-authing them via RADIUS/Infranet Controller MAC-auth realm (thus allowing for consistent 802.1X port configurations enterprise-wide). These customers have since realized the drawbacks of attempting to deploy 802.1X without Beacon, and have (or are considering) deployed Beacon to address the issue of "disabling 1X on ANY port opens a significant security hole".
Hey, I've encountered an interesting scenario recently where one company didn't want corporate users to EVER land in the guest VLAN (thus circumventing the corporate network for potentially unscrupulous purposes). Beacon to the rescue! Let me know if you're interested in discussing that matter on a separate thread. 
|
|
pages:
1 |
|---|