Azure SSO and SCIM for Snowflake

Connect Microsoft Entra ID to Snowflake with SAML SSO and SCIM provisioning.

Introduction

30 Second Summary

Think about how you log into apps at work. Instead of remembering dozens of separate passwords, you click one button and you're in.

In this project, you will connect Microsoft Entra ID to Snowflake using SAML 2.0 for single sign-on and SCIM 2.0 for automated user provisioning. By the end, users created in Entra ID will automatically appear in Snowflake with the correct roles pre-assigned.

What You'll Build

A complete identity management pipeline that federates authentication and automates user lifecycle management between Microsoft Entra ID and Snowflake.

By the end of this project, you'll have:

  • A SAML 2.0 security integration in Snowflake connected to Microsoft Entra ID, enabling passwordless login via Single Sign-On.
  • A SCIM provisioning pipeline that automatically syncs users and groups from Entra ID into Snowflake.
  • Custom attribute mappings that assign Snowflake roles based on Entra ID group membership.
  • Secret Mission: Configure SP-initiated SSO so users can start login from the Snowflake page, and lock down SCIM with a network policy.

Are there any prerequisites?

No prior experience with Snowflake or Microsoft Entra ID is required. This project includes full setup instructions for both platforms, including signing up for free accounts.

Before We Start

Before We Start...

Set Up Your Snowflake Trial Account

To configure SSO and automated provisioning, you first need a Snowflake account to act as the service provider in your identity pipeline.

In this step, you'll create a free Snowflake trial account, sign into the web interface, and confirm you have the admin role needed for the rest of the project.

In this step, get ready to:
  • Sign up for a Snowflake free trial account.
  • Log into Snowsight and note your account URL.
  • Verify your ACCOUNTADMIN role is active.
Sign up for a Snowflake free trial

Snowflake offers a 30-day free trial with $400 in credits. No credit card is required.

  • Open your browser and navigate to signup.snowflake.com.
  • Fill in the signup form with your name, email, company name, and job title.
  • Click Sign up.
  • On the next screen, select Enterprise as the Snowflake edition.
  • Select Microsoft Azure as your cloud provider.
  • Choose a region close to you (any region works for this project).
  • Click Get Started.
  • Check your email for a verification link and click it to activate your account.

Why Azure as the cloud provider?

This project integrates Snowflake with Microsoft Entra ID (formerly Azure Active Directory). Choosing Azure as your Snowflake cloud provider keeps your data within the same cloud ecosystem.

Any cloud provider works for this project since the SSO and SCIM features are cloud-agnostic. Azure is recommended for simplicity.

Not receiving the verification email?

Check your spam or junk folder. The email comes from Snowflake and can take a few minutes to arrive. Make sure you used a valid work or personal email address during signup.

help me troubleshoot why I'm not receiving my Snowflake verification email

Log into Snowsight and note your account URL

Once your account is activated, Snowflake redirects you to Snowsight (the Snowflake web UI). Your account URL is a unique identifier you will need in multiple places throughout this project.

  • After clicking the verification link, create a username and password when prompted.
  • You are now signed into Snowsight.
  • Look at your browser's address bar. Your account URL follows the format https://<orgname>-<accountname>.snowflakecomputing.com.
  • Copy this URL and save it somewhere accessible (a text file or sticky note). You will use it repeatedly throughout this project.

What is the account URL?

Your Snowflake account URL uniquely identifies your account across the internet. It combines your organization name and account name into a single address.

You will paste this URL into SAML configuration fields and SCIM provisioning settings later in the project. Having it on hand saves time.

Verify you have the ACCOUNTADMIN role

The ACCOUNTADMIN role is the highest-privilege role in Snowflake. You need it to create security integrations for SSO and SCIM provisioning.

  • In the Snowsight navigation menu (left sidebar), select your username at the bottom.
  • A user menu appears showing your current role.
  • Select your current role name to open the role selector.
  • Confirm that ACCOUNTADMIN is listed. Select it if it is not already active.

You should see ACCOUNTADMIN displayed as your active role in the bottom-left of the navigation menu.

What is ACCOUNTADMIN?

ACCOUNTADMIN is Snowflake's top-level administrative role. It has full privileges to create and manage security integrations, users, roles, and account-level settings.

As the account creator, you are automatically granted this role. In production environments, this role is tightly controlled and shared among very few administrators.

Don't see ACCOUNTADMIN in the role list?

If you just created your trial account, you should have ACCOUNTADMIN by default. Try refreshing the browser page. If the role still does not appear, sign out and sign back in.

help me figure out why ACCOUNTADMIN is not showing in my Snowflake role list

Your Snowflake account is ready and you have full admin access. Next up, you'll set up Microsoft Entra ID and create the test user that will prove your SSO integration works.

Set Up Microsoft Entra ID

Your Snowflake account is ready and waiting for an identity provider to connect to. Now you need the other half of the SSO equation.

Microsoft Entra ID (formerly Azure Active Directory) is the Identity Provider (IdP) that will manage your users and authenticate them into Snowflake. In this step, you will set up a free Entra ID tenant, create a test user, and organize that user into a security group that will later map to a Snowflake role.

In this step, get ready to:
  • Sign into Microsoft Entra ID in the Azure portal.
  • Create a test user for SSO and provisioning testing.
  • Create a security group that will map to a Snowflake role.
Sign up for Azure and navigate to Entra ID

Before you can manage identities, you need access to the Microsoft Entra admin center. If you already have an Azure account, you can skip directly to navigating to Entra ID.

  • Open your web browser and go to portal.azure.com.
  • If you do not have an Azure account, click Start free and follow the sign-up process.
  • Sign in with your Microsoft account credentials.

What is Microsoft Entra ID?

Microsoft Entra ID is Microsoft's cloud-based identity and access management service. It acts as the central directory where you manage users, groups, and application access.

When you create a new Azure account, a default Entra ID tenant is automatically created for you. This means you already have an identity directory ready to use without any extra setup.

  • Once you are signed into the Azure portal, type Microsoft Entra ID in the search bar at the top of the page.
  • Select Microsoft Entra ID from the search results.

You should see the Entra ID Overview page showing your tenant name and primary domain (something like yourdomain.onmicrosoft.com).

Note your primary domain

Your primary domain (the .onmicrosoft.com address shown on the Overview page) is needed when creating users. Keep this page open or note it down.

Can't find Microsoft Entra ID?

If the search does not return results, try searching for Azure Active Directory instead. Some tenants still show the older name in the search bar.

If you are on a brand new free account, Entra ID should already be available in the left sidebar under Azure services.

Help me find Microsoft Entra ID in the Azure portal.

Create a test user in Entra ID

You need a test user to verify that SSO and SCIM provisioning work correctly later in the project. This user will be the one who logs into Snowflake via Entra ID.

  • In the Entra ID left sidebar, under Manage, select Users.
  • Click New user in the top menu bar.
  • Select Create new user from the dropdown.

The New user form appears with a Basics tab.

  • In the User principal name field, enter snowtest (the domain after the @ symbol should already show your .onmicrosoft.com domain).
  • In the Display name field, enter Snow Test User.
  • Uncheck Auto-generate password and enter a password you will remember for testing.
  • Click Review + create.
  • Click Create.

You should see a notification confirming the user was created, and the user should now appear in the All users list.

What is a user principal name?

The user principal name (UPN) is the username format used for signing in. It looks like an email address (e.g., snowtest@yourdomain.onmicrosoft.com) and must be unique within your tenant.

This UPN will later need to match exactly in Snowflake so the two systems can identify the same person.

Only seeing an Invite option?

If you only see Invite external user and not Create new user, make sure you are signed in as a Global Administrator. New free Azure accounts should have Global Admin permissions by default.

Help me create a new user in Entra ID.

Create a security group

Security groups in Entra ID control who has access to what. When you provision this group into Snowflake via SCIM later, it becomes a Snowflake role.

  • In the Entra ID left sidebar, under Manage, select Groups.
  • Click New group in the top menu bar.

The New Group form appears.

  • Set Group type to Security.
  • In the Group name field, enter Snowflake_Analysts.
  • Leave Membership type set to Assigned.
  • Under Members, click No members selected.
  • Search for Snow Test User, select them, and click Select.
  • Click Create.

You should see a notification confirming the group was created. The group now appears in the All groups list with one member.

Why name the group Snowflake_Analysts?

When SCIM provisions this group into Snowflake, the group's display name becomes a Snowflake role name. Choosing a descriptive name now means the resulting Snowflake role is easy to identify later.

In a real enterprise, you would create multiple groups matching your organization's job functions (e.g., Snowflake_Engineers, Snowflake_DataScientists).

Cannot create a security group?

If the Create button is greyed out or you get a permissions error, confirm you are signed in as a Global Administrator or User Administrator. New free Azure accounts should have Global Admin by default.

Help me troubleshoot group creation in Entra ID.

Your identity provider is ready with a test user and a group that will map to a Snowflake role. Next up, you will connect these two systems by configuring SAML SSO in your Entra ID enterprise application.

Configure SAML SSO in Microsoft Entra ID

Your Microsoft Entra ID tenant is ready with a test user and a security group. Now it is time to connect Entra ID to Snowflake so your users can authenticate without a separate Snowflake password.

You will add Snowflake as an enterprise application and configure SAML 2.0 Single Sign-On. SAML is a protocol that lets one system (the Identity Provider) vouch for a user's identity to another system (the Service Provider). Entra ID acts as the Identity Provider, and Snowflake acts as the Service Provider.

In this step, get ready to:
  • Add the Snowflake enterprise application from the Entra ID gallery.
  • Configure SAML SSO settings with your Snowflake account URL.
  • Assign your test user to the application.
Add Snowflake from the application gallery

Entra ID has a gallery of pre-configured enterprise applications. The Snowflake application comes with SAML and SCIM templates already built in, so you do not have to configure every setting from scratch.

  • In the Azure portal, click the search bar at the top and type Enterprise applications.
  • Select Enterprise applications from the results.
  • Click New application at the top of the page.
  • In the gallery search bar, type Snowflake.
  • Select Snowflake from the search results.
  • Click Create to add the app to your tenant.

Wait a few seconds for the application to be added. You will be redirected to the Snowflake application overview page.

What is an enterprise application?

An enterprise application in Entra ID is a registration that represents an external service your organization uses. It controls who can access the service and how authentication works.

By adding Snowflake as an enterprise app, you give Entra ID the ability to manage which users can sign into Snowflake and how they prove their identity.

Don't see Snowflake in the gallery?

Make sure you are searching within the Browse Microsoft Entra Gallery section (not the general portal search). Try searching for just Snowflake without any extra words.

help me find the Snowflake enterprise application in the Entra ID gallery

Configure SAML single sign-on settings

With the app added, you need to tell Entra ID where to send authentication responses. This means entering your Snowflake account URL in the SAML configuration so the two systems can communicate.

  • In the left sidebar of your Snowflake enterprise app, click Single sign-on.
  • Select SAML as the single sign-on method.

You will see the SAML-based Sign-on configuration page with numbered sections.

  • In the Basic SAML Configuration section, click Edit.
  • In the Identifier (Entity ID) field, enter your Snowflake account URL. It follows this format:
https://[[SNOWFLAKE_ACCOUNT_URL="orgname-accountname"]].snowflakecomputing.com
  • In the Reply URL (Assertion Consumer Service URL) field, enter your Snowflake account URL with /fed/login appended:
https://[[SNOWFLAKE_ACCOUNT_URL="orgname-accountname"]].snowflakecomputing.com/fed/login
  • Click Save at the top of the Basic SAML Configuration panel.

Where do I find my Snowflake account URL?

You noted your account URL when you set up your Snowflake trial. It looks like https://orgname-accountname.snowflakecomputing.com. You can also find it in the Snowsight browser address bar when you are signed in.

The Identifier tells Entra ID which application it is issuing tokens for. The Reply URL tells Entra ID where to send the authentication response after a user signs in.

Next, you need to grab the certificate and URLs that Snowflake will need to trust Entra ID.

  • Scroll down to the SAML Signing Certificate section (section 3).
  • Click Download next to Certificate (Base64). Save this file somewhere you can find it later.
  • Scroll down to the Set up Snowflake section (section 4).
  • Copy the Login URL and paste it somewhere safe (a text file or notes app).
  • Copy the Microsoft Entra Identifier and paste it alongside your Login URL.

Keep these three values handy

You will need the Certificate (Base64) file, the Login URL, and the Microsoft Entra Identifier in the next step when you create the security integration in Snowflake. Having them in a text file prevents switching back and forth between tabs.

What do these values do?

The certificate lets Snowflake verify that login tokens genuinely came from your Entra ID tenant (not an impersonator). The Login URL is where Snowflake redirects users to sign in. The Microsoft Entra Identifier is the unique name Entra ID uses to identify itself to Snowflake.

Assign the test user to the application

Adding an enterprise app does not automatically give anyone access to it. You need to explicitly assign users or groups so that only the right people can sign in via SSO.

  • In the left sidebar of your Snowflake enterprise app, click Users and groups.
  • Click Add user/group at the top.
  • Under Users, click None Selected.
  • Search for Snow Test User and select them.
  • Click Select.
  • Click Assign.

You should now see Snow Test User listed under Users and groups for the Snowflake app.

Why assign users individually?

Entra ID uses assignment-based access by default. Only users (or members of groups) that are explicitly assigned to an enterprise app can authenticate via SSO. This is a security measure that prevents accidental access.

Later, when you configure SCIM provisioning, you will assign the Snowflake_Analysts group instead. For now, assigning the individual user lets you test SSO before adding the complexity of group-based provisioning.

Can't find Snow Test User?

Make sure you are searching by display name (Snow Test User) or the user principal name (snowtest@yourdomain.onmicrosoft.com). If the user does not appear, confirm they were created in the same Entra ID tenant where you added the Snowflake app.

help me find my test user when assigning them to the Snowflake enterprise app

The Entra ID side of SSO is now fully configured. Next, you will create the matching security integration in Snowflake so it knows to trust your Entra ID tenant for authentication.

Create the SAML Security Integration in Snowflake

You have the SAML configuration values ready in Entra ID. Now you need to tell Snowflake about your identity provider so it knows where to send authentication requests and how to verify the responses.

In this step, you will create a security integration in Snowflake that connects it to Entra ID via SAML 2.0. You will also create a matching user account and verify end-to-end SSO login.

In this step, get ready to:
  • Create a SAML2 security integration in Snowflake using the values from Entra ID.
  • Create a Snowflake user that matches the Entra ID test user.
  • Test SSO login from the Entra admin center.
Create the SAML2 security integration

A security integration is the Snowflake object that stores all the details about an external identity provider. It tells Snowflake which IdP to trust, where to redirect users for login, and which certificate to use when verifying SAML assertions.

  • Return to your Snowsight browser tab.
  • Select Projects in the left navigation, then select Worksheets.
  • Click the + button and select SQL Worksheet to open a new worksheet.
  • Make sure your role is set to ACCOUNTADMIN in the top-left role selector of the worksheet.
  • Create the SAML2 security integration by pasting and running the following SQL, replacing the placeholder values with the ones you copied from Entra ID in the previous step:
USE ROLE ACCOUNTADMIN;

-- Create the SAML2 security integration connecting Snowflake to Entra ID
CREATE OR REPLACE SECURITY INTEGRATION entra_id_sso
  TYPE = SAML2
  ENABLED = TRUE
  SAML2_ISSUER = '[[ENTRA_IDENTIFIER="your Microsoft Entra Identifier"]]'
  SAML2_SSO_URL = '[[ENTRA_LOGIN_URL="your Login URL from Entra ID"]]'
  SAML2_PROVIDER = 'CUSTOM'
  SAML2_X509_CERT = '[[CERT_CONTENT="certificate content without BEGIN/END lines"]]'
  SAML2_SNOWFLAKE_ISSUER_URL = '[[SNOWFLAKE_ACCOUNT_URL="https://orgname-accountname.snowflakecomputing.com"]]'
  SAML2_SNOWFLAKE_ACS_URL = '[[SNOWFLAKE_ACCOUNT_URL="https://orgname-accountname.snowflakecomputing.com"]]/fed/login';

What do these parameters mean?

  • SAML2_ISSUER is the Microsoft Entra Identifier you copied. It tells Snowflake which IdP issued the SAML assertion.
  • SAML2_SSO_URL is the Login URL. Snowflake redirects users here when they need to authenticate.
  • SAML2_X509_CERT is the Base64 certificate content (without the BEGIN/END CERTIFICATE lines). Snowflake uses it to verify that SAML responses genuinely came from Entra ID.
  • SAML2_SNOWFLAKE_ISSUER_URL and SAML2_SNOWFLAKE_ACS_URL tell Entra ID where to send the SAML response back to. The ACS URL includes /fed/login at the end.
  • Click the Run button (or press Cmd+Enter on macOS or Ctrl+Enter on Windows) to execute the SQL.
  • You should see a "Statement executed successfully" message in the results panel at the bottom of the worksheet.

Seeing an error?

  • If you see a permissions error, confirm your role is set to ACCOUNTADMIN in the worksheet role selector (top-left corner).
  • If you see a certificate error, make sure you pasted only the Base64 content from the certificate file. Remove the -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- lines and any line breaks.
  • Double-check that your Snowflake account URL does not have a trailing slash.

Help me troubleshoot my SAML2 security integration creation error in Snowflake.

Create a matching Snowflake user

For SSO to work, Snowflake needs a user account whose LOGIN_NAME matches the user principal name (UPN) that Entra ID sends in the SAML assertion. Without this match, Snowflake cannot map the incoming SSO login to a local account.

  • In the same Snowsight worksheet, create a user for your test account by running the following SQL:
-- Create a Snowflake user whose LOGIN_NAME matches the Entra ID UPN
CREATE USER snow_test_user
  LOGIN_NAME = '[[TEST_USER_UPN="snowtest@yourdomain.onmicrosoft.com"]]'
  DISPLAY_NAME = 'Snow Test User';

Why does LOGIN_NAME matter?

When Entra ID sends a SAML assertion, it includes the user's UPN (like snowtest@yourdomain.onmicrosoft.com). Snowflake looks for a user whose LOGIN_NAME matches that value exactly. If no match exists, the SSO login fails.

The LOGIN_NAME here must be the same UPN you assigned to your test user back in Step 2.

  • Click Run to execute the statement.
  • You should see a "Statement executed successfully" message confirming the user was created.

User already exists?

If you see an error that the user already exists, it may have been created earlier. You can drop and recreate it by running DROP USER snow_test_user; first, then re-running the CREATE USER statement.

Help me fix a user creation error in Snowflake.

Test SSO login

The security integration and matching user are in place. Now you can verify that the entire SAML flow works end-to-end by using the built-in test feature in the Entra admin center.

  • Switch back to the Entra admin center in your browser.
  • Navigate to your Snowflake enterprise app. Select Single sign-on in the left menu.
  • Scroll down to the Test single sign-on section at the bottom of the page.
  • Click Test.
  • If prompted, sign in as your test user (Snow Test User) with the credentials you set in Step 2.

You should be redirected to Snowsight and signed in without entering a Snowflake password. This confirms that the SAML flow between Entra ID and Snowflake is working correctly.

SSO test failing?

  • Verify that the LOGIN_NAME of your Snowflake user matches the UPN of your Entra ID test user exactly (case-sensitive).
  • Check that the Identifier (Entity ID) in Entra ID matches the SAML2_SNOWFLAKE_ISSUER_URL in your security integration. They must be identical.
  • Confirm the test user is assigned to the Snowflake enterprise app under Users and groups.
  • If you see a certificate validation error, re-download the Base64 certificate from Entra ID and paste the content (without BEGIN/END lines) into the security integration again.

Help me debug why my SAML SSO test between Entra ID and Snowflake is failing.

Your SSO pipeline is now live. Users can authenticate through Entra ID and land directly in Snowflake. Next up, you will enable SCIM provisioning so that users and groups sync automatically without manual account creation.

Enable SCIM Provisioning in Snowflake

Your SSO integration is live. Users can now authenticate into Snowflake through Entra ID without a Snowflake password.

SSO handles authentication, but it does not create user accounts or assign roles in Snowflake. That is where SCIM comes in. SCIM (System for Cross-domain Identity Management) automatically syncs users and groups from Entra ID into Snowflake so you do not have to manage them manually in both places.

In this step, get ready to:
  • Create a dedicated provisioning role and SCIM security integration in Snowflake.
  • Generate a SCIM access token for Entra ID to authenticate with Snowflake.
  • Create a Snowflake role that will map to your Entra ID security group.
Create the SCIM provisioning role and security integration

SCIM provisioning requires a dedicated Snowflake role that owns all users and roles created through the sync process. This role needs permission to create users and roles on the account.

  • Switch back to your Snowsight worksheet and run the following SQL to create the provisioning role and SCIM integration:
USE ROLE ACCOUNTADMIN;

-- Create a dedicated role for SCIM provisioning
CREATE ROLE IF NOT EXISTS aad_provisioner;
GRANT CREATE USER ON ACCOUNT TO ROLE aad_provisioner;
GRANT CREATE ROLE ON ACCOUNT TO ROLE aad_provisioner;
GRANT ROLE aad_provisioner TO ROLE accountadmin;

-- Create the SCIM security integration for Azure
CREATE OR REPLACE SECURITY INTEGRATION aad_provisioning
  TYPE = SCIM
  SCIM_CLIENT = 'azure'
  RUN_AS_ROLE = 'AAD_PROVISIONER';

What does this SQL do?

  • CREATE ROLE IF NOT EXISTS aad_provisioner creates a dedicated role that will own every user and role synced from Entra ID.
  • The two GRANT statements give this role permission to create users and roles on the account.
  • GRANT ROLE aad_provisioner TO ROLE accountadmin lets ACCOUNTADMIN manage anything the provisioner creates.
  • The CREATE SECURITY INTEGRATION statement registers the SCIM endpoint that Entra ID will call to sync users and groups.

Why a dedicated provisioning role?

The AAD_PROVISIONER role owns all users and roles created by SCIM. If Entra ID sends an update (like deactivating a user), Snowflake checks whether the integration's RUN_AS_ROLE owns that user before applying the change.

Without this ownership pattern, SCIM updates from Entra ID would silently fail because the integration would lack permission to modify existing users.

  • Click the run button (or press Cmd+Enter on macOS, Ctrl+Enter on Windows) to execute all statements.
  • Each statement should show a success message in the results pane. The final statement confirms the integration was created.

Seeing a permission error?

  • Confirm you are using the ACCOUNTADMIN role. Click your profile icon in the top-left corner of Snowsight and check the active role.
  • If you see an error about an existing integration, the name aad_provisioning may already be in use. The CREATE OR REPLACE syntax should handle this, but verify you typed the integration name correctly.
  • Still stuck? Help me troubleshoot my SCIM integration creation error in Snowflake.
Generate a SCIM access token

Entra ID needs a token to authenticate when it calls Snowflake's SCIM endpoint. This token acts as the credential that proves Entra ID is authorized to create and update users in your account.

  • Run the following SQL in your worksheet to generate the token:
SELECT SYSTEM$GENERATE_SCIM_ACCESS_TOKEN('AAD_PROVISIONING');

What does this command do?

SYSTEM$GENERATE_SCIM_ACCESS_TOKEN creates a bearer token tied to your aad_provisioning integration. Entra ID will include this token in every SCIM request it sends to Snowflake.

The token expires after 6 months. You will need to regenerate it before expiry to keep provisioning running.

  • Click the run button to execute the statement.
  • Copy the token value from the results pane immediately and store it somewhere secure (a password manager or a temporary text file). You will paste it into Entra ID in the next step.

Store this token securely

This token grants the ability to create and modify users in your Snowflake account. Treat it like a password. Do not commit it to version control or share it in plain text.

You cannot retrieve this token again after navigating away. If you lose it, you will need to regenerate a new one.

Token generation returned an error?

  • Make sure the integration name matches exactly: AAD_PROVISIONING (case-insensitive in Snowflake, but the quotes must wrap the name correctly).
  • Verify the integration was created successfully in the previous substep. Run SHOW SECURITY INTEGRATIONS; and look for aad_provisioning in the results.
  • Need more help? Help me troubleshoot why SYSTEM$GENERATE_SCIM_ACCESS_TOKEN is failing.
Create the analyst role for group mapping

In the next step, you will configure Entra ID to provision your Snowflake_Analysts group into Snowflake. Groups in Entra ID map to roles in Snowflake. You need the target role to exist before provisioning can assign users to it.

  • Run this SQL to create the analyst role and grant it warehouse access:
-- Create the role that maps to the Snowflake_Analysts group
CREATE ROLE IF NOT EXISTS analyst_role;
GRANT USAGE ON WAREHOUSE COMPUTE_WH TO ROLE analyst_role;

What does this SQL do?

CREATE ROLE IF NOT EXISTS analyst_role creates the Snowflake role that your Entra ID group will map to.

GRANT USAGE ON WAREHOUSE COMPUTE_WH gives anyone with this role permission to run queries using the default compute warehouse. Without this grant, provisioned users would have a role but no way to execute queries.

  • Click the run button to execute both statements.
  • You should see success confirmations for both the role creation and the grant.

Warehouse COMPUTE_WH not found?

  • Snowflake trial accounts create a default warehouse called COMPUTE_WH. If yours has a different name, run SHOW WAREHOUSES; to find your warehouse name and substitute it in the GRANT statement.
  • Need help? Help me find my Snowflake warehouse name so I can grant usage to my analyst_role.

✔️ Awesome, I've got everything!

Great. Make sure you have the SCIM access token saved somewhere safe. You will need it in the very next step.

ⓧ I'd like to double check the full code

Here is all the SQL you should have run in this step:

USE ROLE ACCOUNTADMIN;

CREATE ROLE IF NOT EXISTS aad_provisioner;
GRANT CREATE USER ON ACCOUNT TO ROLE aad_provisioner;
GRANT CREATE ROLE ON ACCOUNT TO ROLE aad_provisioner;
GRANT ROLE aad_provisioner TO ROLE accountadmin;

CREATE OR REPLACE SECURITY INTEGRATION aad_provisioning
  TYPE = SCIM
  SCIM_CLIENT = 'azure'
  RUN_AS_ROLE = 'AAD_PROVISIONER';

SELECT SYSTEM$GENERATE_SCIM_ACCESS_TOKEN('AAD_PROVISIONING');

CREATE ROLE IF NOT EXISTS analyst_role;
GRANT USAGE ON WAREHOUSE COMPUTE_WH TO ROLE analyst_role;

Your Snowflake account is now ready to receive provisioned users from Entra ID. Next up, you will connect Entra ID to this SCIM endpoint and configure the attribute mappings that control which users get synced and what roles they receive.

Configure SCIM Provisioning in Entra ID

In the previous step, you created the SCIM security integration in Snowflake and generated an access token. Now you'll use that token to connect Entra ID to Snowflake's SCIM endpoint.

Once this connection is active, Entra ID will automatically push user and group data to Snowflake. This eliminates the need to manually create accounts whenever someone joins your organization.

In this step, get ready to:
  • Connect Entra ID to Snowflake's SCIM endpoint.
  • Review the default attribute mappings for users and groups.
  • Assign a group and start the provisioning sync.
Connect Entra ID to Snowflake's SCIM endpoint

The provisioning configuration tells Entra ID where to send user and group data. You'll provide your Snowflake SCIM endpoint URL and the access token you generated in the previous step.

  • Switch back to the Entra admin center in your browser.
  • Click Enterprise applications in the left sidebar.
  • Select your Snowflake application from the list.
  • Click the Provisioning tab in the left menu.
  • Click + New configuration.
  • Set the Provisioning Mode to Automatic.
  • In the Admin Credentials section, enter your Snowflake SCIM endpoint URL in the Tenant URL field. This is your Snowflake account URL with /scim/v2/ appended to the end.
  • Paste the SCIM access token you copied in the previous step into the Secret Token field.
  • Click Test Connection.

What is the Tenant URL?

The Tenant URL is your Snowflake account URL followed by /scim/v2/. For example, if your account URL is https://myorg-myaccount.snowflakecomputing.com, your Tenant URL would be https://myorg-myaccount.snowflakecomputing.com/scim/v2/.

This is the endpoint where Entra ID sends SCIM requests to create, update, and delete users and groups in Snowflake.

You should see a success message confirming that the supplied credentials are authorized to enable provisioning.

  • Click Save to store the provisioning configuration.

Test Connection failed?

Double-check that your Tenant URL ends with /scim/v2/ (including the trailing slash). Also confirm the SCIM access token was pasted completely with no extra spaces.

If you still see an error, return to Snowsight and regenerate the token. The token must come from the exact integration name AAD_PROVISIONING (case-sensitive).

Help me troubleshoot my SCIM provisioning connection between Entra ID and Snowflake

Review default attribute mappings

Attribute mappings control which user and group fields sync from Entra ID to Snowflake. The defaults cover the most important identity attributes.

  • In your provisioning configuration, expand the Mappings section.
  • Click Provision Microsoft Entra ID Users (or a similar label referencing Users).
  • Review the default user attributes that sync. You should see mappings for displayName, userName, emails, name.givenName, name.familyName, active, and externalId.
  • Click the back arrow or breadcrumb to return to the Mappings section.
  • Click Provision Microsoft Entra ID Groups (or a similar label referencing Groups).
  • Verify the group mappings include displayName and members.
  • Click the back arrow to return to the main provisioning page.

Why do groups matter for Snowflake?

When Entra ID provisions a group to Snowflake via SCIM, Snowflake creates a corresponding role with the same name. The group's displayName becomes the Snowflake role name, and the members mapping ensures users are automatically granted that role.

This is how you'll connect your Snowflake_Analysts group to a Snowflake role in the next substep.

Assign the group and start provisioning

Provisioning scope controls which users and groups are synced to Snowflake. You'll limit it to only the users and groups explicitly assigned to the enterprise app.

  • In the provisioning configuration, locate the Settings section.
  • Set the Scope to Sync only assigned users and groups.
  • Click Save.
  • Navigate back to your Snowflake enterprise app by clicking Snowflake in the breadcrumb or left menu.
  • Click Users and groups in the left menu.
  • Click Add user/group.
  • Search for and select your Snowflake_Analysts group.
  • Click Assign to add the group to the enterprise app.
  • Navigate to the Overview page of the Snowflake enterprise app.
  • Click Start provisioning.

What happens when provisioning starts?

Entra ID runs an initial provisioning cycle that scans all assigned users and groups. It sends SCIM requests to Snowflake to create or update user accounts and roles. This first cycle may take a few minutes.

After the initial cycle, Entra ID checks for changes approximately every 40 minutes. Any new group members, removed users, or attribute changes are automatically synced to Snowflake.

Provisioning status shows an error?

If provisioning enters a "quarantine" state, it usually means repeated failures when connecting to Snowflake. Check that your Snowflake trial account is still active and that the SCIM token has not been regenerated since you configured it here.

Help me fix my SCIM provisioning errors between Entra ID and Snowflake

Your provisioning pipeline is now live. Next up, you'll configure custom attribute mappings so that provisioned users are automatically assigned a specific Snowflake role based on their group membership.

Configure Custom Role Mapping via SCIM Attributes

Your SCIM provisioning pipeline is syncing users and groups from Entra ID into Snowflake. But synced users do not automatically receive a default Snowflake role. Without one, they land on the PUBLIC role at login and cannot access any warehouses or data.

In this step, you will add a custom SCIM attribute that tells Snowflake which role to assign to each provisioned user. This is how enterprises implement Role-Based Access Control across cloud platforms without manual intervention.

In this step, get ready to:
  • Add the custom defaultRole attribute to the Snowflake app schema in Entra ID.
  • Create a constant mapping that assigns ANALYST_ROLE to provisioned users.
  • Verify the role assignment in Snowflake using DESC USER.
Access the schema editor for custom SCIM attributes

The standard Entra ID provisioning UI does not expose all SCIM attributes that Snowflake supports. To add custom attributes, you need to access the Azure portal with a special URL parameter that enables the advanced schema editor.

  • Open a new browser tab and navigate to this URL:
  • https://portal.azure.com/?forceSchemaEditorEnabled=true
  • Click Enterprise applications in the left navigation menu.
  • Select your Snowflake application from the list.
  • Click Provisioning in the left menu.
  • Click Edit Provisioning.
  • Expand the Mappings section.
  • Click Provision Microsoft Entra ID Users.
  • Scroll down and check the Show Advanced Options checkbox.
  • Click Edit attribute list for SnowFlake.

Why do I need the schema editor URL?

The forceSchemaEditorEnabled=true parameter unlocks the advanced attribute editor in the Azure portal. Without it, you cannot add custom SCIM extension attributes like the one Snowflake uses for default roles.

Add the custom defaultRole attribute

You are now looking at the list of attributes that Entra ID can send to Snowflake during provisioning. You need to add a new attribute that Snowflake recognizes as the user's default role.

  • Scroll to the bottom of the attribute list where you see empty fields for adding a new entry.
  • In the Name field, enter exactly:
  • urn:ietf:params:scim:schemas:extension:2.0:User:defaultRole
  • Leave the Type set to String.
  • Click Save at the top of the page.

What is this attribute?

This is a SCIM extension attribute that Snowflake supports for setting a user's default role during provisioning. When Entra ID sends this attribute in the SCIM payload, Snowflake automatically assigns the specified role as the user's DEFAULT_ROLE.

Snowflake also supports similar attributes for urn:ietf:params:scim:schemas:extension:2.0:User:defaultWarehouse and urn:ietf:params:scim:schemas:extension:2.0:User:defaultSecondaryRoles.

Don't see the empty fields at the bottom?

Make sure you accessed the portal using the full URL with ?forceSchemaEditorEnabled=true. If you navigated to the portal normally, close the tab and open a new one with the correct URL.

Help me access the schema editor for custom SCIM attributes.

Create the role mapping and verify in Snowflake

Now that the custom attribute exists in the schema, you need to create a mapping that tells Entra ID what value to send for it. You will set a constant value of ANALYST_ROLE so that every provisioned user receives this as their default role.

  • Click the back arrow or navigate back to the Attribute Mappings page (the page where you checked "Show Advanced Options").
  • Click Add New Mapping.
  • Set Mapping type to Constant.
  • In the Constant Value field, enter ANALYST_ROLE.
  • Set the Target attribute to urn:ietf:params:scim:schemas:extension:2.0:User:defaultRole.
  • Click Ok, then click Save at the top of the Attribute Mappings page.

Why use a constant mapping?

A constant mapping sends the same value for every user in the provisioning scope. This works well when all members of a specific group should receive the same Snowflake role.

In a production environment, you might use expression-based mappings to assign different roles based on group membership or department attributes. The constant approach is the simplest starting point.

Now test that the mapping works by provisioning your test user on demand.

  • Navigate back to your Snowflake enterprise app's Provisioning page.
  • Click Provision on demand.
  • Search for and select your test user (Snow Test User).
  • Click Provision.
  • Review the results. You should see that the defaultRole attribute was sent with the value ANALYST_ROLE.

Provision on demand showing an error?

Make sure you saved both the attribute list (after adding the custom attribute) and the attribute mapping (after creating the constant mapping). If either save was missed, the attribute will not be recognized.

Also confirm that your test user is still assigned to the Snowflake enterprise app under Users and groups.

Help me troubleshoot SCIM provision on demand failures.

Finally, verify that Snowflake received the role assignment. Switch back to your Snowsight worksheet.

  • Run the following SQL to check the user's properties:
USE ROLE ACCOUNTADMIN;

DESC USER snow_test_user;

What does this command do?

DESC USER displays all properties of a Snowflake user, including their DEFAULT_ROLE. After SCIM provisioning pushes the custom attribute, you should see ANALYST_ROLE in the DEFAULT_ROLE field.

  • Look for the DEFAULT_ROLE property in the output. It should show ANALYST_ROLE.

DEFAULT_ROLE still showing empty or PUBLIC?

Go back to Entra ID and run Provision on demand again. Check the provisioning results to see if the defaultRole attribute appears in the modified attributes list.

If the attribute does not appear, verify that the custom attribute name in the schema editor matches exactly: urn:ietf:params:scim:schemas:extension:2.0:User:defaultRole. A single typo will cause the attribute to be silently ignored.

Help me fix my SCIM default role mapping.

Secret mission

SP-Initiated SSO and SCIM Network Policy

Your SSO works, but only when the login starts from Entra ID. What if users go directly to the Snowflake login page? And what stops unauthorized systems from making SCIM calls to your Snowflake account? In this secret mission, you will enable SP-initiated SSO and lock down SCIM provisioning with a network policy.

Clean Up Your Resources

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. This project uses a Snowflake free trial and Microsoft Entra ID free tier, so there are no ongoing costs while the trial is active.

Resources you used:

  • Snowflake trial account (free for 30 days or until $400 in credits are used).
  • Microsoft Entra ID tenant (free tier, no charges).
  • Snowflake enterprise application in Entra ID (SSO and provisioning configured).
  • SAML2 security integration (entra_id_sso) and SCIM security integration (aad_provisioning) in Snowflake.
  • Network policy scim_network_policy in Snowflake (from the Secret Mission).
  • SCIM access token (stored in Entra ID provisioning config, expires in 6 months).

Keep everything running

No action needed. Choose this if you are still actively exploring SSO, provisioning, or want to experiment with additional attribute mappings.

  • Your Snowflake trial lasts 30 days from signup. The Entra ID free tier has no expiration or charges.
  • The SCIM access token expires after 6 months. If you return after that, you will need to regenerate it.
  • The network policy remains attached to the SCIM integration. No action needed unless you want to update the allowed IP ranges.

Pause - I'll come back to this later

Stop SCIM provisioning to prevent any further sync activity while keeping all configuration intact.

  • In the Entra admin center, navigate to Enterprise applications > Snowflake > Provisioning.
  • Click Stop Provisioning on the Overview page.
  • Your SSO configuration, attribute mappings, and user assignments remain intact. You can restart provisioning at any time by clicking Start Provisioning.
  • Your Snowflake trial continues to count down. If it expires while paused, you will need a new Snowflake account to resume.

Delete - I don't want to use this again

Remove all project resources and start fresh. Follow these steps in order.

In Snowflake, open a Snowsight worksheet with the ACCOUNTADMIN role and run these commands:

USE ROLE ACCOUNTADMIN;

-- Remove the network policy from the SCIM integration first
ALTER SECURITY INTEGRATION aad_provisioning UNSET NETWORK_POLICY;

-- Drop the network policy
DROP NETWORK POLICY IF EXISTS scim_network_policy;

-- Drop both security integrations
DROP SECURITY INTEGRATION entra_id_sso;
DROP SECURITY INTEGRATION aad_provisioning;

-- Drop the provisioned user and roles
DROP USER IF EXISTS snow_test_user;
DROP ROLE IF EXISTS analyst_role;
DROP ROLE IF EXISTS aad_provisioner;

In the Entra admin center, delete the enterprise application:

  • Navigate to Entra ID > Enterprise applications > Snowflake.
  • In the Manage section of the left menu, click Properties.
  • Click Delete at the top of the Properties pane, then confirm with Yes.

Delete the test user and security group:

  • Navigate to Entra ID > Users. Select Snow Test User and click Delete.
  • Navigate to Entra ID > Groups. Select Snowflake_Analysts and click Delete.

Your Snowflake trial will expire on its own after 30 days. No further action is needed for the Snowflake account itself.

Nice Work!

Nice Work!

You just built an enterprise-grade identity management pipeline connecting Microsoft Entra ID to Snowflake!

Users created in Entra ID are now automatically provisioned into Snowflake, assigned roles based on group membership, and able to log in with SSO instead of separate passwords. This is the same identity federation pattern used by enterprise security teams managing access at scale.

You've learned how to:

  • Configure SAML 2.0 Single Sign-On between Microsoft Entra ID and Snowflake so users authenticate without a Snowflake password.
  • Build a SCIM provisioning pipeline that automatically syncs users and groups from your identity provider to Snowflake.
  • Map Entra ID groups to Snowflake roles using custom SCIM attributes for automated role-based access control.
  • Configured SP-initiated SSO and secured SCIM provisioning with a network policy.

Ready to quiz yourself?