Security Thoughts: Azure Active Directory Passport Library for Node.js is vulnerable for authentication bypass (CVE-2016-7191)

Yesterday night, we received a notification that a vulnerability in some older versions of the Azure Active Directory Passport Library for Node.js (Passport-Azure-AD) is vulnerable for authentication bypassing, because the ValidateIssuer setting wasn’t recognized, resulting in incorrectly validating tokens.

An attacker who successfully exploits this vulnerability could bypass Azure Active Directory authentication to a targeted host web application. To exploit this vulnerability, an attacker would have to send a specially crafted token to the target web application that contains a valid user’s identity claims. This update addresses the vulnerability by correcting how identity tokens are validated when Passport strategies take advantage of Azure Active Directory.

About the Azure Active Directory Passport Library for Node.js

Passport-Azure-AD for Node.js is a collection of Passport strategies , provided on GitHub by (mostly) Microsoft employees, that help organizations integrate node applications with Azure Active Directory. It includes OpenID Connect, WS-Federation, and SAML-P authentication and authorization.

These providers let you use the many features of Passport-Azure-AD for Node.js, including web single sign-on (WebSSO), Endpoint Protection with OAuth, and JWT token issuance and validation.

Affected versions

The vulnerability exists in web applications that use outdated versions of the Passport-Azure-AD for Node.js library. The following versions of the Azure Active Directory Passport Library for Node.js (Passport-Azure-AD) are vulnerable:

Passport-Azure-AD v1.0
Passport-Azure-AD v1.4.5
Passport-Azure-AD v2.0

This vulnerability only affects web applications that use the Passport-Azure-AD for Node.js library to take advantage of Azure Active Directory for authentication.

Note:
Standard Azure AD authentication that does not use the Passport-Azure-AD for Node.js library is not vulnerable.

Call to Action

You are strongly advised to update the Azure Active Directory Passport Library in your Node.js project(s) to one of the following versions:

Passport-Azure-AD v1.4.6
Passport-Azure-AD v2.0.1

You can download these libraries here.

The traditional approach

Old Toolbox Enterprises and companies of all sizes, that I have worked with, have traditionally thought in projects. Projects that serve a goal, are planned and have a clear beginning and end. This was all fun and games in a world where IT meant we had to buy physical server capacity, purchase licenses, implement the stuff and then write everything off over a period of, traditionally, four to seven years.

After this period of time, the solution would have served its goal (whether it be supporting some process or making loads of money in return) an would then be decommissioned, migrated or replaced. In the mean time it needed some maintenance; updates and upgrades to the Operating System or other software, monitoring, auditing, back-ups, etc.

The world has changed

When I first started in the industry, I choose to accept the challenge to design stuff for a long(er) period of time, and keep maintenance as small as possible, Former colleagues will tell me I managed the challenge pretty well. I actually replaced several iterations of functionality at some customers over the years.

However, the world has changed…

Virtualization has made it easier to allocate compute, storage and networking. Upfront capacity planning is fast becoming a thing of the past, Need more? allocate more. Need even more? Add a host to the virtualization platform and place the resource hogs on the newest hosts. High Availability is easily achieved through the hypervisor for any resource you’d want. P2V is a process to get resources onto the virtualization platform without downtime, in most cases.

SCRUM, DevOps and other agile development techniques (use by both IT developers and IT Pros) have propagated the Minimum Viable Product and Minimum Viable Service. Getting functionality displayed fast and iterating to gain a more solid solution, also has its downside. Technical Debt is just around the corner and I see cloud providers changing the tables on their customers by eliminating serious debt by completely changing the API(s). The virtue of starting over?

The more recent cloud initiatives offer even more flexibility through its Pay as you Go mantra and turnkey magic. The cloud has also made it clear to many organizations adopting it, that there is a distinction between making a solution available and getting the most out of a solution. Departments responsible for the first, have seen their responsibilities dwindle. Departments responsible for the latter, have seen their work expand from on-premises to the cloud.

… and the world is changing ever faster.

Where are we now?

Many organizations are adopting clouds. Many of them are implementing a hybrid scenario where on-premises resources, systems, platforms, applications and services interact with cloud-based resources, applications and services, in tandem.

In the ‘trust, but verify’ way of thinking, displayed with choosing this scenario (over completely cloud-based), some typical IT processes are discarded from the responsibility set of the organization, like Vulnerability Management (VM) of the cloud components, and others are becoming essential responsibilities, like Security Incident and Event Management (SIEM) and Technical State Compliance Monitoring (TSCM).

The irony

While the cloud gives organizations flexibility and agility, in these hybrid constellations organizations have to keep up with the cloud provider(s).

I feel Microsoft deserves a compliment for the way they allow their customers to postpone upgrades to their cloud resources (like the year organizations could defer the upgrade from BPOS to Office 365) and provide support for on-premises technology that is considered ‘old’ in cloud years (I believe cloud years are like dog and cat years) to give organizations the ability to plan for upgrades, like DirSync with its support ending in April 2017.

It’s not always easy to convey this message to organizations using ‘the traditional approach’, but most of them get it, eventually.

A new approach

Taking Security Incident and Event Management (SIEM) and Technical State Compliance Monitoring (TSCM) as perfect examples, the split between traditional thinking and cloud thinking becomes even more evident. Development of solutions using agile technologies, without starting with the end in sight, inherently provide technical debt. Without sufficient development velocity, the cloud component of the solution changes faster than the on-premises component is able to align, never taking off beyond minimum viable. Terms like continuous integration come to mind.

New Toolbox We have to face, that we can’t create solutions for years to come, anymore. With Technical State Compliance Monitoring (TSCM) in mind, every change in the Technical State (whether it’s in a cloud or on-premises component) needs to trigger a design reevaluation, change management processes, an n state and n+1 state and the automation scripts to actually make the change, audited using SIEM.

Yes, that means I think we need to go back to the drawing board for every large change. And yes, I think this is something that is more intricate then mere maintenance, because the world is changing faster. Maintenance is something organizations do to keep things working in a world that doesn’t change (much).

I feel we can only achieve this when we begin with Lifecycle Management (LCM) as the first step of everything we do as IT Pros.

Posted on September 23, 2016 by Sander Berkouwer in Enterprise Architecture, Recommended Practices

I’m an expert at the Dutch 2016 TechDays

TechDays 2016

Ever since I delivered a session at the Dutch 2011 TechDays with Marien de Gelder, I’ve been a regular at the Dutch TechDays events, hosted by Microsoft Netherlands’ DX team. Some TechDays editions I was invited as a speaker, other years I was asked to deliver hands-on advice to attendees as a subject matter expert (SME) or sit in on Ask the Experts sessions.

About TechDays Netherlands

TechDays is an international series of Microsoft events, hosted by Microsoft subsidiaries around the world. Microsoft Netherlands, just like last year, has decided to make the event a 2-day event, filled with both IT Professionals and Developers content. However, the focus has become more developer-oriented this year.

Microsoft Netherlands has arranged for several highly rated national and international speakers, like John Craddock, Paula Januszkiewicz, David Chappell and Corey Sanders,

Ask the Experts

Just like many of the Dutch Microsoft Most Valuable Professionals (MVPs), you’ll find me at the Ask the Experts booth at TechDays on October 5th.

If you have any questions on integrating modern authentication in your app, want to discuss Agile, SCRUM and/or DevOps or would just like to hang out with me, please don’t hesitate to approach me.

I won’t bite. Knipogende emoticon

Register

Unlike Microsoft Ignite, the Dutch TechDays still have tickets available.
Register here to be part of this event and learn to achieve more.

Fixed issues

This version introduces fixes for the following issues:

Changes to the synchronization interval do not take place until after the next synchronization cycle completes.
The Azure AD Connect wizard does not accept an Azure AD account whose username starts with an underscore (_).
The Azure AD Connect wizard fails to authenticate the Azure AD account provided, if the account’s password contains too many special characters. Error message "Unable to validate credentials. An unexpected error has occurred." is returned in this case.
Uninstalling a Staging Mode server disables password synchronization in the Azure AD tenant and causes password synchronization to fail with the active server.
Password synchronization fails in uncommon cases when there is no password hash stored on the user.
When an Azure AD Connect server is enabled for Staging Mode, the Password Write-back functionality is not temporarily disabled.
The Azure AD Connect wizard does not show the actual password synchronization and password write-back configuration, when the server is in Staging Mode. It always shows them as disabled.
Configuration changes to password synchronization and password write-back are not persisted by the Azure AD Connect wizard, when the server is in Staging Mode.

Improvements

This version introduces the following improvements:

The Start-ADSyncSyncCycle Windows PowerShell Cmdlet has been updated to indicate whether it is able to successfully start a new sync cycle or not.
The Stop-ADSyncSyncCycle Windows PowerShell Cmdlet has been introduced with this version to terminate sync cycle and operation which are currently in progress.
The Stop-ADSyncScheduler Windows PowerShell Cmdlet has been updated to terminate sync cycles and operations which are currently in progress.
When configuring Directory Extensions in the Azure AD Connect wizard, on-premises Active Directory attributes of type "Teletex string" can now be selected.

Version information

This is version 1.1.281.0 of Azure AD Connect.

Download information

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

Concluding

If the Automatic Updating functionality hasn’t already upgraded your Azure AD Connect installation to version 1.1.281.0, you can download and install this version of Azure AD Connect above.

Posted on September 12, 2016 by Sander Berkouwer in Active Directory, Azure Active Directory

Azure Multi-Factor Authentication Server version 7.1.2.1 for your convenience

This week, Microsoft released version 7.1.2.1 of its on-premises Azure Multi-Factor Authentication Server to replace the revoked Azure Multi-Factor Authentication Server v7.1.1.1 bits, due to a signing issue in the Azure Multi-Factor Authentication User Portal, that resulted in problems with some Azure Multi-Factor Authentication Server deployments.

What’s New

Allow users to choose their authentication method during user portal sign-in

After the success of the change in the Azure Multi-Factor Authentication (MFA) Adapter for Active Directory Federation Services (AD FS) that allowed users to choose their authentication method when authenticating to AD FS-connected resources, the User Portal website now also supports this feature.

This allows users to change their additional authentication method(s) in case of a lost/replaced device and or unavailability of network connectivity. It adds flexibility to users to handle these kinds of situations.

Added support for Application Name for AD FS adapter

When you install the Azure Multi-Factor Authentication (MFA) Adapter for Active Directory Federation Services (AD FS), it will register itself with the default name of “Azure Multi-Factor Authentication”. You can now change this.

Added size limit checks to LDAP Import and AD Sync

Azure Multi-Factor Authentication Server utilizes its own phonefactor.pfdata database to store its information in. You can sync user definitions into this database using LDAP and Active Directory synchronization. Now, size limit checks have been added to these import activities.

Added Page Time Limit configuration to LDAP

Next to default query size limit (10000) for LDAP, and the above size limit, an additional time limit can be configured for Use specific LDAP configuration on the Settings tab for Directory Integration.

The value for Page time limit specifies the number of seconds to wait for each page to be returned from the LDAP directory. The default value is 2 seconds.

Fixed several bugs

Every software has bugs. In version 7.1.1.1 a couple of bugs were fixed, including a bug that prevent 32-bit Internet Information Services (IIS)-based web applications from working. In version 7.1.2.1 the bug was fixed with the signing of the User Portal.

Download

Version 7.1.2.1 of the on-premises Azure Multi-Factor Authentication (MFA) Server can be downloaded via the old-fashioned Azure Management Portal or straight from the MFA Management Portal:

Log on to the Azure Portal.
In the column on the left that lists all the available items and services, scroll down until you reach ACTIVE DIRECTORY.
In the main pane, select the default directory.
Just above the list of directories, click the text MULTI-FACTOR AUTH PROVIDERS.
Click the Multi-Factor Authentication Provider that you’ve configured for your organization and is marked as Active in the STATUS column.
Click MANAGE in the bottom pane on the general settings for the Multi-Factor Authentication Provider.
This will redirect you to your tenant view of the PhoneFactor Portal.
In the main pane of the portal click on the Downloads header.
Click the Download link below the list of supported platforms.

Save MultiFactorAuthenticationServerSetup.exe to a network location where you can use it from each of the Windows Servers that have Azure Multi-Factor Authentication installed.

Concluding

Version 7.0.2.1 of Azure MFA Server provides new functionality, but also deprecates some other functionality. As an organization contemplating, evaluating or using Azure MFA Server, the impact of the depcrated features might cause you to stick with a previous version or even an alternative technology.

Related blogposts

Azure Multi-Factor Authentication Server version 7.0.2.1 is here
Azure Multi-Factor Authentication Server reaches version 7.0.0.9
Knowledgebase: You receive a “Web Service Requests must be protected by authentication” error when activating a Multi-Factor Auth app
KnowledgeBase: Users in Azure Multi-Factor Authentication Server 6.3.x and up can not select One-Way OTP or PIN options in the User Portal
KnowledgeBase: Azure MFA Portal shows error “Error communicating with the local Multi-Factor Authentication service. Please contact your administrator.”
Choosing the right Azure MFA authentication methods

About the Azure AD PowerShell Module

Using the Azure Active Directory Windows PowerShell Module, Azure AD Admins can manage several aspects of Azure Active Directory for their organizations and/or customers.

Microsoft has made versions of the MSOnline Windows PowerShell Module available for public download for a while, now. This Windows PowerShell Module comes in two variants:

version 1.0.9031.1, released March 2016
downloadable from Microsoft Download Center
version 1.1.130.0, released June 2016
downloadable from Microsoft Connect, after registration

Note:
The latest 32-bit version of the Azure Active Directory Windows PowerShell Module is version 1.0.8362.1, released on January 2015. 32-bit support has since been deprecated.

The good news on Azure AD PowerShell Module version 2

The version released into preview, today, is dubbed version 2 and it supersedes the previous two versions currently available. Officially, under the covers, the version number is version 1.1.143.0.

More frequent updates

Microsoft promises to release more frequently, than they did previously.
When the version numbers are any indication, the Azure AD Connect playbook seem to be followed and this might mean we go from semi-yearly releases to semi-monthly releases.

While it’ll mean that you’d see updates to the PowerShell Module more often, it also means you’ll see bug fixes and new functionality more often, too.

This is especially helpful to organizations on the bleeding edge of technology, but might not be the most convenient situation to be in for organization with longer adoption cycles. However, I’m confident the team will be gracious with their support statements.

Alignment with Microsoft Graph API

From a development point of view, the ‘old’ Azure Active Directory Windows PowerShell Module didn’t make much sense. When we look at Brian Arkills Azure AD Technical Diagram, we see that the ‘old’ Azure Active Directory Windows PowerShell Module communicates with Azure AD’s PowerShell API as its backend.

The ‘new’ Azure Active Directory Windows PowerShell Module will closely align with the Graph API, and, thus, offer many of the benefits the Graph API has to offer.

Tip!
If you want to learn more about Microsoft Graph API, I feel this article provides a fair introduction to get started with the Graph Explorer on graph.microsoft.io.

AzureAD instead of MSOL

A big change, that will impact all current script (repositories) is the fact that the ‘new’ Azure Active Directory Windows PowerShell Module released into preview last week, uses AzureAD as the keyword, opposed to MSOL.

So where e.g. an ‘old’ Azure Active Directory Windows PowerShell Cmdlet was named New-MSOLUser, to add a new user to the directory, the ‘new’ Azure Active Directory Windows PowerShell Cmdlet’s name is New-AzureADUser.

When you think a simple Search and Replace in PowerShell ISE or Notepad is all it takes to get your script (repository) to the ‘new’ Azure Active Directory Windows PowerShell Cmdlet, you’re in for another surprise: the parameters for some of the Cmdlets in the ‘new’ Azure Active Directory Windows PowerShell Module has changed as well.

It has to do with the same alignment with the Graph API and keeping the names of objects and parameters as close as possible to the names and objects in the Graph API. I welcome this change, because it means less ‘translations’ for objects and attributes between the various systems involved (Active Directory object attributes vs. Azure AD Connect Metaverse object properties vs. LDAP object properties, etc.).

Organizations leveraging a (signed) script repository, of course, need to invest in life cycle management for their scripts too, but in my opinion, this should’ve been part of the functionality of the script repository: Perhaps choosing for that ‘manual’ approach, because ‘Microsoft doesn’t release versions often’, wasn’t the brightest idea, though.

Concluding

The new Azure AD PowerShell Module, that is now released as version 1.1.143.0 is a new direction for managing Azure Active Directory through code.

While at first, the change might break stuff in your environment, or demand further processes within your organization, in the long run this is the way to go.

What’s New

One app for both Azure MFA and Microsoft Accounts

With the new Microsoft Authenticator, Microsoft combines multi-factor authentication for both Azure-based accounts (OrgIDs) and Microsoft Accounts (MSAs) into one app, that supports enterprise and consumer scenarios. Next to these two types of Microsoft accounts, the Microsoft Authenticator supports any service that works with OATH-based one-time passcodes, just as the old Azure Authenticator did (and the old Microsoft Authenticator before it) to allow you to use one app for all your Microsoft, Facebook and Google multi-factor authentication needs.

Push notifications

To make authentication as easy as possible, you only need to click the “approve” button in the push notification triggered by Microsoft Authenticator on your mobile device to complete the login. (And in most cases, you won’t even need to open the app to complete the approval.)

Support for wearables.

You can use an Apple Watch or Samsung Gear device to approve multi-factor authentication challenges.

Note:
Android Wear-based devices and Microsoft’s own band are currently not supported for this scenario.

Finger prints instead of passcodes

Microsoft added support for fingerprint-based approvals on both iPhones and Android-based devices.

Azure Multi-Factor Authentication allows organizations to require a PIN in addition to having possession of their registered device. With this new feature, iOS and Android users with devices supporting TouchID or Android 6.0+ Fingerprint Authentication, won’t need to enter the PIN anymore. Once set up, users just scan their fingerprint instead of entering PIN and tapping Approve.

Note:
The Microsoft Authenticator app, currently, does not support Microsoft Hello on Windows Phone-based mobile devices, like to Lumia 950.

Certificate-based authentication

The Microsoft Authenticator app adds support for enterprise customers to sign in through certificates instead of passwords using certificate-based authentication.

This way, supported Exchange ActiveSync mobile apps on iOS 9+ and Android L+-based devices can perform single sign-on (SSO) certificate-based authentication from the mobile device’s keychain to Exchange Online web-based resources, for both managed and federated Azure AD domains. In federated Azure AD domains, Office applications on iOS 9+ and Android L+ can perform certificate-based authentication against the federation server. The above features were announced in public preview and described in more detail on July 18. A detailed HowTo for deploying certificate-based authentication was posted on July 19.

Rapid Release Cycle

Microsoft is expecting to deliver new improvements at a very rapid pace.

Download and Install

Microsoft Authenticator | Google Play Store

Microsoft Authenticator | iTunes App Store

Microsoft Authenticator Beta | Windows Store

About the vulnerabilities

Microsoft Kerberos Elevation of Privilege Vulnerability (CVE-2016-3237)

A security feature bypass vulnerability exists in Windows when Kerberos improperly handles a password change request and falls back to NT LAN Manager (NTLM) Authentication Protocol as the default authentication protocol. An attacker who successfully exploited this vulnerability could use it to bypass Kerberos authentication. To exploit this vulnerability, an attacker would have to be able to launch a man-in-the-middle (MiTM) attack against the traffic passing between an Active Directory Domain Controller and the target machine. The update addresses this vulnerability by preventing Kerberos from falling back to NTLM as the default authentication protocol during a domain account password change.

The vulnerability was responsibly disclosed to Microsoft by Nabeel Ahmed of Dimension Data.

The following supported Microsoft Operating Systems are susceptible to this vulnerability:

Windows Vista with Service Pack 2 x86
Windows Vista with Service Pack 2 x64
Windows Server 2008 with Service Pack 2 x86
Windows Server 2008 with Service Pack 2 x64
Windows Server 2008 with Service Pack 2 IA64
Windows 7 with Service Pack 1 x86
Windows 7 with Service Pack 1 x64
Windows Server 2008 R2 with Service Pack 1 x64
Windows Server 2008 R2 with Service Pack 1 IA64
Windows 8.1 x86
Windows 8.1×64
Windows Server 2012
Windows Server 2012 R2
Windows RT 8.1
Windows 10 x86
Windows 10 x64
Windows 10 version 1511 x86
Windows 10 version 1511 x64
Windows 10 version 1607 x86
Windows 10 version 1607 x64

Both Server Core and Full Installation of the above Windows Server Operating Systems are susceptible to the vulnerability.

Microsoft NetLogon Elevation of Privilege Vulnerability (CVE-2016-3300)

An elevation of privilege vulnerability exists when Windows Netlogon improperly establishes a secure communications channel to a domain controller. An attacker who successfully exploited the vulnerability could run a specially crafted application on a domain-joined system. To exploit the vulnerability, an attacker would require access to a domain-joined machine that points to an Active Directory Domain Controller running either Windows Server 2012 or Windows Server 2012 R2. The update addresses the vulnerability by modifying how Netlogon handles the establishment of secure channels.

The following supported Microsoft Operating Systems are susceptible to this vulnerability:

Windows 8.1 x86
Windows 8.1×64
Windows Server 2012
Windows Server 2012 R2
Windows RT 8.1

Both Server Core and Full Installation of the above Windows Server Operating Systems are susceptible to the vulnerability.

About the update

Update KB3167679 addresses the vulnerability described as CVE-2016-3237, except on Windows 10, where you’d need to install KB3176492, KB3176493 or KB3176495 on Windows 10, Windows 10 version 1511 and Windows 10 version 1607, respectively).

Update KB3177108 addresses the vulnerability described as CVE-2016-3300.
On Windows Server 2012, however, KB3177108 fixes both vulnerabilities.

A system restart is required after you apply this security update.

Non-security-related fixes that are included in this security update

This security update also fixes a non-security-related issue in scenarios with domain-joined Scale Out File Server (SoFS) on domainless clusters: When an SMB client that is running either Windows 8.1 or Windows Server 2012 R2 connects to a node that is down, authentication fails.

Mitigating factors

The vulnerability described as CVE-2016-3237 cannot be exploited when BitLocker is enabled with a PIN or USB key and the machine is turned off.

Microsoft has not identified any mitigating factors for the vulnerability described as CVE-2016-3300.

Workarounds

Microsoft has not identified any workarounds for these vulnerabilities.

Known issues

If you install a language pack after you install this update, you must reinstall this update.

Currently, the ability to change the passwords of disabled or locked-out accounts is supported only by NTLM. It is not supported by the Kerberos protocol. This security update prevents the Negotiate process from falling back to NTLM for password change operations when Kerberos authentication fails. Therefore, you will no longer be able to change the password for disabled or locked-out accounts after you install this security update. It is not secure to change disabled or locked-out user account passwords by using NTLM. This is why the ability of Negotiate to fall back to NTLM is disabled by this security update.

Note:
Even though you can no longer change the password for disabled or locked accounts, you can set the password by using Active Directory-based tools.

Call to action

I urge you to install the necessary security updates (KB3167679, KB3176492, KB3176493, KB3176495 and/or KB3177108 on systems in a test environment as soon as possible, assess the risk and possible impact on your production environment and then, roll out this update to systems in the production environment.

Additionally, any support and/or incident response practices involving resetting passwords for disabled or locked-out accounts should be changed to use Active Directory-based tools.

What’s new

Version 7.0.2.1 of the Azure Multi-Factor Authentication Server adds the following additional functionality:

Prerequisites checks

The installers in the 7.0.0.9 release of Azure Multi-Factor Authentication Server were missing checks for the appropriate prerequisites, such as checking for Visual C++ Redistributable Package Update 1. Organizations that upgraded their Azure MFA Servers from version 6.3.1 to 7.0.0 didn’t experience these checks missing, but for new installations of Azure MFA Server, this resulted in a less than satisfactory installation experience. The missing prerequisites checks were added to all installers in version 7.0.2.1.

Deprecated support for SAML

The Azure Multi-Factor Authentication (MFA) User Portal will stop supporting the SAML federation protocol to act as an Identity Provider (IdP).

Deprecated support for installations on 32-bit OSs

You can install Azure Multi-Factor Authentication Server components on all supported Windows Server versions. While this provides great flexibility to organizations, it presents the possibility for them to install Azure MFA Server on the latest version of Windows Server that was available as a 32-bit Operating System (OS): Windows Server 2008. This flexibility is being deprecated. The good news is this provides the additional security from the 64-bit Operating System layer (like signed drivers) to Azure MFA Server, inherently a security solution, too.

Fixed bug that resulted in an error when importing OATH tokens

When you attempted to import OATH-based tokens in Azure MFA Server 7.0.0.9, you received an error. The bug causing this error has been fixed in this version.

Fixed a bug that prevented MFA Server from writing to syslogs

Apparently, there was a bug in Azure MFA Server that prevented the server to write to syslog servers. The bug causing this behavior has been fixed in this version.

Other minor bug fixes

Of course, a variety of other minor bugs has also been squashed.

Download

Version 7.0.0.9 of the on-premises Azure Multi-Factor Authentication (MFA) Server can be downloaded via the old-fashioned Azure Management Portal or straight from the MFA Management Portal:

Log on to the Azure Portal.
In the column on the left that lists all the available items and services, scroll down until you reach ACTIVE DIRECTORY.
In the main pane, select the default directory.
Just above the list of directories, click the text MULTI-FACTOR AUTH PROVIDERS.
Click the Multi-Factor Authentication Provider that you’ve configured for your organization and is marked as Active in the STATUS column.
Click MANAGE in the bottom pane on the general settings for the Multi-Factor Authentication Provider.
This will redirect you to your tenant view of the PhoneFactor Portal.
In the main pane of the portal click on the Downloads header.
Click the Download link below the list of supported platforms.

Save MultiFactorAuthenticationServerSetup.exe to a network location where you can use it from each of the Windows Servers that have Azure Multi-Factor Authentication installed.

Concluding

Related blogposts

Azure Multi-Factor Authentication Server reaches version 7.0.0.9
Knowledgebase: You receive a “Web Service Requests must be protected by authentication” error when activating a Multi-Factor Auth app
KnowledgeBase: Users in Azure Multi-Factor Authentication Server 6.3.x and up can not select One-Way OTP or PIN options in the User Portal
KnowledgeBase: Azure MFA Portal shows error “Error communicating with the local Multi-Factor Authentication service. Please contact your administrator.”
Choosing the right Azure MFA authentication methods

Group memberships in Active Directory

When Active Directory shipped with Windows 2000 Server, it came with group membership limits of 5,000 members. In the Windows Server 2003 Forest Functional Level (FFL), this limitation was lifted with the introduction of link-value replication (LVR).

To enable this feature, the Active Directory Forest Functional Level (FFL) needs to be at least Windows Server 2003 interim and any groups expecting to hit the 5,000 limit, need to be cleared of their memberships. After that, the members can be added back to change the way of replication.

The Active Directory Maximum Limits – Scalability documentation further states:

So far, testing in this area has yet to reveal any new recommended limits to the number of members in a group or any other linked multivalued attribute. Production environments have been reported to exceed 4 million members, and Microsoft scalability testing reached 500 million members.

Essentially, Active Directory Domain Services (AD DS) does not offer group membership limitations, as long as the environment is running a currently supported Forest Functional Level (FFL).

The group membership limit in Azure AD

Groups in Azure Active Directory, that are synchronized from on-premises to Azure Active Directory using Azure AD Connect, are limited to 50,000 members.

Note:
Groups in Azure Active Directory, that are still synchronized from on-premises to Azure Active Directory using the soon-to-be-deprecated DirSync tool are limited to 15,000 members.

The 50,000 group membership limit applies to:

Synced security groups
Security groups, synchronized from your on-premises Active Directory Domain Services environment(s) to Azure Active Directory
Synced distribution groups
Distribution groups, synchronized from your on-premises Active Directory Domain Services environment(s) to Azure Active Directory

The limit does does not apply to:

Azure AD-only groups
When a group only lives in Azure Active Directory, the limit does not apply.
Nested groups
The limit applies to memberships per single group. While a group that is a member of a group counts as a membership for that latter group, its memberships do not.
Critical security groups
Security-enabled groups with the attribute isCriticalSystemObject configured as true. These objects, by default, are not synchronized and include most of the built-in groups. You can get an overview of these groups, using the following PowerShell Oneliner:

Get-ADGroup -filter ‘iscriticalsystemobject -eq $true’ | ft

Mail-enabled groups without SMTP e-mailaddresses
Security and distribution groups that have no “SMTP:”address entry in the proxyAddresses attribute and have an empty mail attribute, by default, are not synchronized.

Indications of hitting the limit

When the group membership limit is hit, the Azure AD Connect Sync Engine will stop synchronizing to Azure Active Directory.

In the Application log of the Windows Server on which Azure AD Connect is installed and running, you’d find Event ID 107 errors with source Directory Synchronization, and Event ID 6803 with source AD Sync, along with several other events.

Additionally, in the Synchronization Service Manager of Azure AD Connect, you would see that Exports for the Azure Active Directory connector would report stopped-server-down and the Delta Synchronization for the Active Directory connector has completed-sync-errors as its status.

When you drill down into the flow error for the latter, you’d see a mention of the sync-rule-error-function-triggered for the Connector Space Object Properties of the group that is causing the error.

Circumventing the limit

Ways to circumvent the limit are:

Remove memberships from the on-premises Active Directory group, before synchronizing the group to Azure Active Directory
Empty the Active Directory Recycle Bin
Create the group in Azure Active Directory with memberships and don’t synchronize the on-premises group

Solving the situation

You will need to contact Azure support to get the situation fixed.
Support request can easily be initiated through the Help and Support section of the Azure Portal.

While you can solve all the other warnings, errors, etc., the Azure Active Directory connector will remain broken and report stopped-server-down.

The situation feels comparable to Active Directory Domain Controllers that suspects replication partner(s) of UPN Rollbacks. They will turn their back and not replicate anymore. We know how to deal with that situation, but we don’t have the ability to run repadmin.exe on Azure Active Directory. Knipogende emoticon

Thus, preventing the situation from happening is preferable to detecting and then getting the situation solved by Azure support, especially when you have people from higher management breathing in your neck to solve synchronization fast and questioning Microsofts Hybrid Identity strategy in the process.

Detecting Active Directory groups with 50,000+ members

Use the PowerShell script below to detect groups in the on-premises Active Directory environment, the machine you run it from, is joined to:

cls
“Started Inventory.”
$Groups = Get-ADGroup -filter “*” -Properties DistinguishedName,Members
“Inventory stage done.”
“Started Analysis.”
ForEach ($Group in $Groups) {
$Members = $Group.Members | Measure-Object
if ($Members.Count -gt 49999) {
Write-Host -foregroundcolor Yellow “Group $Group might cause sync problems.”
}
}

“Analysis done.”

Concluding

When you suspect your on-premises Active Directory Domain Services environment(s) have groups with more than 50,000 or more members, it’s a good idea to know the Azure Active Directory group membership limit up front.

a blog by Sander Berkouwer

About the Azure Active Directory Passport Library for Node.js

Affected versions

Call to Action

Related knowledgebase articles

Further Reading

The traditional approach

The world has changed

Where are we now?

The irony

A new approach

About TechDays Netherlands

Ask the Experts

Register

Further reading

Fixed issues

Improvements

Version information

Download information

Concluding

What’s New

Allow users to choose their authentication method during user portal sign-in

Added support for Application Name for AD FS adapter

Added size limit checks to LDAP Import and AD Sync

Added Page Time Limit configuration to LDAP

Fixed several bugs

Download

Concluding

Related blogposts

Further reading

About the Azure AD PowerShell Module

The good news on Azure AD PowerShell Module version 2

More frequent updates

Alignment with Microsoft Graph API

AzureAD instead of MSOL

Concluding

Further reading

What’s New

One app for both Azure MFA and Microsoft Accounts

Push notifications

Support for wearables.

Finger prints instead of passcodes

Certificate-based authentication

Rapid Release Cycle

Download and Install

Further reading

About the vulnerabilities

Microsoft Kerberos Elevation of Privilege Vulnerability (CVE-2016-3237)

Microsoft NetLogon Elevation of Privilege Vulnerability (CVE-2016-3300)

About the update

Non-security-related fixes that are included in this security update

Mitigating factors

Workarounds

Known issues

Call to action

Further reading

What’s new

Prerequisites checks

Deprecated support for SAML

Deprecated support for installations on 32-bit OSs

Fixed bug that resulted in an error when importing OATH tokens

Fixed a bug that prevented MFA Server from writing to syslogs

Other minor bug fixes

Download

Concluding

Related blogposts

Further reading

Group memberships in Active Directory

The group membership limit in Azure AD

Indications of hitting the limit

Circumventing the limit

Solving the situation

Detecting Active Directory groups with 50,000+ members

Concluding

Related knowledgebase articles

Further reading

Microsoft MVP (2009-2016)

Veeam Vanguard (2016)

Sponsor

Search this site