Create and manage AD DS security principles - Windows Server Tutorial

- [Instructor] One of your primary responsibilities as an Active Directory administrator is to manage user accounts, domain users. They have a larger number of properties that are configurable than local user accounts on a Windows 11 workstation for example. Not only will you need to define the user properties, you'll also need to define where in the domain environment the user will reside. That could be in one of the built-in containers, but it's more likely you'll create organizational units to contain your users, perhaps on a departmental basis. When you come to create groups, there are a number of different scopes of group and also types of group to consider. Domain Local groups, Global groups, and Universal groups are the three scopes. A domain local group can be assigned permissions on objects within the domain where the group exists. However, it can contain members potentially from any domain in the forest. By contrast, a global group can be assigned permissions and management responsibility anywhere in the forest, but can only contain members from the domain where the group has been created. And a universal group can contain members from anywhere in the forest, but can also potentially have access to anything in the forest. So you can choose the appropriate scope of group based on your particular administrative requirements. There are security groups and distribution groups. Security groups can be assigned permissions on objects or assigned permissions within Active Directory for management purposes. Distribution groups cannot, they only exist for the purposes of supplementing mail distribution lists in something like Exchange Server. In Active Directory, it's possible to add one group as a member of another group. This is referred to as nesting. However, in a single domain network, you could theoretically use only one scope of group and then you wouldn't need to nest groups. The reason for that is that the distinction about the differences between the different scopes of group relies on who can belong to them and where they can be assigned access. So a global group can have access anywhere in the forest, but can only contain members from the local domain. If there's only one domain, it doesn't really make any difference. All of the resources are in the same domain as all of the users and groups. In organizations where you have multiple domains, you might benefit from nesting groups. There are a number of approaches, but best practice suggests that you nest the groups as follows, depending on your particular needs. So, take your user account, add them to a global group, add that to a domain local group, and then assign permissions to the domain local group. In a very large network consisting of many domains, then you might take the approach of adding a user account to a global group, in turn, adding that to a universal group, adding that as a member of a domain local group, and then assigning the domain local group permissions. In the demonstration, I'm going to show you how to manage organizational units, users, and groups. So the tool that you choose to use to manage your users, groups, and organizational units is entirely dependent on your personal preference. Probably the Active Directory Administrative Center is a good place to start. You can select that from the "Tools" menu in Server Manager, and by using this tool, you can create pretty much any type of object. There are also some capabilities provided here such as Dynamic Access Control and managing the AD Recycle Bin, which we'll talk about later, that are not accessible through some of the other tools. Performing fairly simplistic tasks, you can navigate to find a particular organizational unit and then you can review the objects within that organizational unit. You can then go on to create a new organizational unit beneath the domain or beneath a particular OU, depending on what you want to do. So we want to call this, "IT Computers." And if you want, you can specify some managed capabilities in here, specify who manages it, whatever you want to do, and then otherwise click "OK." So I've now created a child OU, "IT Computers," beneath the IT OU within the Contoso domain. I can then go on to create objects within that if I want to, such as "Computers." We'll talk about adding computers to domains shortly. If I want to add a user account to an OU, again, using the Administrative Center, I can select "New" and then choose "User," and then specify the properties. I'll enter my own name here. It's important that you specify a unique User Principal Name, that's the UPN abbreviation there. That's a name that looks a little bit like an email address. You have to choose a suffix, in this case contoso.com, and then specify the prefix, which might be a variation on the user's name that yields up a unique identity. When you do that, it also generates what's called a down-level sign-in name. In this case, that's the domain name in its NetBIOS format, "Contoso," so it loses the suffix and then uses the same UPN prefix to create "CONTOSO\1aj." And that's possibly the form of user ID that your users might typically use when signing into their domain-joined computers. It's a good idea to specify a password. And then you might want to go on to define other properties such as organizational details, job role, department, company. You might also take the opportunity to add the user to a group and to define password settings, so authentication policy, if there is one, and the Authentication Policy Silo. You may also want to go on to define profile settings so that you can define a roaming profile and a logon script for the user, although these days that's normally handled using Group Policy and Folder Redirection settings within a Group Policy. And when you are ready, on the Account page, you can select any other final details and then click "OK" to create the user account. When you create a group, you start off by specifying whether it's going to be "Security" or "Distribution," and whether it's going to be "Domain Local," "Global," or "Universal." As I said, generally you use domain local groups to assign permissions and then global groups to consolidate users into a collective that in turn belong to the appropriate local group. In a single domain environment, remember, it's not necessary for you to use multiple tiers of group, but that may well still be a good strategy in case you add additional domains along the way and then you can adhere to an existing standard rather than change the way that you've done things. So I'm going to create a group called, I don't know, "IT Managers," I don't know if that exists already, let's see how we go. And then I'm going to select, click "OK" here. I can add members here or define it as a member of another group if I want to. So here we can see I can choose the option here to add a user account. If I type "Warren," which is part of a name, and then select "Check Names," it will select the user for me. And then when I'm happy, I can select "OK," and that will create the group. Later, depending on what I've done, I can change the properties of that group, so I can change it to a distribution. So it tells me, if you're doing this, that's fine, but you'll lose any access because a distribution group can't have permissions. And you can also change the scope. But that's a little bit more complicated because the rules around who can belong to a global, universal, domain local group and what permissions you can have and where can make that somewhat of a convoluted operation, so we're not going to cover that right now, but it is possible in certain circumstances. It's unlikely to be a thing on the test, so we won't worry about it too much. So I'm going to click "OK" there, having made no other changes. So in addition to using "Active Directory Administrative Center," I can also use "Active Directory Users and Computers." And there's my IT OU, and there's my IT Computers OU that I just created. And yeah, I can create objects in here. This is a slightly more simplistic interface, and it's not as configurable. So again, I'm going to add, oh, I don't know, just a standard account, "Sales Manager" is not a very good username, but for our purposes, that will be fine. That, and then select "Next," enter a password, and then I can select these options for "User cannot change password," or "Password never expires," or that "User must change password at logon." Some of these are mutually exclusive. And then select "Next." And as you can see, that's pretty much it. I'm not prompted to do anything more in the wizard, so that's fine, but it necessarily means that I'd have to come back in and specify additional properties, which I can fairly easily do, but it's not a convenience. I think Active Directory Administrative Center gives you more capabilities at the outset. I'm just going to delete that user account because it's a fairly meaningless name. And the other way in which you can manage objects, user or group objects, is to use PowerShell. So if I do a "get-ADUser "-filter *" and then output as a table, for example, that will retrieve all of my user accounts and display them in a table. I can be specific about the things that I want to know, if I want to know anything. So I can say, I don't know, "Name," and then "ObjectClass," for example. And I can obviously do more than just retrieve. I can also create new Active Directory user objects so "New-ADUser," or I can change the properties of a user object, and likewise, a group. And if you're unsure about working with PowerShell, that's fine, you can use the Active Directory Administrative Center. So let's go back to it. And when you perform a management task, like adding a user or group account, down at the bottom you've got "Windows PowerShell History," and that will show you a summary of the task that you just performed. So let's modify a user, change its properties, and let's give them a middle name, and maybe put them into the IT department and the company, Contoso, and then select "OK" to that. And you can see down the bottom here the commands that were actually used to perform that task in PowerShell are, "Set-ADUser," and it tells you the properties that I changed, and then "Rename-ADObject," and the properties that I changed. Likewise, were I to create an object, be it a user account, or a group account, or an organizational unit, whatever it is, that would also be detailed down here. And then there's nothing stopping me from copying that information into a text file and then working on it and taking the general, or sorry, the specific details and generalizing those. It's even possible, of course, to, as you can do with any PowerShell-type command, just read in content from a text file. So if you wanted, you could use a CSV file as the basis for creating these sorts of objects using either the Active Directory Administrative Center, but also by using PowerShell. In the demonstration, you learned how to manage OUs, how to manage users, and also how to manage groups. What are Group Managed Service Accounts? Service accounts are configured to work with several services and interact with the operating system. There are several types, Local System, Local Service, and Network Service, and you can use any or all of those depending on your particular needs. A Group Managed Service Account is a service account managed by the domain. One of the problems with service accounts is that if you change the password for a service account, which is a pretty good idea, otherwise it represents a security risk, you have to remember to reconfigure the service that's been configured to use that service account and update its password on the service's property page. Using Group Managed Service Accounts doesn't have the same requirement because the domain manages the password for the account and deals with that complexity for you. It therefore makes it an inherently more secure way of configuring services. To create gMSAs, you start off by creating a Key Distribution Services Root Key, use PowerShell's Add-KdsRootKey cmdlet to do that. Next, you create accounts using the New-ADServiceAccount cmdlet. And then finally, you'll install the account on a specific server using the Install-ADServiceAccount cmdlet. The Active Directory Recycle Bin is something that you should consider enabling. Once you've done this, you can't turn it off, but it does give you the significant benefit of being able to easily recover things that you inadvertently delete, such as a user account, a group account, or even an organizational unit. You typically enable the AD Recycle Bin by using the Active Directory Administrative Center. If you don't enable the Active Directory Recycle Bin and you delete something like an OU or a user, you'll need to perform an Authoritative Restore of Active Directory. So when you perform an Authoritative Restore, you recover an item that would ordinarily be overwritten by Active Directory replication. So if you've got a couple of domain controllers, you delete a user account, that's replicated to the other instances of the domain controller. If you perform a restore of the object, it'll be deleted again through Active Directory replication. You'll need to perform an Authoritative Restore when you haven't enabled the Active Directory Recycle Bin, or the object you want to restore was deleted before you enabled the Active Directory Recycle Bin, or you must restore items older than the tombstone lifetime of the Active Directory database.