> For the complete documentation index, see [llms.txt](https://doc.engenius.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://doc.engenius.ai/bmc-user-guide/security/local-users-and-sessions.md).
# Local Users & Sessions
Controlling who can access the BMC is the first and most important step in securing your server. By default, the BMC uses a local user database. You should create individual accounts for each administrator and assign them the appropriate level of privilege.
This chapter shows you how to manage local user accounts, understand privilege levels, and monitor active sessions.
## **Creating, editing, and deleting user accounts**
You can manage all local user accounts from the **User Management** page.
1. In the sidebar menu, navigate to **Security and access** > **User management**.
2. To create a new user, click the **Add user** button.
3. Fill in the user's details:
* **Username**: The login name for the user.
* **User Password**: Set a strong password. The interface will enforce any configured password complexity rules.
* **Privilege**: Assign the appropriate access level.
* **Account status**: Set to **Enabled** to make the account active.
4. Click **Add user** to save the new account.
To edit or delete an existing user, click the **pencil icon** (edit) or **trash icon** (delete) next to their name in the user list.
{% hint style="success" %}
**Best Practice: Create named administrator accounts**
Instead of everyone sharing the default `root` account, it's a critical security practice to create a named administrator account for each person who needs access. After creating your own administrator account, you should change the `root` password to something long and complex and store it securely, or disable the account if your security policy allows. This creates accountability and improves audit trails.
{% endhint %}
## **Understanding user privileges**
The BMC has three distinct privilege levels, allowing you to implement the principle of least privilege.
* **Administrator**: Has full read/write access to everything. Can change all settings, manage other users, and perform all operations.
* **Operator**: Has access to most operational tasks, such as power cycling the server, using the KVM, and mounting virtual media. However, they cannot change critical security settings or manage other users.
* **ReadOnly**: Can view status pages, logs, and current settings, but cannot make any changes. This role is perfect for monitoring or auditing purposes.
## **Viewing active user sessions**
The **Sessions** page provides a real-time view of all users who are currently logged into the BMC, and what method they are using. This is useful for security auditing and for seeing who is actively managing the server.
To view active sessions, navigate to **Security and access** > **Sessions**.
The sessions table provides the following information:
* **Session ID**: The unique identifier for the active session.
* **Session Type**: The protocol or method used to connect (e.g., `WebUI`, `IPMI`, `Redfish`, or `SOL`).
* **Mount Type**: If the session is related to virtual media, this specifies how it was mounted.
* **User ID**: The user's numerical ID within the system.
* **User Name**: The login username associated with the session.
* **IP Address**: The source IP address of the connection.
* **Privilege**: The privilege level of the logged-in user.
You can use the **trash icon** to terminate an active session, which will force that user to be logged out.
---
# 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://doc.engenius.ai/bmc-user-guide/security/local-users-and-sessions.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.
