Cisco recently updated their flagship access control solution Identity Services Engine ISE label 1.1.1 or ISE 1.1MR (Maintenance Release). See more on ISE HERE. My team has received lots of questions around on-boarding new devices with ISE. This post will focus on this feature and assumes a standard ISE design is enabled for wireless access.
On-boarding simply means brining a new device onto the network for the first time. This process includes certificate enrollment and profile provisioning without involving IT as well as little interaction with the end user. ISE 1.1MR accomplishes these goals levering an existing Certificate Authority, user database such as Active Directory and ISE framework.
The ISE on-boarding process can vary however will be explained as having a new device connecting to a SSID specified for on-boarding new devices (can be open or secured with PEAP). Devices that connect to the on-boarding SSID will be redirected to a guest registration portal. The user will authenticate, which will trigger the certificate enrollment and profile provisioning process. Parameters to connect to the internal secure SSID will be included with the configuration profile that is provisioned to the mobile device post authentication. From that point on, the device will use the internal SSID for network access, which may have different ISE authorization rules depending on the design. Devices that fail to complete the on-boarding process will default to ether a guest SSID or be denied access depending on the desired policy.
WIRELESS: On-boarding can be designed many ways however for this post we will use two SSIDs called Provisioning_Wireless for new devices and Employee_Wireless for existing approved devices. An accesslist limiting access to ISE, DHCP and DNS will be enabled to prevent devices from staying on the provisioning SSID. A possible configuration for both SSIDS could be as follow
Attribute: Provisioning_Wireless / Employee_Wireless
Broadcast SSID: Enable / Enable
Layer2 Security: None / WPA+WPA2
MAC Filtering: Enable / Disabled
WPA+WPA2 Parameters: None / WPA2 Policy, AES, 802.1x
Layer 3 Security: None / None
AAA Server: ISE / ISE
Advanced: AAA Override Enabled / AAA Override Enabled
Advanced: NAC State – Radius NAC / NAC State – Radius NAC
To build this, go to WLANs > Create New > Go and fill out the profile details. Use NONE for the layer 2 settings so it’s OPEN. For AAA, set the Radius server for ISE. Under advanced, enabled Allow AAA Override and change the NAC state to Radius NAC. Go to Controller > General > Fast SSID change and enabled Fast SSID to help speed up the SSID changing.
ISE: (1) First in ISE setup Active Directory by going to Admin > External Identity Sources > Active Directory and join ISE to an AD system.
(2) Next go to Admin > External Identity Sources > Certificate Authentication Profile > ADD to define the certificate authentication profile (name it and choose Common Name for X509).
(3) Next define an Identity Source Sequence by going to Admin > Identity Source Sequences > Add. Give it a name, enabled and select the certification profile you just created then add AD for the authentication search list.
(4) Next configure ISE to act as a Simple Certificate Enrollment proxy server (SCEP). Go to Admin > Certificates > SCEP CA Profiles > Add. After defining your SCEP server, ISE will download the RA and root CA certificates of the CA server (this can be verified uner the certificate store via SYSTEM > Certificate > Certificate Store).
For this scenario, we will configure ISE authentication to use MAB for on-boarding new devices. It many cases, ISE will not know the MAC address in advance so it must be configured to continue the authentication process via redirection regardless.
This is done in ISE:
(1) Going to Policy > Authentication, choose your MAB wireless policy, click the carrot after allow protocols to show the user options and click the + sign for use.
(2) Select IF USERS NOT FOUND, CONTINUE. As a reminder, ISE Authentication policies are verified top down so make sure your MAB policy used for BYOD is at the top and open for all identity stores. You should lock down the 802.1x wireless to only wireless certificates.
Client provisioning is based on how ISE classifies the client machine. There are customized packages in ISE available that include a software-provisioning wizard, which configures 802.1x settings and ability to obtain digital certificates on the endpoint.
To download wizard packages in ISE, go to Policy Elements > Results > Client Provisioning > Resources > Add. Common mobile devices such as iOS typically have these settings enabled natively so a wizard is not needed.
To configure client provisioning in ISE:
(1) Go to Policy Elements > Results > Client Provisioning > Resources > Add.
(2) Create a native suppliant profile by giving it a name, selecting the Wireless Checkbox, your on-boarding SSID, WPA2 for security, TLS for allow protocals and key size 2048.
(3) Next go to Policy > Client > Provisioning to build your provisioning resources. Create one for native devices and select the mobile profile you just created for the results (example RULE = IOS, Identiy Group = Any, Operating systems MAC IOS ALL and your new mobile profile for results).
(4) Create another that is similar however use Android for the operating systems. Create a third for generic MacOsX devices and use the downloaded wizard. You may also want to create a separate one for Wired and Wireless. The same goes for two more to cover wireless and wired Windows devices. Here is an example of my Client Polices
The final steps are verifying profiling for wireless is working as well as your authorization profiles are setup for redirection, employee and guest access (see previous postings for these configs). These can vary depending on how you want to restrict devices that pass and fail your polices.
Written by Joseph Muniz and Aamir Lakhani
Reviewed by Aman Diwakar and Brian Trulove
waiting this post for long, so reply it before reading in detail.
Before this post, I’ve read here for some initial update.
http://www.cisco.com/en/US/docs/solutions/Enterprise/Borderless_Networks/Unified_Access/byoddg.html
I think what more important to network people is those non-network components like CA…
Hi Ning,
Yep I was briefed on the smart solution concept during Cisco Live. One of the key points about that is Cisco is now supporting the “complete solution”. This means if you open a TAC case and have Cisco Wireless, Access Control (ISE) and a MDM from their focus list (Zenprise, Airwatch, Good Technologies and Mobile Iron), TAC will troubleshoot the entire thing with the same case. For example, if people can’t get online and you call TAC, they will review the complete setup including the non Cisco MDM (as long as its one of those four) rather than open a new case or point the finger at the MDM regarding troubleshooting. This is a great play for those who hate vendors pointing blame for issues at other vendor gear as well as dealing with multiple TAC cases when different technologies don’t work together. The smart solution campaign is also releasing design guides supporting integration between these technologie areas. For example, ISE 1.2 will have a heavy focus on ISE interaction with MDM agents. The official support will be for the four MDM vendors mentioned however most likely will work for other MDMs.
Great article man, I have to say not what management would like to see deploying to 5000+ people lol in 100 remote sites.
Anyway a question about LEAP/PEAP.
I do not have CA server and I often get handshake error cuz clients didn’t accept the certificate ( they sometimes are not even asked to on win7)
Would it be bad to use LEAP as prefered method?
would a 3rd party certificate solve this?
Thanks