feat: [1122]-ldap and user extension + AD profile #1136

PavelJurka · 2024-07-02T08:38:30Z

Related Issue: .

#1122

Description of changes:

This issue is about adding a few useful fields to LDAP user, User object and adding a way how to map Azure ID to it.

dictionary.json

objects/user.json

dictionary.json

mikeradka · 2024-07-24T14:18:03Z

force_change_password_next_sign_in
force_change_password_next_sign_in_with_mfa
on_premises_distinguished_name
user_password_expiry_computed_time

These are a few that have pretty long names. With OCSF we try our best to keep attribute names as concise as possible. Can we look a bit deeper into ways to shorten these attribute names?

While I understand there is an intent to keep these consistent with AD, OCSF and AD still have separate conventions and I am hesitant to deviate from OCSF by introducing large attribute names unless absolutely needed.

force_change_password_next_sign_in and force_change_password_next_sign_in_with_mfa
- the common element with these two is a force_pw_change. Maybe there is a way to consolidate them.
on_premises_distinguished_name
- on_prem_dn? (note that the abbreviation dn is already used in the ldap_dn dictionary attribute)
user_password_expiry_computed_time
- looks like an expiry time. What about something along the lines of pw_expiry?

Expands the `user` object to add relevant data that comes from various Identity Providers or Directories while keep relevance with LDAP and MITRE D3FEND. - Add Observable `type_id` 31-35 for User UID, Group Name, Group UID, Account Name, Account UID - Add `phone_number` to `user` and to `ldap_person` - this attribute can be assigned to both or one or the other depending on the upstream system. For instance Entra ID or Okta - ~~Add `state_id` and `state` to `user` to represent the various states of a user record in a directory or IDP such as their provisioning status, (de)activation. This is 1:1 with Okta with an extra `Deleted` enum added for Google Workspace~~ Removed as #1136 already has a solution - Add `has_mfa` Boolean to Dictionary and `user` object as a quick way to tell if a `user` has MFA/2FA enabled/assigned to them --------- Signed-off-by: Jonathan Rau <139361268+jonrau-at-queryai@users.noreply.github.com> Co-authored-by: Rajas <89877409+floydtree@users.noreply.github.com>

objects/ldap_person.json

dictionary.json

pagbabian-splunk · 2024-08-14T16:16:20Z

dictionary.json

+      "description": "The number of times the user tried to log on to the account using an incorrect password."
+    },
+    "bad_password_time": {
+      "caption": "Bad Password Time",


Naming again. Not sure if these are native AD names. I would prefer 'failed_loginsornum_failed_logins. Also last_failed_loginorlast_failed_login_time`.

pagbabian-splunk · 2024-08-14T16:17:09Z

dictionary.json

+      "caption": "Consistency Guid",
+      "type": "string_t",
+      "description": "Is used to check consistency between the directory and another object, database, or application by comparing GUIDs."
+    },


This one seems very specific, maybe to AD only? Should be type uuid_t.

pagbabian-splunk · 2024-08-14T16:18:02Z

dictionary.json

+    "creator_sid": {
+      "caption": "Creator SID",
+      "type": "string_t",
+      "description": "The security ID of the creator of the object that contains this attribute."


Windows specific - sid. Do we use strings or uids for sids? Can we use creator.uid already in dictionary? We can use this Windows name in the desc.

pagbabian-splunk · 2024-08-14T16:57:31Z

dictionary.json

+      "description": "roxy address of a user. For example [SMTP: bob@contoso.com, smtp: bob@sales.contoso.com]",
+      "type": "string_t",
+      "is_array": true
+    },


Will this always be an email address? If so, we can use the email_t type. Also, a typo in the description of proxy.

pagbabian-splunk · 2024-08-14T16:58:03Z

dictionary.json

+      "caption": "Is Recycled",
+      "type": "boolean_t",
+      "description": "Identifies if the object has been added to the Recycle bin in Active Directory."
+    },


This is a generic name with a specific to AD description.

pagbabian-splunk · 2024-08-14T16:58:48Z

dictionary.json

+      "caption": "Resultant PSO",
+      "type": "string_t",
+      "description": "The effective password policy applied on this object."
+    },


Should this be a Policy data type? Is this specific to AD? What is a PSO?

pagbabian-splunk · 2024-08-14T16:59:54Z

dictionary.json

+      "caption": "SAM Account Type",
+      "type": "long_t",
+      "description": "This attribute contains information about every account type object."
+    },


Windows specific sam_ prefixes. (Just keeping notes of these).

pagbabian-splunk · 2024-08-14T17:01:34Z

dictionary.json

+      "type": "string_t",
+      "description": "The unique identifiers of a service instance in Active Directory.",
+      "is_array": true
+    },


We usually sort these attributes even if they are related (e.g. is_ stays together) but not absolute.

pagbabian-splunk · 2024-08-14T17:48:21Z

dictionary.json

+      "caption": "Last Known Parent",
+      "type": "string_t",
+      "description": "The Distinguished Name (DN) of the last known parent of an orphaned object."
+    },


May need ldap_ because it is a DN or an object. A convention around objects like AD could be retrofitted to LDAP too (we would need to deprecate).

pagbabian-splunk · 2024-08-14T18:04:03Z

dictionary.json

+      "caption": "On Premises Distinguished Name",
+      "description": "The distinguished name of the user in the on-premises Active Directory.",
+      "type": "string_t"
+    },


This is a difference between AD and Azure Entra ID?

pagbabian-splunk · 2024-08-14T18:15:55Z

We may need to break this PR down into a few smaller PRs - it is quite large with many new attributes, but is also very important to get right.

floydtree

I echo @pagbabian-splunk's comment, these additions are much needed for the framework, but we need to break the PR down in smaller chunks. Perhaps you can target additions/enhancements to just one object at a time in a single PR.

Other things to consider -

If you have sample events that you want to normalize, it will help us quite a bit to review.
Consider re-using existing attributes before adding new ones. (Refer to Paul's inline comments)
Consider all the specific data-types as you add new attributes, instead of defaulting to string_t
Consider object creation to avoid redundancy in naming and re-usability of attributes. (e.g on_premises_* vs on on_premises { * })
Consider if you can create an object to group AD specific attributes together (thinking about re-usability and portability across the framework)

@pagbabian-splunk @mikeradka @zschmerber Feel free to add, if I missed anything.

floydtree · 2024-08-14T18:33:37Z

dictionary.json

+      "type": "string_t",
+      "description": "Specifies all the groups in which the object is a member, directly or indirectly. See specific usage.",
+      "is_array": true
+    },


Also, can the caption be made clearer?

Expands the `user` object to add relevant data that comes from various Identity Providers or Directories while keep relevance with LDAP and MITRE D3FEND. - Add Observable `type_id` 31-35 for User UID, Group Name, Group UID, Account Name, Account UID - Add `phone_number` to `user` and to `ldap_person` - this attribute can be assigned to both or one or the other depending on the upstream system. For instance Entra ID or Okta - ~~Add `state_id` and `state` to `user` to represent the various states of a user record in a directory or IDP such as their provisioning status, (de)activation. This is 1:1 with Okta with an extra `Deleted` enum added for Google Workspace~~ Removed as ocsf#1136 already has a solution - Add `has_mfa` Boolean to Dictionary and `user` object as a quick way to tell if a `user` has MFA/2FA enabled/assigned to them --------- Signed-off-by: Jonathan Rau <139361268+jonrau-at-queryai@users.noreply.github.com> Co-authored-by: Rajas <89877409+floydtree@users.noreply.github.com>

…rofile

…h AD api

PavelJurka requested review from floydtree, pagbabian-splunk, Aniak5, mikeradka and zschmerber as code owners July 2, 2024 08:38

Aniak5 reviewed Jul 2, 2024

View reviewed changes

dictionary.json Outdated Show resolved Hide resolved

Aniak5 reviewed Jul 2, 2024

View reviewed changes

dictionary.json Show resolved Hide resolved

Aniak5 reviewed Jul 2, 2024

View reviewed changes

objects/user.json Show resolved Hide resolved

Aniak5 reviewed Jul 2, 2024

View reviewed changes

objects/user.json Show resolved Hide resolved

floydtree added the v1.3.0 Changes marked for v1.3.0 of OCSF label Jul 2, 2024

mikeradka added enhancement New feature or request non_breaking Non Breaking, backwards compatible changes labels Jul 2, 2024

PavelJurka requested a review from Aniak5 July 3, 2024 09:16

mikeradka requested changes Jul 23, 2024

View reviewed changes

dictionary.json Outdated Show resolved Hide resolved

PavelJurka requested a review from mikeradka July 24, 2024 13:25

PavelJurka force-pushed the 1122-User-LdapPerson-Asure-AD-support branch from bc354a3 to f0c170a Compare July 26, 2024 18:05

mikeradka added v1.4.0 or later Changes marked for versions beyond v1.3.0 of OCSF and removed v1.3.0 Changes marked for v1.3.0 of OCSF labels Jul 26, 2024

jonrau-at-queryai mentioned this pull request Aug 2, 2024

user Object expansion and related Observables creation #1155

Merged

pagbabian-splunk reviewed Aug 14, 2024

View reviewed changes

floydtree requested changes Aug 14, 2024

View reviewed changes

PavelJurka marked this pull request as draft September 3, 2024 12:36

PavelJurka force-pushed the 1122-User-LdapPerson-Asure-AD-support branch from 669339a to 3a9f241 Compare October 16, 2024 09:27

PavelJurka added 16 commits October 22, 2024 13:06

feat: [1122]-ldap and user extension + AD profile

4c5bbcd

feat: [ocsf#1122] - ldap - moved active directory sid objects to ad p…

930248a

…rofile

feat: [ocsf#1122] - ldap - moved active directory sid objects to ad p…

e9cc985

…rofile

feat: [ocsf#1122] - ldap - moved active directory sid objects to ad p…

2d89251

…rofile

feat: [ocsf#1122] - ldap - moved active directory sid objects to ad p…

6f5c27e

…rofile

feat: [ocsf#1122] - ldap - moved active directory sid objects to ad p…

1f3a99b

…rofile

feat: [ocsf#1122] - PR ready

bb6e83b

feat: [ocsf#1122] - added ldap group

6f3cfe4

feat: [ocsf#1122] - PR

c6344f6

feat: [ocsf#1122] - pushed back admin_count to be more consistent wit…

aa58992

…h AD api

feat: [ocsf#1122] - pushed back admin_count to be more consistent wit…

0f6f32c

…h AD api

feat: [ocsf#1122] - visibility enum update by the convention

e660baa

feat: [ocsf#1122] - visibility enum update by the convention

58ec283

feat: [ocsf#1122] - visibility enum update by the convention

cedd200

feat: [ocsf#1122] - code review - shortening fields name.

0527052

feat: [ocsf#1122] - pw_expiry_time to be consistent

3f131d4

PavelJurka force-pushed the 1122-User-LdapPerson-Asure-AD-support branch from 9b1b73c to 3f131d4 Compare October 22, 2024 11:08

PavelJurka added 2 commits October 22, 2024 13:20

WIP

a6a1636

WIP

57fab5c

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

feat: [1122]-ldap and user extension + AD profile #1136

feat: [1122]-ldap and user extension + AD profile #1136

PavelJurka commented Jul 2, 2024 •

edited

Loading

mikeradka commented Jul 24, 2024 •

edited

Loading

pagbabian-splunk Aug 14, 2024

pagbabian-splunk Aug 14, 2024 •

edited

Loading

pagbabian-splunk Aug 14, 2024 •

edited

Loading

pagbabian-splunk Aug 14, 2024

pagbabian-splunk Aug 14, 2024

pagbabian-splunk Aug 14, 2024

pagbabian-splunk Aug 14, 2024

pagbabian-splunk Aug 14, 2024

pagbabian-splunk Aug 14, 2024

pagbabian-splunk Aug 14, 2024

pagbabian-splunk commented Aug 14, 2024

floydtree left a comment

floydtree Aug 14, 2024

feat: [1122]-ldap and user extension + AD profile #1136

Are you sure you want to change the base?

feat: [1122]-ldap and user extension + AD profile #1136

Conversation

PavelJurka commented Jul 2, 2024 • edited Loading

Related Issue: .

Description of changes:

mikeradka commented Jul 24, 2024 • edited Loading

Choose a reason for hiding this comment

pagbabian-splunk Aug 14, 2024 • edited Loading

Choose a reason for hiding this comment

pagbabian-splunk Aug 14, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pagbabian-splunk commented Aug 14, 2024

floydtree left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

PavelJurka commented Jul 2, 2024 •

edited

Loading

mikeradka commented Jul 24, 2024 •

edited

Loading

pagbabian-splunk Aug 14, 2024 •

edited

Loading

pagbabian-splunk Aug 14, 2024 •

edited

Loading