> For the complete documentation index, see [llms.txt](https://docs.openiam.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.openiam.com/administration-guide/security/rotate-service-credentials.md). # Rotate service credentials Which service credentials OpenIAM holds and under which Vault key, which of them you rotate yourself, what breaks when one is wrong, and the log line you will see. ## What this is, and when you need it This is **password rotation** for the credentials OpenIAM itself holds, as opposed to the password policy that governs people's passwords. OpenIAM services authenticate to seven databases, RabbitMQ, Redis, OpenSearch, JanusGraph, Vault itself, SMTP mailboxes and every managed system. Almost none of those secrets are in a file — they are in HashiCorp Vault under a naming convention, and one logical credential frequently appears under **two** Vault keys plus an environment variable. Updating one copy produces an outage that presents as unrelated authentication, workflow, synchronization or search failures. Use this page for three things: to find out which credentials exist and under which key, so you can name the one you mean; to work out which of them you rotate yourself and which belong to whoever owns the deployment; and to recognise a wrong credential from the symptom and the log line, because almost none of them announce themselves as a credential problem. A user's password is not on this page — that is [Configure password recovery and account unlock](/administration-guide/security/password-recovery.md). Three of these credentials are yours end to end, because the Webconsole is what writes them: a managed system's service account, an OTP provider secret or social-login private key, and the SMTP credential on the system-properties screen. Everything else is the deployment owner's. [Which of these you own](#which-of-these-you-own) says why, and the key tables, the symptom table and the checks to run after somebody else has rotated one all follow the procedure. {% hint style="danger" %} **A compromised secret is rolled forward, never restored.** This is one of the three genuinely irreversible categories in [Change configuration safely](/administration-guide/start/change-safely.md). If a credential has been exposed — in a log, a screenshot, a ticket, shell history, a container image layer, or an `env.sh` committed to a repository — the only correct action is to issue a new one and revoke the old. Restoring a Vault secret version to "fix" a broken rollout re-enables the exposed value. Roll forward to a third value instead. That is why every sequence below ends with a revocation step and a *proof that the old value fails*, not with a health check. {% endhint %} ## At a glance | | | | ------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **You will end up with** | One managed system's service-account credential changed on the target and in OpenIAM, **Verify connection** passing, one real provisioning operation completed through it, and the old account deleted and proven to fail | | **Where** | **Provisioning → Managed System** at `/webconsole/mngsystemlist`, the form at `/webconsole/mngsystem?id=`, and **Verify connection** on that form. OpenIAM writes the value to `vault.secret.managed.system.`, not to `MNG_SYS.PSWD` | | **You need first** | The managed system's name and ID, the account and who owns it, a **Verify connection** result recorded *before* you change anything, and the ability to change the account on the target itself | | **Takes** | 30 to 60 minutes for one managed system, of which the window where provisioning to that system fails is the two middle steps | | **Reversible** | No. A compromised secret is rolled forward to a third value, never restored — restoring a Vault version re-enables the exposed one, and the revocation step cannot be undone | ## What you rotate yourself One rotation on this page is entirely yours, and it is the commonest: a managed system's service account. The order is the part people get wrong. {% stepper %} {% step %} ### Record what you are changing, and prove it works now The managed system's name and ID, the account, who owns it. Run **Verify connection** *before* you change anything, so that a failure afterwards means something. {% endstep %} {% step %} ### Change the credential on the managed system first On the directory, the database or the application — not in OpenIAM. From this moment until the next step completes, every provisioning operation to that system fails, so these two steps are one window. Do them in this order anyway: the alternative leaves OpenIAM holding a credential the managed system has not been given yet, which fails identically and additionally leaves partial state behind on requests that were already in flight. {% endstep %} {% step %} ### Set the new credential on the managed system in OpenIAM Open the managed system and set the password on its own screen — see [Configure a managed system](/administration-guide/lifecycle/configure-managed-system.md). OpenIAM writes it to `vault.secret.managed.system.` for you. Do not put it in `MNG_SYS.PSWD`; that column is not where the credential lives, and a value there will be discarded. {% endstep %} {% step %} ### Prove it with Verify connection, then with one real operation Run **Verify connection**, per [Verify connectivity to the target](/administration-guide/lifecycle/verify-connection.md). Then run one real provisioning operation end to end, because **Verify connection** proves the bind and not the permissions: a service account that can still authenticate but has lost its write grant passes the connection test and fails every provisioning request after it. {% endstep %} {% step %} ### Revoke the old account and confirm it fails Delete the old account rather than changing its password, then attempt to authenticate with it and confirm the failure. **This step is the rotation.** Everything before it was a configuration change. {% endstep %} {% endstepper %} An OTP provider secret and a social-login private key need no procedure at all: saving the provider form writes the secret, and deleting the provider erases it. ## What to check after somebody else has rotated one The principle the deployment owner works to is that the credential exists in both places before any consumer is restarted, and the old value is revoked only after every consumer has proven it is on the new one. Your part is the proof, and it is a set of Webconsole checks rather than a health check — a container reporting healthy proves the process started, not that it authenticated, and several services open their datasource lazily. Run all seven, because each one exercises a different credential and the first six all report as something other than a credential problem: 1. **Sign in.** The IdP and its database. 2. **Search for an identity.** OpenSearch and the `openiam` schema. 3. **Submit and approve one request.** RabbitMQ and the workflow schema. 4. **Search the audit log.** The audit-log schema and OpenSearch — see [Find audit evidence](/administration-guide/operations/find-audit-evidence.md). 5. **Run one provisioning operation end to end.** The broker, the connector and a managed-system credential. 6. **Send one test notification.** The mailbox credential. 7. **Run Verify connection** on every managed system whose credential was in scope. {% hint style="warning" %} **Ask for the IdP and Webconsole to be restarted last.** They are the only services whose failure stops a human from signing in to fix the others, and a break-glass administrator account cannot help if the sign-in service itself cannot reach its database. This is the one sequencing request worth making even though the restart is not yours to perform. {% endhint %} ### Two orders that are specifically wrong **Rotating a managed-system credential in OpenIAM before the managed system.** Between the two changes every provisioning operation to that system fails and may leave partial state. Managed system first, OpenIAM second, **Verify connection** third. **Rotating the broker password with queues full.** Messages already in flight are fine, but a client that cannot reconnect stops consuming, and the `provision`, `workflow initiate` and `sync` queues back up against their configured concurrency limits. Ask for the queues to be drained first, or accept the backlog and watch the depth — see [Diagnose a failed operation](/administration-guide/operations/diagnose-a-failed-operation.md#the-queue-layer). ## Verification | What to check | How | Yours? | | ------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ----------------- | | A managed-system credential works | **Verify connection** on the managed system, then one real provisioning operation | Yes | | A managed system's credential is where you think | `MNG_SYS.PSWD` is `NULL` — the credential is in Vault, not the column. Break-glass, read-only, [Managed systems](#managed-systems) | Yes | | A mailbox credential works | Send a test notification. Confirm which key the mail service reads before declaring it done | Yes | | An OTP or social secret was written | Reopen the provider and re-save; a provider that saves and then authenticates has its key | Yes | | Nothing leaked | No secret in logs, tickets, screenshots or the change record. Vault TRACE logging is loud about itself — the service logs *"WARNING - TRACE ENABLED FOR VAULT - DISABLE it ASAP"* — so search for that line and confirm TRACE is off | Yes | | Vault is actually being consulted | Absence of *"Vault is disabled"* in the service log, and absence of *"Could not find property"* for the key in question | Yes, from the log | | The Vault key holds what you think | A read of the key returns a document whose `value` is the new secret. Not available from any screen — ask the deployment owner | No | | No environment variable is shadowing it | The service or container definition carries no `SECRET_*` or `vault_secret_*` variable for that key. Not visible from any screen | No | | Every paired key was updated | The broker and cache each have two key names for one credential; both must have moved | No | | No service is still on the old value | Every consumer restarted, no surviving old replica, and the old credential now **fails** | No | ## When it goes wrong | Symptom | Cause | Fix | | --------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | A service starts but cannot reach the database | Its key prefix is not the one that was rotated — there are five distinct `*.jdbc.*` prefixes | Name the right key from [the database table](#databases-seven-schemas-five-distinct-key-prefixes); `vault.secret.jdbc.*` alone has five consumers | | A schema migration fails weeks after a clean rotation | The batch-task and certification **migration** datasources read `vault.secret.jdbc.*` and only connect at startup, so they were never tested | Ask for both managers to be restarted as part of any `vault.secret.jdbc.*` rotation | | The broker rejects every client after a password change | Only `vault.secret.rabbitmq.password` was updated, not `vault.secret.spring.rabbitmq.password` | Update both | | Redis authentication fails only for the second-level object cache while other Redis use works | The cache resolves `spring.redis.password` on its own path, from the same Vault key | Same key, so this is a restart that did not happen; confirm the service was restarted | | OpenSearch credentials ignored by the machine-learning service alone | That service overwrites the Vault values with the plain `opensearch.username` / `opensearch.password` properties | Set both consistently | | A rotated value has no effect anywhere | An environment variable shadows it — the resolver checks env before Vault | Remove the variable and restart | | Vault itself is unreachable after a change | `vault.ssl.key-store-password` or the client keystore changed and services cannot authenticate | Restore the keystore and its password together; this pair has no overlap | | Stored managed-system passwords and password history become unreadable, everywhere at once | A `vault.secret.iam.jks.*` key password was changed without re-keying the keystore | Stop. Restore the keystore **and** the Vault secret version as one coordinated pair. There is no application-level recovery and no break-glass query that helps — the ciphertext is all that survives | | Managed-system provisioning fails immediately after rotation | OpenIAM was updated before the managed system, or only one of the two was changed | Managed system first, OpenIAM second, **Verify connection** third | | SMTP still uses the old password after a successful save on the properties screen | The mail service reads `vault.secret.mailbox..password` while that screen writes the legacy `vault.secret.mail.password` | Set the password on the mailbox configuration instead; a migrated deployment uses mailbox ID `MIGRATED_MB` | | Messages on the bus become unreadable | `org.openiam.mq.broker.encryption.key` was changed without restarting every service together | Restore the key, drain the queues, then change it everywhere at once | | A rotation went wrong and you want the old value back | If the old value was compromised, restoring it re-exposes you | Roll forward to a third value | ## Rollback, and its one limit Rollback for a platform credential is the deployment owner's, and the shape of it depends on whether the credential could overlap: an overlapping one is repointed and the moved consumers restarted, while a non-overlapping one — a keystore password, the broker encryption key — has to have **both sides restored as a pair**, the service-side secret and the Vault secret version, in one action. Alternating one side at a time produces a state where neither value works. The procedure is in the [Installation Guide](/installation/installation.md). For the one rotation that is yours, a managed system's service account, rollback is the same steps in reverse: put the old credential back on the managed system, set it again on the managed system's screen in OpenIAM, and prove it with **Verify connection**. That only works while the old account still exists, which is why its deletion is the last step and not the first. The limit applies to every credential on this page, yours or not: **if the reason for the rotation was exposure, there is no rollback.** Roll forward to a third value. Restoring a compromised secret is the one action here that cannot be undone by a later change, because the exposure is already permanent. ## Which of these you own Three of the credentials on this page are yours end to end, because the Webconsole is what writes them: * **A managed system's service account** — the AD bind account, the database user, the SCIM token. You change it on the managed system, and you prove it with **Verify connection**. See [What you rotate yourself](#what-you-rotate-yourself). * **An OTP provider secret and a social-login private key.** Saving the provider form writes the secret to Vault; deleting the provider erases it. There is nothing else to do. * **The SMTP credential on the system-properties screen** — with one trap, described under [Mailboxes](#mailboxes), because the key that screen writes is not necessarily the key the mail service reads. Everything else — the databases, RabbitMQ, Redis, OpenSearch, the keystores — is rotated by whoever owns the deployment. Rotating one means writing Vault secret versions, removing environment variables from container definitions and restarting services in dependency order, none of which happens in the Webconsole. The procedure is in the [Installation Guide](/installation/installation.md). Your part is to name the credential precisely, to say what a wrong one looks like from your side, and to run the checks afterwards — which is what the key tables and the symptom table on this page are for. ## The key convention, and the one thing that defeats it Every secret lives in Vault under a key beginning `vault.secret.`, and OpenIAM prepends that prefix itself when a caller asks for a bare name. The one exception is a secret **system property**, whose value is keyed by the property's own ID beneath `secret/openiam/propertyvalue/` and is read without the prefix — see [Secret properties](#secret-system-properties) below. That is why the three Spring-named credentials are stored as `vault.secret.spring.redis.password`, `vault.secret.spring.rabbitmq.username` and `vault.secret.spring.rabbitmq.password` rather than under their Spring names, and why the database password is stored in Vault as `vault.secret.jdbc.password` under the path `/v1/secret/openiam/`, which is the shipped `vault.path`. Vault authentication is by client certificate, not by token, and OpenIAM refreshes its token every 30 days. **A missing key is silent.** It returns `404`, yields `null`, and logs only at INFO: {% code overflow="wrap" %} ``` Could not find property 'vault.secret.jdbc.password' in vault. ``` {% endcode %} So a typo in a key name is not an error. The service starts, and fails later at the point it first needs the credential. {% hint style="warning" %} **An environment variable is consulted before Vault, and shadows it silently.** OpenIAM looks for a system property or environment variable named with the dots replaced by underscores — `vault.secret.jdbc.password` becomes `vault_secret_jdbc_password` — then the same name lower-cased and upper-cased, then the loaded properties files, and only then Vault. So a `SECRET_*` or `vault_secret_*` variable left in a container or service definition wins over the value in Vault, and a rotation done correctly in Vault has no effect at all. **This cannot be confirmed from the Webconsole.** Nothing on any screen shows which source a property value came from. Ask whoever owns the deployment to inspect the service or container definition for `SECRET_*` and `vault_secret_*` variables; that is the only place the answer exists. {% endhint %} {% hint style="warning" %} **`org.openiam.vault.disabled` short-circuits the whole mechanism.** When that system property is `true`, every Vault lookup returns `null` and the service logs *"Vault is disabled. Property %s will not be fetched from vault"*. Search the service log for *"Vault is disabled"* before concluding that a Vault key is missing — the two failures look identical from every screen. {% endhint %} ## The keys, by service These are the key names to use when you name a credential in a ticket, a change record or a conversation with the deployment owner. There is no screen that lists them. ### Databases: seven schemas, five distinct key prefixes | Vault key | Consumer | | -------------------------------------------------------- | ----------------------------------------------------------------------------------------------- | | `vault.secret.jdbc.username` / `.password` | ESB, auth-manager, risk-manager, and the batch-task and certification **migration** datasources | | `vault.secret.activiti.jdbc.username` / `.password` | Workflow | | `vault.secret.groovy.jdbc.username` / `.password` | groovy-manager | | `vault.secret.auditlog.jdbc.username` / `.password` | audit-log-manager | | `vault.secret.batchtasks.jdbc.username` / `.password` | batch-task-manager | | `vault.secret.certification.jdbc.username` / `.password` | certification-manager | | `vault.secret.pbac.jdbc.username` / `.password` | pbac-manager | The trap is in the first row: **`vault.secret.jdbc.*` has five consumers across four services**, two of which are migration datasources that only connect at startup. If that pair is rotated and batch-task-manager and certification-manager are not restarted with the rest, they keep working on the credential they already hold — and then fail at their next restart, which may be weeks later and looks like a schema-migration failure rather than a credential one. If a migration fails weeks after a clean rotation, this is why. ### Message broker, cache, search and graph | Vault key | Read by | | ------------------------------------------------ | ---------------------------------------------------------------------------------------------- | | `vault.secret.spring.rabbitmq.username` | Every service, via `spring.rabbitmq.username` | | `vault.secret.spring.rabbitmq.password` | Same | | `vault.secret.rabbitmq.jks.password` | The broker TLS keystore passphrase | | `vault.secret.spring.redis.password` | Every service, via `spring.redis.password`, and separately by the second-level object cache | | `vault.secret.redis.sentinel.password` | Sentinel mode only, with an empty default | | `vault.secret.opensearch.username` / `.password` | The search client on every service, both defaulting to empty, and the machine-learning service | {% hint style="warning" %} **RabbitMQ and Redis each have two names for one credential.** One name is what the broker or cache itself is configured with; the other is what the OpenIAM services read. They are seeded from a single value, so they agree on a fresh installation and drift apart the moment one of them is changed on its own. **Both have to move together**, or the broker's password changes without the clients being told. This is the single commonest way a rotation on this page goes wrong, and its symptom is that every client is rejected at once. `vault.secret.opensearch.*` has a further wrinkle: the machine-learning service reads the Vault value and then overwrites it with the plain `opensearch.username` / `opensearch.password` properties, so on that one service the properties-file value wins. Set both consistently. {% endhint %} ### Keystores and encryption keys | Vault key | Read by | What it protects | | ------------------------------------------ | ------------------------------------------------------------------------ | ----------------------------------- | | `vault.secret.iam.jks.password` | OpenIAM's key management, on every service that decrypts a stored secret | The OpenIAM JKS keystore | | `vault.secret.iam.jks.key.password` | Same | The master key entry | | `vault.secret.iam.jks.cookie.key.password` | Same | The cookie encryption key entry | | `vault.secret.iam.jks.common.key.password` | Same | The common key entry | | `vault.secret.keystore.password` | The authentication login module | The keystore the login module opens | {% hint style="danger" %} **These are the dangerous ones, and they are not yours.** The same keystore decrypts stored managed-system passwords and user password history. Changing a key entry's password without re-keying the keystore makes every encrypted value in the product unreadable, and there is **no recovery from the application** — not from the Webconsole, not from a break-glass query, because the ciphertext is all that survives. The symptom on your side is stored managed-system passwords and password history becoming unreadable at once, across every managed system, immediately after a change window. Rotating the keystore *keys* is a migration project rather than a credential rotation; treat any request to do it as a project, and escalate it. {% endhint %} ### Managed systems `vault.secret.managed.system.` — one key per managed system, named after the managed system's own ID. This is the **service account OpenIAM uses to connect to a managed system**: the AD bind account, the database user, the SCIM token. It is not in `MNG_SYS` any more. On the first start of a current build, OpenIAM decrypts any legacy `MNG_SYS.PSWD` value, writes it to Vault and sets the column to `null`, so an empty `MNG_SYS.PSWD` is correct rather than a sign of a lost password. {% hint style="warning" %} **Break-glass: confirming where a managed system's password lives.** There is no screen that shows this, and an empty password field on the managed system looks the same whether the credential is in Vault or missing entirely. A read-only query settles it: {% code overflow="wrap" %} ```sql SELECT MANAGED_SYS_ID, NAME, PSWD IS NULL AS PSWD_IS_NULL FROM MNG_SYS; ``` {% endcode %} This is outside the supported change path: you are reading the `openiam` schema directly rather than through the Webconsole. Read-only, so it risks nothing and bypasses nothing, and it will not tell you whether the Vault key exists — only that the column is not where the credential is. `PSWD_IS_NULL` false on a current build means this managed system has never been started against a build that performed the move, and its credential is still in the column. **Never write to `MNG_SYS.PSWD`.** A value you put there is not encrypted the way OpenIAM expects, is not what the connector reads, and will be nulled the next time the service starts. The supported path is the managed system's own screen. {% endhint %} ### Mailboxes Modern form — `vault.secret.mailbox..`, where `` is the ID of the mailbox configuration as it appears on the mailbox screen. Eight suffixes: | Suffix | Used when | | --------------------------- | --------------------------------------------- | | `username` | Basic SMTP auth | | `password` | Basic SMTP auth | | `clientId` | Modern auth | | `tenantId` | Modern auth | | `authority` | Modern auth | | `clientSecret` | Modern auth, `authMethod = clientSecret` | | `clientCertificate` | Modern auth, `authMethod = clientCertificate` | | `clientCertificatePassword` | Modern auth, `authMethod = clientCertificate` | Which subset is written depends on **Auth Method**. Saving the mailbox writes `clientId`, `tenantId` and `authority` every time, then *either* `clientSecret` *or* `clientCertificatePassword` according to that field — never both. So a mailbox switched from certificate to secret leaves its old `clientCertificatePassword` key behind in Vault, unread. Legacy form — `vault.secret.mail.username` and `vault.secret.mail.password`. These are the pre-4.2.1.1 single-mailbox keys. Upgrading to 4.2.1.1 moves them to `vault.secret.mailbox.MIGRATED_MB.username` / `.password` and **deletes the old keys**, so a migrated deployment has no `vault.secret.mail.*` keys left and the mailbox ID to look for is the literal `MIGRATED_MB`. A deployment upgrading from a version before that, which still has them, has them relocated into the property-value namespace on the first start after the upgrade instead. {% hint style="warning" %} **The system-properties screen is not where you change a working mailbox.** The two SMTP entries on that screen — `org.openiam.smtp.vault.secret.mail.password` and `...mail.username` — belong to the deprecated **Gateway (SMTP)** tab, and are stored as secret properties under their own IDs. Nothing in the mail path reads them: a deployment on 4.2.1.1 or later sends through the mailbox configuration and its `vault.secret.mailbox..*` keys. So the screen accepts the change, reports success, and the mail service carries on with the old password. **Confirm the outcome, not the save.** Send a test notification from [Mail and notifications](/administration-guide/platform/mail-and-notifications.md) after editing. If mail still fails with the old credential, the mailbox is the place to change it — open the mailbox configuration and set the password there, where the suffix keys above are written. {% endhint %} ### Secret system properties These are the only keys not under a `vault.secret.` name. A system property of type `Secret` has its value stored under the property's own ID, in a namespace of its own, with the `PROPERTY_VALUE` column left empty: | Vault key | Read by | | ----------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `propertyvalue/org.openiam.default.password` | The fallback password the platform uses when it has to set one and none was supplied. Generated at random on the first start that finds it unset, so it is never absent | | `propertyvalue/org.openiam.smtp.vault.secret.mail.password` | The deprecated Gateway (SMTP) screen. Nothing in the mail path reads it — see [Mailboxes](#mailboxes) | | `propertyvalue/org.openiam.smtp.vault.secret.mail.username` | As above | You rotate these from **Administration → System Configuration**, on the tab the property belongs to. A stored secret shows as `******` rather than its value, and saving that mask back leaves Vault untouched rather than clearing it. To read one back, or to remove one, see [Secret properties keep their value in Vault](/administration-guide/reference/system-properties.md#secret-properties-keep-their-value-in-vault-not-in-the-database). ### OTP providers and social keys | Vault key | Read by | | ------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `vault.secret.otp.` | The OTP provider. The key name embeds the identifier you typed in the OTP provider form, so renaming the attribute orphans the old key | | `vault.secret.otp.code.` | Nothing any more. Twilio voice codes used to wait here for Twilio's fetch; they are now held in Redis under a single-use call token. Keys left over from an older release hold codes that no longer verify and can be deleted | | `vault.secret.appleid.private.key.` | Apple sign-in. Written when you save the authentication provider, erased when you delete it | ## What is in a properties file, and what is not Nothing in `conf/properties/` holds a password. Those files carry hosts, ports, URLs, schema names, pool sizes, TLS flags and keystore *paths*; every credential comes from Vault. If somebody tells you a password is "in the properties file", it is not — with two exceptions, and both are shipped literals rather than deployment secrets. {% hint style="danger" %} **Two secrets ship as published literals, and every deployment that has not changed them shares them.** * **`vault.ssl.key-store-password`, shipped `passwd00`.** It opens the client keystore every service uses to authenticate to Vault. It is the bootstrap secret, so it cannot itself live in Vault. * **`org.openiam.mq.broker.encryption.key`, shipped `ff808181670838e0016708610547001b`.** It encrypts message payloads on the bus. It is not the broker password, and it is not in Vault. Neither is changeable from the Webconsole and neither is yours to change, but both are yours to raise. A deployment still on either value is running on a credential published with the product. Ask the deployment owner which of the two were changed at installation, and treat "we do not know" as "they were not". Changing the broker encryption key needs every service updated and restarted together, because a message encrypted with the old key cannot be read with the new one — so it is a drained-queue change, not a rolling one. {% endhint %} ## The shipped credentials are published defaults The starter deployment seeds twenty-three credentials — the broker user, the Redis password, the database root and per-schema passwords, the OpenSearch admin password, the LDAP and JKS keystore passwords, and the four OpenIAM key-entry passwords — and **every one of those defaults is published with the product**. The starter also leaves the hardened Vault deployment mode switched off. {% hint style="danger" %} Treat a first-time audit of that list as an **exposure**, not as a configuration review. A deployment that started from the shipped starter and did not override the defaults is authenticating with values anyone can read. Because they were public from the moment the deployment started, the correct action is to issue new ones and revoke the old — never to restore an earlier value. Raise it with the deployment owner as an exposure with a date, and ask which values were overridden. **You cannot confirm this from the Webconsole.** No screen shows a service credential's value, so the deployment owner is the only person who can answer it, and a first answer of "the defaults are fine" is worth pressing on. {% endhint %} ## Related * The [Installation Guide](/installation/installation.md) — the platform rotation procedure itself: Vault writes, the environment-variable cleanup, the restart order, and the shipped starter defaults * [Change configuration safely](/administration-guide/start/change-safely.md) — the reversibility categories this page depends on * [Where settings live](/administration-guide/start/where-settings-live.md) — which layer a value comes from * [Configure a managed system](/administration-guide/lifecycle/configure-managed-system.md) and [Verify connectivity to the target](/administration-guide/lifecycle/verify-connection.md) — the managed-system service account * [Mail and notifications](/administration-guide/platform/mail-and-notifications.md) — mailbox configuration and the SMTP screen * [SMS and one-time passwords](/administration-guide/platform/sms-and-otp.md) — `vault.secret.otp.*` * [Social sign-in](/administration-guide/security/social-authentication.md) — `vault.secret.appleid.private.key.` * [Diagnose a failed operation](/administration-guide/operations/diagnose-a-failed-operation.md) — reading the queue, cache and search layers whose credentials you just rotated *Applies to OpenIAM 2026.8.1. Last reviewed 14 September 2026.* --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.openiam.com/administration-guide/security/rotate-service-credentials.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.