Background

Before I go any further, there are a few things I want to lay out that will be important later. Refer to the following

This diagram is somewhat simplified but captures the key aspects that are important to this discussion -

1. Cloud applications and services have a relying-party trust with Azure Active Directory (Azure AD). This includes Azure subscriptions (the administration portal), Office 365 (O365) and other SaaS applications

2. When your Azure AD tenant is federated with on-premises AD FS, there is a relying-party trust (RPT) between your tenant and your AD FS farm. This relying-party trust is named "Microsoft Office 365 Identity Platform". This is sometimes confusing for folks because they think it means O365. It doesn't, it means that the Azure AD tenant trusts the authentication mechanisms of the AD FS farm. Furthermore, any authentication requirement that you apply to the "Microsoft Office 365 Identity Platform" RPT will be enforced for all applications and services that have an RPT with Azure AD (you authenticate against AD FS before you pass back via Azure AD to the application)

3. You may (or may not) have other claims-aware applications that have a relying-party trust directly with AD FS. Typically, these would be hosted on-premises or may be third-party applications that are not integrated with Azure AD

Using Azure MFA

Referring to the diagram, there are two places where Azure MFA may be enforced -

1. At Azure AD - preferably using Conditional Access (CA) Policy which you can read more about here - https://aka.ms/ConditionalAccessDeploymentPlan. CA allows you to configure different requirements for different applications and users. Requiring MFA is one of them. Taking this approach provides the most granular control

2. At AD FS. Taking this approach offers some granular control but generally speaking, you want to avoid using MFA against the "Microsoft Office 365 Identity Platform" RPT because enforcing it here, enforces it for all applications and services that are relying-parties to Azure AD. The real purpose of integrating Azure MFA with AD FS is to provide stronger authentication for your other AD FS relying-parties. To configure AD FS 2016 with Azure MFA, refer to https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/operations/configure-ad-fs-and-azure-mfa

For more guidance deploying Azure MFA, refer to the deployment plan here - https://aka.ms/MFADeploymentPlan

Azure MFA Proof Up

I'm finally ready to discuss the core point of this post.

When Azure MFA is enforced in the Azure AD tenant, either directly or via a Conditional Access Policy, users who have not yet signed up for Azure MFA (chosen their authentication options and provided their mobile phone number) are directed to https://account.activedirectory.windowsazure.com/Proofup.aspx where they can set this up. This is a requirement at the first sign-in whether CA or direct assignment (which is no longer recommended) is used.

When Azure MFA is enforced against an AD FS relying-party, this redirect does not take place automatically. The following customization needs to be made (I assume here that your AD FS deployment is using the Default ADFS Web Theme)

1. Open a PowerShell prompt on your Primary AD FS server and create a new AD FS Web Theme by executing
New-AdfsWebTheme –Name ProofUp –SourceName default
2. Export the default AD FS Web Theme by executing
Export-AdfsWebTheme –Name default –DirectoryPath c:\theme
3. Open the C:\Theme\script\onload.js file in a text editor
4. Append the following code to the end of the onload.js file

//Custom Code
//Customize MFA exception
//Begin

var domain_hint = "<YOUR_DOMAIN_NAME_HERE>";
var mfaSecondFactorErr = "The selected authentication method is not available for";
var mfaProofupMessage = "You will be automatically redirected in 5 seconds to set up your account for additional security verification. Once you have completed the setup, please return to the application you are attempting to access.<br><br>If you are not redirected automatically, please click <a href='{0}'>here</a>."
var authArea = document.getElementById("authArea");
if (authArea) {
    var errorMessage = document.getElementById("errorMessage");
    if (errorMessage.innerHTML.indexOf(mfaSecondFactorErr) >= 0) {

    //Hide the error message
        var openingMessage = document.getElementById("openingMessage");
        if (openingMessage) {
            openingMessage.style.display = 'none'
        }
        var errorDetailsLink = document.getElementById("errorDetailsLink");
        if (errorDetailsLink) {
            errorDetailsLink.style.display = 'none'
        }

        //Provide a message and redirect to Azure AD MFA Registration Url
        var mfaRegisterUrl = "https://account.activedirectory.windowsazure.com/proofup.aspx?proofup=1&whr=" + domain_hint;
        errorMessage.innerHTML = "<br>" + mfaProofupMessage.replace("{0}", mfaRegisterUrl);
        window.setTimeout(function () { window.location.href = mfaRegisterUrl; }, 5000);
    }
}

//End Customize MFA Exception
//End Custom Code

Note that you need to change "<YOUR_DOMAIN_NAME_HERE>"; to use your domain name. For example

var domain_hint = "contoso.com";

5. Save the onload.js file
6. Import the onload.js file into your custom theme by executing the following at the PowerShell prompt
Set-AdfsWebTheme -TargetName ProofUp -AdditionalFileResource @{Uri=’/adfs/portal/script/onload.js’;path="c:\theme\script\onload.js"}
7. Apply the custom AD FS Web Theme by executing
Set-AdfsWebConfig -ActiveThemeName

Following these steps, users who are required to use Azure MFA against an AD FS relying-party but who have not registered for Azure MFA will be redirected to the proof up page -

Redirect -

Proof Up -

IMPORTANT: If you have gone against the recommendation I made earlier - to avoid MFA on the "Microsoft Office 365 Identity Platform" relying-party trust, users will not be able to access the proof up page. This is because the proof up page is a relying-party to Azure AD and by requiring MFA on the "Microsoft Office 365 Identity Platform" relying-party trust, you create a chicken-and-egg scenario

I'm not sure how much this new role will lead to blog posts but if I have something worth sharing, you'll still find it here.

Group Policy ADMX versioning has caused a few concerns for Microsoft customers in the past one to two years. A great description of the issue and how to address it is found here.

Recently, one of my customers wanted to identify the ADMX files referenced by Group Policies deployed in their domain so that they could carefully update the ADMX/ADML central store in SYSVOL. This isn't entirely easy because the ADMX file is not used when the GPO is applied to a computer or user.

Further Explanation

The ADMX/ADML file combination may be thought of as the description language that instructs the Group Policy editor. The Group Policy editor shows the policy settings, policy descriptions, drop down boxes and radio buttons that the ADMX/ADML files tell it to. Configuring a policy setting results in the Group Policy editor making changes to a .pol (or other) file in SYSVOL that is ultimately applied to the computer or user.

When you generate a Group Policy report, all of the ADMX and ADML files are read and compared with the policy settings stored in SYSVOL. This information is then glued together by the report generator and output as either HTML or XML. No record of the ADML/ADML files required for the report is kept.

The Solution

I managed to construct a PowerShell script that consumes an XML-based GPO Report, parses out all of the settings, reads the ADML store specified in the script and matches settings to ADMLs. ADML file names correspond to ADMX file names used by the Group Policy editor. The output is a CSV (also specified in the script) that looks similar to -

The script assumes a language match between the GPO Report and the ADML file path provided in the script and has a dependency on the Group Policy PowerShell module.

If you wish to use the following code, redefine <OUTPUT_PATH> and <FULLY_QUALIFIED_DOMAIN_NAME> according to your own environment (I know I could have parameterised this but I'm lazy and this is just a sample).

Also note that something whacky is going on with the source code plugin colour formatting below. I can't work it out but the script still works …

The Script

# Define results file
$results = "<OUTPUT PATH>\Results.csv"

# Define PolicyDefinition ADML Folder
$policyDefs = "\\<FULLY_QUALIFIED_DOMAIN_NAME>\SYSVOL\<FULLY_QUALIFIED_DOMAIN_NAME>\Policies\PolicyDefinitions\en-US"

# Generate a GPO report and capture it as XML
[xml]$GPOs = Get-GPOReport -All -ReportType Xml

# Parse captured XML
$policyInfo = @()

for ($i = 0; $i -lt ($GPOs.DocumentElement.GPO.Count); $i++)
{ 
    #Process Computer Policy
    for ($j = 0; $j -lt $GPOs.DocumentElement.GPO[$i].Computer.ExtensionData.ChildNodes.Count; $j++)
    { 
        if (($GPOs.DocumentElement.GPO[$i].Computer.ExtensionData.ChildNodes[$j].type) -like "*:RegistrySettings")
        {
            if (!($GPOs.DocumentElement.GPO[$i].Computer.ExtensionData.ChildNodes[$j].Policy.Count -eq $null))
            {
                for ($k = 0; $k -lt $GPOs.DocumentElement.GPO[$i].Computer.ExtensionData.ChildNodes[$j].Policy.Count; $k++)
                { 
                    $polInfo = "" | Select-Object gpoName, settingScope, settingName
                    $polInfo.gpoName = $GPOs.DocumentElement.GPO[$i].Name
                    $polInfo.settingScope = "Computer"
                    $polInfo.settingName = $GPOs.DocumentElement.GPO[$i].Computer.ExtensionData.ChildNodes[$j].Policy[$k].Name
                    $policyInfo += $polInfo
                }
            }
            else
            {
                $polInfo = "" | Select-Object gpoName, settingScope, settingName
                $polInfo.gpoName = $GPOs.DocumentElement.GPO[$i].Name
                $polInfo.settingScope = "Computer"
                $polInfo.settingName = $GPOs.DocumentElement.GPO[$i].Computer.ExtensionData.ChildNodes[$j].Policy.Name
                $policyInfo += $polInfo
            }
        }
    }
    #Process User Policy
    for ($j = 0; $j -lt $GPOs.DocumentElement.GPO[$i].User.ExtensionData.ChildNodes.Count; $j++)
    { 
        if (($GPOs.DocumentElement.GPO[$i].User.ExtensionData.ChildNodes[$j].type) -like "*:RegistrySettings")
        {
            if (!($GPOs.DocumentElement.GPO[$i].User.ExtensionData.ChildNodes[$j].Policy.Count -eq $null))
            {
                for ($k = 0; $k -lt $GPOs.DocumentElement.GPO[$i].User.ExtensionData.ChildNodes[$j].Policy.Count; $k++)
                { 
                    $polInfo = "" | Select-Object gpoName, settingScope, settingName
                    $polInfo.gpoName = $GPOs.DocumentElement.GPO[$i].Name
                    $polInfo.settingScope = "User"
                    $polInfo.settingName = $GPOs.DocumentElement.GPO[$i].User.ExtensionData.ChildNodes[$j].Policy[$k].Name
                    $policyInfo += $polInfo
                }
            }
            else
            {
                $polInfo = "" | Select-Object gpoName, settingScope, settingName
                $polInfo.gpoName = $GPOs.DocumentElement.GPO[$i].Name
                $polInfo.settingScope = "User"
                $polInfo.settingName = $GPOs.DocumentElement.GPO[$i].User.ExtensionData.ChildNodes[$j].Policy.Name
                $policyInfo += $polInfo
            }
        }
    }
}

# Define output array
$admlFileUsage = @()

# Search ADML files for policy settings
$admlFiles = Get-ChildItem -Path $policyDefs -Filter *.adml

foreach ($admlFile in $admlFiles)
{
    $admlContent = (Get-Content -Path ($admlFile.FullName))
    $out = "" | Select-Object gpoName, settingScope, settingName, admlFile
    foreach ($polInfo in $policyInfo)
    {
        $settingName = $polInfo.settingName
        if ($admlContent -like "*$settingName*")
        {
            $out.gpoName = $polInfo.gpoName
            $out.settingScope = $polInfo.settingScope
            $out.settingName = $polInfo.settingName
            $out.admlFile = $admlFile.Name
            $admlFileUsage += $out
        }
    }
}

$admlFileUsage | Export-Csv -Path $results -NoTypeInformation -Force

Conclusion

I hope that this script serves as a useful example for others to build upon. As I've only used this script in a test lab with a small number of Group Policy objects, it's entirely possible I've overlooked something. If you identify a problem or see room for improvement, I'd be happy to take the feedback.

If you run an isolated lab in Azure IaaS with more than one Domain Controller and are in the habit of shutting down and de-allocating the VMs to save money, you may have found that SYSVOL doesn’t replicate when you start them back up.

The Cause

De-allocation/re-allocation of a VM changes the VM generation ID and Active Directory forces a safe recovery on restart. The problem with safe recovery in an isolated Azure IaaS lab is that no DC is authoritative.

The Solution

A manual authoritative restore of DFSR SYSVOL is required using steps outlined in KB2218556.

The Whinge

I’m fed up with doing this so wrote a PowerShell script

The Script

# Get the list of all DCs in the local domain
$domainControllers = Get-ADDomainController -Filter *

# Use the first DC in the list as the primary member for DFSR
# If a specific DC is preferred, use Get-ADDomainController -Identity <DC_Hostname>
$primaryDC = $domainControllers[0]

# Stop DFSR on all DCs
foreach ($dc in $domainControllers)
{
    Invoke-Command -ComputerName $dc.HostName -ScriptBlock {Stop-Service DFSR}
}

# Modify DFSR subscription object to disable the SYSVOL replica in AD and replicate it
foreach ($dc in $domainControllers)
{
    $sysvolSubscriptionObject = "CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings," + $dc.ComputerObjectDN
    Get-ADObject -Identity $sysvolSubscriptionObject | Set-ADObject -Server $primaryDC -Replace @{"msDFSR-Enabled"=$false}
    Get-ADDomainController -filter * | foreach {Sync-ADObject -Object $sysvolSubscriptionObject -Source $primaryDC -Destination $_.hostname}
}

# Start and then stop DFSR on all DCs
foreach ($dc in $domainControllers)
{
    Invoke-Command -ComputerName $dc.HostName -ScriptBlock {Start-Service DFSR}
    Start-Sleep -Seconds 20
    Invoke-Command -ComputerName $dc.HostName -ScriptBlock {Stop-Service DFSR}
}

# Modify DFSR subscription to enable the SYSVOL replica in AD and set the primary
# Force replication of these changes
$sysvolSubscriptionObject = "CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings," + $primaryDC.ComputerObjectDN
Get-ADObject -Identity $sysvolSubscriptionObject | Set-ADObject -Server $primaryDC -Replace @{"msDFSR-Options"=1}

foreach ($dc in $domainControllers)
{
    $sysvolSubscriptionObject = "CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings," + $dc.ComputerObjectDN
    Get-ADObject -Identity $sysvolSubscriptionObject | Set-ADObject -Server $primaryDC -Replace @{"msDFSR-Enabled"=$true}
    Get-ADDomainController -filter * | foreach {Sync-ADObject -Object $sysvolSubscriptionObject -Source $primaryDC -Destination $_.hostname}
}

# Start DFSR on all DCs
foreach ($dc in $domainControllers)
{
    Invoke-Command -ComputerName $dc.HostName -ScriptBlock {Start-Service DFSR}
}

The Warning

I’d caution against setting this as a scheduled task or anything too creative. You really do want all DCs booted and running before you do this

The Conclusion

Hopefully it’s useful to some]]> https://docs.microsoft.com/archive/blogs/markrenoden/choosing-a-sourceanchor-for-groups-in-multi-forest-sync-with-aad-connect Fri, 13 Oct 2017 10:07:04 GMT https://blogs.technet.microsoft.com/markrenoden/?p=2275 Introduction

Earlier this year I authored a post discussing choices for sourceAnchor in Multi-Forest Sync with AAD Connect. Following that series, the Azure Active Directory Product Group included sync rules that use mS-DS-ConsistencyGuid as the sourceAnchor for user objects. This was great because it all works out of the box and as an added bonus, there's an action that migrates you from objectGUID to mS-DS-ConsistencyGuid built into the AAD Connect wizard.

Recently, I was working with a customer who was migrating between Forests. These latest changes work terrifically well for user objects but on the current build of AAD Connect (1.1.614.0), the sync rules for Groups do not use mS-DS-ConsistencyGuid. This means, that for groups, you're right back at square one (refer to the earlier series Introduction for background information).

In this post, I'll walk through the setup for custom sync rules so that groups migrate cleanly between Forests and continue to sync with Azure Active Directory without duplication.

Preparation

Pause the sync service by opening a PowerShell prompt and executing

Set-ADSyncScheduler -SchedulerSuspended $true

Open "C:\Program Files\Microsoft Azure AD Sync\UIShell\SyncRulesEditor.exe"

Observe the lowest precedence built-in inbound sync rule (100 in this example) –

Observe the built-in inbound sync rules for Groups, two of each type for each Forest (4 in this example) –

You’ll need to duplicate each of these rules and modify the properties. You’ll set the precedence of the duplicated rules to be lower than the lowest value observed (100 in this example)

Creating Custom Join Rules for Groups

Select the first In from AD -Group Join rule and click Edit

Click Yes at the Edit Reserved Rule Confirmation

Change Description to something like In from AD – Group Join Custom, the Precedence to 4 less than the number observed earlier (96 in this example) and click Next twice –

On the Join Rules page, change the Source attribute to mS-DS-ConsistencyGuid

Click Add group and in the new group, set Source attribute to objectGUID and Target attribute to sourceAnchorBinary

Click Next –

Click Save

Click Yes at the Expression Warning

Repeat for additional In from AD -Group Join rules, this time setting the precedence to one more than last time (97 in this example)

Creating Custom Common Rules for Groups

Select the first In from AD - Group Common rule and click Edit

Click Yes at the Edit Reserved Rule Confirmation

Change Description to something like In from AD – Group Common Custom, the Precedence to one more than the last rule (98 in this example) and click Next three times –

On the Transformations page,

Change sourceAnchor from

ConvertToBase64([objectGUID])

To

IIF(IsPresent([mS-DS-ConsistencyGuid]),ConvertToBase64([mS-DS-ConsistencyGuid]),ConvertToBase64([objectGUID]))

Change sourceAnchorBinary from Direct

[objectGUID]

To an Expression

IIF(IsPresent([mS-DS-ConsistencyGuid]),[mS-DS-ConsistencyGuid],[objectGUID])

Click Save

Repeat for additional In from AD -Group Common rules, this time setting the precedence to one more than last time (99 in this example)

Create Rules to Write mS-DS-ConsistencyGuid back to AD On-Premises

Change rule editor to show outbound rules and take note of the highest precedence rule (170 in this example) –

Click Add new rule

On the Description page, set the Name to Out to AD - mS-DS-ConsistencyGuid

On the Description page, set Connected System to the <Forest you're currently configuring the rule for>

On the Description page, set Connected System Object Type to group

On the Description page, set Metaverse Object Type to group

On the Description page, set the Precedence to a value higher than the precedence noted above (171 in this example) –

Click Next

On the Scoping filter page, click Add group and then Add clause and set the filter to cloudSourceAnchor ISNOTNULL –

Click Next

On the Join rules page, click Add group

Set the Source attribute to sourceAnchorBinary and the Target attribute to mS-DS-ConsistencyGuid

Click Add group again

In the second group, set Source attribute to sourceAnchorBinary and Target attribute to objectGUID –

Click Next

On the Transformations page, click Add transformation. Set the Flow type to Expression, the Target attribute to mS-DS-ConsistencyGuid and the Expression to

IIF(IsPresent([sourceAnchorBinary]),[sourceAnchorBinary],IgnoreThisFlow)

Click Add

Back at the outbound rules editor, click Add Rule and repeat for each additional Forest, setting the precedence to the next number (172 in this example)

Re-establish Sync

Resume the sync service by opening a PowerShell prompt and executing

Set-ADSyncScheduler -SchedulerSuspended $false

Trigger a full sync by executing

Start-ADSyncSyncCycle -PolicyType Initial

Conclusion

This blog post steps through the configuration of sync rules in AAD Connect that use mS-DS-ConsistencyGuid as the sourceAnchor for groups when they are synchronised from on-premises Forests to an Azure Active Directory tenant.

This approach, aligns with the built-in sync rules used for user objects.

]]> https://docs.microsoft.com/archive/blogs/markrenoden/an-alternative-for-dfsr-database-guid-to-name-resolution Wed, 03 May 2017 10:41:20 GMT https://blogs.technet.microsoft.com/markrenoden/?p=2125 Recently I was connected to a support incident where a SYSVOL DFS Replication storm was causing trouble for a customer. Using the DFSR debug logs, the Microsoft support teams were able to identify that one file was being changed over and over again. The log entries were similar to -

+	fid                             0x5000000019841
+	usn                             0x10a7a560
+	uidVisible                      1
+	filtered                        0
+	journalWrapped                  0
+	slowRecoverCheck                0
+	pendingTombstone                0
+	internalUpdate                  0
+	dirtyShutdownMismatch           0
+	meetInstallUpdate               1
+	meetReanimated                  0
+	recUpdateTime                   16010101 00:00:00.000 GMT
+	present                         1
+	nameConflict                    0
+	attributes                      0x10
+	ghostedHeader                   0
+	data                            0
+	gvsn                            {A7088668-9068-4D1F-BEA5-520C67C94967}-v53
+	uid                             {A7088668-9068-4D1F-BEA5-520C67C94967}-v53
+	parent                          {A7088668-9068-4D1F-BEA5-520C67C94967}-v44
+	fence                           Default (3)
+	clockDecrementedInDirtyShutdown 0
+	clock                           20170503 00:17:08.328 GMT (0x1d2c3a29a04c7b7)
+	createTime                      20170503 00:17:08.328 GMT
+	csId                            {9A829445-BA96-4EDB-9033-D08C3D6B308A}
+	hash                            E5C76297-69747039-B2E8590E-FE3AB33E
+	similarity                      00000000-00000000-00000000-00000000
+	name                            SomeFolder

The standard approach for identifying the server on which the change originated is to extract the GUID from the gvsn (A7088668-9068-4D1F-BEA5-520C67C94967 in this case) and to use DfsrDiag.exe with its guid2name command -

C:\Windows\debug>DfsrDiag.exe guid2name /guid:A7088668-9068-4D1F-BEA5-520C67C94967 /rgname:"Domain System Volume"

   Object Type : DfsrVolumeInfo
   Computer    : DC01.contoso.com
   Volume Guid : 37B3C300-0000-0000-0000-100000000000
   Volume Path : C:
   Volume SN   : 2864180062
   DB Guid     : A7088668-9068-4D1F-BEA5-520C67C94967

This is great except that for my customer, their environment has around 90 read-write DCs in a hub site with over 2000 read-only DCs in spoke sites. This DfsrDiag.exe command walks across every DC and in the heat of a high priority incident, this takes too long. All we really want to do is retrieve the DFSR database GUIDs from the 90 read-write DCs as these are the only servers where change could originate.

As it turns out, the DFSR database GUIDs are available via the DfsrVolumeInfo class. In response to the problem my customer was experiencing, I've written the following PowerShell script that retrieves a list of read-write DCs in the domain and then iterates over them to retrieve the DFSR database GUIDs on each server -

#Retrieve the list of read-write DCs
$rwDCs = (Get-ADDomain).ReplicaDirectoryServers

#Initialize the results array
$results = @()

#Iterate through the list of read-write DCs
foreach ($DC in $rwDCs)
{
    #Retrieve Dfsr Volume Information
    $volumes = $null
    $volumes = Get-WmiObject -Namespace "Root\MicrosoftDfs" -Class DfsrVolumeInfo -ComputerName $DC -ErrorAction SilentlyContinue

    #Extract the DC name and the Dfsr Db GUID for each Dfsr Volume
    #Add this information to the results array
    if ($volumes)
    {
        foreach ($volume in $volumes)
        {
            $result = "" | Select-Object DC,dbGUID
            $result.DC = $DC
            $result.dbGUID = $volume.DatabaseGuid
            $results += $result
        }
    }
}

#If the results array is populated, write it out to CSV 'dfsrDbGuids.csv'
if ($results)
{
    $results | Export-Csv -Path .\dfsrDbGuids.csv -NoTypeInformation
}

The output is a CSV with a name to GUID mapping.

You could very easily change this script to accept a list of servers as a parameter for scenarios where you're dealing with a replication group other than the SYSVOL replica.

This blog post series is based upon and tested with AAD Connect, December 2016 release, version 1.1.380.0. Test all deployment designs before production implementation.

Table of Contents

Part 1, Introduction

Part 2, Lab Setup

Part 3, An Aside on EmployeeID

Part 4, Using msDS-SourceAnchor

Part 5, Using mS-DS-ConsistencyGuid

Part 6, Moving off objectGuid

Part 7, Migrating Users

Changing Issuance Transform Rules for O365

If your Azure Active Directory tenant is federated with an on-premises federation service (AD FS for example), you'll need to make one last configuration change before you migrate users. This final step is to ensure your O365 Relying Party Trust Issuance Transform Rule for ImmutableID uses the attribute you've chosen (msDS-SourceAnchor or mS-DS-ConsistencyGuid) instead of objectGuid.

I'll provide an example using AD FS on Windows Server 2016 -

Open the AD FS Management console

In the left-hand pane, select Relying Party Trusts

In the central pane, right-click Microsoft Office 365 Identity Platform and select Edit Claim Issuance Policy

Edit the transform rule replacing objectguid with msds-sourceanchor or ms-ds-consistencyguid depending on the attribute you're using -

c:[Type == "https://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"]
 => issue(store = "Active Directory", types = ("https://schemas.xmlsoap.org/claims/UPN", "https://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID"), query = "samAccountName={0};userPrincipalName,objectguid;{1}", param = regexreplace(c.Value, "(?<domain>[^\\]+)\\(?<user>.+)", "${user}"), param = c.Value);

Save the rule changes

Tools

I'm going to assume you're using the Active Directory Migration Toolkit (ADMT). This is what I've tested with and can confirm works.

Migration Process

Here, I won't be stepping through the use of ADMT. That's not what I want to discuss. I just want to make the migration process clear so that you don't lose any objects. Here we go -

1. Keep the user objects you want to migrate between Forests in scope for AAD Connect synchronisation. By this I mean, leave it in an OU that AAD Connect is synchronising
2. Migrate the users so that they are also in scope for AAD Connect synchronisation in the destination Forest - they should land in an OU that AAD Connect is synchronising
3. Make an edit to a replicated attribute on the destination user object and validate that this shows up in the Azure Active Directory tenant after the next sync cycle (Description attribute for example)
4. Move the object out of scope for AAD Connect synchronisation in the source Forest (and potentially delete/decommission it)

Example

I start with my synchronised users. I'm going to migrate forest2user over to forest1.com

Source user is in a synchronised OU -

After migration, the user object is in a synchronised OU -

At this point, both objects are synchronising into a merged object in the AAD Connect Metaverse. An attribute change on either object will propagate to the Azure Active Directory tenant. I make an edit to the Department attribute on the destination user object -

And now I see this after a sync in the Azure Active Directory tenant -

I am now able to decommission the user object in the source Forest.

Conclusion

This series has covered the proper use of a sourceAnchor for an AAD Connect deployment synchronising multiple Forests to an Azure Active Directory tenant. With the right configuration, user migration between Forests is successful without object duplication in the tenant.

This blog post series is based upon and tested with AAD Connect, December 2016 release, version 1.1.380.0. Test all deployment designs before production implementation.

Table of Contents

Part 1, Introduction

Part 2, Lab Setup

Part 3, An Aside on EmployeeID

Part 4, Using msDS-SourceAnchor

Part 5, Using mS-DS-ConsistencyGuid

Part 6, Moving off objectGuid

Part 7, Migrating Users

Correcting an earlier choice of objectGuid

As it turns out, if you've previously selected objectGuid as you sourceAnchor, you can very easily change to using msDS-SourceAnchor or mS-DS-ConsistencyGuid.

Pause the sync service by opening a PowerShell prompt and executing

Set-ADSyncScheduler -SchedulerSuspended $true

Choose either msDS-SourceAnchor or mS-DS-ConsistencyGuid and make the rule edits described in Part 4 of this series for msDS-SourceAnchor or Part 5 of this series for mS-DS-ConsistencyGuid.

Open "C:\Program Files\Microsoft Azure AD Sync\UIShell\miisclient.exe"

Navigate to Connectors

Select the first Forest connector and click Properties

In the properties sheet, click Select Attributes

Check Show All

Scroll down and check msDS-SourceAnchor (or mS-DS-ConsistencyGuid if you're using that)

Click OK

Repeat for all other Forest connectors

Resume the sync service by opening a PowerShell prompt and executing

Set-ADSyncScheduler -SchedulerSuspended $false

Trigger a delta sync by executing

StartADSyncSyncCycle -PolicyType Delta

What about when other attributes are used for sourceAnchor?

Now you're in a world of hurt.

You need to uninstall AAD Connect and have the wizard remove all components including the sync database. You need to delete your users from Azure Active Directory and you need to start again.

An alternative to starting over is to change the ImmutableID by

Logging into https://manage.windowsazure.com

Navigating to the Azure Active Directory tenant

Selecting Directory Integration

Disabling Directory Sync

Note: It will take time to disable sync for all users … around 1 hour for every 2000 users. Due to the asynchronous nature of this task under the hood, it may not begin immediately (sometimes a delay of hours and in rare cases days). Sync cannot be enabled again until this task is complete.

Change the UPN for users to the .onmicrosoft.com tenant domain -

Set-MsolUserPrincipalName -NewUserPrincipalName user@tenant.onmicrosoft.com -UserPrincipalName user@publicdomain.com

Change the ImmutableID to the value you want to use for each user -

Set-MsolUser -UserPrincipalName user@tenant.onmicrosoft.com -ImmutableId newValue

Change the UPN back to the public domain name -

Set-MsolUserPrincipalName -NewUserPrincipalName user@publicdomain.com -UserPrincipalName user@tenant.onmicrosoft.com

Enable sync for the Azure Active Directory tenant again (again more time for sync to start again)

AAD Connect configuration will need to be updated to reflect the use of the new sourceAnchor

Depending on the services you're using with your Azure Active Directory tenant, you may be facing mailbox export/import operations and various other problems.

I would recommend engaging with Microsoft Premier Field Engineering, Microsoft Consulting or a trusted cloud partner to help you through it.

Conclusion

Moving away from objectGuid over to msDS-SourceAnchor or mS-DS-ConsistencyGuid as your sourceAnchor is relatively easy.

This blog post series is based upon and tested with AAD Connect, December 2016 release, version 1.1.380.0. Test all deployment designs before production implementation.

Table of Contents

Part 1, Introduction

Part 2, Lab Setup

Part 3, An Aside on EmployeeID

Part 4, Using msDS-SourceAnchor

Part 5, Using mS-DS-ConsistencyGuid

Part 6, Moving off objectGuid

Part 7, Migrating Users

Green Fields Deployment with mS-DS-ConsistencyGuid

The steps to configure mS-DS-ConsistencyGuid as the sourceAnchor are almost identical to those for msDS-SourceAnchor. For this reason, I'll be less verbose than last than my last post and just highlight the configuration differences.

The rule logic has to be slightly different because mS-DS-ConsistencyGuid and msDS-SourceAnchor have different attribute syntax (data types) in Active Directory. For write-back to on-premises Active Directory objects, we will use SourceAnchorBinary to populate mS-DS-ConsistencyGuid

Just as I did in the last post, a new deployment starts by choosing mS-DS-ConsistencyGuid in the AAD Connect setup wizard -

Note: It is unsupported to edit the built-in rules. All you can do is copy them which disables the original.

Notice that the lowest precedence on these rules is 100. Starting from a precedence value of

(100 - (2 x number_of_forests)) we'll number each new rule

In my example, this value will be (100 - (2 x 2)) = 96

I'll have

• In from AD - User Join Custom = 96
• In from AD - User Join Custom = 97
• In from AD - mS-DS-ConsistencyGuid = 98
• In from AD - mS-DS-ConsistencyGuid = 99

Modifying User Join Rules

Note the precedence value you're up to

Click Edit and then click Yes when prompted to copy the rule

Provide a meaningful Name (e.g. In from AD - User Join Custom)

Set the Precedence

Click Next twice

On the Join Rules page, in the existing join rule, change the Source Attribute to mS-DS-ConsistencyGuid and the Target Attribute to sourceAnchorBinary

On the Join Rules page, click Add group

On the Join Rules page, in the new join rule, change the Source Attribute to objectGuid and the Target Attribute to sourceAnchorBinary

Click Next

On the Transformation page, edit the second rule so that the FlowType is Expression, Target Attribute is sourceAnchor and the source is

IIF(IsPresent([mS-DS-ConsistencyGuid]),IIF(IsString([mS-DS-ConsistencyGuid]),CStr([mS-DS-ConsistencyGuid]),ConvertToBase64([mS-DS-ConsistencyGuid])),IIF(IsString([objectGUID]),CStr([objectGUID]),ConvertToBase64([objectGUID])))

On the Transformation page, add a third rule so that the FlowType is Expression, Target Attribute is sourceAnchorBinary and the source is

IIF(IsPresent([mS-DS-ConsistencyGuid]),[mS-DS-ConsistencyGuid],[objectGUID])

Click Save

If prompted with an Expression Warning, click Yes

Repeat for each additional Forest being synchronised

Overriding User AccountEnabled and User Common Rules for sourceAnchor

Change the source expression to

IIF(IsPresent([msExchRecipientTypeDetails]),IIF([msExchRecipientTypeDetails]=2,NULL,IIF(IsPresent([mS-DS-ConsistencyGuid]),IIF(IsString([mS-DS-ConsistencyGuid]),CStr([mS-DS-ConsistencyGuid]),ConvertToBase64([mS-DS-ConsistencyGuid])),IIF(IsString([objectGUID]),CStr([objectGUID]),ConvertToBase64([objectGUID])))),IIF(IsPresent([mS-DS-ConsistencyGuid]),IIF(IsString([mS-DS-ConsistencyGuid]),CStr([mS-DS-ConsistencyGuid]),ConvertToBase64([mS-DS-ConsistencyGuid])),IIF(IsString([objectGUID]),CStr([objectGUID]),ConvertToBase64([objectGUID]))))

Click Add

If prompted with an Expression Warning, click Yes

Repeat for each additional Forest being synchronised

Creating a Rule to Write sourceAnchorBinary back into mS-DS-ConsistencyGuid

Now we have rules that correctly populate sourceAnchor and sourceAnchorBinary in the Metaverse, we need rules that write sourceAnchorBinary back into the on-premises mS-DS-ConsistencyGuid attribute -

Change the rule editor filter to show Outbound rules

Take note of the precedence of the last rule in the list

Click Add new rule

On the Description page, set the Name to Out to AD - mS-DS-ConsistencyGuid

On the Description page, set Connected System to the Forest you're currently configuring the rule for

On the Description page, set Connected System Object Type to user

On the Description page, set Metaverse Object Type to person

On the Description page, set the Precedence to a value higher than the precedence noted above (this will need to increase for each new rule created for each Forest)

Click Next three times

On the Transformation page, click Add transformation

In the new transformation set the FlowType to Direct, the Target Attribute to mS-DS-ConsistencyGuid, the Source to sourceAnchorBinary and the Merge Type to Update

Click Add

Repeat for each additional Forest being synchronised

Close the rules editor

Trigger a Full Sync

Open a PowerShell prompt and execute

Start-ADSyncSyncCycle -PolicyType Initial

You should now find that users are successfully synchronised to Azure Active Directory and that sourceAnchor is written back into msDS-SourceAnchor for on-premises objects

Conclusion

The rule changes configured here prefer mS-DS-ConsistencyGuidas the sourceAnchor source but use objectGuid when mS-DS-ConsistencyGuidis NULL. sourceAnchorBinary is written back to mS-DS-ConsistencyGuid in the on-premises object so that this attribute is always used after the initial sync, even after a migration of the user object between Forests.

This blog post series is based upon and tested with AAD Connect, December 2016 release, version 1.1.380.0. Test all deployment designs before production implementation.

Table of Contents

Part 1, Introduction

Part 2, Lab Setup

Part 3, An Aside on EmployeeID

Part 4, Using msDS-SourceAnchor

Part 5, Using mS-DS-ConsistencyGuid

Part 6, Moving off objectGuid

Part 7, Migrating Users

Green Fields Deployment with msDS-SourceAnchor

Following on from my previous sourceAnchor posts, let's assume a new deployment with AAD Connect into an empty Azure Active Directory tenant.

I step through the AAD Connect setup wizard, adding the Forests from my lab (forest1.com and forest2.com), scoping sync to a single OU in each case (SyncOU) and choosing msDS-SourceAnchor as my sourceAnchor attribute -

I complete the wizard allowing initial sync to be triggered and wait … and wait … and nothing shows up in my Azure Active Directory tenant!

What's Going On?

If you go back to Part 2 of this series, I demonstrated that msDS-SourceAnchor starts life as a NULL value. What this means is that sourceAnchor in the AAD Connect Metaverse is not populated when the default sync rules are used. I can see this by running

"C:\Program Files\Microsoft Azure AD Sync\UIShell\miisclient.exe"

I then click on Metaverse Search and then the Search button which displays the objects imported from my Forests into the AAD Connect Metaverse -

If I double-click on one of these objects, I can see the attributes in the Metaverse that have been populated -

In this case, we cannot see sourceAnchor (I'll discuss sourceAnchorBinary in a later post)

It follows that AAD Connect can't create an object in Azure Active Directory. We'll need to modify the sync rules.

Editing the Sync Rules

The sync rules editor is opened by running

"C:\Program Files\Microsoft Azure AD Sync\UIShell\SyncRulesEditor.exe"

When this opens, you'll notice that the rules are filtered by Inbound and that for each Forest, there are three rules that relate to Users -

The rules for each Forest are

• In from AD - User Join
• In from AD - User AccountEnabled
• In from AD - User Common

Note: It is unsupported to edit the built-in rules. All you can do is copy them which disables the original. I'll copy the User Join rule and create a new rule that overrides the other two rules for just the sourceAnchor attribute

Notice that the lowest precedence on these rules is 100. Starting from a precedence value of

(100 - (2 x number_of_forests)) we'll number each new rule

In my example, this value will be (100 - (2 x 2)) = 96

I'll have

• In from AD - User Join Custom = 96
• In from AD - User Join Custom = 97
• In from AD - msDS-SourceAnchor = 98
• In from AD - msDS-SourceAnchor = 99

Modifying User Join Rules

Note the precedence value you're up to

Click Edit and then click Yes when prompted to copy the rule

Provide a meaningful Name (e.g. In from AD - User Join Custom)

Set the Precedence

Click Next twice

On the Join Rules page, in the existing join rule, change the Source Attribute to msDS-SourceAnchor and the Target Attribute to sourceAnchor

On the Join Rules page, click Add group

On the Join Rules page, in the new join rule, change the Source Attribute to objectGuid and the Target Attribute to sourceAnchorBinary

Click Next

On the Transformation page, edit the second rule so that the FlowType is Expression, Target Attribute is sourceAnchor and the source is

IIF(IsPresent([msDS-SourceAnchor]),IIF(IsString([msDS-SourceAnchor]),CStr([msDS-SourceAnchor]),ConvertToBase64([msDS-SourceAnchor])),IIF(IsString([objectGUID]),CStr([objectGUID]),ConvertToBase64([objectGUID])))

On the Transformation page, add a third rule so that the FlowType is Direct, Target Attribute is sourceAnchorBinary and the source is objectGuid

Click Save

If prompted with an Expression Warning, click Yes

Repeat for each additional Forest being synchronised

Overriding User AccountEnabled and User Common Rules for sourceAnchor

IIF(IsPresent([msExchRecipientTypeDetails]),IIF([msExchRecipientTypeDetails]=2,NULL,IIF(IsPresent([msDS-SourceAnchor]),IIF(IsString([msDS-SourceAnchor]),CStr([msDS-SourceAnchor]),ConvertToBase64([msDS-SourceAnchor])),IIF(IsString([objectGUID]),CStr([objectGUID]),ConvertToBase64([objectGUID])))),IIF(IsPresent([msDS-SourceAnchor]),IIF(IsString([msDS-SourceAnchor]),CStr([msDS-SourceAnchor]),ConvertToBase64([msDS-SourceAnchor])),IIF(IsString([objectGUID]),CStr([objectGUID]),ConvertToBase64([objectGUID]))))

IIF(
	IsPresent([msExchRecipientTypeDetails]),
	IIF(
		[msExchRecipientTypeDetails]=2,
		NULL,
		IIF(
			IsPresent([msDS-SourceAnchor]),
			IIF(
				IsString([msDS-SourceAnchor]),
				CStr([msDS-SourceAnchor]),
				ConvertToBase64([msDS-SourceAnchor])
			),
			IIF(
				IsString([objectGUID]),
				CStr([objectGUID]),
				ConvertToBase64([objectGUID])
			)
		)
	),
	IIF(
		IsPresent([msDS-SourceAnchor]),
		IIF(
			IsString([msDS-SourceAnchor]),
			CStr([msDS-SourceAnchor]),
			ConvertToBase64([msDS-SourceAnchor])
		),
		IIF(
			IsString([objectGUID]),
			CStr([objectGUID]),
			ConvertToBase64([objectGUID])
		)
	)
)

The rule changes configured here prefer msDS-SourceAnchor as the sourceAnchor source but use objectGuid when msDS-SourceAnchor is NULL. sourceAnchor is written back to msDS-SourceAnchor in the on-premises object so that this attribute is always used after the initial sync, even after a migration of the user object between Forests.