BloodHound: a member count is this collection

The number is edges in the zip

When a group node shows a member count, that number is the membership edges in the collection you loaded. It describes the zip. It does not describe a change that happened after the collection.

A path count to a high-value target is a different number. Do not add the member count to a path count and call the sum one fact.

A live query is a second read

If you need the group as it is now, that is a directory query at a new time, written beside the zip. The picture does not update when the directory does.

If you did not run that query, write “live membership not queried.” Do not edit the node’s number to match what you expect.

What to file

File the group’s object id, the member count, and the zip name. File a live count only from the query you ran, with its time. Do not file one unlabeled integer.

Worked case: six members the day after a join

Zip lab-help-thursday.zip shows group Lab-Helpdesk with 6 members. The next morning a directory query shows 7, after a join that the zip could not contain. A draft says the directory has 6 because the picture says 6.

The note keeps 6 as the collection and 7 as the later query, with the query time. The picture is not edited. The join is not denied because the zip is smaller.

Snippet

zip: lab-help-thursday.zip
group: Lab-Helpdesk
members in the zip: 6
live query next morning: 7
write: 6 for the zip, 7 for the query
not: the directory has 6

Diagram

The collection and a later query

The node remembers the zip. The directory can move on.

In the zip

Is. Membership edges that were stored

Example. 6

Use. When you describe that collection

A later query

Is. The group at a new time

Example. 7 the next morning

Missing. Say the live list was not queried

Check yourself

1. A group node shows 6 members in a named zip. What is 6?

2. You did not query the directory after the collection. What do you write about today?

3. The next morning a query shows 7. What do you keep?