> 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/reference/search-indexes.md).

# Search indexes and the authorization graph

Every search index OpenIAM maintains, how to rebuild one, and how to rebuild the authorization graph.

## What this is, and when you need it

OpenIAM keeps **32** OpenSearch/Elasticsearch indexes. Symptoms like "the user exists but search cannot find them", "an orphan account does not appear in the orphan screen", or "audit search returns nothing for a period" are index problems, not data problems. Use the table to turn a symptom into the one index you should rebuild.

The right-hand column is the index's real name — what an OpenSearch query, a connection error or a disk-usage report will call it. The left is the identifier OpenIAM uses for the same index, and the name this guide and its cross-references use. Match on the right-hand name when you are looking outside OpenIAM, on the left when you are looking inside it.

| Index                             | Name in OpenSearch                  |
| --------------------------------- | ----------------------------------- |
| `USER_ATTRIBUTES`                 | `userattributes`                    |
| `USERS`                           | `users`                             |
| `USER_RECALCULATION_DOC`          | `user-recalculation`                |
| `USER_VIOLATED_SOD_POLICY`        | `user-violated-sod-policy`          |
| `ORPHAN`                          | `orphan`                            |
| `EMAIL`                           | `email`                             |
| `AUDIT_LOG_TARGETS`               | `auditlogtargets`                   |
| `AUDIT_LOG`                       | `auditlog`                          |
| `AUDIT_LOG_ATTRIBUTE`             | `auditlogattribute`                 |
| `PHONE`                           | `phone`                             |
| `LOGIN`                           | `logins`                            |
| `CONNECTOR_REPLY`                 | `connectorreply`                    |
| `PROVISION_STREAM`                | `provisionstream`                   |
| `CONTACT_INFO`                    | `contacts`                          |
| `IDENTITY`                        | `identity`                          |
| `LOCATION`                        | `location`                          |
| `ROLE`                            | `role`                              |
| `MANAGED_SYS`                     | `managedsystem`                     |
| `GROUP_ATTRIBUTES`                | `groupattributes`                   |
| `GROUP`                           | `group`                             |
| `RESOURCE_ATTRIBUTES`             | `resourceattributes`                |
| `RESOURCE`                        | `resource`                          |
| `GROOVY_SCRIPT`                   | `groovyscript`                      |
| `ORGANIZATION`                    | `organization`                      |
| `METADATA_TYPE`                   | `metadatatype`                      |
| `URI_FEDERATION_STATISTIC`        | `urifederationstatistic`            |
| `PROVISION_REQUEST_DOC`           | `provisionrequest`                  |
| `PROVISION_CONNECTOR_REQUEST_DOC` | `provisionconnectorrequest`         |
| `INCOMPLETE_SELF_REG`             | `incomplete-self-registration`      |
| `INCOMPLETE_SELF_REG_USER`        | `incomplete-self-registration-user` |
| `RECO_SYNCH_INFO_STORAGE`         | `reconsynchstorage`                 |
| `RECON_SYNCH_INFO_STORAGE_OBJ`    | `reconsynchstorageobject`           |

Connection settings — `opensearch.host` and `opensearch.port`, which default to `localhost:9200` — are read from the deployment's own properties at startup, not from **Administration → System Configuration**, so you cannot see or change them from the Webconsole; the deployment owner can, and changing them needs a restart ([Installation Guide](/installation/installation.md)). The client timeouts `org.openiam.opensearch.connection.timeout`, `.socket.timeout` and `.read.timeout` behave the same way. What you *can* observe is the consequence: when the host or port is wrong, every screen backed by an index returns nothing rather than reporting an error, and the failure is recorded in the log of whichever service ran the query, never on screen.

## Rebuilding an index

Reindex is a Webconsole screen at `/webconsole/reindex`, which lists the indexable entity classes and rebuilds the one you pick. It accepts a super-administrator and nobody else, and each run writes a `REINDEX` audit event carrying the entity it rebuilt, so a rebuild is attributable.

{% hint style="warning" %}
A reindex reads the whole entity set. On a large directory it is an expensive operation that competes with normal traffic. Rebuild one index, not all of them, and do it in a maintenance window unless you are recovering from an outage.
{% endhint %}

Verification is not "the screen accepted it". Search for an object you know is missing, and confirm the `REINDEX` audit event completed rather than started.

## Rebuilding the authorization graph

Effective access is computed from a graph, not evaluated per request. **No Webconsole screen rebuilds that graph and no shipped batch task can be scheduled to** — the rebuild is a request against `openiam-esb` instead. See [Rebuild the authorization graph](/administration-guide/operations/rebuild-the-authorization-graph.md), which covers the diagnosis to do first and the request itself.

Graph settings are deployment-owned in the same way. Two of the shipped keys are misspelled — `gremilin.endpoint` and `gremilin.port`, defaults `localhost:8182`, alongside `gremlin.provider=janusgraph`. If you are asking the deployment owner to change one, quote the misspelling; the corrected spelling is a key nothing reads, and setting it fails silently.

Symptoms of a stale graph are specific: an entitlement was granted or revoked, the membership row is correct in the Webconsole, and the user's *effective* access still disagrees. Confirm the membership first — if membership is wrong, a graph rebuild will faithfully rebuild the wrong answer.

*Applies to OpenIAM 2026.8.1. Last reviewed 7 August 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/reference/search-indexes.md?ask=<question>&goal=<user_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.
