Office 365 / Azure AD Password Synchronization Security

February 17, 2016 by Ed Sparks

We are often asked by customers how secure it really is to synchronize their passwords to and from Azure AD, be it standalone or as part of Office 365.

Our short answer:

The passwords themselves are never sent over the wire in either direction. In all cases only password hashes are sent.

The longer answer is easily derived and supported both from TechNet articles and various third-party sites. The key take-away is that only the hashes are ever retrieved, additional encryption applied, and then that is sent to Azure AD or back. The passwords themselves are never used or sent.

From TechNet:

The Active Directory Domain Service stores passwords in form of a hash value representation of the actual user password. The Password hash cannot be used to login to your on-premises network. It is also designed so that it cannot be reversed in order to gain access to the user’s plain text password. To synchronize a password, the Directory Sync tool extracts the user password hash from the on-premises Active Directory. Additional security processing is applied to the password hash before it is synchronized to the Azure Active Directory Authentication service.

When synchronizing passwords using the password sync feature, the plain text version of a user’s password is neither exposed to the password sync tool nor to Azure AD or any of the associated services.

Additionally, there is no requirement on the on-premises Active Directory to store the password in a reversibly encrypted format. A digest of the Windows Active Directory password hash is used for the transmission between the on-premises AD and Azure Active Directory. The digest of the password hash cannot be used to access resources in the customer's on-premises environment.

https://technet.microsoft.com/en-us/library/dn246918.aspx

From A Third-Party

An independent company that makes SharePoint and Office 365 tools also performed their own analysis, down to the packet capture level. What they found was:

The hash over the wire that is captured is not an MD4 hash of clear text password. It is a secure PBKDF2 key derived from SHA256 hash of the MD4 hash (derived from crypto API documented at http://msdn.microsoft.com/en-us/library/windows/desktop/dd433795(v=vs.85).aspx) per RFC 2898.

Overall we're very confident using this functionality at our customer deployments, and Microsoft have created a well thought out and secure implementation.

SharePoint 2013 Active Directory Import will NEVER delete users

March 5, 2015 by Ed Sparks

<face palm>

Microsoft teased us all with the prospect of finally having a simple, supportable and consistent way to quickly sync basic user information from Active Directory into SharePoint 2013.

No more do we have to deal with the wonders of FIM and this mess. One-click wonder.

Look: it even filters disabled accounts with a checkbox!

It appears there's one minor problem...it doesn't work.

First off, check out Microsoft's (not so) tiny list of caveats/exceptions for AD Import.

Consider the following situations and note what the AD import option does not support when you determine whether to use this option.

Consider, indeed! That should more accurately read: "If you wish to use this for any task whatsoever, choose a different option"

Well, it technically it does work, but I guess when they named it Active Directory Import they literally meant that. Once it imports a user it's there for the rest of eternity, never to be removed in any sort of automated fashion. It doesn't matter if you disable, move, or delete an AD account - AD Import could care less, and will do nothing with the related SharePoint User Profile. The "bdeleted" flag never gets updated. Nothing. Yes, Virginia, this wondrous tool will NEVER remove a disabled or deleted account. Of course, the lack of deleted flags means we can't easily run PowerShell commands to remove orphaned users either. In the eyes of the User Profile they're NOT orphaned. They're still there as happy, safe and sound objects.

Honestly, Microsoft, do you ever test this stuff anymore?

It's our belief that this behavior comes from the fact that Active Directory Import appears to be based on a version of the DirSync utility to push users up to the Office 365 or Azure clouds, which also suffers from the same behavior (i.e. removing an on-premise user does nothing at all to the cloud user).

It also appears the LDAP filters may or may not even take effect either, nor are they documented about how they apply, or mix with the OU selection, etc.
This entire thing is just ridiculous and sad.

Back to User Profile Synchronization and FIM we go.

Here's a Microsoft Escalation Blog on this very issue.

Source: http://blogs.msdn.com/b/spses/archive/2015...

Split-bain - the long standing internal domain naming debate revisited

May 31, 2012 by Ed Sparks

The heated discussion that surrounds naming an internal Active Directory domain the same or differently than the external public DNS name lives on.

In my opinion, in these days of increasingly mobile, unmanaged device access, and with the "just works" mantra that I follow - using the same internal and external namespace is the preferred option. (i.e corporate.com for both your AD and public DNS).

By doing so, users get to use and remember a single logon and email address, and there's way less fuss when setting up user accounts. Any of the supposed security disadvantages are simple to overcome with split DNS servers, and the exceptional capabilities of today's application firewalls.

I recently found an interesting old thread on this topic, that is replicated below. It's a good read on the topic.