802.1x guest users created via Sponsor Portal

Cisco ISE has always included a way to create internal network users (Administration > Identity Management > Identities > Users) so ISE admins can create accounts for 802.1x authentication that do not require external authentication (ie Active Directory). This post covers a different way. Instead of using a Network Access Users account, we are going to create guest accounts via the sponsor portal that are allowed to authenticate using 802.1x.

Why would we want to do this? One use case is a lobby ambassador allowing secure access to a vendor that would have different employees come in to work on a system. You could create specific guest types to match the vendor and assign access (dACL, SGT, etc.) based on that guest type so they can access the equipment they are temporarily supporting.

The user we create in this post can access the wired network but it can easily be modified to allow wireless only or wired and wireless 802.1x access. Once the example user authenticates to the network, we are assigning a dACL that grants access to DHCP, DNS, and the Internet while denying access to the local network.

  1. Create an endpoint group to assign the sponsored user endpoints.

    Administration > Identity Management > Groups > Endpoint Identity Groups

    Here, I’ve created a parent group (Dot1x_Guest) with two child groups (wired and wireless). These will be assigned to the guest user type.
    Endpoint Groups
    Note that this is used in the next step but the endpoints will only be assigned to it if you force the user through a guest portal to accept an AUP. Otherwise, the endpoint is assigned to whatever group it is profiled as.

  2. Create the group type the sponsor will assign to the user’s account.

    Work Centers > Guest Access > Portals & Components > Guest Types

    I named this one Wired_Dot1x_Guest to match the endpoint group. The two main settings I changed are Endpoint identity group for guest device registration and Allow guest to bypass the Guest portal.

    Guest Type Settings
    The endpoint group is so we can place the MAC address into a group which can be used in an authorization rule and/or a purge rule. Allowing a guest to bypass the guest portals prevents them from having to accept an AUP before gaining network access. This is useful for 802.1x and VPN authentications. You can, of course, create additional rules to require them to go through a web portal after successfully authenticating if you want to.

  3. A new identity source sequence needs to be created to allow the guest database to be used in the authentication rule for the wired 802.1x policy set.

    Administration > Identity Management > Identity Source Sequences

    I could use the default Guest_Portal_Sequence but I don’t need internal users. I like to leave the defaults for reference and create what I need. I named it Guest_AD so I know exactly what it’s for, added Guest Users and SecurityDemo (my AD join point) to the Authentication Source List, and set the Advanced Search List Settings to continue to the next store in the sequence if they aren’t found in the first store.

    Guest and AD ID source sequence

  4. A dACL that will be assigned to an authorization profile is created.

    Policy > Policy Elements > Results > Authorization > Downloadable ACLs

    The dACL will allow DHCP, DNS, and Internet access. It will deny access to all private networks.

    dACL to only allow DHCP, DNS, and Internet access

  5. The authorization profile to be used in an authorization rule is created.

    Policy > Policy Elements > Results > Authorization > Authorization Profiles

    The only setting configured here is assigning the Internet_Only dACL.
    Wired guest user Internet only authorization profile

  6. The policy set configuration is pretty straightforward. I am using an existing policy set that is configured for handling Wired 802.1x. The Authentication Policy is configured to use the identity sequence that was created above.

    Guest and AD authentication policy
    The Authorization Policy is configured to use the guest user type as a condition and the Internet only policy result created previously.

    Wired 802.1x guest user authorization

  7. Now that we have an endpoint group, a guest user type, and the policy created, we can create a guest user. Navigate to Work Centers > Guest Access > Manage Accounts > Managed Accounts or your sponsor portal FQDN. Under the Create Accounts tab, the Guest type dropdown should contain the guest type that was created above.

    Sponsor portal create guest userFill in the guest user information, click create, and the user will be created with the settings assigned to the Wired_Dot1x_Guest guest type. One thing you will notice is that the state of the guest account will immediately be set to Active. This is because of the setting on the guest type allowing them to bypass the guest portal.

    Guest example

Time to test! I connected my Macbook* to the switch. I was immediately prompted for my login credentials. After putting in the test user account information, I checked the RADIUS Live Logs (Operations > RADIUS > Live Logs) and saw where the account was successfully authenticated with the correct authorization policy.

RADIUS live logs showing successful 802.1x guest access

Checking the access session on the port shows that dot1x authentication was successful and the dACL was applied correctly.

CLI showing the access session information

Was traffic being enforced? I tested DNS resolution and then pinging my ISE node.

CLI showing dACL enforcement

As you can see, DNS worked properly and access to the private network (172.16.0.0/12) was blocked. I was able to browse the Internet without issue.

*Note: Windows systems do not have wired auto config enabled by default. This service is required if they want to do 802.1x wired connections.

Share this post:

2 comments

  1. So this does not require guest users go through the guest portal according to your configuration.
    However, guest endpoint have to enable wired auto config (dot1x) to allow authentication.

    1. Yes, that is correct. Mac OSX and Linux already have 802.1x enabled for wired and wireless connections. Windows only has wireless 802.1x enabled by default. That’s why you must enable the Wired Autoconfig service in order to authenticate Windows devices on a wired 802.1x network. It’s a little different than a standard 802.1x deployment because those are normally domain devices that can be configured via GPO. No change required if you do this configuration on a wireless network (802.1x default enabled).

Leave a Reply

Your email address will not be published. Required fields are marked *