 Hi and welcome to the video courses for Windows Server 2016. My name is Patrick Loner and I'll be your instructor. Let's start with a little bit about my background. I've been in the IT industry for just about 18 years. I got my start with an MCSE on Windows NT, and have sort of worked my way up through the ranks on every version of Windows that has existed. I began my career in a position of network administration at a training center where I handled just about everything, imaging of PCs, hardware and software, troubleshooting in classroom environments, as well as for the business side of things. Touched just about everything and sort of felt like a jack of all trades master of none. I quickly got into training, some of the Windows 2000 courses and CompTIA courses, and as they say, the rest is history. And I've been working as a Microsoft certified trainer now for the better part of 18 years. I've had a couple of positions, one with the training center, another with a network consulting firm for three years where we were involved heavily in projects for upgrading to newer versions of Windows Server, upgrading and migrating to exchange. For the past 10 years I've operated as a freelance trainer and network consultant. It's my pleasure to be your instructor on these courses, and now let's get ready to get into the material. But in the first topic, we're going to just cover an overview of concepts, and I call these identity management concepts, as well as concepts and terms for Active Directory domain services. Identity management just is a term that is used for any platform that exists for the purpose of creating and managing unique identities. Identities represent users and computers and groups, and they are used within a client server domain type environment in order to ensure security. We need to provide access to resources. That's the whole point of a network. But I want to do so in a secure fashion. I need to be able to identify who's accessing. I need to be able to control who is accessing and control the level of access that they have. So we begin with those kinds of concepts. Let's talk about information protection. The concept of information protection really classifies one of the primary duties of IT personnel. Connect users to the information that they need in a secure manner. The purpose of a network is to connect computer systems so that they may share resources. Those resources can be files, folders, printers, applications, et cetera. But we don't just open them up so that anybody can gain access to them. No, we need to connect authorized users to the information that they need. That concept of authorizing a user requires that I know who they are. I have to be able to identify them and then authorize them and then determine the level of authorization that they have. There are a lot of different concepts, but they are foundational to the purpose of IT personnel. There are several approaches to this that are standardized in the industry. These are three acronyms that are probably the most widely used. Identity and Access, just IDA. This is users and other security principles like groups and computers which are given access to resources. Identity and Access as a term or a concept typically just speaks to the actual management platforms like Active Directory Domain Services. There's a database that hosts user accounts or holds, I should say user accounts and groups and computer representations of every system on the network so as to secure access to all of those entities. The AAA, Authentication, Authorization, and Accounting. Users provide their credentials, that's authentication, they're doing that to validate their identity. Then we're going to use those credentials or the system's going to use those credentials to secure access to resources. And monitoring and logging of that access is going to be provided and that would be the accounting piece. When we talk network security, probably one of the most common terms or acronyms that gets used is confidentiality, integrity, and availability. We need our information to be protected against unauthorized access, therefore it needs to be kept confidential. Only authorized users should be able to access the data. We also need to make sure that the data remains, that it keeps its integrity. It goes without being altered in an unauthorized fashion and then of course it has to be available. I've always thought that CIA, the CIA triad, as it's often called, is the best just kind of global term to what we need to do as IT personnel, right? Let's start from the back. We need to make the system available. It needs to be available to the users that need those resources. However, it should only be available to authorized users, so confidential. It shouldn't be able to be modified by unauthorized users, so it should maintain its integrity, both in storage and in transit. So these are three foundational concepts or different approaches, if you will, that we should be familiar with in the industry. So let's dig into them a little bit deeper. Identity and access first. Identity is a user account or other security principle, such as groups and computers, and then those identities will access resources like shared folders or other objects, a database, an exchange mailbox, a web application internally, et cetera. Those identities are going to be stored in a directory database and uniquely identified using what's called a SID, a security identifier. So an object SID is something that we're going to talk about frequently here within Active Directory because it's how the system uniquely identifies each identity. When we go to access, the actual shared folders or the folders on an NTFS file system are secured with a security descriptor. That security descriptor is better known as an ACL, an access control list. Now there's more to the security descriptor than the access control list, but the access control list is one of the most important parts. It is a compilation of individual entries or ACEs, and the ACEs identify an identity and the level of permission that they have on that particular resource. So the directory database like Active Directory stores the identities. The security descriptors are stored on the actual resources that those identities will need to access, but collectively the two are going to ensure that only authorized users have access to resources. Now the functions of authentication and authorization, therefore, are a part of the directory service itself. Technically authorization is part of access as well, but these are integral to Active Directory domain services and they're integral to any type of secure access to resources. The first concept is authentication. Authentication is validating the identity of an individual, the user on the network. We have to be able to identify who you are in order to be able to determine what you are able to do. And we're familiar with the concept of authentication. If I go to try to get onto, let's say, a cruise ship, I have to provide my identity. If I'm going to get on a plane, I have to provide my identity. I don't just provide the ticket, which authorizes me to get on the plane. I also have to validate who I am that my name matches the name on the ticket. And then that identity, that certificate, if you will, has to come from a trusted entity. I've often said I can't just show up with a post-it note that has my name and address on it. The TSA personnel are not going to let me through the security checkpoint. Even if I've got a valid ticket, if my only ID is a post-it note. So the ID has to come from somewhere that is valid. We'll get back to that here in a second. But the concept of authentication is simply validating who somebody is. And so this is any kind of login on a Windows network. You have interactive logon, which is sitting down in front of a computer and typing in a username and a password. That's an interactive logon. Then you have network logon, which occurs anytime you try to access something over the network. Now, the latter of the two, we often in a client-server domain environment don't even see because it's passing your interactive login credentials across the network and we're not being asked to authenticate again. So that can sort of give the impression that you just log into the system once and that's all you need, when in reality there are things going on behind the scenes all the time. But Active Directory does enable what's called single sign-on. You log on to the domain once and then you're able to access resources throughout the domain. I don't want to get ahead of myself too much. It is a necessary concept of validating the identity of the individual. Also necessary, though, is authorization. Authorization is the process of verifying whether an authenticated user has access rights that are required for a network resource. So what can you perform? Are you able to read? Are you able to write? Are you able to delete on Active Directory objects? Are you able to create, manage, delete those kinds of things? So authentication and authorization are definitely tied together, but one does not imply the other. So authentication does not imply authorization. In other words, just because you are who you say you are and that's trusted doesn't mean you can do whatever it is you're trying to do. Go back to the situation where I'm trying to get on a plane. I'm going to go to the airport and I hand the TSA person my driver's license. They're going to ask me for what? They're going to ask me for my ticket. They need the piece of documentation that doesn't identify me but validates that I'm actually supposed to be able to walk through that security checkpoint. If I show up and validate my identity to them, it is meaningless if I'm not authorized to walk through the security gate. And the same thing is true in Active Directory. You can provide a valid username and a password to the domain controller but if you don't have login rights at the computer you're sitting at you're not going to be able to log in. If you go to try to access a file or folder you can validate your identity but if you're not given the permission to access that resource you're not going to be able to access the resource. So authentication alone is not good enough. You have to have both authentication and authorization. So another way that I often say it is that authentication does not imply authorization but it must precede it. So you have to validate your identity before I can determine whether you're authorized to do something. So one final visit to my TSA analogy is just to summarize. If I show up with an ID and no ticket I don't get in. If I show up with a ticket and no ID I don't get in. You need both authentication and authorization. Now let's go back through some of the terms. We've actually mentioned a couple of these already but these are terms that I'm going to use as we go through this course and we just have to make sure everybody knows what we're talking about and we want to continually define them. A SID, an object SID is a security identifier and every user, every computer, every security group, service account, every object technically created in Active Directory has what's called an object SID and that object SID actually is going to have two parts. It's going to be made up of the domain SID, security identifier, and then a relative identifier which identifies that object uniquely but collectively the two are just referred to as the SID. Now typically I don't see the SID. We see common names of users, groups, computers. In fact if you do see the SIDs it often implies that there's a problem like on an access control list if you see a SID instead of a username in many cases that means that there's something wrong with a trust relationship or something to that effect. So we don't have to see them but the system uses them. A security principle is just another term for any object with a SID. I don't usually call it a security principle nor do I know many people who do. It's the user account but a user account's a security principle. A security group is a security principle. A computer account security principle on and on. Now I mentioned the ACL. The full name of that is actually DACL. Sometimes people will pronounce it DACL. It's discretionary access control list and this is a part of a file and folder as well as directory objects and they're the part that grants access to users, groups, and computers. This is where the authorization comes from. The individual access control entries that either grant or deny access to a particular user or group. Access tokens are something that is generated during the login process. The access token is going to be generated through kind of mutual efforts from the local security authority on the client computer as well as the LSA and KDC components on the domain controller. It's going to contain the user SID as well as SIDs of any groups that I belong to. We'll come back to how that's used here in a minute. Kerberos is the primary authentication protocol for Active Directory. Kerberos is an inherent part to any AD environment and it provides a very secure means of authenticating. Back to the access token a little bit more. The access token is a protected object that contains information about the identity and associated user rights of an individual. This is not something that you see. It's certainly behind the scenes, but it's pretty important. It actually stays attached to your user process and is used to determine access rights and your identity throughout the duration of a login session. As I said, it's generated by the LSA in conjunction with the key distribution center component of Kerberos that's hosted on a domain controller. It contains the SID of the user account. It contains the SIDs of any groups that I belong to. It also contains a list of user rights. User rights are a little different than permissions. Permissions are granted on a particular object. A folder, for instance, will have an access control list that says if you're in the marketing group, you get read-write permission. If you're in the managers group, you get modify. That's a permission. It applies to that particular object. User rights are permissions, but they're permissions for the entire system. The user right of logging on locally just simply means that on this system, this account, this group can sit down and log on interactively. Backing up the system, taking ownership of files and directories, shutting down the system, et cetera, et cetera, there are 35 to 40 different user rights. But when you log in, your access token is going to have that list of user rights. It's also going to have other access information. It's possible to restrict log-on times for users. It's possible to restrict the computers that you can log on to. Although this is not commonly done, it would be a part of the access token. So when I log in during the login process, that's when this access token is generated and it's attached to every user process that tries to access resources both locally as well as over the network. Access control is the process used when accessing protected resources. In Windows networks, pretty much every resource is protected because we typically don't see the FAT32 file system being used. All objects on an NTFS partition therefore have a security descriptor, which contains these different components and all Active Directory domain services objects will have a security descriptor as well. The security descriptor has a DACL, which contains a list of users and groups that either have access or have been denied, and that DACL is specific to each object. It also has a system access control list. The system access control list is a little bit different. It controls the auditing of specific objects. So it's determining whether or not I'm trying to track access to this particular object. In either of these cases, DACL or SACL, the individual entries are called access control entries or ACEs. They specify the SID of a single object. It could be user or group or computer. It specifies whether the permission is being allowed, denied or audited, and then it specifies the actual permission. The way that this works is if there isn't an ACE that matches the user or group, then access is implicitly denied. So if you're not on the list, then you don't get access. So the analogy that we usually use is trying to get into a private party. A private party where people have, maybe it's a charity organization and they're setting up a dinner and you've paid $500 a plate that when you walk up, you have to validate who you are, but then you also have to be on the list and if you're not on the list, then you don't get in. That's the way it works in Active Directory and NTFS. There has to be an entry on the list that grants that particular person or group access or else it's implicitly denied. The Kerberos login process is a very involved process. I've broken it down into six steps here and just trying to get a somewhat of a general understanding. You don't need to have detailed knowledge about the Kerberos protocol. The white paper is over 100 pages long for Kerberos and it's just simply not important. But it is behind the scenes. It is what protocol is being used to authenticate so it's somewhat important for us to get just conceptually because Kerberos provides single sign-on capabilities. That's one of the biggest benefits in an Active Directory environment, at least just initially, is the ability to use the same account and access multiple systems but not have to provide that account multiple times. But behind the scenes, it's using that account to determine my level of access. The component that's used on the domain controller is called the Key Distribution Center or KDC and it's a sub-component of the local security authority, LSA. LSA is the actual service you would see if you, say, pulled up task manager and looked at the processes. Now Kerberos gets its name from Cerebrus, the three-headed dog in Greek mythology that guards the river Hades. You might think, well, that's a sort of odd point to bring out. But if you go to the Kerberos web page, it's got pictures or drawings of Cerebrus and it actually is an important point because it's a three-headed dog. We've actually got three components in a Windows network that will provide this single sign-on. You have the client and the server, the client and the file server they're trying to access, and then you have the domain controller, which is this trusted third party to both client and server. So it is kind of a three-pronged approach and that's why I think that that's an important point. So let's walk through these steps here and then we're going to use an analogy. So first off, the user account gets authenticated to a domain controller. A user just sits down in front of a computer and provides their username and password. That username and password is sent in a secure way to the domain controller. The domain controller will then return what's called a TGT or ticket-granting ticket to the client. Now the client will immediately use the ticket-granting ticket to request or apply for access to the local workstation. Remember I have to have the ability to sit down in front of a computer and log in. Technically the workstation that I'm at is the first resource that I'm trying to access on the network. So the client will immediately use the TGT to apply access to the local workstation. The domain controller will grant access to the local workstation. And at that point, even though we don't have it listed, that's when the access token is getting created. So the access token contains the SIDS. I take that back. The access token is actually done up in step number two before I get a ticket-granting ticket. I've got an access token that's got my user SID, my group SIDS, user rights, login information because it's actually that information that's used to determine in step three if I have access to the local workstation. Okay, so now the user's logged in and now let's say I try to hit a shared folder. Well, the client behind the scenes will use the ticket-granting ticket to apply for access to a remote system. It's asking for what's called a service ticket. And assuming that I'm authenticated, the domain controller will return that service ticket to the remote system. The client will then present the service ticket to the file server. Now, the process isn't done, but that service ticket identifies to the file server that, hey, I'm a valid user. I'm an authenticated user. Here's my access token. It tells you exactly who I am. And this is information that has been given to me by this trusted third party, the domain controller. So the file server will accept those authentication credentials and then will use its own access control list to determine whether the user has access to the file. I always like to use the analogy of a county fair with the Kerberos login process, okay? And in order to explain the analogy, we have to contrast it with the analogy of an amusement park. So if you go to an amusement park and you pay, you know, whatever, $50 or $60 or more to get into the amusement park, it's sort of under the understanding that you'll be able to ride all the rides, okay? Sure, every analogy falls off. They've got a few things here or there that may cost additional money. But for the most part, in an amusement park, when you pay to get in the door, you are authorized to ride every ride in that place. That's not the case with a county fair. A county fair, you pay to get in the gate, albeit much less, but all that gives you the ability to do is what? Well, go to the ticket booth. If you want to ride rides, you've got to go to the ticket booth and you've got to buy tickets. And then you have to present those tickets to each individual ride in order to get on the ride. And that's what Kerberos is like. I get into the network. I sign in. I validate my identity. But all I've really given myself the ability to do is to go obtain tickets when I need to go access individual resources. All right? All behind the scenes. The user doesn't see any of this. The user's not asked to authenticate more than once. They are going to either have access to resources or they're not going to have access to resources. And Kerberos is behind the scenes making sure that all that happens. So far, as we've been talking about, we've sort of implied the entire time that we have a domain environment and actually active directory environments are always domain environments. But there is another kind of environment and that is a workgroup situation. And authentication and authorization will work with two different types of identity stores, either standalone or workgroup or active directory, a.k.a. domain. So standalone authentication and authorization just means that the identity store that holds the user accounts and groups is the local SAM or Security Accounts Manager database on the local system. So there is no shared central identity store. If you have a user account on this computer, then you can log on to this computer. If you need to access resources on another computer on the network, then you will need a user account on that computer. Your user account in your local SAM database does nothing for accessing resources on a separate system. So you're going to have to have multiple accounts. You can set up accounts that are shared that multiple people use. You can set up duplicate accounts on each system. And you can achieve that level of access, but you can see how that would become very cumbersome, the management of multiple accounts, the management of passwords. And so this is practically limited to very, very small environments. Now, Microsoft, by the way, in Windows 7 and later has created the concept of a home group, because this was really quite annoying to try to do this back in Windows XP, even in a home network that had three or four different systems. Clearly, their security is not that big of an issue, but still I'm just trying to enable access. So the home group really made it a lot easier, but it did not make it easier by eliminating this requirement to having accounts on each system. It instead just used a special home group user account. And so a home group user account is created and it's the account that is used when people try to access resources from one to another system in the home group. Fundamentally, behind the scenes, the concepts are exactly the same, with the SAM database, no shared identity store. It's just that Microsoft took some steps to make it easier to use in home environments. But in business environments, that's not what we're going to be doing. Even the smallest businesses will often still be utilizing a domain because of the benefits that it provides. Now, when I say that I'm talking 10-plus computers, sure, if you've got a really small business that's only got two or three computers, then you probably aren't going to have a domain because it would just be a little excessive. But anything beyond 10 computers and a domain environment is going to be very beneficial. Active Directory Domains function as a centralized identity store that's trusted by all the domain members. So everybody belongs to the domain, this group of computers that share a common Directory database. That database is hosted on domain controllers, and as we've already seen, users provide authentication services through Kerberos. They run the Active Directory Domain Services role. They provide the ability to authenticate users. They provide the ticket-graining ticket capabilities and service tickets for resources. So there's a lot of benefits to using domains. It allows you to store information centrally regarding users, groups, and computers. Because it's stored centrally, that means I only need one account. It doesn't matter if we have 500 computers in the domain, I'm still going to have one user account for each individual user. They don't need to have separate accounts on multiple systems. They're all also in the same place, so they can be centrally managed. Provides centralized authentication and single sign-on using the Kerberos authentication protocol. Centralized access control using users in groups. And also provides the ability to set up audit trails when that is required. So I suppose just to make sure everybody's on the same page, we discuss really quickly workgroup versus domain. But obviously for the duration of the course, and any time you're in a business environment, you're dealing with Active Directory Domains because of the numerous benefits that they provide. So with that definition of the Active Directory Domain behind us, let's move forward and talk about some of the components and concepts within Active Directory Domain services. We're going to start by talking about the Active Directory database. At the heart of AD is a physical database. It's a directory database that stores information about users, computers, groups, and other objects. Active Directory has both a logical and a physical structure. The logical structure controls the organization of Active Directory. The forest, the trees, the domains, the OUs, those are all part of the logical structure. The physical structure is the database itself, the partitions, the sites really represent the physical structure, global catalog servers, and the like. And we're also going to talk about the concept of trust relationships, although we won't revisit that until we start getting into your more complex Active Directory environments. So at the core, Active Directory Domain services is just a database. That database contains records and fields, but we don't usually refer to them in that way. In Active Directory, we call them objects and attributes. So each record in the Active Directory database represents an object, and an object is a user, a computer, a group, a shared folder, a printer, a domain controller, an OU, et cetera, et cetera, et cetera. These are all objects. Every object has attributes that define that object. So the attributes are unique values to identify things about the object, like login name, SID, password, et cetera. So when we talk about objects and attributes, that's what we're talking about. So let's use a user account. So here's a user object. Here's my user object. My login name is Patrick L. My SID is generated by the system. My password is whatever my password is. There are other attributes. Of course, department, office, city, state, phone numbers, manager, title, it goes on and on and on. But the objects are defined by the attributes. Active Directory also provides services and interfaces between the database. Kerberos would be the authentication protocol as we've talked about, but it is used to access the database to validate credentials. Replication is used to replicate the objects and attributes in the database. There's Windows tools, Active Directory users and computers, Active Directory administrative center, which are used to interact with the database. So in other words, we're never directly interacting with the database, adding records and fields. Now we're going into a graphical tool and clicking a button to create a user account. Or we're using Windows PowerShell and the new AD user, new AD group commands to interface with the database. So at the core, it is a database. It's actually called ntds.dit. It sits in the ntds directory on every domain controller. But never will I actually go and work with those files, save backup and recovery scenarios. We call that database the data store. It contains the database files and processes that store and manage directory information for users, services, applications. So the file name is ntds.dit. By default, it's in the Windows ntds directory. It is a transactional database. That means that changes to the database, the addition or modification of objects, are going to be recorded using transaction log files. The changes are actually made in memory. But the problem with making changes in memory for a database is that if I lose power, then I will have lost the changes and I don't have no way of recovering them. And so simultaneously, when the changes are written into memory, they're written into these log files. And then the log files are used to commit the changes into the database, but they also provide a recovery mechanism should you lose power. This is an extensible storage engine, ESE database, which is a standard type of database for many Microsoft products. Even though it's a single physical file, it is logically divided into partitions or naming context. Okay, now those are just two terms that talk about the exact same thing. And we'll talk about those partitions. This is accessible only, this database, accessible only using domain control or administrative utilities and processes, and we've described some of those already. So the partitions or naming context are important because they provide a logical division of the Active Directory database. Each of these partitions contains different kinds of information. And in many cases, I don't interact with them a great deal, but it's still important to understand that they exist. So I'm going to start right in the middle and that's on the domain partition. If you've worked with Active Directory at all, then this is the partition that you're familiar with because the domain partition is what we see when we open up tools like Active Directory users at computers or the Active Directory Administrative Center. And I'm mentioning both just because the Admin Center was introduced in 2008 R2 and so some people still don't know that it even exists. And anyway, we'll use that tool, we'll use both of them, but the domain partition is going to be the domain and all the organizational units inside of it and where the users and groups and computer objects are. And so that's where we're at 99% of the time, therefore that's the partition that we are the most familiar with. The domain partition is a portion of the Active Directory database that contains those objects and is replicated within the same domain. Now let's go up to the top, Schema Partition. The Schema Partition is a forest-wide partition. There's one Schema, regardless of how many domains you have in your Active Directory environment. It defines objects and attributes. I'm going to hold off on that one because we're going to go into it here in just a second in more detail. The configuration partition is sort of the topology of Active Directory. It's the layout, it defines sites and replication objects and it defines trust relationships. Active Directory integrated applications like Exchange would integrate and store all their information in the configuration partition. On the vast majority of days, you and I would never be going into the Schema or the configuration partition. In fact, really one of the only reasons to even go in there is just to validate information, not actually add any information. So we spend the vast majority of our time in that domain portion, but both the Schema and the Config are forest-wide partitions. In other words, there's only one of them in the entire forest. Now a global catalog is technically a separate partition. The global catalog is a domain controller that has information about multiple domains within the forest. More on that later. And the global catalog also has a partial attribute set or PAS. So the global catalog contains all objects, but it does not contain all attributes. It is primarily there for locating objects in a multi-domain environment. And you also do have application partitions, but application partitions are for the storage of application-related data and in situations where we need to limit where that data is actually going to be replicated. So, you know, in any environment we're going to use the top four, but the use of application partitions is actually far less common. Now you also have a sysfall folder structure on domain controllers. The sysfall folder structure predominantly is going to hold your group policy objects. It can also contain login scripts, but that's really a legacy setup. And so nowadays we use group policy to push out login scripts or even use group policy to eliminate the need for a login script. So the sysfall folder structure has a policies directory in it, and that's where all the group policy objects are going to be contained. And that's where clients are going to connect during login to apply those policies. So it's a single physical file, but the database is separated into these various partitions. And as I said, each partition is going to have different types of information. Now back to the schema, I just didn't want to hit it super quick. I mean, you don't have to deal with the schema that often, but it is incredibly important. The analogy that I often use is like the schema is like the registry for Active Directory. Now that's a completely inaccurate analogy because it's not the same at all. It's not storing the configuration of Active Directory like the registry is. So the only reason, that's my disclaimer, the only reason I didn't even use that statement is just to discuss the importance of the schema. What happens if you corrupt your registry on your computer? Well, you restore from a backup or you reinstall Windows. It's bad news, right? Well, that's the same thing that would happen if you corrupted the Active Directory schema. And so that's why I use that phrase. But really, the schema provides the definitions for objects and attributes that can be created in the Active Directory database. So we said you can create user accounts in Active Directory. Well, how? Well, it's because the user object class is defined in the schema. So when we create a user, we're actually creating an instance of this user object class. And that object class defines the attributes that can be provided for a user account. And it defines that some of these attributes are mandatory like a SID, a display name, a user login name, a password. These are mandatory attributes, whereas others, department, city, state, phone numbers, et cetera, those are optional attributes. And so, but it is the schema that defines that. You can't just go create a car object in Active Directory with attributes like make, model, and year in mileage because that object class doesn't exist. Okay? It's not there. Now if you wanted to create it, if you wanted to use Active Directory to store information like that, well, then you'd have to create an object class and then create attribute classes and link the two together. It's uncommon for us to do that, at least manually, but the Active Directory schema is extensible to support additional applications. And the best example of this really is Microsoft Exchange. Microsoft Exchange is the Microsoft email platform. It's been around for 20 plus years, but it is integrated with Active Directory and has been ever since Exchange 2000. Just so you know, we're on version 2016 now. That means that Exchange stores all of its information in Active Directory. So every policy that you create, every domain that's represented, every, you know, every control, everything that you would create in Exchange is an object in the Active Directory database. Not only that, but it enables a whole bunch of additional attributes for existing objects like users and groups because you can mail-enable them. So you're going to assign them a mailbox. You're going to assign policies to their account limits, et cetera, et cetera. Not meant to be an Exchange class here. I'm just a good example because the very first thing that happens every time you go to deploy Exchange in an Active Directory environment, the very first thing that happens is a schema extension. All these files get added into the schema so that all these new objects can be created and so that when you go to a properties, the properties of a user object, you have access to all these additional attributes that has to be done in order to support that particular application. Having said that, as I said, the schema is not overly relevant to day-to-day life. We don't modify the schema to create a user object. We only modify the schema if we need to create a completely new object type, which is very rare unless it's in conjunction with an application. But don't let that make you think that it's not important. It's incredibly important. It's just not something you're going to work with on a day-to-day basis. The absolute most important part of an Active Directory environment is the domain. It's the term that we just need to understand. When we use the term domain in an Active Directory environment, we're not talking about just a conceptual thing. Oh, there's a client-server domain environment. No, we're actually talking about the core unit in the logical structure of AD. A domain, a collection of Active Directory objects. This is used to group them and manage them within the organization. A domain is like a club that you belong to. You are entering the club. You are logging in to the domain. You're using a user identity that exists in the domain database, specifically in the domain partition for your particular domain. Even though I'm sitting in front of a computer, I'm no longer logging on to that computer. I'm logging on to the domain, to this collection of computers. That collection of computers has a couple of things. It's an administrative boundary. In other words, there's a built-in administrator account in the domain. There's a domain admins group in the domain. The administrative privileges of those accounts extend to and stop at the domain boundary. If I'm an admin in domain A and there's a domain B, I don't have any rights over in domain B and vice versa. It's an administrative boundary. It's also a replication boundary because each domain is represented by a unique domain partition. That partition and everything that you see in Active Directory users and computers for a particular domain would only be replicated within the domain. Just in case here, Active Directory uses a concept of multi-master replication. I just want to make sure we've used the term a couple of times here. Make sure everybody's on the same page. If you've got more than one domain controller for a domain, they both have a writable copy of the database. A user can be added in one copy and a group can be added in another copy. The process of replication is the process of making sure that all of these writable copies of the domain database are kept up to date. That's within a domain. It's a replication boundary. It's also an authentication and authorization boundary by default. In other words, your single sign-on capabilities extend to and stop at the domain boundaries. If you're a user in domain A and you've authenticated to domain A's domain controllers, then you cannot inherently access resources over in domain B. Additional components will be required in order to enable that access. It's the core unit of the Active Directory logical structure and it provides these boundaries. Domains can actually be put together. We won't talk about this a whole lot beyond this concept here until we get into the complex setups. Domains can be set up in trees and forest. A domain tree is a logical hierarchy of domains within the same Active Directory forest. It consists of parent and child domains. They have a contiguous DNS namespace, meaning that an Active Directory domains use DNS names by default. Let's say my top-level domain here is companyabc.com and then I have a support subdomain and a sales subdomain. The DNS name of the sales domain is not just sales, it's sales.companyabc.com, so it's contiguous. There are also two-way transitive trust relationships with the parent and child domains. We're not going to dig too far into that statement right now other than to say that in order for you to cross domain boundaries, administrative boundaries, authorization, authentication boundaries, that trust relationship has to exist and just a little bit more on that here upcoming. A domain tree would be a hierarchy within the same forest where you have the same namespace. A forest is often defined as a collection of Active Directory domain trees. Now, I have personally always hated that description. And here's why, because a forest is really an implementation of Active Directory. In other words, it doesn't matter if you have one domain or 100 domains, you have an Active Directory forest. And you'll see that when we go to deploy our first domain controller, because our choices are going to be a domain controller for a new domain in an existing forest, a domain controller for an existing domain, or a domain controller in a new forest. In other words, the first domain controller you set up, you're creating a forest. And if you add no other domains to it at all in the future, then it is still a forest. So it's just an implementation of Active Directory. The forest though does have a single schema, a single configuration partition, a single global catalog. And if you add multiple domains into an existing forest, then there will be transitive trust between all the domains in the forest. And the forest itself would be the ultimate security boundary. And we're not going to get too tied up in these. I'm trying to give us a good overview of Active Directory, so we need to mention domains, trees, and forest. But please don't let yourself get hung up on this. We have a whole chapter where we'll talk about some of these complex Active Directory environments, and we'll deal with them more at that time. So now we're sort of going back to the domain, because within the domain, we have another component called the OU, or simply organizational unit. And the organizational unit provides a method for organizing objects within the domain, as well as having other features. In one sense, an OU functions like subfolders in a data directory. I usually use My Documents as the example, because you've got some people whose My Documents folder is just thousands and thousands of files, and there doesn't appear to be any organization. You have other people's My Documents folders, like mine, that has at least 30 subfolders in it, and at least some level of organization. And that's kind of one of the features of the OU, is that it can just help you to organize. Could you have an Active Directory environment with 2,000 user accounts, all of which are just in the user's container? Well, yes, but it would be a little bit cumbersome trying to manage that. So it would make a little bit more sense if you had location-based OUs, or departments, or business functions, or as the last bullet point says, anything that works well for administrative purposes. So that's what the OU does. It allows us to group items within the domain to see if we create additional domains, then we need more domain controllers. And we have trust relationships and just the complexity that comes along with multiple domain environments. But to create OUs, you don't need anything. You just go into the administrative tools and create OUs. So typically, they're created to represent the organizational hierarchy to provide the consistent management of objects. And then the two major functions of the OU is to provide the delegation of administrative control and to control the application of group policy. So I can give somebody admin rights on a particular OU and all the objects that are contained within that OU. And I can point a group policy object instead of at the domain, which would affect everybody, I can point it just at an OU. And then it would only affect the objects in that OU. So much more on those two elements to come, but the organizational unit is a very integral part of an Active Directory environment. Active Directory sites are technically logical objects. I've often called them physical, but when you really get down to it, it is just an object that you're using a graphical tool or PowerShell to create. So it truly is a logical object, but they represent physical locations. So sites are logical representing a physical component in Active Directory. So as it says here, they represent IP submets that are connected by high-speed reliable links in order to do two things. One is to control replication traffic and login traffic. The sites will actually consist of subnet objects, and the subnet objects will have the IP addresses or network IDs of the subnets that are used in a physical location. So domain controllers that are set up are associated with one or another site. Clients are associated with those sites based on their IP addresses, and the sites do two things. They control the login traffic using DNS and service records. Domain controllers will register a record that says, hey, I'm a domain controller for this domain in this particular site. So it helps the client to always use a local domain controller. They also control replication. Replication within the same site between DCs happens very quick on what's called a change notification basis, and often it's within seconds. Well, when you don't have or when you have separate physical locations and maybe low-speed or unreliable WAN links, well, then you want the ability to control and schedule that replication. Sites and site links allow us to do that. Other site-aware applications like the distributed file system, Exchange Server 2007 and later would utilize sites. We can assign group policy objects to sites, although we don't typically do that. It is possible if you wanted settings just for a particular location. But Active Directory sites don't have anything to do with the logical organization of AD. They are simply for the control of replication traffic and login traffic. And replication is that process of keeping multiple copies of the Active Directory database that are stored on separate domain controllers up to date. You know, having multi-master replication is very important, or having a multi-master scenario is very important, because it means that changes can be made to any domain controller. But because those changes can be made to any domain controller, we need to also ensure that the domain controllers have the same information. And so replication is going to be used to do that. And the replication topology is going to get created automatically as domain controllers are added to the domain. There's technically nothing you have to do to make replication happen, but we can use Active Directory site objects to control that process. Now earlier we mentioned the concept of a trust relationship. The trust relationship is a mechanism that's required for external access to resources. That's anything outside of the domain. And the reason for this is because the domain was an authentication and authorization boundary, right? So a user account in domain A cannot access resources in domain B. Without a trust relationship. Now if that doesn't make any sense to you, go back to our work group scenario. We've got computer A and computer B. So a user's got an account on computer A, and they try to use that account to access computer B over the network. And computer B says, what's your username? And I say Patrick, and here's my password. And computer B looks in it's SAM, it's security accounts manager database, and says I don't have an account for Patrick. And that's where the process stops. I can't access resources on that computer because I don't have an account on that computer. That's the exact same thing that happens in a domain environment. Right? I've got a user account in domain A. I go try to use that user account against the domain B resource and the domain controller and domain B says I don't know who you are. This isn't coming from a trusted entity. And so trust relationships provide that capability. Think about it like this. The trust relationships are created, and they allow, let's go back to A and B, they allow domain B's domain controllers to say, I trust domain A, I trust their domain controllers to authenticate their users, and I'll let them access my resources. All right? So it's always pointing away, the direction of the trust is always pointing away from the resource to the user account. Because that's specifically what you're saying. You know, you're not copying accounts. I'm just saying, hey, we have a trust relationship. So you authenticate them, you know who they are, and then I'll allow them to use those identities to get authorization to my resources. Doesn't, you know, just as we said before, authentication doesn't imply authorization. So just because I have now authenticated you doesn't mean I'm going to let you use a resource, but before, we never even got past the authentication because they didn't know who you were. All right? So that's what the trust relationship does. Within an Active Directory forest, all the trust relationships are automatic. So if you've got a multi-domain Active Directory forest, you don't ever have to create trust relationships. They are required between domains, but they're two-way, they're transitive, meaning they carry over, and it's automatic. But sometimes with partner organizations, we may need to create trust relationships between external domains, okay? The point is this, in order for resources to be accessed outside the domain, a trust relationship has to exist. So you've got external, which is a domain-to-domain outside of a forest. You've got a forest trust, which is a trust relationship between the roots of two forest domains, and then you have a shortcut, and the shortcut's an odd one that's used within a forest, but it's to provide a quicker path to access those resources, and we're going to leave that one alone for now. Trust relationships really are part of complex Active Directory environments. I think it's important conceptually to understand why they're needed. That's why I put them here, but we'll be going into them in more detail in an upcoming chapter. Thank you.