Learn › BMC & Server Management › Users, Roles and the Management Network

Users, Roles and the Management Network

Final test: the whole Users, Roles and the Management Network chapter. Read a real controller user table, create an account in four commands and prove it establishes an RMCP+ session, prove a wrong password is refused, retire a vendor account left over from a contract that ended and prove the door is shut, record the channel and its cipher suites, set a VLAN tag and put it back with a readback, capture the three writes this controller refuses, file the genuine Dell R730 reference, and produce the access record. 25 objectives on a real workstation called mgmt with a real IPMI 2.0 controller at 10.100.0.2 whose accounts you really change.

Chapter 6. Users, Roles and the Management Network

This chapter covers the following topics:

6.1 The user table as found, and the account summary
6.2 Proving an account is live before changing anything
6.3 Creating an account, and the four commands that populate a slot
6.4 Proving a new account authenticates, and proving a wrong password does not
6.5 Revoking an account, and proving the door is shut
6.6 Privilege levels, per channel, and what this controller does not enforce
6.7 The channel and its cipher policy
6.8 The management network: address, VLAN and SNMP
6.9 Real hardware: a production user table and network
6.10 Writing an access record

What you already know. Chapter 1 read the factory user table, rotated a password, created an operator account and disabled the anonymous slot, and read lan print and the cipher suite table. This chapter does the same work as an access review: it proves each state before and after every change, and it records the management network as found.

Objectives. After this chapter you can:

Read a user table and an account summary, and say what each column decides
Create a controller account at a stated privilege level and prove it authenticates
Revoke an account and prove it no longer authenticates
Explain that privilege is set per channel, and read it back with channel getaccess
Read the management network configuration and change a VLAN tag safely
Say what a controller records but does not enforce, and why that still matters
Write an access record that states what was proven rather than what was assumed

The machine. The accounts on this controller are real: the commands below create, authenticate and revoke them against a live IPMI 2.0 controller. Four deliverables in the lab hold refusals rather than readings, and every one of them needs standard error captured. Boot takes about 3 minutes. This chapter is free; the machine is yours for 60 minutes and stops itself after 20 minutes idle.

This chapter uses a real Linux workstation and software-emulated IPMI hardware. The protocol requests and replies are real; controller identity, sensor values and host behavior may be seeded or emulated. Supplied physical-hardware captures are labeled separately.

Pre-check 1 of 5

These five questions establish whether you need this chapter in full. Each explanation names the section that covers the point.

[ ] Disable it, since it should not exist
[x] Perform the authorized before-check, disable the account, then verify that a fresh sign-in is refused
[ ] Delete the slot so the account cannot be re-enabled
[ ] Change its password and leave it in place in case the vendor returns

>>> This test is explicitly authorized in the lab. Real offboarding can revoke access without knowing the former password, and policy or an incident can require immediate revocation. Do not delay disabling an account merely to obtain a successful login. Section 6.2.

Pre-check 2 of 5

[ ] One: user set with the name, password and level together
[x] Four: set the name, set the password, set the privilege on the channel, enable the slot
[ ] Two: create the account and then enable it
[ ] Three; the slot is enabled automatically once a password is set

>>> A slot is populated field by field: user set name, user set password, user priv and user enable. Missing the last one leaves a fully configured account that cannot open a session. Section 6.3.

Pre-check 3 of 5

[ ] Whether user 4 has ever signed in on channel 1
[x] What user 4 is permitted to do on channel 1: messaging, link authentication and privilege level
[ ] The channel 1 configuration, restricted to what user 4 may see
[ ] The number of sessions user 4 currently holds on channel 1

>>> Privilege is a per-channel property of an account, so it is read per channel. The same account may hold a different level on a serial channel from the one it holds on the LAN. Section 6.6.

Pre-check 4 of 5

[ ] The controller reboots to apply it and is briefly unreachable
[x] The controller starts tagging its frames at once, and if the switch port does not carry that VLAN it is unreachable until somebody goes to the rack
[ ] The setting is volatile and is lost at the next controller reset
[ ] Existing sessions are dropped but new ones connect normally

>>> The change applies the moment it takes, and it changes how the controller's frames appear on the wire. A VLAN the switch port does not carry makes the controller silent, and a controller is the thing you would normally use to fix a machine remotely. Section 6.8.

Pre-check 5 of 5

[ ] Treat the level as meaningless on that controller and grant everyone ADMINISTRATOR
[x] Set levels correctly regardless, record that this firmware does not enforce them, and rely on enforcement only where it is proven
[ ] Raise a firmware defect and stop using the controller
[ ] Use the channel access controls instead, which are always enforced

>>> A control that is recorded and not enforced is a finding to write down, not a reason to stop configuring it. The same account definition is enforced on production firmware, which answers 0xD4, and the record is what the next review reads. Section 6.6.

6.1 The user table as found

Goal: record who has access before changing an account. Read channel 1, then compare the name, IPMI messaging flag and privilege ceiling for each populated slot. The capture below is shortened; your table has more rows.

prompt: ops@mgmt:~$ answer: ipmitool -I lanplus -H 10.100.0.2 -U ADMIN -P ADMIN -C 3 user list 1 output: ID Name Callin Link Auth IPMI Msg Channel Priv Limit 1 true false true USER 2 ADMIN true false true ADMINISTRATOR 3 svc-vendor true false true ADMINISTRATOR 4 true false false Unknown (0x00) 5 true false false Unknown (0x00) 6 true false false Unknown (0x00) 7 true false false Unknown (0x00) 8 true false false Unknown (0x00) 9 true false false Unknown (0x00) 10 true false false Unknown (0x00) 11 true false false Unknown (0x00) ... hint: user list takes the channel number.

Slot 1 is the reserved null-user-name slot. Its settings vary by controller; an empty name is not proof that anonymous access is safe or enabled. In this lab capture, IPMI messaging is true and the ceiling is USER.

Slot 2, ADMIN, is the existing administrator. Keep an approved working administrator path while changing access.

Slot 3, svc-vendor, has an administrator ceiling and IPMI messaging enabled. The lab's expired maintenance contract makes this the account to review for retirement.

Check: identify the slot before changing it. A table row describes configuration; a fresh authorized sign-in is a separate check.

6.1.1 The account summary

user summary gives the counts without the table, which is the quick check on a controller with sixty-three slots.

prompt: ops@mgmt:~$ answer: ipmitool -I lanplus -H 10.100.0.2 -U ADMIN -P ADMIN -C 3 user summary 1 output: Maximum IDs : 63 Enabled User Count : 3 Fixed Name Count : 1 hint: user has a summary subcommand, taking the channel number.

Maximum IDs : 63 is the size of the table, fixed in firmware.

Enabled User Count : 3 is the number that matters to a review. Three enabled accounts on a controller that should have one or two is a question to answer, and it is answerable in a single command across a fleet.

Fixed Name Count : 1 is the number of slots whose name cannot be changed, which is the anonymous slot.

6.2 Proving the account is live

This lab explicitly authorizes a read-only before-check using its supplied contract credential. Real account retirement does not require the former password or a successful sign-in.

Follow the approved policy. In an incident or routine offboarding, immediate revocation may take priority. Here the controlled before-and-after exercise helps distinguish a stored row from usable credentials.

prompt: ops@mgmt:~$ answer: ipmitool -I lanplus -H 10.100.0.2 -U svc-vendor -P Vend0rSvc2019 -C 3 mc info output: Device ID : 0 Device Revision : 3 Firmware Revision : 1.05 IPMI Version : 2.0 Manufacturer ID : 0 Manufacturer Name : Unknown Product ID : 256 (0x0100) Product Name : Unknown (0x100) ... hint: The usual command form with the contract account name and the credential from the offboarding note.

The controller answered. The account is live, the credential still works, and the session ran at ADMINISTRATOR.

Objective 4 records this whole block into orphan-before.txt, and it is the evidence half of the finding. The other half arrives in section 6.5, when the same command is refused.

The pattern generalises: prove the state, change it, prove the new state. Chapter 2 applied it to power. It applies to every change made from a controller.

6.3 Creating an account

The access request on the machine names the slot, the level and the initial password:

ACCESS REQUEST -- node01 BMC

  Requested for      ruiz
  Role               datacenter operations, host power and console
  Level              OPERATOR
  Controller         node01-bmc, 10.100.0.2
  User slot          4 (the next free slot in the table)
  Initial password   Camp-Ruiz-24

The initial password above is what you set. ruiz changes it at the first
sign-in; that is outside this lab, and the access record you file should say the
password was issued and is due to be changed.

OPERATOR is the level for someone who reads the machine and controls its power,
and who does not administer the controller itself. Level numbers as ipmitool
takes them: 1 callback, 2 user, 3 operator, 4 administrator.

Populating a slot takes four commands, because a slot is filled field by field. The first sets the name:

prompt: ops@mgmt:~$ answer: ipmitool -I lanplus -H 10.100.0.2 -U ADMIN -P ADMIN -C 3 user set name 4 ruiz output: hint: user set name takes the slot number and then the name.

A successful name change is normally quiet. Immediately running echo $? checks the command exit status: 0 means ipmitool reported success. Then use user list 1 to verify slot 4 now says ruiz. Silence alone is not the check.

This command changes only the name. The following steps set the password, channel privilege and enabled state.

The slot number comes from the request rather than being chosen: an access request names the slot so that two people working the same table do not collide.

6.3.1 The password

prompt: ops@mgmt:~$ answer: ipmitool -I lanplus -H 10.100.0.2 -U ADMIN -P ADMIN -C 3 user set password 4 Camp-Ruiz-24 output: Set User Password command successful (user 4) hint: user set password takes the slot number and then the password.

This one does print a confirmation naming the slot.

The password from the request is an initial credential: it is issued, it is written down in the request, and the holder is expected to change it at first sign-in. The access record in section 6.10 has to say so, because a credential that appears in a ticket and is never rotated is a credential in a ticket forever.

6.3.2 The privilege level

user priv takes the slot, the level and the channel, in that order. The level is given as a number, and 0x3 is OPERATOR.

prompt: ops@mgmt:~$ answer: ipmitool -I lanplus -H 10.100.0.2 -U ADMIN -P ADMIN -C 3 user priv 4 0x3 1 output: Set Privilege Level command successful (user 4) hint: user priv takes the slot number, the privilege level and the channel number.

The argument order is slot, level, channel, and getting it wrong is the usual reason an account ends up at the wrong level. user priv 4 0x3 1 is slot 4 at level 3 on channel 1; user priv 4 1 0x3 would be read as slot 4 at level 1 on channel 3.

The channel argument is not optional decoration. Section 6.6 covers why.

6.3.3 Enabling the slot

prompt: ops@mgmt:~$ answer: ipmitool -I lanplus -H 10.100.0.2 -U ADMIN -P ADMIN -C 3 user enable 4 output: hint: user enable takes the slot number.

Silent, and it is the command most often forgotten. A slot with a name, a password and a privilege level that has never been enabled is fully configured and cannot open a session, and the table shows it looking correct.

That is why section 6.4 authenticates rather than reading the table and stopping.

6.4 Reading the table back

prompt: ops@mgmt:~$ answer: ipmitool -I lanplus -H 10.100.0.2 -U ADMIN -P ADMIN -C 3 user list 1 output: ID Name Callin Link Auth IPMI Msg Channel Priv Limit 1 true false true USER 2 ADMIN true false true ADMINISTRATOR 3 svc-vendor true false true ADMINISTRATOR 4 ruiz true false true OPERATOR 5 true false false Unknown (0x00) 6 true false false Unknown (0x00) 7 true false false Unknown (0x00) 8 true false false Unknown (0x00) 9 true false false Unknown (0x00) 10 true false false Unknown (0x00) 11 true false false Unknown (0x00) ... hint: The same user list command as section 6.1.

Slot 4 now reads ruiz, IPMI Msg true, privilege limit OPERATOR. Compare it with section 6.1, where slot 4 was empty with IPMI Msg false and a limit of Unknown (0x00).

svc-vendor is still at ADMINISTRATOR in slot 3. Nothing has been revoked yet.

6.4.1 The per-channel view

Goal: check the account on the channel it will use. channel getaccess 1 4 means channel 1, user slot 4.

prompt: ops@mgmt:~$ answer: ipmitool -I lanplus -H 10.100.0.2 -U ADMIN -P ADMIN -C 3 channel getaccess 1 4 output: Maximum User IDs : 63 Enabled User IDs : 4

User ID : 4 User Name : ruiz Fixed Name : No Access Available : call-in / callback Link Authentication : disabled IPMI Messaging : enabled Privilege Level : OPERATOR Enable Status : unknown hint: channel getaccess takes the channel number and then the user id.

Read these fields together:

IPMI Messaging : enabled permits this user to send IPMI messages on this channel. Other account, channel, cipher and session checks still apply.
Privilege Level : OPERATOR is this user's ceiling on channel 1. The session must request an allowed level too.
Link Authentication : disabled concerns link-level authentication, such as PPP. It does not mean RMCP+ password authentication is disabled.
Enable Status : unknown means this response does not tell us the separate enabled state. Do not convert unknown into enabled or disabled.

Try next: authenticate with the new credentials and explicitly request -L OPERATOR. A successful read checks the usable access path, not merely the stored row.

6.4.2 Proving the account works

Goal: prove the account can authenticate and read controller information. -L OPERATOR requests the level we assigned. Without it, ipmitool normally requests ADMINISTRATOR, which is above this account's configured ceiling.

prompt: ops@mgmt:~$ answer: ipmitool -I lanplus -H 10.100.0.2 -U ruiz -P Camp-Ruiz-24 -C 3 -L OPERATOR mc info output: Device ID : 0 Device Revision : 3 Firmware Revision : 1.05 IPMI Version : 2.0 Manufacturer ID : 0 Manufacturer Name : Unknown Product ID : 256 (0x0100) Product Name : Unknown (0x100) ... hint: The usual command form with the new account name and the password from the access request.

This emulator may also print Get HPM.x Capabilities request failed, compcode=d4 during a secondary capability probe. In the tested OPERATOR session, the requested controller read still returned successfully. Check the requested output and exit status; do not mistake a probe warning for proof that every operation failed.

The controller answered, so the account opens an RMCP+ session and reads the machine. Objective 11 files a fuller proof by running sensor list under the same credentials and -L OPERATOR, which shows the account doing real work rather than only connecting.

6.4.3 Proving a wrong password fails

The other half of the proof is the negative case, and it is worth recording because it establishes that the first result was not something else answering.

prompt: ops@mgmt:~$ answer: ipmitool -I lanplus -H 10.100.0.2 -U ruiz -P WrongPassword -C 3 -L OPERATOR mc info > ~/access/badpass.txt 2>&1 output: hint: The same command with a deliberately wrong password, redirected with standard error captured by 2>&1.

The file holds:

Error: Unable to establish IPMI v2 / RMCP+ session

This recorded attempt is refused. Keep the endpoint, user and requested privilege the same as the successful check; here the deliberate change is the password. A generic session error elsewhere can have other causes, including network, cipher and privilege negotiation. Do not treat this message as a universal promise about what RMCP+ can disclose.

2>&1 is required here. The message goes to standard error, so a plain > leaves the file empty. Four objectives in this lab record a refusal, and every one of them needs it.

6.5 Revoking the contract account

Section 6.2 proved the door was open. user disable closes it.

prompt: ops@mgmt:~$ answer: ipmitool -I lanplus -H 10.100.0.2 -U ADMIN -P ADMIN -C 3 user disable 3 output: hint: user disable takes the slot number.

Silent, like the other user commands. Whether it took has to be established separately, which is the next two steps.

6.5.1 The table after the revocation

prompt: ops@mgmt:~$ answer: ipmitool -I lanplus -H 10.100.0.2 -U ADMIN -P ADMIN -C 3 user list 1 output: ID Name Callin Link Auth IPMI Msg Channel Priv Limit 1 true f

Practice Users, Roles and the Management Network in a real Linux terminal at The Linux Camp. Progress is verified automatically as you type commands on the machine.