Moving from other guest/database systems to ISE
For those who are still running ACS, NGS or old systems and want to integrate ISE for guest into the environment here are some options available to you:
Option 1 - Create a separate WLAN (SSID) for new guests
This option creates a separate WLAN for the new ISE guests to use. This new network will be for all new guest accounts. Sponsors and guests will be required to use the corresponding WLAN and new Sponsor Portal. This is an easy approach that doesn't require any special config on NGS or ISE and allows you to have a smooth transition with little overhead
- WLAN1 - NGSGuest
- WLAN2 - ISEGuest (NEW)
The old sponsor portal should reference the new policy or even be blocked access to create accounts and redirect to the new sponsor portal. Once all the old accounts have expired then shutdown NGS and corresponding WLAN.
- Pros - simple!
- Cons
- requires 2 WLANs
- NGS running until the old accounts expires
Option 2 - Point ISE to other system as a RADIUS Token Server
This option points ISE to NGS as a RADIUS token server. Any new accounts will be created on the ISE Sponsor Portal. Old and new guests will use the same WLAN. This approach is more complex but does allow a smooth transition. The old sponsor portal should reference the new policy or even be blocked access to create accounts and redirect to the new sponsor portal. Once all the old accounts have expired then shutdown NGS.
- Pros - single SSID
- Cons
- increased complexity
- NGS still alive until all accounts expire
- potential collision on the user account names, be aware of old/new policy creating accounts
Attached is a document by erieddy on how to configure ISE 1.2 to work with NGS 2.0.5, use as a reference for your ISE deployment.
Option 3 - Export account from other system and import into ISE
The idea here is to export the guest accounts from NGS or other system and import them into ISE. This not really an option but in case you were wondering about this approach here it is already vetted! 
- Pros
- Single WLAN
- Other system removed from the environment
- Single Migration effort
- Cons
- Complex scripting export/import issues (lots of overhead)
- lots of overhead and work!
- ISE API cannot set the password of the account, its randomly generated
- special scripting to match sponsor to guest (ISE authenticates API as the sponsor so the guest is attached to that API call) would need to authenticate depending on the sponsor to match up respective guests
- Other notes
- If they don’t want to use multiple sponsor accounts when migrating from NGS then we could use the same sponsor for all migrations and set an optional data field as originally created in NGS by Sponsor, imported via API. This would solve audit issues and also solve security risks of needing multiple accounts or giving sponsors access to All accounts just to see them, this way a special sponsor group could be setup for old accounts that were migrated perhaps.
- Setting the sponsor is done with the API authenticates for guest account creation, this could be any sponsor account so will need to get the sponsor info on export and then call the API on creation when moving the account to ISE, problem here as we can’t get the sponsors password (which is understandable)
- Set validity date range on the account. We can load these accounts in with the same expiration dates as existing NGS accounts. However, the time profile on these accounts will have to be set to the type of StartEnd. If the time profile is set with FromFirstLogin or FromCreation, ISE overrides the dates submitted by API.