Authentication options in Azure - Azure Tutorial

- [Instructor] Hello and welcome to this lesson on Authentication and Authorization Mechanisms in Azure. A significant and essential role of any platform is authentication and authorization, and the two terms are often quite confused with each other or combined into a single entity. So when understanding security on platforms such as Azure, its vital to know the difference between the different technologies used. Authentication is the act of proving who you are, and often this is performed using a username and password combination. If you can provide the correct details, a system authenticates you. Authentication, however, does not give you access to anything. It merely proves who you are. Once system knows who you are, then it can check what you have access to, and this is what's known as 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, and modifying, or even reading the data within that storage account. Azure provides a range of services, however, it essentially starts with a user database. And in the world of Microsoft, this is active directory domain services, or when dealing with Azure, Azure Active Directory. We differentiate the two because although they do the same thing, they are implemented differently. Both options are just a database of users with details and, of course, credential information. Traditionally, this is in the form of passwords. However, this is starting to change in favor of things such as multi-factorial authentication, which we'll cover shortly. Using Azure Active Directory, we can also define what roles users have, group users, and then at the resource level, use all this to dictate what actions they can perform on a resource, be reading a file, or even creating a new service. So we've just mentioned that there's actually two versions of directory services. There's the traditional directory services known as Active Directory Services, and this normally runs on-premises on domain controllers. Then there's Azure Active Director. Azure Active Director, or Azure AD, takes our identity to the next level by building upon active directory and providing it as an identity as a service. Just like Active Directory Directory Services, Azure Active Directory is a database of users that can be used to grant access to your systems, but it's important to understand that it's an entirely separate database and one that's stored with an Azure, and therefore the underlying hardware and software that powers it is wholly managed by Azure. As Azure AD is a managed service, Microsoft ensures the integrity, security, and resilience of that platform for you. Whereas Active Directory Domain Services secures domain join devices such as service, Azure Active directory secures cloud-based systems such as web apps. It's also important to understand the different communication protocols used. With Azure Active Directory Services, users are often authenticated over HTTPS, whereas Active Directory Domain Services uses the NTLM protocol, and it's generally over an internal network. Now, let's look at something called Azure Tenants, as they define the boundary for Azure AD, not that Azure AD not on-premises Active Directory Domain Services. An Azure AD tenant is an instance of Azure Active Directory. Think of a tenant as the user database. Each tenant has its own set of users. Therefore, if you have more than one tenant, you have two distinct separate user databases. A tenant therefore defines your administrative boundaries, and Azure subscriptions can only belong to one single tenant. However, a single tenant can contain multiple Azure subscriptions. We'll come into subscriptions a bit more later on. Although a single tenant can have multiple Azure subscriptions, there's a number of reasons why we might want to have multiple tenants. And a couple of those examples might be, for example, you might want a dev and test tenant. So for example, you might want a separate tenant for evaluating and testing the effects of policies and rules that we have on users. You might also want a separate software as a service tenant. So if we think of products such as Microsoft Dynamics CRM, this is built as a single saleable system and it's managed by Microsoft. However, it's multi-tenant, in that it's made up of external users, not Microsoft employees. Therefore, it's got to be managed separately to the Microsoft internal active directory. Therefore, having this separate tenant allows you to have a clean definition between your own internal user accounts and your external customer user accounts. At this stage, it's also worth understanding that Azure AD actually uses different pricing tiers. So out the box, Azure provides a free tier known as Active Directory Free. The free tier provides user and group management, on-premises synchronization, basic reporting, self-service password change facilitator for cloud users. In other words, it gives you all the absolute basics that you need to provide cloud-based access. For more advanced scenarios, you can purchase Active Directory Premium P1 licenses. Over and above the free tier, P1 lets hybrid users, that's users who have an account in Azure AD and on your on-premise network, and that lets those hybrid users synchronize accounts between on-premise and cloud and access both cloud and on-premises resources seamlessly. It also provides a more advanced administration tooling and reporting such as Microsoft Identity Manager and also enables a feature called cloud write backs to password changes. Further up the chain, we then have Active Directory Premium P2, and this gives everything that we're getting best from P1, but it adds on Active Directory Identity Protection and Privileged Identity Management. We'll cover these more in detail later, but for now you do need to understand the differences, what the different licenses give you because it is a common exam questions. So we've discussed that there are two versions of AD, a cloud-native option and a on-premises option. For many organizations, they'll want to use the two together, and therefore they'll want to synchronize the accounts between them. And we do this using a product called Azure AD Connect. AD Connect is a synchronization tool that you install on an on-premise server, and essentially copies objects between your on-premise network and your Azure AD. This scenario is excellent providing access to Azure resources for existing on-premise users, and self-service capabilities such as password resets. Although this does require the Azure AD Premium License ad-on. When using Azure AD Connect, you can synchronize between your on-premises directories and Azure in a few different ways. The simplest is just a direct copy of an entire forest into a single tenant, and this is by far the easiest and most common option. However, some organizations have multiple forests. And this can often result in an organization when an organization acquires other companies or maybe if they've built up because they're a big company and built their own forest as they've grown. Alternatively, some global companies have separate forests for different geographies. Regardless of the reason, when setting up your hybrid connect services in Azure, you can choose whether to combine all those forests into a single tenant. Finally, a company with a single forest might want to do the opposite and they might want to split that forest among different Azure tenants. So for example, an organization may wish to have a separate tenant for each regional location, but their current forest currently amalgamate all those users together. Azure AD Connect provides ways of filtering that allows you to therefore separate what you have on-premises between what You have on the cloud. There'll be many occasions when you need set up secure authentication and authorization systems. For example, when a web app needs to communicate with the database or other services, traditionally, this will be performed using a service account, a special account that doesn't allow you to log onto a server or workstation but can be used to authenticate systems by assigning that user access to a consuming service. The problem then is how do we manage the passwords on if these accounts are secure, and more importantly, how do we use them when building applications? Azure have a number of different options for this, and one of them is Managed Identities under the risk service principles. We can also use Key Vaults that can be used to store sensitive information such as passwords and connection strings between them. And we're going to look at these next.