Jan 12, 2020

What is Azure Active Directory?

Updated: Jun 17, 2021

Many are familiar with Active Directory, the on-premises directory and authentication system that is available with Windows Server, but exactly what is Azure Active Directory?

Azure Active Directory (Azure AD or AAD) is a multi-tenant cloud directory and authentication service. Azure AD is the directory service that Office 365 (and Azure) leverages for account, groups, and roles. It is also an Identity Provider (IPD) and supports federation (SAML, etc).
Note: given how rapidly the cloud changes, elements of this post may become out of date soon after the original post date.

Azure AD is highly available and globally deployed.

“Azure AD is deployed in over 30 datacenters around the world leveraging Azure Availability Zones where present. This number is growing rapidly as additional Azure Regions are deployed.

For durability, any piece of data written to Azure AD is replicated to at least 4 and up to 13 datacenters depending on your tenant configuration. Within each data center, data is again replicated at least 9 times for durability but also to scale out capacity to serve authentication load. To illustrate—this means that at any point in time, there are at least 36 copies of your directory data available within our service in our smallest region. For durability, writes to Azure AD are not completed until a successful commit to an out of region datacenter.

This approach gives us both durability of the data and massive redundancy—multiple network paths and datacenters can serve any given authorization request, and the system automatically and intelligently retries and routes around failures both inside a datacenter and across datacenters.

To validate this, we regularly exercise fault injection and validate the system’s resiliency to failure of the system components Azure AD is built on. This extends all the way to taking out entire datacenters on a regular basis to confirm the system can tolerate the loss of a datacenter with zero customer impact.
…
Azure AD is already a massive system running on over 300,000 CPU Cores and able to rely on the massive scalability of the Azure Cloud to dynamically and rapidly scale up to meet any demand. This can include both natural increases in traffic, such as a 9AM peak in authentications in a given region, but also huge surges in new traffic served by our Azure AD B2C which powers some of the world’s largest events and frequently sees rushes of millions of new users.
…
To support the health checks that gate safe deployment and give our engineering team insight into the health of the systems, Azure AD emits a massive amount of internal telemetry, metrics, and signals used to monitor the health of our systems. At our scale, this is over 11 PetaBytes a week of signals that feed our automated health monitoring systems.”

https://azure.microsoft.com/en-us/blog/advancing-azure-active-directory-availability/

Azure Active Directory is Not Cloud AD
Azure Active Directory is not Active Directory hosted in the cloud.
There is no standard AD authentication methods such as NTLM or Kerberos; no LDAP; and no group policy (GPO), so Azure AD won’t work for traditional on-prem applications.

There are cloud hosted Active Directory environments that can be used to manage cloud workloads in Microsoft Azure (Azure Active Directory Domain Services), Amazon AWS (Amazon Managed Microsoft AD), and Google Cloud (Managed Service for Microsoft Active Directory (AD)). These are all hosted Microsoft Active Directory environments which have 2 Domain Controllers (or more) and the tenant admins do not receive Domain Admin rights to the hosted AD environment; only delegated access is provided which often includes the ability to create/manage resources in a specific OU and specific GPOs.

Note: I don’t have room to include a comparison of these services here, but may write a future post if there’s interest (I did some research comparing Microsoft Azure vs Amazon AWS hosted AD service offerings in 2017).

Primary Management Tools
The tool that most AD administrators are familiar with is Active Directory Users and Computers aka ADUC (MMC tool).

Azure Active Directory administrators will primarily use the web console at https://portal.azure.com to administer the environment.

Admins that manage Active Directory on-prem and now Azure AD/Office 365 will be using the on-prem MMC tools as well as the web admin portals (and various URLs associated with them). There are PowerShell cmdlets available for managing Azure AD (similar to on-prem), though cloud features often move faster than the PowerShell tools are released, which means that using the cloud admin portal should still be used, even when using PowerShell.

Interfacing with Azure Active Directory

Since Azure AD doesn’t have LDAP, interfacing with AAD involves connecting via the Graph API (or PowerShell modules). I like PowerShell, so I use the PowerShell modules (or Portal websites) for management and reporting.

There are 2 primary PowerShell modules for interfacing with Azure AD: MSOnline and AzureAD. These can be installed through the PowerShell install feature:

Install-Module -Name MSOnline -Force
Install-Module -Name AzureAD -Force

The AzureAD module may eventually replace the MSOnline PowerShell module, but there are features available in MSOnline that haven’t been ported to the Azure AD module (yet).

Azure AD PowerShell Modules & Cmdlets Comparison
(module & cmdlet data as of January 2020)

Category MSOnline AzureAD

Administrative Unit: Get-MsolAdministrativeUnit

Administrative Unit: Get-MsolAdministrativeUnitMember

Application Get-AzureADApplication

Application Get-AzureADApplicationExtensionProperty

Application Get-AzureADApplicationKeyCredential

Application Get-AzureADApplicationLogo

Application Get-AzureADApplicationOwner

Application Get-AzureADApplicationPasswordCredential

Application Get-AzureADApplicationProxyApplication

Application Get-AzureADApplicationProxyApplicationConnectorGroup

Application Get-AzureADApplicationProxyConnector

Application Get-AzureADApplicationProxyConnectorGroup

Application Get-AzureADApplicationProxyConnectorGroupMember

Application Get-AzureADApplicationProxyConnectorMemberOf

Application Get-AzureADApplicationServiceEndpoint

Application Get-AzureADMSApplication

Application Get-AzureADMSApplicationExtensionProperty

Application Get-AzureADMSApplicationOwner

Application Get-AzureADDeletedApplication

Application Get-AzureADServiceAppRoleAssignedTo

Application Get-AzureADServiceAppRoleAssignment

Application Get-AzureADGroupAppRoleAssignment

Authentication Get-AzureADMSIdentityProvider

Authentication Get-AzureADMSLifecyclePolicyGroup

Authentication Get-AzureADOAuth2PermissionGrant

Contact Get-MsolContact Get-AzureADContact

Contact Get-AzureADContactDirectReport

Contact Get-AzureADContactManager

Contact Get-AzureADContactMembership

Contact Get-AzureADContactThumbnailPhoto

Contract Get-AzureADContract

Device Get-MsolDevice Get-AzureADDevice

Device Get-MsolDeviceRegistrationServicePolicy

Device Get-AzureADDeviceConfiguration

Device Get-AzureADDeviceRegisteredOwner

Device Get-AzureADDeviceRegisteredUser

DirSync Get-MsolDirSyncConfiguration

DirSync Get-MsolDirSyncFeatures

DirSync Get-MsolDirSyncProvisioningError

DirSync Get-MsolHasObjectsWithDirSyncProvisioningErrors

Domain Get-MsolDomain Get-AzureADDomain

Domain Get-MsolDomainVerificationDns Get-AzureADDomain

VerificationDnsRecord

Domain Get-AzureADDomainNameReference

Domain Get-AzureADDomainServiceConfigurationRecord

Federation Get-MsolFederationProperty

Group Get-MsolGroup Get-AzureADGroup

Group Get-MsolGroup Get-AzureADMSGroup

Group Get-MsolGroupMember Get-AzureADGroupMember

Group Get-AzureADGroupOwner

Group Get-AzureADMSGroupLifecyclePolicy

Group Get-AzureADMSDeletedGroup

License Subscription: Get-MsolSubscription Get-AzureADSubscribedSku

Object Get-AzureADMSDeletedDirectoryObject

Object Get-AzureADObjectByObjectId

Partner Get-MsolPartnerContract

Partner Get-MsolPartnerInformation

Password Get-MsolPasswordPolicy

Role Group Get-MsolRole Get-AzureADDirectoryRole

Role Group Get-MsolRoleMember Get-AzureADDirectoryRoleMember

Role Group Get-MsolScopedRoleMember

Role Group Get-AzureADDirectoryRoleTemplate

Service Principal Get-MsolServicePrincipal Get-AzureADServicePrincipal

Service Principal Get-MsolServicePrincipalCredential Get-AzureADServicePrincipal

KeyCredential

Service Principal Get-AzureADServicePrincipalCreatedObject

Service Principal Get-AzureADServicePrincipalOAuth2PermissionGrant

Service Principal Get-AzureADServicePrincipalOwnedObject

Service Principal Get-AzureADServicePrincipalOwner

Service Principal Get-AzureADServicePrincipalPasswordCredential

Session Get-AzureADCurrentSessionInfo

Tenant Get-MsolCompanyAllowedDataLocation

Tenant Get-MsolCompanyInformation

Tenant Get-AzureADTenantDetail

Tenant Get-AzureADTrustedCertificateAuthority

Tenant Get-CrossCloudVerificationCode

User Get-MsolUser Get-AzureADUser

User Get-MsolUserByStrongAuthentication Get-AzureADUserAppRole

Assignment

User Get-MsolUserRole Get-AzureADUserCreatedObject

User Get-AzureADUserDirectReport

User Get-AzureADUserExtension

User Get-AzureADExtensionProperty

User Get-AzureADUserLicenseDetail

User Get-AzureADUserManager

User Get-AzureADUserMembership

User Get-AzureADUserOAuth2PermissionGrant

User Get-AzureADUserOwnedDevice

User Get-AzureADUserOwnedObject

User Get-AzureADUserRegisteredDevice

User Get-AzureADUserThumbnailPhoto

User Get-MsolAccountSku

In the table above, I categorize the cmdlets across the two Azure AD PowerShell module and attempt to link the ones that provide the same or similar capability. I am planning to post more on these cmdlets in the future.

Unfortunately, it isn’t a simple matter to single sign-on (SSO) to these modules. A credential can be captured in PowerShell and reused across modules, but only if MFA isn’t enforced (which reduces account security).

The Microsoft Cloud environment originally only supported username and password authentication. This “legacy authentication” doesn’t include Multi-Factor Authentication (“MFA”), so for security reasons, legacy authentication should be disabled (via Security Defaults, Conditional Access, etc).
The Azure Active Directory Authentication Library provides “modern authentication” which fully supports MFA (and passwordless!).

ADAL according to Microsoft:
“The Azure Active Directory Authentication Library (ADAL) v1.0 enables application developers to authenticate users to cloud or on-premises Active Directory (AD), and obtain tokens for securing API calls. ADAL makes authentication easier for developers through features such as:

· Configurable token cache that stores access tokens and refresh tokens

· Automatic token refresh when an access token expires and a refresh token is available

· Support for asynchronous method calls”

There is an ADAL PowerShell Module (Install-Module -Name adal.ps) which provides some level of SSO across modules (that support it).
Once you have the ADAL module installed, run the following to load the ADAL token in the session:

$clientId = "1b730954-1685-4b74-9bfd-dac224a7b894" # Azure AD PowerShell
$redirectUri = [Uri]::new('urn:ietf:wg:oauth:2.0:oob')
$authority = "https://login.windows.net/common/oauth2/authorize"
$resourceUrl = "https://graph.windows.net"

$ADALresponse = get-adaltoken -Resource $resourceUrl -ClientId $clientId -RedirectUri $redirectUri -Authority $authority -PromptBehavior:Always

Once the $ADALResponse variable is captured, you can leverage this token in the Azure AD modules:

$ConnectAzureADInfo = connect-azuread -AadAccessToken $ADALresponse.AccessToken -AccountId $ADALresponse.UserInfo.DisplayableId

$ConnectMsolInfo = connect-msolservice -AdGraphAccessToken $ADALresponse.AccessToken

# Looks like the Microsoft Teams PowerShell module supports ADAL as well, though I added a new variable that includes the signed-in user UPN.

Connect-MicrosoftTeams -AadAccessToken $ADALresponse -AccountId $AssessmentAccountUPN

Access Rights to Azure Active Directory
With Active Directory, just about everything can be viewed as a regular user. Azure AD users can view information about users and groups, but there are some limitations as to what is accessible.

In Azure AD, privileged groups are called “roles” (which are groups) in order to identify special access. There are several of these admin roles in Office 365 which provide admin-level rights to all of Office 365 or specific parts of it. (Assigning Roles)

Many organizations have a reporting account in the Global Administrator (aka Tenant Administrator) role which is effectively Enterprise Admin, Domain Admin, and Schema Admin wrapped up into a single group. Global Admin has full control to Azure AD and all Office 365 services. This is why many organizations have more than 5 Global Admins (Microsoft’s maximum recommended number). Only cloud accounts should be added to roles so they can leverage Azure MFA (& passwordless) as well as the role membership controlled by PIM.
Also strongly recommended is creating a “break-glass” administrator account (or two) to ensure continued privileged access to the tenant.
Microsoft published a document on how to secure privileged access.

Privileged Identity Management (PIM) is strongly recommended for controlling role membership and requires Azure AD Premium 2 (P2) licenses for each account that will use PIM. PIM provides just in time access to the admin role with the required rights. When an admin needs admin rights, they can request & gain access through PIM (which can be sent for approval or auto-approved). Microsoft recommends all accounts in roles are managed by PIM (and have AAD P2 licenses).There is also a Powershell module for PIM which can be installed:
Install-Module -Name Microsoft.Azure.ActiveDirectory.PIM.PSModule

In Fall 2019, Microsoft added a new role called “Global Reader” which has read-only/view-only rights to all Azure AD/Office 365 services that Global Admin can see (with some exceptions since Microsoft is still rolling out Global Reader read-only capability to all Office 365 services). Membership in Global Reader should be provided to the security team or auditors that require view-only access to the Microsoft Cloud (Azure AD & Office 365) environment.

Attacking Azure Active Directory
Office 365 services are accessible from the internet (by default, use Conditional Access to restrict access) which makes them attractive to attackers. Attackers leverage several attack methods against Azure AD & Office 365.

Account Enumeration
With old school Active Directory, any Active Directory user can enumerate all user accounts & admin group membership with network access to a Domain Controller.
Azure Active Directory users can enumerate all user accounts & admin group membership with access to Office 365 services (the internet by default). User enumeration often possible without an account using O365creeper which attempts to authenticate to O365 using a list of email addresses. Based on the response code, the tool determines if the email address is a valid user account (or not).

Azure AD Enumeration Tools
O365 Creeper – Office 365 Authentication Page (Python) [Account Discovery]
OWA (Golang)
ActiveSync (Python)
MSOnline/AzureAD PowerShell Module (PowerShell)

Password Spraying
A common method attackers leverage as well as many penetration testers and Red Teamers is called “password spraying”. Password spraying is interesting because it’s automated password guessing. This automated password guessing against all users typically avoids account lockout since the logon attempts with a specific password are performed against against every user and not one specific one which is what account lockout was designed to defeat. The attacker starts with a list list of passwords they’re going to try which starts with the most likely passwords (“Fall2017”, “Winter2018”, etc).

When password spraying begins, we start with the first password in the list. That first password is used in an attempt to authenticate as every user (or a subset). This one password is attempted against each user and once all users have been tested with that password, we move on to the next one.

Password Spraying is relatively trivial to perform and is extremely effective. We have worked with many organizations with accounts that were compromised by password spraying their cloud environment. Many customers that are Federated don’t realize it’s their job to look for this, not the cloud’s. There is a real risk beyond the cloud with password spraying. If the same password is used for the cloud account and on-prem and there is no MFA configured, it’s possible that an attacker could password spray the cloud account and then gain access to the corporate network. This is not a theoretical or hypothetical scenario and underscores the importance of MFA.

Office 365 Password Spraying Tools
Ruler (Exchange) [Golang]
SprayingToolkit (Lync/Skype for Business/OWA) [Python]
LyncSniper (Lync/Skype for Business) [PowerShell]
MailSniper (OWA/EWS) [PowerShell]

Office 365 Password Spraying Mitigation
Disable Legacy authentication by enabling “Security Defaults” or configuring a custom Conditional Access policy. Also requiring MFA for all users is strongly recommended.

Office 365 Password Spraying Detection
Assuming password spraying targets Office 365 services and federation is not configured (ADFS, Okta, etc), then detection can be performed by referencing the Azure AD sign-in logs.

Detect by correlating multiple events for the same user within a timeframe with the sign-in error code “50126” and the Client app is “Other clients; Older Office clients” (which means legacy authentication was performed).

Account token theft & reuse
Since cloud authentication typically results in a token stored in the authenticated app or web browser, this is the proof of authentication and could be reused. The web browser typically stores this auth token as a cookie. If this data is stolen, an attacker could leverage this to spoof access and configure persistence for continued access.

Azure AD Reviews
Microsoft’s Azure AD GitHub includes PowerShell code for reviewing Azure AD configuration (https://github.com/AzureAD/AzureADAssessment)

Trimarc also has a new service offering called the Microsoft Cloud Security Assessment (MCSA) which is similar to the on-prem Active Directory Security Assessment but focused on Azure AD & Office 365.

Additional Office 365 Service PowerShell Modules
Exchange Online Module
Install-Module -Name ExchangeOnlineManagement

Microsoft SharePoint
Install-Module -Name Microsoft.Online.SharePoint.PowerShell

Microsoft Teams
Install-Module -Name MicrosoftTeams

Microsoft Skype for Business Online

Microsoft InTune

Install-Module -Name Microsoft.Graph.Intune -Force
(Requires an admin to provide Admin Consent: Connect-MSGraph -AdminConsent)