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

js-logoYesterday 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.

 

Related knowledgebase articles

3187742 Security update for the Passport-Azure-AD for Node.js library 

Further Reading

Security vulnerability details for passport-azure-ad <1.4.6, 2.0.0 
Microsoft Azure Active Directory Passport CVE-2016-7191 Authentication Bypass Vulnerability

0  

Why Lifecycle Management can’t be a mere afterthought anymore

The world we live in has changed significantly over the past few years. We can no longer afford to use our traditional approach to IT. We need to adopt a new way of thinking. In my opinion, this way of thinking doesn’t end with maintenance, but starts with lifecycle management.

 

The traditional approach

Old ToolboxEnterprises 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.

Azure AD Connect Lifecycle Management on a typical Agile Backlog

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 ToolboxWe 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.

0  

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.

 

Further reading

I’ll be hosting three ‘Ask me Anything’ sessions at TechDays Netherlands 2015 
I’m speaking at the Dutch 2014 TechDays

0  

Azure AD Connect version 1.1.281.0 has been released

Last week, Microsoft released a new version of Azure AD Connect for all your on-premises Active Directory Domain Services and LDAP v3 to Azure Active Directory, and thus Office 365, synchronization needs.

Version 1.1.281.0 of Azure AD Connect, dubbed the August 2016 release, adds fixes and improvements.

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.

0  

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.

Edit LDAP Configuration for Directory Integration in the MFA Server Management UI (click for original screenshot)

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:

  1. Log on to the Azure Portal.
  2. In the column on the left that lists all the available items and services, scroll down until you reach ACTIVE DIRECTORY.
  3. In the main pane, select the default directory.
  4. Just above the list of directories, click the text MULTI-FACTOR AUTH PROVIDERS.
  5. Click the Multi-Factor Authentication Provider that you’ve configured for your organization and is marked as Active in the STATUS column.
  6. Click MANAGE in the bottom pane on the general settings for the Multi-Factor Authentication Provider.
  7. This will redirect you to your tenant view of the PhoneFactor Portal.
  8. In the main pane of the portal click on the Downloads header.
  9. 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

Further reading

Azure Multi-Factor Authentication – Part 1: Introduction and licensing
Azure Multi-Factor Authentication – Part 2: Components and traffic flows
Azure Multi-Factor Authentication – Part 3: Configuring the service and server
Azure Multi-Factor Authentication – Part 4: Portals
Azure Multi-Factor Authentication – Part 5: Settings
Azure Multi-Factor Authentication – Part 6: Onboarding
Azure Multi-Factor Authentication – Part 7: Securing AD FS
Azure Multi-Factor Authentication – Part 8: Delegating Administration

0  

Why the Azure Active Directory Windows PowerShell Module is good news

Windows PowerShellLast week, Microsoft announced a new preview version of the Azure Active Directory Windows PowerShell Module.

This is good news! Let me tell you why.

 

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:

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.

Further reading

Azure AD PowerShell: Public Preview    
Azure Active Directory preview cmdlets for group management 
Using Azure PowerShell with Azure Resource Manager 
Azure Active Directory PowerShell Module – Version 1.0 
How to install and configure Azure PowerShell

0  

Microsoft Authenticator – One easy-to-use app for all your multi-factor authentication needs

Microsoft AuthenticatorAs announced on July 25, today, Microsoft’s new Microsoft Authenticator app replaces both its Azure Authenticator and Microsoft Account app as the one easy-to-use app for all your multi-factor authentication needs.

Now, I’m not sure whether Microsoft will use the above slogan for the app, but to me it sums up what this new app offers.

 

Being involved in several Azure Multi-Factor Authentication projects, I’ve been deploying and using the Azure Authenticator app (and its predecessor, the Multi-Factor Auth app) to Windows Phone, iOS an Android-based devices in the past couple of years. Additionally, Dave looked at using the Microsoft Authenticator Windows Phone app with Google back in 2013. Yes, it was named the Microsoft Authenticator app, back in those days, too. That’s OK, because Nokia will soon be making mobile phones too and come full circle again, too…

People using the Azure Authenticator app on Windows Phone, iOS an Android-based devices, will be automatically upgraded to the new Microsoft Authenticator app, starting today. Existing accounts, already configured in existing Azure Authenticator installations will be upgraded automatically. Users of the Microsoft account app for Android will receive a prompt to download the new app.

 

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

 

Further reading

Microsoft Authenticator – Coming August 15th! Supports #AzureAD & Microsoft acct!
Microsoft to release all new Authenticator app for iOS, Android and Windows devices
Moving to the new Azure Authenticator app
ADFS: Certificate Authentication with Azure AD & Office 365
#AzureAD: Certificate based authentication for iOS and Android now in preview!
Microsoft Authenticator combines authenticator products, adds new features
Microsoft rolls out a new Authenticator app for Android and iOS, makes 2FA simpler
CodeChannels – Microsoft Authenticator
Microsoft Merges Its Authenticator Apps Into One, Adds One-Button Approval
Microsoft releases new Authenticator experience on Android
Microsoft Authenticator gets Google and Facebook account support

0  

Security Thoughts: Update for Windows Authentication Methods (KB3178465, MS16-101, CVE-2016-3237, CVE-2016-3300, Important)

Yesterday, during its August Patch Tuesday, Microsoft released security update KB3178465 for Windows Authentication Methods, among other security-related updates.

This update addresses two vulnerabilities in Microsofts implementation of its authentication methods in Active Directory scenarios: CVE-2016-3237 and CVE-2016-3300.

 

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.

Further reading

Microsoft Security Bulletin Summary for August 2016
August Patch Tuesday 2016
Microsoft Patch Tuesday – August 2016

0  

Azure Multi-Factor Authentication Server version 7.0.2.1 is here

After March’s major 7.0.0.9 release of Azure Multi-Factor Authentication Server, it’s good to see an update for the product released in a timely fashion to address the issues, that inevitable rise with a major release, as oposed to minor releases. As the Azure MFA team in Redmond is headed by a new manager, since then, it’ll also be interesting to see how this change affects other changes.

 

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:

  1. Log on to the Azure Portal.
  2. In the column on the left that lists all the available items and services, scroll down until you reach ACTIVE DIRECTORY.
  3. In the main pane, select the default directory.
  4. Just above the list of directories, click the text MULTI-FACTOR AUTH PROVIDERS.
  5. Click the Multi-Factor Authentication Provider that you’ve configured for your organization and is marked as Active in the STATUS column.
  6. Click MANAGE in the bottom pane on the general settings for the Multi-Factor Authentication Provider.
  7. This will redirect you to your tenant view of the PhoneFactor Portal.
  8. In the main pane of the portal click on the Downloads header.
  9. 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 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

Further reading

Microsoft Virtual Academy – How to Upgrade to Latest Azure MFA Server Version
How to upgrade / update current MFA version to the latest?
Azure Multi-Factor Authentication – Part 1: Introduction and licensing
Azure Multi-Factor Authentication – Part 2: Components and traffic flows
Azure Multi-Factor Authentication – Part 3: Configuring the service and server
Azure Multi-Factor Authentication – Part 4: Portals
Azure Multi-Factor Authentication – Part 5: Settings
Azure Multi-Factor Authentication – Part 6: Onboarding
Azure Multi-Factor Authentication – Part 7: Securing AD FS
Azure Multi-Factor Authentication – Part 8: Delegating Administration
New version of Azure MFA Server available (7.0.0)

0  

Default checks to perform when implementing Hybrid Identity, Part 4: Groups with large memberships

Microsoft has introduced an impressive array of technologies and an awesome vision on Hybrid Identity:

Hybrid Identity

Their vision entails seamless access to corporate resources, services and applications for people, no matter where these resources, services and apps are located (either on-premises or in the cloud) while in the mean time allowing for strong authentication and granular authorization.

While Microsofts Azure Active Directory Hybrid Identity Design Considerations document details a lot of pitfalls you might want to avoid while implementing Microsofts Hybrid Identity technologies in the areas of process and architecture, my projects, on the other hand, have shown technical customer configurations beyond belief.

In this series I’ll detail these configurations, how they ruin Hybrid Identity dreams and how to fix them.

Today, let’s discuss group memberships for groups synchronized from your on-premises Active Directory Domain Services environment(s) to Azure Active Directory.

This is a scenario I experienced myself, and I think this is a limit a large organization may run into.

 

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.

EventID 107 with Source Directory Synchronization: Error code: 16. Error Description: Synchronization has been stopped. Your company has exceeded the number of objects that can be synchronized.

EventID 6803 with source ADSync: The management agent failed on run profile "Export" because the server encountered errors.

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.

Connector Space Object Properties

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.

Related knowledgebase articles

2812409 You receive a “This company has exceeded the number of objects that can be synchronized” error in a directory synchronization report
2643629 One or more objects don’t sync when the Azure Active Directory Sync tool is used

Further reading

Conquer Active Directory’s Built-In Limits
LDAP Query Basics
Working with Active Directory using PowerShell ADSI adapter
Event ID 2095 and The USN Rollback Adventure

0