Report FQDN on Windows hosts

[ycombinator]

Describe the enhancement:

In #34456, we enhanced Beats to accept configuration for feature flags via the top-level features configuration key.

The first feature we added a flag for was FQDN reporting (also implemented in the same PR). To enable FQDN reporting, users must set features.fqdn.enabled: true in their Beat's configuration.

FQDN reporting has not yet been implemented for Beats running on Windows hosts, however. This issue is to track the necessary implementation. See background and suggestions in #34456 (comment).

Describe a specific use case for the enhancement or feature:

See #1070.

[elasticmachine]

Pinging @elastic/elastic-agent (Team:Elastic-Agent)

[cmacknz]

I think this only applies to events read using the winlog input, if I am interpreting #34456 (comment) correctly.

[amitkanfer]

Marking this as P0, like all the other FQDN issues.
Would be great to get an effort estimation for this task ASAP.

[cmacknz]

We investigated the behaviour of add_host_metadata and the winlog input and concluded:

• When the event is forwarded from a separate host, we want to leave the host.name as is. This is accomplished by the forwarded tag on the add_host_metadata process condition.
  • Under agent, this is configured in

    beats/x-pack/filebeat/cmd/agent.go

    Lines 49 to 53 in e7e6dac

    	{
    	"add_host_metadata": mapstr.M{
    	"when.not.contains.tags": "forwarded",
    	},
    	},

  • For standalone Beats, this is in the default configuration file:

    beats/filebeat/filebeat.yml

    Lines 167 to 169 in e7e6dac

    	processors:
    	- add_host_metadata:
    	when.not.contains.tags: forwarded

• When the event is not forwarded from a separate host, we want to overwrite the host.name received from winlog to match the one determined by the add_host_metadata processor. This appears to work today with no changes.
  • winlog sets the host.name attribute here:

    beats/winlogbeat/eventlog/eventlog.go

    Line 101 in 34a87e5

    winevent.AddOptional(m, "host.name", e.Computer)

  • add_host_metadata has logic to skip adding host.metadata if it already exists, but will ovewrite host.name if it is the only host field that is set:

    beats/libbeat/processors/add_host_metadata/add_host_metadata.go

    Lines 156 to 170 in e7e6dac

    	func skipAddingHostMetadata(event *beat.Event) bool {
    	// If host fields exist(besides host.name added by libbeat) in event, skip add_host_metadata.
    	hostFields, err := event.Fields.GetValue("host")
    	// Don't skip if there are no fields
    	if err != nil || hostFields == nil {
    	return false
    	}
    	switch m := hostFields.(type) {
    	case mapstr.M:
    	// if "name" is the only field, don't skip
    	hasName, _ := m.HasKey("name")
    	if hasName && len(m) == 1 {
    	return false

The conclusion is that the only action we have is to test winlogbeat (which is the winlog Filebeat input under agent) with the fqdn feature enabled and ensure it has the behaviour we want for both of these cases. We should be able to do this by configuring a the winlog integration for agent to read from an evtx file with the appropriate preconditions. There are some sample evtx files in https://github.com/elastic/beats/tree/9b4bd2d32a6cf6f179c2e3cf32848ca7ac3c8e95/x-pack/winlogbeat/module/security/test/testdata/collection for reference.

We want to test that:

1. A winlog event that sets host.name to a value that is different than what add_host_metadata would set has the host.name corrected to match.
2. A winlog event that sets host.name to a value that is different from what add_host_metadata would set but is forwarded from another machine is unchanged.

Since the only work here is testing the estimate is set to Small (<2 days).

[jlind23]

Thank you @cmacknz for the update!

[ycombinator]

The conclusion is that the only action we have is to test winlogbeat (which is the winlog Filebeat input under agent) with the fqdn feature enabled and ensure it has the behaviour we want for both of these cases.

Chatted with @jlind23 about this in a 1-1 today. We decided that since the only work expected for this issue is testing, we will close this issue for now. Things are expected to work as-is; if testing reveals that they don't, we will reopen this issue. This gives more accurate visibility into the state of this issue.