Deep Dive into Azure Managed Identities – Part 2

Posted on August 12, 2019 by mattfeltonma

Welcome back fellow geeks for the second installment in my series on Azure Managed Identities. In the first post I covered the business problem and the risks Managed Identities address and in this post I’ll be how managed identities are represented in Azure.

Let’s start by walking through the components that make managed identities possible.

The foundational component of any identity is the data store in which the identity lives in. In the case of managed identities, like much of the rest of the identity data for the Microsoft cloud, the data store is Azure Active Directory. For those of you coming from the traditional on-premises environment and who have had experience with your traditional directories such as Active Directory or one of the many flavors of LDAP, Azure Active Directory (Azure AD) is an Identity-as-a-Service which includes a directory component we can think of as a next generation directory. This means it’s designed to be highly scalable, available, and resilient and be provided to you in “as a service” model where a simple management layer sits in front of all the complexities of the compute, network, and storage infrastructure that makes up the directory. There are a whole bunch of other cool features such as modern authentication, contextual authorization, adaptive authentication, and behavioral analytics that come along with the solution so check out the official documentation to learn about those capabilities. If you want to nerd out on the design of that infrastructure you can check out this whitepaper and this article.

It’s worthwhile to take a moment to cover Azure AD’s relationship to Azure. Every resource in Azure is associated with an Azure subscription. An Azure subscription acts as a legal and payment agreement (think type of Azure subscription, pay-as-you-go, Visual Studio, CSP, etc), boundary of scale (think limits to resources you can create in a subscription), and administrative boundary. Each Azure subscription is associated with a single instance of Azure AD. Azure AD acts as the security boundary for an organization’s space in Azure and serves as the identity backend for the Azure subscription. You’ll often hear it referred to as “your tenant” (if you’re not familiar with the general cloud concept of tenancy check out this CSA article).

Azure AD stores lots of different object types including users, groups, and devices. The object type we are interested in for the purposes of managed identity are service principals. Service principals act as the security principals for non-humans (such as applications or Azure resources like a VM) in Azure AD. These service principals are then granted permissions to access resources in Azure by being assigned permissions to Azure resources such as an instance of Azure Key Vault or an Azure Storage account. Service principals are used for a number of purposes beyond just Managed Identities such as identities for custom developed applications or third-party applications.

Given that the service principals can be used for different purposes, it only makes sense that the service principal object type includes an attribute called the serviceprincipaltype. For example, a third-party or custom developed application that is registered with Azure AD uses the service principal type of Application while a managed identity has the value set to ManagedIdentity. Let’s take a look at an example of the serviceprincipaltypes in a tenant.

In my Geek In The Weeds tenant I’ve created a few application identities by registering the applications and I’ve created a few managed identities. Everything else within the tenant is default out of the box. To list the service principals in the directory I used the AzureAD PowerShell module. The cmdlet that can be used to list out the service principals is the Get-AzureADServicePrincipal. By default the cmdlet will only return the 100 results, so you need to set the All parameter to true. Every application, whether it’s Exchange Online or Power BI, it needs an identity in your tenant to interact with it and resources you create that are associated with the tenant. Here are the serviceprincipaltypes in my Geek In The Weeds tenant.

Now we know the security principal used by a Managed Identity is stored in Azure AD and is represented by a service principal object. We also know that service principal objects have different types depending on how they’re being used and the type that represents a managed identity has a type of ManagedIdentity. If we want to know what managed identities exist in our directory, we can use this information to pull a list using the Get-AzureADServicePrincipal.

We’re not done yet! Managed Identities also come in multiple flavors, either system-assigned or user-assigned. System-assigned managed identities are the cooler of the two in that they share the lifecycle of the resource they’re used by. For example, a system-assigned managed identity can be created when an Azure Function is created thus that the identity will be deleted once the Azure VM is deleted. This presents a great option for mitigating the challenge of identity lifecycle management. By Microsoft handling the lifecyle of these identities each resource could potentially have its own identity making it easier to troubleshoot issues with the identity, avoid potential outages caused by modifying the identity, adhering to least privilege and giving the identity only the permissions the resource requires, and cutting back on support requests by developers to info sec for the creation of identities.

Sometimes it may be desirable to share a managed identity amongst multiple Azure resources such as an application running on multiple Azure VMs. This use case calls for the other type of managed identity, user-assigned. These identities do not share the lifecycle of the resources using them.

Let’s take a look at the differences between a service principal object for a user-assigned vs a system-assigned managed identity. Here I ran another Get-AzureADServicePrincipal and limited the results to serviceprincipaltype of ManagedIdentity.

ObjectId                           : a3e9d372-242e-424b-b97a-135116995d4b
ObjectType                         : ServicePrincipal
AccountEnabled                     : True
AlternativeNames                   : {isExplicit=False, /subscriptions//resourcegroups/managedidentity/providers/Microsoft.Compute/virtualMachines/systemmis}
AppId                              : b7fa9389-XXXX
AppRoleAssignmentRequired          : False
DisplayName                        : systemmis
KeyCredentials                     : {class KeyCredential {
                                       CustomKeyIdentifier: System.Byte[]
                                       EndDate: 11/11/2019 12:39:00 AM
                                       KeyId: f8e439a8-071b-45e0-9f8e-ac10b058a5fb
                                       StartDate: 8/13/2019 12:39:00 AM
                                       Type: AsymmetricX509Cert
                                       Usage: Verify
                                       Value:
                                     }
                                     }
ServicePrincipalNames              : {b7fa9389-XXXX, https://identity.azure.net/XXXX}
ServicePrincipalType               : ManagedIdentity
------------------------------------------------
ObjectId                           : ac960ac7-ca03-4ac0-a7b8-d458635b293b
ObjectType                         : ServicePrincipal
AccountEnabled                     : True
AlternativeNames                   : {isExplicit=True,
                                     /subscriptions//resourcegroups/managedidentity/providers/Microsoft.ManagedIdentity/userAssignedIdentities/testing1234}
AppId                              : fff84e09-XXXX
AppRoleAssignmentRequired          : False
AppRoles                           : {}
DisplayName                        : testing1234
KeyCredentials                     : {class KeyCredential {
                                       CustomKeyIdentifier: System.Byte[]
                                       EndDate: 11/7/2019 1:49:00 AM
                                       KeyId: b3c1808d-6778-4004-b23f-4d339ed0a91f
                                       StartDate: 8/9/2019 1:49:00 AM
                                       Type: AsymmetricX509Cert
                                       Usage: Verify
                                       Value:
                                     }
                                     }
ServicePrincipalNames              : {fff84e09-XXXX, https://identity.azure.net/XXXX}
ServicePrincipalType               : ManagedIdentity

In the above results we can see that the main difference between the user-assigned (testing1234) and system-assigned (systemmis) is the within the AlternativeNames property. For the system-assigned identity has values of isExplicit set to False and has another value of /subscriptions//resourcegroups/managedidentity/
providers/Microsoft.Compute/virtualMachines/systemmis. Notice the bolded portion specifies this is being used by a virtual machine named systemmis. The user-assigned identity has the isExplicit set to True and another property with the value of /subscriptions//resourcegroups/managedidentity/
providers/Microsoft.ManagedIdentity/userAssignedIdentities/testing1234. Here we can see the identity is an “explicit” managed identity and is not directly linked to an Azure resource.

This difference gives us the ability to quickly report on the number of system-assigned and user-assigned managed identities in a tenant by using the following command.

Get-AzureADServicePrincipal -All $True | Where-Object AlternativeNames -like “isExplicit=True*”

True would give us user-assigned and False would give us system-assigned. Neat right?

Let’s summarize what we’ve learned:

An object in Azure Active Directory is created for each managed identity and represents its security principal
The type of object created is a service principal
There are multiple service principal types and the one used by a Managed Identity is called ManagedIdentity
There are two types of managed identities, user-assigned and system-assigned
System-assigned managed identities share the lifecycle of the resource they are associated with while user-assigned managed identities are created separately from the resource, do not share the resource lifecycle, and can be used across multiple resources
The object representing a user-assigned managed identity has a unique value of isExplicit=True for the AlternativeNames property while a system-assigned managed identity has that value of isExplicit=False.

That’s it for this post folks. In the next post I’ll walk through the process of creating a managed identity for an Azure VM and will demonstrate with a bit of Python code how we can use the managed identity to access a secret stored in Azure Key Vault.

See you next post!

Deep Dive into Azure Managed Identities – Part 1

Posted on August 7, 2019 by mattfeltonma

“I love the overhead of password management” said no one ever.

Password management is hard. It’s even harder when you’re managing the credentials for non-humans, such as those used by an application. Back in the olden days when the developer needed a way to access an enterprise database or file share, they’d put in a request with help desk or information security to have an account (often referred to as a service account) provisioned in Windows Active Directory, an LDAP, or a SQL database. The request would go through a business approval and some support person would created the account, set the password, and email the information to the developer. This process came with a number of risks:

Risk of compromise of the account
Risk of abuse of the account
Risk of a significant outage

These risks arise due to the following gaps in the process:

Multiple parties knowing the password (the party who provisions the account and the developer)
The password for the account being communicated to the developer unencrypted such as plain text in an email
The password not being changed after it is initially set due to the inability or difficult to change the password
The password not being regularly rotated due to concerns over application outages
The password being shared with other developers and the account then being used across multiple applications without the dependency being documented

Organizations tried to mitigate the risk of compromise by performing such actions as requiring a long and complex password, delivering the password in an encrypted format such as an encrypted Microsoft Office document, instituting policy requiring the password to be changed (exceptions with this one are frequent due to outage concerns), implementing password vaulting and management such as CyberArk Enterprise Password Vault or Hashicorp Vault, and instituting behavioral monitoring solutions to check for abuse. Password rotation and monitoring are some of the more effective mitigations but can also be extremely challenging and costly to institute at a scale even with a vaulting and management solution. Even then, there are always the exceptions to the systems with legacy applications which are not compatible (sadly these are often some of the more critical systems).

When the public cloud came around the credential management challenge for application accounts exploded due to the most favored traits of a public cloud which include on-demand self-service and rapid elasticity and scalability. The challenge that was a few hundred application identities has grown quickly into thousands of applications and especially containers and serverless functions such as AWS Lambda and Azure Functions. Beyond the volume of applications, the public cloud also changes the traditional security boundary due to its broad network access trait. Instead of the cozy feeling multiple firewalls gave you, you now have developers using cloud services such as storage or databases which are directly administered via the cloud management plane which is exposed directly to the Internet. It doesn’t stop here folks, you also have developers heavily using SaaS-based version control solutions to store the code which may have credentials hardcoded into it potentially publicly exposing those credentials.

Thankfully the public cloud providers have heard the cries of us security folk and have been working hard to help address the problem. One method in use is the creation of security principals which are designed around the use of temporary credentials. This way there are no long standing credentials to share, compromise, or abuse. Amazon has robust use of this concept in AWS using IAM Roles. Instead of hardcoding a set of IAM User credentials in a Lambda or an application running on an EC2 instance, a role can be created with the necessary permissions required for the application and be assumed by either the Lambda service or EC2 instance.

For this series of posts I’m going to be focusing on one of Microsoft Azure’s solutions to this problem, which are called Managed Identities. For you folks that are more familiar with AWS, Managed Identities conceptually work the same was as IAM Roles. A security principal is created, permissions are granted, and the identity is assumed by a resource such as an Azure Web App or an Azure VM. There are some features that differ from IAM Roles that add to the appeal of Managed Identities such as associating the identity lifecycle of the Managed Identity to the resource such that when the resource is created, the managed identity is created, and when the resource is destroyed, the identity is destroy.

In the next entry I will do a deeper dive into what a managed identity looks like behind the scenes.

See you soon fellow geek!

A Comparison – AWS Managed Microsoft AD and Azure Active Directory Domain Services

Posted on September 6, 2018 by mattfeltonma

Update June 2021: I’m surprised I have to say this, but technology changes rapidly in the cloud and this was a comparison of the technologies at a point in time. Please reference the latest official documentation for both products to understand capabilities and features and how they compare at the time you are reading this post.

Over the past year I’ve done deep dives into both Amazon’s AWS Managed Microsoft Active Directory and Microsoft’s Azure Active Directory Domain Services. These services represent each vendor’s offering of a managed Windows Active Directory (AD) service. I extensively covered the benefits of a service over the course of the posts, so today I’m going to cover the key features of each service. I’m also going to include two tables. One table will outline the differences in general features while the other outlines the differences in security-related features.

Let’s hit on the key points first.

Amazon provides a legacy (Windows AD is legacy folks) managed service while Microsoft provides a modernized service (Azure AD) which has been been integrated with a legacy service.
Microsoft synchronizes users, passwords hashes, and groups from the Azure AD to a managed instance of Windows Active Directory. The reliance on this synchronization means the customer has to be comfortable synchronizing both directory data and password hashes to Azure AD. Amazon does not require any data be synchronized.
Amazon provides the capability to leverage the identities in the managed instance of Windows AD or in a forest that has a trust with the managed instance to be leveraged in managing AWS resources. In this instance Amazon is taking a legacy service and enabling it for management of the modern cloud management plane.
The pricing model for the services differs where Amazon bills on a per domain controller basis while Microsoft bills on the number of objects in the directory.
Amazon’s service is eligible to be used in solutions that require PCI DSS Level 1 or HIPAA.
Both services use a delegated model where the customer has full control over an OU rather the directory itself. Highly privileged roles such as Schema Admin, Enterprise Admins, and Domain Admins are maintained by the cloud provider.
Both services provide LDAP for legacy applications customers may be trying to lift and shift. Microsoft limits LDAP to read operations while Amazon supports both read and write operations.
Both services support LDAPS. At this time Amazon requires an instance of Active Directory Certificate Services be deployed to act as a Certificate Authority and provide certificates to the managed domain controllers.
Both services do not allow the customer to modify the Default Domain Policy or Default Domain Controller Policies. This means the customer cannot modify the password or lockout policy applied to the domain. Amazon provides a method of enforcing custom password and lockout policies through Fine Grained Password Policies. Additionally, the customer does not have the ability to harden the OS of the domain controllers for either service so it is important to review the vendor documentation.
Amazon’s service supports Active Directory forest trusts and external trusts. Microsoft’s service doesn’t support trusts at this time.

Here is a table showing the comparison of general features:

Features	AWS Managed Microsoft AD	Azure Active Directory Domain Services
Cost Basis	Number of Domain Controllers	Number of Directory Objects
Schema Extensions	Yes, with limitations	No
Trusts	Yes, with limitations	No
Domain Controller Log Access	Security and DNS Server Event Logs	No
DNS Management	Yes	Yes
Snapshots	Yes	No
Limit of Managed Forests	10 per account	1 per Azure AD tenant
Supports being used on-premises	Yes with Direct Connect or VPN	No, within VNet only
Scaled By Customer	Yes	No
Max number of Domain Controller	20 per directory	Unknown how service is scaled

Here is a table of security capabilities:

Features	AWS Managed Microsoft AD	Azure Active Directory Domain Services
Requires Directory Synchronization	No	Yes, including password
Fine-Grained Password Policies	Yes, limited to seven	No
Smart Card Authentication	Not native, requires RADIUS	No
LDAPS	Yes, with special requirements	Yes, but LDAP operations are limited to read
LDAPS Protocols	SSLv3, TLS 1.0, TLS 1.2	TLS 1.0, TLS 1.2
LDAPS Cipher Suites	RC4, 3DES, AES128, AES256	RC4, 3DES, AES128, AES256
Kerberos Delegation	Account-Based and Resource-Based	Resource-Based
Kerberos Encryption	RC4, AES128, AES256	RC4, AES128, AES256
NTLM Support	NTLMv1, NTLMv2	NTLMv1, NTLMv2

Well folks that sums it up. As you can see from both of the series as well as this summary post both vendors have taken very different approaches in providing the service. It will be interesting to see how these offerings evolve over the next few years. As much as we’d love to see Windows Active Directory go away, it will still be here for years to come.

Until next time my fellow geeks!

AWS Managed Microsoft AD Deep Dive Part 7 – Trusts and Domain Controller Event Logs

Posted on September 3, 2018 by mattfeltonma

Welcome back fellow geek. Today I’m continuing my deep dive series into AWS Managed Microsoft AD. This will represent the seventh post in the series and I’ve covered some great content over the series including:

Today I’m going cover three additional capabilities of AWS Managed Microsoft AD which includes the creation of trusts, access to the Domain Controller event logs, and scalability.

I’ll first cover the capabilities around Active Directory trusts. Providing this capability opens up the possibility a number of scenarios that aren’t possible in managed Windows Active Directory (Windows AD) services that don’t support trusts such as Microsoft’s Azure Active Directory Domain Services. Some of the scenarios that pop up in my head are resource forest, trusts with trusted partners to maintain collaboration for legacy applications (applications dependent on legacy protocols such as Kerberos/NTLM/LDAP), trusts between development, QA, and production forests, and the usage of features features such as selective authentication to mitigate the risk to on-premises infrastructure.

For many organizations, modernization of an entire application catalog isn’t feasible but those organizations still want to take advantage of the cost and security benefits of cloud services. This is where AWS Managed Microsoft AD can really shine. It’s capability to support Active Directory forests trusts opens up the opportunity for those organizations to extend their identity boundary to the cloud while supporting legacy infrastructure. Existing on-premises core infrastructure services such as PKI and SIEM can continue to be used and even extended to monitor the infrastructure using the managed Windows AD.

As you can see this is an extremely powerful capability and makes the service a good for almost every Windows AD scenario. So that’s all well and good, but if you wanted marketing material you’d be reading the official documentation right? You came here for the deep dive, so let’s get into it.

The first thing that popped into my mind was the question as to how Amazon would be providing this capability in a managed service model. Creating a forest trust typically requires membership in privileged groups such as Enterprise Admins and Domain Admins, which obviously isn’t possible in a manged service. I’m sure it’s possible to delegate the creation of Active Directory trusts and DNS conditional forwarders with modifications of directory permissions and possibly user rights, but there’s a better way. What is this better way you may be asking yourself? Perhaps serving it up via the Directory Services console in the same way schema modifications are served up?

Let’s walk through the process of setting up an Active Directory forest trust with a customer-managed traditional implementation of Windows Active Directory and an instance of AWS Managed Microsoft AD. For this I’ll be leveraging my home Hyper-V lab. I’m actually in the process of rebuilding it so there isn’t much there right now. The home lab consists of two virtual machines, one named JOG-DC running Windows Server 2016 and functions as a domain controller (AD DS) and certificate authority (AD CS) for the journeyofthegeek.com Active Directory forest. The other virtual machine is named named JOG-CLIENT, runs Windows 10, and is joined to the journeyofthegeek.com domain. I’ve connected my VPC with my home lab using AWS’s Managed VPN to setup a site-to-site IPSec VPN connection with my local pfSense box.

Prior to setting up the trusts there are a few preparatory steps that need to be completed. The steps will be familiar to those of you who have established forests trusts across firewalled network segments. At a high level, you’ll want to perform the following tasks:

Ensure the appropriate ports are opened between the two forests.
Ensure DNS resolution between the two forests is established

For the first step I played it lazy since this is is a temporary configuration (please don’t do this in production). I allowed all traffic from the VPC address range to my lab environment by modifying the firewall rules on my pfSense box. On the AWS side I needed to adjust the traffic rules for the security group SERVER01 is in as well as the security group for the managed domain controllers.

To establish DNS resolution between the two forests I’ll be using conditional forwarders setup within each forest. Setting the conditional forwarders up in the journeyofthegeek.com forest means I have to locate the IP addresses of the managed domain controllers in AWS. There are a few ways you could do it, but I went to the AWS Directory Services Console and selected the geekintheweeds.com directory.

On the Directory details section of the console the DNS addresses list the IP addresses the domain controllers are using.

After creating the conditional forwarder in the DNS Management MMC in the journeyofthegeek.com forest, DNS resolution of a domain controller from geekintheweeds.com was successful.

I next created the trust in the journeyofthegeek.com domain ensuring to select the option to create the trust in this domain only and recording the trust password using the Active Directory Domains and Trusts. We can’t create the trusts in both domains since we don’t have an account with the appropriate privileges in the AWS managed domain.

Next up I bounced back over to the Directory Services console and selected the geekintheweeds.com directory. From there I selected the Network & security tab to open the menu needed to create the trust.

From here I clicked the Add trust relationship button which brings up the Add a trust relationship menu. Here I filled in the name of the domain I want to establish the trust with, the trust password I setup in the journeyofthegeek.com domain, select a two-way trust, and add an IP that will be used within configuration of the conditional forwarder setup by the managed service.

After clicking the Add button the status of the trust is updated to Creating.

The process takes a few minutes after which the status reports as verified.

Opening up the Active Directory Users and Computers (ADUC) MMC in the journeyofthegeek.com domain and selecting the geekintheweeds.com domain successfully displays the directory structure. Trying the opposite in the geekintheweeds.com domain works correctly as well. So our two-way trust has been created successfully. We would now have the ability to setup any of the scenarios I talked about earlier in the post including a resource forest or leveraging the managed domain as a primary Windows AD service for on-premises infrastructure.

The second capability I want to briefly touch on is the ability to view the Security Event Log and DNS Server logs on the managed domain controllers. Unlike Microsoft’s managed Windows AD service, Amazon provides ongoing access to the Security Event Log and DNS Server Log. The logs can be viewed using the Event Log MMC from a domain-joined machine or programmatically with PowerShell. The group policy assigned to the Domain Controllers OU enforces a maximum event log size of 256MB but Amazon also archives a year’s worth of logs which can be requested in the event of an incident. The lack of this capability was a big sore spot for me when I looked at Azure Active Directory Domain Services. It’s great to see Amazon has identified this critical use case.

Last but definitely not least, let’s quickly cover the scalability of the service. Follow Microsoft best practices and you can take full advantage of scaling horizontally with the click of a single button. Be aware that the service only scales horizontally and not vertically. If you have applications that don’t follow best practices and point to specific domain controllers or perform extremely inefficient LDAP queries (yes I’m talking to you developers who perform searches using front and rear-facing wildcards and use LDAP_MATCHING_RULE_IN_CHAIN filters) horizontal scaling isn’t going to help you.

Well folks that rounds out this entry into the series. As we saw in the post Amazon has added key capabilities that Microsoft’s managed service is missing right now. This makes AWS Managed Microsoft AD the more versatile of the two services and more than likely a better fit in almost any scenario where there is a reliance on Windows AD.

In my final posts of the series I’ll provide a comparison chart showing the differing capabilities of both AWS and Microsoft’s services.

See you next post!

Journey Of The Geek

The chronicles of a Bostonian tech geek navigating through life and technology

Tag Archives: identity

Deep Dive into Azure Managed Identities – Part 2

Deep Dive into Azure Managed Identities – Part 1

A Comparison – AWS Managed Microsoft AD and Azure Active Directory Domain Services

AWS Managed Microsoft AD Deep Dive Part 7 – Trusts and Domain Controller Event Logs