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

mikeradka · 2024-07-23T16:21:47Z

dictionary.json

@@ -154,6 +167,17 @@
        }
      }
    },
+    "allowed_to_act_on_behalf_of_other_identity": {


This is a very long name. Could this be made more concise? Also should this be a boolean?

It's long but name and type is consistent with AD. Can we keep it? thank you!

Do you have some examples of how this looks in AD?

We may still want to consider looking how to make this more concise, if it is possible to do so. Why not something along the lines of act_on_behalf, acts_on_behalf, or on_behalf_of with the details about the indication that the account is allowed to act on behalf of another identity within the attribute's description?

It is the native AD name. There is an LDAP display name, and a CN name. adminCount (which doesn't have an internal separator) is a LDAP display name. Admin-Count is the CN name.

msDS-Allowed-To-Act-On-Behalf-Of-Other-Identity is the CN name and msDSAllowedToActOnBehalfOfOtherIdentity is the LDAP display name.

Another common name for this is 'impersonation.' e.g. can_impersonate. If it is a boolean, then we would have is_* has_* and can_* conventions. However this proposed attribute seems to be a string_t - not sure why.

Similarly, allowed_to_delegate_to could be can_delegate. Again as boolean but this is also an array.

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?

…rofile

…h AD api

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 <[email protected]> Co-authored-by: Rajas <[email protected]>

pagbabian-splunk · 2024-07-25T21:28:50Z

objects/ldap_person.json

+    },
+    "allowed_to_delegate_to": {
+      "requirement": "optional"
+    },


Why are these AD specific attributes included directly in the ldap_person object rather than included via the AD profile which is also applied? That is, these two will always be in the object even if the profile is not applied.

pagbabian-splunk · 2024-08-14T16:08:45Z

dictionary.json

@@ -154,6 +167,17 @@
        }
      }
    },
+    "allowed_to_act_on_behalf_of_other_identity": {


Another common name for this is 'impersonation.' e.g. can_impersonate. If it is a boolean, then we would have is_* has_* and can_* conventions. However this proposed attribute seems to be a string_t - not sure why.

Similarly, allowed_to_delegate_to could be can_delegate. Again as boolean but this is also an array.

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: [email protected], smtp: [email protected]]",
+      "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 <[email protected]> Co-authored-by: Rajas <[email protected]>

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 Outdated 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

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

PavelJurka added 14 commits July 26, 2024 20:04

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

df96b4f

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

e2b07c6

…rofile

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

b501629

…rofile

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

b82c00c

…rofile

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

1295dac

…rofile

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

058ec74

…rofile

feat: [ocsf#1122] - PR ready

20478f1

feat: [ocsf#1122] - added ldap group

b5df645

feat: [ocsf#1122] - PR

c4b014d

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

c2f3b5b

…h AD api

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

85669ae

…h AD api

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

4de9ef3

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

a204ba3

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

03ad367

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

f0c170a

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

PavelJurka added 2 commits July 26, 2024 20:38

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

64b2d2e

Merge branch 'main' into 1122-User-LdapPerson-Asure-AD-support

669339a

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

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 Jul 23, 2024

PavelJurka Jul 24, 2024

mikeradka Jul 24, 2024 •

edited

Loading

pagbabian-splunk Jul 25, 2024

pagbabian-splunk Aug 14, 2024

mikeradka commented Jul 24, 2024 •

edited

Loading

pagbabian-splunk Jul 25, 2024

pagbabian-splunk Aug 14, 2024

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:

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mikeradka Jul 24, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mikeradka commented Jul 24, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

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 Jul 24, 2024 •

edited

Loading

mikeradka commented Jul 24, 2024 •

edited

Loading

pagbabian-splunk Aug 14, 2024 •

edited

Loading

pagbabian-splunk Aug 14, 2024 •

edited

Loading