For the complete documentation index, see llms.txt. This page is also available as Markdown.

GCP_IN_OU

Summary

Forestall ACL Alias

GCP_IN_OU

GCP Alias

Entity Relation (Structural)

Affected Object Types

Users, Organizational Units

Exploitation Certainty

Certain

Description

GCP_IN_OU is a structural edge representing that a Google Workspace User or Organizational Unit is contained within an Organizational Unit (OU) in the Google Workspace directory:

User ─── GCP_IN_OU ───► Organizational Unit
Child Organizational Unit ─── GCP_IN_OU ───► Parent Organizational Unit

The edge points from the contained object to its parent OU. A User belongs to exactly one OU at a time, while child OUs form a hierarchy beneath the root OU. The root OU itself is connected to the Customer by GCP_PARENT.

OUs structure the Workspace directory and apply policies selectively. Password policies, device policies, app access settings, and Context-Aware Access rules applied to a parent OU cascade to its child OUs and Users unless overridden.

Key properties:

  • The edge points from a User or child OU to its parent OU.

  • A User belongs to exactly one OU at a time.

  • OU-level policies apply to members and descend through the OU hierarchy unless overridden.

  • Moving a User or OU can change which inherited controls apply.

Identification

Google Admin Console

  1. Open Google Admin Console (admin.google.com) → Directory → Organizational units.

  2. Expand the OU tree to identify each child OU's parent.

  3. Select an OU to view its directly assigned Users.

Admin SDK Directory API

Exploitation

GCP_IN_OU has no direct exploit. Its security significance comes from OU-level policy inheritance:

  • Move a User to a less-restricted OU to bypass Context-Aware Access policies, app-access restrictions, or stricter MDM requirements applied to the original OU. Moving a User requires an appropriately privileged Workspace administrator.

  • Move a child OU beneath a less-restricted parent to change inherited controls for every User and nested OU below it.

  • Modify OU-level policies to relax security controls for all members and descendants simultaneously.

  • Map a target's effective controls by following its OU and ancestor OU edges.

Mitigation

  1. Restrict User and OU moves to dedicated directory administrators and require change approval for sensitive OUs.

  2. Keep privileged accounts in hardened OUs with the most restrictive access policies.

  3. Alert on hierarchy and membership changes involving executives, administrators, finance Users, and other sensitive populations.

  4. Layer security controls instead of relying solely on OU membership; use groups and Context-Aware Access as additional enforcement layers.

  5. Review inherited settings after OU moves to ensure the destination hierarchy does not weaken required controls.

Detection

Log Type
Method
Key Fields

Admin Activity

MOVE_USER_TO_ORG_UNIT

Actor, target User, source OU, destination OU

Admin Activity

MOVE_ORG_UNIT

Actor, target OU, previous parent, new parent

Admin Activity

CREATE_ORG_UNIT

Actor, new OU, parent OU

Alert on:

  • Users moved from a restricted OU to a less-restricted one.

  • Child OUs reparented beneath a hierarchy with weaker inherited controls.

  • OU membership changes for privileged or executive accounts.

  • Bulk User moves or hierarchy changes outside an approved maintenance window.

References

  • https://developers.google.com/admin-sdk/directory/reference/rest/v1/orgunits

  • https://knowledge.workspace.google.com/admin/users/advanced/add-an-organizational-unit

  • https://knowledge.workspace.google.com/admin/users/advanced/how-the-organizational-structure-works

Last updated

Was this helpful?