
Azure AD and Access Management
This is an introduction to Azure AD and Access Management.
Table of Contents
- Understanding Directory Structure
- Active Directory Domain Services
- Roles and Domain Controllers
- AD DS Forests
- Forest Models
- Introduction to Azure AD
- Adding Azure AD
- Azure AD Connect
- Password Hash Synchronization
- Pass-through Authentication
- Federation with Azure AD
- Azure AD Seamless Single Sign-On
- Privileged Access Management
Understanding Directory Structure
I will describe directory structures and the role they play in network and organizational environments. One of the foremost features of any organizational network has to be trust. Trust is the security principle that defines information and access safely. Trust is established in large part by a directory structure managed and maintained by network administrators and delivered to end users.
So they can access their information stores as what are called objects. In this graphic, you get a basic sense of what an Active Directory structure looks like. It is very much like a directory tree that you would see in a file hierarchy.
It might help to look at another kind of hierarchy, the kind we see in the form of an organizational chart.
In an organizational chart, the responsibility to superiors is defined as you move down the chart. So at the very top you will see the top-level executive, starting with the CEO. The CEO reports to the CTO and COO, and so on. Now this is a basic example, of course, and an actual organizational chart of a large organization would be much more complex. The CTO and COO have people reporting to them, VP's, managers, supervisors, and then employees underneath that tier. In another visual example, this is a simplified hierarchy of an Organization.
So organizations typically have business units, also referred to as departments or organizational units known as OU's. So, here we have Sales, marketing, Production, HR, Purchasing, Accounting, all falling under the main umbrella of the Organization. Each unit has their own structure organized by function and employee.
So these are somewhat emblematic of what a network directory would look like with objects appearing in order of precedence. Having a measure of control over those objects that reside underneath them. So similar to this is the notion that a network is domain joined. That is, everyone logs into a network and accesses network resources through a domain.
Something like company.com, where company is the actual name of the organization. So these units are domain joined, Ous like Sales, marketing, HR, and so on, all connect to a domain on an Active Directory, managed by an internal server or in the cloud. They also have access to the cloud.
To simplify that, this visual removes the specific unit names and just demonstrates how in an Active Directory structure, everything is an OU. Regardless of what it is labeled and what it contains.
Active Directory Domain Services
I will discuss Active directory Domain Services and the purpose of AD DS objects. In the Active directory Domain Services, shortened to AD DS, there is a directory structure that is stored as a hierarchy. This hierarchy represents a network broken into objects that contain information and control access.
Before we dig deeper into AD DS, it helps to understand why it is a good idea.
First, it provides a level of security, restricting access to network resources using permissions. Certain users have access to some objects, while not others. Others have access to other objects and so on. Everything is predicated on the idea that you control whether to allow a user to access certain network resources or block their access.
In AD DS, we have what is known as a schema, and that schema defines the structure and rules of the AD. So using a schema, administrators define how data is stored and accessed. The things are broken into objects, and those objects could be very small like individual users, for example. To very big entire OUs within an organization. Each object contains attributes. So, for example, if we are talking about a user object, that object could contain attributes like name, user name, email address, telephone, employee number, password, and so on.
Common examples of AD DS objects include user accounts, groups, shared resources, and computers.
Again, the schema is defined by the organization based on its size, its needs, and many other features that administrators feel need to be defined in the schema. Drilling down a bit for my example of object attributes. You could have user information credentials, access rights, contact information, and these are very basic.
You can decide whatever kinds of attributes you need to assign the objects based on what the objects represent, and how they need to be used and controlled.
Roles and Domain Controllers
Here I will discuss server roles and the purpose of domain controllers. Let us also discuss roles in Windows Server. If you are not familiar with Windows Server, it is a special edition of Windows that provides networking service to computers in a network. On an organizational scale, a very important thing to have because you need to apply precise control over network services to ensure a network is secure and running smoothly.
Windows Server uses what is called roles. Roles are a specific functionality that the Windows Server system can provide. Because there are so many different roles, and these are just some of the most common examples. You will often have dedicated Windows Server systems running specific roles, rather than having a single window Server system running everything, which is not only inefficient, it is simply not practical in some cases. So examples include DHCP and DNS servers.
Hyper-V is Microsoft's virtualization technology. Web Server, which is called IIS, short for Internet Information Services. Print and Document Services. File and Storage Services. Remote Access Services. Remote Desktop Services. Device Health Attestation.
A domain controller is a specific type of Windows Server running a specific role. A domain controller is a Windows Server system running the role called Ad DS.
When you get your login prompt at your workstation and there is some text there that says something like logging in as, and a slash followed by a company domain name like "soandso.com". Then there is a slash and your user name. That is a domain controller login.
When you enter your credentials, password, along with your username, the Windows Server running AD DS, that is the domain controller, is deciding whether you get to have access to the network and your assigned resources. Essentially, you are logging into your company network through that computer.
So a domain controller is ensuring that legitimate domain clients, regardless of where they are or what organizational unit they belong to, can gain access to the network. If you do not have valid credentials, then you do not get in.
AD DS Forests
I will discuss AD DS Forests, and their purpose in a network environment. The simple model of a domain controller is a single domain like "soandso.com". Every user in the organization would log into the network through that domain controller in what is called a domain-joint login.
That is the simplest model for a domain controller. However, large networks can be quite complex and large. That means that a single domain and a single domain controller just will not cut it. That is when we get in to talk about something called AD DS Forests. To demystify that term, remember we are talking about a hierarchical structure, which is more commonly referred to as a tree structure.
To use the tree metaphor a forest is a large group of trees. In a forest scenario, you would have the top-level container, the forest. To that is joined multiple domains as in this example. Each domain is a separate domain controller, and that contains more information about users, network resources, computers, various access policies, and so on. Now, looking at that a bit differently, what we have in an AD DS Forest is a parent-child relationship.
If you know anything about hierarchies, that is going to make sense. Simply, in computing, we use the parent child relationship to describe objects and subobjects, and an ownership relationship if you will.
So here the forest at the top is the parent, and the three domains below it are children of the parent object, again, the forest. Now we dig into the specific usage of a scenario like this by looking at this in domains. The top-level forest is a domain controller for "soandso.com". Under it, the child domains are "sales.soandso.com", "hr.soandso.com", and "info.soandso.com". You could begin to see how a forest could be deployed in a corporate network, subdividing domain controllers according to their assigned purpose.
The purpose has been devices by using Ous, organizational units. Every user in the sales department would have access to 'sales.soandso.com", and HR would have access to "hr.soandso.com", and so on.
Forest Models
In an AD DS Forest, there is a parent controller known as a Forest and then child domain controllers. You can have multiple AD DS Forests, and how you choose to set them up is based on what kind of relationship you need to establish between them. There are three different Forest models to choose from, organizational, resource based, and restricted access. Let us take a look at each.
In an organizational Forest, each Forest contains users and resources, and each Forest has autonomy over its own users and resources.
The purpose of this can vary, but generally if you want to cordon off different network services and data and keep that information contained to just the users and resources in each Forest, you can do that. However, you can have a trust relationship between Forests and it is a two way trust relationship. So if a user or group of Organization Forest A, on the left, needed access to a network resource in Organizational Forest B, on the right, that can be done by granting access to a user account or a group. In a Resource forest, one forest manages resources, that is the Resource Forest on the right.
It does not actually contain any user account information beyond what might be needed for basic administrative purposes. For example, admins who have access in that Resource Forest, so they can grant access to users in the Organizational Forest on the left. Users in the Organization Forest and any other Organizational Forest can access the resources in the Resource Forest in a one-way trust relationship. That is, the Resource forest recognizes a user or group as being authorized to access specific resources and that is all.
The idea here is to be able to provide availability of network resources, while keeping them safe and available if parts of a network go down. In a Restricted Access Forest, a Forest contains the user information and other data, and information needs to be kept private from the rest of the network.
This is a way of protecting information that absolutely cannot be allowed to be compromised. Notice that there is no trust relationship between the Organizational forest on the left and the Restricted Forest on the right.
This means that users who are granted access to the Restricted Forest not only need to have a different set of user credentials to access the information in that Forest, they in fact must have a completely different computer system. So it is, indeed, highly private and used in scenarios where information is extremely confidential and needs to be treated as such.
Introduction to Azure AD
I will discuss Azure AD and its various editions. Azure Active Directory is the cloud-based version of the Active directory role normally associated with Windows Server. It is highly versatile and can work in conjunction with your existing directory services. Like AD Ds, Azure Active Directory provides access control using directory services. It provides access to applications on a network level, and it provides identity management.
Azure Ad offers many useful features for network administrators including the ability to control users and their access to network resources through policies. The ability to collaborate securely in an organizational environment. To protect the identities from compromise and avoid threats. It also enables automation and enforces the policies and rules administrators create for access to a network.
There are four editions of Azure Ad, not including the Azure AD that comes with Office365. They are Free, Basic, Premium P1, and Premium P2.
Like other Microsoft 365 plans, which edition you choose will determine what levels of service you have access to. You should dig into the differences between the plans and pricing in order to understand which works best for you. Perhaps the single biggest difference between the Free edition and the others is that it limits you to 500,000 AD objects, while all the others have no limitation on the number of objects.
I mentioned the Azure AD that comes with Office 365, and there are a few differences between it and the premium plans. Generally, it follows the features of the Basic edition with a few exceptions. For example, the Office 365 edition includes multi-factor authentication through MFA Server, while the basic edition does not. Again, it will help to research differences with each plan to suit your needs. Keep in mind that Premium P1 and Premium P2 are more full-featured editions with premium features.
Adding Azure AD
Like Windows Server Active Directory, Azure Active Directory provides network directory service and access control. It is a cloud based version of the Active Directory role normally associated with Windows Server.
It is highly versatile and can work in conjunction with your in-house directory services and provides identity management and access to application. So, I am going to show you how to add the resource or access it in the Azure portal. Here we are at portal.azure.com. What I am going to do is click Create a resource on the left hand toolbar, the very top item with the Plus sign next to it.
Then in the Marketplace, we can search for Azure, and I will just start typing. There we go, Azure Active Directory is the first response, so I will click that.
Now, here we can choose to create an Azure Active Directory, I will click Create.
We can go through all the steps of creating that Active Directory. So, we start with the Organization name. So, for example, it could be "soandso.com", I will just make something up. I am not going to actually create the directory because I have already got something installed. The idea here is that you enter your Organization name. Then you have to add your domain name. So notice here under Initial domain name that we have ".onmicrosoft.com" after it.
So whatever we enter here is going to be preceded by ".onmicrosoft.com". So I could do "soandso" and that would be added to it. Now that would be the domain name that we used for our Azure Active Directory services. Then we choose our country or region. So this is really up to you, where you want to place this in terms of geography, and locale, and where you are going to be located. I will just leave it at the default, the US. Then I click Create and that Active Directory will be created for us.
Now, as I said, I don't really want to do that because I have already got something set up. So, if we look in the left hand toolbar, I go down to Favorites. Then, all the way down, almost to the very end, right there is Azure Active Directory.
Underneath, a Sign-in section displays a free trial link. Your role section displays on the right hand side displaying the host's role as Global administrator and a More info link. Below is a Find section containing a Users drop-down field and a Search field. Next, is an Azure AD Connect sync section showing the Status as Not enabled and the Last Sync as Sync was never on.
This will take us to the Azure Active Directory portion of the Azure portal, where all your management is done. So once you have created that directory, then you are going to be here. This is going to be the management portal for the Active Directory portion of your Azure activities with Microsoft 365.
Azure AD Connect
Azure Active Directory provides network directory services, and access control from the cloud with your Microsoft 365 and Azure accounts. It is a cloud based version of the Active Directory role normally associated with Windows Server. Now, in addition to being a highly versatile tool, it can work in conjunction with your in-house directory services and provide identity management and access to the applications.
The idea here is that you integrate your in-house Active directory with the Azure Active Directory or another directory service on your network if you are not using Microsoft Windows Server Active Directory. Here is how to connect to it. So we are in the portal for Azure, "portal.azure.com". Now what I want to do is look in the left hand column and halfway down or actually all the way down in this view, we are going to see Active Directory right there. I will click that. Now, that will take me to my Active Directory that I have already set up.
Now, we also have a new column here with all the options for Active directory. If I scroll down a bit, you are going to see right there, Azure AD Connect. I will click that.
Now, If I had already installed this, we will see something different that we have not seen before. So what we are seeing is a little info that we are going to use as your AD Connect to integrate with our Azure AD. With our Windows Server Active Directory or another directory on our network. We are not using Windows Server after that. If we are not using Windows Server AD, and we see Sync Status. Right now it is not installed, so we cannot actually see anything. Here is where we want to actually connect.
There is a link to download Azure AD Connect, I will click that.
Now, that takes me to a new tab with the big red Download button. This is Azure AD Connect and it is actually an installer. I will click download. I will choose from the options here, we are going to choose to run.
I do not want to do that and I will explain why in a second. I will just click Save for now. Now, a security scan will run on this. Once that is done, the download should start.
Ok once the download is finished, I am going to click Open Folder, see the folder where we actually downloaded this. There it is Azure AD Connect, it is a Windows installer application. Now, the reason that I did not run it is this simple reason. Azure AD Connect will check when you run it to make sure that you are actually installing the application on a Windows Server. Right now I am not running Windows Server. So it actually has to be run and installed on Windows Server, and that would be the next step in the process.
We will install this in Windows Server, and that Windows Server is also going to have the Active Directory role installed on it. So it has to work with the injunction of the Active Directory on Windows Servers, so we have to ensure that we have a directory installed on that server node when you install Azure Active Directory Connect.
Password Hash Synchronization
I will discuss how password hash synchronization works in Azure AD Connect. So, let us talk about Azure AD Connect before we talk about pass-hash synchronization. Azure AD Connect uses different ways to grant access to accounts. Password hash synchronization matches your on-site Active directory login with your Azure AD login using a hash of a single password for security.
Pass-through authentication lets users use their same login credentials locally and in the cloud to sign in. It offers federated authentication which you can use with Azure AD Connect to establish a mix of local Active Directory federated services. Synchronization occurs to keep your users and other Active directory objects up to date with your AD objects in the cloud. Azure AD Connect also provides health monitoring to ensure that you know your network's activities at all times
Now, drilling down a bit, I want to look at pass-hash synchronization. Password hash synchronization is a single sign-on feature that works regardless of a user's location. Users use the same password they would use to sign in locally as remotely. This is accomplished by syncing the hash of the password with your on-premise Active Directory controller. This, of course, has the benefit of reducing the need for multiple passwords which can be problematic, especially in large organizations.
Under PHA, a user logs in with their password. This goes through the Active Directory domain controller locally, if the user is logging in behind a firewall or through Azure AD, and authenticated apps remotely. Azure AD Connect ensures that the hash of the password is synchronized between itself and the local domain controller to ensure that the password will always be secure and always be the same.
Here are the steps for enabling pass-hash synchronization. First, you have to install Azure AD Connect. This is accomplished by accessing a link in the Azure portal, which allows you to click a download link and install it on your Windows Server system. Once that is done and the link has been established, you set up synchronization between your in-house AD DS and Azure AD. Then you can set up password hash synchronization.
Pass-through Authentication
In pass-through authentication, a user accesses their accounts through Azure AD in the cloud and the various Office 365 apps associated with it. A pass-through authentication agent then connects with a local Active Directory to verify the password. If the credentials are valid, the user gains access. This method offers a finer level of control over credentials because authentication has to occur behind the firewall on the AD DS server.
Pass-through authentication is convenient and secure, offering a better user experience, simple implementation for admins, and it is very secure.
Some helpful information about Azure AD and pass-through authentication includes the fact that everything is encrypted in transit. The password is not stored anywhere but on the on-premises AD DS server. The connection is outbound only, and the process is integrated with Azure AD for a seamless authentication.
Federation with Azure AD
I will discuss federation using Azure AD. Federation with Azure Active directory is a way to establish trust among multiple domains. Using AD FS as your Active Directory Federation Services, this method of authentication is an alternative to pass-through authentication.
In fact, you can use pass-through synchronization as an alternative sign in method in case AD FS is down for some reason. In federation across organizations, you have multiple actors, that is, different organizations with multiple domains that are part of a federation. For example, different organizations that work together in similar ways, perhaps suppliers in a co-op or some other common purpose. The trust levels are varied, and that is important because trust in such scenarios does not have to be equal and probably should not be equal in the same way across the board.
In federations with Azure AD, all authentication occurs on premises behind the firewall by the AD DS server. Cloud access is still possible for Azure AD and Office 365 apps, maintaining a trust relationship with the AD DS server using a web proxy, for example.
Federation with the Azure AD has important security benefits allowing you to provide secure authentication methods, on-premise. While providing improved access control for users across the federation to gain access to their information.
Azure AD Seamless Single Sign-On
Here I will discuss the purpose of Azure Ad Seamless Single Sign-On. You can create a secure network of secured devices without having to use their credentials to sign into the network. It is a simplified automated solution. It can be cost effective because you do not need to invest in AD FS infrastructure to utilize this method.
In the SSSO scenario, domain joined sign on is achieved through Azure AD and Office 365 apps. Azure AD Connect interfaces with your on-premise AD DS server to provide authentication. So again, there is no need for a federated server solution in this method.
Using SSSO with Azure AD, Azure AD Connect is used to establish sign on and sign out is still possible. The process is opaque, however, so users do not see any of this when they are accessing their Office 365 apps. Again, it is automatic, and users could be assigned multiple user ID's, for example, one for in-house and one for remote sign-on.
SSSO with Azure AD is free, offers a high browser compatibility, and provides a great fail-safe method for remote users who need to access their organization's resources in a secure and convenient way.
Privileged Access Management
Here I will discuss Privileged Access Management and its purpose in Office 365. In Office 365 Privileged Access Management, you have precise control over user access. It uses the principle of least privilege, a security privilege that strives to give users access to the least amount of resources.
That is, just what they need in order to get their work done and no more. While that may sound restrictive, it is an important security principle and all it means is that users are not given blanket access to resources they should not have access to. A user has to request access for something they need access to, a document, for example.
Office 365 uses Azure AD Privileged Access Management for access control. It helps create layers that provide additional safety for an organization's information.
Azure AD works with Azure Ad Privileged Identity Management. Giving admins precise configuration over access to Office 365 and Azure information by assigning role privileges in real time. So users can access information based on groups, for example.
There are a few benefits to PIM. First, it means fewer users will have access to privileged information, satisfying the least privilege principle. Instead, users will have access to just what is needed and just in time, meaning they can gain privilege on an as-needed basis and no more.
So just to look at the two side by side, Office 365 PAM deals with tasks undertaken by users, say to gain access to open a document. While Azure AD PIM allows admins to assign roles, so they can request access to information assigned, for example, to groups, so perhaps a folder for a set amount of time.
Example of AD DS Objects
User accounts, groups, shared resources, and computers
AD DS Forest Models
Organizational, Resource, and Restricted Access
Four Editions of Azure AD
Free, basic, Premium P1, and Premium P2
Enabling Password Hash Synchronization
Installing Azure AD Connect, Setup sync between AD DS and Azure AD, Setup password hash synchronization
Which is not a feature of pass-through authentication?
Different passwords
What defines the structure and rules of an Active Directory?
Schema
Which is not a feature of password hash synchronization?
Multiple passwords
Which best describes a server role?
Specific functionality running on a windows server
What is the purpose of Azure AD Connect?
To integrate Azure AD and in house Active directory
Which term describes objects and subobjects in AD DS Forests?
Parent child
Which edition of Azure AD has a 500k object limit?
Free
Which AD DS forest model provides a one way trust relationship between forests?
Resource Forest
What best describes the principle of least privilege?
Limit user resources to just what they need to work
Which is not characteristic of Azure AD single seamless sign on?
Disable sign out
What is the term used for information stored in an Active Directory structure?
Objects
Which button in the Azure portal toolbar allows you to add Azure AD
Create a resource
What is the purpose of federation with Azure Ad?
Establish trust between domains