Skip to main content
Custom security attributes allow you to define and assign business-specific metadata to Azure AD objects, enabling fine-grained access control and organizational categorization.

Resources

Attribute Set

Resource: microsoft365_graph_beta_identity_and_access_attribute_set

Attribute Definition

Resource: microsoft365_graph_beta_identity_and_access_custom_security_attribute_definition

Allowed Values

Resource: microsoft365_graph_beta_identity_and_access_custom_security_attribute_allowed_value

Attribute Set

Create a container for related attributes:
resource "microsoft365_graph_beta_identity_and_access_attribute_set" "organization" {
  id          = "Organization"
  description = "Organizational attributes for access control"
}

Attribute Definition

resource "microsoft365_graph_beta_identity_and_access_custom_security_attribute_definition" "department" {
  attribute_set = microsoft365_graph_beta_identity_and_access_attribute_set.organization.id
  name          = "Department"
  description   = "User's department"
  
  data_type     = "String"
  is_collection = false
  is_searchable = true
  
  status       = "Available"
  use_predefined_values_only = false
}

Data Types

TypeDescriptionExample
StringText values”Engineering”, “Sales”
IntegerNumeric values12345
BooleanTrue/falsetrue, false

Assign to Users

resource "microsoft365_graph_beta_users_user" "employee" {
  display_name        = "John Doe"
  user_principal_name = "[email protected]"
  account_enabled     = true
  mail_nickname       = "johndoe"
  
  password_profile = {
    password = "SecurePassword123!"
  }
  
  custom_security_attributes = {
    Organization = {
      "@odata.type" = "#microsoft.graph.customSecurityAttributeValue"
      Department    = "Engineering"
      ClearanceLevel = "Confidential"
      CostCenter    = 1001
      Projects      = ["ProjectA", "ProjectB"]
    }
  }
}

Use in Conditional Access

Filter users based on custom attributes:
resource "microsoft365_graph_beta_identity_and_access_conditional_access_policy" "high_clearance" {
  display_name = "High Clearance Access"
  state        = "enabled"
  
  conditions = {
    users = {
      # Filter by custom security attribute
      # Note: Actual filtering syntax depends on implementation
    }
    
    applications = {
      include_applications = ["SensitiveApp"]
    }
  }
  
  grant_controls = {
    operator = "OR"
    authentication_strength = {
      id = "00000000-0000-0000-0000-000000000004"
    }
  }
}

Common Use Cases

Assign departments to users and use them to control access to resources.
Track which projects users are assigned to for resource allocation and access.
Define clearance levels and restrict access to sensitive data accordingly.
Assign cost centers for chargeback and reporting purposes.
Tag users with compliance requirements (HIPAA, PCI-DSS, etc.).

Import Syntax

# Attribute set
terraform import microsoft365_graph_beta_identity_and_access_attribute_set.set <set-id>

# Attribute definition
terraform import microsoft365_graph_beta_identity_and_access_custom_security_attribute_definition.attr <set-id>_<attr-name>

# Allowed value
terraform import microsoft365_graph_beta_identity_and_access_custom_security_attribute_allowed_value.value <set-id>_<attr-name>_<value-id>

Best Practices

Design your attribute structure before implementation. Attributes cannot be deleted, only deprecated.
Set use_predefined_values_only = true for attributes that should have a controlled vocabulary.
Enable is_searchable to allow filtering and querying by attribute values.
Use clear descriptions to explain what each attribute represents and how it should be used.

Build docs developers (and LLMs) love