ISE Wired & Wireless 802.1x Authentication

In its simplest form you can add the AD Join Point to the guest identity source sequence and it will enable AD users to log in via the same portal, so you can use the same SSID also. This enables users to register their device against their username so you can remember the MAC of the device and authenticate/authorise subsequent connections to the SSID using the registered MAC, rather than throwing a portal at employees each time they connect. 


Alternatively you can use a different SSID and use PEAP so AD users can just use their AD user/pass on any device. Most people prefer that. The brute-force risk is small via guest-portal as it is rate-limited by default. 

Select allOpen in new window

In fact, our intention is to exclusively transmit three SSIDs:

"Corp" - utilizing 802.1x authentication with EAP-Chaining.

"Guest" - employing a Self-Registered Captive Portal.

"IOT" - configured with iPSK and MAB authentication, associated with a designated group of devices and linked to their corresponding VLANs.

We would rather avoid create and broadcast an additional SSID exclusively for Employee Internet Access. Is there a method to accommodate this need within Guest SSID above while still allowing us to create ISE authorization policies accordingly?

Please excuse my ignorance, employees will need use Guest Portal for their initial login and use their AD credentials. After successful login, they should register their device by providing its MAC address. When they reconnect next time, they will just associate with the SSID, and access will be granted. 

However, malicious users might attempt repeated invalid logins in an attempt to brute force their way in whether using portal or PEAP.

I believe, as you previously suggested, instead of granting portal access to employees, we could simple fire up a new SSID for both employees and visitors/contractors.

For employees they can just simply put AD user and password after associating with SSID.

For contractors, we can create users on internal database of ISE

What authentication methods is suitable in such scenarios m?

PEAP is the one to use. It can be used by any device with no configuration. Just connect and the device will prompt for a user/pass. You would need to obtain an EAP cert from a well-known public CA to install on the PSNs though.

Thank you Sir

Is it secure enough and better than portal?

It's secure enough if you're not allowing access to corporate resources, or limited resources. It's actually no better than the portal in most respects, other than there's less parts to it so slightly more reliable. In terms of secure authentication though, it's probably less secure than the portal because PEAP allows for an unvalidated server to be used, whereas the guest portal uses a digital certificate to build the HTTPS connection, and that has to be validated via the chain.

it's probably less secure than the portal because PEAP allows for an unvalidated server to be used, whereas the guest portal uses a digital certificate to build the HTTPS connection, and that has to be validated via the chain. 

Select allOpen in new window

I apologize in advance, but the statement is a bit unclear to me.  Server's identity may not be thoroughly checked during the authentication process when using PEAP. 

To break it down further, when a user enters their credentials, the authenticator (which could be a Wireless LAN Controller or Access Point in our case) forwards the request to ISE. ISE then examine whether the connection is from an XYZ SSID and subsequently checks the Identity Stores. If it's and user, they will be authenticated by AD. For visitors, ISE will verify and authenticate against internal stores. 

I apologize in advance, but the statement is a bit unclear to me.  Server's identity may not be thoroughly checked during the authentication process when using PEAP.  

Correct. That is one reason why it is preferred to use EAP-TLS - validation is mutual, so server has to validate client cert and client has to validate server cert. With PEAP you can disable server cert checking so the client will just build the tunnel regardless of what is on the other end.

To break it down further, when a user enters their credentials, the authenticator (which could be a Wireless LAN Controller or Access Point in our case) forwards the request to ISE.

Correct again. It will be the WLC in your case.

 ISE then examine whether the connection is from an XYZ SSID and subsequently checks the Identity Stores. If it's and user, they will be authenticated by AD. For visitors, ISE will verify and authenticate against internal stores.

If that's how you've configured your ruleset and conditions, yes.

Super clear.

This enables users to register their device against their username so you can remember the MAC of the device and authenticate/authorise subsequent connections to the SSID using the registered MAC, rather than throwing a portal at employees each time they connect. 

Select allOpen in new window

We would create another SSID for employees with captive portal and apply the registered MAC approach.

However, I'm a bit uncertain about authentication and authorization policies. Is it feasible for you to generate a sample policy within your lab's ISE and then share it with me? I would greatly appreciate it.

We would create another SSID for employees with captive portal and apply the registered MAC approach.

No. You can use the same portal. ISE knows it's an employee because an AD username was used.

There's a common misconception that you need different SSIDs for different levels of network access. That's not really true as you can use AAA-Override to send different attributes based on who/what/where, etc. The difference in SSID is purely to use different authentication methods over the air (so PSK, 802.1X, Portal, etc.). Usually one SSID for each type is enough if your RADIUS is able to enforce policy like ISE can.

I can do something quickly. It depends on what you want though. Are you after a single policy that uses different rules for corporate SSID, guest SSID and BYOD SSID, or do you want guest and BYOD combined? 

We don’t do BYOD.

We don’t allow personal devices to connect and access corporate resources. We just want to give them internet access

I prefer separate rules for corporate and guest SSiDs.

Secondly,  wast thinking to keep separate SSIDs for Guest and Employees and different portals just seperate traffic since employee will authenticate using AD credentials

This is just my assumptions

Your expertise advise will be valuable 

Thank you very very much. 

I truly value your help and support. There's no one else who provides support quite like you do.

Last query on this thread, how can I configure the authorization policy so that after successful authentication, employees are placed in different VLANs from those used by public guests?

Look at the picture…

Employee WiFi has a different result. That is an authorisation profile. The profile has a different VLAN ID configured.

I am sorry. I thought the profile just a DACL to restrict the traffic to corporate network.

Thank you for clarifying.

You can implement dACLs. They too are configured within the authorisation profile. You can combine multiple attributes in one authorisation profile, or you can add multiple authorisation profiles to the rule.

Just one last query on this thread:

How we can configure ISE captive portal to initially show a choice between guests and employees. Depending on what the user selects, it will then follow the appropriate workflow for authentication and authorization?

You can't. But as I've said a few times, you don't need to. A single portal is just the front-door so you can still authorise employees one way and guests another using the same portal.

The only way to force a different portal is to use a different SSID.