Managing iLO users

Managing iLO Users
Copy for LLM
Copy page as Markdown for LLMs
View as Markdown
Open this page as Markdown
Open in ChatGPT
Get insights from ChatGPT
Open in Claude
Get insights from Claude

NOTE

It is possible that some properties or resources described in this section are not implemented in HPE iLO 4 and iLO 5.

HPE iLO supports:

Local user authentication
Directory authentication
Role based local user administration via Redfish
Directory Authentication configuration via Redfish

User account modifications require Redfish clients to be authenticated with the "Administer User Accounts" privilege (UserConfigPriv in the Redfish ManagerAccount resource type

TIP:

Managing iLO users with iLOrest is described in this documentation section.

The Account Service

The iLO user management service is described in the AccountService subsystem . This subsystem contains the capabilities of the service (i.e. Active Directory, LDAP) as well the URIs of various resources like the entry point of the local account database.

The following example retrieves the local user account and application accounts URIs from the AccountService.

NOTE

Application accounts have been introduced with HPE iLO 7.

ilorest login ilo-ip -u ilo-user -p password
ilorest list Accounts Oem/Hpe/AppAccounts --select AccountService. --json
{
  "Accounts": {
    "@odata.id": "/redfish/v1/AccountService/Accounts/"
  },
  "Oem": {
    "Hpe": {
      "AppAccounts": {
        "@odata.id": "/redfish/v1/AccountService/Oem/Hpe/AppAccounts/"
      }
    }
  }
}

ilorest logout

Local user administration

HPE iLO holds a local user database enabling consistent user management for all interfaces including the Web interface (GUI) as well as the Redfish API. Refer to the example of the previous paragraph to retrieve the URIs of the local user accounts.

TIP:

Refer to this documentation section of iLO user management with iLOrest.

The following example lists the URIs of local iLO users and application accounts.

GET /redfish/v1/AccountService/Accounts/
and
GET /redfish/v1/AccountService/Oem/Hpe/AppAccounts

A local user account consists of a user name, password, and a set of privileges. The RoleId property describes one of three defined Redfish roles based upon assigned privileges. The Oem/Hpe/LoginName property is a description of the account.

NOTE

Due to a terminology mismatch between the Redfish standard and historical iLO products, the properties for UserName and LoginName are reversed in Redfish vs. the HPE iLO Web interface. The following table provides a detailed description of each property in the different contexts.

Redfish Property	GUI Term	Description	Example
`UserName`	Login Name	The user identity string used with a password to log into iLO	jsmith
`Oem/Hpe/LoginName`	User Name	The descriptive name of the user	Jane Smith - Director of IT

The following example retrieves the properties of iLO user with UserName equal to jsmith.

GET /redfish/v1/AccountService/Accounts/?$filter=UserName eq 'jsmith'

NOTE

Password is always shown as null even though it is a PATCHable property.

Roles and privileges

HPE iLO uses a set of Privileges assigned to each user account to grant and restrict access to features. HPE iLO privileges are:

Redfish	iLO Web Interface (GUI)
LoginPriv	Login
RemoteConsolePriv	Remote Console
VirtualPowerAndResetPriv	Virtual Power and Reset
VirtualMediaPriv	Virtual Media
HostBIOSConfigPriv	Host BIOS
iLOConfigPriv	Configure iLO Settings
UserConfigPriv	Administer User Accounts
HostNICConfigPriv	Host NIC
HostStorageConfigPriv	Host Storage
SystemRecoveryConfigPriv	Recovery Set

Application accounts

Application accounts have been introduced with HPE Gen12 servers including an iLO 7. These accounts and associated application token allow host based applications (i.e. AMS, iSUT, SUM, iLOrest) to get authenticated for in-band communication, by the iLO Redfish service without requiring any human being intervention for supplying iLO credentials.

Refer to the Transitioning to HPE iLO 7 section for more detail on those specific accounts.

Roles

You can use RoleId property to create users with specific starting privileges.

On a GET of the local user account, RoleId is synthesized based upon the enabled privileges. iLO does not store a separate RoleId value. For this reason, modifications to raw privileges may or may not result in a changed RoleId based upon iLO's mapping.

If the PATCH includes both RoleID and individual privileges, the privileges corresponding to the RoleId are assigned to the local user account first, and then the explicit privileges are assigned.

The following example sets all iLO privileges as long as the account performing the operation already has sufficient privileges to grant these privileges.

PATCH /redfish/v1/AccountService/Accounts/{accountId}

Privileges granted on Local Account Creation by RoleId

RoleId	Privileges
Administrator	HostBIOSConfigPriv, HostNICConfigPriv, HostStorageConfigPriv, LoginPriv, RemoteConsolePriv, UserConfigPriv, VirtualMediaPriv, VirtualPowerAndResetPriv, iLOConfigPriv
Operator	HostBIOSConfigPriv, HostNICConfigPriv, HostStorageConfigPriv, LoginPriv, RemoteConsolePriv, VirtualMediaPriv, VirtualPowerAndResetPriv
ReadOnly	LoginPriv

RoleId shown on an existing Local User Account by Privilege

The RoleId reported is the smallest superset of assigned privileges.

Privileges	RoleId
LoginPriv only	ReadOnly
iLOConfigPriv or UserConfigPriv or SystemRecoveryConfigPriv and anything else	Administrator
any other combination	Operator

Creating a new Local User Account

The simplest possible new local user account create operation is to POST to the Accounts collection, as shown in the example below.

The following example creates a user account jsmith with the default ReadOnly RoleId and only the iLO Login privilege. Notice that Oem/Hpe/LoginName defaults to the provided UserName unless it is specifically specified.

POST /redfish/v1/AccountService/Accounts/

NOTE

Each local user account must have a unique UserName.

GET /redfish/v1/AccountService/Accounts/{accountId}

Creating a new Account using a RoleId

You may specify a RoleId with a new user account, as shown in the following example.

POST /redfish/v1/AccountService/Accounts/

To retrieve the just created account, perform a GET operation like in the following example.

GET /redfish/v1/AccountService/Accounts/{accountId}

Creating a new account with specific privileges

You may also create a local user with specific privileges.

POST /redfish/v1/AccountService/Accounts/

Payload:
{
    "UserName": "jsmith",
    "Password": "passwordexample",
    "Oem": {
        "Hpe": {
            "LoginName": "Director of IT",
            "Privileges": {
            "LoginPriv": true,
            "VirtualMediaPriv": true,
            "VirtualPowerAndResetPriv": true
            }
        }
    }
}

This results in the following new local user account:

GET /redfish/v1/AccountService/Accounts/{accountId}

Info

Several Python examples have been posted in the GitHub repository of the HPE Redfish library.

Modifying a Local User Account

The following properties are modifiable on an existing local user account:

UserName
Password - this is always returned as null, but you may PATCH it with a value to change the password
RoleId - PATCHing RoleId on an existing local user account will reset it’s existing privileges with those mapped to the RoleId.
Oem/Hpe/LoginName
Oem/Hpe/Privileges/* - any of the privileges may be modified with true or false

Adding and Removing Privileges

Local user account privileges may be modified with a PATCH to the URI of the desired ManagerAccount resource, as shown in the example below.

PATCH /redfish/v1/AccountService/Accounts/{accountId}/

Changing Roles

PATCH /redfish/v1/AccountService/Accounts/{accountId}/

Changing Password

Local user account passwords may be modified with a PATCH to the URI of the desired ManagerAccount resource, as shown in the example below.

PATCH /redfish/v1/AccountService/Accounts/{accountId}/

Enabling and Disabling User Accounts

The property Enabled, listed under the URI redfish/v1/AccountService/Accounts/{AccountId} allows an account with administrator privileges to enable or disable other iLO Accounts. Enabled admin accounts are able to perform GET and PATCH operations on the URI. Accounts that are not enabled cannot perform GET and PATCH operations. If the Enabled property is set to True, you are able to login and access HPE iLO. If the Enabled property is set to False, you will not be able to login and access iLO.

Perform GETon the URI redfish/v1/AccountService/Accounts/{AccountId}

GET redfish/v1/AccountService/Accounts/{AccountId}

A local user account can be enabled or disabled with a PATCH to the URI of desired ManagerAccount resource, as shown in the example below.

PATCH redfish/v1/AccountService/Accounts/{AccountId}

Default iLO factory account

When HPE iLO is reset to factory defaults using iLOrestfactorydefaults, the Redfish action or using the System Utilities/iLO Configuration Utility menu, all user setting data are erased. Default credentials are required to access HPE iLO after a factory reset.

The following example sets default HPE iLO username and password after an iLO factory reset action .

curl --insecure --silent --user <ilo-user>:password \
     --header 'Content-Type: application/json'      \
     --request PATCH 'https://<ilo-ip>/redfish/v1/AccountService' \
     --data '{
    "Oem": {
        "Hpe": {
            "DefaultUserName": "administrator",
            "DefaultPassword": "DefaultFactoryPassword" }}
                }'

Removing a Local User Account

A local user account can be removed with a DELETE to the URI of desired ManagerAccount resource, as shown in the example below.

 DELETE /redfish/v1/AccountService/Accounts/{accountId}/

Directory Authentication

Local users authentication

The following example disables local users authentication.

NOTE

Disabling local user authentication is not allowed when both Directory Authentication AND Kerberos Authentication are disabled.

PATCH /redfish/v1/AccountService/

Payload:
{
    "LocalAccountAuth": "Disabled"
}

TIP

Use the Enabled value in the above example to enable local users authentication.

Configuring Active Directory Authentication

The following example enables authentication by a Microsoft Active Directory service using default standard port 636.

PATCH /redfish/v1/AccountService/

The following example enables authentication by a Microsoft Active Directory using a custom TCP/UDP port.

NOTE

In order to use a custom port for directory authentication, you need first to send a PATCH request with the custom port mentioned in the ServiceAddresses[] array, as shown in step 1 of the below example.

Then, you have to remove the custom port and send the PATCH request again as mentioned in step 2 below.

The first step populates the Oem.Hpe.DirectorySettings.LdapServerPort read-only property, but keeps the port number in the ServiceAddresses[] array, which makes it redundant.

The second step removes the redundant port number in the ServiceAddresses[] array.

PATCH /redfish/v1/AccountService/

Configuring generic LDAP Authentication

The following example enables authentication by a generic LDAP service using the default TCP/UDP port 636.

PATCH /redfish/v1/AccountService/

The following example enables authentication by a generic LDAP service using a custom TCP/UDP port.

NOTE

Then, you have to remove the custom port and send the request again as mentioned in step 2 below.

The first step populates the Oem.Hpe.DirectorySettings.LdapServerPort read-only property, but keeps this port number in the ServiceAddresses[] array.

The second step removes the redundant port number in the ServiceAddresses[] array.

PATCH /redfish/v1/AccountService/

Disable Active Directory and generic LDAP Authentication

PATCH /redfish/v1/AccountService/

Enable and configure HPE Extended Schema Authentication (Active Directory only)

PATCH /redfish/v1/AccountService/

Add User Search Contexts

The following example shows two possibilities to add user search contexts The first one (Body 1) adds two new User Search Contexts, with no already existing User Search Context present. The second one (Body 2) adds a new User Search Context, with two existing User Search Contexts present.

PATCH /redfish/v1/AccountService/

Delete User Search Contexts

The following example shows two possibilities to delete User Search Contexts. The first one (Body 1) deletes one/multiple User Search Contexts: Assume you have three existing User Search Contexts, e.g. "CN=Users,DC=domain,DC=com", "DC=domain,DC=com" and "DC=testdomain,DC=com". To delete one, exclude it from the payload and keep the ones to be retained.

The second one (Body 2) deletes all User Search Contexts.

PATCH /redfish/v1/AccountService/

Import LDAP Server CA Certificate

POST /redfish/v1/AccountService/ExternalAccountProviders/LDAP/Certificates/

View LDAP Server CA Certificate Status

GET /redfish/v1/AccountService/?$select=Oem/Hpe/DirectorySettings/LdapCaCertificateLoaded`

View LDAP Server CA Certificate Details

NOTE

The LDAP provider supports a single certificate

GET /redfish/v1/AccountService/ExternalAccountProviders/LDAP/Certificates/{certId}/

Add new Directory Groups (No Existing Groups)

NOTE

"Administrator" and "Operator" are predefined Redfish RoleIds. "LDAP" can also be used instead of "ActiveDirectory".

PATCH /redfish/v1/AccountService/

View Directory Groups

GET /redfish/v1/AccountService/?$select=LDAP/RemoteRoleMapping, ActiveDirectory/RemoteRoleMapping`

Add New Directory Groups to Existing Groups

In the following example, assume that two directory groups are already present (TestGroup1 and TestGroup2). Use the LocaleRole and RemoteGroup values for the existing directory groups in the payload. Add an additional group "TestGroup3" with "ReadOnly" Redfish Role. "LDAP can also be used instead of "ActiveDirectory".

PATCH /redfish/v1/AccountService/

Delete Directory Groups

In the following example, assume you have three existing directory groups, e.g. "TestGroup1", "TestGroup2" and "TestGroup3". To delete "TestGroup3", exclude it from the payload and keep the ones to be retained. "LDAP" can also be used instead of "ActiveDirectory". It shows how to delete one/multiple Directory Groups (Body 1) or all Directory Groups (Body 2).

NOTE

"LDAP" can also be used instead of "ActiveDirectory"

PATCH /redfish/v1/AccountService/

View Directory Group Privileges

GET /redfish/v1/AccountService/Roles/

Modify Directory Group Privileges

Sample Body 1 (Update AssignedPrivileges): Add/Remove the privileges in the AssignedPrivileges[] array. Sample Body 2 (Update OemPrivileges): Add/Remove the privileges in the OemPrivileges[] array.

PATCH /redfish/v1/AccountService/Roles/{directoryGroupId}/

Enable, Configure, Disable Kerberos Authentication

PATCH /redfish/v1/AccountService/

Import Kerberos Keytab File

POST /redfish/v1/AccountService/Actions/Oem/Hpe/HpeiLOAccountService.ImportKerberosKeytab/

Start Directory Test

POST on /redfish/v1/AccountService/DirectoryTest/Actions/HpeDirectoryTest.StartTest/

Stop Directory Test

POST /redfish/v1/AccountService/DirectoryTest/Actions/HpeDirectoryTest.StopTest/

View Directory Test Result

GET /redfish/v1/AccountService/DirectoryTest/