Learn › BMC & Server Management › First Day on the Floor
The factory ADMIN password cannot go to production. Learn BMC account slots and IPMI privilege levels with interactive diagrams, then provision a named operator account on a live BMC entirely over IPMI: name the slot, set the password, grant OPERATOR, enable it, and log in as the new user to prove it works at its own level.
It is 07:40 at the DC-EAST facility in Ashburn, Virginia. The Dell PowerEdge R750xs in Bay 14, Row 7 passed first contact yesterday; Work Order DC-EAST-WO-1001 is closed and filed. This morning the security sweep flagged the same machine before it could join the production pool.
The finding is one line: the BMC still answers to the factory ADMIN / ADMIN login, and the entire floor shares that password.
There is a deadline attached. A new technician, Dana Reyes, starts on this row Monday, and she needs her own credentials on this controller before her first shift. Work Order DC-EAST-WO-1002: provision a named operator account on the Bay 14 BMC and prove it works, at exactly the access level the job requires and not one rung more.
This is a Practice Zone. The diagrams below react to you: click the boxes, flip the switches. The real machine comes at the end, under Ready to practice.
Why does a shared password on a management controller fail an audit? Because the BMC is the one computer that records everything done to the server: every power cycle, every reset, every configuration change lands in its event log stamped with the account that did it.
Now follow that sentence to its weak point. If everyone logs in as ADMIN, the only name the log can ever record is ADMIN.
{ "height": 360, "caption": "Flip the account model and watch what the audit log can actually say.", "nodes": [ { "id": "tech1", "label": "Alis (day)", "kind": "admin", "x": 0, "y": 40, "detail": "Day-shift technician. One of three people who know the ADMIN password." }, { "id": "tech2", "label": "Marcus (swing)", "kind": "admin", "x": 0, "y": 170, "detail": "Swing-shift technician. Same password, same login, same identity as far as the BMC knows." }, { "id": "tech3", "label": "Priya (night)", "kind": "admin", "x": 0, "y": 300, "detail": "Night-shift technician. If she power-cycles a server at 03:12, the log entry looks identical to anyone else's." }, { "id": "cred", "label": "ADMIN / ADMIN", "kind": "net", "x": 300, "y": 170, "detail": "One factory password, taped to the whole team. Every login through it collapses three people into a single identity." }, { "id": "bmc", "label": "BMC", "kind": "bmc", "x": 600, "y": 170, "detail": "The controller authenticates the ACCOUNT, not the human. It has no idea whose fingers were on the keyboard." }, { "id": "log", "label": "Audit log (SEL)", "kind": "host", "x": 880, "y": 170, "detail": "The BMC records WHO did WHAT. But the only who it knows is the account name. Shared account, shared blame." } ], "edges": [ { "from": "tech1", "to": "cred", "kind": "mgmt" }, { "from": "tech2", "to": "cred", "kind": "mgmt" }, { "from": "tech3", "to": "cred", "kind": "mgmt" }, { "from": "cred", "to": "bmc", "label": "one identity", "kind": "oob" }, { "from": "bmc", "to": "log", "label": "logged as: ADMIN", "kind": "plain" }, { "from": "tech1", "to": "bmc", "label": "alis", "kind": "mgmt" }, { "from": "tech2", "to": "bmc", "label": "marcus", "kind": "mgmt" }, { "from": "tech3", "to": "bmc", "label": "priya", "kind": "mgmt" } ], "toggle": { "label": "Accounts:", "on": "Named per operator", "off": "Shared ADMIN", "dimOn": ["cred", "e:tech1-cred", "e:tech2-cred", "e:tech3-cred", "e:cred-bmc", "e:bmc-log"], "dimOff": ["e:tech1-bmc", "e:tech2-bmc", "e:tech3-bmc"] } }
Flip the toggle. With one shared credential, three different people collapse into a single identity before they ever reach the BMC, and the log line at the far end can only say ADMIN. With named accounts, every one of those log lines carries a person.
>>> No way to know. The timestamp narrows nothing: any of the three could have logged in at 03:12, from the floor or from home. And an IP address is not an identity: workstations are shared, addresses get reassigned, and VPN sessions all exit the same gateway. The only who a BMC can testify to is the account name, so the account name has to mean one person.
BMC accounts do not live in /home, and there is no useradd. The controller keeps a fixed table of numbered slots, sized when the firmware was built. Slot 1 is reserved for the anonymous user, disabled on any sane deployment. Slot 2 holds the factory admin account. Every other slot sits empty until someone claims it.
You can read that whole table over the wire, from your workstation, without opening a shell on the BMC. The subcommand is user list 1, riding the same lanplus-and-credentials preamble as every command in this track. On this controller the table is 63 slots deep, so pipe the output through head -6 to pin the first rows that matter:
ipmitool -I lanplus -C 3 -H $BMC_IP -U ADMIN -P ADMIN user list 1 | head -6Type it into the practice terminal:
prompt: ops@dc-east-ws01:~$ answer: ipmitool -I lanplus -C 3 -H $BMC_IP -U ADMIN -P ADMIN user list 1 | head -6 output: ID Name Callin Link Auth IPMI Msg Channel Priv Limit 1 true false false USER 2 ADMIN true false true ADMINISTRATOR 3 true false false Unknown (0x00) 4 true false false Unknown (0x00) 5 true false false Unknown (0x00) hint: Type it exactly: ipmitool -I lanplus -C 3 -H $BMC_IP -U ADMIN -P ADMIN user list 1 | head -6
Drop the head filter and the table keeps going all the way to slot 63, every unclaimed row reading Unknown (0x00): never configured, no name, no access. Real vendor firmware is usually tighter, 10 to 16 slots is the norm, which is why slot discipline matters on a fleet.
Read the columns left to right. ID is the slot number. Name is the account. Callin, Link Auth, and IPMI Msg are per-session capabilities. The one that matters most is the last: Channel Priv Limit, the ceiling, the highest privilege this account can ever hold on this channel. The trailing 1 in the command is the channel itself: user access on a BMC is granted per network channel, and channel 1 is this controller's LAN interface.
One choice worth calling out now: slot 3 and slot 4 are both empty here, but on a live fleet the low slots fill first with reserved and vendor entries. You will provision Dana into slot 4, a clean row nobody else has claimed. On a BMC you name the slot yourself, so pick a free one and own it.
IPMI defines four privilege levels, and every account gets exactly one as its ceiling, per channel:
{ "height": 420, "caption": "Click a rung, then flip the badge and watch the config plane.", "nodes": [ { "id": "adm", "label": "ADMINISTRATOR (4)", "kind": "admin", "x": 0, "y": 10, "detail": "Keys to the controller itself: create and delete accounts, change network settings, update firmware. The level that can mint other levels." }, { "id": "op", "label": "OPERATOR (3)", "kind": "admin", "x": 0, "y": 130, "detail": "Hands: power control, resets, and everything USER can read. Cannot reconfigure the BMC. The right ceiling for a floor technician." }, { "id": "usr", "label": "USER (2)", "kind": "admin", "x": 0, "y": 250, "detail": "Read-only eyes: sensors, event log, inventory. Cannot power-cycle anything." }, { "id": "cb", "label": "CALLBACK (1)", "kind": "admin", "x": 0, "y": 370, "detail": "A relic of dial-up management: the BMC could only call you back over a modem line. Present in the spec, unused in modern facilities." }, { "id": "config", "label": "BMC config: users, network", "kind": "nic", "x": 560, "y": 30, "detail": "The configuration plane of the controller. An account that can reach this can create accounts, so treat this wire as the crown jewels." }, { "id": "power", "label": "Power control", "kind": "psu", "x": 560, "y": 190, "detail": "Power on, power off, cycle, reset. The physical hands of remote management." }, { "id": "read", "label": "Read sensors + SEL", "kind": "sensor", "x": 560, "y": 350, "detail": "Temperatures, fans, voltages, and the event log. The observation plane every level above CALLBACK can reach." } ], "edges": [ { "from": "usr", "to": "read", "kind": "plain" }, { "from": "op", "to": "read", "kind": "plain" }, { "from": "op", "to": "power", "kind": "plain" }, { "from": "adm", "to": "read", "kind": "plain" }, { "from": "adm", "to": "power", "kind": "plain" }, { "from": "adm", "to": "config", "kind": "plain" } ], "toggle": { "label": "dreyes badge:", "on": "OPERATOR", "off": "ADMINISTRATOR", "dimOn": ["adm", "config", "e:adm-read", "e:adm-power", "e:adm-config"] } }
Flip Dana's badge. With ADMINISTRATOR, every wire is live, including the one into user and network configuration, the plane where an account can mint other accounts. With OPERATOR, that wire simply does not exist for her. She can power-cycle a hung server at 3 a.m.; she cannot rewrite the controller that logs her doing it.
>>> OPERATOR. USER cannot power-cycle anything, so she could not do her job. ADMINISTRATOR hands a floor badge the keys to the whole management plane, and the next audit fails twice: once for the shared ADMIN, once for the over-privileged operator. Least privilege is not stinginess; it is matching authority to the job, exactly.
Now provision Dana. ipmitool builds an account the way the protocol actually thinks: a slot is not created in one stroke, it is filled property by property. Three writes claim the slot, three separate facts:
ipmitool -I lanplus -C 3 -H $BMC_IP -U ADMIN -P ADMIN user set name 4 dreyes
ipmitool -I lanplus -C 3 -H $BMC_IP -U ADMIN -P ADMIN user set password 4 IronKey2026
ipmitool -I lanplus -C 3 -H $BMC_IP -U ADMIN -P ADMIN user enable 4The first names slot 4 dreyes. The second sets her password. The third flips the slot on, because a fresh slot is created disabled. Read them as three verbs on one slot number: set name, set password, enable. Miss the enable and the account exists but cannot log in.
This is the universal path. Every IPMI 2.0 BMC on earth speaks user set, so the muscle memory you build here works against a Supermicro, an HPE iLO, a Dell iDRAC, anything. That portability is the whole reason to learn the standard commands first.
Dell also ships a vendor shell (SSH to the BMC, then racadm), and it can build the same account. That path is real and you met it in the last work order, but it is Dell-only and it files users as indexed properties with different syntax. One honest tradeoff: the vendor CLI is sometimes more convenient on Dell iron, the IPMI commands work everywhere. This track teaches the portable path.
Now the catch that breaks real deployments. The slot has a name, a password, and an on switch, but no access level on the LAN channel yet. Granting the rung is its own move, and it is one line:
ipmitool -I lanplus -C 3 -H $BMC_IP -U ADMIN -P ADMIN user priv 4 3 1Read the three numbers right to left: on channel 1, set slot 4 to privilege level 3, which the ladder says is OPERATOR. Until this runs, the roster shows Dana's name with no usable privilege on the channel: an account that exists but cannot act. Then user list 1 shows the finished row:
ID Name Callin Link Auth IPMI Msg Channel Priv Limit
4 dreyes true false true OPERATORName, enabled, and a ceiling of OPERATOR: a complete, least-privilege account, built entirely over the wire.
Building the badge is half the work order. The other half is proving it opens the door, and this is where almost everyone trips the first time.
When ipmitool opens a session it does not ask the BMC what it is allowed to do. It requests a privilege level up front, and unless you say otherwise it silently requests ADMINISTRATOR. The BMC's session gate compares the requested level against the slot's ceiling before a single command runs. Dana's ceiling is OPERATOR, so the default request is above it, and the gate refuses the whole session. Right password, dead session.
The fix is one flag: -L OPERATOR. Request exactly what the badge holds.
{ "height": 360, "caption": "Same badge, two requests. Flip the request and watch the gate.", "nodes": [ { "id": "ws", "label": "dreyes @ dc-east-ws01", "kind": "admin", "x": 0, "y": 170, "detail": "Dana, authenticating with her own username and password. The credentials are correct in both scenarios below." }, { "id": "reqa", "label": "default request: ADMINISTRATOR", "kind": "net", "x": 300, "y": 40, "detail": "ipmitool asks for ADMINISTRATOR unless told otherwise. Most first-time operator logins fail right here, with a perfectly good password." }, { "id": "reqo", "label": "-L OPERATOR", "kind": "net", "x": 300, "y": 300, "detail": "Request exactly what the badge allows. One flag, and the session request fits under the ceiling." }, { "id": "gate", "label": "BMC session gate", "kind": "bmc", "x": 620, "y": 170, "detail": "Compares the requested level against the slot's Channel Priv Limit before any command runs. It never negotiates downward." }, { "id": "refused", "label": "REFUSED", "kind": "host", "x": 900, "y": 40, "detail": "Insufficient privilege: the ceiling working as designed. The session never opens, so not a single command runs." }, { "id": "granted", "label": "Session opens at OPERATOR", "kind": "sensor", "x": 900, "y": 300, "detail": "The session runs at OPERATOR: chassis status and power control work, configuration commands stay out of reach." } ], "edges": [ { "from": "ws", "to": "reqa", "kind": "oob" }, { "from": "ws", "to": "reqo", "kind": "oob" }, { "from": "reqa", "to": "gate", "kind": "mgmt" }, { "from": "reqo", "to": "gate", "kind": "mgmt" }, { "from": "gate", "to": "refused", "label": "asks above the ceiling", "kind": "plain" }, { "from": "gate", "to": "granted", "label": "fits the badge", "kind": "plain" } ], "toggle": { "label": "Session request:", "on": "-L OPERATOR", "off": "ipmitool default", "dimOn": ["reqa", "refused", "e:ws-reqa", "e:reqa-gate", "e:gate-refused"], "dimOff": ["reqo", "granted", "e:ws-reqo", "e:reqo-gate", "e:gate-granted"] } }
And there is one strange line you will see with your own eyes. At OPERATOR level, ipmitool's opening HPM.x capabilities probe (an administrator-grade query it always fires first) gets refused with compcode = d4, IPMI's code for insufficient privilege. Then the command you actually asked for completes anyway:
prompt: ops@dc-east-ws01:~$ answer: ipmitool -I lanplus -C 3 -H $BMC_IP -U dreyes -P IronKey2026 -L OPERATOR chassis status output: Get HPM.x Capabilities request failed, compcode = d4 System Power : off Power Overload : false Power Interlock : inactive Main Power Fault : false Power Control Fault : false Power Restore Policy : always-off Last Power Event : Chassis Intrusion : inactive Front-Panel Lockout : inactive Drive Fault : false Cooling/Fan Fault : false hint: The house form, but the credentials are dreyes / IronKey2026 and you add -L OPERATOR. The subcommand is chassis status.
That d4 line is not an error to fix. It is the privilege ceiling working, visible in your terminal: the one probe that needed ADMINISTRATOR was refused, and everything within OPERATOR ran clean. When you see it during the lab, read it as proof the badge is scoped exactly right.
>>> Refused. Correct password, wrong request: ipmitool asked for ADMINISTRATOR on Dana's behalf, and her ceiling is OPERATOR. BMCs do not negotiate downward; the requested level either fits under the slot's ceiling or the session never opens. An operator badge must ask for an operator session: -L OPERATOR.
Time to do it for real. The BMC address is preset in $BMC_IP, and you still hold the factory ADMIN / ADMIN credentials, legitimately, for now: it takes an administrator to mint an operator.
Six objectives close Work Order DC-EAST-WO-1002:
1. Audit the roster. From your workstation, over the wire, pull the BMC's full account table and see the finding for yourself. 2. Name the slot. Claim slot 4 for dreyes over IPMI. 3. Set the password. Give slot 4 the temporary password IronKey2026. 4. Grant OPERATOR and switch it on. Set slot 4 to OPERATOR on the LAN channel, then enable it. 5. File the roster. The updated account table goes to ~/bmc-users.txt. 6. The challenge. Log in AS dreyes at her own level and capture the proof to ~/access-proof.txt. No structure given on this one.
Here is the deal: the workspace shows no commands. It hands you one objective at a time, and you recall the move. That recall is the whole point; it is how last hour's reading becomes your skill.
Stuck is normal. Hit Request a signal on any objective for a nudge, or ask Daemon. It knows exactly which task you are on and will nudge, not spoil.
Your workstation dc-east-ws01 is booting in the bay below, with the Bay 14 BMC on the management network beside it. $BMC_IP is preset. Log in with ADMIN / ADMIN one more time, and make it one of the last times anyone in this building ever does: by the end of this work order, that password's days are numbered.
Launch it and close WO-1002.
Practice User Setup in a real Linux terminal at The Linux Camp. Progress is verified automatically as you type commands on the machine.