[integration][windows] - Fixed parsing of winlog.event_data.MemberName in forwarded data stream when extra commas are present

[ShourieG]

Type of change

Please label this PR with one of the following labels, depending on the scope of your change:

• Bug

Proposed commit message

ISSUE: The Windows integration did not parse winlog.event_data.MemberName properly and map it to user.target.name when user CN contained extra "," characters. For example CN=Reyes\, Elena (FFF),OU=Basic,OU=Domain Users,DC=ddd,DC=ccc,DC=fff will be parsed to user.target.name Reyes\, which is wrong.

FIX: Fixed parsing of winlog.event_data.MemberName in forwarded data stream by removing the old splitToken method and replaced it with a custom split processor logic that splits on the basis of commas but ignores escaped commas.

Checklist

• I have reviewed tips for building integrations and this pull request is aligned with them.
• I have verified that all data streams collect metrics or logs.
• I have added an entry to my package's changelog.yml file.
• I have verified that Kibana version constraints are current according to guidelines.

Author's Checklist

• [ ]

How to test this PR locally

Related issues

Screenshots

[elasticmachine]

💚 Build Succeeded

the below badges are clickable and redirect to their specific view in the CI or DOCS

Expand to view the summary

Build stats

• Start Time: 2023-11-09T06:37:07.754+0000

• Duration: 20 min 28 sec

Test stats 🧪

Test	Results
Failed	0
Passed	148
Skipped	0
Total	148

🤖 GitHub comments

Expand to view the GitHub comments

To re-run your PR in the CI, just comment with:

• /test : Re-trigger the build.

[elasticmachine]

🌐 Coverage report

Name	Metrics % (covered/total)	Diff
Packages	100.0% (8/8)	💚
Files	91.667% (11/12)	👎 -8.333
Classes	91.667% (11/12)	👎 -8.333
Methods	85.156% (109/128)	👍 20.871
Lines	91.587% (5868/6407)	👎 -8.413
Conditionals	100.0% (0/0)	💚

[efd6]

Since the original issue shows that the comma is preceded by a backslash, it seems to me that this could be done with a split processor; something like {"split": {"if": "ctx.winlog?.event_data?.MemberName != null", "field": "winlog.event_data.MemberName", "target_field": "_temp.MemberNameParts", "separator":"(?<!\\\\),"} with _temp.MemberNameParts being used as the direct source of the script's memberNameParts var.

[ShourieG]

Since the original issue shows that the comma is preceded by a backslash, it seems to me that this could be done with a split processor; something like {"split": {"if": "ctx.winlog?.event_data?.MemberName != null", "field": "winlog.event_data.MemberName", "target_field": "_temp.MemberNameParts", "separator":"(?<!\\\\),"} with _temp.MemberNameParts being used as the direct source of the script's memberNameParts var.

@efd6 true, but we don't know if that's always the case or not, hence more of a generic approach was taken.

[efd6]

@efd6 true, but we don't know if that's always the case or not, hence more of a generic approach was taken.

I have asked at the original issue. If it is guaranteed, the simpler approach would be preferable. Note that you can use the key part of the list in a zw-look ahead. It's more costly than the lookbehind since that is only a single code point behind, but I still think preferable in terms of maintenance.

[andrewkroh]

Reference info for the distinguished name format:

• https://learn.microsoft.com/en-us/previous-versions/windows/desktop/ldap/distinguished-names
• https://www.ietf.org/rfc/rfc2253.html

Event IDs containing MemberName - https://windows-event-explorer.app.elstc.co/search?q=EventData.Name%3A%22MemberName%22

[efd6]

The key is in the table here. , is reserved, and so MUST be escaped. This means the split processor approach is valid.

[ShourieG]

@efd6, @leehinman I've updated the PR with the split processor logic as suggested.

[ycombinator]

LGTM.

[leehinman]

LGTM

[kcreddy]

LGTM 👍🏼

[elasticmachine]

Package windows - 1.42.1 containing this change is available at https://epr.elastic.co/search?package=windows