Implement Azure Active Directory

For those of you familiar with Microsoft Active Directory, you will find the similarities mostly end at the name. Your Azure AD tenant begins when you create your subscription. In other words, the Azure AD tenant (sometimes called the directory name) goes with it. Your domain name will be something like: example.onmicrosoft.com where "example" is the name of your Azure Active Directory. Azure AD can be used to manage access to multiple SaaS solutions on Azure.



When you first create your account you are automatically provisioned a free edition of Azure AD. This leads us into the next section. Azure AD editions. There are four editions: Free, Basic, Premium P1, and Premium P2 which have different features.

Here is a breakdown of the features available in each edition. SSO, B2B collaberation, Self-service password change (not reset), and AAD Connect are available on all editions. These features are important to know for the exam.

Drag the checkmark to the red box to mark this section as complete.

Users

Creating an AAD user in the portal you have three options:

 • User
 • Global Administrator
 • Limited Administrator

A user has limited access to most directory resources and will have Role Based Access Control (RBAC) applied to control access.

The user account used to create the Azure subscription is created as a Global Administrator. This role should be used sparingly since it is given a large swathe of privileges. It has full administrative access to all features in the Azure Active Directory.

The Limited Administrator is added to a specific nonglobal administrative role upon creation. Examples include Application Admin, Billing Admin, Service Admin, plus about 30 more. These built-in admin roles are created by Microsoft and have preset permissions that are useful. You can also create your own custom roles, which will be covered later.

Adding a User With a Custom Domain

If you need to add a user that has a custom domain, you will first need to add the custom domain to Azure AD. If you have not done this you receive an error that "'example.net' is not a verified domain name in this directory"

Create New Azure Active Directory Users

Adding Users

In this video we wil create user accounts to demonstrate how to create an additional Global Administrator account as well as users with different AAD roles.

To create another Global Administrator we will add a new user and assign them the Global Administrator Role. Notice after creation that we will have two Global Administrators, one where the source is Microsoft Account, and one where the source is Azure Active Directory.

Next we will create a basic user.

Then we will create two Limited Administrator users. One Application Developer admin and one Cloud Application Administrator.

Associating User to Subscription

You will notice if you log in with any of your newly created accounts that you aren't able to create any resources. This is because the user is not associated with any subscription. If the user clicks the + Add button in the Subscription blade, they will be able to create their own subscription and create resources. To associate users with a subscription you will use RBAC, which we will cover later.

Drag the checkmark to the red box to mark this section as complete.

AAD Connect

Azure Active Directory Connect is used to implement a hybrid identity structure. This means that you will link your on-premise Active Directory (AD) with your AAD. This is a one-way street for the most part, from your on-prem AD to your AAD. This will allow AD to access Azure resources.

AAD Connect supports three methods of of sign-in:

 • Password hash synchronization
 • Pass-through synchronization
 • ADFS

Synchronization support creates directory objects like users, devices, and groups in AAD from your on-prem AD. To navigate to Azure AD Connect, click Azure AD Connect while in the Azure Active Directory blade. You will see the sync status of AAD Connect. It will say Not Installed if you have never run it. You need to navigate to this blade from the server you plan to install the Azure AD Connect client on in order to synchronize objects. Click the Download Azure AD Connect link to install the agent. The account that initiates synchronization must be a Global Administrator in the Azure AD. (The account you used to create the subscription is a Microsoft Account, and not an Azure AD Account!)

☆Placeholder for video for Install Azure AD Connect.

Afterwards your Azure AD Connect blade will look like this:

☆Placeholder for image

Connect Health

In order to monitor the health of the synchronization Azure provides a service called Connect Health. If you have ever delt with anything where synchronization happens, then I am sure you are used to problems where one or the other endpoint becomes out of synch with the other. This can be due to many reasons, including network issues, client/server issues, time mismatch, firewall configurations, user error, just to name a few. This can become an issue for example if a user is disabled or deleted in on-prem AD, and this change doesn't replicate to Azure AD.

Azure AAD Connect Health monitors the health of features, including:

 • Synchronization errors with Azure AD (missing, out-of-date, or duplicates)
 • Identifies IP addresses that are bad actors, attempting ADFS logon
 • Monitor health issues with Azure AD Directory Services
 • Configure alerts based on error types

☆Placeholder for Azure AD Connect video

Drag the checkmark to the red box to mark this section as complete.

Directory Objects

It's time that we talk about objects. Specifically Azure AD objects. Referring back to the table listing features available in each of the four Azure AD versions, only the free tier has a limit on the number of objects available. What is an AAD object? An object in Azure AD is a user, device, or group. So 500,000 objects will be sufficient for most applications.

Drag the checkmark to the red box to mark this section as complete.

Single Sign-On

Single sign-on (SSO) is a response to the complexities introduce due to the growing amount of apps and resources. If there was a separate set of credentials for each sign-on it would quickly become a nightmare for the user and administrators as well. SSO creates a secure way to sign in to multiple Azure resources with one account. Keep in mind Azure SSO operates on a different set of protocols than on-premise authorization. Azure utilizes web based authorization protocols such as OAuth, and passwordless methods such as hardware keys and Hello. SSO in AAD has three identity sign-on methods to consider:

 • Password Hash Synchronization
 • Pass-through Synchronization
 • Active Directory Federation Service (ADFS)

Password Hash Synchronization

This should rightly be called something else, since AAD Connect creates a hash of the hash of the password from the on-premise AD to AAD. The users sing on to the Azure services using the same password as they would on-premises. This method requires the least amount of effort to implement.

Pass-Through Authentication

Pass-Through Authentication utilizes an authentication agent, dowloaded to the on-premises servers, to manage authentication between AD and AAD.

Active Directory Federation Service

Administrators of on-premise infrastructure might already be familiar with Active Directory Federation Service (ADFS). The on-prem Administrator can federate a trust relationship between the on-prem environment with AAD.

☆Placeholder for SSO video

Self-Service Password

Self-service password services drastically reduce the workload placed on Azure administrators to perform password support by implementing a means for the end user to conduct that support themselves. Self-Service password change is supported on all versions of AAD, however Self-Service Password Reset (SSPR) is not an option until the Basic version, and Self-Service Password unlock is only available on the Premium P1 and P2 tiers. These features must be enabled in AAD, and then configured by the end user to use reset options such as security questions. The Administrator has the ability to implement self-service password features granularly for select users and even implement custom SSPR security questions, and the number of questions required to be answered.

☆Placeholder for Self-service Password videos

Drag the checkmark to the red box to mark this section as complete.

Application Proxy

The application proxy allows Azure users to access an on-premise application remotely using SSO. A proxy is essentially an abstraction layer, or virtual layer, that exposes an endpoint. An example of this is an application endpoint, or Application Programming Interface (API), usually accessible via an Uniform Resource Identifier (URI). An Application Proxy, accessible via an URI can then receive the incoming data and forward the request to the appropriate service.

From a security perspective, this is advantageous since the requestor does not hold the connection information to the end application. Additionally, management of the application and its connections is simplified. If an endpoint changes, the change only needs to be made in one location, instead of on every platform that requests access to the application.

In order to use Application Proxy, you will dowload and install Microsoft Azure Active Directory Application Proxy Connector on a server in an on-premise datacenter. You will have to sign in to the proxy connector with your Azure account to connect the server hosting the connector to the Application Proxy. Logging in with a Global Administrator account with an Azure Active Directory source will add an entry to appear on the Application Proxy blade.

It is good practice to place the Application Proxy Connector closest (geographically) to the content that users need. Then configure that external endpoint URI for that specific connector.
☆Placeholder for Application Proxy video

Drag the checkmark to the red box to mark this section as complete.

Service Level Agreement

Service Level Agreements (SLA) are an agreement between the enterprise and Microsoft as a guarantee that a specific resource will be available for a guaranteed timeframe. These SLA are usually reffered to by a specific number of "9's." For example a service that has an uptime guarantee of 99.9 percent would have three 9's for an SLA. Basic and Premium editions of AAD have an SLA. Usually, when the SLA is breached, a monetary compensation is guaranteed by Azure. The current SLA terms for Basic and Premium editions of AAD are:

In order to calculate the Monthly Uptime Percentage, use the following formula:

(User Minutes - Downtime) / User Minutes * 100

• User Minutes is the sum of the amount of downdtime and the number of impacted users

• Downtime is measured in user-minutes; that is, the sum of the length(in minutes) of each incident that occurs multiplied by the number of users impacted by that incident.

• Downtime is defined as any period of time when users are unable to log in to the Azure AD service or Azure AD fails to successfully emit the authentication and authorization tokens required for users to log into applications connected to a service.

Drag the checkmark to the red box to mark this section as complete.

Identity Protection

Needless to say, an enterprise is only as secure as its weakest link. Usually that is the user. The most common way for a malicious actor to gain unauthorized access is through legitimate, compromised credentials. These are usually gained through a phishing campaign or social engineering. Hackers have refined and improved this attack vector drastically and become highly succesful at it.

Identity Protection protects an enterprise from exploited accounts and spoofing. AAD Identity Protection is a Marketplace feature and is required for some conditional access policies that you might want to implement.

☆Placeholder for Identity Protection video

Multifactor Authentication

Multifactor Authentication (MFA) is used to combine different forms of authentication in order to make it more difficult for a hacker to compromise an account. One of the main reasons for implementing MFA is because passwords are a weak form of security. Usually this falls down to human nature. A general user is going to want to select a simple password that is easy for them to remember, and use that single password across many different services. I know at one time I have been guilty of this.

The problem with this is that if a hacker compromises this password, they can use it to gain access to all the resources that it was used for. MFA combines two or more forms of authentication, which are broken down into:

 • Something you know
 • Something you have
 • Something you are

Something You Know

Something you know is the most common and widely used form of authentication in existence. It has existed long before the advent of computers, back in history as far as people wanted to limit access to something. Examples of something you know are:

 • Username
 • Password
 • Answers to account recovery questions

Since hackers have perfected the art of Social Engineering, OSINT gathering, and phishing, relying on this form of authentication is complete folly. In fact, many platforms are moving to passwordless technologies that are more secure. Even the NIST is moving away from suggesting certain password complexity requirement and now suggests the use of a passphrase. A passphrase is a long, usually nonsensical phrase that is easy to remember (phrases are easier to remember than a random string of letters,numbers, and special characters). Since a phrase can be much longer than a password, it becomes exponentially more difficult to brute force crack.

Something You Have

Something you have is a additional node to authentication that relies on the user having a physical device, and sometimes needing physical access to the system. Examples of something you have include:

 • A mobile device
 • Digital certificates
 • Smart cards
 • FIDO2 hardware key (or other vendor solutions)
 • Hardware tokens that generate random numbers

The combination of something you know with something you have is a powerful form of authentication since in order to crack it you would need to know the users login credentials and have possesion of (or be able to engineer) the physical device that is being used for MFA. Cellular devices are very popular for MFA since the phone number is tied to one device, which has a robust means of verifying authentication itself. This is not foolproof though, as hackers have proven able to hijack apps and devices used for MFA in this sense.

Something You Are

Something you are is one of my favorite methods of authentication, and usually is substituted for another term: biometrics. It is one of my favorite because it is by far the hardest to imitate, though given the prevalance of nation-state actors and communities of hackers that can amass resources, it is not outside the realm of possibilities to accomplish. Examples of something you are include:

 • Fingerprints
 • Retina
 • Facial recognition
 • Gait analysis
 • Speech patterns/Voice

If I had to rate each of the methods of authentication as the most robust, something you are, would be at the top of the list. In fact, many people think that biometrics alone are enough to maintain security. Two factors is always more secure than one though, and if you learn about biometrics you will learn that it is a very tricky science where you have to usually tweak the system to avoid false positives or even false negatives. The algorithm for authentication using biometrics lies on a statistical curve, which means there is inherently gray area that can be exploited.

Privileged Identity Management

Privileged Identity Management (PIM) is a feature to control access to a critical or sensitive resource on the infrastructure. PIM adds authentication capabilities to resources on Azure based on the AAD identity, AAD group assignment, or RBAC.

Managed Identities

Managed identities are another way that an on-premise AD Administrator might be familiar with. They are similar to Managed Service Accounts. Prior to this, we have discussed identities that belong to a physical person. Next we will discuss Azure solution to assign identities to apps,services, and security principals. Examples of use cases for Managed Identities (MI) include:

 • Azure App Service
 • Azure Functions
 • Azure Virtual Machines

Azure AD uses MI to manage authentication of Azure resources for the use of shared secrets (Azure Key Vault) which are discussed elsewhere. MI might be more formally know as Managed Service Identities.

☆Placeholder for Managed Identity video.

Drag the checkmark to the red box to mark this section as complete.

Azure AD Domain Services

This concept will make the most sense to IT professionals with experience with on-premise AD Domain Services (ADDS) experience. Azure AD Domain Services is useful for a concept known as lift-and-shift migration. It is important to realize that AD uses protocols that do not exist inside of AAD including:

 • Lightweight Directory Access Protocol (LDAP)
 • New Technology LAN Manager (NTLM)
 • Kerberos

Some workarounds for enterprises wanting to migrate existing workloads to the cloud. One option is creating a site-to-site connection between the AAD and on-premise AD. Another option is to simply create a Microsoft Server VM or replicating that domain to the cloud. Microsofts solution is Azure AD Domain Services for lift-and-shift scenarios. Two scenarios exist:

 • Azure AD DS for hybrid
 • Azure AD DS for cloud-only

Azure AD DS hybrid solutions allow the enterprise to retain its on-premise infrastructure while migrating to the cloud. Identities must be migrated between the on-premise AD and AAD tenant. Cloud resources exist in a Virtual Network and access AAD using Azure ADDS. Azure AD Connect then synchronizes to the on-premise infrastructure.

The cloud-only solution is the same as hybrid, minus the on-premise portion.

☆Placeholder for AADDS picture.

Next section: Role-Based Access Control or AZ-104 Home