Share via

How can I map Custom Security Attributes on a user in Entra to an external attribute in Snowflake via SCIM user provisioning?

Ben Levy 20 Reputation points
2026-05-05T00:43:13.6+00:00

My overall goal is to have a single user attribute in Entra that can both be used for dynamic groups and also mapped to a tag when provisioning users in Snowflake. What I'm currently trying to use is a CSA, but I'm not sure how to access its value in my snowflake provisioning app. Can this be done? and if not, is there an alternative way to achieve the same end?

Microsoft Security | Microsoft Entra | Microsoft Entra ID

Answer accepted by question author

Shubham Sharma 15,865 Reputation points Microsoft External Staff Moderator
2026-05-05T01:15:37.4566667+00:00

Hey Ben, it looks like you want to use one attribute in Entra both for dynamic groups and for SCIM‐provisioning into Snowflake as a “tag.” You’ve tried defining a Custom Security Attribute (CSA), but you don’t see it in the Snowflake SCIM app’s attribute‐mapping UI—and today, that’s expected behavior. Right now the built-in provisioning engine only surfaces:

• Azure AD built-in user properties (displayName, mail, jobTitle, etc.)

• Directory extension (schemaExtension) properties

• Azure AD Connect extensionProperties (when using hybrid)

Custom Security Attributes (CSAs) aren’t yet exposed as a “Source attribute” for outbound SCIM mappings.

What you can do instead

  1. Create a directory‐extension attribute (a schemaExtension) on your users – You can register it via Microsoft Graph or via Azure AD Connect’s directory extension feature. – Set its value however you like (PowerShell, Graph, sync from on-prem, etc.). – You can use that extension attribute in dynamic group rules just like a CSA.
  2. In your Snowflake enterprise‐app provisioning settings – Go to Azure AD → Enterprise apps → Snowflake → Provisioning → Mappings → Users – Click “Show advanced options” and then “Edit attribute list” – Add a SCIM extension namespace (for example, urn:ietf:params:scim:schemas:extension:Custom:2.0:User:YourTag) – Back in the user‐attribute mapping UI, map your directoryExtension_[yourAppId]_[propName] source to that new SCIM path

That way you have one single attribute in Azure AD that:

• Drives your dynamic group membership

• Is visible in the provisioning mapping UI

• Flows into Snowflake as the tag you need

Reference links

• Customize user‐provisioning attribute mappings (SCIM apps)

https://docs.microsoft.com/azure/active-directory/manage-apps/customize-application-attributes

• Register and use directory‐extension attributes in Azure AD Connect

https://docs.microsoft.com/azure/active-directory/app-provisioning/user-provisioning-sync-attributes-for-mapping#create-an-extension-attribute-using-azure-ad-connect

• Tutorial: Provision custom extension attributes to a SCIM app

https://docs.microsoft.com/entra/identity/app-provisioning/customize-application-attributes?wt.mc_id=knowledgesearch_inproduct_azure-cxp-community-insider#editing-the-list-of-supported-attributes

Let me know if you have questions on any of those steps!

Was this answer helpful?

1 person found this answer helpful.

1 additional answer

Sort by: Most helpful
Most helpful Newest Oldest

  1. AI answer

    2026-05-05T00:43:27.7133333+00:00

    Custom security attributes (CSAs) can be used in dynamic group rules and can also be flowed through SCIM-based provisioning, but they are exposed via a specific SCIM extension namespace and must be explicitly mapped in the Snowflake provisioning app.

    To achieve the goal (one attribute in Entra used for both dynamic groups and Snowflake tags), use a CSA and then surface it in the Snowflake SCIM app as a custom attribute mapping.

    1. Use the CSA directly in Entra for dynamic groups

    Once a custom security attribute set and attributes are defined (for example, attribute set HRConfidentialData with attributes like PayGrade, EmployeeLevel, etc.), they can be referenced in dynamic group rules. This satisfies the “dynamic groups” part of the requirement and is already supported.

    2. Understand how CSAs appear in SCIM

    For provisioning scenarios, CSAs are carried in SCIM payloads under the extension namespace:

    urn:ietf:params:scim:schemas:extension:microsoft:entra:csa

    The sample SCIM bulk payload in the documentation shows custom fields under this extension that can be mapped to custom security attributes.

    In inbound scenarios, the mapping table looks like this (example):

    • urn:ietf:params:scim:schemas:extension:microsoft:entra:csa:PayGrade → CustomSecurityAttributes.HRConfidentialData_PayGrade

    This same pattern applies in reverse for outbound provisioning: the CSA is represented by a SCIM attribute with the …:csa: prefix, and the provisioning app can map that SCIM attribute to a target app attribute.

    3. Map the CSA into the Snowflake SCIM app

    In the Snowflake enterprise application’s Provisioning → Attribute mappings (Users), add a new mapping that exposes the CSA as a source attribute and maps it to a Snowflake custom extension attribute:

    1. In Entra admin center, open Enterprise applications → Snowflake app → Provisioning.
    2. Open Attribute mappings for Users.
    3. Select Add new mapping.
    4. In the source attribute list, select the CSA in the CustomSecurityAttributes.<AttributeSetName>_<AttributeName> form (for example, CustomSecurityAttributes.HRConfidentialData_PayGrade).
    5. In the target attribute, choose or define the Snowflake SCIM custom attribute that should receive this value (for example, a Snowflake custom extension attribute used as a tag or role indicator, following the pattern used for Snowflake’s custom SCIM attributes like DEFAULT_ROLE, DEFAULT_WAREHOUSE, etc.).
    6. Save the mapping.

    This causes Entra provisioning to read the CSA from the user object and send it to Snowflake in the SCIM payload, where Snowflake can interpret it as a tag or other metadata.

    4. Alternative if CSA cannot be used directly

    If the Snowflake app schema editor does not expose CSAs as selectable source attributes, use an intermediate Entra attribute that is supported as a source in the Snowflake app and mirror the CSA value into it via inbound provisioning or other processes. For example:

    • Map the SCIM extension attribute (for inbound HR → Entra) to both:
      • CustomSecurityAttributes.<Set>_<Name> (for dynamic groups), and
      • A standard or extension attribute (for example, extensionAttribute1) that is then mapped in the Snowflake app.

    The documentation shows this pattern for custom attributes:

    • A SCIM extension attribute like urn:ietf:params:scim:schemas:extension:contoso:1.0:User:HireDate is mapped to employeeHireDate.
    • Another extension attribute is combined into jobTitle using an expression.

    The same approach can be used to ensure the same logical value is available both as a CSA (for dynamic groups) and as a “regular” attribute that the Snowflake provisioning app can map.

    5. Summary

    • Yes, the scenario is supported: a single logical value can be used both as a CSA (for dynamic groups) and as a SCIM-mapped attribute to Snowflake.
    • Prefer mapping the CSA directly in the Snowflake provisioning app if it appears in the CustomSecurityAttributes.<Set>_<Name> list.
    • If it does not appear, mirror the CSA value into another Entra attribute that is supported as a source for the Snowflake app and map that attribute to a Snowflake custom SCIM attribute used as a tag.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.