This is a response I sent to this question on ActiveDir.
The usual objection to storing a password in Azure Active Directory (or anywhere that isn’t on-premise) is that you don’t have control of your credentials, and you don’t have the direct ability to enhance the at-rest or over-the-wire risks to those credentials. Let’s examine the logic of that a bit more closely …
For their on-premise services, very few organizations actually go to the strenuousness and periodicity of regulatory audits that Microsoft does for its cloud services. But meeting regulatory auditing doesn’t necessarily mean secure–as folks like Target might like to point out.
If you do sync your passsword, what actually is sent to Microsoft?
Turns out it is a hash of your password hash. So not the password and not even the NT hash.
If you don’t sync your password to AAD and only use federated authentication, do Microsoft’s cloud services ever have your password? Absolutely–yes. If your users use any of the various fat-clients to access Office 365 services, those fat-clients don’t support the security token protocols needed to do federation natively themselves. So they send the password over the wire to the O365 service. The O365 service proxies the federated authentication for the client–getting a federated token with your on-premise STS (or IdP) and using that token to get an AAD federated token it can use to access your O365 content and then send that content back to your fat-client. There are very few customers I know of that aren’t using any fat-clients with O365–so a very large number of users are currently sending their password to Microsoft over-the-wire. That isn’t quite the same as the at-rest credential risk, but most folks seem to gloss over this issue. I believe Microsoft is working on extending the fat clients they own, but they don’t control all fat clients, so this issue will likely remain as long as you have non-Microsoft based clients (e.g. iOS). More folks seem to be familiar with the MFA “app password” issue–which comes from exactly the same client protocol support issues.
So to summarize, there is no option that is “safe” if you define safe as your password doesn’t leave your on-premise organization. There are only options which may or may not meet your organization’s risk management stance. If that stance is that you can’t have at-rest credentials off-premise, then DirSync password sync isn’t for you.
A final thought: our organization had the same sort of initial reaction to storing credentials off-premise. But we’re now thinking about sticking a domain controller in an Azure VM–for a number of reasons that include reducing network traffic back to on-premise for Azure based VMs and to improve our geo-redundancy/business continuity stance. And in a year, we’ll probably also consider sticking a DC VM in Amazon EC2. Bottom line: business needs often trump overly stringent security principles–and while security principles are nice things, it’s really all about risk management.