There are plenty of integration and configuration challenges when we look at 802.1X, but one of the most notable issues is choosing the right supplicant to best serve your end users.

Some of the major obstacles we face with 802.1X center around creating a smooth end user experience.  We, as integrators, have the distinct ability to make ‘whatever’ work- we find a way. But, what I hear most from my customers is “it has to be easy for the end user.”  (Sometimes they go on a little further, but I’ll leave it at that.)

Why does it matter?
Wireless, wireless, wireless. Although wired 1X is popular with our customer-base, the world isn’t quite flocking to it yet. However, 802.1X is certainly the best way to increase security and ease management of wireless networks. It’s standard, it’s flexible, it’s widely-supported by devices and endpoints and it eliminates the need for pre-shared keys or secondary passwords. It’s what most enterprises, government and educational organizations are implementing now, so it’s important.

What are some of the problems?
The end user will have some adjustments to make, and network admins and support desks aren’t always thrilled with the propect of re-training users for these expectations.

  • First of all, the time to authenticate and connect to the network is going to drastically increase. I say drastically- it’s only a few seconds- but I’m sure it feels like minutes to a new 1X end user.
  • In addition, we’re in a transition and growing period where we’re trying to integrate and authenticate multiple pieces- the machine and/or user as well as any other clients residing on the endpoint, so there can be single-sign-on issues. Not SSO in the traditional sense, but single-1X-sign-on vs logging in to authenticate and open the port, logging in again to get to network resources (such as Novell).
  • There may also be issues supporting multiple profiles, so end users may need to understand the concept of enabling 802.1X on an interface at their office, then disabling it when they go home.
  • Or perhaps, in a shared or lab-type environment, we may have multiple unique users logging in to the same endpoint device, so we have to make it easy for end users to log off so there’s a forced re-auth for the next user.

There are plenty more, but this hits on the major concerns of most organizations planning to implement 802.1X (wired or wireless).

How do we address the issues?
There are different ways to deal with the complexity of supplicant and end-user interactions. First and foremost, a good end user training program will be needed. There’s a learning curve, but eventually end users will get it- we just have to make sure the transition for ‘now’ to ‘got it’ is smooth and doesn’t overwhelm help desk resources.

As the operating systems and clients progress, we’re seeing more integration and the ability to share 802.1X information between disparate pieces of the endpoint.

In the meantime, there are also 3rd-party supplicants that can ease several of the pains. Cisco’s Secure Services Client  (acquired from Meetinghouse’s Aegis supplicant) and Juniper’s Odyssey Access Client  (acquired from Funk) both offer options and configurations not currently available in native OS supplicants. (For example, both offer the GINA shim for integrating Windows 1X login with Novell as well as multiple profile support.) Although I haven’t tried it, my understanding is you can still operate both of these clients independent of the controllers provided from the same vendor.

Is it a deal-killer?
It can be. The struggle to provide a smooth transition for end users is often a deal-killer for organizations looking at deploying 802.1X. Although there are ways to combat most of these obstacles; often the time, planning and money required to proceed make it unattractive enough to abandon the project. In most cases, the more heterogeneous the endpoint environment is, the less attractive the solution becomes. In an all-Microsoft environment, you can have an 802.1X framework up in a matter of hours. With a mix of authentication directories, endpoint OSs and user expectations, you could spend weeks or months ironing out the details.

The good news.
Yes, there’s some good news here. The increased adoption of 802.1X is continually leading to increased integration of the software, operating systems and clients on endpoints. While 802.1X may never reach ‘plug-and-play’ status, pretty soon the integration will reach a point where configuration is simplified enough for more wide-spread adoption, even in the most diverse environments.

Just hang tight, we’ll get there!

# # #

 

jj

Author, speaker, and recognized authority on network and wireless security architectures, Jennifer (JJ) Minella helps organizations solve technical problems and align teams.

View all posts

3 comments

  • Roland,
    If you’re using multiple VLANs with dynamic VLAN assigment, there are a few things to check.

    First, be sure there are ip helper address settings configured in the switches, so if a client of VLAN 99 needs an IP address from a DHCP server on VLAN 1, it can reach it. Without the ip helper, the VLAN 99 request won’t make it to VLAN 1, so the client will never receive an IP.

    Generally, there is no need to change lease times on the DHCP server to facilitate the change. When the switch resets the port, it will trigger the action you need.

    Some time lapse is to be expected. In typical standard-based implementations, the EAPoL and RADIUS communications have to happen in 3 parts before the port can be opened. In specific situations, as with some of Cisco’s default settings, the switch may go through other steps as well, to check for spanning tree and EtherChannel connections, etc.

    All in all, 30 seconds is not terribly far out of the normal range, but it can be shorter if everything is playing nicely. Five to eight seconds is about as fast as I see in a controlled lab. Time depends on the operating system and supplicant, the switch and the RADIUS/AD servers.

    -jj

  • Hi,
    I’m implementing dot1x on a client LAN. The customer requires no external dot1x client to install on clients OS. I’m having problems with DHCP, WinXP SP3/SP2 dot1x client don’t renew the ip address when auto-vlan assignement occurs. Switch vendor told me to set 1 minute dhcp lease on untrusted VLAN but I still have a 30sec of no net access between ethernet cable plug in and full network access, it’s a long long time… Any suggestion on how to fix it? It’s a shame that EAP and DHCP don’t work togheter on a operating system called “Professional”. 802.1x is a great technology but client bugs/annoyances make it not widely implemented.
    Roland