# Monitoring & ML not available: "you should also assign the monitoring\_user role."

**URL:** <https://discuss.elastic.co/t/monitoring-ml-not-available-you-should-also-assign-the-monitoring-user-role/196162>\
**Category:** Kibana\
**Created:** [August 21, 2019, 4:41pm UTC](https://discuss.elastic.co/t/monitoring-ml-not-available-you-should-also-assign-the-monitoring-user-role/196162 "2019-08-21T16:41:37Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![jetnet](https://avatars.discourse-cdn.com/v4/letter/j/a87d85/32.png) [@jetnet](https://discuss.elastic.co/u/jetnet)\
**Post date:** [August 21, 2019, 4:41pm UTC](https://discuss.elastic.co/t/monitoring-ml-not-available-you-should-also-assign-the-monitoring-user-role/196162/1 "2019-08-21T16:41:38Z")

</div>

One more issue after upgrade 6.8 -\> 7.3

It is not clear how to grant "Stack Monitoring" and "Machine Learning" privileges to an AD group (`unmapped_groups_as_roles: true`), which already has access to **all** indices and has **all** cluster privileges.

There is a message in Kibana "_you should also assign the monitoring\_user role_", but it's not clear how to do that.  
Is it something for role\_mapping?

**Note** : a user from that AD group can access all monitoring data, when querying ES directly. Why does Kibana refuse to show the Monitoring page?

Thanks!

---

<div class="post-metadata">

**Author:** ![Igor\_Zaytsev](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/igor_zaytsev/32/50662_2.png) [@Igor\_Zaytsev](https://discuss.elastic.co/u/Igor_Zaytsev)\
**Post date:** [August 22, 2019, 1:19am UTC](https://discuss.elastic.co/t/monitoring-ml-not-available-you-should-also-assign-the-monitoring-user-role/196162/2 "2019-08-22T01:19:29Z")

</div>

Hey @jetnet!

Some specific features like Monitoring and Machine Learning might require write access to be able to set some config settings.

You will need to map correct roles to specific user groups. Checkout #7 [https://www.elastic.co/guide/en/elasticsearch/reference/current/configuring-ldap-realm.html](https://www.elastic.co/guide/en/elasticsearch/reference/current/configuring-ldap-realm.html) for Monitoring example.

You'll need to also map additional roles for Machine Learning features, checkout the relevant build-in roles here: [https://www.elastic.co/guide/en/elastic-stack-overview/current/built-in-roles.html](https://www.elastic.co/guide/en/elastic-stack-overview/current/built-in-roles.html)

---

<div class="post-metadata">

**Author:** ![jetnet](https://avatars.discourse-cdn.com/v4/letter/j/a87d85/32.png) [@jetnet](https://discuss.elastic.co/u/jetnet)\
**Post date:** [August 22, 2019, 6:29am UTC](https://discuss.elastic.co/t/monitoring-ml-not-available-you-should-also-assign-the-monitoring-user-role/196162/3 "2019-08-22T06:29:10Z")

</div>

hello Igor,

as I wrote, I'm using an **unmaped** AD group as a role, and the role has **full** index and cluster access.  
Are there some restrictions on Kibana 7.x when using `unmapped_groups_as_roles: true`?

Thanks!  
P.S. It's always disappointing, when an upgrade breaks something, that used to work with the previous version 🙂

---

<div class="post-metadata">

**Author:** ![jetnet](https://avatars.discourse-cdn.com/v4/letter/j/a87d85/32.png) [@jetnet](https://discuss.elastic.co/u/jetnet)\
**Post date:** [August 22, 2019, 11:47am UTC](https://discuss.elastic.co/t/monitoring-ml-not-available-you-should-also-assign-the-monitoring-user-role/196162/4 "2019-08-22T11:47:20Z")

</div>

I added a role-mapping for this group:

```auto
POST /_security/role_mapping/myADgroup
{
  "roles": [
    "monitoring_user",
    "machine_learning_admin"
  ],
  "enabled": true,
  "rules": {
    "field": {
      "groups": "CN=myADgroup,OU=Groups,DC=company,DC=com"
    }
  }
}

```

This fixed the issue.

But the question remains: why wasn't that necessary for Kibana 6.x?

P.S. the wrong "no access" status is still shown in Kibana, even though the Monitoring and ML pages are available now:

 ![image](https://us1.discourse-cdn.com/elastic/original/3X/9/3/93418d38ce91066e1aafb3e0836451fc43b3c52d.png)

---

<div class="post-metadata">

**Author:** ![Igor\_Zaytsev](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/igor_zaytsev/32/50662_2.png) [@Igor\_Zaytsev](https://discuss.elastic.co/u/Igor_Zaytsev)\
**Post date:** [August 22, 2019, 3:43pm UTC](https://discuss.elastic.co/t/monitoring-ml-not-available-you-should-also-assign-the-monitoring-user-role/196162/5 "2019-08-22T15:43:20Z")

</div>

Glad you got your issue resolved.

New features might come with more flexibility which would require more access.

Please note that the "Privilege Summary" is per Space level. Here is more info: [https://www.elastic.co/guide/en/kibana/master/kibana-privileges.html](https://www.elastic.co/guide/en/kibana/master/kibana-privileges.html) If there are inconsistencies however, please file an issue at [https://github.com/elastic/kibana/issues/new?template=Bug\_report.md](https://github.com/elastic/kibana/issues/new?template=Bug_report.md)

Hope that helps.

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [September 19, 2019, 3:43pm UTC](https://discuss.elastic.co/t/monitoring-ml-not-available-you-should-also-assign-the-monitoring-user-role/196162/6 "2019-09-19T15:43:22Z")

</div>

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.