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 only setting configured here is assigning the Internet_Only dACL.
- 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.
The Authorization Policy is configured to use the guest user type as a condition and the Internet only policy result created previously. - 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 utilize 802.1x wired connections.
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.
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).
Hi, interesting post. We’re also looking into this. I’m not an expert on ISE so I have a few questions about the AD connection with regard to guest account creation using the sponsor portal. Using the identity sequence created in step 3 it is possible to use the sponsor portal to create quest accounts in the AD referenced in the identity sequence instead of creating them locally on ISE?
I don’t understand how the sponsorportal is connected to the external identity source as the new identity sequence only is connected to the authorization rule.
Lastly, would an ldap connection be able to do the same?
You wouldn’t create the guest account in AD/LDAP using the Sponsor Portal. The sponsor portal only creates accounts in the local guest database. If you want to use AD accounts, you would need to create the account there and the authorization rule will need to include a condition that identifies the guest account (ie external group equals Guests). The authentication policy is already configured to use both the internal guest database and the AD source but you would need to change that if using LDAP to allow the lookup.
Hi,
this is a great solution and it works very well, but i have a problem. The Clients rejects the server certificate. The certificate is public signed.
Do you have an idea how to fix this?
I think you misspelled the word “manny” on your website. If you want to keep errors off of your site we’ve successfully used a tool like SpellPros.com in the past for our websites. A nice customer pointed out our mistakes so I’m just paying it forward :).
I noticed this post a few years back but recently we had a requirement to setup a guest wifi network based on WPA2 enterprise. I used the setup as described above and it works perfectly with one exception. The AUP cannot be used anymore as this is part of the guest portal.
So I was wondering if it is possible to use a hotspot guest portal just to accept the AUP after connecting to the WiFi network using WPA2 enterprise?
Not sure if the “guest-flow” within ISE will be able to connect the dot1x session to the hotspot portal session after accepting the AUP.
Any thoughts?
Great article.
I have a fairly stupid but very valid question, I created a Sponsor Portal and I can create eg 20 Random users, I can’t seem to figure out or find out where these users are kept on ISE. I know the Endpoints will be in a specified Guest Endpoint database.
Where are the Random Users, I hope to use them in an Authorisation policy.
They are in the guest database which is not to be confused with internal users.
1S3AX0HP https://dzen.ru sgjvhnbtcbstfgdjgfbs