Lenovo Remote Physical Presence

原文：Lenovo Remote Physical Presence — theDXT (Daniel Keer)

On Lenovo servers the default configuration has a physical presence policy enabled. When a physical presence policy is enabled it prevents you from doing a few tasks on the system either in BIOS or IPMI. Lenovo calls their IPMI XClarity Controller (XCC).

With an enabled physical presence policy your only options to do some of those tasks is to either physically go and move a jumper on the motherboard or to make some tweaks in XCC or BIOS to assert your physical presence even if you are remote.

Here's how to do it in IPMI or BIOS.

What physical presence actually means

Physical presence is a security control, not a bug. The idea is that some changes are dangerous enough that a remote attacker with stolen administrator credentials should not be able to make them. If someone has your XCC or BIOS administrator password, a physical presence policy means that password alone is not enough to disable secure boot, change the boot order to a removable device, reset the TPM, clear the security configuration, or wipe the management controller's own settings.

On a Lenovo server the policy is enforced by the firmware and the XClarity Controller working together. The server tracks whether someone has "asserted" physical presence — historically, by moving a jumper on the motherboard with the server powered off. Asserting it opens a time-limited window in which the protected operations are allowed. Once the window closes, the protection returns automatically.

Every major vendor implements something like this. Dell uses a similar jumper-based approach on iDRAC and calls out the same class of protected operations; HPE calls it physical presence on iLO. If you manage a mixed fleet, the concept is worth understanding once because the failure mode is identical everywhere: someone tries to change a boot order over the network, gets an unhelpful "operation not permitted" style error, and assumes the controller is broken. The wider comparison in iDRAC vs iLO vs IPMI is a good background read on what each controller exposes.

What matters for this article is that on Lenovo hardware you do not have to drive to the datacentre, and you do not have to shut the server down to move a jumper. Both the XClarity Controller and the BIOS setup offer a remote assertion. Remote physical presence assertion is exactly what it sounds like: you declare, as someone authorised to use the out-of-band interface, that you are physically present, and the firmware believes you for the next 30 minutes.

Prerequisites and pre-flight checks

Before you rely on this during an outage, confirm the following on a quiet day:

• Working XCC access. A login with administrator rights to the XClarity Controller web interface, whether over the dedicated management port or the shared LAN-on-motherboard interface. If you can only reach the XCC from a particular VLAN, make sure the machine you will be sitting at is on it.
• BIOS access. The XClarity Provisioning Manager (the UEFI setup interface, reachable via the remote console) or the local console. Confirm you can open the remote KVM before you need it.
• Firmware level. Older XCC and BIOS firmware builds have different menu layouts and, in some releases, different behaviour for the remote assert. Note the XCC and UEFI firmware versions on each affected server before you start so you are not hunting for a switch that has moved.
• Knowledge of what actually needs the assertion. Write down the change you are making. Do not burn the window discovering that the setting you want is on a different page.
• A maintenance window, if the change requires a reboot. Asserting physical presence itself is non-disruptive, but many of the operations it unlocks — boot order changes, TPM operations, secure boot configuration — take effect on the next start.
• Change control awareness. Asserting physical presence weakens a security control for 30 minutes. If your environment has an audit trail requirement, note the time and the operator, exactly as you would for a jumper change.

Method 1 — Assert physical presence from the XClarity Controller

This is the one you will use most often, because it needs nothing from the operating system and nothing from the on-screen console.

• Log in to the XClarity Controller
• Click on BMC Configuration

• Click on Security

• Toggle the switch for Assert Physical Presence and click Apply

• You can now perform any tasks that needed physical presence to be asserted.

The physical presence will be turned off after 30 minutes or you can manually turn it off sooner.

Immediately after the toggle applies, go and make the change you needed. Two habits are worth building here. First, turn the assertion off yourself when you are finished rather than waiting out the timer — a control you consciously close is a control your auditors can follow. Second, if the operation you are performing requires the server to restart, remember that the assertion window and the restart have to overlap; start the change early in the window, not at minute 28.

If the toggle is greyed out, the usual causes are a user account without administrator privilege on the XCC, an XCC firmware version that predates the remote assert feature, or a policy at the BIOS level that has disabled remote assertion entirely. That last case is deliberately hard to work around remotely, and you should treat it as a design decision rather than an obstacle — someone chose to require a truck roll.

Method 2 — Assert physical presence from the BIOS

Use this route when the XCC interface is unavailable, when the switch is missing from your firmware's XCC page, or when you are already in the BIOS for another reason.

• Enter the BIOS setup
• Click on UEFI Setup

• Click on System Settings

• Click on Security

• Click on Physical Presence Policy Configuration

• Click on Toggle Remote Physical Presence Assert

• You can now perform any tasks that needed physical presence to be asserted.

The physical presence will be turned off after 30 minutes or you can manually turn it off sooner.

Note the difference in mechanics between the two methods. Through the XCC you are toggling a management controller setting that the firmware reads. Through the BIOS you are toggling the policy state directly in the platform setup, and if you have not saved the change with the appropriate exit option, the assertion may not survive the reboot you just triggered — which is the opposite of helpful when the whole point was to change the boot order. Save on exit, and if the operation needs a restart, confirm the assertion is still active afterwards.

The 30-minute window and how to use it well

The window is the part people get wrong in production, so treat it as a resource:

• Do the change first, housekeeping second. The assertion is a timer; anything that needs to be inside it should happen in the first ten minutes.
• Turn it off when you are done. Both interfaces let you revert the switch. Leaving it on for the full 30 minutes because you forgot is a finding in an audit, not a convenience.
• Do not batch unrelated changes into one window unless they genuinely depend on each other. If you run out of time, assert again — that is cheap. A rushed change to boot order on a production host is not.
• Record the assertion. Time, operator, ticket, and what you changed. This mirrors the paperwork a physical jumper change would have generated, and it is the honest way to keep the control meaningful.

Verifying it worked

You will know immediately, because the protected operation stops failing. If it still fails, check in this order:

1. Confirm the assertion is still active and the window has not expired.
2. Confirm you are changing the setting you think you are. A boot order change in the wrong menu, or an apply that was never saved, looks exactly like a rejected operation.
3. Confirm the account you are using is a full administrator. The XCC will accept your login and still refuse the operation for a lower-privileged role.
4. Confirm the operation is one this server requires physical presence for. Not every security setting on a Lenovo server is gated in this way; some are simply not configurable remotely.
5. Check for a pending reboot. Some changes are accepted and only take effect at the next start, which is easy to mistake for nothing having happened.

And if you are chasing a problem on the host itself rather than the firmware — a build you cannot identify, a configuration you need to reconstruct — the same out-of-band discipline applies. Knowing the host's exact build without a working vCenter, as described in ESXi Build Number without vCenter, is often the first thing you need before you decide what to change at the firmware layer.

FAQ and common problems

Is asserting physical presence the same as moving the jumper? Functionally yes for the duration of the window, which is why the feature exists. The jumper remains the fallback, and on some models and firmware levels the only option — usually where remote assertion has been deliberately disabled by policy.

The switch does not exist on my server. Check the XCC firmware version first; the remote assert has been added and moved between releases. If the firmware is current and the option is still absent, the model or the platform policy does not offer it, and the jumper is your path.

Can I assert physical presence when the server is powered off? Through the XCC, yes — the management controller has standby power, which is exactly the point. That is how you change boot order on a server that will not boot an OS.

Does it survive a restart? The assertion is a timed state held by the management controller or the platform, not a persistent setting. Restarting does not automatically clear it early, but the timer keeps running regardless of what the OS or the hypervisor is doing, so plan around the clock rather than around the boot cycle.

Is there a way to disable the policy entirely so I never hit this again? Yes, and you should think carefully before doing it. Turning the physical presence policy off permanently makes remote administration easier and removes a genuine protection against a stolen out-of-band credential. In a locked-down environment, use the temporary assertion and keep the policy. Related firmware-level security work, such as replacing a TPM, is covered in Lenovo Update TPM 1.2 to 2.0 — and yes, TPM operations are one of the things a physical presence policy is there to protect.

That’s all it takes to assert your physical presence over a Lenovo server even if you are remote.