Abbey Docs
  • 👋Welcome
  • Getting Started
    • Quickstart
    • Step-by-Step Tutorials
      • AWS: Managing Access to Identity Center Groups
      • AWS: Managing Access to Identity Center Permission Sets
      • AWS: Managing Access to IAM Groups
      • Azure AD: Managing Access to Groups
      • Confluent: Managing Access to Kafka ACLs
      • Databricks: Managing Access to Managed Tables in Unity Catalog
      • Databricks: Managing Access to Groups
      • GitHub: Managing Access to Teams
      • Google Cloud: Managing Access to Groups
      • Google Workspace: Managing Access to Google Groups
      • Kafka: Managing Access to ACLs
      • Okta: Managing Access to Groups
      • Postgres: Managing Access to Roles
      • Snowflake: Managing Access to Tables
      • Tabular: Managing Access to Apache Iceberg Roles
      • Tailscale: Managing Access to ACLs
      • Vault: Managing Access to Groups and Policies
      • Integrating Abbey with Terraform Cloud
      • Using Abbey with Atlantis
      • Using Abbey with Spacelift
    • Starter Kits
  • How Abbey Works
    • How Abbey Works
    • Key Concepts
  • Build a Grant Kit
    • Get a Starter Kit
    • Connect a Repo
    • Create a Grant Kit
    • Link Identities
    • Write Access Policies
    • Deploy Your Grant Kit
    • Request Access
    • Approve or Deny Access Requests
  • Use Cases
    • Time-Based Access
      • Expire After a Duration
      • Expire At a Specific Time
    • Approval Workflows
      • Using a Single Approval Step
      • Using Multiple Approval Steps
      • Conditionally Skip Approval Steps
  • Admin
    • User Roles
    • Sign-in and MFA
      • Sign-in Methods
      • Multifactor Authentication (MFA)
      • Enabling Single Sign-On
    • Sources
      • PagerDuty
      • Directory Sync
    • End User Notifications
    • Manage API Tokens
  • Reference
    • Grant Kits
      • Workflows
      • Policies
      • Outputs
    • Referencing Users and Groups
    • Linking Application Identities into Abbey
      • Why do I need to link application identities?
      • How do I Link Application Identities?
      • Supported Application Identity Types and Schemas
      • Application Data Object
    • Access Policies
      • Types of Access Policies
      • Policy Bundles
      • Inline Policies
      • Helper Functions
      • Policy Examples
    • Terms of Service
    • FAQ
      • Troubleshooting
  • Resources
    • Abbey Labs
    • Terraform Registry
    • GitHub
    • System Status
    • Privacy Policy
    • Logo
Powered by GitBook
On this page
  • Before you start
  • Step 1: Configure Your Grant Kit
  • Configure Output
  • Configure Reviewers
  • Step 2: Configure the Azure User
  • Step 3: Deploy Your Starter Kit
  • Step 5: Automate Access Management
  • Next Steps
  1. Getting Started
  2. Step-by-Step Tutorials

Azure AD: Managing Access to Groups

PreviousAWS: Managing Access to IAM GroupsNextConfluent: Managing Access to Kafka ACLs

Last updated 1 year ago

In this tutorial, you'll learn how to configure to add users to groups. This use case models Group-based access control.

To make this example simple, you can act as both the Azure user gaining access to the system and the approver of the system. This will allow you to go through the flow of requesting and approving access from the same account. In a more common production scenario, these calls would be happening from two separate accounts.

We will be using the as a base and replace configuration stubs for our use case.

Before you start

  1. Make sure you have:

    • An

    • An

    • An Azure user

  2. Make sure you setup:

    • An by following Get a Starter Kit

    • A Connection to a repo by following Connect a Repo

Step 1: Configure Your Grant Kit

Configure Output

Grant Kits rely on your GitHub account and repository name to output access changes, which we'll set through Terraform local variables. Update the locals block in main.tf with your account_name and repo_name

main.tf
 locals {
  account_name = "" #CHANGEME
  repo_name = "" #CHANGEME
  ...
}

Configure Reviewers

Workflow defines who should approve an access request.

Let's update the reviewers block by adding yourself as the reviewer by switching replace-me@example.com with the email address you use to sign into Abbey.

main.tf
 resource "abbey_grant_kit" "..." {
   ...
   workflow = {
     steps = [
       {
         reviewers = {
-          one_of = ["replace-me@example.com"] # CHANGEME
+          one_of = ["alice@example.com"]

Step 2: Configure the Azure User

In the Azure console, find your User and copy the User Principal Name. Replace the stub with it.

main.tf
data "azuread_user" "dev_azure_user" {
-  user_principal_name = "replace-me-EXT-MICROSOFT_UPN@example.com" # need to use azure userPrincipalName
+  user_principal_name = "alice-EXT-MICROSOFT_UPN@example.com"
}

This will allow terraform to grab the Azure user ID to generate the grant that adds the user to the group.

Step 3: Deploy Your Starter Kit

brew update && brew install azure-cli
az login

Then we'll need to create a set of credentials for use by Github via:

az ad sp create-for-rbac --name "myApp" --role contributor \
                            --scopes /subscriptions/{subscription-id} \
                            --sdk-auth

The command should output a JSON object similar to this:

  {
    "clientId": "<GUID>", # AZURE_CLIENT_ID
    "clientSecret": "<GUID>", # AZURE_CLIENT_SECRET
    "subscriptionId": "<GUID>", # AZURE_SUBSCRIPTION_ID
    "tenantId": "<GUID>", # AZURE_TENANT_ID
    (...)
  }

Next, add the following repository secrets so Github Actions can access these credentials.

  1. AZURE_CLIENT_ID

  2. AZURE_CLIENT_SECRET

  3. AZURE_SUBSCRIPTION_ID

  4. AZURE_TENANT_ID

You can do this via Github repo page -> Settings -> Secrets and Variables -> Actions -> New Repository Secret and create with the above names. You can take the values from the JSON output of the az ad sp command.

What should it look like?

We also will need to add the correct permissions to the role we created during the az ad sp create-for-rbac command. This will allow the Azure client using the secrets in the github actions job to add the user to the desired group.

Find the role by navigating to the Azure Console , then

  1. App Registrations

  2. View all registrations in Directory

  3. Select "myApp" (the app we created as part of the az command).

  4. API Permissions

  5. Add a Permissions

  6. Microsoft Graph

  7. Add Directory.ReadWrite.All with "Grant Admin Consent for Default Directory" enabled

Your final page in permissions should look like this:

To deploy your Starter Kit, follow instructions from Deploy Your Grant Kit.

Step 5: Automate Access Management

You can now start requesting and approving access by following the Request Access and Approve or Deny Access Requests guides.

Abbey strives to help you automate and secure access management without being intrusive.

To that end, this Pull Request contains native Terraform HCL code using normal open source Terraform Provider libraries. It represents the permissions change. In this case, it's just a simple creation of a new Terraform Resource.

After approving the request, you should be able to see that the User has been added to the Group in the Azure console. Note that because this starter kit comes with a time-based policy by default, the user will automatically be removed after 1 hour.

Next Steps

To learn more about what Resources you can configure, try one of our Step-by-Step Tutorials.

For more information on how Abbey works, visit the Key Concepts or Grant Kits page.

This repo uses Azure in the Github Actions job when generating terraform resources. We'll need to . On Mac:

ABBEY_TOKEN - API token taken from

Congratulations! Abbey is now managing permissions to your Resource for you.

🎉
🎉
install the Azure CLI
Settings > API Tokens
Azure Starter Kit
Abbey account
Azure Starter Kit
Grant Kits
Abbey API Token