Azure AD Connect 1.1.561.0 finalizes Automatic Upgrade scenario changes and the move to mS-DS-ConsistencyGuid

Yesterday, Microsoft released version 1,1.561.0 of Azure AD Connect, its free Hybrid Identity bridge product to synchronize objects and their attributes from on-premises Active Directory Domain Services (AD DS) environments to Azure Active Directory.

This version is hot on the heels of version 1.1.557.0, because it features some fixes for organization who recently made the switch to mS-DS-ObjectGuid as their Source Anchor attribute in Azure AD Connect. Also, it incorporates many of the Automatic Upgrades behavioral changes when using the Customize Settings mode of the Azure AD Connect Configuration wizard.

What’s New

Since version 1.1.105.0 of Azure AD Connect, the Azure AD Connect team has steadily expanded the Automatic Upgrade feature feature to support organizations with the following configurations:

The installation is not a DirSync upgrade.
The installation is not an Express settings.
You have more than 100,000 objects in the metaverse.
You are connecting to more than one Active Directory forest.

Note:
Express setup only connects to one Active Directory forest.

You are not using a SQL Server Express LocalDB database.
The Active Directory Connector account is not the MSOL_ or AAD_ account that is created, by default when you connect to Active Directory (anymore).
The server is set to be in Staging Mode.
You have enabled the Device Write-back feature.
You have enabled the Group Write-back feature.
You have enabled the User Write-back feature.

Fixes

The Azure AD Connect team fixed an issue that caused the out-of-box synchronization rule “Out to AD – User ImmutableId” to be removed when OU-based filtering configuration is updated. This synchronization rule is required for the msDS-ConsistencyGuid as Source Anchor feature. Fortunately, the logic in Azure Active Directory and Active Directory Federation Services (AD FS) allow for a fallback scenario where the objectGUID is used for hard matching, when the mS-DS-ConsistencyGuid is empty.

The Azure AD Team fixed an issue that causes out-of-box synchronization rules to have precedence value that is less than 100. In general, precedence values 0 – 99 are reserved for custom synchronization rules.

The Azure AD Connect team fixed an issue where the Domain and OU Filtering screen in the Azure AD Connect wizard is showing the Sync all domains and OUs option as selected, even though OU-based filtering is enabled.

The Azure AD Connect team fixed an issue that caused the Configure Directory Partitions screen in the Synchronization Service Manager to return an error if the Refresh button is clicked. The error message is:

An error was encountered while refreshing domains:

Unable to cast object of type ‘System.Collections.ArrayList’ to type ‘Microsoft.DirectoryServices.MetadirectoryServices.UI.PropertySheetBase.MaPropertyPages.PartitionObject.”

The error occurs when a new Active Directory domain has been added to an existing Active Directory forest and you are trying to update Azure AD Connect using the Refresh button.

Version information

This is version 1.1.561.0 of Azure AD Connect.
It was signed off on on July 23, 2017.

Download information

You can download Azure AD Connect here.
The download weighs 79,6 MB.

Concluding

Much of the above behavior was introduced in version 1.1.558.0, but internal testing led to several more fixes to make sure the choice for Azure AD Connect is the right choice for organizations on their Hybrid Identity journeys.

Azure AD Connect version 1.1.557,0 wasn’t released through the Automatic Upgrades feature, so I expect many organizations to go from 1.1.553.0 to version 1.1.561.0. Those with lifecycle management surrounding their Azure AD Connect installations should take note of release notes mentioning versions that are not offered through this feature.

Posted on July 24, 2017 by Sander Berkouwer in Active Directory, Azure Active Directory

Top Five reasons why Identity Admins should look at Windows Server Insider Preview Build 16237

Yesterday, Microsoft made Windows Server Insider Preview Build 16237 available to the Windows Insiders and Windows Insiders for Business programs. This is the first preview build of the Redstone 3 (RS3) release of Windows Server vNext.

I’ve looked at this release, and as an Identity Admin, I feel this build has a lot to offer.
I condensed a short list of the top five reasons to look at Windows Server Insider Preview Build 16237:

1. SMB1 is disabled, by default

Disabling version 1 of the Server Message Block (SMB) protocol is good news for security, because this version utilizes weak hashing algorithms and other vulnerabilities. Recently, a couple of these vulnerabilities were successfully exploited as part of WannaCry and Petya.

For Microsoft to disable SMB1 by default in Windows Server, therefore, helps, especially since the SMB protocol plays an important role in Active Directory.

However, it might end up being a catastrophe when you leverage certain products in your networking infrastructure. Looking at Windows Server Insider Preview Build 16237 early, provides plenty of time to move away from that stuff, including VMware vSphere 6.0 or at least provides an impact analyses.

Note:
aka.ms/stillneedssmb1 lists known SMB1-using products, that will be affected when SMB1 is disabled.

2. Improvements in time accuracy

When thinking Active Directory and Kerberos, you’re thinking time synchronization. In Windows Server Insider Preview 16237, Microsoft made the following improvements:

Pressing EU regulations in 2018 require strict time precision and traceability. Win32tm improvements in Redstone 3 (RS3) support greater time accuracy, and jitter is removed from the measurements that calibrate the service.
New system event logging lets you archive time service data to support traceability compliance.
System center monitoring now includes a new rule that lets you detect when a device within the networking environment is out of compliance.

3. Improved Branch Office Connectivity

Looking at networking, Windows Server Insider Preview Build 16237 promises a 2x throughput improvement for TCP and UDP performance in low latency intra-datacenter scenarios.

Thinking of low-latency intra-datacenter connections, the need for Active Directory sites regularly pops up. With significant throughput improvements, Active Directory replication should work better with Windows Server Insider Preview Build 16237.

4. Shielded VMs for Linux

Shielded Virtual Machines allow Active Directory admins to retake ownership of virtual Active Directory Domain Controllers. The only way, of course, is to shut out virtualization admins and storage admins of management tasks. Except for starting and stopping your virtual Domain Controllers, this is exactly what the Shielded VM feature in Hyper-V offers in Windows Server 2016. With Windows Server Insider Preview Build 16237, the Shielded VMs functionality is expanded to Linux. Now even more services can be given back to the respective owners, like your SIEM and TSCM admins.

5. Continuous Innovation

This is the first public preview release of Windows Server, since Microsoft announced ìts departure from the long-term servicing channel (LTSC) model of Windows Server 2016 towards Semi-annual Channel releases.

While this allows for Microsoft to deliver continuous innovation, I feel IT departments should look early at new releases to assess their impact and benefits offered to the business. While it might feel like a good idea to stick with an LTSC-release of Windows Server for Active Directory Domain Controllers, for most organizations it might prove that semi-annual releases of Windows Server better align with System Center Current Branch and Azure Infrastructure-as-a-Service (IaaS).

On the other hand: Microsoft does not support in-place upgrades for Azure IaaS-based Virtual Machines and we don’t have guidance yet on whether this applies to Windows Server’s Semi-annual Channel, too.

Concluding

Windows Server Insider Preview 16237 offers a glimpse on the future of on-premises Active Directory and security. Looking at it early makes it easier to adopt the Semi-annual Channel changes coming to Windows Server vNext.

About the vulnerability

In a remote attack scenario, an attacker could exploit this vulnerability by running a specially crafted application to send malicious traffic to an Active Directory Domain Controller. An attacker who successfully exploited this vulnerability could run processes in an elevated context. There is a good explanation of the vulnerabilities at the Preempt blog. Preempt also offers a video where they demonstrate the attack vector.

The update addresses this vulnerability by incorporating enhancements into Extended Protection for Authentication. These enhancements are designed to mitigate authentication attacks. It revolves around the concept of channel binding information.

When Extended Protection for Authentication is enabled, authentication requests are bound to both the Service Principal Names (SPN) of the server the client attempts to connect to and to the outer Transport Layer Security (TLS) channel over which the Integrated Windows Authentication (IWA) authentication takes place.

About the update

Microsoft issued the following update packages:

Product	Article	Update Type
Windows 10	4025338	Security update
Windows 10 v1511	4025344	Security update
Windows 10 v1607	4025339	Security update
Windows 10 v1703	4025342	Security update
Windows 7 with Service Pack 1	4025341	Monthly Rollup
	4025337	Security update-only
Windows 8.1	4025336	Monthly Rollup
	4025333	Security update-only
Windows Server 2008 with Service Pack 2	4025409	Security update
Windows Server 2008 R2 with Service Pack 1	4025341	Monthly Rollup
	4025337	Security update-only
Windows Server 2012	4025331	Monthly Rollup
	4025343	Security update-only
Windows Server 2012 R2	4025336	Monthly Rollup
	4025333	Security update-only
Windows Server 2016	4025339	Security update

Updates need to be installed on all systems within the networking environment to enable the channel binding enhancements.

Active Directory Domain Controllers

The security update that is described in CVE-2017-8563 introduces a registry setting named LdapEnforceChannelBinding, leveraging the Extended Protection for Authentication functionality in Windows’ Security Support Provider Interface (SSPI).

Active Directory admins can use this registry key to help make LDAP authentication over SSL/TLS more secure.

To enable this functionality, Active Directory admins need to explicitly configure the following registry setting on all their Active Directory Domain Controllers, after they installed the corresponding update:

Path: HKEY_LOCAL_MACHINE/System/CurrentControlSet/Services/NTDS/Parameters
Key: LdapEnforceChannelBinding
DWORD value: 0 indicates disabled. No channel binding validation is performed. This is the behavior of all servers that have not been updated.
DWORD value: 1 indicates enabled, when supported. All clients that are running on a version of Windows that has been updated to support channel binding tokens (CBT) must provide channel binding information to the server. Clients that are running a version of Windows that has not been updated to support CBT do not have to do so. This is an intermediate option that allows for application compatibility.
DWORD value: 2 indicates enabled, always. All clients must provide channel binding information. The server rejects authentication requests from clients that do not do so.

Miscellaneous information

Server Core

Server Core installations of Windows Server are vulnerable to this attack vector and need to be updated, too.

Reboot requirements

Admins need to restart the Operating System to apply the update. However, admins do not have to restart their Domain Controllers a second time to apply the above registry change.

Mitigations

Microsoft has not identified any mitigating factors for this vulnerability.

Workarounds

Microsoft has not identified any workarounds for this vulnerability.

Acknowledgements

The vulnerability was responsibly disclosed three months ago to Microsoft by Yaron Zinar, Eyal Karni, and Roman Blachman at Preempt.

Call to action

I urge Active Directory admins to apply the update throughout their networking environment, following their normal test procedures.

Since Domain Controllers are under more strict control than client devices, the recommended way to implement this functionality is to update the Domain Controllers and set the LdapEnforceChannelBinding registry key to 1.

Then, when you’ve updated all the client devices in scope, set the LdapEnforceChannelBinding registry key to 2.

Note:
Do not change the value to 2 when you have Windows Vista or Windows Server 2008-based installations. This is a known issue as described in KnowledgeBase article 979231.

About Source Anchors

The source anchor attribute helps Azure AD Connect to perform a hard match between on-premises objects in Active Directory Domain Services (AD DS) to objects in Azure Active Directory.

It is recommended to use an attribute as a source anchor that doesn’t change throughout the lifecycle of an Active Directory object and is unique to the object. Because people get married, get divorced, change their names, etc. the userPrincipalName, and mail attributes cannot be picked as the source anchor attribute in Azure AD Connect. (and also, because source anchors may not contain special characters, like the @-sign).

Before Azure AD Connect version 1.1.524.0, Azure AD Connect (but also Azure AD Sync and DirSync) defaulted to the objectGUID attribute for objects as the source anchor. Azure AD Connect version 1.1.553.0, and beyond, defaults to the mS-DS-ConsistencyGuid for user objects, but objectGUID for groups and computer objects.

The table below provides an overview:

This begs the question: What’s wrong with using ObjectGUID as the source anchor?

What’s wrong with objectGUID?

objectGUID is an attribute for on-premises Active Directory objects, that is written to with a random value when the object is created. From there on, it can no longer be changed. It’s immutable, even for Active Directory itself.

You’d think this makes for a pretty decent source anchor, but there two challenges:

The Cross-forest Migration Challenge

With the possibility for Azure AD Connect to synchronize multiple on-premises Active Directory Domain Services (AD DS) environments, a challenge emerges:

How do we cope with migrating a user object from one Active Directory forest, to another, when the person associated with the user account enjoys the benefits of Azure Active Directory?

When a user object is migrated from one Active Directory forest, to another, it is reborn, and, thus, receives a different value for objectGUID. Azure AD Connect will not be able to perform a hard match and the person may receive no mailbox, a fresh new mailbox, or worse, access to someone else’s mailbox…

The Accidentally Deleted Challenge

The second issue with using objectGUID as the source anchor for Azure AD Connect is that it complicates undelete of (accidentally) deleted user objects in on-premises Active Directory Domain Services (AD DS) environments in scope for synchronization.

While the use of the Active Directory Recycle Bin feature is highly recommended (Azure AD Connect provides a notice when this feature is not enabled), it’s not possible to enable it in every environment. While enabled, though, it adds another 180 days time-out, by default, to the garbage collection process on each of your Domain Controllers, on top of the default 180 days tombstone lifetime.

In other Active Directory Domain Services (AD DS) environments, though, the tombstone lifetime may still be set at 60 days. When these Active Directory forests were first setup, admins leveraged Domain Controllers running Windows Server versions prior to Windows Server 2003 with Service Pack 1. In the time since its inception, the tombstone lifetime was never set to 180 days, although Microsoft changed its recommendation.

When you reanimate an object beyond the tombstone lifetime, or in other rare cases, the object is recreated with its former attributes, except for objectGUID… Since this is a system-generated value set at creation date, the object is reborn with a different value for its objectGUID attribute.

How does mS-DS-ConsistencyGuid help?

When your organization already faced the challenges above, you may have already switched from objectGUID to mS-DS-ConsistencyGuid, mS-DS-SourceAnchor or even EmployeeID, using Mark Renoden’s guidance or using Roelf Zomerman’s guidance.

The magic in Azure AD Connect version 1.1.553.0, and beyond, is the introduction of the ability to automatically switch from objectGUID to mS-DS-ConsistencyGuid.

When you select mS-DS-ConsistencyGuid , Azure AD Connect will perform the following actions:

In organizations with Active Directory Federation Services (AD FS) and the ‘Office 365 Identity Platform’ (or urn:federation:MicrosoftOnline) Relying Party Trust (RPT), Azure AD Connect will update the AD FS Issuance Transform Rules for this RPT to accommodate the use of mS-DS-ConsistencyGuid.
On the first synchronization cycle, Azure AD Connect will check the mS-DS-ConsistencyGuid attribute of user objects in scope. When these attributes are empty, Azure AD Connect will update the attributes with the value of the objectGUID attribute.
On the second synchronization cycle, Azure AD Connect will synchronize the user objects in scope with filled mS-DS-ConsistencyGuid attributes to Azure Active Directory.

Now, when you migrate a user object from one on-premises Active Directory Domain Services (AD DS) environment, to another, and both environments are in (future) scope of Azure AD Connect, the value for the objectGUID attribute of the user object changes, but the value for the mS-DS-ConsistencyGuid attribute remains the same. With mS-DS-ConsistencyGuid as its source anchor attribute, Azure AD Connect is able to hard match the Active Directory user object with the Azure Active Directory user object, as if nothing happened.

The same thing happens when you reanimate a user object in the on-premises Active Directory Domain Services (AD DS) environment: the value for the objectGUID attribute of the user object changes, but the value for the mS-DS-ConsistencyGuid attribute remains the same.

What you need to know

I have already scattered some tidbits throughout this blogpost on what you may, and may not expect from this change. I’ve compiled a list below for your convenience:

The source anchor setting is a per-Azure AD Connect setting. When you change the source anchor attribute on your actively synchronizing Azure AD Connect installation, you should also change the source anchor attribute on the Staging Mode Azure AD Connect installation(s).
The mS-DS-ConsistencyGuid attribute may not be in use by another application throughout each of the on-premises Active Directory Domain Services (AD DS) environments you have or intend to have in scope for Azure AD Connect.
Custom-managed Azure AD Connect service account(s) may not have permission to write to the mS-DS-ConsistencyGuid attribute of user objects in your on-premises Active Directory Domain Services (AD DS) environment(s). You will need to grant this permission manually in (each of) the Active Directory Domain Services environment(s) in scope.
The switch from objectGUID to mS-DS-ConsistencyGuid as the source anchor in Azure AD Connect is (currently) only available for user objects, not for groups or computer objects.
When you leverage Active Directory Federation Services (AD FS) as the Azure AD authentication scenario with Azure AD Connect, you will need direct network connections using TCP80, TCP443 and TCP5985 between your Azure AD Connect installation and the primary AD FS Server, when you switch from objectGUID to mS-DS-ConsistencyGuid as the source anchor attribute.
When you make the switch through Azure AD Connect, it is no longer a good idea to reset the ‘Office 365 Identity Platform’ (or urn:federation:MicrosoftOnline) Relying Party Trust (RPT) by deleting it on the AD FS Primary Server and then recreating it using the Convert-MSOLDomaintoFederated PowerShell Cmdlet. Instead, use the Reset Azure AD and AD FS Trust option in Azure AD Connect:

Concluding

Join me for part 2 of this series, where I show you the exact changes in Active Directory Federation Services’ Issuance Transform Rules and a script to grant a custom Azure AD Connect service account permissions to write the mS-DS-ConsistencyGuid attribute in your on-premises Active Directory Domain Services (AD DS) environments.

What’s New

Azure AD Connect

Password Write-back is now available for preview with Microsoft Azure Government cloud and Microsoft Cloud Germany.

The Initialize-ADSyncDomainJoinedComputerSync PowerShell Cmdlet now has a new optional parameter named –AzureADDomain. This parameter lets you specify which verified DNS domain name to be used for configuring the service connection point (SCP) in Active Directory Domain Services.

Pass-through Authentication (PTA)

The name of the agent required for Pass-through Authentication (PTA) has been changed from Microsoft Azure AD Application Proxy Connector to Microsoft Azure AD Connect Authentication Agent.

Enabling Pass-through Authentication (PTA) no longer enables Password Hash Synchronization (PHS), by default.

Fixed issues

Azure AD Connect

The team fixed an issue with the Initialize-ADSyncDomainJoinedComputerSync PowerShell Cmdlet that caused the verified domain configured on the existing service connection point (SCP) object to be changed even if it is still a valid domain. This issue occurs when your Azure AD tenant has more than one verified domain, that can be used for configuring the service connection point (SCP) in Active Directory Domain Services.

Version information

This is version 1.1.557.0 of Azure AD Connect.
It was signed off on on July 4, 2017.

Download information

You can download Azure AD Connect here.
The download weighs 79,6 MB.

Concluding

Azure AD Connect version 1.1.557.0 is currently not offered to organizations currently utilizing Azure AD Connect, but it is the only version available for download, now.

Posted on July 6, 2017 by Sander Berkouwer in Active Directory, Azure Active Directory

Creating an MFA Provider when you have CSP or DreamSpark

Microsoft is working hard to migrate all management activities from the ‘classic’ Windows Azure Management website (manage.windowsazure.com) to the ‘new’ Azure Portal (portal.azure.com).

Some of Microsoft’s new subscriptions, like its DreamSpark and CSP-style subscriptions, don’t offer access to the ‘classic’ Windows Azure Management website. But alas, some of the management tasks for implementing Multi-factor Authentication (MFA) for your organization can only be performed in that portal. Setting up an Azure MFA Provider to implement MFA Server on-premises is one such scenario, and a fairly common one: You can’t download and connect your on-premises MFA Servers without an MFA Provider.

However, you might hit the No subscriptions found. screen when you follow a link from the new Azure Portal to the classic portal, or when you navigate directory to the ‘classic’ Azure Management website:

No subscriptions found.

This blogpost shows you how to overcome that hurdle, by creating an Azure Active Directory-only Azure subscription.

About Azure AD-only Azure subscriptions

Azure AD-only subscriptions are special subscription that give access to Azure Active Directory only. With a special Azure offer code, you can sign up for such a subscription. Signing up does not require a credit card.

This subscription has the following characteristics:

It is a regular Azure subscription
It has a subscription ID that can be managed and associated with EA
It will not expire or incur charges
It can only manage Azure AD services
You can assign licenses for Azure AD Basic or Free since these are purchased over licensing agreements as opposed to Azure consumption
You cannot create any other Azure resources except those related to Azure AD
You can add other co-admins and change the service admin from the account portal
The account that signed up for this subscription is also the account admin and has access to the account portal

Signing up for an Azure AD-only Subscription

Perform these steps to sign up for an Azure AD-only subscription:

Make sure you use a clean browser or browser tab where you are not already signed in to any Microsoft services, either Azure AD-based or Microsoft Account (MSA)-based. My recommendation is to use an InPrivate browser session.
Navigate to the following URL:
https://account.windowsazure.com/signup?offer=MS-AZR-0110P
Select Sign in with your organizational account and sign in with the Global Administrator account of your Azure AD tenant.

Complete the Azure sign up form and press the Next button to complete the first piece of the form.
Now, enter your phone number and press the Next button in the second piece of the form.

Press the Sign up button.

You will be forwarded to the Azure Account portal while your subscription is set up. This will only take a few minutes. After this brief period of time, you will receive an e-mail message and the screen will change.
At this moment, go to your browser’s address bar, and change the URL to https://manage.windowsazure.com.
You can opt to take the Windows Azure tour, or skip it by pressing the little x in the right top corner of the modal screen.
You can close the New pane that appeared from the bottom, and you can certainly close the blue Portal modal that lures you to the New Azure Portal.
In the left navigation pane, click on Active Directory.

From the menu items below active directory in the main screen, click on MULTI-FACTOR AUTH PROVIDERS.
Click the link CREATE A NEW MULTI-FACTOR AUTHENTICATION PROVIDER.
In the Name field, type something useful to name your MFA Provider. If your organization has a naming convention, follow that.
Select the Usage Model.
Click Create at the bottom of the screen.

Concluding

Now, you now have access to manage the full feature set of Azure AD and Azure Multi-Factor Authentication. Go ahead and enjoy all the goodness Azure MFA Server has for you!

Vulnerability could allow Elevation of Privilege

In this version of Azure AD Connect, an Elevation of Privilege vulnerability was fixed. This vulnerability is described in Microsoft Security Advisory 4033453 and CVE-2017-8613.

If the Password Writeback feature is enabled in Azure AD Connect, a malicious person who successfully exploited this vulnerability could reset passwords and gain unauthorized access to arbitrary privileged user accounts, residing in the on-premises Active Directory Domain Services (AD DS) environment.

Version 1.1.553.0 of Azure AD Connect addresses this issue by blocking Password write-back request for on-premises privileged accounts (determined by querying the adminCount attribute) unless the requesting Azure AD Administrator is the owner of the account in the on-premises Active Directory Domain Services environment.

Call to action

Please update to Azure AD Connect version 1.1.553.0 as soon as possible,

Mitigating actions

If you are unable to immediately upgrade to the latest “Azure AD Connect” version, consider the following options:

If the account in the on-premises Active Directory Domain Services environment is a member of one or more on-premises privileged groups, consider removing the account from the group(s).
If an on-premises Active Directory administrator has previously created Control Access Rights on the adminSDHolder object for the account in the on-premises Active Directory Domain Services environment, which permits Reset Password operation, consider removing it.
It may not always be possible to remove existing permissions granted to the account in the on-premises Active Directory Domain Services environment. For example, the account relies on the group membership for permissions required for other features such as Password synchronization or Exchange hybrid writeback. In these cases, consider creating a DENY ACE on the adminSDHolder object to disallow the AD DS account with Reset Password permission.

What’s New

Azure AD Connect Sync

Previously, the ‘msDS-ConsistencyGuid as Source Anchor’ feature was available to new deployments only. Now, it is available to existing deployments.

Specific to the userCertificate attribute on Device objects, Azure AD Connect now looks for certificates values required for connecting domain-joined devices to Azure AD and filters out the rest before synchronizing to Azure AD.

Azure AD Connect now supports writeback of Exchange Online cloudPublicDelegates attribute to on-premises AD publicDelegates attribute. This enables the scenario where an Exchange Online mailbox can be granted SendOnBehalfTo rights to users with on-premises Exchange mailboxes. To support this feature, a new out-of-box sync rule “Out to AD – User Exchange Hybrid PublicDelegates writeback” has been added. This sync rule is only added to Azure AD Connect when the ‘Exchange Hybrid’ feature is enabled.

Azure AD Connect now supports synchronizing the altRecipient attribute from Azure AD.

The cloudSOAExchMailbox attribute in the Metaverse indicates whether a given user has an Exchange Online mailbox or not. Its definition has been updated to include additional Exchange Online RecipientDisplayTypes as Equipment and Conference Room mailboxes.

Several X509Certificate2-compatible functions for creating synchronization rule expressions to handle certificate values in the userCertificate attribute were added.

Metaverse schema changes have been introduced to allow customers to create custom synchronization rules to flow sAMAccountName, domainNetBios, and domainFQDN for Group objects, as well as distinguishedName for User objects.

The ADSyncDomainJoinedComputerSync PowerShell Cmdlet script now has a new optional parameter named AzureEnvironment. This parameter can be used to specify which region the corresponding Azure Active Directory tenant is hosted in.

The Sync Rule Editor has been update to use Join (instead of Provision) as the default value of link type during sync rule creation.

AD FS Management

Previously, the ADFS Certificate Management feature provided by Azure AD Connect could only be used with ADFS farms managed through Azure AD Connect. Now, you can use the feature with ADFS farms that are not managed using Azure AD Connect.

Fixes

Azure AD Connect Sync

Fixed an issue related to the ‘msDS-ConsistencyGuid as Source Anchor’ feature where Azure AD Connect does not write-back to on-premises AD msDS-ConsistencyGuid attribute. The issue occurs when there are multiple on-premises AD forests added to Azure AD Connect and the User identities exist across multiple directories option is selected.

Previously, even if the ‘msDS-ConsistencyGuid as Source Anchor’ feature wasn’t enabled, the “Out to AD – User ImmutableId” synchronization rule was still added to Azure AD Connect. The effect is benign and does not cause write-back of the
msDS-ConsistencyGuid attribute to occur. To avoid confusion, logic has been added to ensure that the sync rule is only added when the feature is enabled.

Fixed an issue that caused password hash synchronization to fail with error event 611. This issue occurs after one or more domain controllers have been removed from the on-premises Active Directory Domain Services environment.

Previously, even if Automatic Upgrade had been disabled using the
Set-ADSyncAutoUpgrade cmdlet, the Automatic Upgrade process continued to check for upgrade periodically, and relied on the downloaded installer to honor disablement. With this fix, the Automatic Upgrade process no longer checks for upgrade periodically.

AD FS Management

The following URLs are new WS-Federation endpoints introduced by Azure AD to improve resiliency against authentication outage and will be added to the on-premises AD FS Replying Party Trust (RPT) configuration:

The team fixed an issue that caused AD FS to generate incorrect claim value for IssuerID. This issue occurs if there are multiple verified domains in the Azure AD tenant and the domain suffix of the userPrincipalName attribute used to generate the IssuerID claim is at least 3-levels deep (for example, johndoe@us.contoso.com). The issue is resolved by updating the regex used by the claim rules.

Important information on this release

There are schema and synchronization rule changes introduced in this build.
Azure AD Connect Synchronization Service will trigger Full Import and Full Sync steps after you upgrade to this version. In some environments these steps may take several hours. During this timeframe other information is not synchronized.

Version information

This is version 1.1.553.0 of Azure AD Connect.
It was signed off on on June 27, 2017.

Download information

You can download Azure AD Connect here.
The download weighs 79,6 MB.

Concluding

If your Azure AD Connect implementation hasn’t automatically upgraded to version 1.1.553.0 yet, please update your Azure AD Connect implementation as soon as possible.

In larger organizations and larger networking infrastructures, make sure to schedule the upgrade through lifecycle management in a period of time where the impact of the Full Synchronization cycle would not impact business processes.

Posted on June 28, 2017 by Sander Berkouwer in Active Directory, Azure Active Directory, Security Updates

KnowledgeBase: When you activate the Microsoft Authenticator App on Android 5.x you receive “Your device does not trust the activation URL”

The mobile world is still a fragmented world, where various versions of Apple’s iOS and Google’s Android compete for usage share. With people still getting accustomed to today’s throw-away society and handset manufacturers and vendors tailoring to their needs, there’s people using three years old Operating Systems on mobile phones they just purchased.

The situation

When you implement Azure Multi-Factor Authentication (MFA) Server in a Hybrid Identity scenario, you’d be wise to use your Web Application Proxy infrastructure to publish Azure MFA Server’s User Portal and Mobile Portal.

The issue

With default settings, Web Application Proxies and Active Directory Federation Services (AD FS) Servers running Windows Server 2012 R2 (and up) don’t support Server Name Indication (SNI).

Server Name Indication (SNI) is an extension to the TLS protocol that allows any connecting device to indicate which hostname it is attempting to connect to at the start of the TLS handshake process. This allows a server to present multiple SSL/TLS certificates on the same IP address and TCP port. It allows multiple secure websites to be served by the same IP address without requiring all those sites to use the same certificate.

Therefore, when you try to activate a mobile device running Android 5.x, while accessing the Mobile Portal through a Web Application Proxy with default settings or any proxy, firewall and/or load balancer that doesn’t offer Server Name Indication), you receive the following error:

Unable to add the account

We couldn’t add the account as
your device does not trust the
activation URL. Please contact your
IT administrator.

CANCEL REPORT

The cause

Android 5 supports SNI, according to Qualys, but the official Microsoft Authenticator App on Android 5.x does not support it.

This is a piece of missing functionality in the Microsoft Authenticator App. There are no indications that indicate Microsoft is spending resources on fixing this issue in the Microsoft Authenticator App on this platform.

The workaround

To workaround this issue, accommodate non- Server Name Indication (non-SNI) capable devices on your Web Application Proxies by specifying a fallback TLS certificate, following these steps:

Log on interactively on a Windows Server that acts as a Web Application Proxy with an account with local administrator privileges.
Open a command prompt as an administrator, by either:
- Typing in cmd and then right-clicking on the Command Prompt search result and selecting Run as administrator from the context menu, or
- Pressing Windows + R simultaneously, typing cmd.exe and hitting Ctrl + Shift + Enter all at the same time.
Enter the following command at the command prompt:

netsh http show sslcert

This will output the certificate bindings in use. Copy the application globally unique identifier (GUID), including its brackets and the certificate thumbprint hash of the federation service.
Now construct the following command at the command prompt:

netsh http add sslcert ipport=0.0.0.0:443 certhash=CertThumbPrint
appid={ApplicationGUID}

Next, run the following command:

net stop appproxysvc && net start appproxysvc

Close the command prompt window.
Log off.

Concluding

This challenge with Microsoft’s Authenticator App will go away, because Android 5.x devices will, eventually, go away. Until that time, accommodate non-SNI capable devices on your Web Application Proxies by specifying a fallback TLS certificate.

The situation

Microsoft’s on-premises Multi-Factor Authentication Server and the accompanying Azure MFA Service, luckily, supports more authentication methods, besides voice calls and text messages (in random order):

Phone call
Two-way SMS
Two-way SMS with PIN
One-way SMS
One-way SMS with PIN
OATH token
Mobile App

I’ve done an extensive review of the pros and cons of each authentication method, so I decided to take a closer look at the Mobile App, especially, since Microsoft has put quite some work in it recently.

To this purpose, I added the Multi-Factor Authentication Mobile Portal to an existing Multi-Factor Authentication Server implementation.

I then logged on to the Multi-Factor Authentication User Portal with a user account, performed the second authentication method assigned to the user account and choose Activate Mobile App from the menu in the left pane.

The issue

After I hit the Generate Activation Code and scanned the barcode with my phone, the app responded with an error:

The remote server returned an error: NotFound

The cause

The existing Multi-Factor Authentication Server implementation, I reused to this purpose, uses a TLS certificate that was issued by a private Certification Authority (CA).

Although the root certificate was added to the certificate store of the phone and any desktops with the root certificate installed gain access to the Mobile Portal without problems, the certificate will not work on phones.

The solution

To make the Microsoft Authenticator app work, use a publicly trusted TLS certificate with your Multi-Factor Authentication (MFA) Server Mobile Portal(s).

Related blogposts

Choosing the right Azure MFA authentication methods
Microsoft Authenticator – One easy-to-use app for all your MFA needs

a blog by Sander Berkouwer

What’s New

Fixes

Version information

Download information

Concluding

1. SMB1 is disabled, by default

2. Improvements in time accuracy

3. Improved Branch Office Connectivity

4. Shielded VMs for Linux

5. Continuous Innovation

Concluding

Further reading

About the vulnerability

About the update

Active Directory Domain Controllers

Miscellaneous information

Server Core

Reboot requirements

Mitigations

Workarounds

Acknowledgements

Call to action

Further reading

About Source Anchors

What’s wrong with objectGUID?

The Cross-forest Migration Challenge

The Accidentally Deleted Challenge

How does mS-DS-ConsistencyGuid help?

What you need to know

Concluding

Further reading

What’s New

Azure AD Connect

Pass-through Authentication (PTA)

Fixed issues

Azure AD Connect

Version information

Download information

Concluding

About Azure AD-only Azure subscriptions

Signing up for an Azure AD-only Subscription

Concluding

Further reading

Vulnerability could allow Elevation of Privilege

Call to action

Mitigating actions

What’s New

Azure AD Connect Sync

AD FS Management

Fixes

Azure AD Connect Sync

AD FS Management

Important information on this release

Version information

Download information

Concluding

The situation

The issue

Unable to add the account

The cause

The workaround

Concluding

Further reading

The situation

The issue

The cause

The solution

Related blogposts

Further reading

Search this site

Microsoft MVP (2009-2017)

Veeam Vanguard (2016-2017)

Advertisement

DirTeam.com / ActiveDir.org Blogs

Recent Posts

Recent Comments

Archives

Categories