Single Sign-On (SSO) allows users to access Snowflake using their existing Microsoft Entra ID credentials instead of maintaining a separate Snowflake password.

In this tutorial, we’ll configure Microsoft Entra ID as the Identity Provider (IdP) and Snowflake as the Service Provider (SP) using SAML 2.0.

We’ll also cover two common problems that can occur during implementation:

SAML certificate validation errors
Snowflake being unable to find the user from the SAML assertion

Note: All tenant names, domains, Snowflake accounts, users, IDs, URLs, and screenshots used in this tutorial should use demonstration data. Do not publish production credentials or customer information.

What We’ll Build

Our authentication flow will look like this:

User → Snowflake → Microsoft Entra ID → SAML Authentication → Snowflake

For this tutorial, we’ll use the following dummy environment:

Setting	Example
Entra Tenant	DataTools SSO Demo
Entra Domain	datatoolsssodemo.onmicrosoft.com
Snowflake Organization	DEMOORG
Snowflake Account	DEMO12345
Test User	snowflake.user@example.com
Security Integration	ENTRA_SSO
Snowflake Role	PUBLIC

The corresponding demo Snowflake URL would be:

https://demoorg-demo12345.snowflakecomputing.com

Table of Contents

Step 1: Create a Microsoft Entra Test Tenant

For learning and testing, it’s a good idea to create a separate Microsoft Entra workforce tenant rather than experimenting inside a production customer tenant.

Microsoft Entra ID → Overview → Manage tenants → Create

Choose a Workforce tenant.

For example:

Organization name: DataTools SSO Demo
Initial domain: datatoolsssodemo.onmicrosoft.com
Country/Region: Select the appropriate region

Complete the tenant creation process.

Why use a separate tenant?

A dedicated test tenant lets you validate the complete authentication flow without affecting existing production users, applications, or authentication policies.

Suggested caption: Creating a dedicated Microsoft Entra workforce tenant for the Snowflake SSO lab.

Step 2: Switch to the New Entra Tenant

After creating the tenant, make sure you’re actually working inside it.

Open your account/profile menu and select the option to Switch directory.

Select:

DataTools SSO Demo

Then navigate to:

Microsoft Entra ID → Overview

Verify that the displayed tenant name and tenant ID belong to your new environment.

This is an easy step to overlook. Configuring the application in the wrong tenant can cause unnecessary troubleshooting later.

Step 3: Add Snowflake as an Enterprise Application

Inside Microsoft Entra, navigate to:

Entra ID → Enterprise applications → New application

Search for:

Snowflake

Select the official Snowflake for Microsoft Entra ID gallery application published by Snowflake and add it to your tenant.

Once created, open the Snowflake Enterprise Application.

Suggested caption: Snowflake added as an Enterprise Application in Microsoft Entra ID.

Important Permission Note

Your Snowflake permissions and Microsoft Entra permissions are completely separate.

Being ACCOUNTADMIN in Snowflake does not mean you have permission to create Enterprise Applications in Microsoft Entra.

Make sure your Entra administrator has the appropriate application-management permissions before beginning the implementation.

Step 4: Configure SAML Single Sign-On

Open your Snowflake Enterprise Application and navigate to:

Single sign-on → SAML

Under Basic SAML Configuration, click Edit.

We’ll use the following dummy Snowflake environment:

Organization: DEMOORG
Account: DEMO12345

Configure the URLs as follows.

Identifier / Entity ID

https://demoorg-demo12345.snowflakecomputing.com

Reply URL / ACS URL

https://demoorg-demo12345.snowflakecomputing.com/fed/login

Sign-on URL

https://demoorg-demo12345.snowflakecomputing.com

Logout URL

https://demoorg-demo12345.snowflakecomputing.com/fed/logout

Leave Relay State blank unless your implementation specifically requires it.

Save the configuration.

Suggested caption: Example Snowflake SAML service-provider URLs configured in Microsoft Entra.

Step 5: Download the Microsoft Entra SAML Certificate

Still inside the SAML configuration page, locate:

SAML Certificates

Download the active:

Certificate (Base64)

You’ll also need the values shown under the Snowflake setup section, including:

Login URL
Microsoft Entra Identifier

Keep these values available because we’ll use them when creating the Snowflake security integration.

Step 6: Prepare the Certificate Correctly

This is an important step because an incorrectly formatted certificate can cause Snowflake to reject the SAML response.

The downloaded certificate typically looks similar to:

-----BEGIN CERTIFICATE-----
MIIC8DCCAdigAwIBAgIQExampleCertificateData...
MoreBase64CertificateData...
-----END CERTIFICATE-----

For Snowflake’s SAML2_X509_CERT, remove:

-----BEGIN CERTIFICATE-----

and:

-----END CERTIFICATE-----

Then combine the complete certificate body into one continuous string without spaces or line breaks.

For example:

MIIC8DCCAdigAwIBAgIQExampleCertificateDataMoreBase64CertificateData...

Do not accidentally remove characters from the actual Base64 certificate body.

Step 7: Create the Snowflake SAML Security Integration

First check whether an integration with your intended name already exists:

USE ROLE ACCOUNTADMIN;

SHOW SECURITY INTEGRATIONS;

Now create your SAML2 security integration.

A simplified example looks like this:

CREATE SECURITY INTEGRATION ENTRA_SSO
    TYPE = SAML2
    ENABLED = TRUE
    SAML2_ISSUER = '<MICROSOFT_ENTRA_IDENTIFIER>'
    SAML2_SSO_URL = '<MICROSOFT_ENTRA_LOGIN_URL>'
    SAML2_PROVIDER = 'CUSTOM'
    SAML2_X509_CERT = '<BASE64_CERTIFICATE_BODY>'
    SAML2_SP_INITIATED_LOGIN_PAGE_LABEL = 'Microsoft Entra SSO'
    SAML2_ENABLE_SP_INITIATED = TRUE
    SAML2_SNOWFLAKE_ISSUER_URL =
        'https://demoorg-demo12345.snowflakecomputing.com'
    SAML2_SNOWFLAKE_ACS_URL =
        'https://demoorg-demo12345.snowflakecomputing.com/fed/login';

Replace the placeholder values with the information from your Microsoft Entra environment.

Keep an administrative fallback login available while testing SSO. Don’t disable your working authentication method until the new SSO flow has been successfully validated.

Step 8: Assign a User to the Snowflake Application

Return to Microsoft Entra and navigate to:

Enterprise applications → Snowflake → Users and groups

Click:

Add user/group

Select your test user.

For example:

snowflake.user@example.com

Leave the application role as User unless your organization’s configuration requires something different.

Click Assign.

Afterward, verify that the user appears in the Snowflake application’s assigned users.

Step 9: Check the SAML User Identity

This is one of the most important parts of the configuration.

Microsoft Entra sends an identity to Snowflake in the SAML assertion. Snowflake must be able to match that identity to a Snowflake user.

For example, suppose Entra sends:

snowflake.user@example.com

Your Snowflake user’s LOGIN_NAME should match that value.

Create a demonstration user:

USE ROLE ACCOUNTADMIN;

CREATE USER IF NOT EXISTS ENTRA_TEST_USER
    LOGIN_NAME = 'snowflake.user@example.com'
    DISPLAY_NAME = 'Entra SSO Test User'
    DEFAULT_ROLE = PUBLIC;

In production, assign whatever Snowflake roles are appropriate for the user’s actual access requirements.

Step 10: Test the SSO Flow

Open a new Incognito/Private browser window.

This prevents an existing Microsoft or Snowflake session from interfering with the test.

Navigate to your Snowflake base account URL:

https://demoorg-demo12345.snowflakecomputing.com

Do not manually start your test by browsing directly to:

/fed/login

The /fed/login URL is the Assertion Consumer Service (ACS) endpoint that receives the SAML response.

On the Snowflake login page, select:

Microsoft Entra SSO

You should be redirected to Microsoft Entra.

Authenticate using the user assigned to the Snowflake Enterprise Application.

After successful authentication, Entra sends the SAML response back to Snowflake.

Troubleshooting: HTTP 400 / Invalid SAML Certificate

During SSO testing, you may successfully authenticate with Microsoft but then receive an HTTP 400 error when the browser returns to Snowflake.

One possible Snowflake login error is related to:

SAML_RESPONSE_INVALID_BAD_CERT

This usually indicates that the certificate Snowflake is using doesn’t match the active certificate used by Microsoft Entra to sign the SAML response.

Fix

Return to:

Entra → Snowflake Enterprise Application → Single sign-on → SAML Certificates

Download the currently active Certificate (Base64) again.

Prepare the certificate correctly by:

Removing the BEGIN CERTIFICATE marker
Removing the END CERTIFICATE marker
Keeping the entire Base64 certificate body
Removing line breaks
Making the certificate one continuous string

Then update the existing Snowflake integration:

ALTER SECURITY INTEGRATION ENTRA_SSO
SET SAML2_X509_CERT = '<CORRECT_BASE64_CERTIFICATE_BODY>';

Retest using a new Incognito/Private browser session.

Troubleshooting: “Matching User Is Not Found”

After fixing the certificate, you may encounter another error:

SAML response is invalid or matching user is not found.

Don’t immediately assume the visible Microsoft Entra username is the value Snowflake is receiving.

Snowflake provides a login failure UUID on the error page.

Copy that UUID and run:

SELECT SYSTEM$GET_LOGIN_FAILURE_DETAILS(
    '<UUID_FROM_SNOWFLAKE_ERROR_PAGE>'
);

This can reveal the actual identity Snowflake is attempting to resolve.

For example, the result might indicate:

Unable to resolve user 'snowflake.user@example.com'
from the SAML assertion

You now know exactly which identity Snowflake received.

Special Consideration for Microsoft Entra B2B Guest Users

External/B2B Entra users require extra attention.

A guest user’s visible tenant UPN may look something like:

john_example.com#EXT#@datatoolsssodemo.onmicrosoft.com

However, the SAML assertion might actually send:

john@example.com

If you create your Snowflake user with the #EXT# identity while the SAML assertion contains john@example.com, Snowflake won’t be able to resolve the user.

Instead of guessing, use:

SELECT SYSTEM$GET_LOGIN_FAILURE_DETAILS(
    '<LOGIN_FAILURE_UUID>'
);

Then configure LOGIN_NAME to exactly match the identity Snowflake reports.

For example:

ALTER USER ENTRA_TEST_USER
SET LOGIN_NAME = 'john@example.com';

Retest SSO after making the change.

Final Validation

Once everything is configured correctly, your authentication flow should be:

1. User opens the Snowflake account URL.

2. User selects Microsoft Entra SSO.

3. Snowflake redirects the browser to Microsoft Entra.

4. Microsoft authenticates the user.

5. Entra generates a signed SAML response.

6. The browser sends the SAML response to Snowflake’s ACS endpoint.

7. Snowflake validates the certificate.

8. Snowflake extracts the user identity from the SAML assertion.

9. Snowflake matches that identity against the user’s LOGIN_NAME.

10. The user successfully accesses Snowflake.

Key Lessons

There are three particularly important lessons from implementing Snowflake SSO with Microsoft Entra ID.

1. Entra and Snowflake permissions are separate

Snowflake ACCOUNTADMIN doesn’t give you Microsoft Entra administrator privileges. Confirm both sides before starting an implementation.

2. Certificate formatting matters

Snowflake needs the complete Base64 certificate body without the BEGIN/END markers or line breaks. A mismatched or malformed certificate can cause SAML validation errors.

3. Don’t guess the SAML user identity

This is particularly important with B2B guest accounts.

If Snowflake can’t find the user, retrieve the login failure details:

SELECT SYSTEM$GET_LOGIN_FAILURE_DETAILS(
    '<UUID_FROM_SNOWFLAKE_ERROR_PAGE>'
);

Use the identity Snowflake actually receives from the SAML assertion when configuring the user’s LOGIN_NAME.

Conclusion

Microsoft Entra ID and Snowflake SAML SSO is relatively straightforward once the relationship between the two systems is clear.

Most of the configuration happens in four areas:

Microsoft Entra Enterprise Application → SAML configuration → Snowflake Security Integration → Snowflake User Mapping

The parts most likely to cause trouble are certificate configuration and identity mapping.

A disciplined implementation process, using a test tenant, maintaining fallback administrative access, testing in a private browser session, and using Snowflake’s login failure diagnostics, makes these issues much easier to identify and resolve.

How to Configure Snowflake SSO with Microsoft Entra ID using SAML

What We’ll Build

Step 1: Create a Microsoft Entra Test Tenant

Why use a separate tenant?

Step 2: Switch to the New Entra Tenant

Step 3: Add Snowflake as an Enterprise Application

Important Permission Note

Step 4: Configure SAML Single Sign-On

Identifier / Entity ID

Reply URL / ACS URL

Sign-on URL

Logout URL

Step 5: Download the Microsoft Entra SAML Certificate

Step 6: Prepare the Certificate Correctly

Step 7: Create the Snowflake SAML Security Integration

Step 8: Assign a User to the Snowflake Application

Step 9: Check the SAML User Identity

Step 10: Test the SSO Flow

Troubleshooting: HTTP 400 / Invalid SAML Certificate

Fix

Troubleshooting: “Matching User Is Not Found”

Special Consideration for Microsoft Entra B2B Guest Users

Final Validation

Key Lessons

1. Entra and Snowflake permissions are separate

2. Certificate formatting matters

3. Don’t guess the SAML user identity

Conclusion

Related Tutorials

Sign Up for Updates

Need quick help?

Recent Blog Posts