{ "api_version": "1", "kind": "dse_post", "self": "https://update.dsesecurity.com/api/v1/posts/check-both-wazuh-permission-mappings-for-a-read-only-user/", "item": { "id": "https://update.dsesecurity.com/updates/check-both-wazuh-permission-mappings-for-a-read-only-user/", "slug": "check-both-wazuh-permission-mappings-for-a-read-only-user", "url": "https://update.dsesecurity.com/updates/check-both-wazuh-permission-mappings-for-a-read-only-user/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/check-both-wazuh-permission-mappings-for-a-read-only-user.md", "json": "https://update.dsesecurity.com/api/v1/posts/check-both-wazuh-permission-mappings-for-a-read-only-user/" }, "title": "Check both Wazuh permission mappings for a read-only user", "summary": "Check the indexer permissions and separate Wazuh server role mapping for a read-only internal user. Include the documented run_as and dashboard refresh requirements in the validation plan.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "advisory", "name": "Advisory" }, "featured": false, "image": { "theme": "cyber-defense", "label": "Cyber defense", "alt": "Layered glass and metal cyber-defense structure with controlled blue and gold signal paths.", "card_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-10-30T06:47:21+00:00", "modified_at": "2026-10-30T06:47:28+00:00", "reviewed_on": "2026-10-30", "reading_minutes": 3, "word_count": 521, "potentially_affected": "Wazuh deployments following the official internal read-only user procedure; actual identity and permission mappings require review.", "dse_recommendation": "DSE recommends a two-layer permission review followed by positive and negative tests using the actual intended read-only identity.", "primary_source": { "name": "Wazuh — Wazuh RBAC - How to create and map internal users", "url": "https://documentation.wazuh.com/current/user-manual/user-administration/rbac.html", "published_on": null, "authority": "documentation.wazuh.com" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "

Bottom line: Do not close a read-only account request after creating the identity. Review the two documented permission mappings and test the intended account’s actual reading and administrative boundaries.

\n

Source fact: documented behavior

\n

The Wazuh RBAC – How to create and map internal users guide configures indexer read permissions and a read-only tenant for the internal read-only user.

\n

It separately maps that internal user to the Wazuh readonly role through the server’s role-mapping workflow.

\n

The procedure requires run_as to be true, then calls for a dashboard restart and clearing the browser cache and cookies.

\n

What the source does not establish

\n

This article follows the documented internal read-only account procedure. It does not approve access to every index or tenant, design a custom document restriction or claim that successful authentication proves the requested authorization boundaries.

\n

Applicability questions

\n\n

DSE recommendation: controlled next steps

\n

The following steps are DSE recommendations based on the cited source.

\n

DSE recommends a two-layer permission review followed by positive and negative tests using the actual intended read-only identity.

\n
    \n
  1. Write the account’s intended reading tasks before copying a role example. Identify the information population and tenant it is allowed to reach. Treat the source’s broad example permissions as a procedure to assess, not automatic approval for every organization. Have the data owner identify any narrower requirements that need a separate role design and review.
    2. \n
  2. Inspect the indexer mapping and the Wazuh server role mapping as two distinct entries in the account record. Confirm that both refer to the same intended internal identity. Review the documented runtime setting and refresh actions with the dashboard operator, preserving a recovery administrator and a maintenance allowance for the restart rather than experimenting with the only available management session.
    3. \n
  3. Start the validation with a fresh browser session for the intended user after the planned refresh. Attempt the approved reading tasks and the specifically prohibited administrative action. Keep the administrator’s successful session out of the acceptance evidence. If one layer works and another does not, investigate that mapping directly instead of granting a broader role merely to suppress the error.
    4. \n
\n

Verification and evidence

\n

Proposed verification: prepare an allowed view, an excluded information population if the approved design includes one, and a harmless administrative action that the read-only identity must not perform. Record the expected outcome for each before signing in. Use a test account or approved isolated arrangement; no account creation or permission change was performed for this article.

\n

Retain the redacted identity reference, both role mappings, the reviewed runtime setting and actual observations from the fresh user session. An incomplete negative test remains an open authorization question. Do not report the account as accepted merely because the dashboard loads, a role label says read-only or an administrator can retrieve the same data.

\n

Official references

\n\n

Source review completed October 30, 2026. Recheck the official source and deployment-specific applicability before changing production settings.

\n", "content_text": "Bottom line: Do not close a read-only account request after creating the identity. Review the two documented permission mappings and test the intended account’s actual reading and administrative boundaries.\nSource fact: documented behavior\nThe Wazuh RBAC – How to create and map internal users guide configures indexer read permissions and a read-only tenant for the internal read-only user.\nIt separately maps that internal user to the Wazuh readonly role through the server’s role-mapping workflow.\nThe procedure requires run_as to be true, then calls for a dashboard restart and clearing the browser cache and cookies.\nWhat the source does not establish\nThis article follows the documented internal read-only account procedure. It does not approve access to every index or tenant, design a custom document restriction or claim that successful authentication proves the requested authorization boundaries.\nApplicability questions\n\nWhich internal identity is being reviewed?\nWhat indexer role and tenant permissions are actually mapped?\nWhat separate Wazuh server role mapping applies?\nWhich permitted reads and prohibited changes must be demonstrated?\n\nDSE recommendation: controlled next steps\nThe following steps are DSE recommendations based on the cited source.\nDSE recommends a two-layer permission review followed by positive and negative tests using the actual intended read-only identity.\n\nWrite the account’s intended reading tasks before copying a role example. Identify the information population and tenant it is allowed to reach. Treat the source’s broad example permissions as a procedure to assess, not automatic approval for every organization. Have the data owner identify any narrower requirements that need a separate role design and review.\nInspect the indexer mapping and the Wazuh server role mapping as two distinct entries in the account record. Confirm that both refer to the same intended internal identity. Review the documented runtime setting and refresh actions with the dashboard operator, preserving a recovery administrator and a maintenance allowance for the restart rather than experimenting with the only available management session.\nStart the validation with a fresh browser session for the intended user after the planned refresh. Attempt the approved reading tasks and the specifically prohibited administrative action. Keep the administrator’s successful session out of the acceptance evidence. If one layer works and another does not, investigate that mapping directly instead of granting a broader role merely to suppress the error.\n\nVerification and evidence\nProposed verification: prepare an allowed view, an excluded information population if the approved design includes one, and a harmless administrative action that the read-only identity must not perform. Record the expected outcome for each before signing in. Use a test account or approved isolated arrangement; no account creation or permission change was performed for this article.\nRetain the redacted identity reference, both role mappings, the reviewed runtime setting and actual observations from the fresh user session. An incomplete negative test remains an open authorization question. Do not report the account as accepted merely because the dashboard loads, a role label says read-only or an administrator can retrieve the same data.\nOfficial references\n\nWazuh RBAC – How to create and map internal users — Wazuh; official product documentation.\n\nSource review completed October 30, 2026. Recheck the official source and deployment-specific applicability before changing production settings.", "content_markdown": "Bottom line: Do not close a read-only account request after creating the identity. Review the two documented permission mappings and test the intended account’s actual reading and administrative boundaries.\n\n## Source fact: documented behavior\n\nThe [Wazuh RBAC – How to create and map internal users](https://documentation.wazuh.com/current/user-manual/user-administration/rbac.html) guide configures indexer read permissions and a read-only tenant for the internal read-only user.\n\nIt separately maps that internal user to the Wazuh readonly role through the server’s role-mapping workflow.\n\nThe procedure requires run_as to be true, then calls for a dashboard restart and clearing the browser cache and cookies.\n\n## What the source does not establish\n\nThis article follows the documented internal read-only account procedure. It does not approve access to every index or tenant, design a custom document restriction or claim that successful authentication proves the requested authorization boundaries.\n\n## Applicability questions\n\n- Which internal identity is being reviewed?\n\n- What indexer role and tenant permissions are actually mapped?\n\n- What separate Wazuh server role mapping applies?\n\n- Which permitted reads and prohibited changes must be demonstrated?\n\n## DSE recommendation: controlled next steps\n\nThe following steps are DSE recommendations based on the cited source.\n\nDSE recommends a two-layer permission review followed by positive and negative tests using the actual intended read-only identity.\n\n- Write the account’s intended reading tasks before copying a role example. Identify the information population and tenant it is allowed to reach. Treat the source’s broad example permissions as a procedure to assess, not automatic approval for every organization. Have the data owner identify any narrower requirements that need a separate role design and review.\n\n- Inspect the indexer mapping and the Wazuh server role mapping as two distinct entries in the account record. Confirm that both refer to the same intended internal identity. Review the documented runtime setting and refresh actions with the dashboard operator, preserving a recovery administrator and a maintenance allowance for the restart rather than experimenting with the only available management session.\n\n- Start the validation with a fresh browser session for the intended user after the planned refresh. Attempt the approved reading tasks and the specifically prohibited administrative action. Keep the administrator’s successful session out of the acceptance evidence. If one layer works and another does not, investigate that mapping directly instead of granting a broader role merely to suppress the error.\n\n## Verification and evidence\n\nProposed verification: prepare an allowed view, an excluded information population if the approved design includes one, and a harmless administrative action that the read-only identity must not perform. Record the expected outcome for each before signing in. Use a test account or approved isolated arrangement; no account creation or permission change was performed for this article.\n\nRetain the redacted identity reference, both role mappings, the reviewed runtime setting and actual observations from the fresh user session. An incomplete negative test remains an open authorization question. Do not report the account as accepted merely because the dashboard loads, a role label says read-only or an administrator can retrieve the same data.\n\n## Official references\n\n- [Wazuh RBAC – How to create and map internal users](https://documentation.wazuh.com/current/user-manual/user-administration/rbac.html) — Wazuh; official product documentation.\n\nSource review completed October 30, 2026. Recheck the official source and deployment-specific applicability before changing production settings." }, "json_ld": { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://dsesecurity.com/#organization", "name": "Detection Systems & Engineering", "alternateName": "DSE Security", "url": "https://dsesecurity.com/", "logo": { "@type": "ImageObject", "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20" } }, { "@type": "Organization", "@id": "https://update.dsesecurity.com/#editorial-team", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/", "parentOrganization": { "@id": "https://dsesecurity.com/#organization" } }, { "@type": "WebSite", "@id": "https://update.dsesecurity.com/#website", "name": "DSE Updates", "alternateName": "DSE Security Knowledge Hub", "url": "https://update.dsesecurity.com/", "inLanguage": "en-US", "publisher": { "@id": "https://dsesecurity.com/#organization" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "WebPage", "@id": "https://update.dsesecurity.com/updates/check-both-wazuh-permission-mappings-for-a-read-only-user/", "url": "https://update.dsesecurity.com/updates/check-both-wazuh-permission-mappings-for-a-read-only-user/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-10-30" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/check-both-wazuh-permission-mappings-for-a-read-only-user/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "Cybersecurity", "item": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "@type": "ListItem", "position": 3, "name": "Check both Wazuh permission mappings for a read-only user", "item": "https://update.dsesecurity.com/updates/check-both-wazuh-permission-mappings-for-a-read-only-user/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/check-both-wazuh-permission-mappings-for-a-read-only-user/#article", "identifier": "https://update.dsesecurity.com/updates/check-both-wazuh-permission-mappings-for-a-read-only-user/", "url": "https://update.dsesecurity.com/updates/check-both-wazuh-permission-mappings-for-a-read-only-user/", "headline": "Check both Wazuh permission mappings for a read-only user", "description": "Check the indexer permissions and separate Wazuh server role mapping for a read-only internal user.", "abstract": "Check the indexer permissions and separate Wazuh server role mapping for a read-only internal user. Include the documented run_as and dashboard refresh requirements in the validation plan.", "articleBody": "Bottom line: Do not close a read-only account request after creating the identity. Review the two documented permission mappings and test the intended account’s actual reading and administrative boundaries.\nSource fact: documented behavior\nThe Wazuh RBAC – How to create and map internal users guide configures indexer read permissions and a read-only tenant for the internal read-only user.\nIt separately maps that internal user to the Wazuh readonly role through the server’s role-mapping workflow.\nThe procedure requires run_as to be true, then calls for a dashboard restart and clearing the browser cache and cookies.\nWhat the source does not establish\nThis article follows the documented internal read-only account procedure. It does not approve access to every index or tenant, design a custom document restriction or claim that successful authentication proves the requested authorization boundaries.\nApplicability questions\n\nWhich internal identity is being reviewed?\nWhat indexer role and tenant permissions are actually mapped?\nWhat separate Wazuh server role mapping applies?\nWhich permitted reads and prohibited changes must be demonstrated?\n\nDSE recommendation: controlled next steps\nThe following steps are DSE recommendations based on the cited source.\nDSE recommends a two-layer permission review followed by positive and negative tests using the actual intended read-only identity.\n\nWrite the account’s intended reading tasks before copying a role example. Identify the information population and tenant it is allowed to reach. Treat the source’s broad example permissions as a procedure to assess, not automatic approval for every organization. Have the data owner identify any narrower requirements that need a separate role design and review.\nInspect the indexer mapping and the Wazuh server role mapping as two distinct entries in the account record. Confirm that both refer to the same intended internal identity. Review the documented runtime setting and refresh actions with the dashboard operator, preserving a recovery administrator and a maintenance allowance for the restart rather than experimenting with the only available management session.\nStart the validation with a fresh browser session for the intended user after the planned refresh. Attempt the approved reading tasks and the specifically prohibited administrative action. Keep the administrator’s successful session out of the acceptance evidence. If one layer works and another does not, investigate that mapping directly instead of granting a broader role merely to suppress the error.\n\nVerification and evidence\nProposed verification: prepare an allowed view, an excluded information population if the approved design includes one, and a harmless administrative action that the read-only identity must not perform. Record the expected outcome for each before signing in. Use a test account or approved isolated arrangement; no account creation or permission change was performed for this article.\nRetain the redacted identity reference, both role mappings, the reviewed runtime setting and actual observations from the fresh user session. An incomplete negative test remains an open authorization question. Do not report the account as accepted merely because the dashboard loads, a role label says read-only or an administrator can retrieve the same data.\nOfficial references\n\nWazuh RBAC – How to create and map internal users — Wazuh; official product documentation.\n\nSource review completed October 30, 2026. Recheck the official source and deployment-specific applicability before changing production settings.", "datePublished": "2026-10-30T06:47:21+00:00", "dateModified": "2026-10-30T06:47:28+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/check-both-wazuh-permission-mappings-for-a-read-only-user/" }, "inLanguage": "en-US", "isAccessibleForFree": true, "author": { "@type": "Organization", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "@id": "https://dsesecurity.com/#organization" }, "image": { "@type": "ImageObject", "@id": "https://update.dsesecurity.com/updates/check-both-wazuh-permission-mappings-for-a-read-only-user/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/cyber-defense-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Check both Wazuh permission mappings for a read-only user" }, "articleSection": [ "Cybersecurity", "IT" ], "keywords": [ "Cybersecurity", "IT", "Guide", "Advisory priority" ], "genre": "Guide", "about": [ { "@type": "Thing", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "@type": "Thing", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "wordCount": 521, "timeRequired": "PT3M", "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usageInfo": "https://update.dsesecurity.com/usage/", "copyrightHolder": { "@id": "https://dsesecurity.com/#organization" }, "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "citation": { "@type": "CreativeWork", "name": "Wazuh — Wazuh RBAC - How to create and map internal users", "url": "https://documentation.wazuh.com/current/user-manual/user-administration/rbac.html" } } ] } }