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.

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.

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


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.


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.

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


Azure Multi-Factor Authentication Server version is here

After March’s major 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 of the Azure Multi-Factor Authentication Server adds the following additional functionality:

Prerequisites checks

The installers in the 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

Deprecated support for SAML

The Azure Multi-Factor Authentication (MFA) adapter for Active Directory Federation Services (AD FS) will stop supporting the SAML federation protocol.

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



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



Version 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
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)


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.

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:

“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.”



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


Recommended Practices for your Hybrid Identity Admin accounts

Recommended PracticesI’ve been involved in quite some Microsoft Hybrid Identity implementations: Big and small implementations, with and without AD FS next to Azure AD Connect, with Azure AD Connect and 3rd party tooling.

One thing though, all these implementations had in common was the admin account(s) they needed done right.

You can dial a lot of knobs when implementing Hybrid Identity. One of the more important knobs is the one that turns on federated single sign-on to your organization’s on-premises Active Directory Federation Services (AD FS) implementation. This particular setting is changed using the Azure Active Directory PowerShell Module.

Many early adopters of Microsoft Hybrid Identity using AD FS have already experienced a common pitfall: when you’ve converted a DNS Domain in Azure Active Directory to federated, you need AD FS to authenticate. Even to change the setting from federated back to standard.

The main reason to convert from federated to standard is because there’s something wrong with the AD FS implementation…

So, how do you cope with this challenge?


Global admins and/or on-premises admins

One of the first things, prospect admins learn during training is to use separate accounts for admin purposes and day-to-day usage, like e-mail and browsing. This is based on the principle of least (administrative) privilege.  The same holds true for Azure Admins:

You don’t want to assign Global Admin rights in Azure Active Directory to your day-to-day account.

In most on-premises environments, admin accounts are prefixed with adm in their username or postfixed with a number. The latter number strategy allows for a quick overview of the impact of an account; when 1 represents print admin or account operator rights and 9 represents both on-premises Enterprise Admin and Azure Global Admin, the number quickly indicates how much impact deleting the account might have or what account to use for a specific task.

However, there is a dark side to this practice: a person with malicious intent, might quickly target accounts of the most interest.

Admin roles in Azure Active Directory

Azure Active Directory offers the following administrator roles:

Table with Admin Roles in Azure Active Directory - Global administrator, Privileged role administrator, Billing administrator, Password administrator, Service administrator, User administrator, Exchange administrator, SharePoint administrator, Skype for Business administrator, AdHoc license administrator, Compliance administrator, Directory readers, Directory writers, Email verified user creator, Mailbox administrator, Partner tier1 support, Partner tier2 support, Workplace device join, Security administrator and Security reader

These roles can be the basis for number postfixing your Azure Active Directory admins.

For Azure Resource Management (ARM)-based resources, you can additionally add your own Roles-based Access Control (RBAC) for finer-grained access management. While the users and groups would live in Azure Active Directory, none of the Azure Active Directory resources, themselves, are ARM-based, momentarily.


Azure Active Directory Privileged Identity Management

AzureAD PIMAzure Active Directory Privileged Identity Management (PIM) allows for non-permanent and more granular just-in-time admin roles. Auditing and reporting allows for insights on the actual usage of administrative privilege and accounts that no longer need administrative privileges. By acting on these insights, the attack surface of privileged accounts is minimalized

Azure Active Directory Privileged Identity Management (PIM) is currently in preview.


Multi-factor Authentication

Authentication is the process of confirming the truth of an attribute of an entity – in short, confirming its identity. The most common attribute checked to confirm the identity of the person signing in with a user account (object) in networking environments is the password attribute. The password attribute is a value that the person sets. It is something the person (can prove he/she) knows. To make authentication more reliable and, thus, confirm the identity without a doubt, multiple authentication factors may be combined. For instance, something the person (can prove he/she) has in physical possession and/or something the person (can prove he/she) is are authentication factors that can be used for Multi-Factor Authentication beyond mere password validation.

Microsoft offers free Multi-Factor Authentication for Global Admins in Azure Active Directory. This solution offers reliable authentication for these accounts.

Azure Multi-Factor Authentication for Admins is only free, when Azure Active Directory has not yet been configured with a consumption-based license (pey-per-authentication) for Azure Multi-Factor Authentication.

It is highly recommended to enable multi-factor authentication on each account that has the Global Administrator role assigned in Azure Active Directory. If your organization, utilizes other admin roles (either the pre-defined roles, Azure AD PIM roles and/or Azure ARM RBAC) MFA could be applied according to the combination of (some sort of) classification of the administrative privilege(s) and day-to-day burden.

For instance, you may decide not to enforce MFA for logins for User management administrators, as their privileges are not as high-impact as other privileges and these people may need to use their privileges often.

From a technical perspective, the tooling used, needs to support modern authentication. If you want to use multi-factor authentication for admin purposes, you will need to use at least the following versions of the admin tools:

  • Version 8362.1 of the Azure Active Directory PowerShell Module (released January 19, 2015)
  • Version of Azure AD Connect (released February 2016)


The curse of the Microsoft Account

With Windows 8, Microsoft introduced the Microsoft Account. This account, formerly known as a Windows Live ID, can be used to log onto Windows devices ever since or provide single sign-on to consumer-based Microsoft services when logged on with a domain account (Windows Store, Cortana, etc.). The functionality is called the Connected Accounts feature. This was Microsoft’s solution to bridging the work-life divide. However, Microsoft accounts are not company-owned, but personally-owned.

Microsoft Accounts can also be used in Azure Active Directory. They can even be assigned admin roles (although some limitations apply).

You should really need to decide whether you want to assign roles to accounts your organization does not own and/or manage.

I feel strongly, that admin accounts with e-mail addresses like are not that professional. When hiring a consultant, this kind of administrative practices might lead to some raised eyebrows.

To add to injury, several display and sign-in problems occur when admins use Microsoft Accounts with the same domain part (everything after the @-sign) as your organization does.

There are two ways to create an Azure Active Directory directory:

  1. The Azure route
  2. The Office365 route

Azure tenant names, created by default, when the Azure tenant is created from a Microsoft account might raise the same eyebrows: For the Microsoft account you’ll end up with the tenant name. Again, think of when the person of the named account leaves, the tenant name will leave a permanent mark on the organization.

When you take the Office365 route to create the Azure Active Directory tenant, the tenant name for Azure Active Directory is the same as the tenant name for Office365. This name is defined when you create the Office365 tenant.


To sync or not to sync admin accounts

In line with the principle of least administrative effort, you might not even want to assign Azure admin privileges to on-premises admin accounts, that are synchronized to Azure Active Directory.

Although this might result in a situation where an admin person needs to use six accounts, instead of having the benefit of single sign-on, like everyone else, it does provide a separation of administrative privileges and fault domains…

How to name these accounts? might not look very sexy and might possibly cause RSI, it does the job for a privileged account that is assigned the Service Administrator role in Azure Active Directory. A separate (default) vanity UPN Suffix might become a requirement when the person to which the original Microsoft account belongs, leaves the organization.

Don’t forget to add other Global Admins and remove the original Microsoft Account from the Global Administrator role and/or your Azure directory.


To federate or not to federate admin accounts

When synchronizing accounts. another big question remains: To federate admin accounts, or not.

In my opinion, federation offers benefits for everyone. However, I don’t feel that strongly for admin accounts. Password Synchronization using Azure AD Connect offers a solution that is equally beneficial for admins, yet provides an exit strategy for when the on-premises Active Directory Federation Services (AD FS) implementation fails.

Since federation in Azure Active Directory is governed using DNS domains, a quick and dirty way of removing admin accounts from the scope of federation is by assigning a separate userPrincipalName (UPN) Suffix to admin accounts on-premises. For instance can be used for admins, while is used for the day-to-day user accounts.

Converting child and parent domains

One of the reasons why I choose in the above example is because this introduces an entirely new DNS Domain, instead of a subdomain.

While you can use subdomains for your admin accounts, it is not recommended: When converting domains in Azure Active Directory (from standard to federated, and vice versa), by default, all subdomains will be converted too.

The way around this, although unsupported, is to place the parent domain and the child domain in different Azure tenants.



Use these recommended practices for Azure Admins in Hybrid Identity scenarios:

  • Separate admin privileges from day-to-day accounts
  • Deploy Multi-factor Authentication
  • Deploy Azure AD Privileged Identity Management (PIM)
  • Use admin account and password synchronization for your convenience
  • Don’t use Microsoft Accounts
  • Don’t federate admin accounts
  • Assign admin accounts a separate UPN Suffix on-premises and/or in Azure AD


Related blogposts

New features in AD DS in Windows Server 2012, Part 9: Connected Accounts
Azure AD Connect is here

Further reading

Security Best Practices for using Azure MFA with Azure AD accounts
Use role assignments to manage access to your Azure Active Directory resources AzureAD updated with new admin roles
Azure Active Directory documentation
Active Directory from on-premises to the cloud – Azure AD whitepapers
Azure Active Directory Part 4: Group Claims
Cloud security controls series: Azure Active Directory‘s Access and Usage Reports
Assigning administrator roles in Azure Active Directory
Managing Azure AD from the Azure Portal 1– Sign Up with an Organizational Account
Managing Azure AD from the Azure Portal 3– Add a Co-Admin, Use 2FA
Changing Service Administrator and Co-Administrator when logged-in with an organizational account


Pictures of ITPROceed 2016

Two weeks ago, I presented at ITPROceed 2016 at Utopolis in Mechelen, Belgium. I was invited back as a speaker, as I presented on ITPROceed 2015 previously.

I drove off in the first daylight from my home, since it’s a 2-hour drive from my house to the venue in Mechelen, driving past Rotterdam and Antwerpen, and their traffic challenges, on the way over.

Rotterdam in the early morning light (click for larger photo)

In Mechelen, I was overtaken and greeted by a guy in a white BMW. Apparently, Adnan Hendricks, my former colleague at OGD and now working for Microsoft Netherlands. We didn’t drive together this year, but at least shared the last few miles of tarmac.

I parked the car and saw Mark Eveleens and Richard van Zundert of OpsLogix fame:

Breakfast Reception at ITPROceed (click for larger photo, courtesy of the ITPROceed Organization)

After some light breakfast, I checked in at the VIP (cinema)room, which was in use as the speaker room (like last years). I received a new ITPROceed speaker shirt and met up with more familiar faces, especially the CoreTech Benelux people; Kenny Buntinx, Dieter Wijckmans and Tim De Keukelaere and the Microsoft BeLux delegation; Sigrid Vandenweghe and Peter de Tender.

The VIP Room, acting as Speaker Room (click for larger photo)Kenny Buntix offering to iron the shirt? (click for larger photo)

With Rasmus Hald sitting directly behind me, I made some last-minute tweaks to the presentation and added a backup demo, that would circumvent any Azure Portal goofiness I might experience… Remember: My demo’s at ITPROceed were based on Windows 10 build 14361 (released four days earlier) and the current release of Azure Active Directory… Yes, I like to live dangerously. Knipogende emoticon

After lunch, my 50-minute time slot emerged and I got ready to present on ‘Azure Active Directory Join for Windows 10 Bring-Your-Own Scenarios’.

Title Slide (click for larger photo)
Last moment preparations before the session (click for larger photo)Yep, that's what this session is about... (click for larger photo)
Beginning the presentation (click for larger photo, courtesy of the ITPROceed organization)And we have lift off! ;-) (click for larger photo, courtesy of the ITPROceed organization)
Enjoy the Show! (click for larger press shot courtesy of the ITPROceed organization)
A lot of people in the audience taking pictures. Fun!

I’d like to thank all the attendees of the session. You were great!

After the session I wrapped up my equipment and headed back to the speaker room to ditch my stuff; With my presentation done, I could catch up with old acquaintances (Hi, Arlindo!) and sponsors (VEEAM and GlobalKnowledge among others), and have conversations with my fellow geeks (Hi, Didier!).

Joining the crowd in the central hallwayTwittering all the ITPROceed goodness with Rasmus (click for larger photo, courtesy of the ITPROceed organization)

After the closing keynote on ‘Data is the new electricity’, and the ITPROceed raffle, it was time for the ITPROceed BBQ.

The ITPROceed Raffle, a recurring spectacle! (Click for larger photo, courtesy of the ITPROceed organization)The ITPROceed BBQ, a new spectacle! (photo courtesy of the ITPROceed organization)
The wonderful group of people running ITPROceed. You know who you are. You are great! Thank You!

I just love how Azure, Azure Stack and Azure Steak come together like that! Emoticon die tong uitsteekt

A quiet drive back home to give all these new impressions and thoughts the right place in my head later, I arrived home with my family.

Thank you!


When you’re interested in all the pictures, shared by the ITPROceed organization, take a look here, as I have only shared a selection of these pictures.

Related blogposts

I’ll be speaking at ITPROceed 2016
Pictures of ITPROceed 2015
I’ll be speaking at ITPROceed 2015
Pictures of the Belgian 2013 Community Day


Pictures of the Ajilon ‘Minimalism in Windows Server’ event

AjilonAs both Jeff Wouters  and I announced on our blogs, on Wednesday, June 22, 2016, we presented on Server Core and Nano Server during our ‘Minimalism in Windows Server’ event, sponsored by Ajilon IT.

It was great fun with a couple of familiar faces and a lot of new faces, keen on hearing what Jeff and I meant with that catchphrase, and then, what the implications are for future deployments, migrations and operations.

Jeff and I arrived early, even though the weather of the night before and their resulting floods and traffic prevented manyothers  from arriving at the designated time. We sat down in the Kloostertuin (Convent garden), where we had our first drinks and shook the first hands of the evening: Ben Gelens. Glimlach

De kloostertuin (click for larger photo, by Leerhotel Het Klooster)

The people from Ajilon IT booked the Refter room at the Leerhotel and kicked off the evening with a little introduction to their company and what they have to offer to people working with them and for them. Jeff, Ben and I sat on the benches in the back of the room, preparing our demos, tweaking our slides and having some fun.

Ben and me on the benches (click for original photo by Ben Gelens)The three amigos (click for original photo by Jeff Wouters)

After dinner, Ajilon provided a short and amusing introduction. I started the first presentation on Server Core, its origins, its many improvements over the years and its apparent faith.

My favorite presentation style: with beer (click for original photo by Jeff Wouters)
Presenting (click for original photo by Ajilon IT)Look, mom! My new 'about me' slide! (click for original photo)

During the handover to Jeff, I received a question on Desired State Configuration vs, Group Policy, which I let Ben answer, since he was sitting in front row and nodding for a chance to answer it. Glimlach

After that brief cooperation, Jeff put Server Core out of its misery and introduced the Nano Server installation option for Microsoft’s upcoming Windows Server 2016:

Jeff presenting on Nano Server (click for larger photo)Our audience for the Ajilon IT event. Thank you!

Around 9PM we told our audience that, from our perspective, questions are so much nicer when you’re eating bitterballen. After receiving the nice gifts from Ajilon, we headed back to the Kloostertuin for these snacks, some more fun. Well after 10PM we, eventually, went home.

We had fun!

Thank you.


Related blogposts

I’m hosting a ‘Minimalism in Windows Server’ event with Jeff Wouters and Ajilon


Ten years of blogging

10, Downing street

Ten years ago, on June 23, 2006, I posted the first blog post here.

Today, over 700 posts and three whitepapers later, I’m still enjoying blogging, sharing and informing you on Microsoft products, technologies, features and news.

To me, it’s not something that is tied to an employer, residence, a specific time of the day or even if some country is part of an continental union… That’s why I’m sure I can share that I’ll continue blogging, sharing and informing you.

Enjoy! Glimlach


From the Field: The Case of the Unreanimatable Tombstone Objects

Windows Troubleshooting

Troubleshooting stories from the field are the best. That’s why I like writing them down. Although, sometimes they might appear as straight cases of schadenfreude, I feel there are lessons to be learned for anyone, if you’re willing to look closely and listen carefully.

Today, I saw someone stress over an ‘Oops!’ situation that occurred straight after a long Exchange to Office 365 migration weekend, that, as a consequence, went sour all of a sudden. Thinking he was doing the right things, the person actually made it worse. But, it’s a long story, so let’s begin at the beginning.


The situation

After a long migration weekend, involving a Microsoft Exchange to Office365 migration and Azure AD Connect for Hybrid Identity, someone on the project team accidentally deleted an entire Organizational Unit (OU) in Active Directory Domain Services. By the time the error was detected, Azure AD Connect had synchronized the changes and orphaned the Office365 mailboxes for the deleted user accounts…

Although the Active Directory environment consisted of Windows Server 2012-based Domain Controllers running the Windows Server 2012 Domain Functional Level (DFL) and Forest Functional Level (FFL), it didn’t have the Active Directory Recycle Bin enabled.

Getting the objects back, then, would pose a challenge. Not for these guys, because they use Veeam Backup & Replication with the Veeam Explorer for Active Directory.

However, because restores might present new other challenges, the person next to me decided to enable the Active Directory Recycle Bin feature in the Active Directory environment, before restoring the objects.


About VEEAM Explorer for Microsoft Active Directory

VEEAM Modern Data ProtectionVeeam Backup & Replication offers ground-breaking restore possibilities, based on a single (incremental) backup file. The Veeam Explorer for Microsoft Active Directory is a feature that allows for object-level restores in Active Directory, based on the same single backup of any Domain Controller.

To this purpose, Veeam Backup & Replication creates an isolated environment to which it restores the Domain Controller, plus a Veeam interface to restore objects to the production Active Directory Domain Services environment.


The problem

After verifying successful replication of enabling the Active Directory Recycle Bin, he started up Veeam Backup & Replication and restored the affected objects using the Veeam Explorer for Microsoft Active Directory.

To his loud dismay, Veeam created objects with new Security Identifiers (sIDs), instead of properly restoring objects with their original sIDs, as he expected from the documentation and previous experiences.

Looking up to an enormous amount of work to hard match the new user objects with the orphaned mailboxes, correcting profile issues, etc. the person asked me for advice.


The background

Now, of course, I know the Veeam Explorer for Microsoft Active Directory is not as bad as the person would have me think. Knipogende emoticon


How the Active Directory Recycle Bin works

Let’s look at what happens when we enable the Active Directory Recycle Bin, introduced with Windows Server 2008 R2, first.

Active Directory Object Lifecycle with Active Directory Recycle Bin disabled (click for original figure, provided by Microsoft)

In an environment that doesn’t have the Active Directory Recycle Bin enabled, an object that is deleted becomes tombstoned for the period of the tombstone lifetime. This makes sure Domain Controllers have the opportunity to replicate this change. As part of the tombstoning process, the object is stripped from all link-valued and non-link-valued attributes, so the object doesn’t appear as a group member, etc. After the Tombstone Lifetime Period, the locally running garbage collection process deletes the tombstone object from the database, on each Domain Controller separately.

Active Directory Object Lifecycle with Active Directory Recycle Bin enabled (click for original figure, provided by Microsoft)

After the Active Directory Recycle Bin feature is enabled, the deletion process for objects changes, significantly, as the above figure shows:

  • A deleted lifetime is introduced
    After you enable Active Directory Recycle Bin, when an object is deleted, the system preserves all of the object’s link-valued and non-link-valued attributes, and the object becomes logically deleted, which is a new state. A deleted object is moved to the Deleted Objects container, and its distinguished name is mangled. A deleted object remains in the Deleted Objects container in a logically deleted state throughout the duration of the deleted object lifetime. Within the deleted object lifetime, you can recover a deleted object with Active Directory Recycle Bin and make it a live Active Directory object again. Within the deleted object lifetime, you can also recover a deleted object through an authoritative restore.
  • The tombstone lifetime is replaced with a recycled lifetime
    After the deleted object lifetime expires, the logically deleted object is turned into a recycled object and most of its attributes are stripped away. After the recycled object lifetime expires, the garbage-collection process physically deletes the recycled Active Directory object from the database.

These changes result in a couple of situations, as documented by Microsoft:

The process of enabling Active Directory Recycle Bin is irreversible. After you enable Active Directory Recycle Bin in your environment, you cannot disable it.

When Active Directory Recycle Bin is enabled, all objects that were deleted before Active Directory Recycle Bin was enabled (that is, all tombstone objects) become recycled objects. These objects are no longer visible in the Deleted Objects container, and they cannot be recovered with Active Directory Recycle Bin. The only way to restore these objects is though an authoritative restore from a backup of AD DS that was taken of the environment before Active Directory Recycle Bin was enabled.

A recycled object cannot be recovered with Active Directory Recycle Bin or with the steps in Reanimating Active Directory Tombstone Objects.


How the Veeam Explorer for Microsoft Active Directory works

VEEAM Explorer for Active Directory Restore Options (click for original screenshot, provided by VEEAM)

Now, let’s look at how the Veeam Explorer for Microsoft Active Directory works, from a functional perspective. In Veeam’s support forums, we found the following gem of information:

In case you need to restore an object then Veeam looks for it either in a tombstone container or in a recycle bin (in your case that would be a recycle). If nothing’s found then Veeam needs to restore the object from backup. If you restore the object from a backup then your GUID and SID will change. In case of a tombstone/resyscle restoration GUID and SID do not change.


The cause

So, Veeam explorer for Microsoft Active Directory looks for deleted objects (when Active Directory Recycle Bin is enabled) and tombstone objects (when Active Directory Recycle Bin is not enabled) and tries to undelete or reanimate these (resulting in objects with the same sIDs), before resorting to recreate objects (resulting in objects with new sIDs).

Because the Active Directory Recycle Bin was enabled before Veeam Explorer for Microsoft Active Directory could work its magic, Veeam Explorer for Microsoft Active Directory was able to only find recycled objects, that can’t be undeleted or reanimated. Thus, Veeam Explorer for Microsoft Active Directory recreated the objects.


The solution

Microsoft’s documentation already points to the solution. Authoritatively restoring the objects should bring them back with their original sIDs.

We first deleted the objects that we created using Veeam Explorer for Active Directory, to avoid duplicate objects. Then, again, Veeam Backup & Replication helped in this case. We performed an authoritative restore for the Organizational Unit (OU) from backup, using the following commands in Directory Services Restore Mode (DSRM):


activate instance ntds 

authoritative restore

restore subtree “OU=OrganizationalUnit,DC=domain, DC=tld

Can’t get into the Directory Services Restore Mode (DSRM), because the startup option is missing on your Domain Controller? Follow these instructions.

This resulted in objects with original sIDs, and no more orphaned mailboxes, profile issues, etc.



Under the hood, Active Directory works in mysterious ways. Understanding how it works, makes your life easier and your choices better.

Backup solutions know how Active Directory works, and allow for ways to handle possible restrictions. The people at Veeam have found excellent ways to handle Active Directory and I still feel the Veeam Explorer for Microsoft Active Directory is a tremendously intelligent way to handle Active Directory object restores, with authoritative restores as a worst case help line if you need it.

Related blogposts

How to add a DSRM startup option in Windows Server 2008 and 2008 R2
I am a 2016 Veeam Vanguard
I’ll be presenting at Veeam on Tour
I will be hosting Veeam Webinars on Host-based Backup and Restore for Virtualized Active Directory Domain Controllers

Further reading

What’s New in AD DS: Active Directory Recycle Bin
Veeam Explorer for AD and AD Recycle Bin enable
Backing up Domain Controller: Best practices for AD protection (Part 1)
How to recover a Domain Controller: Best practices for AD protection (Part 2)
Active Directory Recycle Bin in Windows Server 2008 R2
Revive Deleted AD Objects with Active Directory Recycle Bin
The Active Directory Recycle Bin
Configuring Active Directory Recycle Bin
The Active Directory Recycle Bin in Windows Server 2008 R2
Enabling the Active Directory Recycle Bin Feature on Windows 2008 R2


Security Thoughts: Vulnerability in Active Directory could allow denial of service (MS16-081, KB3160352, CVE-2016-3226)

Yesterday, Microsoft released update 3160352 as part of its June 2016 Patch Tuesday to address an important vulnerability in Active Directory, allowing denial of service. This security update is rated Important for all supported editions of Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2

About the vulnerability

A vulnerability has been detected by Ondrej Sevecek of GOPAS and described as part of CVE-2016-3226, that could allow denial of service if an authenticated attacker creates multiple machine accounts. To exploit the vulnerability an attacker must have an account that has privileges to join machines to the domain.

An attacker who successfully exploited this vulnerability could cause the Active Directory service to become non-responsive.

About the update

The security update addresses the vulnerability by correcting by correcting how machine accounts are created.

This security update is rated Important for all supported editions of Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2

Affected Operating Systems

The following supported Microsoft Windows Server Operating System versions, running both Full Installations and Server Core Installations are affected by this vulnerability:

  • Windows Server 2012 R2 Datacenter
  • Windows Server 2012 R2 Standard
  • Windows Server 2012 R2 Essentials
  • Windows Server 2012 R2 Foundation
  • Windows Server 2012 Datacenter
  • Windows Server 2012 Standard
  • Windows Server 2012 Essentials
  • Windows Server 2012 Foundation
  • Windows Server 2008 R2 Service Pack 1

KB3160352 addresses the vulnerability on the affected Operating Systems.

This security update is rated Important for all supported releases of Microsoft Windows.
A system restart is required after you apply this security update.

Mitigating factors

To exploit this vulnerability, an attacker must have an account that has privileges to join machines to the domain. If an attacker cannot join new machines to the domain, the vulnerability cannot be exploited.


Microsoft has not identified any workarounds for these vulnerabilities.


Call to action

I urge you to install KB3160352 on Domain Controllers 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 Domain Controllers in the production environment.

Related KnowledgeBase articles

3160352 MS16-081: Security Update for Active Directory: June 14, 2016