How to configure Luna HSM partition policies for unattended service startup

This is the hands-on companion to our concept chapter on Luna HSM activation and auto-activation. The goal: a PED-authenticated (in current Thales documentation, “multifactor quorum-authenticated”) application partition whose dependent services survive appliance reboots and short power outages without anyone presenting a PED key, plus a tested remote path for the day the outage outlasts the battery. The steps below assume a Luna Network HSM 7 appliance, Luna HSM Client 10.x on the application host, and lunacm run from that client. Command syntax below is drawn from the Luna 7.x documentation; a few details shift between appliance software and client versions, and those are flagged inline. When in doubt, check the command trees on thalesdocs.com for your exact version.

Before you start

You will need:

• The blue PED key (Partition Security Officer) for the target partition — policies are changed by the Partition SO.
• The black PED key (Crypto Officer) — activation is created by a CO login.
• A PED, either locally connected or a Remote PED with the orange (RPV) key if you are working over Remote PED from the start.
• An NTLS-registered client with the partition visible as a slot in lunacm, and a change window — the policy changes here are non-destructive, but you are touching a production authentication path.

If your appliance and client setup is not yet at this point, work through the Luna HSM design and operational guide first.

Step 1: View the current partition policies

From lunacm on the client, set the slot to the target partition and dump its policies:

lunacm:> slot set -slot <slot_number>
lunacm:> partition showpolicies

In the output, find the two policies that matter here:

22: Allow activation : 0
23: Allow auto-activation : 0

Add -verbose to see, for each policy, whether changing it is destructive in either direction. For policies 22 and 23 both transitions are non-destructive — you can enable and disable them on a live partition without affecting key material. That is not true of every partition policy, so make checking the verbose output a habit before any changepolicy.

Step 2: Enable activation and auto-activation

Policy changes are a Partition SO operation. Log in as the Partition SO (blue key at the PED), then enable policy 22, then policy 23:

lunacm:> role login -name po
        (present the blue PED key when prompted)
lunacm:> partition changepolicy -policy 22 -value 1
lunacm:> partition changepolicy -policy 23 -value 1
lunacm:> role logout

Order matters conceptually if not syntactically: policy 23 has no effect unless policy 22 is on, and if 22 is ever disabled later, auto-activation silently stops working even though 23 still shows as enabled. Enable both, always, on service partitions. If the Crypto Officer role does not yet have a challenge secret — the text credential your application will use — the Partition SO creates it (and the CO should change it at first login):

lunacm:> role createchallenge -name co

Note for newer stacks: from appliance software 7.9.0 and Luna HSM Client 10.8.0, challenge secrets have stricter character-set enforcement (8–255 characters, limited special-character rules). If you standardise secrets via a vault, validate the format against your version before rollout.

Step 3: Activate the partition with the CO black key

Activation is not a command of its own — it is the side effect of a Crypto Officer PED login while policy 22 is on. Log the CO in:

lunacm:> role login -name co
        (present the black PED key when prompted, then enter the challenge secret if prompted)

On success, the HSM caches the CO’s PED secret. From this point, applications log in as CO using the challenge secret alone; the PED stays in its safe. The same pattern applies to the Crypto User role (role login -name cu, grey key) if your applications use the more restricted CU role — in a least-privilege design serving read-only crypto operations, they probably should.

Step 4: Verify activation actually works

Do not take activation on faith — prove the PED is out of the loop. Log the CO out and back in, and confirm no PED prompt appears:

lunacm:> role logout
lunacm:> role login -name co -password <challenge_secret>

If the login completes without the PED lighting up, activation is live. If the PED prompts, the cache is not in place — recheck policy 22 and repeat Step 3. Then verify end-to-end from the application side: restart one dependent service and confirm it opens sessions to the partition cleanly. The exact display of activation state in partition showinfo or the lunash partition show output varies across appliance versions, so treat “challenge-only login succeeds without PED” as the authoritative test rather than hunting for a status flag.

Step 5: Set up Remote PED for reactivation without a site visit

Auto-activation covers reboots and outages up to roughly two hours. Beyond that, someone must log the CO back in with the black key — and Remote PED is what makes that a ten-minute task instead of a drive to the data centre. The moving parts: a PED in remote mode attached by USB to a workstation running pedserver (installed with the Luna HSM Client), and the appliance’s built-in PED client connecting to it. Trust is anchored by a Remote PED Vector (RPV) on an orange key, imprinted on the HSM — if you do not yet have an RPV and orange keys, create them via the appliance’s PED vector initialisation procedure (a one-time HSM SO ceremony; see the Remote PED section of the Thales docs for your appliance version).

On the workstation with the remote PED attached, start and check pedserver:

pedserver -mode start
pedserver -mode show

Confirm the listening port (default 1503) and that the PED shows as connected. Then, from lunash on the appliance (over SSH), point the appliance at the pedserver and connect:

lunash:> hsm ped set -ip <pedserver_ip> -port 1503
lunash:> hsm ped connect
        (present the orange RPV key at the remote PED when prompted)

With the connection up, PED prompts for that HSM are served by the remote PED: the CO login from Step 3 can now be performed with the black key presented at the remote workstation. Details that vary by environment and version: the appliance-initiated connection needs outbound reachability to port 1503 (if your firewall policy forbids that, use the PED-initiated connection mode, which reverses direction and uses port 9697 inbound to the appliance); the connection idles out after a default 1800 seconds; and client-side lunacm has its own equivalent (ped connect -ip <ip> -port <port>) for operations driven from the client rather than the appliance shell.

Step 6: Test the power-loss scenario — safely

An untested recovery path is a guess. Test in two stages, in a maintenance window, ideally on a non-production or HA-shielded appliance first:

• Reboot test (auto-activation works): cleanly restart the appliance with lunash:> sysconf appliance reboot. When it returns, confirm dependent services reconnect and the challenge-only CO login still succeeds with no PED prompt. This proves policies 22 and 23 are doing their job.
• Deactivation drill (the >2-hour outage, simulated): do not leave a production appliance unpowered for two hours to prove a point. Simulate the end state instead: lunacm:> role deactivate -name co clears the cached credential exactly as an exceeded battery window would. Watch what your applications actually log when the partition refuses their challenge secret — this is the error signature your on-call team must recognise — then run your full reactivation procedure over Remote PED, end to end, and time it.

If the drill takes more than about thirty minutes, the bottleneck is almost always custody — locating people and keys — not commands. Fix that now, on a Tuesday afternoon, rather than during the real event on a Sunday morning.

Step 7: Document it for on-call

Capture the following in the runbook while it is fresh — this is also the artefact your IRAP assessor will want to see alongside the policy settings:

• Per partition: slot numbers, policy 22/23 state, which roles are activated (CO, CU), and which applications depend on it.
• The application-side error signature of a deactivated partition, captured verbatim from your Step 6 drill, so first responders stop chasing password theories.
• The reactivation procedure for both paths — local PED and Remote PED — as exact command sequences, with the pedserver workstation hostname and port.
• Key custody: who holds black, blue and orange keys, after-hours contacts, and realistic time-to-keys for each. Include the M-of-N split if your keysets use one.
• Site power posture versus the ~2-hour auto-activation window: UPS runtime, generator status, and which sites can realistically exceed the window.
• The drill result: date, elapsed time, and what you fixed. Re-run it after appliance software upgrades — activation behaviour and challenge-secret rules are exactly the kind of thing that shifts between versions.

---

Where this leaves you

Your partition now survives reboots and short outages unattended, and you have a rehearsed, timed path back from the outages it cannot survive. The next weak point is the connection layer itself — NTLS client certificates, STC identities and HA group membership are what break next in a DR scenario, and they fail with far less obvious symptoms than a refused login. That is where the series goes next: follow along at The Luna Field Guide.