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.
- 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.
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.
- 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.
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.
- 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.
- 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.
- The authorization profile to be used in an authorization rule is created.
Policy > Policy Elements > Results > Authorization > Authorization Profiles
- 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.
- 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.
Fill 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.
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.
Checking the access session on the port shows that dot1x authentication was successful and the dACL was applied correctly.
Was traffic being enforced? I tested DNS resolution and then pinging my ISE node.
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.