> 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/getting-started-guide/verify-and-first-login.md). # Verify health and log in Confirm every service is healthy, sign in for the first time, and create a break-glass administrator. **Goal:** a healthy stack, a working admin login, the content provider configured, and default credentials changed.\ **Time:** 20–30 minutes. {% stepper %} {% step %} **Health check** {% code overflow="wrap" %} ```bash openiam-cli status ``` {% endcode %} Backend services (esb, idm, auth, synchronization, reconciliation, workflow, email, groovy, auditlog, batchtask, certification-manager, device, business-rule) and the UI apps (`idp`, `webconsole`, `selfservice`, `selfservice-ext`, `ui-static`, `reportviewer`) should report healthy. Healthy lines look like: {% code overflow="wrap" %} ``` [OK] - openiam-esb - Service working. Application status: [ UP ] ``` {% endcode %} while a service still starting reports `[WARNING] - … - Service working, but Application status: [ DOWN ]. Probably it's still starting.` — normal during the first 10–15 minutes, a problem if it persists. You can also probe any UI app directly through its actuator endpoint (the UI apps listen internally on 8081–8086: idp 8081, webconsole 8082, selfservice 8083, selfservice-ext 8084, reportviewer 8085, ui-static 8086): {% code overflow="wrap" %} ```bash curl -s http://localhost:8082/webconsole/actuator/health # {"status":"UP"} ``` {% endcode %} To inspect one service: {% code overflow="wrap" %} ```bash openiam-cli log synchronization # tails /usr/local/openiam/logs/synchronization.log ``` {% endcode %} {% endstep %} {% step %} **First login** Open `https:///webconsole` and sign in with the default administrator: * Username: `sysadmin` * Password: `passwd00` You are immediately forced to change the password — the current password policy is displayed next to the form. Then the first-login wizard walks you through: 1. **Content provider setup.** A content provider represents a domain that OpenIAM serves — authentication policy, theming, and URL rules hang off it; the reverse proxy matches every request to one by its *Domain Pattern*. Enter a name (e.g. `Default CP`); the *Domain Pattern* field comes prefilled with the host's address — make sure it is the DNS name you actually browse to; and select SSL support (you enabled HTTPS on the previous page). *Application servers* keeps its default.
The first-run Content Provider setup screen, with the provider name, the domain pattern, the SSL support choice and one application server entry
2. **Challenge questions** for your admin account. Landing in the Webconsole can take a few minutes the first time while caches warm up. {% endstep %} {% step %} **Create a break-glass admin** Before touching authentication settings later in this guide, create a second administrator account: **User Admin → Create User**, then grant the **Super Security Admin** role (the same role `sysadmin` holds). **Set its password yourself** using the admin *Change Password* action on the user's record — don't rely on an activation email, since SMTP isn't configured until [Require MFA for one URL](/getting-started-guide/authentication/mfa-for-one-url.md). Verify you can log in with it. If an MFA or policy experiment ever locks out one admin, you use the other. {% endstep %} {% step %} **Change the remaining defaults** The stack ships with well-known defaults. For an isolated lab you may defer this to after the POC; for anything network-reachable, do it now. | Credential | Default | How to change | | ----------------------- | ------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | RabbitMQ `openiam` user | `passwd00` | Three coordinated steps: update the secret in Vault (`vault kv put secret/openiam/RABBITMQ_PASSWORD …` — and its `vault.secret.rabbitmq.password` twin), change it on the broker (`rabbitmqctl change_password openiam ''`), then `openiam-cli stop && openiam-cli start`. Full procedure with the Vault login steps: Administration Guide → *Changing service passwords manually* | | Redis | `passwd00` | Same pattern via the Redis keys in Vault — see the same guide page | | Database users | schema name (openiam → `idmuser`/`idmuser`) | In your database and the matching Vault JDBC secrets | | Grafana (if installed) | `admin`/`admin` | `https://:3000` → profile → change password | **Whatever you decide about RabbitMQ, note the current password** — you will type it into the AD connector installer in [Install the AD connector](/getting-started-guide/lifecycle/install-ad-connector.md), and a stale value there is a classic time sink. {% endstep %} {% endstepper %} ## You know this worked when… {% hint style="success" %} You can log in to `/webconsole` with your changed password **and** with the break-glass admin; `/selfservice` loads; `openiam-cli status` is clean. {% endhint %} Next: the [Identity lifecycle POC](/getting-started-guide/lifecycle.md). --- # 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/getting-started-guide/verify-and-first-login.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.