It is important to grasp the difference between Active Directory (AD) and Azure Active Directory (AAD) and how these two technologies work together to secure and authenticate an organisation. This blog post will note the differences between AD and AAD, benefits, methods of utilisation, and management of AD and AAD.
Before diving into Active Directory (AD), let us dive into the fundamentals of a domain controller to understand what AD is. A server on the network known as a domain controller centrally controls access to people, PCs, and servers. This is accomplished by Microsoft's Active Directory (AD) service, which is used to arrange and manage users, computers, and other resources on a network. It is a database that is used to centrally manage user access to network resources like applications, file services, printers, and other resources.
Users and machines at your company are organised in a database called Active Directory. It offers programmes, file services, printers, and other network resources authentication and authorisation. It authenticates users using protocols like Kerberos and NTLM and queries and modifies Active Directory database objects using Lightweight Directory Access Protocol (LDAP).
The roles of Active Directory (AD) are varied but some of the more important roles are:
Essentially, AD keeps track of all of your users, PCs, and servers and verifies their identities when they login in (the network logon). Once logged in, AD also controls what users are permitted to do and access (authorization). As an illustration, it is aware that John Smith belongs to the Sales Group and is therefore prohibited from accessing the HR folder on the file server. Additionally, it enables management and control of PCs and servers on the network using Group Policy (thus, for instance, you could set every user's browser's home page to be your intranet or you might forbid users from installing other applications).
The majority of well-established firms will have one or more Domain Controllers on their network that are running AD.
Azure Active Directory (AAD) is not simply a cloud version of Active Directory (AD), as the name might suggest. Although it performs some of the same functions, it is quite different.
The Azure Active Directory (AAD) is a secure online authentication store that can contain users and groups. Users have a username and a password, which are used when they sign into an application that uses Azure AD for authentication. So, for example, all of the Microsoft Cloud services use Azure AD for authentication: Office 365, Dynamics 365, and Azure. Under the hood, if you have Office 365, you are already using Azure AD.
As well as managing users and groups, Azure AD manages access to applications that work with modern authentication mechanisms like SAML and OAuth. Applications are an object in Azure AD that allows you to create an identity for your applications (or third-party applications) to which you can grant access to users. Besides seamlessly connecting to any Microsoft Online services, Azure AD can connect to thousands of SaaS applications (e.g., Salesforce, Slack, Zendesk and more) using a single sign-on.
When compared with AD, here is what Azure AD does not do:
Note: Azure Active Directory (AAD) does not replace AD.
AD is great at managing traditional on-premises infrastructure and applications. Azure AD is great at managing user access to cloud applications. Both AAD and AD serve different purposes, with the area of overlap being user management.
You can utilise both if you have an existing traditional on-premise AD setup and wish to use Azure AD to control access to cloud applications (like Office 365 or any of the thousands of SaaS apps available).
If you use Office 365, your users will have both a username and password for network logon plus a username and password for that service (controlled by Azure AD and managed by AD). These two certifications are unrelated to one another. This is good, but it means that if you have a policy requiring users to change their passwords twice (and they may, of course, use the same password for both).
Alternately, you can synchronise AD with Azure AD so that users only need one piece of login information for access to O365 and network logon. To accomplish this, you could use Azure AD Connect, a little piece of free Microsoft software that you install on a server to carry out the synchronisation.
You can run your firm solely using Azure AD if you're a new company or one that wants to move away from traditional on-premise infrastructure to cloud-based applications.
In this scenario, even though all of your applications will be in the cloud, your staff will still use physical devices, such as PCs and smartphones, to access and collaborate.
In the case of PCs (this applies to Windows 10 only), you can join Azure AD and login to machines using Azure AD user accounts. You can apply conditional access policies that require machines to be joined to Azure AD before accessing company resources or applications. However, Azure AD Join provides limited functionality compared to AD Join (as there is no Group Policy), and in order to gain fine-grained control over the PCs, you would then use a Mobile Device Management solution, such as Microsoft Intune, in addition to this.
Other devices (Windows 10, iOS, Android, and MacOS) can be Azure AD registered (which means you sign into the device itself without requiring an Azure AD account, but can then access apps, etc. using the Azure AD account) and controlled using Microsoft Intune.
If you can't get all of your applications as SaaS apps and still need some to run on your own servers, you can migrate them to Azure virtual machines (VMs). If those VMs need to be domain joined, then you can either deploy a domain controller on another VM in Azure, or you can use Azure Active Directory Domain Services (Azure AD DS), which is a PaaS service (you don’t have to manage it) for domain joining Azure VMs. Azure AD DS automatically synchronises with Azure AD to ensure that all of your users have the application access you require.