Rajeev Kallur - Senior cloud developer, HPE

March 2026

Starting with iLO 7, HPE introduced a new security paradigm for host-based applications that need to communicate with the Integrated Lights-Out (iLO) management processor: Application Accounts (appaccounts). Unlike traditional iLO user accounts that humans use to log in via the iLO web GUI, Redfish API or SSH, application accounts are purpose-built credentials that allow software running on the host OS to authenticate with iLO securely — with the secret material stored inside the server's Trusted Platform Module (TPM).

The iLOrest command-line tool provides a dedicated appaccount command that lets administrators create, delete, check the existence of, view details of, and reactivate these application accounts. This guide walks through every capability in depth, with real-world examples and explanations of the internal mechanics.

Before diving in, it's important to understand two related but distinct concepts:

When to use which term:

• Use appaccount create / appaccount delete when you're managing the full lifecycle of an application's registration — creating or removing it from both TPM and iLO.
• Use appaccount reactivate when the token has expired but the account itself is still valid — you're renewing the secret, not recreating the account.
• Use appaccount exists / appaccount details to inspect the state of accounts and their tokens across both stores.

Think of it this way: the appaccount is the "identity card" and the apptoken is the "password" on that card. The card persists, but the password expires and needs periodic renewal.

Before running any ilorest appaccount sub-command, ensure the following:

1. HPE iLO 7 v1.11.00 or later firmware is installed on the server. The command explicitly checks the iLO generation and will fail with an INCOMPATIBLE_ILO_VERSION_ERROR error 54 on iLO 5 or iLO 6.
2. Virtual NIC (vNIC) is enabled in iLO. All appaccount operations communicate with iLO over the internal vNIC interface. If vNIC is not enabled or misconfigured, you will see a vNIC_DOES_NOT_EXIST_ERROR error (142).
3. Log into the host OS of the desired iLO target as root or administrator. The command can only be used via in-band management. Moreover, it checks for root on Linux and Administrator on Windows; unprivileged users are blocked with a USER_NOT_ADMIN error (5).
4. iLO Administrator credentials (login -u / -p) are required for create, reactivate, and delete operations. Even for self-registered account deletion, credentials are strongly recommended to ensure the account is fully removed from both TPM and iLO (see the detailed explanation under the Deleting an application account paragraph).

Every application account lives in two places simultaneously:

This distinction is critical: TPM operations are local vNIC driver calls that don't require iLO REST authentication, while iLO-side operations always require a valid authenticated REST session. This has real implications for commands like delete --self, as explained below.

When everything is in sync, both locations agree. But situations like a TPM clear can cause the two to go out of sync — the appaccount still exists in iLO but the apptoken is no longer in TPM. The appaccount command handles these orphaned accounts transparently during the create workflow.

The following example retrieves the statuses (iLO and TPM) of all appaccounts present in iLO:

ilorest appaccount details --hostappid all
iLORest : RESTful Interface Tool version 7.1.0.0
Copyright (c) 2014-2026 Hewlett Packard Enterprise Development LP
----------------------------------------------------------------------
Application Name: iLORest
Application Id: **00b5
App account exists in TPM: yes
App account exists in iLO: yes

Application Name: AMS
Application Id: **fea0
App account exists in TPM: yes
App account exists in iLO: yes

Application Name: Smart Update Manager
Application Id: **48bb
App account exists in TPM: yes
App account exists in iLO: yes

Application Name: Integrated Smart Update Tools
Application Id: **06f8
App account exists in TPM: yes
App account exists in iLO: yes

The following example illustrates the above note:

u=ilorest-appuser ; p=password

ilorest appaccount delete --self -u $u -p $p
iLORest : RESTful Interface Tool version 7.1.0.0
Copyright (c) 2014-2026 Hewlett Packard Enterprise Development LP
-------------------------------------------------------------------------
Application account has been deleted successfully.

ilorest appaccount details --self
No self-registered iLORest app account found.
Use 'appaccount details --hostappid all' to see all app accounts.

ilorest -vv appaccount details --hostappid all
iLORest : RESTful Interface Tool version 7.1.0.0
There are no application accounts.
iLORest return code: 0

ilorest appaccount details --hostappid all -u $u -p $p
Application Name: Integrated Smart Update Tools
Application Id: **06f8
App account exists in TPM: no
App account exists in iLO: yes

Application Name: Smart Update Manager
Application Id: **48bb
App account exists in TPM: no
App account exists in iLO: yes

Application Name: AMS
Application Id: **fea0
App account exists in TPM: no
App account exists in iLO: yes

The appaccount create subcommand generates a new apptoken and saves it in TPM, while simultaneously registering the corresponding appaccount in iLO. This is the primary way to set up application-level authentication.

Behind the scenes, the command:

1. Validates prerequisites — checks for root/admin, vNIC access, iLO7+.
2. Silently handles orphans — if a previous account with the same ID exists in iLO but not in TPM (e.g., after a TPM clear), the command automatically and silently cleans up the stale iLO account, then proceeds to create a fresh account in both stores as if nothing happened. The user sees only the success message — no extra steps are required.
3. Generates and saves — calls generate_save_token() to create the apptoken in TPM and register the appaccount in iLO in a single operation.

After a TPM clear, all apptokens are wiped but the corresponding appaccounts remain in iLO (orphaned). Rather than requiring a manual delete-then-create sequence, the create command detects this situation automatically:

TPM clear occurs → apptokens wiped → appaccounts remain in iLO (orphaned)
                                        ↓
         ilorest appaccount create (with same parameters)
                                        ↓
         Orphaned iLO account silently deleted → fresh account created in both TPM and iLO
                                        ↓
         "Application account has been generated and saved successfully."

The user doesn't need to know about the orphan — create handles it transparently.

There are two modes:

ilorest appaccount create --hostappname <name> --hostappid <id> --salt <salt> -u <ilo_user> -p <ilo_password>

All three parameters (--hostappname, --hostappid, --salt) are mandatory in this mode. They must correspond to one of the recognized HPE applications (SUM, SUT, AMS). The hostappid is a hex string of 4 or more characters that uniquely identifies the application.

Example — Creating an account for SUM:

u=sum-appuser ; p=password
ilorest appaccount create --hostappname SUM --hostappid a1b2c3d4 --salt sumsecret -u $u -p $p
Application account has been generated and saved successfully.

u=ilorest-appuser ; p=password
ilorest appaccount create --self -u $u -p $p

The --self flag tells iLOrest to create an account for itself, using the reserved ID prefix 00b5. You cannot combine --self with --hostappname, --hostappid, or --salt — doing so will produce an error.

Example — Self-registering iLOrest:

ilorest appaccount create --self -u admin -p iLOpassw0rd
Application account has been generated and saved successfully.

If you try to create an account that already exists in both TPM and iLO, the command does not fail — it simply informs you:

Application account already exists for the specified host application.

In all failure cases, the error message also suggests: "Alternatively, you can use the --no_app_account option in the login Command to log in using your iLO user account credentials."

The appaccount delete subcommand removes an application account from both TPM (the apptoken) and iLO (the appaccount). The command follows a two-step process:

1. Delete the apptoken from TPM — removes the cryptographic secret via a vNIC driver call. This does not require iLO REST authentication.
2. Delete the appaccount from iLO — removes the account via an authenticated DELETE call to /redfish/v1/AccountService/Oem/Hpe/AppAccounts/<id>. This requires a valid iLOrest session.

If the account exists in only one location (e.g., iLO but not TPM after a TPM clear), the command still succeeds as long as it was removed from at least one.

iLO does not allow any modifications to its REST API resources without authentication. This means:

• TPM deletion (apptoken) works without credentials — it's a local vNIC driver operation.
• iLO deletion (appaccount) requires credentials to create a REST session, query the account list, and perform the DELETE call.

If you run delete --self without -u / -p, the command will:

1. ✅ Successfully delete the apptoken from TPM.
2. ❌ Silently skip the iLO-side appaccount deletion (no REST session available).
3. ✅ Report "success" because the TPM deletion succeeded.

The result is an orphaned appaccount left in iLO. While this orphan is harmless (it can't be used without the matching TPM token) and will be silently cleaned up by a subsequent create, it clutters the account list. To ensure a clean, immediate deletion, always provide credentials. Refer to the example in the previous paragraph

• Deleting another application's account (e.g., SUM, SUT, AMS): iLO Administrator credentials (-u and -p) are mandatory. The command will reject the request without them.
• Deleting your own self-registered account (--self or ID containing 00b5): Credentials are not enforced by the CLI, but are strongly recommended for a complete deletion.

When you provide a 4-character hostappid, the command automatically expands it to the full ID using the ExpandAppId() function. This makes it convenient to use the short IDs shown in the details output.

Delete a SUT account (credentials required):

ilorest appaccount delete --hostappid a1b2 -u admin -p iLOpassw0rd

Delete the iLOrest self-registered account (credentials recommended):

ilorest appaccount delete --self -u admin -p iLOpassw0rd

Expected output on success:

Application account has been deleted successfully.

If the account does not exist:

The application account you are trying to delete does not exist.

The appaccount exists subcommand checks whether an appaccount/apptoken is present in either TPM or iLO (or both). It is a read-only operation.

Internally, it:

1. Expands a short (4-char) hostappid to the full ID if possible.
2. Checks for the apptoken in TPM (this also detects expired/inactive tokens — they still "exist").
3. Checks for the appaccount in iLO by querying the REST API (requires credentials for a complete check).

If found in either location, the account is reported as existing.

Check by application ID:

ilorest appaccount exists --hostappid a1b2

Check the self-registered iLOrest account:

ilorest appaccount exists --self

The command returns a distinct exit code (ACCOUNT_DOES_NOT_EXIST_ERROR) when the account is not found, which is useful for scripting and automation.

The appaccount details subcommand provides a consolidated view of all application accounts, showing which ones have apptokens in TPM, appaccounts in iLO, or both. This is the most powerful diagnostic tool for understanding the state of appaccounts on a server.

Internally, the command:

1. Calls ListAppIds() to enumerate all apptokens known to TPM.
2. Queries the iLO REST API at /redfish/v1/AccountService/Oem/Hpe/AppAccounts/ to find accounts registered in iLO.
3. Merges the two lists — any appaccount found only in iLO (orphaned after a TPM clear) is included with ExistsInTPM: no.

ilorest appaccount details --hostappid all
Application name: SUM
Application Id: **c3d4
App account exists in TPM: yes
App account exists in iLO: yes

Application name: SUT
Application Id: **e5f6
App account exists in TPM: yes
App account exists in iLO: yes

Application name: iLOrest
Application Id: **00b5
App account exists in TPM: yes
App account exists in iLO: yes

ilorest appaccount details --hostappid all --only_token
Application Name: iLORest
Application Id: **00b5
App account exists in TPM: yes

Application Name: AMS
Application Id: **fea0
App account exists in TPM: yes

Application Name: Smart Update Manager
Application Id: **48bb
App account exists in TPM: yes

Application Name: Integrated Smart Update Tools
Application Id: **06f8
App account exists in TPM: yes

# Provide the last 4 digits of the AppId
ilorest appaccount details --hostappid 48bb
Application Name: Smart Update Manager
Application Id: **48bb
App account exists in TPM: yes
App account exists in iLO: yes

ilorest appaccount details --self --json
[
  {
    "ApplicationID": "**00b5",
    "ApplicationName": "iLORest",
    "ExistsInTPM": true,
    "ExistsIniLO": true
  }
]

After a TPM clear, you might see:

Application Name: SUM
Application Id: **c3d4
App account exists in TPM: no
App account exists in iLO: yes

This tells you the SUM apptoken has been wiped from TPM but the appaccount persists in iLO. To restore it, simply run appaccount create with the same parameters — the orphaned iLO account will be cleaned up automatically and silently.

The appaccount reactivate subcommand is designed exclusively for renewing expired or inactive apptokens as part of the token expiry and rotation lifecycle. Application tokens stored in TPM have a defined lifespan. When a token expires, the application can no longer authenticate with iLO. The reactivate command renews the token in place without requiring a full delete-and-recreate cycle.

• ❌ Does not handle orphaned accounts. If the apptoken has been removed from TPM entirely (e.g., after a TPM clear), reactivate will fail with an error. Use appaccount create instead — it handles orphan cleanup automatically and silently.
• ❌ Does not create new accounts. It only renews existing, expired tokens.
• ❌ Does not modify the iLO-side appaccount. Only the TPM-side apptoken is renewed.

1. Checks whether the apptoken exists in TPM. The _check_exists_in_tpm() function returns True for both active and inactive/expired tokens — an expired token still exists, it's just no longer valid for authentication.
2. If the token does not exist in TPM at all (it was wiped, not just expired), the command raises an error and directs the user to use create instead.
3. If the token exists but is expired/inactive, it calls reactivate_token() to renew it in place.

ilorest appaccount reactivate --hostappname <name> --hostappid <id> --salt <salt> -u <ilo_user> -p <ilo_password>

Or for self-registered:

ilorest appaccount reactivate --self -u <ilo_user> -p <ilo_password>

iLO Administrator credentials are always required — no exceptions.

Reactivate an expired SUM token:

ilorest appaccount reactivate --hostappname SUM --hostappid a1b2c3d4 --salt sumsecret -u admin -p iLOpassw0rd

Output on success:

Application account has been reactivated successfully.

If the token doesn't exist in TPM (e.g., after TPM clear):

The application account you are trying to reactivate does not exist.
If the account was orphaned after a TPM clear, please use `appaccount delete` followed by `appaccount create` to recreate it.

An orphaned account is one where the appaccount exists in iLO but the apptoken is missing from TPM. The account can't be used for authentication because the secret is gone.

The appaccount create command is the primary and recommended recovery mechanism for orphaned accounts. When you run create for an application that has an orphaned account:

1. It detects that the appaccount exists in iLO but the apptoken is missing from TPM.
2. It silently deletes the orphaned appaccount from iLO.
3. It creates a fresh apptoken in TPM and a fresh appaccount in iLO.
4. The user sees only: "Application account has been generated and saved successfully."

No manual cleanup is required. The entire orphan recovery is invisible to the user.

For security-sensitive automation pipelines, the appaccount command supports encoded credentials. When the --encode flag is active, the provided -u (username) and -p (password) values are treated as encoded strings and decoded internally using the Encryption.decode_credentials() utility before use.

This prevents plaintext passwords from appearing in process listings, shell history, or CI/CD logs.

The appaccount command communicates with iLO in two fundamentally different ways:

Operations like generate_save_token, delete_token, token_exists, reactivate_token, and ListAppIds are performed through the vNIC driver — a direct host-to-iLO channel that does not go through the REST API. These calls do not require REST authentication.

Querying, creating, and deleting appaccounts in iLO is done via the Redfish REST API at https://16.1.15.1 (the vNIC IP). iLO requires authentication for all REST API operations — both reads and writes.

Since appaccount runs without a prior ilorest login session, it creates temporary REST sessions on demand:

• _create_ilo_session() — POSTs to /redfish/v1/SessionService/Sessions/ with the provided credentials, obtaining an X-Auth-Token.
• _delete_ilo_session() — DELETEs the session when done.

These temporary sessions are always cleaned up in a finally block, even if an error occurs — preventing session exhaustion on iLO.

# Create the self-registered account (credentials required)
u=ilo-appaccount ; p=password
ilorest appaccount create --self -u $u -p $p

# Verify it was created
ilorest appaccount exists --self

# View the details
ilorest appaccount details --self

No manual cleanup needed — just re-run create. Orphans are handled silently.

# Simply recreate the account (orphaned iLO account is cleaned up automatically)
u=ilo-appaccount ; p=password
ilorest appaccount create --hostappname SUM --hostappid a1b2c3d4 --salt sumsecret -u $u -p $p

# Verify recovery
ilorest appaccount details --hostappid a1b2 -u $u -p $p

# Reactivate the expired token (token must still exist in TPM, just expired)
u=ilo-appaccount ; p=password
ilorest appaccount reactivate --hostappname SUM --hostappid a1b2c3d4 --salt sumsecret -u $u -p $p

# Verify the account is active
ilorest appaccount exists --hostappid a1b2

# List all accounts in JSON (credentials enable iLO-side data)
u=ilo-appaccount ; p=password
ilorest appaccount details --hostappid all --json -u $u -p $p

# Delete a stale account (credentials required for iLO-side removal)
ilorest appaccount delete --hostappid e5f6 -u $u -p $p

# Confirm deletion
ilorest appaccount exists --hostappid e5f6

# Always provide credentials for a complete deletion from both TPM and iLO
u=ilo-appaccount ; p=password
ilorest appaccount delete --self -u $u -p $p

# Verify
ilorest appaccount exists --self

1. Always provide iLO credentials for create, delete, and reactivate operations to ensure both TPM and iLO stay in sync.
2. Never embed plaintext credentials in scripts. Use the --encode flag or integrate with a secrets manager.
3. Audit appaccounts regularly. Use appaccount details --hostappid all --json -u admin -p <password> and feed the output into your SIEM or compliance tools.
4. Clean up unused accounts. If an application (e.g., SUM) is no longer deployed on a server, delete its appaccount with credentials.
5. After TPM clear, just re-run create. The command silently handles orphaned iLO accounts — no manual cleanup needed.
6. Monitor token expiry. When an application suddenly fails to authenticate with iLO, check if its apptoken has expired using appaccount details and reactivate if needed.
7. Restrict iLO admin credentials. Only users who manage appaccounts should have iLO admin access.

The appaccount command in iLOrest is a powerful, security-first tool for managing application-level authentication on iLO7+ servers. By leveraging dual storage — apptokens in TPM for hardware-backed secret security and appaccounts in iLO for REST API authorization — it provides a robust foundation for automated server management.

Key strengths of the design include:

• Transparent orphan recovery — the create command silently cleans up stale iLO accounts after a TPM clear, requiring no manual intervention.
• Token lifecycle management — the reactivate command handles token expiry and rotation without disrupting the account.
• Comprehensive diagnostics — the details command provides a unified view of both stores, making it easy to spot inconsistencies.

Currently limited to SUM, SUT, AMS, and iLOrest (with custom application support not yet available), it covers the core HPE management stack comprehensively. Whether you're automating firmware updates with SUM, collecting host data with AMS, or scripting iLO configuration with iLOrest, the appaccount command ensures your application credentials are secure, auditable, and recoverable.

1. Verify your environment — Confirm that your server is running iLO7 firmware and that vNIC is enabled.
2. Create your first appaccount — Run ilorest appaccount create --self -u <admin> -p <password> to register iLOrest itself.
3. Audit your existing accounts — Run ilorest appaccount details --hostappid all --json -u <admin> -p <password> to see what's already registered.
4. Integrate into your automation — Add appaccount create/delete steps to your provisioning scripts and CI/CD pipelines so every server is configured consistently.
5. Bookmark this guide — Refer back to the Workflows and Error reference sections when troubleshooting.

Interested in learning more....stay tuned with the HPE Developer Community....