During the ISE installation you are asked to enter a username and a password for the super user account. Once entered, the ISE installation script adds an account for the ISE GUI and the CLI. However, these two accounts are not the same account, the installation script is merely creating one of each with same credential during the installation. Once added, you will have to manage them independently. Another difference between the accounts is that the CLI account is specific to each node, whereas the GUI admin account is replicated to the secondary nodes (Non primary admin node) in a distributed deployment. One frequent issue new ISE administrators run into is with password expiry and the lock out policy. The default password expiry is set to 45 days and the lock out timeout is for 15 minutes for both the CLI and the GUI. Imagine you are trying to troubleshoot the access issue and you can’t login to the UI due to lock out policy. To avoid surprises, adjust these settings as needed. Here are the default settings as of ISE 2.6 on the CLI:
Matching GUI admin settings can be located at Administration > System > Admin Access:
Authentication > Password Policy
Authentication > Account Disable Policy
Authentication > Lock/Suspend Settings
Few suggestions depending on your security policy:
Create alternate super admin account for both CLI and GUI
Use longer password expiry period than default
Use shorter lock out period than default
Lastly, in case you get locked out and need to reset the password for the admin account.
GUI: run 'application reset-passwd ise admin' from the exec mode CLI
CLI: Use ISE install ISO disk or image to boot the system and select option 3 or 4 which reads 'System Utilities' or 'Recover administrator password' depending on the version of the boot image and follow the steps.
ISE is shipped with most of best practices settings turned on by default. These settings ensure that ISE deployments can scale up to the specification. Some of the settings that are turned on by default are for suppressing repeated failed and repeated successful RADIUS requests. It is important to leave these settings on for any sizable deployment, but these settings could hamper visibility into the issues when you are trying to troubleshoot the initial ISE setup. For initial install, follow these steps so you have visibility into all the authentication requests that reaches ISE regardless of their status:
Go to Administration > System > Settings
On the left-hand-side of the screen, click Protocols > RADIUS
Check 'Disclose invalid usernames' (This setting reveals username for bad password events. Depending on the version of ISE and patch it may only be set temporarily)
Note: Once the initial pilot stage is complete and ISE policies have been validated, make sure to turn these settings back to default
Update ISE with latest profiler feed (AND posture update) to reduce unknown endpoint count
ISE releases or patches doesn’t come with latest profiler feed update. What this means is that newly introduced end points such as new iOS, Android devices or even Cisco AP may not get profiled properly upon installation. Now, ISE profiler feed is enabled by default to get updates around 1AM per configured timezone on the admin node so should help reduce unknown endpoints provided that ISE can reach Cisco services through the Internet. Make sure to allow ISE get access to the Internet so it can get latest feed updates. Aside from the feed update, ISE also relies on posture update for profiling when it comes to web browser user agent strings. Unlike feed service, posture update is not enabled by default. To configure the posture update behavior:
Go to Administration > System > Settings
On the left-hand-side of the screen, click Posture > Updates
Click Update Now to download user agent string database from Cisco. Note the version of the ‘Cisco supported OS version’ under Update Information pane below
You can also enable periodic update from here as well
Creating first policy set
Best policy is one that is easy to read. Don’t put all policy rules into single or default policy set, it will make the policy conditions complex and hard to read. Use following table as template and customize it for your environment.
ISE Live Logs page is where you will be spending most of your time within the ISE GUI. This is where all authentication events are presented in real time. There are 3 distinct status; Auth Passed, Auth Failed, and Session.
Auth Passed (Green check)
Some examples of such status: ISE sent back RADIUS ACCESS-ACCEPT as result of the policy, successful ISE WebAuth, successful CoA, successful PAC provisioning.
Auth Failed (Red X)
Some examples of such status: ISE sent back RADIUS ACCESS-REJECT as result of policy, failed ISE WebAuth, failed CoA, failed PAC provisioning, due to suppression settings, unknown NAD.
Session (Blue i)
Accompanied by ‘Auth Passed’ and it means in addition to Auth Passed, ISE received RADIUS Accounting Start. As ISE receives RADIUS accounting update for the session, the time for the session is updated via interim accounting update and the line item balloons up to the top of the Live Log.
Understanding ISE Live Sessions status
Operations > RADIUS > Live Sessions
While ISE Live Logs page provide events in real time, Live Sessions page can be used to view sessions that ISE is maintaining at given point in time. As noted in the ISE Live Logs section above, sessions are successful authentication event that ISE received RADIUS accounting Start for. You may be wondering what happens if ISE doesn’t receive RADIUS accounting start from the network device for a give session? Even if ISE doesn’t receive RADIUS accounting start, ISE will maintain it, but for shorter duration. ‘Started’ status means ISE received accompanying RADIUS accounting start whereas ‘Authenticated’ status means ISE received RADIUS authentication request that was successfully authenticated, but there was no RADIUS accounting start. For authentications with missing RADIUS accounting start, ISE only maintains session for 1 hour. When ISE isn’t maintaining the session, you end up with endpoints on the network but is not visible to ISE as connected endpoint as such ISE cannot send CoA which may break many of the advanced ISE use cases. Another case of ‘Authenticated’ is where ISE is configured with passive ID and/or Easy Connect. In these cases, ISE learned that a AD domain user was authenticated via WMI or AD agent but there were no RADIUS accounting received related to the same endpoint IP address. There are additional session status and following table summarizes the different session status:
ISE accepted the session, but did not receive accounting start. Aside from misconfiguration, typical reason to see Authenticated status is for RADIUS keepalive requests or passive ID without matching MAB/802.1X sessions. If no accounting start message is received, the session will be removed after 1 hour.
ISE received RADIUS accounting start. Unless posture is used, most of the sessions should show up as Started. ISE requires interim accounting message to be sent within 5 days, if not the session will be removed.
The endpoint has been posture checked and compliant using the AnyConnect posture module. This status is not applicable for temporal agent which shows up as 'Started' even when compliant.
Authenticating & Authorized
These are legacy status and should not show up on a properly configured ISE deployment.
ISE received RADIUS accounting stop. Terminated session will be removed from the table after 15 minutes.
Hi all,i'm facing some problems with DHCP snooping config. The scenario is the following. An IP phone is attached to the Catalyst 3650 switch. The switch has a SPAN port that has as source interface g1/0/46 (interface to which the phone is connected)...
Hello, has anybody made the experience that ODBC lookups might lead to "High Authentication Delay" on ISE PSN Nodes ? And has anybody a possible solutuion for that potential issue ? We have an ODBC connection to lookup MAC Addresses f...
Hi A server needs to install certificate for users access. I am not very clear about the process. Hope someone give some suggestion. Here are four steps for it. First is to generate a pair of key(private and publice) at the server. Second is to generate C...