I have just installed Winlogbeat on one of my Windows 2019 terminal servers.
After configurion the .yml file I have entered setup commands:
winlogbeat.exe setup --index-management
winlogbeat.exe setup --dahsboards
The template was created and dashboards were added.
After inspecting the dashboards I noticed the following thing.
I have checked the index template mapping and I do not have any mappings for this field.
I have met with this error a lot of times during the last few months.
I did not change the configuration regarding the index template, index pattern in beats .yml
I have not idea what I am doing wrong so my mapping set up from beasts have missing fields.
I have a similar issue with 7.7 filebeat cisco module, 7.8 metricbeat system module, as well as I, have with filebeat 7.9.2 netflow module
Do you already have data in the winlogbeat index?
If so, if you update the Index Pattern does it solve the error?
I do have now.
But the fields did not dynamically add. I just want to understand If the error in dashboards results from fields that are no longer used or it's something else?
This is even weirder. It's like It's present but it's not?
I don't get It.
Did you refresh your Kibana index patterns?
I do not know the powershell dashboard but I do know the other one (User Management Events) because i was the one I did it.
Regarding to winlog.logon.id is a very useful field because it allows you to correlate different events performed by the same user, if it is not in the index pattern is dynamically generated (when you receive an event with that field) . From winlogbeat's Index Template:
In summary, if you have an index with winlog.logon.id field present and then you refresh your index pattern in kibana, the error in the user managment event dashboard should disappear
Please let me know if that helps you
Thanks for your input.
I did refresh the indices and I saw some change in field numbers. But still, see the same error. Does this just must mean that kibana has never seen a document with that field?
What do you see in the discovery tab when wyou search for the winlog.logon.id?
What do you see if you go to Index Patterns -> winlogbeat and search for this field?
I see this. My agent version is 7.9.2
And still appears this error?
It looks better but still not perfect.
Can and should I set up auto index refresh?
Hi Adriann, It is not related to index refresh, but index pattern.
How does the User Management Event dashboard looks like?
I'll try to reproduce your scenario
I started with a clean space. No index pattern, no dashboards and it works OK for me
I refreshed the index once again and now its better.
Now I only miss this field. In this dashboard.
Can you explain why It works like this?
I did some extra test with a clean environment and here the explanation: when you first execute
winlogbeat setup --index-management a winlogbeat index is created based on winlogbeat's index template. In that index pattern there is no definition for
winlog.event_data.OldTargetUserName. That's why when you enter the first time to the dashboards the error appears.
Once you have real data containing values for
winlog.event_data.OldTargetUserName and you refresh the Kibana's index pattern the error will disappear.
Just to check, just rename a user in windows, so event 4781 is generated, refresh your index pattern and
PS1: I've also realize that the newer version of the dashboards are not in this version. I do not why (https://github.com/elastic/beats/pull/18775)
PS2: When new users (modeling multiple users in an event) fields will be incorporated to ECS (https://github.com/elastic/ecs/pull/914#issuecomment-671584201) I'll use those fields for dashboards
I asked my friend to add a local user and change his name. The output shows some field but even after refreshing the index pattern this is the dashboard look.
Please close the browser and open the dashboard again.
Yes, now I can see everything. Thank you very much for your help in resolving this as well as helping me understanding how It works <3
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.