How to reset/recover Integrated Lights Out Manager (ILOM) password

2025年7月23日 LOG admin

The default user and password of Oracle ILOM (Integrated Lights Out Manager) is root / changeme. If someone already changed the password and it has since been lost, the service processor will not accept root/changeme any more. This guide gives the step-by-step procedure to recover or reset the ILOM password on Oracle (formerly Sun) SPARC servers, including the physical-presence button location for each T-series model, the default-account workaround, and the ILOM CLI commands that recreate the root account.

Try ipmitool first

Before pulling out the serial cable, attempt a password reset from the host operating system or a management station that has the server's service processor in reach. If the ILOM user exists and IPMI is enabled, a single command can change it:

ipmitool -I lanplus -H <ILOM-IP> -U root -P <old-password> user set password 2 <new-password>

This only works when you still know some credential with administrator privilege, or when a serial-over-LAN session is already authenticated. If it fails, use the serial console and physical-presence procedure below.

Two details make the difference between this working and not. First, the trailing number is a user ID, not a username — list the users before you change anything, because the ID for root is not always 2:

ipmitool -I lanplus -H <ILOM-IP> -U root -P <old-password> user list
ID  Name       Callin  Link Auth  IPMI Msg   Channel Priv Limit
1   anonymous  false   false      true       NO ACCESS
2   root       true    false      true       ADMINISTRATOR

Second, the service processor only answers IPMI over the network if the interface has been enabled — on a hardened ILOM, RMCP+ is often switched off. You can also reach the SP in-band from the host operating system, using the internal KCS interface the operating system exposes as /dev/ipmi0:

# ipmitool -I open user list
# ipmitool -I open user set password 2 <new-password>

This works on Solaris and Oracle Linux hosts where the local IPMI driver is loaded, and it is the fastest way out when the network path to the SP is broken but the operating system is still running. It cannot help you when the host itself will not boot — which is exactly the case the rest of this article is written for.

Important notes

You must be physically present at the server to perform this recovery — it is deliberately impossible to do remotely.
The procedure uses the built-in default user account to recover a lost password or to re-create the root account.
You cannot change or delete the default user account; it exists purely for this kind of emergency access.

The two preconfigured accounts, and what each is for

ILOM ships with exactly two preconfigured local accounts, and understanding the split saves a lot of confusion during a recovery:

root — the persistent Administrator account, password changeme from the factory. This is the account you log in with every day, the one you are supposed to change and the one you have lost.
default — the password-recovery account, password defaultpassword. It cannot be changed, cannot be deleted, and has no purpose other than letting someone who is physically present at the chassis reset an administrator account.

Both accounts exist on ILOM 3.x, 4.x and the current 5.x firmware generations, so the procedure below still applies to a SPARC T7 or an Oracle x86 server running current firmware — the parts that differ are the button you press and the prompts around it. When you re-create or repair an administrator account, remember that ILOM local users carry a role: Administrator grants full control, Operator is read-only plus a few actions, and Callback is for dial-out use. A recovered account that has the right password but the wrong role will authenticate and still refuse to change anything.

Step 1 – Connect to ILOM over the serial console

Attach a serial (or SER MGT) cable to the server, open your terminal at 9600 8N1, and log in using the default user account:

SUNSP-xxxxxxxx login: default

You will be prompted to press and release the physical-presence button:

Press and release the physical presence button.
Press return when this is completed...

If the login is refused rather than accepted, stop here and check two things: that you are on the SER MGT port and not the NET MGT port (the SER MGT port is the one that always answers, even when the network configuration is unknown), and that the terminal is at 9600 8N1 with no flow control. A wrong baud rate usually shows as garbage rather than as a rejected login, but a hardware handshake mismatch can show up as a login that never completes.

Step 2 – Prove physical presence at the server

Press and release the physical-presence button. On Sun SPARC Enterprise T5xxx servers and X-series systems this button is the Locator button. The exact location differs by model:

On Sun SPARC Enterprise T5xxx and X-series servers: the Locator button.
SPARC T3-1 / T4-1: (rear) pin-hole to the left of the USB ports.
SPARC T3-2 / T4-2: (rear) pin-hole to the left of NET0.
SPARC T3-4 / T4-4: (rear) to the right of the OK LED, above the USB port.
SPARC T3-1b / T4-1b: (front) Locate button / Physical Presence (white LED).

After pressing the button, return to your serial console and press Enter. You will be prompted for a password.

Because the pin-hole buttons on the T3/T4 rack servers are small and unlabelled, use a straightened paper clip and press until you feel the switch click, then release immediately. Holding the button down is not required and, on some models, holding the Locator button for a long time triggers the locator LED instead of the physical-presence event. The definitive check is the console: when the SP has registered the press, the password prompt appears. If it does not, press the button again — a second press within the same session is accepted.

Step 3 – Log in with the default account password

Type the password for the default user account, which is:

defaultpassword

Note that this is the password for the default account used only for recovery — it is not related to the root account you are trying to recover. It is also case-sensitive and has no trailing period. Copy it carefully; three failed attempts in a row will lock the account for a lockout interval, which forces you to wait before you can try again.

Step 4 – Reset the password or re-create the root account

Once you are at the ILOM CLI (the -> prompt), set a new password for the root user. If the account was deleted, re-create it and give it administrator role:

-> set /SP/users/root password
Enter new password: ********
Enter new password again: ********

If the root user no longer exists and you need to recreate it before setting the password:

-> create /SP/users/root
-> set /SP/users/root role=Administrator
-> set /SP/users/root password
Enter new password: ********
Enter new password again: ********

The CLI also accepts the password inline, which is handy when you are scripting the change from a jump host or automating the same fix across a rack of servers:

-> set /SP/users/root password=<new-password>
Changing password for user /SP/users/root

Be aware that an inline password lands in your shell history and, potentially, in a terminal log. For interactive work prefer the prompted form above; for scripted work, pass the value in from an environment variable and clear your history afterwards.

Step 5 – Verify the new root password

Log out of the default session and log back in as root with the password you just set. A clean login confirms the reset:

-> exit
SUNSP-xxxxxxxx login: root
Password:
-> show /SP/users/root

The show command should list the root account with its role. From a remote workstation you can also confirm over SSH or the web interface at https://<ILOM-IP>/.

Re-creating, locking and listing accounts

The recovery path re-creates root, but the same /SP/users targets manage every local account, and knowing them makes the rest of the cleanup straightforward:

-> show /SP/users
/SP/users
    Targets:
        default
        root

-> show /SP/users/root
    Properties:
        role = Administrator
        password = *****

-> create /SP/users/opsadmin
-> set /SP/users/opsadmin role=Administrator
-> set /SP/users/opsadmin password
-> set /SP/users/opsadmin cli_mode=cli

Two behaviours surprise people here. First, an account that has been created but never given a password cannot be used — ILOM lists it but rejects the login. Second, deleting and re-creating a user resets that user's SSH keys and any per-user properties, so if the environment authenticated with SSH public keys, those keys have to be re-imported after the account is rebuilt. If you only needed to unlock an account that had been locked by failed logins, you do not need to delete it: setting the password as shown in Step 4 is enough to clear the lockout.

Reset the ILOM configuration to factory defaults

When the root account cannot be repaired — for example when the account database itself has been corrupted, or when no administrator account exists and setting the password fails — the fallback is to return the service processor to its factory configuration. This wipes ILOM's own settings: users you created, network configuration, alert rules, LDAP and RADIUS settings, and the ILOM-specific preferences. It does not touch the server's operating system or data.

-> set /SP reset_to_defaults=all
-> reset /SP
Are you sure you want to reset the SP? (y/n) y

After the SP finishes rebooting — typically two to five minutes — the preconfigured accounts are back, so root with changeme works again (assuming the platform's firmware still ships that default). Plan for reconnecting the SER MGT console and reconfiguring the network settings, because the SP will no longer be reachable at its old address. Because this is destructive to the management configuration, capture a backup first if you can reach the CLI at all:

-> dump -destination /SP/backup/ilom-backup.xml
-> set /SP/backup/ ...   (or pull the file off with the web interface)

Note that a factory reset does not help if the reason you cannot log in is that the SP itself is unhealthy — a hung SP will not answer the CLI, and the recovery in that case is a full SP power cycle or an ILOM firmware recovery, not a password fix.

Resetting the root password from the ILOM Preboot menu

On several x86 platforms that use ILOM as their service processor — the X4170, X4270, X4275 and their successors — the SP has a preboot menu that can restore the root password to the factory default without a serial-presence handshake. Connect to the serial console, power-cycle the server, and press the key that interrupts the SP boot when the prompt appears; inside the preboot menu, choose the option that resets the password to the factory default, and let the SP continue booting. This route depends on the platform and the firmware generation, so treat it as a convenient alternative rather than a guarantee, and check the server's own documentation for the key sequence your model expects.

After recovery: verify and harden the account

Getting back in is only half the job. Work through this list before you walk away:

Confirm you can authenticate as root on the serial console, over SSH and in the web interface — three different front-ends, three different failure modes.
Confirm the role is Administrator with show /SP/users/root; an account recovered with the wrong role will let you in and then refuse every change.
Re-check any SSH public keys the account had, and re-import them if the account was deleted and re-created.
Change any credential that the recovery session exposed. If the new password was typed at a shared console or written into a ticket, change it again now.
Confirm the ILOM network settings survived: the SER MGT address, the NET MGT address and the DNS configuration are frequently lost in a factory reset and always worth verifying after any recovery.
Where the account database is managed centrally, verify that LDAP, Active Directory or RADIUS authentication still works, and that the local root account remains as the break-glass fallback rather than the everyday path. The differences between the major out-of-band controllers — and where each one keeps its credentials — are compared in iDRAC vs iLO vs IPMI: Out-of-Band Server Management Guide.
Record the new password in the password vault, and record the fact that the recovery account was used. The next person to need it will thank you.

Troubleshooting

Physical-presence prompt times out: you must press the button within the timeout and press Enter immediately afterwards. Repeat the whole sequence from login if it expires.
Wrong model button: on T3/T4 rack servers the pin-hole is on the rear; on 1b blade-style systems it is a front Locator button. Refer to the table above.
Serial console shows nothing: confirm 9600 8N1 with no flow control and that you are on the SER MGT / console port, not a USB management port.
Account locked out entirely: if the SP is unresponsive, a full SP reset from the service processor's own recovery path may be required before the default-account procedure will work.
The default login is rejected: you are most likely on the wrong port, at the wrong speed, or the SP is in a state where the recovery account has not been loaded. Wait for the SP to finish booting before you try again; the login prompt appears before ILOM is fully ready on some platforms.
set /SP/users/root password reports an invalid target: the account was deleted. Re-create it, set the role, then set the password, exactly as in Step 4.
The web interface refuses to load after a successful CLI reset: the browser is holding a stale session or the SP has not restarted its web services. Close the browser, or reload the SP with reset /SP.
Everything works but the host will not boot: ILOM access and host booting are separate problems. Check the host console output over the SP's console redirection rather than the ILOM CLI itself.

FAQ

Can this be done remotely? No. The physical-presence step exists precisely to prevent a remote attacker with a stolen credential from taking over the service processor, so the recovery path requires a human at the chassis. Plan a site visit or a remote-hands request.

Is the default account a security risk? It is a deliberate, documented break-glass account with a fixed password, and it can only be used by someone who is already standing at the server. Treat physical access to the chassis as part of your security boundary — which it always was.

Does a password reset interrupt the running host? The default-account procedure does not reboot the host and does not touch the operating system. The factory-reset route does not reboot the host either, but it does drop the SP for several minutes, which takes out your remote console and power control while it restarts.

What if the root account was deleted deliberately? The recovery account can re-create it. That is why you should not delete root and rely solely on named administrator accounts — the preconfigured account is the one path that always remains.