Overview
When viewing the “Identities” page in Surface Command, how is “Administrator?” determined? What does it mean when this value is True, False, or blank?
While this field is a boolean field, interpreting its value is not always simple. This article explains:
- It’s a correlated property - what are the possible values, and what do they mean?
- How to query for common use cases around this field
- How do some of the data source (e.g., Entra ID) report this data, and how Surface Command evaluates that data.
It’s a Correlated Property - Possible Values
The is_administrator field is what’s called a correlated property, meaning that its presentation value is derived from one or more values contributed by the various data sources (connectors). It can have 3 possible values at the top level (we will dig into the levels below the “top level” later on):
| Value | Default Top-Level Meaning | …but… |
|---|---|---|
| True | At least one of the sources reported a True value for the Identity record | You, the customer, can control how the values from the sources are evaluated. Additionally, it’s helpful to understand how each of the sources evaluate True. |
| False | None of the sources reported True, and at least one of the sources reported False | You, the customer, can control how the values from the sources are evaluated. Additionally, it’s helpful to understand how each of the sources evaluate True. |
| blank / empty / null | None of the sources reported True or False values | This is rare, but possible when the number of sources reporting the Identity record is 1 or very low. |
Querying is_administrator
Consider the following simple query:
MATCH (i:Identity)
WHERE i.is_administrator = True
RETURN i
The result might look something like:
Based on the above table of the 3 possible values for the is_administator field, the safest interpretation is that these 2 identities were reported to be privileged users by at least one of AD, Google Workspace, or KnowBe4. Any interpretation beyond that requires additional analysis:
For “William Gates”, Google Workspace data indicated that William is a privileged user:
But since Active Directory directory did not report William as a privileged user, William’s admin-ness is probably limited to his activities in Google Workspace. Admin-ness is not all or none.
Admin-ness in Entra ID
In Surface Command’s Entra ID connector, the admin-ness of a user is determined to be True if any one of the following five conditions is met.
Assignment
- The user’s
userRegistrationDetails.isAdminproperty value, coming directly from the Microsoft API, is set to True
Direct Associations
- Associated with a Directory Role that is based on a privileged Unified Role Definition
- Associated with a Directory Role that is privileged
Transitive (indirect) Associations
- Associated with a Directory Role that is associated with a Directory Role that is based on a privileged Unified Role Definition
- Associated with a Directory Role that is associated with a Directory Role that is privileged
- Member of a Group that is associated with a directory role that is privileged
Admin-ness in Slack
As another data source example, let’s consider the is_admin property of a Slack User. According to Slack’s API documentation, this value is True if both of the following conditions are met:
- The user is a Slack Workspace admin.
- The API user is also an admin, otherwise, the property value is invisible.
The Context is Important
Is a Slack Workspace admin an admin in the same sense as an Entra ID privileged user? Probably not. The key point is that admin-ness is not meaningful without the context.
Querying is_administrator - Take Two
So, simply querying for Identity.is_administrator won’t always provide the complete answer. Therefore, it is sometimes useful to query the underlying “concrete” values from the data sources.
In the Identities page, this can be done by selecting the concrete properties and adding them to the output display (be sure to turn on the “Show source type” toggle):
In cypher, you can reference the underlying “concrete” properties as follows:
Note that the query matches User, not Identity (which is an alias to User).