# Azure User Account Filtering **URL:** \ **Category:** Administration & Troubleshooting\ **Tags:** microsoft-azure-active-directory, identity-security-cloud\ **Created:** [October 19, 2026, 7:13pm UTC](https://community.sailpoint.com/discuss/t/azure-user-account-filtering/59709 "2026-10-19T19:13:48Z")\ **Posts on this page:** 1\ **Page:** 1
**Author:** ![jbeeson](https://sea3.discourse-cdn.com/sailpoint2/discuss/user_avatar/community.sailpoint.com/jbeeson/32/17591_2.png) [@jbeeson](https://community.sailpoint.com/discuss/u/jbeeson)\ **Post date:** [October 19, 2026, 7:13pm UTC](https://community.sailpoint.com/discuss/t/azure-user-account-filtering/59709/1 "2026-10-19T19:13:48Z")
Yes. I’d tighten Option 1 so it reads like a real practitioner asking for a supported design, rather than a long list of questions. I’d also keep the focus on **account segregation first, PIM second** , since the filtering architecture is the piece you need help validating. ## Suggested Title **Best Practice for Filtering Privileged Accounts into a Separate Azure Source for PIM Management** ### 1. What are you trying to do or solve? We are using **SailPoint Identity Security Cloud (ISC)** with an **Azure / Microsoft Entra ID source** and would like to separate our **privileged accounts** from our standard user accounts. Our goal is to configure two Azure sources against the same Microsoft Entra tenant: - **Existing Azure Source:** Continue aggregating and managing our standard user accounts while excluding privileged accounts. - **New Privileged Azure Source:** Aggregate only privileged accounts so they can be managed separately, with the longer-term goal of using the Azure connector for **Microsoft Entra Privileged Identity Management (PIM)**. Conceptually, we are looking to achieve: Existing Azure Source ``` Standard Accounts EXCLUDE -> Privileged Accounts ``` Privileged Azure Source ``` INCLUDE -> Privileged Accounts Only USE -> PIM Management ``` I am looking for guidance on the **recommended and supported approach for creating mutually exclusive account filters between the two sources** , particularly since both sources will connect to the same Entra tenant. The SailPoint documentation indicates that **User Filters** can define the scope of accounts during aggregation. It also documents support for advanced filtering, including operators such as `NOT` and `NE`, when Advanced User Filter functionality is used. [[documentat…lpoint.com]](https://documentation.sailpoint.com/connectors/microsoft/entra_id/help/integrating_entra_id/aggregation_settings.html) Before making this change to our existing production source, I would like to better understand the recommended architecture and any potential concerns. Specifically: - What is the recommended method for separating privileged and standard accounts between two Azure sources? - Is there a preferred Entra attribute to use for this type of filtering, such as UPN, an extension attribute, or another account attribute? - Can we configure an **exclusion filter** on our existing source and the corresponding **inclusion filter** on the privileged source to ensure the two populations remain mutually exclusive? - Are there considerations around **aggregation, Delta Aggregation, correlation, or provisioning** when two Azure sources connect to the same tenant? - Are there any potential issues if an account unintentionally meets the filters on both sources? - For organizations using the Azure connector to manage **PIM** , is separating privileged accounts into a dedicated Azure source the recommended approach? The main objective is to make sure we establish the correct source architecture before moving the privileged-account population out of our existing Azure source. ### 2. What have you already tried or configured? Our existing Azure source is currently operational and aggregating accounts from our Microsoft Entra tenant. I have reviewed the SailPoint documentation for **Aggregation and Filter Settings** , specifically the use of **User Filters** to control the scope of accounts included during account aggregation. SailPoint provides examples such as: accountEnabled eq true The documentation also indicates that Advanced User Filters can be used for advanced queries such as `NOT` and `NE`. [[documentat…lpoint.com]](https://documentation.sailpoint.com/connectors/microsoft/entra_id/help/integrating_entra_id/aggregation_settings.html) We have a consistent method for identifying our privileged-account population. The primary question is therefore not how to identify the accounts, but rather **how SailPoint recommends structuring the filtering between the two sources**. Ideally, we want a configuration similar to: Source 1: Standard Accounts Filter = Everything except Privileged Accounts Source 2: Privileged Accounts Filter = Privileged Accounts only Before modifying our production source, I would like to validate that this is a supported design and understand whether there are any considerations related to having two Azure sources targeting different account populations within the same Entra tenant. If anyone has implemented a similar model, particularly for managing **privileged accounts or PIM through SailPoint** , I would be very interested in hearing how you structured the account filters and any lessons learned. ### 3. Environment Details - **Product:** SailPoint Identity Security Cloud (ISC) - **Source / Connector:** Azure / Microsoft Entra ID - **Microsoft Environment:** Single Microsoft Entra tenant - **Current Configuration:** Existing Azure source managing standard and privileged accounts - **Proposed Configuration:** Separate Azure sources for standard and privileged accounts - **Primary Objective:** Isolate privileged accounts into a dedicated Azure source - **Long-Term Objective:** Manage PIM-related access through the dedicated privileged-account source Any guidance, recommended filter examples, architecture recommendations, or lessons learned from implementing a similar configuration would be greatly appreciated.