samples: drop stale SPP-version prerequisites from all READMEs; document proxmox-ve-http dual-mode rotation

Author: petrsnd

samples/http/facebook/README.md

@@ -19,7 +19,6 @@ Facebook user accounts accessed through the public web interface.
 
 ## Prerequisites
 
-- SPP 6.0 or later
 - Outbound HTTPS access from SPP to `https://www.facebook.com`
 - The managed account must use password-based sign-in only; checkpoint, login approvals, MFA prompts, or CAPTCHA must be disabled
 - Managed account username/email and current password; no separate service account is required

samples/http/forgerock-openam/README.md

@@ -20,7 +20,6 @@ ForgeRock AM / OpenAM user accounts in a target realm.
 
 ## Prerequisites
 
-- SPP 6.0 or later
 - ForgeRock AM/OpenAM 7.5 or later recommended; this sample was tested with AM 7.5
 - Network access from SPP to the AM endpoint and realm
 - A service account with permission to authenticate and update users in the target realm

samples/http/okta-discovery/README.md

@@ -23,7 +23,6 @@ Okta users and group memberships in an Okta tenant.
 
 ## Prerequisites
 
-- SPP 6.0 or later
 - Network access from SPP to the Okta tenant URL configured in `Address`
 - An Okta API token with rights to read users and groups, change passwords, and add/remove users from groups
 - `FuncUsername` must be the login name of an existing Okta user for `CheckSystem`; `FuncPassword` is the Okta API token used as the `SSWS` authorization value

samples/http/onelogin-jit/README.md

@@ -23,7 +23,6 @@ OneLogin users and role assignments used in Safeguard JIT access workflows.
 
 ## Prerequisites
 
-- SPP 6.0 or later
 - Network access from SPP to the OneLogin API endpoint in `Address`
 - A separate OneLogin Generic REST connector already managing the base asset, account, and entitlement inventory
 - OneLogin OAuth client credentials with rights to manage users and roles; configure the client ID as `FuncUsername` and the client secret as `FuncPassword`

samples/http/proxmox-ve-http/README.md

@@ -20,9 +20,10 @@ Proxmox VE 7.x and 8.x clusters or single nodes, managed via the REST API on por
 
 ## Prerequisites
 
-- SPP 6.0 or later
 - A Proxmox VE node reachable from SPP on port 8006 (or whatever port the asset specifies)
-- A **service account in the `@pve` realm** with the `Realm.AllocateUser` privilege on `/access/realm/pve` (the built-in `PVEUserAdmin` role grants this). The standard `User.Modify` privilege alone is **not** sufficient for cross-user password changes via the API.
+- A service account in the `@pve` realm:
+  - For **service-account mode** (one account rotating another): the service account needs `Realm.AllocateUser` on `/access/realm/pve` — the built-in `PVEUserAdmin` role grants this. The standard `User.Modify` privilege alone is **not** sufficient for cross-user password changes via the API.
+  - For **self-managed mode** (the account rotates its own password): no special privilege is required — Proxmox always allows users to change their own password.
 - Managed user accounts must also live in the `@pve` realm.
 
 ## Deployment
@@ -67,8 +68,8 @@ No custom parameters. The full credential set comes from reserved parameters aut
 ## Limitations
 
 - **`@pve` realm only.** Users in `@pam` (the host's OS PAM stack) cannot be rotated via the Proxmox API regardless of API-level privileges — the Proxmox API call returns an error directing the caller to use `passwd` on the host. Rotating `@pam` users requires SSH-to-the-host + `sudo passwd <user>`, which is a separate platform (not yet shipped).
-- **Service-account model only.** This sample does not support self-rotation — `ChangePassword` always operates cross-user and depends on the service account holding `Realm.AllocateUser`. Configuring the asset for self-managed rotation will fail at the API call.
-- **Ticket lifetime is ~2 hours.** Each operation fetches a fresh ticket; the script does not persist tickets across SPP operations.
+- **Both self-managed and service-account modes are voyage-tested.** In service-account mode a privileged user (e.g. holding `PVEUserAdmin` on `/access/realm/pve`) rotates another `@pve` user's password. In self-managed mode the account rotates its own password; Proxmox always allows users to change their own password, so the `Realm.AllocateUser` privilege requirement does not apply. The same script handles both — SPP supplies the credentials such that `%FuncUserName%`/`%FuncPassword%` and `%AccountUserName%`/`%AccountPassword%` resolve to the same identity in self-managed mode, and the API accepts the `confirmation-password` field as benign on a same-user change.
+- **Ticket lifetime is ~2 hours.** Each operation fetches a fresh ticket; the script does not persist tickets across SPP operations. Self-rotation invalidates the ticket held during the change, but since the next operation re-authenticates, this is not observable.
 - **`401 Unauthorized` responses do not carry `WWW-Authenticate`.** Proxmox does not advertise the auth scheme on failure, which means generic HTTP debugging tools may misclassify the failure mode. The script does not rely on the header.
 - **No support for `DiscoverAccounts`.** The script does not enumerate Proxmox users; the operator adds managed accounts explicitly.
 - **No API token support.** Proxmox also offers token-based auth (`Authorization: PVEAPIToken=user@realm!tokenid=UUID`). That is a different sample and not implemented here.

samples/http/twitter/README.md

@@ -19,7 +19,6 @@ Twitter/X user accounts accessed through the web interface.
 
 ## Prerequisites
 
-- SPP 6.0 or later
 - Outbound HTTPS access from SPP to `https://twitter.com`
 - The managed account must support direct username/password sign-in without extra verification prompts
 - Managed account username and current password; no separate service account is required

samples/http/wordpress/README.md

@@ -20,7 +20,6 @@ WordPress user accounts exposed through the WordPress REST API.
 
 ## Prerequisites
 
-- SPP 6.0 or later
 - A WordPress site reachable from SPP with the REST API enabled
 - The JSON Basic Authentication plugin (or equivalent Basic-auth support) installed on the site
 - A service account with permission to read settings and update WordPress users; use HTTPS because Basic auth sends credentials on every request

samples/ssh/generic-linux-ssh-keys/README.md

@@ -24,7 +24,6 @@ A Linux or Unix host that uses OpenSSH-style `AuthorizedKeysFile` paths for mana
 
 ## Prerequisites
 
-- SPP version 6.0 or later
 - A Linux/OpenSSH host reachable over SSH
 - A service account that can run `sshd -T -C`, `id`, and the required file-management commands (`mkdir`, `touch`, `cp`, `cat`, `tee`, `mv`, `chown`, `chmod`) through `sudo` or the configured `DelegationPrefix`
 - Managed accounts that store SSH keys in standard OpenSSH authorized-keys files

samples/ssh/generic-linux-with-ad/README.md

@@ -21,7 +21,6 @@ A Linux host where the service account may authenticate as `user@domain`, while
 
 ## Prerequisites
 
-- SPP version 6.0 or later
 - A Linux host reachable over SSH
 - If you use `FuncUserDomain`, the target must accept SSH logins in `user@domain` form
 - A service account that can use `sudo` (or another `DelegationPrefix`) to read `/etc/shadow` and run `passwd`

samples/ssh/generic-linux-with-discovery/README.md

@@ -22,7 +22,6 @@ A generic Linux host with local accounts in `/etc/passwd`, password hashes in `/
 
 ## Prerequisites
 
-- SPP version 6.0 or later
 - A Linux host reachable over SSH
 - A service account with enough privilege to read `/etc/shadow`, inspect `/etc/passwd`, and run the discovery pipeline commands (`grep`, `wc`, `cut`, `tr`, `id`, and `awk`)
 - An account-discovery job in SPP if you want to use `DiscoverAccounts`