Category: Password Writeback (Page 1 of 2)

Security Defaults – Understanding User Authentication-1

2024-08-25 / Grace Oducado / 0 Comments

Microsoft provides aset of tools called CA—however, these require configuration and ongoing management, plus you must upgrade to the Azure AD Premium P1 tier to use it.

For some organizations, this may either involve too much effort (perhaps you are a small team) or possibly cost too much.

Because security is so important, Microsoft offers Security Defaults—these are a set of built-in policies than protect your organization against common threats. Essentially, enabling this feature preconfigures your AD tenant with the following:

Requires all users to register and use MFA
Requires administrators to perform MFA
Blocks legacy authentication protocols
Protects privileged activities such as accessing the Azure portal

An important note to consider is that Security Defaults is completely free and does NOT require a premium AD license.

It’s also important to understand that because this is a free tier, it’s an all-or-nothing package. It’s also worth noting that the MFA mechanism only works using security codes through a mobile app authenticator (such as Microsoft Authenticator) or a hardware token. In other words, you cannot use the text message or calling features.

Security Defaults is enabled by default on new subscriptions, and therefore you don’t need to do anything. However, for organizations that require more control, you should consider CA.

Understanding and setting up CA

For organizations that want more control over security or that already have an Azure AD Premium P1 or P2 license, CA can provide a much more granular control over security, with better reporting capabilities.

Azure uses several security-based services that can be applied depending on various attributes, known as signals, which are then used to make decisions around which security policies need to be applied.

This process and set of tools are called CA, and this can be accessed in the Azure portal via the AD Security blade.

Tip

For the exam, Azure CA requires an Azure AD Premium P1 license.

Standard signals you can use when making decisions include the following:

User or group membership: For example, if users are in a group that will give them access to particularly sensitive systems or high levels of access—that is, an admin group.
IP location: For example, when users are signing in from a controlled IP range such as a corporate network, or if users are signing in from a particular geography that has specific local requirements.
Device-specific platforms, such as mobile devices, may need different security measures.
Application: Similar to groups, specific applications, regardless of role, may need additional protective measures—for example, a payroll application.
Real-time risk detection: Azure Identity Protection monitors user activity for “risky” behavior. If triggered, this can force particular policies to be activated, such as a forced password reset.
Microsoft Cloud App Security: Enables application sessions to be monitored, which again can trigger policies to be applied.
Terms of use: Before accessing your systems, you might need to get consent from users by requesting a terms-of-use policy to be signed. A specific Azure AD policy can be defined, requiring users to sign this before they can sign in.

Once a signal has been matched, various decisions can then be made regarding a user’s access. These include the following:

Block Access

–Block the user from proceeding entirely.

Grant Access, which is further broken down into the following:

–Require MFA

–Require device compliancy (via device policies)

–Require device to be Hybrid Azure AD-joined

–Requirement an approved client app

–Requirement of an app protection policy—that is, a review

Understanding conditional access, MFA and security defaults – Understanding User Authentication

2024-06-30 / Grace Oducado / 0 Comments

In today’s environments that often expand beyond an organization’s network into the cloud, controlling access while still enabling users to access their resources becomes more complicated.

An additional complication is the fact that different users may have other requirements. For example, a system’s administrators most definitely need the most secure access policies in place. In contrast, an account that will always have more limited access anyway may not need quite as stringent measures because they won’t be accessing (or be granted access to) particularly risky systems should they be compromised.

Another example is where a user is signing in from—if a user is on the corporate network, you already have physical boundaries in place; therefore, you don’t need to be as concerned as a user accessing from a public network.

You could argue that you should always take the most secure baseline; however, the more security measures you introduce, the more complex a user’s sign-on becomes, which in turn can impact a business.

It is, therefore, imperative that you get the right mix of security for who the user is, what their role is, the sensitivity of what they are accessing, and from where they are signing in.

MFA

Traditional usernames and passwords can be (relatively) easily compromised. Many solutions have been used to counteract this risk, such as requiring long and complex passwords, forcing periodic changes, and so on.

Another, more secure way is to provide an additional piece of information—generally, one that is randomly generated and delivered to you via a pre-approved device such as a mobile phone. This is known as MFA.

Usually, this additional token is provided to the approved device via a phone call, text message, or mobile app, often called an authentication app.

When setting up MFA, a user must register the mobile device with the provider. Initially, a text message will be sent to verify that the user registering the device owns it.

From that point on, authentication tokens can only be received by that device. We can see the process in action in the following diagram:

Figure 3.13 – MFA

Microsoft Azure provides MFA for free; however, the paid tiers of Azure AD offer more granular control.

On the Azure AD free tier, you can use a feature called Security Defaults to enable MFA for ALL users, or at the very least on all Azure Global Administrators when Security Defaults isn’t enabled. However, the free tier for non-global administrators only supports a mobile authenticator app for providing the token.

With an Azure AD Premium P1 license, you can have more granular control over MFA through the use of CA, which allows you only to use MFA based on specific scenarios—for example, when accessing publicly over the internet, but not from a trusted location such as a corporate network.

Azure AD Premium P2 extends MFA support by introducing risk-based conditional access. We will explore these concepts shortly, but first we will delve into what is available with Security Defaults.

Federated authentication – Understanding User Authentication

2024-05-09 / Grace Oducado / 0 Comments

Federated authentication uses an entirely separate authentication system such as Active Directory Federation Services (AD FS). AD FS has been available for some time to enable enterprises to provide SSO capabilities for users by extending access management to the internet.

Therefore, some organizations may already make use of this, and it would therefore make sense to leverage it.

AD FS provides additional advanced authentication services, such as smartcard-based authentication and/or third-party MFA.

Generally speaking, it is recommended to use PHS or PTA. You should only consider federated authentication if you already have a specific requirement to use it, such as the need to use smartcard-based authentication.

Azure AD Connect Health

Before we leave authentication and, specifically, AD Connect, we must look at one last aspect of the service: AD Connect Health.

Azure AD Connect Health provides different types of health monitoring, as follows:

AD Connect Health for Sync, which monitors the health of your AD DS to Azure AD.
AD Connect Health for AD DS, which monitors your domain controllers and AD.
AD Connect Health for AD FS, which monitors AD FS servers.

There are three separate agents, one for each scenario; as with the main AD Connect agent, the download link for the AD Connect Health agent can be accessed in the Azure portal, as follows:

Navigate to the Azure portal at https://portal.azure.com.
In the top bar, search for and select Active Directory.
In the left-hand menu, click AD Connect.
On the main page, click Azure AD Connect Health under Health and Analytics.
You will see the links to the AD Connect Health agents under Get tools, as in the following example:

Figure 3.12 – Downloading the AD Connect Health agents

The AD Connect Health blade also gives you a view on any alerts, performance statistics, usage analytics, and other information related to the AD.

Some of the benefits include the following:

Reports on these issues:

–Extranet lockouts

–Failed sign-ins

–Privacy compliance

Alerts on the following:

–Server configuration and availability

–Performance

–Connectivity

Finally, you need to know that to use AD Connect Health, the following must apply:

You must install an agent on your infrastructure on any identity servers you wish to monitor.
You must have an Azure AD P1 license.
You must be a global administrator to install and configure the agent.
You must have connectivity from your services to Azure AD Connect Health service endpoints (these endpoints can be found on the Microsoft website).

As we can see, Azure provides a range of options to manage authentication, ensure user details are synchronized between and cloud, and enable easier sign-on. We also looked at how we can monitor and ensure the health of the different services we use for integration.

In the next section, we will look at ways, other than just with passwords, we can control and manage user authentication.

Password Writeback – Understanding User Authentication

2024-04-20 / Grace Oducado / 0 Comments

As we have already mentioned, one of the benefits Azure AD provides is self-service password resets—that is, the ability for users to reset their passwords by completing an online process. This process results in the user’s credentials being reset in the cloud—however, if you have hybrid scenarios with those same accounts, you would typically want to have a password reset performed in the cloud to write that change back to the directory.

To achieve this, we use an optional feature in AD Connect called Password Writeback.

Password Writeback is supported in all three hybrid scenarios—PHS, PTA, and AD Federation.

Using Password Writeback enables enforcement of password policies and zero-delay feedback—that is, if there is an issue resetting the password in the AD, the user is informed straightaway rather than waiting for a sync process. It doesn’t require any additional firewall rules over and above those needed for AD Connect (which works over port 443).

Note, however, that this is an optional feature, and to use it, the account that AD Connect uses to integrate with your AD must be set with specific access rights—these are the following:

Reset password
Write permissions on lockoutTime
Write permissions on pwdLastSet

AD Connect ensures that the user login experience is consistent between cloud and hybrid systems. However, AD Connect has an additional option—the ability to enable a user already authenticated to the cloud without the need to sign in again. This is known as Seamless SSO.

Seamless SSO

Either PHS or PTA can be combined with an option called Seamless SSO. With Seamless SSO, users who are already authenticated to the corporate network will be automatically signed in to Azure AD when challenged.

As we can see in the example in the following diagram, if you have a cloud-based application that uses Azure AD for authentication and you have Seamless SSO enabled, users won’t be prompted again for a username and password if they have already signed in to an AD:

Figure 3.11 – SSO

However, it’s important to note that Seamless SSO is for the user’s device that is domain-joined—that is, domain-joined to a network. Devices that are joined to Azure AD or Hybrid Azure AD-joined use primary refresh tokens also to enable SSO, which is a slightly different method of achieving the same SSO experience but using JSON web tokens (JWT).

In other words, Seamless SSO is a feature of hybrid scenarios where you are using AD Connect. SSO is a single sign-on for pure cloud-managed devices.

Azure AD versus AD DS – Understanding User Authentication

2023-10-05 / Grace Oducado / 0 Comments

Azure AD is the next evolution. It takes identity to the next level by building upon AD DS and provides an Identity as a Service (IDaaS) to provide this same level of security and access management to the cloud.

Just as with AD DS, Azure AD is a database of users that can be used to grant access to all your systems. It’s important to understand that it is an entirely separate database— one that is stored within Azure—and therefore the underlying hardware and software that powers it is wholly managed by Azure—hence IDaaS.

In a traditional on-premises world, you would be responsible for building directory servers to host and manage AD DS. As an IT administrator or architect, you need to consider how many servers you require and what specifications they need to be to support your user load and resilience, to ensure the system is always available. If your identity system failed due to hardware failure, access to all your systems would be blocked.

Azure AD is a managed service, and Microsoft ensures the integrity, security, and resilience of the platform for you.

Whereas AD DS secures domain-joined devices, Azure AD secures cloud-based systems such as web apps. With Azure Web Apps, for example, they are not domain-joined to an internal network. Users may authenticate over the internet—that is, over public networks, as opposed to internal networks. As such, the protocols used must also be different—NTLM and Kerberos used in AD DS would not be suitable and, instead, traditional web protocols must be used—that is, HyperText Transfer Protocol Secure (HTTPS), as depicted in the following diagram:

Figure 3.4 – Azure AD versus AD DS protocols

Azure AD also integrates with other Microsoft online services such as Office 365. If you sign up for Microsoft Office 365, an Azure AD tenant will be created for you to manage your users. This same “tenant” can also be used to manage your Azure subscriptions and the apps you build within them.

Azure AD is distinctly separate from AD DS—that is, they are entirely different databases. However, you can link or synchronize Azure AD and your on-premises AD DS, effectively extending your internal directory into the cloud. We will cover this in more detail later, but for now, understand that although different, AD DS and cloud-based Azure AD can be connected.

Important note

Azure AD, even with synchronization, does not support domain-joining virtual machines (VMs). For domain-joined VMs in Azure, either allow AD DS traffic back to on-premises, build domain controllers within the Azure network or use Azure AD DS, which is a fully managed AD DS solution.

The following table shows some of the common differences between the two services:

An instance of Azure AD is called an Azure tenant. Think of a tenant as the user database. In the next section, we will look at tenants in more detail.

Why AD? – Understanding User Authentication

2023-09-30 / Grace Oducado / 0 Comments

Let’s take a step back and consider a straightforward scenario: that of an online e-commerce website. Before you can order something, you need to register with that website and provide some basic details—a sign-in name, an email, a password, and so on.

A typical website such as the one shown in the following diagram may simply store your details in a database and, at its simplest, this may just be a user record in a table:

Figure 3.1 – Simple username and password authentication

For more advanced scenarios that may require different users to have different levels of access—for example, in the preceding e-commerce website—the user databases may need to accommodate administrative users as well as customers. Administrative users will want to log in and process orders and, of course, we need to ensure the end customers don’t get this level of access.

So, now, we must also record who has access to what, and ensure users are granted access accordingly, as in the example shown in the following diagram:

Figure 3.2 – Role-based authorization

The same would also be valid for a corporate user database. For example, the company you work for must provide access to various internal systems—payroll, marketing, sales, file shares, email, and so on. Each application will have its own set of security requirements, and users may need access across multiple systems.

For corporate users, Microsoft introduced Active Directory Domain Services (AD DS), which is a dedicated identity management system that allows businesses to manage user databases in a secure and well-organized way. Users in an AD are granted access to other systems (provided they support it) from a single user database. Microsoft AD DS takes care of the complexity and security of user management. See the example shown in the following diagram:

Figure 3.3 – AD

From a single account, IT administrators can provide access to file shares, email systems, and even web applications—provided those systems are integrated with AD. Typically, this would be achieved by domain-joining the device that hosts the application—be it an email server, web server, or file server; that is, the hosting device becomes part of the network, and AD manages not only the user accounts but the computer accounts as well.

In this way, the identity mechanism is a closed system—that is, only internal computers and users have access. Although external access mechanisms have been developed over time to provide remote access, these are still about securely connecting users by essentially extending that “internal” network.

Microsoft AD DS uses specific networking protocols to manage the security of devices and users—that is, the way devices communicate with each other—known as Integrated Windows Authentication (IWA); they are New Technology LAN Manager (NTLM) and Kerberos.

Microsoft AD DS is a common standard today for many organizations. Still, as discussed, it is built around the concept of a closed system—that is, the components are all tightly integrated by enforcing the requirement for them to be “joined.”

Introducing Azure AD – Understanding User Authentication

2023-07-11 / Grace Oducado / 0 Comments

Azure AD is a cloud-based mechanism that provides the tools to address our security needs. Backed by Microsoft AD, an industry-standard and, importantly, proven secure authentication andauthorization system, it gives both cloud-first (that is, stored and managed entirely in the cloud) and hybrid (a mix of cloud and on-premises) solutions.

Some of these tools are included by default when you create an Azure AD tenant. Others require a Premium add-on, which we will cover later.

These tools include the following:

Self-service password resets: Allowing your users to reset their passwords themselves (through the provision of additional security measures) without needing to call the helpdesk.
MFA: MFA enforces a second form of identification during the authentication process—a code is generated and sent to the user, and this is entered along with the password. The code is typically sent to a user’s device as either a text message or an MFA authentication app on their mobile device.
You can also use biometric devices such as fingerprint or face scanners.
Hybrid integration with password writebacks: When Azure AD is synchronized to an on-premises AD with AD Connect, changes to the user’s password in Azure AD is sent back to the on-premises AD to ensure the directories remain in sync.
Password protection policies: Policies in Azure can be set to enforce complex passwords or the period between password changes. These policies can be integrated with on-premises directories to ensure consistency.
Passwordless authentication: For many organizations, the desire to remove the need for passwords altogether in favor of alternative methods is seen as the ultimate solution to many authentication issues. Credentials are provided through the use of biometrics or a FIDO2 security key. These cannot be easily duplicated, and this removes the need for remembering complex passwords.
Single sign-on (SSO): With SSO, users only need to authenticate once to access all their applications—regardless of whether they sign on through their on-premises directory or Azure AD, the single authentication process should identify the user across different environments.
CA: To further tighten security, CA policies can provide further restrictions to user sign-in, or when different rules may apply. For example, MFA can be set not to be required when signing in from specific Internet Protocol (IP) ranges, such as a corporate network range.

Differentiating authentication from authorization – Understanding User Authentication

2023-06-24 / Grace Oducado / 0 Comments

User security is perhaps one of the most critical aspects of a system and, therefore, its architecture. Security has, of course, always been important to protect sensitive information within an organization. However, as we move our applications online and widen our audience, the need to ensure only the correct people gain access to their data has become crucial.

In this chapter, we explore the key differences between authentication and authorization, what tooling we have available within Azure to ensure the safety of user accounts, and how we design solutions according to different business needs.

In this chapter, we will examine the following topics:

Differentiating authentication from authorization
Introducing Active Directory (AD)
Integrating AD
Understanding Conditional Access (CA), Multi-Factor Authentication (MFA), and security defaults
Using external identities

Differentiating authentication from authorization

A significant and essential role of any platform is that of authentication and authorization. These two terms are often confused and combined as a single entity. When understanding security on platforms such as Azure, it’s vital to know how the different technologies are used.

Authentication is the act of proving who you are, often performed with a username/password combination. If you can provide the correct details, a system authenticates you.

Authentication does not give you access to anything; it merely proves who you are.

Once a system knows the who, it then checks to see what you have access to—this is termed authorization.

In Azure, authorization is the act of checking whether you have access to a particular resource such as a storage account, and what actions you can perform, such as creating, deleting, modifying, or even reading the data in the storage account.

Because of the number of different services and their associated actions that are available to a user in Azure, and the importance of ensuring the validity of a user, the ensuing mechanisms that control all this can become quite complicated.

Luckily, Azure provides a range of services, broken down into authentication and authorization services, that enable you to strictly control how users authenticate and what they can then access, in a very granular way.

Traditionally, authentication has been via simple username/password combinations; however, this is ineffective on its own, and therefore you need to consider many factors and strategies when designing an authentication mechanism. For example, the following scenarios may apply:

A user may choose too simple a password, increasing the chances of it being compromised.
Complex passwords or regular changes mean users are more likely to forget their password.
There may be delays in the authentication process if a user needs to call a helpdesk to request a password reset.
A username/password combination itself is open to phishing attacks.
Password databases can be compromised.

Important note

A phishing attack is an action whereby a malicious person will attempt to steal your password by sending you to a dummy website that looks like the one you want to access but is, in fact, their site. You enter your details, thinking it is the correct site, and now they have your personal information and can then use this to log in to the real site.

When systems are hosted on a physically isolated network, some of these issues are mitigated as you first need physical access to a building or at least a device set up with a virtual private network (VPN) connection that, in turn, would require a certificate.

However, in cloud scenarios, and especially hybrid systems, whereby you need external authentication mechanisms that must also map or sync to internal systems, this physical firewall cannot always be achieved.

With these scenarios in mind, we need to consider how we might address the following:

Managing and enforcing password complexity rules
Providing additional layers over and above a password
How to securely store and protect passwords

Now that we understand some of the issues we face with authentication systems, especially those that rely on username/password combinations, we can investigate what options are available to mitigate them. First, we will examine Microsoft’s established security platform, AD.

Network monitoring – Principles of Modern Architecture

2023-04-06 / Grace Oducado / 0 Comments

CPU and RAM utilization are not the only source of problems; problems can also arise from misconfigured firewalls and routing, or misbehaving services causing too much traffic.

Traffic analytics tools will provide an overview of the networks in the solution and help identify sources that generate high traffic levels. Network performance managers offer tools that allow you to create specific tests between two endpoints to investigate particular issues.

For hybrid environments, VPN meters specifically monitor your direct connection links to your on-premises networks.

Monitoring for DevOps and applications

For solutions with well-integrated DevOps code libraries and deployment pipelines, additional metrics and alerts will notify you of failed builds and deployments. Information, support tickets, or work tasks can be automatically raised and linked to the affected build.

Additional application-specific monitoring tools allow for an in-depth analysis of your application’s overall health, and again will help with troubleshooting problems.

Application maps, artificial intelligence (AI)-driven smart detection, usage analytics, and component communications can all be included in your designs to help drive operational efficiencies and warn of future problems.

We can see that for every aspect of your solution design—security, resilience, performance, and deployments—an effective monitoring and alerting regime is vital to ensure the platform’s ongoing health. With proper forethought, issues can be prevented before they happen. Forecasting and planning can be based on intelligent extrapolation rather than guesswork, and responding to failure events becomes a science instead of an art.

Summary

In this chapter, we looked at a high-level view of the architecture and the types of decisions that must be considered, agreed upon, and documented.

By thinking about how we might design for security, resilience, performance, and deployment and monitor all our systems, we get a greater understanding of our solution as a whole.

The last point is important—although a system design must contain the individual components, they must all work together as a single, seamless solution.

In the next chapter, we will look at the different tools and patterns we can use in Azure to build great applications that align with best-practice principles.

Architecting for performance – Principles of Modern Architecture

2022-11-06 / Grace Oducado / 0 Comments

As we have already seen, resilience can be closely linked to performance. If a system is overloaded, it will either impact the user experience or, in the worst case, fail altogether.

Ensuring a performant solution is more than just increasing resources; how our system is built can directly impact the options available and how efficient they are.

Breaking applications down into smaller discrete components not only makes our solution more manageable but also allows us to increase resources just where they are needed. If we wish to scale in a monolithic, single-server environment, our only option is to add more random-access memory (RAM) and CPU to the entire system. As we decompose ourapplications and head toward a microservices pattern whereby individual services are hosted independently, we can apportion additional resources where needed, thus increasing performance efficiently.

When we need to scale components, we have two options: the first is to scale up—add more CPU and RAM; the second option is to scale out—deploy additional instances of our services behind a load balancer, as per the example in the following diagram:

Figure 2.3 – Scale-out: identical web servers behind a load balancer

Again, our choice of the underlying technology is important here—virtual servers can be scaled up or out relatively quickly, and with scale, sets can be dynamic. However, virtual servers are slower to scale since a new machine must be imaged, loaded, and added to the load balancer. With containers and PaaS options such as Azure Web Apps, this is much more lightweight and far easier to set up; containers are exceptionally efficient from a resource usage perspective.

We can also decide what triggers a scaling event; services can be set to scale in response to demand—as more requests come in, we can increase resources as required and remove them again when idle. Alternatively, we may wish to scale to a schedule—this helps control costs but requires us to already know the periods when we need more power.

An important design aspect to understand is that it is generally more efficient to scale out than up; however, to take advantage of such technologies, our applications need to avoid client affinity.

Client affinity is a scenario whereby the service processing a request is tied to the client; that is, it needs to remember state information for that client from one request to another. In a system built from multiple backend hosts, the actual host performing the work may change between requests.

Particular types of functions can often cause bottlenecks—for example, processing large volumes of data for a report, or actions that must contact external systems such as sending emails. Instead of building these tasks as synchronous activities, consider using queuing mechanisms instead. As in the example in the following diagram, requests by the User are placed in a Job Queue and control is released back to the User. A separate service processes the job that was placed in the Job Queue and updates the User once complete:

Figure 2.4 – Messaging/queueing architectures

Decoupling services in this fashion gives the perception of a more responsive system and reduces the number of resources to service the request. Scaling patterns can now be based on the number of items in a queue rather than an immediate load, which is more efficient.

By thinking about systems as individual components and how those components respond—either directly or indirectly—your solution can be built to not just scale, but to scale in the most efficient manner, thereby saving costs without sacrificing the user experience.

In this section, we have examined how the right architecture can impact our solution’s ability to scale and perform in response to demand. Next, we will look at how we ensure these design considerations are carried through into the deployment phase.