1. Home
  2. Training Library
  3. Microsoft Azure
  4. Courses
  5. Azure Active Directory Security

Azure AD Tools and Identity Solutions


Overview of the course
Course Intro
Introduction to Azure AD
What is Azure AD?
Secure Access to Azure AD
Integrate Securely with Azure AD
Start course

Please note: this course is now outdated. The security aspects of Azure Active Directory are covered in our  Designing for Azure Identity Management course found here.


Azure Active Directory, commonly referred to as Azure AD, is Microsoft’s Identity and Access Management service in the Cloud. It manages users, groups, and applications along with their access to other applications and resources running in the cloud. This is exactly what we have with traditional on-premises Active Directory. Azure AD runs as a cloud service and thus can be thought of as Identity and Access Management as a Service.

This course is an introduction to Azure AD security and covers topics related to securing users, groups, devices, and applications as well as cover hybrid identity infrastructure solutions and much more!

What You'll Learn in this Course

Lesson What you'll learn
Overview of the Course Overview of the course and the Learning Objectives
Introduction to Azure AD An intro to Azure AD and Cloud Security
Secure Access to Azure AD Discuss users, group, apps, and RBAC
Integrate Securely with Azure AD Azure AD Connect, Identity solutions, MFA, and App Integration
Identity Management Discuss Identity Management and premium features
Summary Summary and Course Wrap-up



In this lesson you’ll learn secure methods to integrate Azure AD with On-premises.

We’ll cover Azure AD Connect, hybrid identity solutions, on-premises integration with AD FS, multi-factor authentication, and finish up with app integration with Azure AD for B2B and B2C scenarios.

The Azure AD Connect tool is how you connect and integrate your on-premises identity infrastructure with Azure AD. If you’ve been working with Azure for a while you may be familiar with tools such as DirSync or Azure AD Sync. Azure AD Connect replaces these older tools and is now a single tool used for credential synchronization and sign-in. Through the use of password hashes (and without sending the actual password) this provides users with a single identity to access both on-premises applications and cloud services such as Office 365. You may combine this tools with on-premises identity infrastructure such as AD FS which enables Single Sign-On as well as Multi-factor authentication.

Let’s have a deeper discussion about the Hybrid Identity solution options you may choose. Again, remember the goal here of each solution is to synchronize your on-premises directory objects with Azure AD thus enabling users to to work on-premises and in the cloud in a simplified way.

This simplest solution is the Synchronized Identity solution. As you can see here in this illustration from the Microsoft documentation the AD Connect tool simply does a Password Sync from your on-premises Active Directory to Azure AD. Unfortunately doing it in this way forces you to maintain a separate password for cloud-based resources. The way it works is that your on-premises Active Directory will store the user passwords as hash values which represents the password. You cannot decode this hash value on the other side since it’s a one-way mathematical function which is the hashing algorithm. The Connect tool securely copies and syncs these on-prem hash values with Azure AD. But you may not use this hash value to actually sign in to your on-prem network since it is unidirectional from on-prem to Azure AD and not the other way around. As we saw before, users may reset their passwords from the Azure Portal. There is an optional feature called password writeback which will write the new password back to the on-premises Active Directory thus avoiding setting up and managing self-service on-premises password reset solutions. Don’t worry this whole process is encrypted with a symmetric key during the writeback setup process and sent over an HTTPS channel and is protected by a randomly generated password that only your on-premises installation knows about. These features are all components of the AD Connect tool.

Now let’s take a look at the Pass-through Authentication solution. This solution avoids the password hash authentication and synchronization process. No passwords are stored in the cloud. Instead, when users sign in using Azure AD directly, then Azure AD validates a users’ passwords directly against your on-premises Active Directory. This solution can be configured again using the Azure AD Connect tool which deploys agents to your on-prem servers to listen for the password validation requests. The server which you setup to deploy these agents to on-premises only needs to be Windows Server 2012 R2 or higher and has to be joined to a domain in the forest through which users are validated.

Both of these two solutions can be combined with Single Sign-On (SSO) for users on domain-joined computers that are connected to the corporate network to provide a seamless and easy connection using only usernames to securely access cloud resources.

Let’s wrap-up our hybrid identity solutions with Federated Identity using AD FS. This solution is noticeably the most complex but gives you the most control over how users access on-premises and cloud resources. This is because all authentication happens on-premises on your AD FS server. This allows your on-prem administrators to enforce as much policy, control, and levels of access they’d like for user authentication. The downside is maintainability. If your on-premises infrastructure is down, users will not be able to sign in to cloud services. You may setup password synchronization as we saw before to act as a backup in case you have downtime. AD FS also has the advantage to be integrated with your PKI infrastructure and allow sign-ins via Certificates and smartcards. Also this solutions lends itself well to multi-factor authentication using the on-premises infrastructure. The federated trust here is between your AD FS infrastructure and Azure AD.

One question you may ask is if you can mimic the entire AD FS infrastructure itself in the cloud. The answer is yes, you may implement AD FS in Azure using existing Azure resources such as virtual machines used for Domain Controllers and Web Application Proxies, Virtual Networks and subnets for tiered networking resources, and Load balancers along with Availability Sets for high availability all connected back to your on-prem resources over a highly secure, high-bandwidth ExpressRoute connection. We won’t go into the details of this here but thought I should mention it for completeness.

If you recall from the demo where we explored Azure Active Directory in the Portal we saw settings for configuring Enterprise applications and custom app registration. These settings control application integration with Azure AD. Enterprise applications should be managed and taking advantage of cloud-enabled applications whether in the cloud directly or even on-premises have an advantage integrating with Azure AD in order to authenticate and create secure connections with end-users.

The result of this integration enables you to assign apps to users and groups, configure single sign-on for applications, allow self-service access to applications, and provide automatic provisioning and de-provisioning using 3rd party tools. You can use the search bar at the top of the portal and search for “Enterprise application” or “App registration”. The portal provides a gallery of ready to use 3rd party applications as well.

These app integrations with Azure AD take advantage of authentication and authorization standards like SAML 2.0, Ws-Federation, OpenID , etc. You can even use certificates and passwords. You can also connect applications from the cloud back to on-premises by using the Azure AD proxy to allow access to intranet apps from anywhere.

Let’s have a quick look at an Azure AD Application web authentication scenario. The blue bar on the left is the Browser which we’ll represent as the User. The green bar on the right is the web application the user wants to access. The middle bar is Azure AD. When a user first navigates to the web application they are immediately redirected by a sign-in request to the authentication endpoint in Azure AD which includes the App ID URI of the application. On the third line, the user simply provides credentials on the sign-in page to sign in. If the user is successfully authenticated Azure AD creates an authentication token and returns a sign-in response to the application’s Reply URL that was configured in the Azure Portal. The returned token includes information about the user and Azure AD that are required by the application to validate the token. The application validates the token. As a final step after, Azure AD starts a new session with the user. This session allows the user to access the application until it expires. Essentially what we’ve done here is take an Application that has registered with Azure AD, and use the built-in Azure AD authentication mechanisms to validate users and allow access to the application without the application having to worry about about all the details of authentication and authorization. You may view other types of authentication scenarios such as this in the Microsoft documentation.

First let’s get the acronyms out of the way. B2C is business to consumer while B2B is Business to business. The hyperlink you see is used by the Azure Documentation to launch you to the portal to create Azure B2C applications. These applications are mainly for developers who want to build Web, PC, and mobile apps and services that can authenticate with consumer identity services like Facebook, Google and Microsoft. Azure B2B applications are Azure AD based applications used for authenticating between business to business partners. The benefit of B2B applications are listed here which shows how compelling it is to authenticate without having to manage cross-organizational credentials, directories, accounts, etc. You simply choose the Enterprise App you want to use in your organization and you provision it to a user. Just note that an Azure AD Administrator is needed to add Users to Apps.


About the Author
Christopher Jackson
Azure Researcher and Trainer
Learning Paths

Chris has over 15 years of experience working with top IT Enterprise businesses.  Having worked at Google helping to launch Gmail, YouTube, Maps and more and most recently at Microsoft working directly with Microsoft Azure for both Commercial and Public Sectors, Chris brings a wealth of knowledge and experience to the team in architecting complex solutions and advanced troubleshooting techniques.  He holds several Microsoft Certifications including Azure Certifications.

In his spare time, Chris enjoys movies, gaming, outdoor activities, and Brazilian Jiu-Jitsu.