02-22-2016 07:40 AM
Hey Guys,
Customer is building a new fresh ISE 2.0 (previous ISE 1.3) environment and are curious how BYOD clients will handle this migration. The new ISE environment will be fresh (new certs/config/IP's) but will connect to the same internal PKI/AD infrastructure. I would assume the only issue for BYOD clients would be the need to trust the new PSNs when they hit them since they have not seen that certificate before. Any other foreseen issues for these BYOD clients?
Solved! Go to Solution.
02-22-2016 04:45 PM
Found it. Thanks guys for all the help!!!
02-22-2016 08:22 AM
Shouldn't be an issue if you're using public certs for portals and as you've already called out, some clients will require the user to trust the new PSN the first time they see it. Other than that, shouldn't be an issue.
Regards,
-Tim
02-22-2016 09:35 AM
Thanks Tim. Customer is using Public certificates for the portals but internal CA for the EAP authentication so from the sounds of it should be good.
02-22-2016 08:24 AM
If the customer is using ISE internal CA, added in ISE 1.3, then we would need to export the Internal CA store from the old ISE 1.3 primary PAN and later import it to the new 2.0 deployment. ISE admin CLI "application configure ise", option 7 for export and option 8 for import.
If the EAP certificates of the new and old PSNs are signed by the same CA chain, authentications should continue to work.
If the customer also uses certificate renewal and has different admin certificates for the new and old PSNs, Apple iOS endpoints need remove the existing configuration profile manually and go through BYOD again during the renewal.
02-22-2016 09:37 AM
hslai can you elaborate on your last point? The admin certificates will be new and customer does have rules for certificate redirect to portal for expiring certificates. They are using their Microsoft CAs and not the internal ISE CA for handing out certificates.
02-22-2016 04:04 PM
Apple iOS devices do not allow installing another configuration profile with the same name if the payload is changed. The configuration profile on Apple iOS devices is signed by the admin certificate of ISE PSN, which authenticated and performed the BYOD, so that this admin certificate is part of the payload.
The workaround is to use a single wild-card of UCC certificate for all ISE PSNs for the same set of network devices.
02-22-2016 04:24 PM
Thanks so if I understand this correctly since this is a fresh environment will all new PSNs/Certificates only two options would be to delete old profile and re-enroll or change profile name. This will only affect them when they come to renew the certificate for Apple iOS devices correct?
02-22-2016 04:36 PM
That is about it.
As I recalled, ok to have two configuration profiles named differently but with the same Wi-Fi network ID. I've not recently tested it because we have been using the same name.
02-22-2016 04:43 PM
Thanks!!! I guess my only concern would be how iOS would prioritize profiles. If it kept trying to use the old profile ISE would redirect to client to the BYOD provisioning portal. Guess only option is really to delete that old profile. Interesting I have not seen this caveat called out in any documentation.
02-22-2016 04:45 PM
Found it. Thanks guys for all the help!!!
02-25-2016 09:21 AM
Hey guys one last question. Any way to migrate the registered endpoints? I don't think this has any effect on users authenticating since we are just checking the cert but obviously without it they would have no way to list a device as lost.
02-25-2016 01:20 PM
For endpoint group static assignments, we may use CSV export of endpoints from ISE 1.3 and then import to ISE 2.0.
If needing portalUser, then use ISE endpoint API from ISE ERS. The on-line doc @ https://<ISE-PPAN-IP-or-FQDN>:9060/ers/sdk will have more info, once ERS is enabled.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide