# Winlogbeat does not resolve SIDs of forwarded Event-Logs

**URL:** https://discuss.elastic.co/t/winlogbeat-does-not-resolve-sids-of-forwarded-event-logs/83752
**Category:** Beats
**Tags:** winlogbeat
**Created:** [April 26, 2017, 7:01pm UTC](https://discuss.elastic.co/t/winlogbeat-does-not-resolve-sids-of-forwarded-event-logs/83752 "2017-04-26T19:01:38Z")
**Posts on this page:** 8
**Page:** 1

<div class="post-metadata">

### Author: ![wuppi](https://avatars.discourse-cdn.com/v4/letter/w/3da27b/32.png) [@wuppi](https://discuss.elastic.co/u/wuppi)
#### Post date: [April 26, 2017, 7:01pm UTC](https://discuss.elastic.co/t/winlogbeat-does-not-resolve-sids-of-forwarded-event-logs/83752/1 "2017-04-26T19:01:38Z")

</div>

We use winlogbeat on one Windows-Host which collects evet-logs from several Domain-Controllers and several domains. Winlogbeat only resolves the common SIDs and the SIDs of local users of the collector-system. The log only told me, that some SIDs couldn't be resolved, no reason why. Googeling around I could not find any hint about the capability of winlogbeat to resolve SIDs on remote machines.... I'm stuck. Does anybody know more about this?

---

<div class="post-metadata">

### Author: ![andrewkroh](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/andrewkroh/32/3784_2.png) [@andrewkroh](https://discuss.elastic.co/u/andrewkroh)
#### Post date: [April 26, 2017, 7:15pm UTC](https://discuss.elastic.co/t/winlogbeat-does-not-resolve-sids-of-forwarded-event-logs/83752/2 "2017-04-26T19:15:11Z")

</div>

This came up once in the past and we discussed adding a processor to lookup the SIDs in the event with the AD. The first step would be figure what features are needed in the processor and open an enhancement ticket.

See the topic at [Winlogbeat displaying GUID in Windows events instead of object name](https://discuss.elastic.co/t/winlogbeat-displaying-guid-in-windows-events-instead-of-object-name/71442/5?u=andrewkroh)

---

<div class="post-metadata">

### Author: ![wuppi](https://avatars.discourse-cdn.com/v4/letter/w/3da27b/32.png) [@wuppi](https://discuss.elastic.co/u/wuppi)
#### Post date: [April 27, 2017, 8:37pm UTC](https://discuss.elastic.co/t/winlogbeat-does-not-resolve-sids-of-forwarded-event-logs/83752/3 "2017-04-27T20:37:12Z")

</div>

Hmm, I can see usernames in "winlogbeat\_user\_name" and according to the documentation in [https://www.elastic.co/guide/en/beats/winlogbeat/current/exported-fields-eventlog.html](https://www.elastic.co/guide/en/beats/winlogbeat/current/exported-fields-eventlog.html) The user.identifier already can be resolved. Cite: "If Winlogbeat cannot resolve the SID to a name, then the [user.name](http://user.name), user.domain, and user.type fields will be omitted from the event. If you discover Winlogbeat not resolving SIDs, review the log for clues as to what the problem may be."  
But the log does not contain any clues on the problem, only stating there is a problem with resolving some SIDs.  
That is why I thought and still think that winlogbeat has the ability to resolve SIDs unter certain circumstances, but debugging is painful....

Thank you for your answer!

---

<div class="post-metadata">

### Author: ![andrewkroh](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/andrewkroh/32/3784_2.png) [@andrewkroh](https://discuss.elastic.co/u/andrewkroh)
#### Post date: [May 3, 2017, 4:00am UTC](https://discuss.elastic.co/t/winlogbeat-does-not-resolve-sids-of-forwarded-event-logs/83752/4 "2017-05-03T04:00:55Z")

</div>

Did you enable debug? The log message requires debug logging to be enabled.

```auto
logging.level: debug
logging.selectors: [eventlog]

```

Here's a link to the log message and the function that does the lookup.

[Log Message for errors](https://github.com/elastic/beats/blob/v5.3.2/winlogbeat/eventlog/wineventlog.go#L205-L209)  
[sys.PopulateAccount()](https://github.com/elastic/beats/blob/v5.3.2/winlogbeat/sys/sid_windows.go) uses `LookupAccountSid` to do the actual lookup with Windows.

From [LookupAccountSid](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379166(v=vs.85).aspx):

> A pointer to a null-terminated character string that specifies the target computer. This string can be the name of a remote computer. If this parameter is NULL, the account name translation begins on the local system. If the name cannot be resolved on the local system, this function will try to resolve the name using domain controllers trusted by the local system. Generally, specify a value for lpSystemName only when the account is in an untrusted domain and the name of a computer in that domain is known.

Winlogbeat does this lookup with a NULL system name. So is this machine that Winlogbeat is running on a member of the same domain that the SID is from?

---

<div class="post-metadata">

### Author: ![wuppi](https://avatars.discourse-cdn.com/v4/letter/w/3da27b/32.png) [@wuppi](https://discuss.elastic.co/u/wuppi)
#### Post date: [May 3, 2017, 6:53pm UTC](https://discuss.elastic.co/t/winlogbeat-does-not-resolve-sids-of-forwarded-event-logs/83752/5 "2017-05-03T18:53:27Z")

</div>

Wow, thank you very much. This matches to what I've seen: resolution of SIDs of local users and of well-known SIDs is functional, only users from remote machines cannot be resolved.  
I already had debugging enabled and the logmessage you pointed me to is the only one I see. It says "account lookup failed" but that is clear to me 😉

Yes, your assumption is right, the winlogbeat runs on a machine not belonging to any domain but gathering logs from domain controllers of three different domains.

I understood, that winlogbeat might be able to resolve SIDs from different servers and domains if the target computer is specified. Not being so good in analyzing code I do not understand wher and how to specify the corresponding target system (btw. the corresponding servername is the value of "winlogbeat\_computer\_name").

I will try to find out or ask someone else, but if somebody here could give me another hint. theat would be great!.  
TIA

---

<div class="post-metadata">

### Author: ![andrewkroh](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/andrewkroh/32/3784_2.png) [@andrewkroh](https://discuss.elastic.co/u/andrewkroh)
#### Post date: [May 3, 2017, 7:15pm UTC](https://discuss.elastic.co/t/winlogbeat-does-not-resolve-sids-of-forwarded-event-logs/83752/6 "2017-05-03T19:15:13Z")

</div>

Winlogbeat does not provide a way to configure the remote host that is used to do the SID lookup.

It could be enhanced to make this configurable. But I don't know the security requirements of the RPC session to the remote host. So this would be something to figure out. Also would need to figure out if windows does any caching or if Winlogbeat needs to do its own caching.

---

<div class="post-metadata">

### Author: ![wuppi](https://avatars.discourse-cdn.com/v4/letter/w/3da27b/32.png) [@wuppi](https://discuss.elastic.co/u/wuppi)
#### Post date: [May 3, 2017, 7:37pm UTC](https://discuss.elastic.co/t/winlogbeat-does-not-resolve-sids-of-forwarded-event-logs/83752/7 "2017-05-03T19:37:18Z")

</div>

The remote host for SID-lookup could be retreived from the log-message. In case of forwarded events winlogbeat stores the name of the computer which is the origin of the message in winlogbeat\_computer\_name. This computer should be able to resolve the SID I think....  
For now I think, we have to change our configuration if we want the SIDs to be resolved and collect eventlogs only from trusted domains or to ommit eventlog-forwarding and install winlogbeat on each server.

Thank you very much for helping me to understand!

---

<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 31, 2017, 7:46pm UTC](https://discuss.elastic.co/t/winlogbeat-does-not-resolve-sids-of-forwarded-event-logs/83752/8 "2017-05-31T19:46:03Z")

</div>

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