IPMI, iLO, and iDRAC for Remote Management

By Kokil Thapa | Last reviewed: September 2026

When SSH dies and the kernel panics, you need IPMI, iLO, and iDRAC for remote management to recover the machine without driving to a data centre. These out-of-band interfaces sit on a separate management controller that stays alive when the host OS is down. On production deployments I maintain, that separation has saved hours during disk failures, bad kernel upgrades, and firewall lockouts. This guide covers how each platform works, how to secure it, and what to do when the main network path is gone. If you run bare-metal or colocated servers alongside cloud workloads, read our Linux system administration service overview for the full operational picture.

What is IPMI, and how do iLO and iDRAC relate to it?

IPMI stands for Intelligent Platform Management Interface. It is an open standard, originally from Intel, that defines how a Baseboard Management Controller (BMC) talks to the host and to administrators. The BMC is a small computer on the motherboard. It has its own CPU, RAM, and network port. It runs even when the main server is powered off.

iLO (Integrated Lights-Out) is HPE's proprietary implementation built on IPMI concepts. iDRAC (integrated Dell Remote Access Controller) is Dell's equivalent. Both extend the baseline with richer web UIs, virtual media, and licensing tiers. Supermicro, Lenovo, and other vendors ship plain IPMI firmware or their own branded consoles.

The practical difference matters when you buy hardware. Generic IPMI often ships with a basic web UI and IPMI-over-LAN on port 623. HPE iLO 5 and iLO 6 add HTML5 remote console, firmware update workflows, and directory integration on higher licence tiers. Dell iDRAC9 and iDRAC10 offer similar features with Enterprise licences unlocking virtual media and automated inventory.

Core capabilities shared across platforms

• Remote power on, off, cycle, and graceful shutdown
• Serial-over-LAN and HTML5 or Java KVM console
• Virtual media to mount ISO images for OS installs
• Hardware sensor readings: temperature, fan speed, voltage
• Event logs and SEL (System Event Log) for diagnostics
• User account management on the BMC itself

None of this replaces your application layer. It sits below the OS. That is exactly why it survives when Ubuntu user management and SSH access are both broken.

How do IPMI, iLO, and iDRAC compare for remote server management?

Choosing between them is rarely a software decision. You get whatever BMC your hardware vendor ships. Still, knowing the trade-offs helps when you spec servers or audit an existing rack.

Redfish is a modern REST-based management standard from DMTF. Both HPE and Dell push Redfish on current generations. Legacy IPMI commands still work through compatibility layers. For automation, Redfish is cleaner than parsing IPMI hex output.

How do you configure IPMI, iLO, and iDRAC on a new server?

First boot is the easiest window to set management credentials. Most servers expose a BIOS setup prompt for BMC configuration. Miss it, and you may need physical access or a factory reset jumper.

Initial setup checklist

1. Connect the dedicated management NIC to a switch port on an isolated VLAN.
2. Boot into BIOS or UEFI setup and locate BMC, iLO, or iDRAC settings.
3. Assign a static IP on the management subnet or reserve a DHCP lease.
4. Change the default password immediately. Factory defaults are well known.
5. Disable unused protocols: disable IPMI v1.5 if only v2.0 is needed.
6. Update BMC firmware before putting the server into production.
7. Document the management IP, credentials location, and licence tier.

For generic IPMI from Linux on the host itself, install ipmitool and configure the channel:

sudo apt install ipmitool freeipmi-tools

ipmitool lan print 1

sudo ipmitool lan set 1 ipsrc static
sudo ipmitool lan set 1 ipaddr 10.10.99.50
sudo ipmitool lan set 1 netmask 255.255.255.0
sudo ipmitool lan set 1 defgw ipaddr 10.10.99.1

sudo ipmitool user set name 2 admin
sudo ipmitool user set password 2 'LongRandomPassw0rd!'
sudo ipmitool user enable 2
sudo ipmitool channel setaccess 1 2 callin=on ipmi=on link=on privilege=4

On HPE, use the iLO web UI or hponcfg with an XML config file. On Dell, browse to the iDRAC IP and run the first-time wizard, or use racadm setniccfg from a bootable lifecycle controller environment.

Store BMC passwords in your secrets vault, not in plain-text wiki pages. Treat them like root credentials. Our guide on secrets management with HashiCorp Vault covers patterns that apply here. Generate strong credentials with a password generator and rotate them on the same schedule as root passwords.

Network layout that works in production

Never bridge the management interface to your public-facing subnet. A common pattern I've used on colocated racks in Kathmandu and on international hosting:

• Management VLAN (e.g. 10.10.99.0/24) reachable only via VPN or jump host
• Firewall rules allowing admin IPs to TCP 443 and optionally UDP 623
• DNS A record like srv01-mgmt.internal.example.com separate from production DNS
• SNMP disabled unless you actively monitor via an internal NMS

This mirrors the isolation principles in CI/CD secrets management best practices. The BMC is a high-value target. An attacker with IPMI access owns the hardware regardless of disk encryption.

How do you secure IPMI, iLO, and iDRAC against attacks?

BMC interfaces have a terrible security history. Researchers have found default credentials, cipher downgrade bugs, and unauthenticated firmware uploads on multiple vendors. Shodan regularly indexes exposed IPMI ports. Treat every BMC as a root-equivalent backdoor.

Non-negotiable hardening steps

• Change default usernames and passwords before the server touches any network.
• Place the management NIC on a private VLAN with no default gateway to the internet.
• Disable IPMI-over-LAN on the production-facing NIC if the board shares ports.
• Enable TLS 1.2 or higher and replace factory self-signed certs with internal CA certs.
• Disable anonymous authentication and cipher suite zero (IPMI v2.0 only).
• Apply BMC firmware updates on the same cadence as OS security patches.
• Audit BMC user accounts quarterly and remove departed staff access.

The Intel IPMI specification defines authentication modes, but firmware quality varies by vendor. Scan your management subnet with an internal vulnerability scanner. CVEs affecting iLO and iDRAC appear regularly on NVD.

For certificate management on internal CAs, see our PKI and certificate management basics article. HPE and Dell both accept uploaded certificates through their web UIs or CLI tools.

Generate unique passwords per host. Reusing one BMC password across twelve servers means one leak compromises the entire rack. This is the same principle as multi-cloud secrets management, applied at the hardware layer.

How do you recover a server using IPMI, iLO, or iDRAC when SSH fails?

This is where out-of-band management pays for itself. The scenario is familiar: a bad iptables rule, a failed glibc upgrade, or a full disk on / that prevents SSH from starting.

Step-by-step recovery workflow

1. Connect to the BMC web UI or VPN into the management network.
2. Check power state and the System Event Log for hardware faults first.
3. Open the remote KVM console and watch the boot process.
4. If the OS is hung, issue a power cycle (not just reboot) from the BMC.
5. Boot into single-user mode or a rescue ISO via virtual media if filesystem repair is needed.
6. Fix the issue, verify SSH on the production NIC, then close the console session.

From the command line on your admin workstation with IPMI access:

ipmitool -I lanplus -H 10.10.99.50 -U admin -P 'secret' power status
ipmitool -I lanplus -H 10.10.99.50 -U admin -P 'secret' power reset
ipmitool -I lanplus -H 10.10.99.50 -U admin -P 'secret' sol activate

Dell iDRAC equivalents via racadm:

racadm -r 10.10.99.12 -u root -p 'secret' serveraction powercycle
racadm -r 10.10.99.12 -u root -p 'secret' console view

On HPE iLO, the RESTful API or web console handles the same tasks. For scripted power operations in deployment pipelines, combine BMC calls with Laravel Envoy for remote task automation patterns on the application side.

I've used this exact path after a failed PHP-FPM config locked me out of a colocated box at 2 AM Nepal time. The production NIC was dead. The iLO interface came up fine. Virtual media booted an Ubuntu live ISO, I chrooted in, fixed the config, and rebooted. Total downtime was under twenty minutes.

Cloud VMs on AWS or similar do not expose IPMI. You use the provider's serial console or instance recovery features instead. For hybrid setups, document which machines have BMC access and which rely on cloud consoles. Our Adventure Third Pole Trek deployment runs on managed cloud, but sister legal-tech sites on shared EC2 still benefit from knowing when bare-metal BMC is the right tool.

What are common IPMI, iLO, and iDRAC mistakes to avoid?

Most BMC incidents I see are configuration errors, not hardware failures. Avoid these patterns.

Exposing management ports to the internet

Port 623 and BMC HTTPS interfaces get scanned constantly. If your hosting provider assigns a public IP to the management NIC, request a private VLAN or re-cable. Check with nmap from an external host after setup.

Shared NIC mode without understanding failover

Some boards multiplex management and production traffic on one physical port. A misconfigured switch can leak IPMI to the wrong VLAN. Prefer dedicated management ports when the hardware supports them.

Ignoring firmware updates

BMC firmware ages silently. Vendors patch critical CVEs in iLO and iDRAC releases. Schedule quarterly BMC update windows separate from OS patching. Test on one host before rolling across a cluster.

Skipping monitoring integration

Pull sensor data into your existing monitoring stack. High inlet temperature or a failed fan predicts downtime before the OS notices. Tools like Prometheus exporters for Redfish exist for Dell and HPE current generations. Pair this with log rotation and disk space management on Linux on the host side for full coverage.

No documented break-glass procedure

Write a one-page runbook: management IP, VPN steps, default recovery ISO, and who holds credentials. Store it where on-call can reach it when the wiki server itself is down. Offline copies matter.

For teams without in-house ops capacity, support and maintenance services can include BMC monitoring and firmware cadence as part of a managed hosting agreement. Pair that with domain registration and hosting when you are standing up new infrastructure.

Key Takeaways

• IPMI is the open standard; iLO and iDRAC are vendor implementations with richer UIs and licensing tiers.
• Always isolate the management NIC on a private VLAN reachable only via VPN or jump host.
• Change default BMC credentials and apply firmware updates before the server goes live.
• Use remote KVM and virtual media to recover when SSH, Docker, or the host OS is unreachable.
• Automate power and sensor checks with ipmitool, racadm, or Redfish APIs in your runbooks.
• Cloud VMs use provider consoles; BMC access applies to bare-metal, colocation, and dedicated servers.

People Also Ask

Can IPMI work when the server is powered off?

Yes. The BMC draws standby power from the PSU and remains online when the host is off. You can power on the server remotely, configure BIOS settings, and access the console before the OS boots. That is the core value of out-of-band management.

Is iLO the same as IPMI?

iLO implements IPMI commands and extends them with HPE-specific features. You can still use standard ipmitool against many iLO versions. Day-to-day admin usually goes through the iLO web UI or Redfish API on newer ProLiant generations.

What port does IPMI use?

IPMI-over-LAN typically uses UDP port 623. Web interfaces for iLO and iDRAC use HTTPS on port 443. Some setups also expose SSH on port 22 for CLI access. Restrict all of these to trusted admin networks only.

Do I need IPMI if I already have cloud servers?

Cloud instances do not expose IPMI, iLO, or iDRAC. You only need BMC access for physical hardware you own or colocate. Hybrid teams should document which recovery path applies to each machine to avoid confusion during incidents.

Build infrastructure you can recover from anywhere

IPMI, iLO, and iDRAC for remote management are not optional extras on bare-metal production servers. They are your last-resort recovery path when everything above the BMC layer fails. Configure them on day one, isolate them on a management VLAN, and test the console before you need it at 2 AM. If you are standing up dedicated servers for a Laravel application, eCommerce platform, or enterprise application, build BMC hardening into the provisioning checklist from the start. Need hands-on help with server provisioning, testing and optimization, or ongoing ops? Contact us to discuss your infrastructure setup. For background on how I work with production systems, see about me or browse the home page.