I’m doing a little more structured work with public cloud, so have been going back and cleaning up and standardising the existing accounts I already have. The first thing is to create accounts that are company, not user specific. I like to use distribution groups or mailing lists for setting up accounts. They are more preferable to individual accounts, as having the same email on all platforms provides details of an initial attack point. So for public cloud, I want to use generic emails that represent Azure, AWS & GCP.
Sadly, the generic approach works for AWS and GCP but not for Microsoft. AWS doesn’t care what email address you use. Clearly, it needs to be a real one, but aliases and distribution groups are fine. GCP expects the email address to be set up as a Google account, which again is fine for distribution groups. Azure works differently.
Azure validates an email account to see whether the account already exists within Office 365. If it does, then the sign-on credential (e.g. password) is simply the same as the AD account. If an attempt is made to set up an account with a non-existent user, then this is rejected. Obviously, it’s possible to create an account using a non-O365 account/domain, including a generic email address. The restriction is only on O365 managed domains.
The Microsoft Way
Does this seem right? Initially, I thought not. It seems unreasonable not to allow a generic email address as the account owner, because this restricts the ability to ensure emails are distributed to those people managing the account. After all, I can do it if my domain isn’t O365 managed. However, as I thought about it, I realised this is the way O365 also works. The first user creates the subscriptions, which can then be managed across multiple users.
My concern with the Microsoft model was if any individual user left the company and had their email account deleted, would it orphan the Azure account. However, an Azure subscription can have multiple owners and administrators, so theoretically this should never happen. The subscription(s) should outlive any individual user.
What I’m not happy about is the assumption that I want to link my O365 and Azure accounts together. In many ways they are not linked; there’s no implicit assumption that an O365 administrator is an Azure administrator. There’s no “shared AD”, other than the lookup to see if the account exists. Although it seems logical that I should want to link my O365 and Azure user list, as a policy I may want the choice not to. However, I think Microsoft has made this non-linking mistake in the past and created a mess with it. For example, I have an O365 account and Microsoft account that has the same email address but are totally separate accounts with separate passwords. This causes me no end of problems. Maybe they didn’t want that kind of problem again.
The Architect’s View
The AWS and GCP models aren’t wrong, just different. Perhaps Google enforces the same restriction with accounts that are also managed via Gmail. I haven’t checked. The subtle difference in the Azure model compared to GCP and AWS is that having an account doesn’t imply an Azure subscription. That has to be added on afterwards, a bit like O365. By comparison, creating an AWS account implies a (pay as you go) subscription.
It may seem like I’m nit-picking here, but the differences I’m highlighting can sometimes turn out to be major problems further down the line and be impossible to correct without deleting an account or subscription. Something that’s not desirable or in some cases, possible.
Of course one last thing to remember is that I’m using generic emails for account names to avoid using one specific email address. If the platforms allow notifications to go to multiple users, then the problem I’m describing isn’t really a problem at all.
Are you running multiple clouds? What’s your opinion of the creation process?
Comments are always welcome; please read our Comments Policy first. If you have any related links of interest, please feel free to add them as a comment for consideration.
Copyright (c) 2009-2017 – Post #332D – Chris M Evans, first published on http://blog.architecting.it, do not reproduce without permission.