# "Azure Excessive Signin Logs by Azure Identity" unusable azure.signinlogs.identity

**URL:** <https://discuss.elastic.co/t/azure-excessive-signin-logs-by-azure-identity-unusable-azure-signinlogs-identity/269708>\
**Category:** SIEM\
**Created:** [April 9, 2021, 1:03pm UTC](https://discuss.elastic.co/t/azure-excessive-signin-logs-by-azure-identity-unusable-azure-signinlogs-identity/269708 "2021-04-09T13:03:19Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![willemdh](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/willemdh/32/16922_2.png) [@willemdh](https://discuss.elastic.co/u/willemdh)\
**Post date:** [April 9, 2021, 1:03pm UTC](https://discuss.elastic.co/t/azure-excessive-signin-logs-by-azure-identity-unusable-azure-signinlogs-identity/269708/1 "2021-04-09T13:03:19Z")

</div>

Hello,

Just noticed that in the rule `"Azure Excessive Signin Logs by Azure Identity"` it seems impossible to display the field `azure.signinlogs.identity`, which is not very user friendly and a waste of time to lookup afterwards..

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

So 2 questions?

- Why can't we display `azure.signinlogs.identity` in the signal overview?
- Why is `azure.signinlogs.identity` not copied to `user.name` in the azure.signin pipeline?

Best regards,

Willem

---

<div class="post-metadata">

**Author:** ![Andrew\_G](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/andrew_g/32/49178_2.png) [@Andrew\_G](https://discuss.elastic.co/u/Andrew_G)\
**Post date:** [April 12, 2021, 9:55pm UTC](https://discuss.elastic.co/t/azure-excessive-signin-logs-by-azure-identity-unusable-azure-signinlogs-identity/269708/2 "2021-04-12T21:55:03Z")

</div>

Hi @willemdh,

Unmapped fields in an alerts index, (e.g. `.siem-signals-default`) are not displayed in the `Detection alerts` table, as shown in the screenshot above, until one of the following actions is taken:

- manually add a [runtime field](https://www.elastic.co/guide/en/elasticsearch/reference/current/runtime.html) to the alerts index (for the unmapped field), as illustrated by the [runtime fields documentation](https://www.elastic.co/guide/en/elasticsearch/reference/current/runtime-mapping-fields.html)

- manually add a [mapping](https://www.elastic.co/guide/en/elasticsearch/reference/current/mapping.html) to the alerts index (for the unmapped field) as illustrated by the [mapping documentation](https://www.elastic.co/guide/en/elasticsearch/reference/current/explicit-mapping.html#add-field-mapping), and re-index the alert data

Of the two options above, adding a runtime field is preferable, because it doesn't require re-indexing.

To that end, we opened:

- An enhancement request to [Provide a workflow for adding runtime fields to an alerts index for unmapped fields](https://github.com/elastic/kibana/issues/96894)

- An issue to [Prevent unmapped fields from being added to the Detection alerts table](https://github.com/elastic/kibana/issues/96898)

---

<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:** [May 10, 2021, 9:55pm UTC](https://discuss.elastic.co/t/azure-excessive-signin-logs-by-azure-identity-unusable-azure-signinlogs-identity/269708/3 "2021-05-10T21:55:21Z")

</div>

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