As a hands-on practice area lead, I get to deliver projects both directly as an architect, and indirectly as an Engagement Manger. In one recent project, one of my Higher Ed clients wanted to setup attribute-based filtering. The matter got escalated to me and I helped the client in setting this up. I documented the process to my client and thought there may be others who may find this helpful as well.
In this article I will not be going into what AADConnect is and how to deploy the same. I will assume that you already know about AADConnect and possibly have deployed the same as well.
One of the features of AADConnect is the ability to filter objects that are synched to Azure AD. The default and the recommended configuration are to sync all objects in all domains in the configured forest. There are cases, however, that requires us to filter the objects to be synched. AADConnect provides the following filtering options: Group-based, Domain-based, OU-based, and Attribute-based. It is possible to use multiple filtering options at the same time. For more information, check out: https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-sync-configure-filtering. Rest of this article will focus on Attribute based filtering, where, I am mostly documenting the steps to go about configuring attribute -based filtering. However, what I found during my interaction with the client, that giving a brief background about the architecture helped to ease the transition. So I start with a synopsis of the architecture below, I highly recommend you to dig deeper with: https://docs.microsoft.com/en-us/azure/active-directory/hybrid/concept-azure-ad-connect-sync-architecture
Connected Directories (CD): Data repositories that are synchronized by AADConenct. There is a source CD and a target CD. Target CD is always Azure AD. The source CD can be sources as SQL server, AD. Most often, source CD is the on-premises Active Directory (AD).
Connector: A module that encapsulates all interaction between CD and AADConnect. Each type of CD has its own Connector. If you have a custom CD, then it is possible to create a custom Connector, using extensible connectivity framework.
Metaverse: There is a Metaverse between the source CD and the target CD that contains the aggregated view of the staging objects. We make use of the available extensible schema to map the objects from the CDs to the objects in the Metaverse. While the handshake is slightly more complex, I found it easier to explain, as the objects from the source CD (on-premises AD), are “Imported” into the Metaverse and objects in the Metaverse, are “Exported” into the target CD (Azure AD).
During both import and export, the data from the source can be filtered, transformed, and computed values can be injected. Making changes during the export is not recommended, however.
The Import (Inbound) and Export (Outbound) itself is a process that takes the objects through pipeline of modules. The pipeline consists of: Source (On-premises AD in case of Import and Metaverse in case of Export), Scope module, Join module, Transform module, Precedence module, and Target (Metaverse in case of Import and Azure AD in case of Export).
Scope: Scope module evaluates an object and determines the rules that are in scope. Scope is defined in Groups and groups contain Clauses. There is a logical OR between the Groups and a logical AND between the Clauses.
Join: The Join module in the sync pipeline is responsible for finding the relationship between the object in the source and an object in the target. On Import, this would be an object in in the source (on-premises AD) and finding a relationship to an object in the metaverse.
The joins are defined as one or more groups. Inside a group, you have clauses. A logical AND is used between all clauses in a group. A logical OR is used between groups. The groups are processed in order from top to bottom. When one group has found exactly one match with an object in the target, then no other join rules are evaluated. If zero or more than one object is found, processing continues to the next group of rules. For this reason, the rules should be created in the order of most explicit first and fuzzier at the end.
Transform: The Transform module provided the ability to alter the value of an attribute or allow to go directly to the target. Flow types include: Direct (attribute value passed as is), Constant (inject a constant value), Expression (compute the value). Check out “understanding declarative provisioning expression language” for the details for the expression language.
Precedence: In case there are several rules that modifies the same attribute value in the target, the Precedence is used to resolve the conflict. The rule with the highest Precedence (lowest numerical value) will affect the attribute over all other rules.
With that as a short background, let us continue onto the configuration for the attribute-based filtering.
Configuring Attribute Based Filtering:
Attribute based filtering provides great control over which objects gets synched to Azure AD by filtering objects based on their attributes. This document walks through setting up such filtering, using AD extension attribute and msDS-cloudExtensionAttribute1.
NOTE: While attribute-based filtering gives great control, it can also cause unexpected results, as the rules could affect more than what it was intended for. Be careful while setting up AD synchronization and filtering based on the attribute.
NOTE: The following instruction walks through negative filtering, where all objects in scope will be synched, except for those that meet the rule criteria, and so are filtered out.
Positive filtering on the other hand, will sync only those objects that meet the criteria and filter out everything else. This could be more complex to create, and can have adverse effect on the synchronized objects, so positive filtering will not be discussed in this document.
The following steps will use msDS-cloudExtensionAttribute1 for filtering:
1. AD Updates:
Following needs to be in AD before using the attribute for filtering. Skip if any of these has already been completed. (The AD Updates instruction can also be skipped if one of the well-known attributes, as department, is used for filtering).
a. Mounting AD Schema
Launch a Command Prompt window as an administrator and run the following:
RegSvr32 schmmgmt.dll
You should get a prompt indicating the schema is mounted.
b. Creating / assigning custom attribute
Open MMC Console as an administrator.
File -> Add/Remove snap-in.
Add "Active Directory Schema" from the available snap-ins.
Select OK to complete the Add-In selection.
Select "Attributes" under "Active Directory Schema" and ensure that the msDS-cloudExtensionAttribute1 exists in the schema.
If the attribute does not exist, select “Add” and add the attribute to the schema.
c. Adding the attribute to the user object (and/or group/OU) class
Select Classes in the Add-In.
Scroll the right pane till "user" (or group, or organizationalUnit).
Double click to open the properties screen.
Ensure that the attribute msDS-cloudExtensionAttribute1 does not exist under the "Optional" box.
Select "Add" to open the schema object selector screen.
Select msDS-cloudExtensionAttribute1 and select "OK" button.
Select "Apply" and "OK" in the properties screen.
Repeat the above for other objects (group, ou etc.,) that you want to add the extended attribute.
d. Restarting AD Domain service
After all the attributes are added, restart the "Active Directory Domain Services".
e. Confirming changes
Confirm the changes by going to "Active Directory Users and Computers", selecting a user, and validating that the added attribute is displayed.
Tip: To display the "Attribute Editor" tab, select "Advanced Features" from the View menu.
f. Populate attribute value
You can use the editor or PowerShell to populate the attribute value.
Set the value to 1 for those objects that need to be synched, and 0 to those that should be filtered out.
2. Stop the Sync cycle
a. RDP into the server running AADConnect service.
b. Launch PowerShell as an administrator and disable the sync by running the following:
Set-ADSyncScheduler -SyncCycleEnabled $False
3. Azure AD Connect – attributes update
a. Launch "Azure AD Connect" as an administrator.
b. Select "Configure".
c. Select "Customization Options".
d. Provide Office 365 Global admin UID and PWD, and connect to Azure AD.
e. Select "Next" to skip "Connect your directories".
f. Select "Next" to skip "Domain and OU filtering".
g. Select "Directory extension attribute sync" and select "Next".
h. In "Directory extensions", under "Available Attributes", select the attributes created/added in AD and move them to the "Selected Attributes" section.
i. Select "Next" and complete the configuration. Note that it may take several minutes to complete the configuration.
4. Sync Connector updates:
a. Launch the "Synchronization Service".
b. Select the "connectors" tab.
c. Select the "AD Domain services” connector.
d. From the "Actions" select "Refresh Schema", provide UID/PWD, and update the schema.
e. Once “update schema” successfully completes, select "Properties" for the same connector.
f. “Select Attributes” and ensure that the attribute does show up for the connector (msDS-cloudExtensionAttribute1).
g. Select the attribute and "OK" to add the attribute to the connector.
h. The Extension Attributes should have been added by default for the "Windows Azure Active Directory" connector. Validate the same by selecting the connector and then selecting the properties, and attributes.
5. Creating the rules:
a. Launch "Synchronization Rules Editor".
b. Create the rule to filter the users:
i. Create a new rule with the following as the values:
Direction: Inbound
Name: In from AD - UserDoNotSyncFilter
Description: Filter users who have msds-CloudExtensionAttribute1 set to 0
Connected system: <Select the connector to local AD>
Connected system object type: user
Metaverse object type: person
Link type: Join
Precedence: 201
ii. Select "Next".
iii. For the "Scoping filter", select “Add Group” and "Add clause" and add the following:
Attribute: msDS-cloudExtensionAttribute1
Operator: EQUAL
Value: 0
iv. Select "Next".
v. Skip the "Join rules" by selecting "Next".
vi. For the “Transformations”, select "Add transformations" with the following values:
FlowType: Constant
Target Attribute: cloudFiltered
Source: True
Merge Type: Update
vii. Select Add/Save to complete the rule.
c. To create a rule to filter the group:
Follow the instructions for setting the "user" filtering as above with the following changes:
Connected system object type: group
Metaverse Object type: group
Precedence: 202
Complete rest of the configuration as above.
d. To create a rule to filter the OU:
Follow the instructions for setting the "user" filtering as above and select:
Connected system object type: organizationalUnit
Metaverse Object type: person
Precedence: 203
6. Run a full synchronization:
a. Back in the "Synchronization Service".
b. Select the connector to the "Active Directory Domain Services".
c. Select "Run" and select "Full Synchronization".
d. Select "OK".
e. When the synchronization is complete, there should not be any errors.
7. Start a sync to Azure AD (Only if there are no errors in the previous step):
a. From PowerShell command window, run the following command:
Start-ADSyncSyncCycle -PolicyType Initial
8. Validate the changes in Azure AD:
a. Once the synchronization is complete, the objects should be filtered out of Azure AD.
b. Validate the same in Azure AD Portal.
9. Turn on the synchronization cycle:
a. In the PowerShell window type and run the following:
Set-ADSyncScheduler -SyncCycleEnabled $True
A word of caution, that, in my case I had the benefit of working on a system that was not yet synchronized. That made it easier to run the full sync and check the Sync Service and Azure AD for the effectiveness of the rules that I put in. If you have an established AADConnect, you may want to be a little more careful and “Apply and Verify” the changes before you run the full sync as in step 6 above. To verify the changes, follow the steps below before doing #6 above.
1. Start “Synchronization Service” from the Start menu.
2. Select Connectors. In the Connectors list, select the Connector where you made a configuration change earlier. In Actions, select Run.
3. In Run profiles, select the operation that was mentioned in the previous section. If you need to run two actions, run the second after the first one has finished. (The State column is Idle for the selected connector.)
3. In Run profiles, select the operation that was mentioned in the previous section. If you need to run two actions, run the second after the first one has finished. (The State column is Idle for the selected connector.)
After the synchronization, all changes are staged to be exported. Before you actually make the changes in Azure AD, you want to verify that all these changes are correct.
1. Start a command prompt and go to %Program Files%\Microsoft Azure AD Sync\bin.
2. Run csexport "Name of Connector" %temp%\export.xml /f:x.
The name of the Connector is in Synchronization Service. It has a name similar to "contoso.com – AAD" for Azure AD.
3. Run CSExportAnalyzer %temp%\export.xml > %temp%\export.csv
4. You now have a file in %temp% named export.csv that can be examined in Microsoft Excel. This file contains all the changes that are about to be exported.
5. Make the necessary changes to the data or configuration, and run these steps again (Import, Synchronize, and Verify) until the changes that are about to be exported are what you expect.
When you're satisfied, export the changes to Azure AD.
1. Select Connectors. In the Connectors list, select the Azure AD Connector. In Actions, select Run.
2. In Run profiles, select Export.
3. If your configuration changes delete many objects, then you see an error in the export when the number is more than the configured threshold (by default 500). If you see this error, then you need to temporarily disable the "prevent accidental deletes" feature.
Comments
Post a Comment