ISE 2.0 - Guest Policy — Networking fun

In this post, I'm going to create my guest wireless policy. Guest access is typically what you think of when you visit a company, connect to the wireless and then get a splash page to enter some sort of credentials you were either provided or you self-register to get your own credentials. I'm going to create a basic guest wireless policy and I'll walk you through some of the different options you can use with this policy if you want to play around with this in your own lab or you're looking to deploy this in your production network.

Note: You do need to have a separate SSID for MAB and dot1x. The reason for this is that there are certain limitations on wireless where you cannot use dot1x and MAB at the same time on the same SSID so if you need to do profiling, you could always put it on the same SSID as Guest if you wish. Be aware of this limitation in production instead of trying to troubleshoot a flow that can't work.

To start, I'm going to navigate to Guest Access>Configure>Guest Portals>Sponsor Guest Portal (Default) and choose to edit it.

Note: As stated in previous posts, you can just clone the portal and configure that if you don't want to change the default.

Before I configure anything, I'm going to go through some of the options and settings under this page.

Under the Portal Settings section, this is where we can change the following:

HTTPS port that ISE uses for the Guest Portal. I usually keep this at 8443 but if you do decide to change it, remember to change it in your ISE-ONLY ACLs if you're locking down ports
Certificate Group Tag - This is to specify the certificate used for this portal. I usually recommend using a certificate signed by a public CA to avoid any pesky certificate warnings in the end-user's browser
Authentication Method - This is the Identity Source Sequence that we'll be using for this portal
Employees using this portal as guests - This is where we specify what role the guests will inherit their login options from
Display language - Pretty self explanatory

The next section is the Login Page Settings:

Require an access code - I don't typically see this on Guest Portals as much as Hotspot pages. Basically, if the user is to be able to continue with the onboarding, they have to have the access code you specify here. This might be useful for Hotspot access but if you're using a guest portal, it just makes more sense to use sponsor access instead of a pre-shared access code
Include AUP - You can add a AUP here as well as where you want to specify it and if you want to have a guest accept it on order to proceed
Allow guests to create their own accounts - You would check this selection if you want your guests to have the ability to self-register their own accounts
Allow guests to change passwords after login - You would check this option if you want to allow guests to change the password that ISE assigns them. It's probably a good idea to check this and modify the password requirements if you have guests that will be onsite for long periods of time

The section for Acceptable Use Policy (AUP) Page Settings on this page is pretty self-explanatory. It's just providing you with some additional options for AUP which might be required depending on the legal requirements of your organization:

For the Guest Change Password Settings section, you can check this box if you want to require you guests to change their passwords when they first login:

For Guest Device Registration Settings, there are only a couple options on this section:

Automatically register guest devices - This means that ISE will automatically create an endpoint for the device from which the guest is connecting with and the endpoint will be added to the endpoint identity group specified for this point. If you plan on posturing the endpoint every time it connects, you might not want to check this box.
Allow guests to register devices - This is an option to allow registered guests to register new devices to your network. You can configure a maximum number of devices each user can register if you do choose this option

On the section for BYOD Settings, you would configure this if you don't want to create a separate policy for BYOD or you want to lock down the BYOD policy to allow only certain devices for corp access and allow your employees to login to guest with the rest of their endpoints. The options here are pretty self-explanatory:

The Guest Device Compliance Settings section would be checked if you want to create a posture policy and enforce it on you guest access:

The Post-Login Banner Page Settings is if you want to enable having a post-login banner page:

The VLAN DHCP Release Page Settings section will be used if you want to enable the release and renewal of the guest device IP address:

The Authentication Success Settings section is where you can define where the endpoint is directed after authentication is successful:

The Support Information Page Settings section is if you want to include a Support Information page for your help desk to use so they can troubleshoot access issues experienced by your guests:

On the right-hand side of the page, you can see your Guest Flow. This will change dynamically to reflect the flow as you make changes to the setting (i.e. adding a AUP page, removing a post login banner page, etc):

For my guest portal, I'm going to uncheck the box for Allow Guests to create their own accounts since I want to require a sponsor to register my guests:

I'm also going to include an AUP page:

I'm not going to allow my employees to login to the guest portal since I have a BYOD policy that I would like them to use:

After I've completed this, I'll click Save to save my changes.

I'm going to walk through some different ways you can customize your guest access. If I navigate to Guest Access>Configure>Guest Types, I can configure the types of guests I can create or use:

If I edit one of these guest types, I can actually change a lot of different options for this guest type:

Maximum allowed time on my network
Limit them to login on certain days or windows of time
Limit the amount of simultaneous logins and the maximum amount of devices they can register on my network
Define the endpoint identity group their devices will be added to after they register it
How often the endpoints are purged from this identity group
Whether or not the guest can bypass the Guest portal in future logins
Choose to and specify the methods ISE will notify the user if their account will soon expire
Specify the sponsor group that can create this guest type

I can also specify different options for my sponsor groups and define them by navigating to Guest Access>Configure>Sponsor Groups:

To keep things simple, I'm just going to edit the ALL_ACCOUNTS (Default) group. This is where I define the group of individuals who can have the sponsor portal access to create accounts. In my lab, I'm just going to allow all domain users to create guest accounts. I'm going to click on Members and remove the ALL_ACCOUNTS default and add the following AD group: ad1:securitydemo.net/Users/Domain Users:

On this page, we can also specify or customize the following settings:

What kind of guest types this sponsor group can create
What locations this sponsor group can create guest accounts for
If the sponsor can create a bulk amount of guest accounts and how they are assigned
Whether the sponsor can manage all guest accounts or a specific subset
What access and modifications a sponsor has control over in regards to the guest accounts

In my lab, I'm going to allow this group to create access for all guests in my pre-defined "San Jose" location and click Save.

I'm going to modify the Sponsor Portal next. This is the portal that our sponsors login to create guest access. To modify this, I'll navigate to Guest Access>Configure>Sponsor Portals and edit the default sponsor portal. I'm not going to really change much in this page except add a FQDN for the ease of use for my sponsors to connect to this. I've already created a DNS entry to sponsor.securitydemo.net on my AD server:

The rest of the settings on this page are pretty self-explanatory and were covered in the guest portal options so I won't get repetitive. After I've finished with adding the FQDN, I'll click Save.

The next thing I'll go over is the different global guest settings I can configure on top of what I've already configured specifically for certain guest portals or guest types. If I navigate to Guest Access>Settings>Guest Account Purge Policy, I can schedule when guest accounts will be purged or perform a manual purge:

On the Guest Access>Settings>Custom Fields, I can define custom fields that can be used as part of our Guest or Sponsor portal. For example, let's say you want to require sponsors to check guest's ID before giving them a guest account. You could create a custom field to make them acknowledge that they did so or add a custom field to have them enter the last four digits of the user's drivers license number. You would define the string here to add to your portal settings.

On the Guest Access>Settings>Guest Email Settings page, I can define whether or not to enable email notifications to guest and from which email address to send notifications from:

On the Guest Access>Settings>Guest Locations and SSIDs page, I can define different locations and SSIDs if I want to limit my sponsors to specific SSIDs or locations. I created a San Jose location in my lab and defined my guest SSID. One thing to note: I would HIGHLY recommend changing the time zone of your locations to whatever your global ISE timezone is on the NTP settings. The reason for this is that during guest account creation, I've seen ISE default to the global timezone and if I had PST defined for my location, my guest account wasn't enabled until I either changed the start time of the guest account or PST hit that time. I would just say as a best practice, keep your time zone the same throughout your entire ISE deployment:

Under the Guest Access>Settings>Guest Username Policy page, I can define how usernames are automatically created to make it a little more initiative for guests:

On the Guest Access>Settings>Guest Password Policy, I can define how long the passwords are, what characters are allowed, whether or not they expire and when they should expire. My recommendation is to use a combination of upper and lowercase and numeric with a minimum password length of 8. These passwords are auto-generated when guest accounts are being created so if you make them too long or add special characters in there, you might get some crazy passwords that are hard for your guests to enter in on their devices. Ultimately, it's up to you on how much you want to balance security with ease of use:

Now that I've gone through the various settings, I'm going to create my network element. Since we're already created the WLC ACLs in our previous blog posts, I'm going to start with creating just one DACL. On the Policy>Policy Elements>Results>Authorization>Downloadable ACLs page, I will click Add and create the following DACL:

Name: INTERNET-ONLY
ACL:
permit udp any eq bootpc any eq bootps
permit udp any any eq domain
permit ip any host 10.1.100.21
deny ip any 10.0.0.0 255.0.0.0
deny ip any 172.16.0.0 255.240.0.0
deny ip any 192.168.0.0 255.255.0.0
permit ip any any

I then need to create my authorization profiles on the Policy>Policy Elements>Results>Authorization>Authorization Profiles page. I'll create the following authorization profiles:

Name: GUEST-REDIRECT

Check VLAN and enter VLAN ID 70
Check the box for Web Redirection, choose Centralized Web Auth, and type in GUEST-REDIRECT for the ACL value, and choose Guest Portal from the drop-down

Name: GUEST-ACCESS

Check DACL Name and choose GUEST from the drop-down
Check VLAN and enter VLAN ID 70
Check the box next to Airespace ACL Name and type in GUEST

Now that I've created those policy elements, I can create my policy on the Policy>Policy Sets page. On this page, I'll need to create an entirely new policy set. I can put it above or below my existing policy sets - it doesn't really matter. For this policy set, I'm going to name it Guest Wireless and give it the following top-level conditions:

DEVICE:Device Type EQUALS All Device Types#Wireless Controller
AND
Radius:Called-Station-ID ENDS WITH SecurityLabGuest

This top-level condition basically tells ISE to use this policy set if the request is coming from the wireless controller and the SSID is SecurityLabGuest

Under the Authentication Policy on this policy set and create the following rule:

Name: MAB
If: Wireless_MAB <- this is pre-created condition in ISE
Allowed Protocols: Default Network Access
Default: Internal Endpoints <- Under If user not found, choose Continue from the drop-down

On the Default Rule of the Authentication Policy, I just use the All_User_ID_Stores identity source sequence:

Under the Authorization Policy, I will create the following rules:

Name: Guest Access
If: GuestEndpoints <- Predefined ISE group
Conditon(s): <blank>
Then: GUEST-ACCESS

Name: Guest Redirect
If: Any
Condition(s): Wireless_MAB <- Predefined ISE group
Then: GUEST-REDIRECT

Then I will change the Default rule to DenyAccess at the end:

In it's final form, my policy set will look like this:

After saving my policy set, I can test out my guest with another test device and have my moment of truth when I go to Operations>RADIUS Livelog and see the following when I connect to my guest SSID:

I can either go to https://sponsor.securitydemo.net or navigate to Guest Access>Manage Accounts to create a guest account. After creating an account and logging in on my test device, I should see my success in the RADIUS Livelog:

Huzzah! We now have guest access up and running for wireless but what if we want to add it to our wired access as well to protect our ports? Actually, it's pretty simple to add it at this point. If I navigate back to my policy sets at Policy>Policy Sets, I would need to modify my existing Wired policy set. The only thing I would need to add is two rules in the Authorization policy at the very end before the Default rule. The rules I would create are:

Name: Guest Access
If: GuestEndpoints
Condition(s): <none>
Then: GUEST-ACCESS

Name: Guest Redirect
If: <any>
Condition(s): Wired_MAB
Then: GUEST-REDIRECT

In terms of order, it would look like this on my Authorization Policy:

Note: Alternatively, I could also just have the default rule as GUEST-REDIRECT. Either way is just as effective and most of the time you would be putting it as the default rule in production but since this is a lab where I frequently test different rules, I created a standalone rule so I can disabled and re-enable it as needed in the future. Another thing to note is that either way you do it, this will not interfere with my future profiling policies because of where it is ordered on my Authorization Policy. These rules simply will act as a "catch-all" if nothing is matched above so when we create profiling authorization rules in the future, we just need to make sure they are positioned above the Guest Redirect rule in the Authorization Policy.

After saving my changes to this policy set, I can test it out by connecting a non-dot1x PC to a port in my switch and check Operations>RADIUS Livelog to show that my computer is hitting the GUEST-REDIRECT Authorization Profile instead of the Default of DenyAccess:

After signing into the guest portal, you'll see your authorization profile change:

On the actual switch itself, you can see the authentication session by issuing the show authentication session interface type/mod detail command:

From the above output, I can see the following:

MAC Address
IPv4 Address assigned to the endpoint
Username - Since this is MAB, it will be the MAC address
Status - Authorized since it matched the Guest Redirect rule in our Authorization Policy
Common Session ID - This is the session ID for this particular sesssion between the NAD and this endpoint. This is useful for troubleshooting in ISE if you need to
Local policies - These are the existing policies we've created on the switch/port
Server Policies - This is based on the authorization profile that ISE is using for this endpoint. As you can see, it's using the ISE-ONLY ACL. This is NOT a downloadable ACL. This is an ACL we created on the switch during our switch configuration post.
URL Redirect - This is the redirect URL that ISE uses for this specific session. If you notice, the session ID is part of the URL
Method Status List - Here you can see that it failed dot1x and succeed under MAB. This is a good place to troubleshoot when you have failures

After signing into the guest portal and gaining access, I'll see a very different output when I issue the show authentication session command again:

This time, you will see that a DACL was downloaded since it now shows an ACS ACL and you can see which DACL it was. If you issue the show access-list command, you'll also see the ACL in detail there. As far as the VLAN is concerned, the authorization profile specified VLAN 70 but since the port was already configured as switchport access vlan 70, there was no need to change the VLAN.

To give you an idea of what the sponsor portal process looks like for the sponsor: