ISE admin CLI and GUI account
Introduction
During the installation of a Cisco ISE node, whether virtualized or running on a physical SNS appliance, an initial administrator account must be created. This account is then used to generate two separate user identities: one for Command Line Interface (CLI) access and one for Graphical User Interface (GUI) access. These accounts enable administrators to manage the ISE environment.
The GUI account provides access to the web interface, offering a comprehensive overview of the cluster configuration, while the CLI account is primarily used to access ISE nodes via SSH, a feature enabled during the initial setup. Initially, both accounts share the same credentials, allowing administrators to authenticate to both interfaces using the same username and password.
service sshd enable.Cisco ISE employs a Role-Based Access Control (RBAC) model to categorize administrative users based on the scope and visibility required for their tasks. For both access methods, it is possible to define, with varying levels of granularity, which commands or menus a user can access and which data they are permitted to view. The default administrator accounts are assigned to two distinct roles: the CLI account is associated with the Admin role, while the GUI account belongs to the Super Admin group. As observed, the type of account varies depending on the access method. The CLI supports only two roles, whereas the GUI offers a broader set of roles, including the ability to create custom ones.
CLI Access
The Cisco ISE CLI admin account grants elevated privileges, enabling administrators to perform critical system-level tasks such as:
- Start and stop the Cisco ISE application
- Apply software patches and upgrades
- Reload or shut down the Cisco ISE appliance
- View all system and application logs
When logged in using an admin account, a wide variety of commands is available, as illustrated in the example below:
ISE-NODE-2/adminCLI#?
Possible completions:
application Application Install and Administration
backup Backup system
backup-logs Backup system and application logs
clear Reset functions
clock Set the System Clock
configure cfg
copy Enter URL (use disk:/path/file for local) (Max Size - 2048)
crypto Crypto operations
debug Debugging functions (see also 'undebug')
delete Delete a file
dir List files on local filesystem
esr Enter the Embedded Services Router console
exit Exit the management session
forceout Force Logout all the sessions of a specific system user
generate-password Username for which password has to be generated
halt Shutdown the system
idle-timeout Idle timeout for all the sessions of a specific system user
license License operations
mkdir Create new directory
nslookup DNS lookup for an IP address or hostname
password Update Password
patch Install System or Application Patch
permit List cli for Secure Tunnel
ping Ping a remote ip address
ping6 Ping a remote ipv6 address
reload Reload the system
reset-config Reset network and time settings
restore Restore system
rmdir Remove existing directory
screen-length Configure screen length
screen-width Configure screen width
show Show information about the system
ssh SSH to a remote ip address
tech TAC commands
terminal Set terminal line parameters
traceroute Trace the route to a remote ip address
undebug Disable debugging functions (see also 'debug')
who Display currently logged on users
A user-level CLI account has limited privileges and cannot perform configuration changes or view the status of ISE application processes. Commands available to user-level accounts include basic operations:
ISE-NODE-2/userTest#?
Possible completions:
crypto Crypto operations
exit Exit the management session
license License operations
nslookup DNS lookup for an IP address or hostname
password Update Password
ping Ping a remote ip address
ping6 Ping a remote ipv6 address
show Show information about the system
terminal Set terminal line parameters
traceroute Trace the route to a remote ip address
Creating Local CLI Accounts
In production environments, it is recommended to avoid manually creating local CLI accounts due to security and scalability concerns. Instead, CLI access should be controlled through an external identity source such as Active Directory, where SSH users are validated against the configured identity store.
To create a new local CLI account, use the following command in configuration mode:
username <user-name> password <plain | hash> <password> role admin email <user-email> disabled
The parameters that must be specified are:
- Username: The name used for authentication, for example when accessing the node via SSH.
- Password: The password associated with the account. It can be provided either in plain text or as a hash. When entering a plain-text password, characters such as ! and # must be escaped with a backslash (). In the running configuration, the password is automatically stored as a SHA-256 hash. You may also supply the hashed value directly.
- Email: Associates an email address with the account, enabling notifications to the user when their password is about to expire.
- Disabled: Creates the account in a disabled state, meaning it cannot be used until explicitly enabled.
Once the account has been created, you can verify all locally configured CLI accounts by using the show users status command. Below is an example of the output:
ISE-NODE-2/adminCLI#show users status
USERNAME ROLE DISABLED LOCKED
adminCLI Admin
testUser Admin
testTest Admin *
accountNotAd User
ISE-NODE-2/adminCLI#
When a new account is created, you can verify its creation in the logs from the CLI by running the command show logging system ade/ADE.log | include 1018
2025-11-09T16:10:18.829491+01:00 ISE-NODE-2 CARSSetup[4215]: ADEAUDIT 1018, type=USER, name=USER CONFIGURATION MODIFIED, username=adminCLI, cause=CLI User configuration has been modified, adminipaddress=10.190.13.89, interface=CLI, detail=Added user test with role: Admin state: Enabled successfully
show logging system <file-name>.As shown in the output, the log entry provides several details about the newly created account, excluding the password of course. The information is presented in the following order:
- the log ID, which in this case is 1018
- a description of the logged event
- the administrator account that performed the action, adminCLI in this example
- the IP address from which the administrator was connected when creating the user, in this case 10.190.13.89
- the type of account that was created, shown in the detail field (here, an Admin user)
- the state of the account; in this example, the account was created in an enabled state. Using the disabled keyword, it is possible to create the account without enabling it, making it temporarily unusable.
In this example, an Admin account was created. Below is the corresponding log entry for the creation of a User-level account.
2025-11-09T16:19:15.602889+01:00 ISE-NODE-2 CARSSetup[4215]: ADEAUDIT 1018, type=USER, name=USER CONFIGURATION MODIFIED, username=adminCLI, cause=CLI User configuration has been modified, adminipaddress=10.190.13.89, interface=CLI, detail=Added user testtest with role: User state: Enabled successfully
When a new account is created with an associated password, the user is required to change that password upon the first login attempt. The output for this scenario is shown below:
login as: testpwd
testpwd@10.48.18.42's password:
Pre-authentication banner message from server:
| You are required to change your password immediately (administrator enforced)
> .
End of banner message from server
You are required to change your password immediately (administrator enforced).
WARNING: Your password has expired.
You must change your password now and login again!
Changing password for user testpwd.
Current password:
New password:
Retype new password:
It is also interesting to observe how the node behaves when the user sets a new password. The following logs illustrate this process:
2025-11-09T17:36:09.169359+01:00 ISE-NODE-2 CARSSetup[4215]: ADEAUDIT 1018, type=USER, name=USER CONFIGURATION MODIFIED, username=system, cause=CLI User configuration has been modified, adminipaddress=127.0.0.1, interface=CLI, detail=User testpwd has been modified with password, role: User state: Enabled successfully
Unlike the previous example, the source IP address used for the password change is 127.0.0.1, which is the local address of the machine. This occurs because the update is triggered internally by ISE itself.
As with the CLI, the GUI also allows a Super Admin to forcibly terminate another user’s session. This can be done by navigating to Administration → System → Settings → Session → Session Info. From this page, you can select the session you want to end and click Invalidate to terminate it.
Once an account has been created, whether it is an admin or user account, its password can be modified at any time. In addition to the user performing a password reset on their own, an administrator can update the password by using the username command again.
To review the most recent CLI login attempts, you can use the show logins cli command. By default, the command displays the last ten entries. If needed, additional entries can be shown by specifying a higher value with show logins cli count . The output also includes information about system reboots. For reference, the example below shows the default set of ten entries returned by the command.
ISE-NODE-2/adminCLI#show logins cli
testtest pts/1 10.190.13.89 Sun Nov 9 16:21 still logged in
testtest pts/1 10.190.13.89 Sun Nov 9 16:20 - 16:20 (00:00)
testtest pts/1 10.190.13.89 Sun Nov 9 16:20 - 16:20 (00:00)
testtest pts/1 10.190.13.89 Sun Nov 9 16:19 - 16:19 (00:00)
testtest pts/1 10.190.13.89 Sun Nov 9 16:19 - 16:19 (00:00)
adminCLI pts/0 10.190.13.89 Sun Nov 9 15:53 still logged in
adminCLI pts/0 10.190.1.142 Sat Nov 8 12:40 - 12:52 (00:12)
adminCLI pts/0 10.190.1.142 Sat Nov 8 12:38 - 12:38 (00:00)
adminCLI pts/0 10.190.1.142 Sat Nov 8 12:38 - 12:38 (00:00)
reboot system boot 4.18.0-425.10.1. Sat Nov 8 12:37 still running
wtmp begins Wed Sep 20 11:56:55 2023
If you want to view only the users who are currently connected to the CLI, you can use the show users command. An example of the output is shown below:
ISE-NODE-2/adminCLI#show users
USERNAME ROLE HOST TTY LOGIN DATETIME
adminCLI Admin 10.190.13.89 pts/0 Sun Nov 9 15:53:33 2025
mb Admin 10.190.13.89 pts/1 Sun Nov 9 17:27:21 2025
-------------------
DETACHED SESSIONS:
-------------------
USERNAME ROLE STARTDATE
% No disonnected user sessions present
If at any point you need to disconnect a user who is currently logged in via CLI, an administrator can issue the forceout <user-name> command. The log generated by this operation is shown below.
2025-11-09T17:52:31.694783+01:00 ISE-NODE-2 CARSSetup[94927]: ADEAUDIT 2040, type=FORCEOUT, name=FORCEOUT USER, username=system, cause=Forced logout of all the sessions of a CLI user, adminipaddress=127.0.0.1, interface=CLI, detail=Forced logout of user usr successful
2025-11-09T17:52:31.582890+01:00 ISE-NODE-2 ADE-SERVICE[1336]: [94927]:[info] user: user.c[3319] [system]: Invoked force logout for user: usr
2025-11-09T17:52:31.683127+01:00 ISE-NODE-2 ADE-SERVICE[1336]: [94927]:[info] user: user.c[3355] [system]: force logout: CLI user found a match usr
2025-11-09T17:52:31.695540+01:00 ISE-NODE-2 ADE-SERVICE[1336]: [94927]:[info] user: user.c[3395] [system]: Force logout on usr successful
ISE-NODE-2/adminCLI#
In this case, the log ID differs from the previous example, changing from 1018 to 2040. The log also specifies the username that was forcibly logged out, shown in the “detail” field. As in the earlier scenario, the source IP address is the local address of the node.
Just like the accounts created through the CLI, it is also possible to view the internal administrator accounts created through the GUI. To do so, you can enter the ISE configuration mode using the following command:
aaplicaton coniguration ise
Below are all the options available to the admin user. For our purposes, the relevant one is option 15.
ISE-NODE-2/adminCLI#application configure ise
Selection configuration option
[1]Reset M&T Session Database
[2]Rebuild M&T Unusable Indexes
[3]Purge M&T Operational Data
[4]Reset M&T Database
[5]Refresh Database Statistics
[6]Display Profiler Statistics
[7]Export Internal CA Store
[8]Import Internal CA Store
[9]Create Missing Config Indexes
[10]Create Missing M&T Indexes
[12]Generate Daily KPM Stats
[13]Generate KPM Stats for last 8 Weeks
[14]Enable/Disable Counter Attribute Collection
[15]View Admin Users
[16]Get all Endpoints
[19]Establish Trust with controller
[20]Reset Context Visibility
[21]Synchronize Context Visibility With Database
[22]Generate Heap Dump
[23]Generate Thread Dump
[24]Force Backup Cancellation
[25]CleanUp ESR 5921 IOS Crash Info Files
[26]Recreate undotablespace
[27]Reset Upgrade Tables
[28]Recreate Temp tablespace
[29]Clear Sysaux tablespace
[30]Fetch SGA/PGA Memory usage
[31]Generate Self-Signed Admin Certificate
[32]View Certificates in NSSDB or CA_NSSDB
[33]Recreate REPLOGNS tablespace
[34]View Native IPSec status
[35]Enable/Disable/Current_status of Audit-Session-ID Uniqueness
[36]Check and Repair Filesystem
[37]Enable/Disable/Current_status of RSA_PSS signature for EAP-TLS
[0]Exit
By entering 15 and pressing Enter, the following output is displayed:
Admin User Report
User Name Description Enabled First Name Last Name Email Groups
=============== ==================== ======== =============== =============== ========================= ========================================
pippo ENABLED ["ERS Operator"]
adminGUI Default Admin User ENABLED ["Super Admin"]
test ENABLED ["Super Admin"]
Returning to the accounts created via CLI, in addition to the runtime display commands, there is also the generic show running-config username command, which allows you to view all locally created users directly from the configuration. An example output is shown below:
ISE-NODE-3/admin#show running-config username
username admin password hash $6$QN/U7Lie5UN1GsP8$lrsMB0go3C9s6jcGs52GgP3bSAOzznLGOEBIItoYIxcskVXYBQVgl6YqKyZLgJG9IrDDS/cTpBQvLhMYiXcjd. role admin
username mb password hash $6$RGUzlAPxOVStv963$kgD3h3XGJYu56zq65v0jfqkOkyGEJtFSSM0wO3fYN27/z7yUC2.jlhFoLFpITTXN.UjLj/BcwW/TZzz2wOXdl. role admin
Additional options are available to further refine the search.
ISE-NODE-3/admin#show running-config username ?
Possible completions:
admin Username (Max Size - 31)
mb Username (Max Size - 31)
| Output modifiers
<cr>
Possible match completions:
disabled User is disabled
email User email address
password Password and user role
role Specify user role
As previously shown, creating a local user account from the CLI is a straightforward process. One of the most important attributes of any account is its password. To enhance the overall security posture, ISE enables administrators to enforce a set of password policies that must be adhered to when defining a password. These policies can be reviewed using the show running-config password-policy command. An example of the output is provided below:
ISE-NODE-2/adminCLI#show running-config password-policy
password-policy
digit-required
lower-case-required
min-password-length 8
no-username
password-expiration-days 45
password-expiration-enabled
password-lock-enabled
password-lock-retry-count 3
upper-case-required
!
ISE-NODE-2/adminCLI#
It is important to note that these policies are read-only when viewed from the CLI. Any modification must be performed through the GUI. If you attempt to change a policy from the CLI, the following error message will appear:
ISE-NODE-2/adminCLI(config-password-policy)#password-expiration-days 12
% Error: Configuration changes ignored. Password policy is replicated from ISE administration node. Please set CLI password policy using the ISE web UI on the primary administration node.
ISE-NODE-2/adminCLI(config-password-policy)#
For this reason, password policies must be modified through the GUI using an administrator account, such as a Super Admin or System Admin. It is also important to note that not all GUI options apply to accounts created through the CLI. The password policy defined in the Administrator Account Settings section of Cisco ISE applies to all administrator accounts.
The configuration menu for password policies is located under: Administration → System → Admin Access → Authentication → Password Policy
Any change made from this page is automatically replicated and reflected in the corresponding CLI output. For example, if you modify the maximum password lifetime and set it to a value different from the default, such as 78 days, the updated value will also appear in the CLI output as shown below.
IMMAGINE DEL 79
ISE-NODE-2/adminCLI#show running-config password-policy
password-policy
digit-required
lower-case-required
min-password-length 8
no-username
password-expiration-days 78
password-expiration-enabled
password-lock-enabled
password-lock-retry-count 3
upper-case-required
!
ISE-NODE-2/adminCLI#
After reviewing how to create, manage, and display user accounts through the CLI, we can now move on to the next section, which covers the same concepts from the perspective of the GUI.
GUI Access
The second and most commonly used method for managing user accounts is through the GUI. From the GUI, administrators can:
- Manage deployments, help desk operations, network devices, and node monitoring and troubleshooting
- Manage Cisco ISE services, policies, administrator accounts, and overall system configuration and operations
- Change administrator and user passwords
Administrator accounts can be managed under Administration → System → Administrators → Admin Users. From this page, it is possible to create new accounts and assign all the available attributes to them.
INSERIRE IMMAGINE DELLA PAGINA DEGLI AMMINISTRATORI
From this page it is possible to delete an account or disable it. When an account is disabled, anyone using those credentials will no longer be able to access the Cisco ISE graphical interface. It is important to remember that these accounts are stored internally within the ISE cluster.
Special mention must be made of the admin account created during the initial setup. This account cannot be deleted or disabled, unlike the default CLI account. As a result, only a limited set of attributes can be modified. Several fields are fixed and cannot be changed, including the account status, the read-only option, the requirement to change the password at the next login, and the administrator groups assigned to the account.
The screen below displays all the attributes that can be configured for each individual administrator account.
IMMAGINE DELLA CREAZIONE DI UN UTENTE
Tip
For test or lab environments, it can be useful to apply the following recommendations to simplify account management. When creating an account through the GUI, it is advisable to enable the option Inactive account never disabled. This ensures that the account will not be automatically disabled, effectively overriding the Account Disable Policy. Another helpful option is Administrator password expires. By disabling this setting, the account password will not expire over time, which can be convenient in non production scenarios.
As explained earlier, administrator access in ISE is based on the Role Based Access Control model. Depending on the specific account, or in the case of an external identity store depending on the group to which the user belongs such as an Active Directory group, ISE determines which features, pages and information each administrator is allowed to access.
In contrast to the command line interface, which provides only two role types, the graphical interface offers a much wider range of administrator groups and also allows the creation of custom groups. The image below shows all the available groups.
IMMAGINE DEI GRUPPI
In addition to the groups that are installed by default, the interface also allows the creation of custom administrator groups. This option is useful when there is a need to define profiles with specific levels of access or visibility. For example, it is possible to create a group that cannot view any information related to TACACS. In this way, both the menus and the associated data are hidden from all users who are assigned to that group.
IMMAGINE DELLE CARATTERISTICHE DEL GRUPPO
These administrator groups can be either internal or external. Internal groups are associated with local administrator accounts created within ISE, while external groups are mapped to users belonging to groups defined in an external identity source, for example Active Directory groups within the organization.
For later use, we temporarily create a group named groupTest. This group will be used shortly when defining the RBAC policy.
Once the administrator groups have been created, the next step is to specify which resources they are allowed to access. To complete the flow, two additional elements are required: the RBAC policies and the permission objects. Permission objects are used to define, within the GUI, which menus or data should be visible to the users who belong to a specific group.
ISE provides a number of default permission objects, both for menu visibility and data visibility. As an example, the Menu Access page allows you to define which menus should be accessible. The drop down list in this section directly reflects the structure of the ISE graphical interface. Using the show and hide options, it is possible to control the visibility of each menu entry. For demonstration purposes, we create a new permission object named testMenuAccess.
The same approach applies to data masking through the Data Access page. Here we create another permission object by selecting Add and naming it testDataAccess. All the information available in ISE can be shown or hidden based on the visibility requirements for the selected group.
After creating these permission objects, the final step is to combine them into an RBAC policy. RBAC policies associate a group with the defined visibility settings. As with other areas, ISE already includes several default RBAC policies that can be used by assigning users to the corresponding predefined groups.
The logic behind RBAC is straightforward. For each policy, ISE checks whether a user belongs to the specified group. If the condition is met, the associated Menu Access and Data Access objects are applied to that user. To create the final policy, select Actions and choose Insert new policy. Assign a name, such as RBAC Group Test Policy, and specify the group to which the policy applies, in this case groupTest. The last step is to associate the visibility settings we prepared earlier, testMenuAccess and testDataAccess.
Now, when creating a new administrator account, assigning the user to the group groupTest ensures that the corresponding RBAC policy is applied.
Refernce
https://www.cisco.com/c/en/us/td/docs/security/ise/3-3/cli_guide/b_ise_CLI_Reference_Guide_33.html