Saturday, August 21, 2010

Scalable Guest Account Provisioning

One question that always seems to come up when discussing guest wireless access is the problem of account management. Many smaller organizations are looking to implement guest connectivity solutions but struggle with the administrative overhead of managing accounts for potentially very large amounts of guests. Typically, these responsibilities are delegated to the help desk department, since architects and engineers shouldn't be performing these tasks.

Let's face it, for most organizations the staff members placed on the help desk are either just beginning their careers and are fairly inexperienced, are tinkerers with technology but not really IT professionals, or have been placed on the help desk from some other completely unrelated department since they just weren't working out in their previous position (I've seen some horrible cases of this in the education sector).

Three options exist with the Cisco Unified architecture to manage guests, depending on the scalability required as well as the technical proficiency of help desk staff.

1.) Controller Lobby Admin
This is the most basic solution, which is not really scalable, but may fit for a very small organization that doesn't require high availability and failover. The anchor controller can store local usernames and passwords for guest accounts right on the network hardware itself. The help desk staff login directly to the wireless controller (... that just sent shivers down my neck typing it!) and provision guest accounts. Help desk staff can be limited to guest account creation only (highly advisable) by assigning them the lobby admin role, either with a local account or through TACACS+ or RADIUS.

2.) WCS Lobby Ambassador
This is one option to begin scaling the solution for mid-size organizations. If multiple anchor controllers exist for redundancy, possibly in different data centers, a method to provision accounts on all of the anchor controllers simultaneously should be implemented. Otherwise, help desk staff would need to login to each and every anchor controller to create the same guest account. OUCH! And let's not even mention possible user-error when creating multiple copies of the same account.

With this method, help desk staff are assigned a lobby ambassador role on the WCS server, again either locally on the WCS server or through TACACS+ or RADIUS. This has the benefit of not requiring help desk staff to login directly to the network equipment (YEAH!). They simply login to the WCS server, create the guest account once, and push the configuration template to the appropriate anchor controllers.

Notice how I stated the appropriate anchor controllers? This is one of the key drawbacks of this method. You have to rely on the help desk staff to be able to select the correct controllers to push the guest account configuration to. This leaves the window open for configuration mistakes, with guest accounts pushed to other production controllers. 

Also, help desk staff are required to create a controller template for each guest user, which is definitely not an intuitive procedure.

3.) NAC Guest Server
This is the big kahuna of guest account management. These appliances can handle administrative roles through local user account, active directory integration, LDAP, or RADIUS. Guest account settings can be emailed or an SMS message can be sent to them. It acts as a RADIUS server for user authentication from the controllers. Best of all, your help desk staff does not need to login to any system related to network operation or control. The help desk staff could even be completely taken out of the picture if guest account provisioning is delegated to authorized employees in your network.

Scalability is in full force with this solution. Multiple anchor controllers can be deployed, and simply point guest authentication to the NAC guest server(s) via RADIUS. Simple, familiar, and reduces the opportunity for user-error.

If you're a large organization looking to roll out scalable wireless (or wired) guest access, check out this appliance on Cisco's website. From personal experience, it rocks!

- Andrew


  1. Andrew,

    Great post on the different approaches in handling guests in a Cisco Unified WiFi network. That NAC Guest Server solution is new to me.


  2. Hi Andrew,

    Nice post on how to manage user account, but i have one question plz:

    I have a design with Anchor WLC in DMZ to authorize guest user to access to the internet. I have two LDAP databases to authenticate the user: one for guest user and the other for sponsor user (the employee). Is it possible that the Anchor WLC verify the first DB, if the user is not in the first, he verify the second DB ?
    to clarify the question: in my case, it may happens that a sponsor user must connect to the guest WLAN, in this case he should use his login/pwd in the second DB to access.

  3. Hi Lazhar,
    In order to accomplish what you are trying to do, lookup users from two different databases on the same SSID, you will need to use a RADIUS server that supports both backend databases. Configure the RADIUS server to lookup users in both, and set the priority order for user lookup. You will also need to set the action taken when the user is not found in the first database to check subsequent databases in the list, rather than failing the authentication.


  4. Hi Andrew,

    many thanks for your answer,

    best regards,

  5. Cisco's approach towards this important deployment issue is such a lame and half baked, it needs a lots of improvements. We are trying to make some headway using Cisco WCS only, and it is already a becoming a headache. Cannot allow everybody to create accounts, as template is not very customizable, limiting to few users makes it to loose its usefulness. Also even cannot thing of Cisco NAC Guest server as they are offering a lot of other options down the line...stalemate for now i guess.