Rajeev Kallur's profile photo
Rajeev Kallur - Senior cloud developer, HPE

March 2026

br
# Managing application accounts on HPE iL07+ servers with iLOrest - A complete guide

## Introduction

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](/docs/redfishclients/ilorest-userguide/ilocommands#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.

## Terminology: Application account vs. Application token

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

| Term | What It Is | Where It Lives | Lifecycle |
|  --- | --- | --- | --- |
| **Application account** (appaccount) | The application's identity record in iLO. Includes app name, ID, and authorization configuration. | **iLO** (Redfish API) | Created / deleted explicitly by the admin |
| **Application token** (apptoken) | The cryptographic secret the application uses to authenticate. Has a **defined lifespan**. | **TPM** (hardware) | Created with the account; expires and is renewed via `reactivate` |


**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.

## Which applications are supported?

Important
As of today, application accounts can only be created for the following HPE-recognized applications:

| Application | Description |
|  --- | --- |
| **SUM** (Smart Update Manager) | HPE's firmware and driver update tool |
| **SUT** (Smart Update Tools) | Automated OS-level update agent |
| **AMS** (Agentless Mgmt Service) | Collects host OS information for iLO |
| **iLOrest** (self-registered) | HPE's RESTful interface tool itself |


**Custom or third-party applications are not yet supported.** You cannot register an arbitrary application with its own `hostappid` / `hostappname` / `salt`
unless it is one of the recognized HPE tools listed above.

When using the `--self` flag, iLOrest creates a self-registered account with the reserved ID prefix `00b5`, which is exclusively allocated to iLOrest's own self-registration mechanism.

## Prerequisites

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](/docs/redfishclients/ilorest-userguide/errors)
on iLO 5 or iLO 6.
2. **Virtual NIC ([vNIC](/docs/redfishservices/ilos/supplementdocuments/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)](/docs/redfishclients/ilorest-userguide/errors).
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](https://servermanagementportal.ext.hpe.com/docs/redfishservices/ilos/supplementdocuments/vnic#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)](/docs/redfishclients/ilorest-userguide/errors).
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](#2-deleting-an-application-account) paragraph).


Note
**CHIF vs. vNIC:**
The [CHIF](/docs/etc/glossaryterms)
(Channel Interface) driver used in iLO 5 and iLO 6 is **not exposed in iLO7**. All host-to-iLO communication on iLO 7 is performed exclusively through the
**vNIC (Virtual NIC)** interface. The `appaccount` command uses the vNIC for both local TPM operations and iLO REST API calls.

## Understanding dual storage: TPM + iLO

Every application account lives in **two places simultaneously**:

| Storage | What it holds | Access mechanism |
|  --- | --- | --- |
| **TPM** (Trusted Platform Module) | The **apptoken** — cryptographic secret for authentication. Has an expiry lifecycle. | vNIC driver call from the host OS (no REST auth needed) |
| **iLO** (Redfish REST API) | The **appaccount** — identity record iLO uses to authorize REST API requests. | Authenticated REST session (username + password) |


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:

```shell
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
```

## Subcommands at a glance

| Subcommand | Purpose | Does it require iLO Credentials? |
|  --- | --- | --- |
| `create` | Create a new appaccount (apptoken in TPM + appaccount in iLO). Silently cleans up orphans. | **Yes** — always |
| `delete` | Remove an appaccount from both TPM and iLO | **Yes** — always recommended |
| `exists` | Check whether an appaccount / apptoken exists in TPM or iLO | No |
| `details` | List all appaccounts with their TPM / iLO presence status | No (more complete with credentials) |
| `reactivate` | Renew an **expired apptoken** in TPM (token rotation). Does **not** handle orphans. | **Yes** — always |


Note
A `appaccount delete --self` command allows running without credentials, but this is **not recommended**.
Without credentials, only the TPM token is deleted. The iLO-side account **cannot** be removed without an authenticated REST session,
leaving an **orphaned account in iLO**. Always provide `-u` and `-p` for a complete deletion.

The following example illustrates the above note:

Good practise to delete an appaccont
```shell
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
```

## 1. Creating an application account

### What it does

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.


### Why `create` is the recommended recovery path after TPM clear

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:

```text
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.

### Syntax

There are two modes:

#### Mode 1: Named application (for SUM, SUT, or AMS)

```shell
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:**

```shell
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.
```

#### Mode 2: Self-registration (for iLOrest itself)

```shell
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:**

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

### What if the account already exists?

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

```text
Application account already exists for the specified host application.
```

### Error scenarios

| Error | Meaning |
|  --- | --- |
| `SavinginTPMError` | The apptoken could not be written to TPM. Delete the account and retry. |
| `SavinginiLOError` | The appaccount could not be registered in iLO. Delete and retry. |
| `InvalidCredentialsError` | The iLO username / password is wrong. |
| `GenerateAndSaveAccountError` | A general failure occurred during generation. Retry later. |


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."*

## 2. Deleting an application account

### What it does

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.

### Why credentials are always recommended

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](#understanding-dual-storage-tpm--ilo)

### Credential rules

- **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.


### Short appid expansion

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.

### Examples

**Delete a SUT account (credentials required):**

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

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

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

**Expected output on success:**

```text
Application account has been deleted successfully.
```

**If the account does not exist:**

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

## 3. Checking if an application account exists

### What it does

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.

Note
Without credentials, only the TPM check is performed. Provide `-u` / `-p` for a complete existence check across both stores.

### Examples

**Check by application ID:**

```shell
ilorest appaccount exists --hostappid a1b2
```

**Check the self-registered iLOrest account:**

Command
```shell
ilorest appaccount exists --self
```

Output when found
```text
Application account exists for this host application.
```

Output when not found
```text
Application account does not exist for this hostapp.
```

The command returns a distinct [exit code](/docs/redfishclients/ilorest-userguide/errors) (`ACCOUNT_DOES_NOT_EXIST_ERROR`) when the account is not found, which is useful for scripting and automation.

## 4. Viewing application account details

### What it does

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`.


Note
Without credentials, only TPM-side data is returned. Providing `-u` / `-p` enables the iLO REST query, giving you the complete picture.

### Viewing all application accounts

#### Table or JSON output

Table
```shell
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
```

JSON
```shell
# NOTE: Because iLOrest is missing its appaccount, it is required to supply credentials
u=ilorest-appuser p=password
ilorest appaccount details --hostappid all --json -u $u -p $p
[
  {
    "ApplicationName": "SUM",
    "ApplicationID": "**c3d4",
    "ExistsInTPM": true,
    "ExistsIniLO": true
  },
  {
    "ApplicationName": "SUT",
    "ApplicationID": "**e5f6",
    "ExistsInTPM": true,
    "ExistsIniLO": true
  }
]
```

Security note
Application IDs are **partially masked** — only the last 4 characters are shown, prefixed with `**`.

### Filtering: TPM-only or iLO-only

Apptoken status only - Table
```shell
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
```

Appaccount status only - JSON
```shell
# NOTE: Because iLOrest is missing its appaccount, it is required to supply credentials
u=ilorest-appuser ; p=password
ilorest appaccount details --hostappid all --json --only_account -u $u -p $p
[
  {
    "ApplicationID": "**06f8",
    "ApplicationName": "Integrated Smart Update Tools",
    "ExistsIniLO": true
  },
  {
    "ApplicationID": "**48bb",
    "ApplicationName": "Smart Update Manager",
    "ExistsIniLO": true
  },
  {
    "ApplicationID": "**fea0",
    "ApplicationName": "AMS",
    "ExistsIniLO": true
  }
]
```

### Viewing a specific account

```shell
# 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
```

### Viewing the self-registered account

Viewing self-registered details when it exists
```shell
ilorest appaccount details --self --json
[
  {
    "ApplicationID": "**00b5",
    "ApplicationName": "iLORest",
    "ExistsInTPM": true,
    "ExistsIniLO": true
  }
]
```

When absent
```shell
ilorest appaccount details --self
No self-registered iLOrest app account found.
Use 'appaccount details --hostappid all' to see all app accounts.

u=ilorest-appuser p=password
ilorest appaccount details --hostappid all -u $u -p $p
```

### Detecting orphaned accounts

After a TPM clear, you might see:

```text
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.

## 5. Reactivating an expired apptoken

### What it does

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.

### What reactivate does not do

- ❌ **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.


### When to use reactivate vs. create

| Scenario | What happened | Recommended command |
|  --- | --- | --- |
| Token expired (still in TPM) | Apptoken's lifespan has elapsed | `appaccount reactivate` |
| Periodic token rotation | Scheduled credential renewal | `appaccount reactivate` |
| TPM was cleared (orphan in iLO) | Apptoken wiped; appaccount remains in iLO | `appaccount create` (silently cleans up the orphan) |
| Account does not exist at all | Fresh setup | `appaccount create` |
| Account needs to be removed | Decommissioning an application | `appaccount delete` |


### How it works internally

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.


### Syntax

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

Or for self-registered:

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

iLO Administrator credentials are **always** required — no exceptions.

### Examples

**Reactivate an expired SUM token:**

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

**Output on success:**

```text
Application account has been reactivated successfully.
```

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

```markdown
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.
```

Tip
If you see this error after a TPM clear, just run `appaccount create` with the same parameters. It will silently clean up the orphaned iLO account and create everything fresh.

## Orphaned accounts: what they are and how they're handled

### What is an orphaned account?

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.

### How orphans occur

| Trigger | Result |
|  --- | --- |
| TPM clear (via BIOS or iLO) | All apptokens wiped from TPM; appaccounts remain in iLO |
| Failed creation (partial write) | Apptoken may exist in TPM but not in iLO, or vice versa |
| Deleting `--self` without credentials | Apptoken removed from TPM; appaccount left in iLO (no REST session) |


### How the tool handles orphans

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.

### Summary by subcommand

| Subcommand | Orphan behavior |
|  --- | --- |
| `create` | **Silently cleans up** the orphaned iLO account, then creates fresh in both stores. User sees a normal success message. |
| `delete` | Attempts deletion from both TPM and iLO independently. Succeeds if removed from at least one. |
| `details` | Shows orphans clearly — `ExistsInTPM: no` alongside `ExistsIniLO: yes`. |
| `exists` | Reports the account as existing if found in either store. |
| `reactivate` | **Does not handle orphans.** Fails if the apptoken is missing from TPM. Only works on expired tokens still in TPM. |


## Credential encoding support

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.

## Session management under the hood

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

### 1. vNIC driver calls (for TPM operations)

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.

Note
In iLO7, the CHIF (Channel Interface) driver used in iLO 5/iLO 6 is **not available**. All host-to-iLO communication is through vNIC exclusively.

### 2. Redfish REST API over vNIC (for iLO account operations)

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.

Takeway
Any operation that touches the iLO REST API (create, delete from iLO, details with iLO data, orphan cleanup) requires credentials.
Operations that only touch TPM (token existence check, token deletion, token reactivation) use the vNIC driver and don't need REST credentials
— though the CLI still requires them for create and reactivate to ensure the full operation succeeds.

## Quick reference: Common workflows

### Workflow 1: First-time setup of iLOrest self-registration

```shell
# 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
```

### Workflow 2: Recovery after TPM clear

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

```shell
# 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
```

### Workflow 3: Token expiry — reactivating an expired apptoken

```shell
# 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
```

### Workflow 4: Audit and cleanup

```shell
# 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
```

### Workflow 5: Deleting the self-registered account

```shell
# 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
```

Reminder
⚠️  Running `delete --self` without credentials only removes the apptoken from TPM.
The appaccount in iLO will remain as an orphan until the next `create --self` silently cleans it up. Always include credentials for an immediate, complete deletion.

## Error reference

| Error | Cause | Resolution |
|  --- | --- | --- |
| `IncompatibleiLOVersionError` | Running on iLO5 or iLO6 | Upgrade to iLO7 firmware |
| `VnicExistsError` | vNIC not enabled or misconfigured | Enable vNIC in iLO settings; verify host OS NIC config |
| `UserNotAdminError` | Not running as root / Administrator | Use `sudo` (Linux) or run as Administrator (Windows) |
| `UsernamePasswordRequiredError` | Missing `-u` or `-p` for a command that requires them | Provide iLO admin credentials |
| `InvalidCommandLineError` | Wrong flag combination (e.g., `--self` with `--hostappid`) | Check syntax; use `-h` for help |
| `NoAppAccountError` | Account / token not found for the given ID | Verify `hostappid`; use `create` if the token was wiped |
| `SavinginTPMError` | TPM write failed during creation | Delete the account and retry |
| `SavinginiLOError` | iLO REST API write failed during creation | Delete the account and retry |
| `AppAccountExistsError` | Account already exists (create) or ID not found (details) | Use `exists` to verify; delete first if needed |
| `ReactivateAppAccountTokenError` | Token reactivation failed | Retry; check iLO logs for details |
| `GenBeforeLoginError` | Cannot determine iLO version | Ensure vNIC is enabled on the iLO7 server |


## Security best practices

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.


## In summary

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.

## Get started today

### Ready to secure your iLO 7 application authentication? Here's how to take the first step

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](#quick-reference-common-workflows) and [Error reference](#error-reference) sections when troubleshooting.


Interested in learning more....stay tuned with the [HPE Developer Community](https://developer.hpe.com/blog/)....