Authentications tab shows "All values returned zero"

Hi, I'm using Elastic Cloud, I have two different deployments.
One in version 7.6.2 and Elastic SIEM it's working properly and one in 7.8.0
In this last version 7.8.0

, SIEM Module don't show authentications even when it's receiving security logs with winlogbeat from Windows Server 2008 R2.
Authentications tab shows "All values returned zero". It shows 293 users but Successes and Failures has also zero on all the columns.
Any idea ?? Perhaps I have to downgrade previously version ?

This is the request

  "aggregations": {
    "eventActionGroup": {
      "terms": {
        "field": "event.outcome",
        "include": [
        "order": {
          "_count": "desc"
        "size": 2
      "aggs": {
        "events": {
          "date_histogram": {
            "field": "@timestamp",
            "fixed_interval": "2700000ms",
            "min_doc_count": 0,
            "extended_bounds": {
              "min": 1594361664971,
              "max": 1594448064971
  "query": {
    "bool": {
      "filter": [
          "bool": {
            "must": [],
            "filter": [
                "match_all": {}
            "should": [],
            "must_not": []
          "bool": {
            "must": [
                "term": {
                  "event.category": "authentication"
          "range": {
            "@timestamp": {
              "gte": 1594361664971,
              "lte": 1594448064971
  "size": 0,
  "track_total_hits": true

and here the response

  "took": 7,
  "timed_out": false,
  "_shards": {
    "total": 2,
    "successful": 2,
    "skipped": 0,
    "failed": 0
  "hits": {
    "total": {
      "value": 60273,
      "relation": "eq"
    "max_score": null,
    "hits": []
  "aggregations": {
    "eventActionGroup": {
      "doc_count_error_upper_bound": 0,
      "sum_other_doc_count": 0,
      "buckets": []

Thank you .... and sorry for my English.

Welcome to the community @xhidalgo!

Would you be willing to post a few sample events (scrubbed of any sensitive details) that were counted in 7.6.2, but not 7.8.0?

This would help us better understand what event IDs you're looking at, and also whether or not Windows Server 2008 R2 is providing the expected data. Thanks!

Hi Andrew. Thank you.

Really I'm sure right now that the problem is not version related ... I'm just trying same version 7.8.0 in new deployment for another client and authentications shows correctly with his Windows Server 2008 R2 Standard.
This one works properly.

This one don't work

The difference is ... the one it's not working it's Windows 2008 R2 Datacenter Edition. Could be the problem ??
The deployment not working is receiving the events with winlogbeat

Thank you...

Thanks for providing those screenshots and the details above @xhidalgo!

The deployment not working is receiving the events with winlogbeat

Would you be willing to answer the following questions to help determine the next troubleshooting steps?

  • For the deployment that's not working, are you collecting data from both the host that's working correctly, and the host that's working incorrectly? (If yes, great. If not, it would be helpful to have data from both hosts in the same deployment.)

  • Are both the working and non-working hosts collecting data via the same agent.type, e.g. winlogbeat?

  • Are both the working and non-working hosts collecting data with the same version of winlogbeat, e.g. 7.8.0?

  • Does the working host have any additional beats, e.g. filebeat, that perhaps the non-working host doesn't have?

Hi Andrew.

The deployment that is working has versión winlogbeat 7.6.2 (we installed previously) against 7.8.0 kibana deployment.

The deployment not working had both versions 7.8. Uninstalling winlogbeat version 7.8 and installing 7.6 works !!!

There are some differences in winlogbeat.yml

Host does not have any additional beats... only winlogbeat...

By now it's working with winlogbeat version 7.6.2.

Thank you

Hi, the same problem appears with domain controllers Windows 2019 (also datacenter edition). . Not working with winlogbeat 7.8 but working good with 7.6.

I can confirm that this issue exists between winlogbeat 7.8 on domain controllers of both 2012 R2 and 2019 version sending logs to elk stack 7.8. Haven't tried winlogbeat 7.6.

Can you please share a copy of the authentication event's raw JSON. You can copy it from the JSON View.

Screen Shot 2020-07-16 at 11.27.56 AM

I suspect the issue is that winlog.keywords are missing from the event or are non-English. There was a change to use a more generic way of adding event.output = success/failure that was based on looking for "Audit Success" or "Audit Failure". It used to be based on the event ID (e.g. event id 4624 -> success).

Below is a raw json object, but i have removed some privacy related stuff. Please let me know if you need some more information

  "_index": "winlogbeat-7.8.0-2020.07.20",
  "_type": "_doc",
  "_id": "HO38anMBFI_Rqs2_n6pw",
  "_version": 1,
  "_score": null,
  "_source": {
    "log": {
      "level": "information"
    "winlog": {
      "version": 2,
      "provider_name": "Microsoft-Windows-Security-Auditing",
      "logon": {
        "id": "0x38e2849c",
        "type": "Network"
      "provider_guid": "{54849625-5478-4994-a5ba-3e3b0328c30d}",
      "record_id": 134091856,
      "process": {
        "thread": {
          "id": 4200
        "pid": 672
      "event_id": 4624,
      "opcode": "Info",
      "api": "wineventlog",
      "event_data": {
        "TargetUserSid": "SID",
        "ElevatedToken": "%%1842",
        "TransmittedServices": "-",
        "KeyLength": "128",
        "SubjectLogonId": "0x0",
        "SubjectUserName": "-",
        "RestrictedAdminMode": "-",
        "TargetLinkedLogonId": "-",
        "TargetDomainName": "-",
        "LogonProcessName": "NtLmSsp ",
        "LmPackageName": "NTLM V2",
        "TargetLogonId": "0x38e2849c",
        "ImpersonationLevel": "%%1833",
        "TargetUserName": "-",
        "SubjectDomainName": "-",
        "AuthenticationPackageName": "NTLM",
        "LogonType": "3",
        "SubjectUserSid": "-",
        "TargetOutboundDomainName": "-",
        "VirtualAccount": "%%1843",
        "LogonGuid": "{00000000-0000-0000-0000-000000000000}",
        "TargetOutboundUserName": "-"
      "computer_name": "COMPUTERNAME",
      "task": "Logon",
      "keywords": [
        "Audit Success"
      "channel": "Security"
    "ecs": {
      "version": "1.5.0"
    "source": {
      "ip": "IP",
      "domain": "HOSTNAME",
      "port": 8227
    "host": {
      "ip": [
      "os": {
        "version": "10.0",
        "family": "windows",
        "name": "Windows Server 2019 Standard",
        "build": "17763.1339",
        "platform": "windows",
        "kernel": "10.0.17763.1339 (WinBuild.160101.0800)"
      "mac": [
      "name": "HOSTNAME",
      "architecture": "x86_64",
      "id": "ID",
      "hostname": "HOSTNAME"
    "user": {
      "name": "USERNAME",
      "domain": "DOMAIN",
      "id": "SID"
    "message": "An account was successfully logged on.\n\nSubject:\n\tSecurity ID:\t\tS-1-0-0\n\tAccount Name:\t\t-\n\tAccount Domain:\t\t-\n\tLogon ID:\t\t0x0\n\nLogon Information:\n\tLogon Type:\t\t3\n\tRestricted Admin Mode:\t-\n\tVirtual Account:\t\tNo\n\tElevated Token:\t\tYes\n\nImpersonation Level:\t\tImpersonation\n\nNew Logon:\n\tSecurity ID:\t\tSID\n\tAccount Name:\t\tUSERNAME\n\tAccount Domain:\t\tDOMAIN\n\tLogon ID:\t\t0x00000000\n\tLinked Logon ID:\t\t0x0\n\tNetwork Account Name:\t-\n\tNetwork Account Domain:\t-\n\tLogon GUID:\t\t{00000000-0000-0000-0000-000000000000}\n\nProcess Information:\n\tProcess ID:\t\t0x0\n\tProcess Name:\t\t-\n\nNetwork Information:\n\tWorkstation Name:\tHOSTNAME\n\tSource Network Address:\tIPV4\n\tSource Port:\t\t8227\n\nDetailed Authentication Information:\n\tLogon Process:\t\tNtLmSsp \n\tAuthentication Package:\tNTLM\n\tTransited Services:\t-\n\tPackage Name (NTLM only):\tNTLM V2\n\tKey Length:\t\t128\n\nThis event is generated when a logon session is created. It is generated on the computer that was accessed.\n\nThe subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.\n\nThe logon type field indicates the kind of logon that occurred. The most common types are 2 (interactive) and 3 (network).\n\nThe New Logon fields indicate the account for whom the new logon was created, i.e. the account that was logged on.\n\nThe network fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.\n\nThe impersonation level field indicates the extent to which a process in the logon session can impersonate.\n\nThe authentication information fields provide detailed information about this specific logon request.\n\t- Logon GUID is a unique identifier that can be used to correlate this event with a KDC event.\n\t- Transited services indicate which intermediate services have participated in this logon request.\n\t- Package name indicates which sub-protocol was used among the NTLM protocols.\n\t- Key length indicates the length of the generated session key. This will be 0 if no session key was requested.",
    "process": {
      "executable": "-",
      "pid": 0,
      "name": "-"
    "agent": {
      "version": "7.8.0",
      "id": "4ffb909b-3a14-406f-a265-2b9e433848d4",
      "name": "HOSTNAME",
      "hostname": "HOSTNAME",
      "ephemeral_id": "bde3d3a1-c561-45af-904f-6e5d654ff7f9",
      "type": "winlogbeat"
    "related": {
      "user": "USERNAME"
    "@version": "1",
    "@timestamp": "2020-07-20T06:50:05.953Z",
    "type": "wineventlog",
    "event": {
      "outcome": "success",
      "module": "security",
      "provider": "Microsoft-Windows-Security-Auditing",
      "created": "2020-07-20T06:50:06.387Z",
      "category": "authentication",
      "kind": "event",
      "code": 4624,
      "type": "start",
      "action": "logged-in"
    "tags": [
  "fields": {
    "@timestamp": [
    "event.created": [
    "winlog.event_data.ProcessCreationTime": []
  "sort": [

Hi there,

I can confirm the same behaviour here with the following config :

  • ELK 7.8.0
  • Winlogbeat 7.8
  • DC in W2019 Datacenter in French

So, the winlog.event is not "Audit Success" or "Audit failure" but "Succès de l’audit" or "Echec de l’audit"

Is there any way to fix it without downgrading to winlogbeat 7.6 ?

Thanks in advance,


Hi there,

I just checked my SIEM and I can report the very same issue.
This is my environment:

  • Elasticstack 7.8.0
  • Windows 2012R2 (German)
  • Winlogbeat 7.8
    I have not tried if downgrading to 7.6 fixes this issue.

Your assumption is correct, the only keyword in my log is in german.

"winlog": {
  "keywords": [
    "Überwachung erfolgreich"

Oddly enough in the tab "Events" login events are properly tagged with "event.action" resolving to "logged-in" or "logged-in-special" so maybe the UIs are checking different fields/have different approaches?

I'm also not entirely sure how checking for keywords is needed here. Some event IDs, like 4624 (successful authentication), are information enough by itself. The simple existence of that event ID means that a logon happened successfully, in every other case the system would throw a 4625 event.

1 Like

I've opened a pull request to fix this at

Hi, i did the upgrade to ELK 7.9 and Winlogbeat 7.9, still the same issue...

If this was a PR fix from:

Looks like the soonest will be 7.9.1 which hasn't been released yet but should be very soon.


I can confirm that the 7.9.1 version fix the issue.

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