Azure AD and Access Management

This is an introduction to Azure AD and Access Management.

Check out Audible on Amazon and listen to the newest books!

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.