Chapter 8 Authentication & Authorization

Authentication and authorization are distinct but crucial concepts. Authentication involves confirming that I am who I claim to be. This process commonly employs methods like the traditional username and password, or in modern smartphones, facial recognition. Once the service verifies the provided details, ensuring that I am indeed myself, authentication is successful.

So, to reiterate, authentication confirms your identity, ensuring you are who you claim to be. It acts as the initial test; if you can't be authenticated, you won't gain entry. Authorization, on the other hand, follows authentication and determines what actions or resources your authenticated identity is allowed to access. It is the granular aspect of identity services. If authorization fails, access is denied.

Authentication vs. Authorization

You must know the difference to create effective access management.

Keep out the baddies

Access management is critical to ensure only the right people and processes have access.

So, to reiterate, authentication confirms your identity, ensuring you are who you claim to be. It acts as the initial test; if you can't be authenticated, you won't gain entry. Authorization, on the other hand, follows authentication and determines what actions or resources your authenticated identity is allowed to access. It is the granular aspect of identity services. If authorization fails, access is denied.

Understanding the difference between authentication and authorization is crucial. Access management, a vital aspect of any client infrastructure, ensures that only authorized individuals or processes gain access to business applications and processes. Azure offers various mechanisms for access management, and we'll explore the primary ones in the upcoming section.

Active Directory

Before delving into the Azure-specific details, let's start with Active Directory (AD). Despite the similar name, AD and AAD are distinct products. AD was designed for traditional offices with on-premises users, focusing on managing physical access, computers, and printers. However, it wasn't designed for web-based services, which were not prevalent when AD was conceived in 2000.

While the concept of authentication remains constant, the methods and services provided by AD differ significantly from those in Azure.

Traditional Office Use

Active Directory was designed for traditional office use with computers and printers.

What is “Web”?

The web as a concept or service was not part of the design for Active Directory. Web services were not part of the original vision for Active Directory in 2000.

Authentication

Active Directory authentication uses services that aren’t available on Azure.

Mandatory

You can’t have an Azure account without an AAD service.

First User

Every Azure account needs a first user and this user is in the initial AAD instance.

Azure Active Directory (AAD) is a service within Azure, and every Azure account includes an AAD service. When you create a new Azure account, the first user and owner must be in an Azure Active Directory instance.

Organization

A tenant represents the organization

Dedicated AAD

A tenant is a dedicated instance of AAD that an organization receives when signing up for Azure.

Separate

Each tenant is distinct and completely separate from other AAD tenants.

Max 500 Tenants

Each user in Azure can be a member or guest of up to 500 Azure AD tenants.

A tenant represents your organization in Azure and is a dedicated instance of Azure Active Directory. It is the first AAD instance created when a user signs up for Azure. Each Azure AD tenant is separate from others, and a user belongs to a single tenant, although they can be guests in other tenants.

Billing Entity

All resources within a subscription are billed together.

Cost Separation

You can have multiple subscriptions within a tenant to separate costs.

Payment

If a subscription isn’t paid, all the resources and services associated with the subscription stop.

Subscriptions are billing entities associated with Azure resources, and you can have multiple subscriptions within a single tenant. Remember, if you don't pay your Azure bill for a subscription, the linked resources and services will stop working.

Azure Active Directory plays a significant role in managing users in a hybrid cloud architecture, where some services are on-premises, and others are hosted in Azure. While managing a hybrid scenario is beyond the scope of this course, be aware that AAD is crucial in such setups.

Microsoft Entra = New Product Family

Includes all of Microsoft’s identity and access capabilities includes Azure AD, Plus Permissions Management and Verified ID

Now, a quick update from Matt: In 2022, Microsoft introduced the Microsoft Entra product family, with Azure AD as a key component. This offering includes features for expanded permissions, management, and verified identity across multiple clouds.

it's important to know that Azure AD is part of the Microsoft Entra product family.

To recap for the exam: Azure Active Directory is the primary tool for managing users and permissions on Azure. It's distinct from on-premises Active Directory. A tenant is a dedicated instance of Azure AD representing your organization, and a user belongs to a single tenant but can be a guest in others. Subscriptions are billing entities, and Azure AD is crucial in managing users in hybrid cloud setups. Next, we'll dive into authentication.

Manage users and permissions with Azure Active Directory.

• Active Directory(AD) is not the same as Azure Active Directory.

• Different skillset from AD to Azure AD.

• Every Azure account will have an Azure AD service.

• A tenant is a dedicated instance of Azure AD. It represents your organization in Azure.

• A user can be a member or guest of up to 500 tenants.

• A subscription is a billing entity. All resources belong to a single subscription.

• Azure AD can help manage users in a hybrid cloud setup.

Zero Trust is not a specific Azure service; rather, it is more of a security philosophy or model that fundamentally shapes how modern work-from-anywhere authentication functions. Let's take a moment to explore it.

To comprehend how Zero Trust facilitates modern work, let's first glance at how classic security models operated, at least until the last few years. Traditionally, security models, especially concerning access to sensitive resources, relied on a concept known as a trusted perimeter, or a trusted boundary for secure access. The trusted perimeter was often exemplified by the internal corporate network, where access to private or sensitive materials was restricted to entities or devices within that secure network. Users and devices outside of this network were considered non-trusted.

While this model has served well over the years, it poses challenges in the modern workplace. The major challenge arises from the fact that, with a perimeter model, one must be within the trusted perimeter or corporate network to access sensitive corporate resources. This becomes a hurdle for remote work, as individuals working outside the office are not within that trusted perimeter.

Classic Trusted vs. Untrusted Model

Must be on corporate network to access resources

• Remote work is a challenge

• VPN is extension of trusted perimeter

• Mobile device access even more challenging

All users assumed untrustworthy unless proven otherwise

• Trusted by identity

• Regardless of location (trusted/untrusted networks)

• Least privilege access — just enough permissions to perform job

• Simplified, centralized management

Zero Trust = Trusted Identities, Not Location

In response to challenges like these, the Zero Trust security model comes into play. In simple terms, Zero Trust assumes that everyone is untrustworthy unless proven otherwise, regardless of their location—inside or outside a corporate network. Unlike trust based on a security perimeter, Zero Trust relies on identity to establish trust, regardless of the user's location.

A key principle of Zero Trust is granting least privileged access, meaning assigning users just enough permissions to perform their job functions. This approach aligns with simplified and centralized management, exemplified by Azure Active Directory. Conditional access policies, which we'll discuss shortly, complement this model by managing centralized identities as the primary trust model.

To simplify, think of Zero Trust as trusting identities rather than locations. Proving one's identity becomes the key to accessing sensitive resources, irrespective of the user's physical location.

Access Microsoft 365 email, documents, and resources for remote workforce

• Access from anywhere

• Authenticate with identity, not over VPN

Centrally control access with Conditional Access policies

Allow access only from approved managed devices

• Independent from network location

It's crucial to note that the location or perimeter-based model still has its place and is often combined with identity-based or Zero Trust security models for enhanced security. Conditional access policies provide the flexibility to combine these different models.

With the concept of trusted identities in mind, let's explore a typical scenario of Zero Trust in action, particularly in relation to Microsoft Cloud services. Imagine a distributed workplace where employees need to access Microsoft 365 resources remotely. With Zero Trust, authentication or trust is established based on identity, not solely relying on a VPN connection. Conditional Access policies further enhance control by allowing access only from approved or managed devices, irrespective of their network location.

Multi-factor authentication, or MFA, plays a crucial role in modern online security, especially for your applications. If you're not familiar with multi-factor authentication, it involves using at least two methods to identify yourself during the login process. The key security feature of MFA lies in its layered approach to authentication, providing an extra level of protection.

MFA typically incorporates two or more of the following authentication methods:

1. Something you know: This is typically a username and password, which is a common factor in most authentication processes.

2. Something you have: This could be an application on your phone or a key fob, serving as an additional element to prove your identity.

3. Something you are: This involves biometrics, such as a fingerprint or retina scan. It adds a unique physical aspect to the authentication process.

The strength of MFA lies in the fact that if one authentication factor is compromised by attackers, they still need to overcome additional layers to gain access.

For example, let's consider logging in to your favorite gingerbread cookie recipe website. Initially, you enter your username and password (something you know). To ensure your credentials haven't been compromised, the system sends a code to your phone (something you have), which you then enter into the website. This two-step verification process utilizes both something you know and something you have to grant access, enhancing the overall security of the login.

MFA is generally recommended as a default security practice. However, there might be specific scenarios where, as an Azure admin, you may choose not to enable it. MFA is facilitated through Azure Active Directory and is integrated into Azure as a first-class citizen right from the start, making it a seamless and effective security measure.

If you aim to enhance the protection of identities hosted in Azure Active Directory, Conditional Access policies offer the solution. These policies, a premium feature integrated into Azure Active Directory, go beyond the traditional username and password authentication, providing a more robust security framework.

Authentication Protections beyond Username/Password

If/then policy to grant access

• If (user) meets these conditions (signals), then grant/block access to defined applications

Often paired with multi-factor authentication (MFA)

• Centrally applied MFA enforcement

  • Does not rely on end user enabling MFA

Conditional Access policies operate based on if/then logic, determining access based on predefined conditions or signals. Once a user signs in, if their account aligns with a set of specified conditions, the policy is applied. Common conditions include the user or groups attempting to sign in, the applications they are trying to access, the location from which they are accessing these applications, and whether the access is from approved company-managed devices.

The process involves a two-step approach, initiated within a Conditional Access policy:

1. Define Conditions (Signals): These are the criteria that must be met for the policy to apply. Conditions include user or group details, target applications, sign-in location, and device management status.

2. Access Decisions: Once the specified conditions are met during a user login, the policy determines the access decision. This could involve granting access to applications, blocking access entirely, or allowing access but requiring multi-factor authentication for an extra layer of security.Create Conditional Access Policy

Assign signals (conditions)

• Users/groups

• Application to grant/deny access

• Location (IP)

• Approved devices

Access decisions (grant/block access)

• Grant access

• Block access

• Require MFA

Common scenarios for implementing Conditional Access policies include:

• Centrally Enforcing Multi-Factor Authentication: Ensuring multi-factor authentication is required for administrators or all users in the organization.

• Blocking Legacy Authentication Protocols: Preventing sign-ins using outdated and less secure authentication protocols for critical applications.

• Location-Based Access Control: Granting access only to specific locations, aligning with a perimeter-based security model.

• Device Management Requirements: Requiring sign-ins from organization-approved and managed devices for specific applications.

It's important to note that the requirements for managed devices and specific locations can be independent of each other, providing flexibility in policy configuration. Overall, Conditional Access policies elevate security beyond the simple username and password requirement, allowing the application of additional conditions to approve or deny access. In the next lesson, we'll explore further aspects of security in Azure.

Multi-Factor Authentication Is More Secure but Less Convenient

More steps required to log in

• Password and device/biometrics

• Increased user frustration:

• If everything is not working as expected

• Overall, less convenient

Passwordless authentication aims to strike a balance between security and convenience, recognizing the inherent conflict between the two. While multifactor authentication is universally more secure, it tends to be objectively less convenient due to the added steps involved.

Objective: Increase Convenience While Staying Secure

Remove password from system login

Replace with:

• Something you have (phone/key fob)

• Something you know/are (on device)

  • Fingerprint/face unlock/PIN

The objective of passwordless authentication is to increase the convenience of logging into a system while maintaining a high level of security. It seeks to achieve the best of both worlds by combining the relative convenience of using passwords only with the increased security of multifactor authentication.

In a typical scenario, passwordless authentication removes the traditional password prompt during system login. Instead, authentication is performed using either something you have (e.g., a phone or key fob) combined with something you know or something you are (e.g., biometrics like fingerprint or face unlock) on the device you own. This eliminates the need to memorize a password for system login.

Microsoft Authenticator App

• Microsoft’s MFA mobile app

  • Configure in Azure AD

• Authenticate in app with biometrics/PIN

Windows Hello

• Face recognition in Windows

FIDO2 Security Key

• Hardware key

When working with Azure and Azure Active Directory, there are three main passwordless authentication methods:

1. Microsoft Authenticator App: A mobile app available on iOS and Android, configured in Azure Active Directory. Users authenticate with biometrics, face unlock, or a PIN number.

2. Windows Hello: This method is specific to Windows and works with facial recognition cameras on Windows 10 or Windows 11, allowing users to use their face as an authentication method.

3. FIDO2 Security Key: A USB hardware key used for multifactor authentication. The USB key itself serves as the authentication device.

• Log in to Microsoft 365, and enter your username.

• Instead of a password, you are prompted to check Microsoft Authenticator.

• Use the biometric/PIN in the Authenticator app to confirm authentication.

• Confirm numerical challenge in the Authenticator app.

In a passwordless login scenario, after entering the username, users are prompted to check the Microsoft Authenticator app, use Windows Hello facial recognition, or insert the FIDO2 Security Key. The process typically involves verifying the authentication on the user's device, either through biometrics or a PIN number.

The end result is a secure authentication process that is relatively more convenient than entering a traditional password and using an MFA device on top of that. Passwordless authentication provides a user-friendly approach while maintaining a strong security posture.

we're focusing on securely collaborating with users outside our organization, such as external consultants assisting with Azure or Azure Active Directory configurations. One solution is to create a separate internal organization account for the external user to temporarily use. However, this approach requires the external user to manage two separate accounts, which may not be the most convenient solution.

A more streamlined approach for external collaboration in Azure is known as B2B or business-to-business collaboration. This involves inviting external users as guests into your Azure environment. Here's how it works:

1. Inviting External User:

   • Azure Active Directory can easily invite external users from various identity providers, including Microsoft, Google, and Facebook accounts.

   • Preconfigured identity providers simplify the invitation process, and additional extended identity providers can also be configured.

2. Permission Assignment:

   • Once the external user accepts the invitation, you need to assign proper permissions to their guest account.

   • Follow the principle of least privilege, granting only the permissions required for their specific job role.

   • Note that different permissions are required for Azure Active Directory and Azure subscriptions, as they are distinct permission environments.

3. Optional Steps:

   • Assign the guest user to an application integrated with Azure Active Directory.

   • Apply Conditional Access policies for additional security measures, such as requiring multi-factor authentication and restricting access to approved managed devices.

In summary, the process for inviting an external consultant into the internal Azure environment involves configuring the identity provider (if non-Microsoft), inviting the external user, assigning permissions, and optionally applying additional security measures through integrated applications and Conditional Access policies.

This approach ensures a secure and efficient collaboration environment for external users within your Azure setup.

Azure Active Directory Domain Services (AADDS) is a critical topic for larger organizations facing challenges in fully adopting cloud services. The primary obstacle lies in integrating older applications with modern cloud services. This lesson delves into the intricacies of AADDS, shedding light on its significance.

Before we proceed, a quick heads-up: this lesson involves numerous acronyms related to different Active Directory varieties.

The central focus is on comprehending the limitations of Azure Active Directory Service when dealing with cloud migrations, especially concerning the migration of legacy applications. Older business-critical applications often lack compatibility with modern authentication protocols like OAuth 2.0, necessitating the use of traditional Active Directory Domain Services (AADS). AADS involves managing protocols such as Group Policy, LDAP, NTLM, and Kerberos, encompassing classic Active Directory features.

It's crucial to note that Azure Active Directory is not a direct substitute for classic Active Directory, as they operate using distinct protocols and management methods.

Legacy applications

• Unable to use modern authentication protocols (OAuth 2.0)

Require traditional Active Directory (AD DS) management/protocols

• Group Policy

• LDAP

• NTLM

• Kerberos

Continue using on-premises AD

• Sync to Azure AD with Azure AD Connect

Configure AD server on Azure VM

• Also known as self-managed AD DS

• You maintain/configure the operating system (OS)

Azure Active Directory Domain Services (Azure AD DS)

• Managed Active Directory Domain Services

• Provides classic AD features in a managed service

  • Group Policy, LDAP, Kerberos, domain join

To address the challenge of migrating these legacy applications to the cloud, several solutions exist, each catering to specific needs. One approach involves maintaining the use of the on-premises Active Directory server. If the existing on-premises Active Directory environment is to be retained, synchronization with Azure Active Directory can be achieved through Azure AD Connect.

For organizations opting for a fully cloud-hosted solution, configuring another Active Directory server on an Azure Virtual Machine is a viable option. This scenario, often termed "self-managed Active Directory," entails maintaining and configuring the underlying operating system of the Azure Virtual Machine.

The third and primary solution discussed in this lesson is the managed service, Azure Active Directory Domain Services (AADDS). In contrast to the self-managed option running on an Azure Virtual Machine, AADDS is a fully managed instance of Active Directory Domain Services. It provides classic Active Directory features, including Group Policy, LDAP, Kerberos, and the ability to join servers to a Windows domain.

Azure AD DS is a managed service

• No need for OS configuration/management

• Behind the scenes: two Windows domain controllers for high availability

Create unique namespace/domain name

• Example: aadds-companyname.com

• Standalone domain, not extension of on-premises AD domain

One-way sync from Azure AD to Azure AD DS

• Synchronize users, groups, and credentials

• Azure AD may also bidirectional sync with on-premises AD

As opposed to the self-managed option running on an Azure Virtual Machine, Azure Active Directory Domain Services (AADDS) is a fully managed instance of Active Directory Domain Services. It offers all the classic Active Directory features, including Group Policy, LDAP, Kerberos, and the capability to join servers to a Windows domain. In the managed service, you are relieved of configuring and managing the underlying operating system.

AADDS operates with two separate Windows domain controllers running behind the scenes in a high-availability scenario. Despite this, you don't need to directly interact with these domain controllers; they serve as the underlying infrastructure supporting the managed service.

A crucial distinction between AADDS and classic Active Directory (ADDS) is that the managed AADDS service requires creating a completely separate and unique namespace or domain name, like "aadds-companyname.com." This is distinct from the typical companyname.com domain and emphasizes that AADDS is a standalone domain, not an extension of an on-premises AD domain.

Once configured with a unique domain name, the next step involves a one-way synchronization process from Azure Active Directory to the managed AADDS service. This synchronization includes users, groups, and credentials from your Azure AD instance.

In more complex hybrid scenarios, Azure Active Directory might engage in a bidirectional sync process with on-premises Active Directory environments, alongside the one-way synchronization with the managed AADDS service. This results in a two-way synchronization of users, groups, and credentials between your on-premises Active Directory and the managed AADDS environment.

To sum up, the managed AADDS service becomes the ideal choice for a cloud migration scenario where there's a need to lift and shift legacy enterprise applications to Azure Virtual Machines. This is particularly relevant when these applications don't support modern authentication standards and must be integrated with a classic cloud-hosted Active Directory instance. Choosing a managed service is preferable over maintaining a self-hosted environment on an Azure Virtual Machine. The resolution involves creating an Azure Active Directory Domain Services instance as the managed cloud-hosted version of classic Active Directory and integrating the legacy applications with the AADDS managed service.

Single sign-on (SSO) in Azure, specifically Azure Active Directory Seamless Single Sign-On, allows you to use one username and password to log in to multiple applications. Microsoft uses this concept for various services like Outlook.com, Azure, Skype, and the Microsoft Store.

In Azure, the SSO feature is integrated into Azure Active Directory (AAD). Once SSO is enabled in AAD, users can seamlessly access all applications connected to the AAD instance without the need to log in multiple times. It simplifies the authentication process by requiring only a single username and password for signing in to different applications.

For example, if a company like LlamaRama has applications such as an HR app, a payroll system, a training portal, and a lunch-ordering app, all connected to Azure AD, enabling SSO in AAD allows users to access these applications using the same username and password.

That concludes the information about Azure Active Directory Seamless Single Sign-On. If you have further questions or need a summary for the exam, feel free to ask.

AAD Is Fundamental!

You can’t use Azure without AAD. AAD is not the same as Active Directory (AD).

AAD Is First

The first service of every new account will be an AAD instance.

Tenant

Tenant = Organization Single instance of AAD

A user can be a member or guest of up to 500 tenants.

Subscription

Billing entity that controls the cost of resources and services associated with it.

Hybrid Cloud

AAD can help you manage users in a hybrid cloud architecture between on-premises and in Azure

Zero Trust Concepts

• Everyone assumed untrustworthy unless proven otherwise

• Regardless of location

• Trusted identities vs. trusted locations

• Necessary for remote work

Multi-Factor Authentication

• Extra layer of security using something you know, something you have, and something you are

Conditional Access

• If/then policy for granting access (i.e., conditions)

• Centralized management

• Examples:

• Require MFA

• Require managed device

Passwordless Authentication

• Bridge gap between security and convenience

• Remove system password

• Replace with something you have/are

• Methods:

• Microsoft Authenticator

• Windows Hello

• FIDO2 security key

External Guest Access

• External collaboration

• Invite external user with existing account

• Works with many identity providers

• Microsoft/Google/Facebook

Azure Active Directory Domain Services (Azure AD DS)

• Managed instance of Active Directory (AD DS)

• Integrates with classic AD features

• Kerberos, LDAP, NTLM, Group Policy

• One-way sync with Azure AD

• Requires separate domain

Single Sign-On

• Use single username and password to log in to multiple applications using AAD