Chapter 7: Identity and Access Management – Mastering Windows Security and Hardening

Chapter 7: Identity and Access Management

In this chapter, we will be reviewing identity and access management in depth, as well as their importance within an enterprise today. With the shift to a decentralized user environment and everything moving to the cloud, identity has become extremely critical and the need to protect our user identities has never been more important. Since users can now access their corporate information from anywhere over the internet, a simple breach of their identity could allow an intruder to log in and access the user's information and any data they have access to within the environment. Because of this, we need to revisit the traditional method of using a username and password and add enhanced protection to our identity and access model, which will be covered in more detail in this chapter.

In today's world, the use of passwords is becoming obsolete. Because of ongoing major breaches and the advancement of technology, our passwords have most likely already been breached and are sitting on the dark web for sale. In addition, there is a chance that the password you use has either been re-used on other accounts or there is some small variation in the re-used password. What does this mean? Essentially, someone with your password will be able to start accessing all your accounts if there is no additional security added. We are already seeing user accounts within services that haven't been breached being hacked because hackers are reusing usernames and passwords from other services to try and gain access. This type of attack is known as credential stuffing and, unfortunately, it is working!

In this chapter, we will provide an overview of identity and access management and all the components required to build a robust program. We will then cover account and access management, followed by authentication and Multi-Factor Authentication (MFA), and discuss what is next with authentication by considering a passwordless world. The end goal of your authentication strategy? To get to a passwordless world! We will finish off the chapter with some extremely powerful Microsoft cloud technologies to better protect your identities—Conditional Access and Identity Protection.

This chapter will include the following topics:

  • Identity and access management overview
  • Implementing account and access management
  • Understanding authentication, MFA, and going passwordless
  • Using Conditional Access and Identity Protection

Technical requirements

In this chapter, we will refer to identity management solutions, such as Microsoft Identity Manager (MIM). We will also provide overviews of different access and identity management services within Azure, and they require varying levels of licenses and requirements. It is encouraged that you research the specific licensing requirements for each solution independently if they fit your needs. At a minimum, you can follow along with the referenced solutions using the following:

Now, let's look at an overview of identity and access management.

Identity and access management overview

Identity and access management has never been as important as it is today. Identity can be somewhat considered as the foundation for security within your organization. Although there are other methods of compromising data, simply gaining access to a user or administrative account can be destructive. If an intruder compromises an account, they now acquire the same account level of access across all systems and data. All this can take place without anyone being alerted. It is very important that you are rigid with your identity and access policies. The role of least-privilege is a must! This is a role where no access is added to your account until needed based on your job function. We cover this in more detail in the Authorization section of this chapter. Essentially, if you don't need access, you don't get it. In addition, ensuring that you separate user accounts from administrative accounts is critical. There should never be elevated or privileged permissions added to your regular user accounts where general day-to-day tasks are performed. As already stated, passwords have become obsolete and do not provide the level of security needed today. You need to start implementing MFA as soon as possible, along with more modern technologies to protect your users and your organization's data.

Let's look at the foundation or framework of what comprises a solid identity and access management program. If you have studied for your CISSP certification, or some other security-related exam, you will be familiar with the term Identification, Authentication, Authorization, and Accountability (IAAA) or just Authentication, Authorization, and Accountability (AAA). (Here, we will use IAAA to emphasize identity as the first component of the process because, without an identity, the proceeding components cannot exist.)


The identity portion for your access relates to something that identifies who you are. In simple terms, it is a unique identifier that you enter to let the system know it is you who is trying to access it. A simple example could be a username, an email address, or an employee ID number. Traditionally, within a Windows environment, you may be familiar with sAMAccountName, which was essentially a username that only worked within your corporate network. Using this outside your corporate network was not possible as there was no unique identifying factor that accompanied the username on places such as the internet. Today, you will need to adopt the userPrincipalName (UPN) method for your identity in order to support internet- and cloud-based technologies. The UPN appends a domain that you own to the end of your username to provide a unique identity no matter where you are and how you access it. An example of a UPN identity could


After you have entered your identity, you will typically be presented with some form of authentication to validate that you are the person who should be gaining access to the system. The most common form of this is entering a password. As part of authentication, there are four different methods to authenticate your identity that are worth mentioning:

  • Type 1 is something you know. This is currently the most common and widely adopted method of authentication. Some examples include a password, PIN, or passphrase.


    An example of a password could be W!nd0ws10, while a similar passphrase could be W!nd0ws $ecure 10. Typically, passphrases can contain spaces, are longer, and are easier to remember than a password.

  • Type 2 is something you have. This authentication method consists of something you have with you in order to confirm it is you. Some examples include a hard token, a soft token on your phone, or a smart card. With Microsoft, the Authenticator app is an example of this.
  • Type 3 is something that you are. This authentication method is commonly known as biometrics or something physical that is used to authenticate you. Some examples of something that you are include your fingerprints and facial or iris scans. On Microsoft, Windows Hello falls under this category of authentication.
  • Type 4 is location-based. This authentication method may not be as commonly used but can be extremely powerful with the advancement of cloud compute and AI technologies. Authenticating based on location allows you to authenticate users based on a defined geolocation. Think of a company that only conducts business within the United States. Why would they expect anyone to access their servers from outside the United States? Anyone accessing them from outside the United States can be expected to be an intruder and should be blocked. On Microsoft, Conditional Access can provide this level of authentication.

Next, let's look at authorizing your identity against the system to gain access to data.


Once you have been authenticated into your environment or system, you will need to access the data or systems you have been authorized to access. Authorization is a method in which permissions have been added to your identity to allow access to some information or a system. Just because you have been authenticated, it doesn't mean you are authorized to access data or a system. This is where the principle of least-privilege comes into play and as a best practice, there should be no authorization added to a new identity by default. Authorization isn't an easy task, especially as an organization grows. Ensuring that someone only has access to what they are authorized to do can be a full-time role, especially ensuring that the authorization is updated and removed as roles change. To better help with authorization, you need to ensure you have a well-defined access model in place and tools such as identity management, AD for centralized user and group management, and most importantly, Role-Based Access Control (RBAC) to define your users' authorization based on their job functions.

Now that the identity has been authenticated and authorized to your system, let's look at what accountability is in terms of the actions and data accessed inside an environment.


The last function is known as accountability, also referred to as accounting. This is the function that allows us to ensure that an identity or user is not abusing their rights or the authorization provided. Here, we need to ensure that we track all the activities of our users and ensure auditing is in place to hold anyone accountable for any misuse of their identity and access. This is also a critical process as part of any investigative and forensic work that is carried out for attempted breaches or compromised accounts. Knowing exactly where an account has been authenticated and what data it has accessed must be captured and audited for historical purposes.

As you can see, the full scope of an identity and access management program will take great effort and time to implement correctly. With the identity of your users being at the forefront and essentially serving as the key to your data and systems, organizations must implement a well-rounded and robust identity and access management program. As we discussed earlier in this book, ensure your policies and standards have leadership support to ensure your program is effective.


As a start, to assist with password management practices, it is highly recommended that you provide a form of a password manager to your users. It is also recommended that you educate your users about identity protection services. There are many services available and you can view the service as insurance coverage for your identity. It is worth the investment!

To finish off this section, we wanted to remind you of the importance of physical access security. We also touched on this in Chapter 3, Server Infrastructure Management, in the Physical and user access security section. Ensuring that an intruder can't easily walk into your site is not only critical to your data, but also to the safety of your employees. Nothing is more important than human safety! Referring back to the NIST cybersecurity framework, there is a specific category and subcategory to ensure you implement the minimum recommended guidelines for physical security, as shown:

Figure 7.1 – The NIST cybersecurity framework's physical access to assets guidelines

The following link gives you access to NIST Special Publication 800-53 (Rev. 4), referenced in the preceding figure:

Next, we will review account and access management and what is involved in the identity management life cycle.

Implementing account and access management

One of the most important tasks with your identity and access management program is the management of accounts and the access they have. There is a whole life cycle process that relates to account and access management and may involve multiple teams to make the process a success. There's also a chance that multiple systems and tools are involved in the life cycle, including manual human processes that have room for error and increase vulnerability due to poor housekeeping. The account and access management life cycle is a complex process and has only become more challenging with the ongoing expansion of more apps, as well as the shift to the cloud. A typical account and access management program may involve resources from HR, the identity and security teams, technical operations teams, hiring managers, and potentially others.

To ensure success with your account and management program, it is critical that you have well-defined policies in place that enforce the correct standards and procedures that must be followed. This process is critical as part of this life cycle. Any mismanagement of this process could result in significant damage to your organization. Some examples of this include applying incorrect permissions to a user account, not disabling a disgruntled employee's account who was dismissed, or not managing and auditing your privileged accounts, to name a few. One item to help with any mismanagement or even manual errors is to implement automation. The more you can automate, the fewer errors will occur. There will always be a need for manual processes, whether it be the initial input of user data, physical validation that the information is correct, or applying an end date to a user, but the more you can reduce any manual intervention, the less error-prone it will be.

Every organization is structured differently, but for the most part, you will likely have accounts categorized by Full-Time Employee (FTE), contractor, vendor, guest, or service accounts. For each of these categories, you will need separate policies and procedures for their management. Your FTE accounts will most likely be managed differently to your contractor accounts, as well as your vendor and guest accounts. Ensuring all these accounts are managed correctly will require the ongoing management and auditing of your accounts and their access. This will require close collaboration between HR, the identity and security teams, and the hiring or reporting managers of these accounts. In the next few subsections, we will cover the following topics:

  • HR and identity management
  • Integrating directory services
  • Using local administrative accounts
  • Managing Azure external user access (Business-to-Business (B2B))
  • Understanding the Azure cloud administrative roles
  • Implementing privileged access management security tools
  • Using Azure RBAC


    Never use shared accounts within your environment. All users who access your environment should have an account assigned that identifies them. Without an assigned identity, you have no accountability.

Let's look at a typical account and access life cycle scenario that starts with HR as the source of authority for the identity.

HR and identity management

Your identity management life cycle needs to start somewhere, and that is most likely with your HR department. This is where your employees start their journey within your organization. Once an employee has accepted a position, their digital profile is created. HR software is very specialized and is typically independent of the core IT identity services. Within an HR system, you can expect to manage your personal information, time off, payroll, performance, employees you manage, and learning, as well as view internal job opportunities, and much more. The big challenge with your HR system is efficiently integrating the application into your core identity services.


There are many HR platforms available on the market today. Microsoft also has a product for an HR management suite known as Dynamics 365 Human Resources. Other products you may be familiar with include SAP SuccessFactors, Workday, and Oracle PeopleSoft.

When you look at your core identity services, you are most likely going to have an AD deployment in your on-premise environment that's even synchronized to Azure AD if you have already begun your cloud journey. One of the challenges of AD within a traditional deployment is the limitation on delivering a well-rounded identity service beyond the basics. Having the ability for employees to request contractor accounts, manage their own AD groups, update members and profile information, use a self-service portal, and provide advanced ID management and full life cycle management of identities and automation are not native features of AD. Because of this, there is a need for an identity management solution to sit between your HR source and AD to provide the required efficiency.

From a Microsoft standpoint, this solution is known as MIM, which is the latest edition of Forefront Identity Manager (FIM). MIM is an extremely powerful management tool and serves as a critical component of the overall identity life cycle and supports your organization's identity and access processes. MIM deployments can be highly complex depending on the level of customizations needed. To learn more about MIM and its capabilities, visit


Ensure you have set up secure automated integration from your HR system into your identity management system. In addition, your HR system will contain Personal Identifiable Information (PII), so it is critical that you work closely with the HR team to ensure the data is correctly secured and encrypted any time it leaves the HR system.

As cloud adoption strengthens, an ideal scenario would be to directly integrate your HR system with a cloud identity provider, such as Azure AD. Unfortunately, many organizations have compliance requirements to keep identities and passwords on-premises and many applications still rely on AD for authentication and as the identity provider. Because of this, a hybrid deployment from on-premises to the cloud is commonly seen within your identity architecture.

Next, we will review the available Microsoft directory service technology to support your identity life cycle.

Integrating directory services

Beyond an HR system with integration into your identity management solution or MIM is AD. AD is an on-premise hierarchical directory that stores objects, such as user accounts, passwords, user information, computer objects, security groups, and much more. This is where the identity of your users will be active and enabled for accessing the IT systems within your environment.

Referring back to the overall identity life cycle, once an object has been established in MIM, based on the HR feed, it will then provision an account in AD for the user. The MIM object isn't the account that the user will use but is typically set up as the authoritative source to the AD object. What this means is if the MIM object is set to be termed because the HR system sent a term instruction, the AD object will be disabled. Depending on your configuration, re-enabling the account directly within AD will eventually revert it to a disabled state since MIM is authoritative. This is extremely powerful and exactly how the process should work. It also helps prevent anyone with access to AD from creating and enabling accounts that they shouldn't. All requests should filter through MIM, or other identity management tools, for better control and accountability as they serve as the centralized place for all identity and access requests.


Protecting your active identities is critical and AD needs to be at the core of this protection. The following is Microsoft's best practices for securing AD:

With a shift to the cloud, a copy of these identities needs to be synchronized to Azure AD to support the identity and authentication requirements of the modern world. To support this, a synchronization tool is needed between your on-premises AD environment and the cloud identity provider or Azure AD. This will enable the hybrid identity of your organization. Microsoft has a tool known as Azure AD Connect that provides synchronization for all or any selected objects or Organizational Units (OUs) from your AD into Azure AD. With Azure AD Connect, you can provide a single identity for your user to access both on-premises resources as well as cloud-based resources.

One important decision to make around Azure AD Connect is the method of authentication for your users to sign in. Since Azure AD only syncs a copy of your identity, you need to determine how to manage your passwords within the cloud. Azure AD Connect provides the option to sync the hash (known as password hash sync), pass-through authentication back to on-premises to authenticate, or leverage federated authentication, such as Active Directory Federation Services (AD FS) or a supported third-party system. In order to take advantage of Microsoft's advanced cloud security identity features, you will need to enable password hash sync.


Microsoft does not sync the actual passwords of your user accounts. For optimal security of your user passwords, a hash of the password with a per-user salt is synced to Azure AD.

Azure AD is Microsoft's enterprise cloud identity provider, providing the next generation of identity management and security for your users. Some examples of services that a user will log into using their Azure AD account are Exchange Online, OneDrive for Business, and so on. The user will not know the difference between the traditional AD account versus the Azure AD account. This is optimal for the user experience.

In its simplest form, this completes the life cycle of a user's identity from the system of record up to the cloud. The life cycle provided can be applied using any identity service or vendor and the following workflow should be referenced for the life cycle and process of your identities:

HR > Identity management system > Traditional directory service > Identity synchronization > Modern directory services

It's also critical to ensure the off-boarding process works correctly throughout this life cycle. If properly configured, when HR initiates a termination, the account should be disabled throughout all directories. Any failures in this process could allow a user to access resources after they have left the organization, which is a serious security concern.


Make sure you are fully aware of synchronization times within each of your identity systems. Terminating a user within HR can take time to synchronize downstream through your systems. For immediate action, you may need to manually intervene to ensure identities are correctly disabled in a timely fashion.

In addition to your identity life cycle is your group management strategy. Ensure you constantly audit group memberships and understand what services, applications, and data your users have access to. Ensure users don't have access to groups that they shouldn't and as users change roles, it is critical they are removed from groups that they no longer need access to. Group management must be part of your identity life cycle and the correct processes and procedures are critical to ensure they are managed correctly.

The following diagram illustrates a high-level architecture of what your identity life cycle may look like:

Figure 7.2 – The identity life cycle architecture example

The account life cycle can be very complex, and mismanagement of this process can easily open up opportunities for vulnerabilities with your Windows devices. Some best practices with this architecture include working closely with your HR team, ensuring all traffic, feeds, and integrations are encrypted, minimizing the number of privileged identities, and enforcing MFA on all accounts. Be sure to enable auditing to hold accountability and add safeguards to ensure the identity portal is secure and not accessible over the internet if possible.

Next, let's look at local administrative accounts and how to reduce the vulnerabilities associated with them.

Using local administrative accounts

There are a few different schools of thought when it comes to local administrator accounts on devices. One is simply not to allow them and is the obvious, more secure choice. Any means of elevated access should be managed by either AD group membership or through Azure AD roles. These accounts should also have strict password requirements, managed with a Privileged Access Management (PAM) solution, and should not be local to the device. On the other hand, there may be legitimate reasons as to why these local accounts exist. Perhaps the help desk leverages these accounts to remotely install an application. They may exist as a failsafe if systems don't frequently connect to a domain controller and are prone to trust relationship errors. They can even be useful in a scenario where an Azure AD-joined device is un-joined and there is no account available to log in locally.

Another common scenario where local administrators exist is when users claim they need this access to perform their job functions. While this may prove true in some scenarios, this is not generally the case. Many times, the user just doesn't want to be inconvenienced if they need to install an app or run some process that requires a call to the support desk. To combat this, many organizations incorporate a form of approval for temporary admin access. This can be accomplished either through temporary security group membership in AD or through a software center package with a scheduled task to remove them after a specified amount of time. In our experience, unless the user absolutely must have administrative rights and is willing to get documented approval from their supervisor, we advise against doing this. In addition, we recommend that if a user must have a local administrative account, it should be a separate account to their regular identity, have stricter password requirements, and be managed by IT, where access can be revoked or the password changed at any time. Imagine two common attack scenarios.

In scenario one, the user unknowingly downloads a macro-enabled Excel spreadsheet that invokes a PowerShell command. The command enumerates all local users and mapped drives, can now run processes in the user's context, and attempts to install a keylogging application. If the user's normal identity has local administrative access, then the malicious macro inherits these permissions and can complete the installation. Now, the keylogging application sends keystrokes and all harvested data back to a remote server in another country.

In scenario two, the user requests a unique local admin account but sets an identical password. A malicious actor has infiltrated the network and uses a technique known as Link-Local Multicast Name Resolution Poisoning (LLMNRP) with NetBIOS name service spoofing to trick a response to the computer. As a result, the user's system is redirected to fake services that wait for mistyped network shares or system addresses that do not resolve in the local host's file or DNS. The credentials and the user's hash are then harvested by displaying a fake password prompt to what looks to be a legitimate login page. Now, using the recovered credentials, the actor can enumerate other accounts on the system and, through trial and error, attempt to crack the local admin account or gain other access using credential stuffing. Even worse, if this system is connected to the domain, they can further query the domain controller and enumerate users, systems, and groups and continue to further move laterally.

These are just two common examples. The following are a few recommendations to better manage local admin accounts:

  • For domain-joined systems, implement a system known as a Local Admin Password Solution (LAPS) to rotate local administrative account passwords if they must exist. For more information, including a link to download the LAPS solution, visit
  • Use a PAM solution from reviewed vendors, such as Thycotic or BeyondTrust, to manage the local administrative accounts on your workstations. These vendors offer robust solutions, can manage multiple account types, and have reporting and auditing functionalities built into them.
  • If you are using Windows Autopilot, set the user account type to standard in the Autopilot profile. This will allow the user to enroll a device onto Azure AD and Intune but remain a standard user.
  • For Azure AD-joined devices, leverage the additional local administrators on the Azure AD-joined devices setting in Device Settings, also known as the Device Administrators Azure AD role.


    Using the Device Administrators Azure AD role is a convenient way to add accounts as local administrators, but be mindful that this will make them an administrator for all Azure AD-joined devices.

Next, let's look at external or guest accounts, which are commonly referred to as B2B.

Managing Azure external user access (B2B)

Azure AD B2B is a game-changer within the enterprise identity space. When looking back at the traditional model with AD and on-premises applications, providing access to external partners was far from an easy task. For most, setting up an identity within their local directory server was probably standard practice. This meant needing to create and manage the life cycle of external accounts within your environment, far from a secure model. Others may have set up AD FS or third-party federation applications to support the ability to allow the external party to use their own ID. The issue with this is the involvement, complexity, and effort to set up the federation between external vendors. The more external vendors you work with, the more integrations you will need to set up and systems to manage.

Azure AD B2B allows you to simply invite an external or guest user into your Azure environment and provide them access to your applications and services. Once invited into your organization, the external user then authenticates with their current work identity and password to access approved applications. There is no need to provision new accounts or add any additional infrastructure to support collaboration with your external users. The best part of this process is the user's identity is managed and maintained by their hosting organization, which is a significant improvement over past models. Once the external user is termed within their hosting environment, they can no longer access your environment. From a security and auditing perspective, this is a major advantage.

You can learn more about Azure AD B2B from

To view and access the external user settings, log into, click on the portal menu at the top left, and choose Azure Active Directory. Select User Settings and click on Manage external collaboration settings. Here, you can configure the external collaboration settings. The settings in the following screenshot are a good place to start to secure your external collaboration settings:

Figure 7.3 – The Azure AD external user settings

To invite a new external user into your organization, go back to the Azure AD management screen and click on Users, then click on New Guest User. You will be asked to provide information, such as Name, Email address, First name, Last name, Personal message, Groups, Roles, Usage location, Job title, and Department. By default, the user will not have access to anything other than the Office 365 portal. Once this information is entered, click on Invite.

The external user will receive a welcome email, as in the following screenshot, to accept the invitation and gain access to your environment using their business email:

Figure 7.4 – An invitation example for B2B access

Microsoft has both B2B and B2C as part of its guest access services. You can visit to view the differences.

The Azure AD B2B model is extremely powerful and allows you to move away from old methods of needing to provision accounts within your environment. The model is very simple and, from a security and auditing perspective, is a step in the right direction.


To enforce additional security on your external and guest users, use a conditional access policy to enforce MFA.

Next, let's discuss the different types of administrative roles available on the Azure cloud. It's important to cover these roles as they directly relate to your Windows systems due to their control over the management plane in which Windows is administered.

Understanding the Azure cloud administrative roles

Administrative role permissions are worth discussing as they can have a direct impact on your Windows workstations and servers that run in the cloud. An example of this is that an Office administrative role may have permission to add or remove licenses. If an Intune license is removed, then the user will be kicked out of Intune management. Another example could be an Intune administrator that can perform actions such as adding or removing apps and configurations, as well as accidentally initiating remote actions, such as wiping or deleting a device. It is important that these permissions are only assigned as needed and limited. There are many types of cloud-based administrative roles that serve different purposes, and although they are named similarly, they can perform different types of actions. Let's break them down into a few categories, which include the following:

  • The Office 365 admin and Azure AD roles
  • Intune roles
  • Security and compliance admins

Let's look at these different types of admin roles.

The Office 365 admin and Azure AD roles

These administrative roles are mainly available to be assigned in the Microsoft 365 (M365) admin center and are commonly used to assign permissions that administer many of the SaaS offerings from Microsoft, such as SharePoint or Teams. Most of the M365 admin roles will overlap with the Azure AD roles and an assignment in either portal will be honored. Some examples of Office 365 admin roles include the following:

  • SharePoint admin
  • Exchange admin
  • Teams admin
  • PowerBI admin


    The M365 admin center has a useful feature called Compare Roles. Select up to three roles to compare their permissions.

The following screenshot shows the Compare roles page:

Figure 7.5 – The M365 admin center Compare roles page

Like Office 365 admin roles, the Azure AD roles are used to grant access to Azure AD and other Microsoft services. They also contain additional roles specific to managing Azure AD directories and B2C identities.

Next, let's look at the roles that are specific to managing aspects of the Intune service.

Using Intune roles

You can use Intune roles to limit access to specific functions inside Intune and to create custom roles. Intune administrator is the only built-in role available to M365 and Azure AD roles and grants full administrative access. Use the Microsoft Endpoint Manager admin center to granularly assign permissions using the built-in roles. The following screenshot shows some of the built-in roles available for assignment:

Figure 7.6 – Intune roles within the Microsoft Endpoint Manager admin center

Next, let's look at the Security & Compliance administrative roles.

Security and compliance admins

The security and compliance admin roles contain permissions that are specific to compliance and document forensic tasks, such as data loss prevention, litigation holds, and eDiscovery. While they don't have a direct impact on Windows systems and subsystems, admins with these assigned roles can view classified documents, OneDrive files, email content, and where these files move to. These types of permissions are often exploited for corporate espionage. The following screenshot shows the security and compliance roles:

Figure 7.7 – The Office 365 security and compliance roles

Now that we have identified different types of privileged roles, including Office 365 and Azure AD admin roles, let's look at how you can protect access to your Windows systems using PAM and other identity management tools.

Implementing PAM security tools (PAM, PIM, and JIT)

When referencing the topic of privileged access security in terms of securing access to a Windows server, we can think of it as the action of accessing a server with an account or service with elevated rights. This account can be used interactively with remote desktops with tools such as PowerShell, or as a service account leveraged to run an underlying system service or scheduled task. We would not want anybody to have access to use these accounts or even apply elevated permissions to a user account granting rights to perform highly privileged actions on systems in the environment. Let's look at three ways to secure access using PAM, Privileged Identity Management (PIM), and Just-In-Time (JIT) solutions.

Using PAM

A PAM solution can be critical in helping organizations secure access to systems, meet compliance, and monitor the privileged accounts used in their environment. Privileged access can be defined when an administrator or account accesses a sensitive system and, therefore, directly exposes it to a higher risk of attack due to the ability to perform privileged actions. With an ever-growing threat landscape and a seemingly unlimited amount of attack vectors, implementing a PAM solution can provide a huge benefit in strengthening your company's security posture. PAM also helps organizations maintain compliance and avoid penalties from compliance violations if access is regularly audited. By implementing a PAM solution coupled with a JIT request approval process, the risk of compromise is greatly reduced. The core principle of JIT access uses a workflow approval process that provides temporary access or grants escalated permissions when needed. It helps eliminate the need for free-standing privileged accounts. A free-standing account always exists in the environment, whether it is actively in use or not, and can make great attack targets for malicious actors.

When choosing a PAM solution, look for the following core sets of features:

  • Account discovery for all systems, devices, and applications, which includes, but is not limited to, Windows, Linux, Unix, Cisco devices, and other networking equipment
  • The ability to manage local accounts and service accounts and restart services when needed to minimize the impact
  • Credential management capabilities, including password rotation, a workflow approval process, and auditing trails
  • Password rotation for stale passwords of free-standing (always-existing) privileged accounts
  • The ability to provide access to systems using tools, such as web password fillers and Remote Desktop Protocol (RDP) Secure Shell (SSH) launchers, that never expose credentials
  • Discovery alert rules to notify the security team if new backdoor accounts were created without approval
  • Automation workflows for privileged execution using scripted tasks
  • Monitoring and auditing capabilities through remote session recording, command logging, and analytics
  • The capability to link to an IT Service Management (ITSM) tool or change management process
  • SIEM integration for leveraging Security Operations Center (SOC) services
  • Third-party access leveraging Single Sign-On (SSO) and MFA

SaaS solutions are becoming a popular option in the PAM space. Depending on your use case for PAM, a SaaS solution can offer a lighter footprint and eliminate the need to deploy extensive infrastructure

Next, let's enhance the PAM solution and look at JIT access.

Connecting with JIT access

JIT access is used to provide an account with the permissions needed to perform its operations for a limited time and then remove unnecessary access after the time expires. While PAM is a means to control access to accounts, JIT adds an additional layer to help mitigate any risks from "free-standing" or always-available accounts. Typically, access is granted through an approval process with a set of policies that defines who can request the defined role. With this, JIT helps enforce the principle of least-privilege. Many PAM vendors have a JIT solution built into their product, these days. Azure offers two solutions that have a similar feature set, as described previously, called Azure PIM and Azure Security Center JIT access. Azure JIT is available through Azure Security. Azure JIT provides JIT access by policing the inbound traffic ports used for the remote management of your virtual machines by a set of rules enforced through network security groups. By using an approval workflow through Azure Security Center, when access is granted, the locked-down ports are opened.


Chapter 6, Network Fundamentals for Hardening Windows, includes a walkthrough to configure Azure Security Center JIT access, but further reading can also be found at

While Azure Security Center JIT access protects access through network rules, let's look at Azure PIM to provide temporary access to admin roles through eligibility.

Enabling admins with Azure AD PIM

Azure PIM is a service that allows you to control access to resources and services in Azure at the identity level. Let's consider an example of the VP of sales for a company to explain "privileged" identity. This VP may be considered high profile, but in the context of PIM, it's unlikely that they have any elevated access permissions to IT services and resources. A service desk employee, on the other hand, who may be an offshore resource or an hourly based employee, may have been over-provisioned and assigned a contributor role to your subscription at some point to perform a function. They may also have local administrator rights to Azure devices and/or server operator group membership in AD.

This service desk employee's account would be considered a privileged identity. Not only is the principle of least-privilege thrown out the window in this example, waiting for regular auditing of account permissions to flag this account as a high risk to remove privileges could occur too late, and your organization might be at risk if this account is compromised. Implementing Azure PIM helps balance these security risks while still allowing your employees to perform their duties safely. In fact, a key benefit of PIM is detecting which users are assigned privileged roles as a built-in auditing capability. PIM is built around the concept of eligibility by leveraging "eligible" admins as opposed to permanent admins. A permanent admin is a user who always has the privileges needed to perform their required actions. An eligible admin is a role that requires a user to activate their eligibility when they need to perform an elevated function. As far as permissions are concerned, both a permanent and an eligible admin can have the same rights, but the eligible admin doesn't need these permissions all the time.

For more information on the Azure PIM service, go to

In the following example, we are going to set up an eligible admin in Azure PIM for the Intune administrator Azure AD role. We will require justification and a ticket number reference and we will need to specify a maximum time that the role can be active for. Then, we need approval to activate it.

Azure AD Premium P2 is required to use and manage Azure PIM:

Take the following steps to enable Azure PIM:

  1. Log in to the Azure portal at
  2. Search for Azure AD Privileged Identity Management and select it.
  3. Select Azure AD Roles from the Manage section.
  4. Select Settings under Manage.
  5. First, we will modify the Intune service administrator role. Select Roles, and then find and select Intune Service Administrator.
  6. Change the maximum activation duration (in hours) to 2. Enable Notifications, Incident/Request ticket, and Require Approval.
  7. Scroll down and click on Select approvers and choose your account or an approver. Choosing at least two approvers is recommended.
  8. Click Save.


    Enable Multi-Factor authentication is grayed out for this role, but some roles require it to be enabled. Make sure you check the other role settings and enable MFA when requesting activation.

  9. Now, let's make a user an eligible admin for this role. Click on Azure AD Roles – Settings in the breadcrumb navigation to go backward. Select Members under Manage.
  10. Click on Add Member.
  11. Choose Select a role, select Intune Service Administrator, and click on Select.
  12. Choose Select members and find an eligible user, then click on Select.
  13. Click on OK.

By default, it will add the user as an eligible activation to the Azure AD role. When the user logs in to the Azure portal, they can search for Azure AD PIM and choose the Azure AD roles. It will display a list of eligible and current active roles. The following screenshot shows the activation screen:

Figure 7.8 – Activate a user as an Intune service administrator

This is a very basic example of how Azure PIM can be used to protect your Windows systems. PIM also extends beyond Azure AD roles to Azure RBAC for managing resources. Discovery is also useful for finding and auditing all permanent and eligible privileged roles in your subscription.


Azure PIM also supports external users to collaborate on Azure resources using B2B. For more information about B2B, visit

Next, let's look at Azure RBAC and provide an overview of how it's used for authorization

Using Azure RBAC

Once the account is set up and active, authorization will need to be added, depending on how many systems, services, applications, or access to third-party environments are needed. RBAC is the best solution to solve this challenge, but in most cases, you are not able to implement it 100% because of the constant growth and change. RBAC in Azure is used for the authorization of access to Azure resources by using role assignments. An example of an Azure resource could be anything from a virtual machine, a virtual network interface, Azure Firewall, or a load balancer, to name a few. RBAC roles are assigned actions based on resource providers and are typically assigned to a scope for granularity. Azure already has many built-in roles, and custom roles can be built using them as a template. To read the official documentation on RBAC for Azure resources, visit


We covered creating a custom RBAC role in Chapter 3, Server Infrastructure Management.

In this section, we covered various topics regarding identity and access management. To recap, we covered the account life cycle, beginning with the source of authority from HR to ensuring proper controls are in place to disable accounts when employees leave the company. Next, we discussed local administrator accounts and accounts that allow collaboration from external vendors, known as B2B. Finally, we discussed cloud-based administrative roles in Azure and Office 365 and finished discussing access management solutions, such as PAM, PIM, and JIT, before ending with RBAC. Next, let's look at the methods used for authentication, as well as how best to protect these methods and provide a good and secure experience for your end users.

Understanding authentication, MFA, and going passwordless

In this section, we will review authentication as you are familiar with it today. We will also look at MFA and its importance in today's technical world. We will finish with a review of what we can expect the next generation of authentication to look like with no more passwords. As already stated, a compromise of credentials is one of the most common methods of a breach today. Our current authentication models are outdated and need updating. The traditional method of entering a username and password is simply not acceptable and you need to make changes to improve. If you don't have a strategy in place to improve your authentication posture, add it to your top three security priorities. We need to assume that our account information and passwords have already been breached. If they haven't, it's only a matter of time before they are!

Looking at a traditional on-premises deployment, authentication methods consist of Kerberos, Integrated Windows Authentication, Digest Authentication, NTLM authentication, or TLS/SSL, depending on what you are accessing from your device and how you are accessing it. Modern authentication within Azure AD uses an access security token with claims, OAuth 2.0, and SAML, depending on what you are accessing and how it's been configured. Using a hybrid model will include all of these protocols as part of your authentication process, depending on what is being accessed and where the service is being provided.


For your on-premises deployment of AD, it is highly recommended that you enforce secure LDAP. By default, LDAP traffic is not encrypted and could easily be viewed by an attacker within your network.

Let's look at password management and recommendations for how to manage passwords.

Securing your passwords

Since passwords are still relevant and will be for a while, it is important to review your current policies and it could be time to make some changes based on newer recommendations. Your current password policies may consist of what has always been recommended as standard. This includes changing them every 90 days, using 8 characters as a minimum, and ensuring complexity. Now, security research has suggested new recommendations based on advances in cracking tools, password leaks on the dark web, predictable passwords as a result of frequent change, and users writing them down due to complexity. The following current recommendations are now widely recommended to counter these challenges:

  • Consider using passphrases over passwords.
  • Use a minimum of 12 characters. The more the better.
  • Remove the periodic requirements to change passwords and only change them in the event of account compromise.
  • Don't use common passwords.
  • Reduce complexity rules to allow passphrases to be easier to remember.

In your Windows AD environment, you can configure your password policy natively using Group Policy if you only require one policy for your domain. If there is a requirement to deploy additional password polices, then a fine-grained password policy can be configured and allows multiple password policies per domain. An example of this would be to enable a stronger password requirement for privileged accounts.


You can only apply a fine-grained password policy against global security groups or user objects. In addition, to use fine-grained password policies, the domain functional level must use Windows Server 2008 or newer.

Take the following steps to implement a password policy using Group Policy:

  1. To change the password policy using Group Policy, open the Group Policy Management snap-in from your management workstation.
  2. Right-click on Default Domain Policy, select Edit, then browse to Computer Configuration | Policies | Windows Settings | Security Settings | Account Policies | Password Policy. In the following screenshot, you can see where to configure your domain password policy:

Figure 7.9 – Default AD domain password policy

Use the following steps to implement more than one password policy using a fine-grained password policy:

  1. To use fine-grained password policies, log in to your domain controller (Windows 2012 or newer) with the appropriate permissions.
  2. Search for Active Directory Administrative Center and click on domain (local), then double-click on System and double-click on Password Settings Container.
  3. Right-click on the main screen and select New, then click on Password Settings.
  4. Fill out the requirements for your password policy and select the groups of users that the policy will apply against, then click OK. The following screenshot shows the new policy screen:

Figure 7.10 – Fine-grained password policy

For your Azure password policy, your options to modify are limited. By default, any account created in Azure can use a password between 8 to 256 characters, requires complexity, expires every 90 days, receives a notification after 14 days of setting it, doesn't allow the last used password to be used again, and locks a user out after 10 incorrect attempts. There are two sections to configure your Azure passwords. The first section is for setting the password expiration and the number of days that the user will be notified before expiration. To modify these settings, follow these steps:

  1. Log in to with the correct permissions.
  2. Click on the menu at the top left. Click on Admin | Show All | Settings. Click on the Settings sub-menu, then on Security & Privacy | Password expiration policy.
  3. Select Set user passwords to expire after a number of days to configure the two options. These policies apply to any accounts created directly in Azure AD.

The second section is the Password Protection section to prevent users from using easily guessed passwords and to customize the lockout settings for your tenant. To modify these settings, follow these steps:

  1. Log in to with the correct permissions.
  2. Click on the menu at the top left. Click on Azure Active Directory | Security | Authentication Methods | Password Protection.
  3. Here, you can modify the lockout threshold and the lockout duration in seconds, enable a custom banned list, enable password protection on a Windows Server AD, and change the password protection mode to Enforced or Audit.

The following article provides instructions to deploy Azure AD password protection on-premises:

Next, let's look at configuring Self-Service Password Reset (SSPR) as a self-help tool for your users.

Introducing SSPR

SSPR is a feature of Azure AD that allows users to self-set, reset/change, or unlock their passwords. This feature is only free for cloud identities looking for password change functionality. If syncing from an on-premises AD, then M365 Business or Azure AD Premium P1 or greater is required. For this discussion, let's assume we have hybrid users that have an on-premises AD identity synchronized to Azure AD.

In this section, we are going to cover how to enable SSPR, as well as how to configure a link on the Windows login page in the event that a user cannot get into their device. This can considerably minimize support calls and save the worker's time if they forget their password or device PIN. To do this themself from the end user's perspective, all that is required is an internet connection and an alternative method of authentication, depending on the SSPR configuration. To enable SSPR and set up the authentication and registration methods, follow these steps:

  1. Log in to the Azure portal at
  2. Go to Azure Active Directory | Users | Password Reset and choose All (or Selected to test), then click Save.


    You only can choose one security group if you are using the Selected option to enable SSPR. Keep this in mind if you're thinking about rolling this out.

  3. Choose Authentication methods under the Manage menu. Select 1 for the number of methods required to reset and select Mobile app code and Mobile phone as the methods available to users. Click Save.
  4. Choose Registration under the Manage menu. Leave Yes selected to require users to register when signing in and leave the default value of 180 days to require re-confirmation of their authentication information.


    This is an important setting worth noting if you're using regular user identities as service accounts. If SSPR is scoped to All users, then any service account will be required to re-confirm their verification methods every 180 days and can cause a process to stop as a result. The best practice is to use service principals as service accounts in Azure.

  5. Choose Customization under the Manage menu. Choose Yes to customize the help desk link and enter an email or URL to your service desk.
  6. Choose On-Premises integration under the Manage menu. In order to configure password writeback, Azure AD Connect must be set up with the password writeback configuration. Choose Yes and select No for the option to allow users to unlock accounts without resetting their password.

    The following screenshot shows the password writeback to on-premises AD setup option on the self-service password reset page:

Figure 7.11 – On-premises AD integration

For more information about how to configure password writeback with Azure AD Connect, visit

Once the self-service password reset has been configured, users can go directly to to reset their passwords.

After they enter their user ID and enter the characters for the CAPTCHA, they will be asked to verify their identity with an alternative method, as shown:

Figure 7.12 – The self-service password reset portal asking for additional security verification

Now that we have enabled SSPR, we will show you how to implement the Reset password link on the Windows 10 login screen.

Implementing SSPR for Windows 10 login

There are a few prerequisites and limitations to keep in mind before enabling the Reset password link on the Windows 10 login screen. This next walkthrough is going to assume that your workstations are all Windows 10 Azure AD-joined and Intune-managed. We will be using a custom OMA-URI setting on Intune device restriction profiles to deploy the configuration service provider (CSP).

For more information around the limitations and restrictions of using the Reset password link for Windows 10 clients, visit

To enable the Password Reset link on the Windows 10 login page, follow these steps:

  1. Log in to the Microsoft Endpoint Manager admin center at
  2. Click on Devices and choose Configuration profiles under Policy. Create a new profile.
  3. Give it a friendly name, such as Device Restriction – Windows 10 SSPR, and a description. Select Windows 10 and later for Platform and choose Custom for Profile type.
  4. Click on Add to add a new OMA-URI setting with the following configurations:

    Name: Self-Service Password Reset

    Description: Windows 10 Reset Password link

    OMA-URI: ./Vendor/MSFT/Policy/Config/Authentication/AllowAadPasswordReset

    Data Type: Integer

    Value: 1

  5. Click on OK and select Create. Click on Assignments and choose a security group or specific users or devices.

    The following screenshot shows the Reset password link that takes the user to the Azure AD SSPR web page:

Figure 7.13 – The Windows 10 Reset password link

We just covered passwords and the best practices for password management. Next, let's look at one way to eliminate the need for users to enter passwords multiple times, creating a better and more secure user experience with Azure AD Seamless SSO.

Using Azure AD Seamless SSO

Organizations whose devices are not fully Azure AD-joined can still leverage Azure AD authentication for domain-joined systems using Azure AD Seamless SSO. With Azure AD Seamless SSO, users' passwords are validated using either Azure AD pass-through authentication or Azure AD password hash synchronization. Both can provide a seamless SSO experience for users to access apps, such as Office 365, SaaS, and other line-of-business apps, without requiring additional login. First, let's clarify the difference between pass-through authentication and password hash synchronization.

Azure AD pass-through authentication allows a synchronized password between on-premises and the cloud. Passwords are validated directly against a Windows Server AD. Choose pass-through authentication if you wish to enforce on-premises security and password policies and do not want passwords to be stored with the Azure AD authentication service.

Azure AD password hash synchronization synchronizes the stored on-premises password hash to the Azure AD authentication service using Azure AD Connect. Authentication takes place against Azure AD, not against on-premises AD. Whenever a password is changed on-premises, the password is synced (within 2 minutes) to Azure AD. If password writeback is configured, then a user can change the password from the cloud and sync it back on-premises. If using password hash synchronization, any on-premises password complexity policy will override any policies configured in the cloud. Any on-premises expiration policy will not be honored in the cloud and if a user's password expires on-premises, cloud services will not be interrupted.


Currently, a policy called EnforceCloudPasswordPolicyForPasswordSyncedUsers is in public preview, as well as a feature to synchronize temporary passwords with the ability to force a password reset on the next login.

Next, let's consider seamless sign-on. Not only can the user use the same password to log in to cloud applications, but with a few additional configurations, they can now also silently sign in to apps, such as the Office 365 web portal, without having to re-enter their credentials. In the Azure AD pass-through authentication architecture, the Azure AD Connect agent allows the passing of Kerberos tickets to and from the domain up to the cloud to provide an authentication mechanism. To view the status of Azure AD Connect, as well as the agent status, follow these steps:

  1. Log in to the Azure portal at
  2. Choose Azure Active Directory and select Azure AD Connect from the Manage section.
  3. Under the User Sign-In section, Pass-through authentication status should be set to Enabled. You can click on it to view its status, IP address, and any warnings issued for the authentication agent.

If you are leveraging Azure AD pass-through authentication, there is one additional step that is needed for your endpoint to leverage the feature using Group Policy. There are two Azure AD URLs that need to be added to your computer's intranet zone that will allow successful Kerberos pass-through. Take a look at these steps:

  1. Add the URLs to User Configuration > Administrative Templates > Windows Components > Internet Explorer > Internet Control Panel > Security Page > Site to Zone Assignment List.
  2. Set this policy to enabled and add the following URLs with a value of 1. Anything with a value of 1 is placed into the intranet zone:

    The following screenshot shows the added URLs with a value of 1:

Figure 7.14 – The site-to-zone assignment list for trusted sites

The Microsoft documentation has a full write-up on SSO deployments and can be reviewed at

Next, let's look at how we can configure Azure SSO for other applications to leverage an Azure AD identity and authentication.

Configuring Azure SSO

You are probably already aware of SSO and most likely have it deployed within your environment today. Having SSO in your environment provides significant improvement and security over your account management. Without SSO, users would need usernames and passwords for every application and service they need access to. Not only is this a bad experience for the user but from an administration and operations perspective, it becomes unmanageable. The downside is that one account now has access to many applications and services with SSO, which is why it is important to ensure you provide strong access and management policies with your user accounts. Applying technologies such as MFA and location-based access will help with these scenarios.

The modern version of SSO from Microsoft is currently known as Azure AD SSO. Azure SSO allows you to integrate your Azure identity into any SaaS, on-premises, or custom-developed app that supports standard SSO protocols, such as the Security Assertion Markup Language (SAML). The on-premises version of Azure SSO that you may be familiar with is AD FS. AD FS has served a great purpose in the traditional world for federation and SSO, but the infrastructure needed to support and maintain deployment can become very complex. Shifting this service to Azure requires no infrastructure to support SSO and integrating SSO has become very simple, with minimum configuration and clicks needed. In addition to the standard SSO integration, Azure SSO builds on Azure AD with the ability to use all the advanced and security features for your enterprise app deployments.

A simple SSO setup with an external enterprise app using SAML can be configured by taking the following steps:

  1. Log in to
  2. Search for Enterprise Applications and navigate to the management console.
  3. Click on All applications on the left, then click on New Application.
  4. For the purposes of this demonstration, we will select Non-gallery application (there are also many featured applications that you can select to set up SSO with those apps).
  5. Enter a name for the app and click on Add. Once you click on Add, you will be directed to the new app.
  6. Click on Single sign-on from the left-side menu, then click on SAML.
  7. Next, you will be prompted to enter your SAML information. If you are using a third-party SaaS app, it will need to provide you with the basic SAML configuration and you will need to provide it with the SAML signing certificates.

    The following screenshot is of the SAML SSO configuration page:

Figure 7.15 – The Azure Enterprise app with the Azure SSO SAML configuration screen

If you look at the left-side menu in the preceding screenshot, you will see that you have the ability to configure who can access the app with the Users and groups option and you can apply Conditional Access policies, audit logs, and much more to ensure access to your Enterprise applications are hardened and secured.

Next, let's look at how to enable MFA.

Configuring MFA

One of the more important technologies in this book that we would recommend you deploy immediately if not already enabled is MFA. Passwords have become obsolete, especially used as the only factor for authentication. If you aren't using MFA with your Azure subscription, then make doing so a priority now. The benefit of using MFA in Azure is that you can complement it with Conditional Access policies or Azure AD Identity Protection. Complementing MFA with these technologies means you don't have to force the user to use MFA all the time, but instead, you can apply rules or risk-based conditions that would enforce the need for MFA to be prompted. This provides a very powerful, secure deployment and, at the same time, eases the technology onto your users without causing too much disruption.


Azure MFA is included in the free Azure AD license, but in order to take advantage of the advanced features of MFA, you will need to increase your license. The following link provides an overview of the different license types:

To access the Azure MFA settings, follow these steps:

  1. Log in to
  2. Click on the portal menu at the top left and choose Azure Active Directory.
  3. Select Security and choose MFA. You will see the following screen:

Figure 7.16 – The Azure MFA settings


From the Getting started screen, click on Additional cloud-based MFA settings to add/remove the specific verification options you would like your users to use.

You can find additional details on the configurations shown in the preceding screenshot at

There are several authentication methods currently available on Azure AD. They include the following:

  • Using the Microsoft Authenticator app on your Apple or Android device:

    --Verification code provided on the app (renews every 30 seconds)

    --A push notification where you click on Approve when prompted

  • A verification code provided to a hardware token
  • A call to your cell phone where you will need to press #
  • A text message to your phone with a verification code

There are three supported methods in which MFA can be required for your users:

  • Enabled at the user level, which will require MFA every time the user authenticates. This option takes precedence over the other two methods, so it may not be the most practical one to use. This option is more fitting for privileged accounts.
  • Enabled using Conditional Access policies, allowing the use of advanced criteria such as the location, device state, device compliance, approved applications, assigned roles, and so on. This requires the Azure AD Premium license to be enabled on the user's device.
  • Enabled using Identity Protection, applied when any detected sign-in attempt or user risk occurs. This also requires the Azure AD Premium license to be enabled on the user's device.

You can enable user-level MFA by using the following steps:

  1. Log in to
  2. Click on the portal menu at the top left, then click on Azure Active Directory.
  3. Click on Users, then put a checkmark next to the user you would like to enable MFA for.
  4. Click on Multi-Factor Authentication and a new window will open.
  5. Put a checkmark next to the user you would like to enable, then click on Enable, as in the following screenshot:

    Figure 7.17 – Enabling MFA for a user

  6. Click on enable multi-factor auth on the pop-up window, then click close.

When the user you enabled accesses the portal for the first time, they will be required to set up MFA for their account. If the user is using the free version of an MFA license, they will only see the mobile app option:

Figure 7.18 – Setting up MFA for the first time


Microsoft no longer supports the MFA server as of July 1st, 2019. In order to protect your on-premises infrastructure with MFA, you will need to review the third-party options or ensure you have PAM in place for the best protection.

Next, let's look at using a form of biometric authentication to log in to your Windows devices, known as Windows Hello.

Introducing Windows Hello

Windows Hello is Microsoft's biometric or PIN authentication feature for your Windows 10 devices. This technology replaces the traditional password authentication methods that have always been used on Windows devices. Windows Hello works with a Microsoft account, an AD account, or an Azure AD account. Support is also in progress to support an identity provider service or a reliable party service that supports Fast ID Online (FIDO) v2.0. Windows Hello provides two options for biometric authentication on supported hardware, and the biometric data and PIN are only stored on the local device and are not available externally. This is a significant security enhancement that helps ensure an attacker isn't able to get a copy of your biometric data. The two options for Windows Hello biometrics are as follows:

  • Facial recognition
  • Fingerprint recognition

Next, let's look at what it means to go passwordless.

Understanding going passwordless

Passwordless is the future and Microsoft's making a big push in this direction as an authentication strategy. The technology is already available, and you can go passwordless today. Unfortunately, it may not be easy to get to a passwordless world straight away, but you do need to understand and begin this journey sooner rather than later. The methods that are used to provide a passwordless world are currently much more secure for your users.

With the elimination of passwords, authentication is improved by using something you already have, such as a phone or a security key, in addition to something you are or know, such as biometrics or a PIN. Microsoft supports passwordless authentications with Windows Hello for Business, the Microsoft Authenticator app, or a FIDO2 security key.


FIDO is an alliance that works toward improving today's authentication challenges with passwords. They are looking to provide simpler and secure authentication methods using open standards. You can view additional information about this at

To enable passwordless in Azure, follow these steps:

  1. Log in to
  2. Click on the portal menu at the top left and choose Azure Active Directory.
  3. Click on Security, then choose Authentication methods.
  4. Click on Authentication methods - Authentication method policy. Here, you can configure FIDO2 or the Microsoft Authenticator app for passwordless sign-in.

The following screenshot shows the configuration screen for passwordless:

Figure 7.19 – Enabling passwordless in Azure portal

As you can see from the screenshot, passwordless is in preview at the time of writing, and is not generally available with full support.

The final section we will cover in this chapter is Conditional Access and Identity Protection, leveraging the power of the cloud for much more advanced identity technology.

Using Conditional Access and Identity Protection

Conditional Access is an Azure cloud policy tool that enforces compliance based on conditions for your users. The Conditional Access policies allow you to specify criteria against your users that will trigger specific requirements or exceptions based on the location, device platform or type, application, group membership, and much more. For example, if a user is not on a trusted device and is trying to access their email via Exchange Online, they will be required to use MFA. This is a simple example, but the possibilities of this scenario are extensive and allow increased security. Conditional Access is a necessity within the cloud world, and you need to use it. If not, prioritize and enable it immediately.

You can learn more about Conditional Access at

The following is a list of several use cases to get you started today with Conditional Access:

  • Require MFA for your admins (privileged roles).
  • Require compliant mobile devices before allowing access to company resources.
  • Enable MFA for all guest users.
  • Block all legacy authentication protocols.
  • Allow users on trusted company devices to access resources without MFA.
  • Block any access outside a specific region—for example, a United States-based company could block any connection from everywhere outside the United States.
  • Enforce MFA on any app that contains PII, whether on a trusted device or not.
  • Only allow specific applications to be accessed from trusted devices.

To set up a Conditional Access policy, follow these steps:

  1. Log in to
  2. Click on the portal menu at the top left and choose Azure Active Directory. Click on Security, then Conditional Access, then click on New Policy.


    By default, Microsoft enables security defaults, which are a set of standard security features that Microsoft enforces. To set up your own Conditional Access policies, you will need to disable this by going to the portal menu at the top left. Click on Azure Active Directory | Properties | Manage Security Defaults . Change this setting to No, then click Save.

    The following screenshot shows where you will need to set up your new Conditional Access policy:

    Figure 7.20 – New Conditional Access policy

    Within the new policy, configure your assignments and the following configurations:

    Users and groups is where you can include and/or exclude users and groups.

    Cloud apps or actions is where you can include or exclude apps as part of the policy, as well as any user-specific actions.

    Conditions is where you configure specific conditions for the policy. These include Sign-in risk, Device platforms, Locations (using IP ranges or countries/regions), Client apps, and Device state.

  3. Next, you will configure your access controls:

    Grant is where you can grant or block access. If you grant access, you can select multiple requirements to comply with—for example, requiring MFA and devices to be marked as compliant.

    Session applies session limits to cloud apps.

  4. Finally, select Report-only to review the policy or select On to enable, then click on Done to complete the policy setup.


    Ensure you thoroughly test the Conditional Access policy before enabling it for the organization. There are scenarios where you could lock yourself out or cause major disruption to your users if you don't test and validate.

To add an additional layer of security, you could also add a location condition to block anyone from accessing the organization outside of a specific country. To do this, you can build locations within the Named locations option within the Conditional Access policy and add a new location based on IP ranges or country/region.


MFA does not work with legacy protocols, so it is highly recommended and important that you block legacy authentication to prevent a breach with any apps still using any legacy protocol. Some examples include POP, IMAP, and SMTP. The following guide provides the steps to block authentication:

Azure Identity Protection, like Conditional Access, is an Azure cloud-based security tool. With the advancement of the cloud and its collective customers, Microsoft currently analyzes 6.5 trillion signals per day to help better protect its customers and support services like Identity Protection. Identity Protection provides security for your users with any identity-based risks. Detection and remediation of these risks can be automated for quick protection. There are two types of identity-based risks used. User risks try to determine whether an account has been compromised and sign-in risks try to determine whether the authentication request is from the real owner. Risk is identified by atypical travel, anonymous IP addresses, unfamiliar sign-in properties, malware-linked IP address, leaked credentials, and Azure AD threat intelligence.


To learn more about the risks, visit

To access Identity Protection and enable the policies, go to the portal menu at the top left. Click on Azure Active Directory, choose Security, and click on Identity Protection to access the Identity Protection features. Within this management console, you can enable User risk policy, Sign-in risk policy, and MFA registration policy (required to protect against sign-in risks unless you block access). To enable the user risk policy, select User risk policy from the left and configure each of the following options:

  • Users: Decides who will be included or excluded from the policy
  • Conditions: Where you select the user risk level (Low and above, Medium and above, or High)
  • Access: To block or allow access and require password change if allowed
  • Estimated impact: To provide an overview of the percentage that the user's policy will apply to

Once configured, change the policy to On and click Save. The following screenshot shows the User risk policy configuration screen:

Figure 7.21 – Enabling the user risk policy

Complete the preceding steps again for the sign-in risk policy and ensure you enable the MFA registration policy as well.


The recommendation from Microsoft is to set the user risk policy to high and the sign-in risk policy to medium and above.


In this chapter, we extensively covered identity and access management and its importance to ensure you provide the best protection for your users and Windows devices. We started with an overview, covering the foundation of IAAA and what each component of it is. We then reviewed account and access management, which covered the life cycle of identity management, as well as external access and privileged access.

Next, we covered authentication methods, including password management, SSPR, and different SSO methods. The remainder of this section included a review of MFA and Windows Hello and an overview of the future of a passwordless world. We finished this chapter by covering some new advanced cloud authentication tools, known as Conditional Access and Identity Protection.

In the next chapter, we will be looking at the administration and remote management of your Windows environment. In this chapter, we will review device administration, modern device management, security baseline enforcement, and remote management.