Administer Active Directory Domain Services

0:00Active Directory Domain Services is the foundation of every Windows-based network. It provides us with the tools and technologies used to identify, authenticate, and manage network based resources. Let's take a closer look at what we're going to be covering in this skill. [MUSIC PLAYING] I like to think of Active Directory as one big database. It's a database that stores network objects such as users and computers. These are objects that require identity, and also will require authentication when accessing other network-based resources, such as printers, and files.

0:40Now do note that there are no new features for Active Directory in server 2019. We know that because we didn't receive a new domain or forest functional level, which dictates the feature set that Active Directory will use. Our max level, even in server 2019, server 2016. So that's a telltale sign that we have no features. So this skill is more on the essential side here of our server 2019 essentials course. So here's what we're going to be covering in this skill. We're going to start within Active Directory Domain Services overview, to get familiar with its purpose and also all the major components.

1:15Forest, domain, sites, domain controllers, and global catalogs. From there, we'll look at how to install and configure domain controllers. We'll look at how to install a second domain controller into an existing domain, and we'll look at how to configure a domain controller as a global catalog server. From there, we'll look at the many ways and tools used to create users and groups, the two primary objects in Active Directory Domain Services. From there, we will look at organizational units, or OUs for short. We'll define the purpose for them.

1:45We'll look at how to design a proper OU hierarchy. And then, we'll look at how to create and utilize them. We'll also take a good look at designing groups, and assigning permissions to them. We'll cover all of our group scopes, and implement some best practices for doing so. We'll wrap this skill up by looking at some common Active Directory Management tasks. Again, some more best practices to make your day to day life easier managing Active Directory Domain Services. Our virtual lab environment for this skill consists of four machines. We have ADMIN-NUG, our client machine and management box.

2:17We have DC-NUG, which is already a domain controller hosting the NuggetLab.Com domain. We have DC2-NUG, which right now is just a regular old server core machine. So we're going to take a look at how to add a second domain controller into our environment. That will also give us the opportunity to perform management tasks between them. And we also have a file server, with all kinds of data on it we'll be using to work with permissions. So that's our virtual lab environment, and our plan for learning all about Active Directory Domain Services. It's a critical skill for system administrators.

2:50Let's get learning all about it. I hope this has been informative for you, and I'd like to thank you for viewing.

0:00What is Active Directory Domain Services? And what are the components that make it what it is? Those are the questions will be answering in this Nugget. [MUSIC PLAYING] Fun fact, did you know that Active Directory Domain Services was initially released back in Windows Server 2000? Making it over 20 years old. And another fun fact, over 90% of Fortune 1,000 companies implement Active Directory Domain Services. The whole point of it is to provide our organizations with centralized management and authentication of network based objects, things like users, computers, printers, and files.

0:40Let's go over the many components that make up in ADDS infrastructure, starting at the top with forests. Now, a forest forms a security boundary and really just acts as a logical container for domains. So here we have the Nugget Lab forest, which consists of three domains, nuggetlab.com, west.nuggetlab.com and east.nuggetlab.com. Speaking of domains, domains are very much like forests in that they act as a container. Forest contain domains. Domains contain our Active Directory objects, namely users and computers.

1:12Think about this. When you log into your computer and onto the network, what do we typically log into? A domain, right? And that's because a domain acts as a security boundary for all the resources within it, as opposed to a forest, which, again, acts as a security boundary for all the domains within it. Now, notice in our example here that we have three domains. We have nuggetlab.com, which is our parent domain. We also have west and east.nuggetlab.com, which are acting as child, or subdomains. So we have three distinct security boundaries here. And if we wanted users in one domain to access resources in another domain, for example, maybe we wanted west and east.nuggetlab.com to access resources in nuggetlab.com, which could be acting as headquarters, then we can set up domain trusts between them.

1:57And, by the way, you can also configure forest trusts for users to access resources across forests. Another ADDS component that I want to briefly touch on are sites. Now, think of domains and forests as logical boundaries. Sites are physical boundaries and are primarily used to control replication of our AD objects across physical locations. Here's an example. Let's say that headquarters, which is hosting nuggetlab.com, is physically located in the UK. And west and east.nuggetlab.com are across the pond, hosted in the USA.

2:32So we could set up sites here for these locations, which, again, will allow us to control, schedule, and dictate how replication of our Active Directory objects flows between these sites. Sites can contain multiple domains. But a domain cannot belong to more than one site. So those are all of the top level containers within an Active Directory infrastructure-- forest, domains, and sites. If we were to peer into a domain, we have what is arguably the most important object in all of Active Directory, the domain controller.

3:02The domain controller is a machine that has Active Directory Domain Services installed, was promoted to a domain controller, and hosts the Active Directory database containing all of Active Directory's objects. The primary Active Directory objects we're talking about here are users, groups, and computers, which we assign permissions to against resources on the network. Now, a domain controller can also be configured as a GC, a global catalog server. A global catalog server is responsible for authentication and handling Active Directory searches, as a GC will store a complete list of every active directory object and all their attributes within its own domain and a partial list of objects in other trusted domains.

3:47This can dramatically speed up searches for cross domain resources. But it can also have an impact on replication traffic across sites, which is why the default is a very small subset of attributes for each object. And those are the primary components that make up Active Directory Domain Services. Coming up next, we're going to get a hands on with domain controllers. I hope this has been informative for you, and I'd like to thank you for viewing.

0:00One domain controller in an Active Directory Infrastructure is never enough. It's a single point of failure. So if we were to lose that DC, our entire organization comes to a screeching halt. So that's why most organizations implement at least two domain controllers, for redundancy, but we also get the added benefit of load balancing. Let's take a look at how to install a second DC into an Active Directory Infrastructure. [MUSIC PLAYING] Let's get right to it.

0:32The first thing we need to do is install the Active Directory Domain Services role on to DC2-NUG, which right now is nothing on it and it's a Server Core machine. There's a number of ways we can do this. Of course, we can do it through Windows Admin Center, we can do it through Server Manager, or we can do it through PowerShell. We're going to go the Server Manager route here and walk through some wizards. You can see how they differ from installing your first domain controller into a brand new forest, which we did many skills ago, and I'll show you the PowerShell equivalence here along the way. So in Server Manager, we're going to head down to All Servers.

1:03There's DC2-NUG. All we need to do is give that a right-click and choose Add Roles and Features. We can accept the defaults for the first couple of screens here. And on the third screen, ensure that we're targeting DC2-NUG. We are. And on Server Roles, we're going to choose the second one here, Active Directory Domain Services. Notice here that because it's a Server Core machine, it's only going to install the PowerShell module for Active Directory, not any of the graphical tools, such as Active Directory Users and Computers, because it's a Server Core machine. So we're good here on Server Roles. We can hit Next. We'll accept the defaults here for everything else and then confirm and install.

1:37Once installation completes, we can promote this server to a domain controller, which will launch us into another wizard, the same one that we walked through many skills ago when we got DC-NUG up and running. But we're going to get some different options this time because we're not adding a new forest. We are adding a domain controller to an existing domain, and there is our nuggetlab.com domain. All we need to do here is provide credentials for doing so, so I'll just provide the domain administrator credentials here, and hit Next. For our Domain Controller Options, we're also going to turn this into a DNS server because we only have one running in our environment, which is hosted on our domain controller, so this will get rid of that single point of failure as well.

2:16We're also going to turn this into a Global Catalog Server. Now, a Global Catalog Server handles Authentication requests and Active Directory Search requests. So this will help out with the load balancing piece, but I'm going to turn this off in the wizard, so I can show you how to turn it on outside of the wizard using Active Directory tools Also notice that we could turn this into a read-only domain controller. Now, RODCs do not store passwords locally. Only writable domain controllers do that. So this is a great option when you need a domain controller in a remote location, such as a branch office, but you don't trust the physical security at that office.

2:52Because if somebody were to get into this or steal this domain controller, it would be worthless, since those passwords aren't stored. All right, we're good with this screen. Let's enter in our Directory Services Restore password. I'll just use the lab password a few times here and hit Next. We can safely ignore DNS options here, as DNS delegation doesn't apply to our environment. For Additional Options-- this is a screen you do not get when you install your first domain controller into a forest. We have a couple of them here. First up, Install for Media. This also applies to that branch office scenario.

3:23Let's say, for example, that our branch office is on the West Coast. We'll say Los Angeles. And our primary site, HQ, is in New York City. And we've got a slow WAN link here between these domain controllers, and we've got a massive Active Directory Infrastructure. Well, if we were to just install this without Install for Media, that could take months, if at all possible, to replicate your entire Active Directory Infrastructure over that WAN link. So what we do, prior to running this wizard and installing a domain controller here at a branch office location, is run the NTDS utility to essentially export our Active Directory Infrastructure, all of that data, all those objects, out to a flat file.

4:07We can then take that file, ship it over to our branch office location, where we can then check this box, browse to it, and, that way, it will load all of that data up from that flat file rather than over the slow link. So checking this box will allow you to enter in a path to that data generated by NTDSUtil. We can also choose where to replicate from, where are we going to receive all of this Active Directory data from. Any domain controller or a specific domain controller. This is also, again, useful when you have many domain controllers spread across multiple sites.

4:41You can obviously here choose one that is closest to your domain controller that you're bringing up. We're good here with the defaults, since we only have one other domain controller in our environment, so we'll hit Next. Everything else throughout this wizard is the same as the initial wizard when installing your first domain controller, so we'll hit Next. I do want to point out here, though, on Review Options, we can hit View Script, and here it is. A one-liner in PowerShell to do everything we just did in the wizard. Install ADDS Domain Controller specifying some of the options here, all the same options we just walked through, and that'll easily allow you to automate bringing up multiple domain controllers.

5:15So we're good here. We'll go and head next. This will run through a prerequisite check, and then we can hit Install, and there we are, good to go. A few minutes later, and we now have a second domain controller in our environment. Now let's configure DC2 as a Global Catalog Server and also verify that everything is properly in place. We'll do this here, again, in Server Manager. If we drop down the Tools menu, we have all kinds of Active Directory tools in here. We'll be using some of these throughout this skill. But the first one I want to go into here is Active Directory Users and Computers.

5:48What we want to do here is head down to Domain Controllers and just verify that we have two DCs. We do. But notice here the DC Type. We only have one, Global Catalog. DC2-NUG is just a regular old DC. And how we can change that is by, again, heading into Tools here and heading down to Active Directory Sites and Services, which is a tool that you generally use to manage your site's subnets and replication. But we can also configure a global catalog through here. So if we expand Sites, head down to Default-First-Name-Site, expand Servers, there are both of our domain controllers, and we want to expand DC2-NUG and then give NTDS settings here a right-click and head into Properties.

6:28There it is. All we need do is check that box and hit OK, and it's now a global catalog server. If we head back in to Active Directory Users and Computers and give this a refresh, they should now both say GC rather than DC. Another thing we should verify here is DNS. If we drop down the Tools menu here, let's fire up the DNS Management Console, and we also need to connect here to DC2-NUG. If this was properly configured, what we should see here is exactly what we saw over on DC-NUG.

7:00Look at that. There's nuggetlab.com. There's our testing.com that we created in a previous skill, and, look, all of our records made it over. And also notice here that we now have to name server records, one for DC-NUG and one for DC2-NUG. Another thing you'll want to do here is if you're utilizing DHCP, to ensure that DC2-NUG gets set up as a secondary DNS server. And if you're not using DHCP, which actually turned our management box back here to a static IP, then we can configure it manually. Lets do that. I'll head into Network Connections, Change Adapter Options.

7:34We'll head into the Properties of our network adapter, into IPv4, and down here it is 192.168.1.102. And now, we have 2 DNS servers configured. Now, one more true test here. What if we completely shut down DC-NUG? Think everything in our environment still going to work? It should, right? Let's test it out. So over on DC-NUG here, I'm just going to shut it completely down and give it a minute here to power all the way down. All right, it's all the way power down.

8:04Now let's head back to Admin-NUG. I'm going to go ahead and log off of this machine. All right, now we can sign back in, and this should work just fine. Hey, look at that, we're on. Without any domain controller, we wouldn't have been able to do that. Let's also verify here in Server Manager by bringing up Active Directory Users and Computers. And notice here that we are in Active Directory. I'm just going to push this bar to the right just to show you here. Look at the top. We are connected to DC2-NUG.

8:36That's how it's done. No more single points of failure and load balancing for Authentication and Active Directory Searches. I hope this has been informative for you, and I'd like to thank you for viewing.

0:00Users and groups-- the primary objects in Active Directory Domain Services and a data responsibility for system administrators. In this Nugget, we're going to take a look at the many ways that we can create and work with them. Here we are on the desktop of our Windows 10 management box, ADMIN-NUG. Now, I've already launched many of the tools that we'll be working with in this Nugget, including Windows Admin Center, Server Manager, and the PowerShell Integrated Scripting Environment.

0:31Let's actually start in Server Manager. There's a couple of tools that we can access through here. One of them is the old school ADUC, Active Directory Users and Computers. And the other is the newer school, ADAC, Active Directory Administrative Center. Let's actually start here in ADUC, because this tool has been around forever. It's tried and true. And it's really easy to work with. This will default us into the Users node, which will show us all the users and groups in our Active Directory infrastructure. And you can see, we only have two users. One of them is disabled, the Guest account. And the other one is what we've been using this entire course, the Administrator account.

1:04All the rest of these are groups. Now, let's say that we wanted to create a user. We can simply right click on the Users node and choose New User. This will pop open a dialogue and allow us to fill out some very basic information about our user. Let's create the user. How about John Smith? So we fill in their first and last name. Now we can provide them with a logon name, otherwise known as the sAMAccountName. You'll see where that matters here when we begin automating this with PowerShell. But this is what they will use to log into their machine with. So john.smith will be his user name.

1:36We'll hit Next, and we can provide some information here about their account. First up, we need to give them a password. So I'll just enter in the lab password a few times here. And then we have some options around their account here. We're going to force them to change their password the first time they log in. And we'll leave the rest of these at their defaults. We'll go ahead and hit Next, Finish. And that's it. We created user John Smith. Now let's give that new user a right click and head into Properties. This allows us to fill in much more detailed information about this user, general information, address information.

2:08We have more control over their account here including when they're allowed to log into our network and what they're allowed to log in to. We also have some more account options down here. We can configure their user profile, point them to a network share, their home folder, as well as connect them to a specific network drive. We can configure telephone numbers and more organizational information. Let's also take a look at how to create a group. We'll come back to users here in a little bit. If we right click on a user's node and choose New, there it is, Group.

2:38This will pop open another dialog where we can give our group a name, specify its scope, and its type. Now let's say that John is a developer in the IT department. And he's going to be a member of this group along with all the other developers. So let's give this group the name IT Developers. Now, the type 99% of the time is going to be Security. Security groups we can associate with permissions. Distribution groups you cannot associate with permissions. And they're useful for mailing lists when you're implementing something like Exchange in your environment.

3:11Scope, on the other hand, is the important one. These really determine two things, both of which relate to, well, as the name implies here, scope-- number one, where these groups can be assigned permissions in, either the same domain with domain local, any domain with global, or any domain or any forest with universal; and number two, what types of members they can include it where those members exist. Members, by the way, is a term that describes both user accounts and groups, because groups can contain other groups.

3:44Now, this can all get very confusing and convoluted quickly, which is why years ago Microsoft laid out best practices for designing groups and assigning permissions to them. It's a process known as AGDLP. And we're going to get much deeper into it in our Nugget on permissions. For now, though, let's keep it simple. And we're actually covering the first two steps, the A and the G, which is create your accounts and then add your accounts into global groups, and also why this is the default selection when creating groups. So we're going to create a global group here and assign our user to it, which we can easily do here by either heading into our group or heading into our user.

4:21It's easier here if we just head into our group. We open that up. We hit Members. We add our member in. And now we can browse Active Directory. I'll just start typing in John, hit Check Names. And that'll resolve it. And look at that. John Smith is now a member of our IT Developers global group. Moving on, let's take a look at another tool that you can use to create users and groups and manage Active Directory. Back in Server Manager, if we drop down the Tools menu, it's the first entry in the list here, Active Directory Administrative Center. And this tool is really nice because it's more modern.

4:51It looks and feels exactly like Server Manager. It's highly customizable. And it's built on top of PowerShell. So everything we doing here is just executing PowerShell commandlets under the hood, which is a great way to learn all of those Active Directory PowerShell commandlets. It also wraps some very common operations here on the Overview page, such as resetting users' passwords when they forget them and performing a global search against all the objects here in Active Directory. Let's say that we wanted to create a user. We could hit nuggetlab here.

5:21And look at that-- looks familiar. These are all the nodes that we saw back in Active Directory, users and computers. And over here on the right here, we have our tasks. We can hit New, for example, and create a new user. It'll pop open our new user dialog where we can begin filling out this information. And if you use this a lot, again, you can customize this. You can drop sections down here. And we can turn off all the things that we don't use to simplify our view. Let's create another user here. How about old Joe Smith? And you'll notice here that we get some nice visuals indicating required field with that big red splat.

5:55And they dim out when those requirements have been met. We also need to provide the user logon name here, the sAMAccountName, which is going to be joe.smith. And that's it-- no more required fields here. But if we head down to Member Of, we can hit Add. And since we already have that group created, we could type in IT, hit Check Names. And there is our IT Developers group. This will create the user and add him in to that group. So we can now see our user right there. And also if we bring up our PowerShell history, we can see that it used the New-ADUser commandlet. And those are all the parameters that were supplied to create that user under the hood-- so a fantastic tool here in Active Directory Administrative Center.

6:33But let's crank it up a notch and head into the Integrated Scripting Environment where I've got a script opened up and ready to go. Now, if you're following along, just hit that Open button on the toolbar. It'll plant you into the Nuggetlab directory where you can also open this script. Now, to create an individual user, as we just saw over there in ADAC, we utilize the New-ADUser commandlet. Here we're going to create the user Jane Smith by passing in some information about her-- first name, last name, her sAMAccountName, which is her logon name. And optionally you're enabling the account and also supplying a default password.

7:05And notice because we're passing this in as plain text, we need to convert it to a secure string, as that is what the account password parameter expects. So I'm going to highlight this code here and execute it, which will create Jane Smith. And we can verify using either one of our tools here. If we head back into Users and Computers and give this a refresh, there is Jane Smith. And we're actually missing Joe Smith. And that's because when we created him over here, we created him in the root of our network infrastructure, our hierarchy here. So if I give that a right click and choose Move, we're going to move it down to Users.

7:36There we go. Now we should be able to see Joe in here with Jane and John-- perfect. All right, back to the Integrated Scripting Environment we go. So creating individual users, a breeze. We have lots of methods for doing so. But what if you had to create hundreds of users? Creating them individually by hand, just not something that we would want to do, because it would take a very long time. So let's say that we've got a data dump from our HR department in the form of a comma-separated file. In fact, I've got one here in the C drive in the Nuggetlab directory-- right there, ad-users.csv.

8:11Here it is. We've got close to 100 users here in this file. The very first row are column headers that describe the data below. So all we need to do is utilize a little bit of PowerShell here to import that file and then map those columns in that file to the parameters of the New-ADUser commandlet-- very simple here. We're running an import CSV referencing that file and piping that to a foreach loop, meaning for every single record row in that file minus the first one, the column headers there, it will run this commandlet.

8:43And that's all we're doing then is mapping the name of those columns in that file to the parameters inside of the New-ADUser commandlet. So I'm going to highlight all of this code and hit Execute. And that'll just take a minute to create all of those users in Active Directory. All right, that just finished up. If we head into Active Directory Users and Computers and give this a refresh, look at all those users. That is so much fun to do. Now let's drill into one of our users here by giving them a double click to open up their Property pages. And check it out. Just verify here that all that data made it over. We've got address information.

9:13We've even got information about the organization they belong to, including their department. So our users look good. Let's head back into the ISE and create some groups. We're going create six groups here using the New-ADGroup commandlet. And these groups are going to be modeled after the departments our users belong to. And these are all going to be global security groups. So I highlighted those six lines of code. We'll run them. That will create those six groups. Finally, our last step here-- because right now those groups are empty-- is to assign our users to those groups.

9:43And we're going to do that again by looping through that same file and using the Add-ADGroupMember commandlet, targeting a group based on the department-- that's the identity parameter-- and specifying which member we're placing into that group based on the sAMAccountName. So this will add the member into the group based on their department, which is the actual group itself. So we'll run that. It'll just take a second to complete. And when it's done, if we head back in Active Directory Users and Computers-- and I'll just give this a refresh here with F5 on the old keyboard-- and there it is.

10:14There's our group. There's the Executive group. Here's a Manufacturing group. If we open this up and look at members, we'll get all the members in that group. We could also look at, say, Research and Development. And we've got a handful of members in there as well as Sales and Marketing. We've got a handful of members in there as well. So we've got plenty of objects inside of our Active Directory infrastructure to play with for the Nuggets to come. But let's finish this Nugget up by taking a look at what we can do against Active Directory through Windows Admin Center. And the answer is, out of the box, not much. I actually did install the Active Directory extension into Windows Admin Center, which is currently in preview mode.

10:49So if we head to one of our domain controllers here-- and I'll just go ahead and choose dc-nug-- there is that extension right there, Active Directory. Once that loads up on the Overview tab here, we can perform a global search. So if we type in Smith here, we should see those three user accounts that we created. And we could choose them to perform some light management against them and also see some information about their account down below. You can also drop down the Create button here to create users, groups, and OUs here in Windows Admin Center. And finally, you can hit Browse here to navigate through the hierarchy of all the objects in Active Directory.

11:23So as you can see, we certainly have a lot of flexibility when it comes to creating users and groups. Which method you choose will depend on the scenario you're faced with and, of course, personal preference. I hope this has been informative for you, and I'd like to thank you for viewing.

0:00Organizational units an Active Directory serve two primary purposes-- one, group policy. It's how we can distribute group policy settings to different areas within our organization. And two, delegation. It's how we can delegate administrative duties to other members of our IT staff. Let's take a look at how to design and work with OUs. [MUSIC PLAYING] Organizational units themselves are just containers.

0:31They are containers for other objects-- users, computers, and groups. We design an organizational unit hierarchy and place these objects into it to, again, support group policy, delegation, and to a lesser extent, just organizing the objects in Active Directory. Now, how you design your hierarchy will depend on your organization. But the golden rule is always this-- keep it simple. Keeping it simple will make it much easier to manage group policy and delegation. Here's an example using a simple functional design.

1:04At the top of the hierarchy, we have an OU for accounts and for machines. And then we can further break them down and organize them accordingly. Under Accounts, we can have one for users and admins in services. And here we could even get more granular. Under Users, we could create an OU here for each department or each job role. It's a common strategy to model your OU design after your business units. We would do the same thing on the machine side, break it down by servers and workstations. And underneath Servers, we could have an OU for each type of server, and underneath Workstations for each type of PC.

1:37And we could even get more granular here by creating OUs for each specific type of operating system. So maybe we have one underneath laptops and desktops for Windows 8 and Windows 10. Now, once your hierarchy is in place and all of your Active Directory objects are in their respective OU, then you can start harnessing the power of delegation in group policy. On the delegation side, let's say that we've got to help desk staff out there and we've got a group called IT Help Desk. And we want to give them the ability to reset passwords on all the users in the organization.

2:09Well, we can just give that group the ability to do so on this OU, which will flow down to all of our OUs, whether we have them separated by job role or department. That will give them the ability to reset passwords for all the users in that OU and beneath it. We could also delegate control to members of our IT staff on the server side to give them the ability to do things like reboot servers. The other side of the OU coin is, of course, group policy. A policy is really just a collection of settings. We have settings for both users and computers, and there's thousands and thousands of settings that we can control.

2:45So we configure a group policy and link it to an organizational unit. And whatever OU that is linked to, and every OU underneath it, will receive those settings. So for example, say that we wanted to deliver the company wallpaper to all workstations in our environment. We would configure that setting, define our wallpaper, and it will link it to our Workstations OU, and everything underneath it would then receive that wallpaper. Again, we have a skill dedicated to group policy, so we'll look at how to do that and much more when we get there.

3:16But for now, let's head into the virtual lab and take a look at how to create OUs and configure delegation. Here we are in the desktop of our Windows 10 Management Box ADMIN-NUG, and we're going to do this through Active Directory Users and Computers, which we can quickly get into by right clicking on the Start button, heading up to Run, and typing in dsa.mse. Once inside, we can create an organizational unit by right clicking on our domain nuggetlab.com, heading down to New, and choosing Organizational Unit. And all we need to do here is just simply give it a name. So I'll call this one Accounts, and let's create another top level one here.

3:48So right click on nuggetlab.com, head down to New, Organizational Unit, and this time we'll call this one Machines. Now, if we wanted to create an OU within these, you guessed it. We would right click on that OU, hit New, and Organizational Unit. And let's create one here called Users. Oh, that was wrong. Uers. Easy enough to rename. There we go. All right. So I went ahead and created the remaining OUs. Next up is to get our users, computers, and groups into them. Let's start here with users. If we head over to Users, there's our administrator account.

4:19I'm going to drag that over to Admins. We'll get a little message. I'm going to say, you know what? Don't show me that message ever again. We'll hit Yes, and now our administrator account is in there. Also let's grab all of our users, which start up here. I'll do a Control-Shift-End to grab them all, and just drag them over to Users. That will add all 95 users into them. Let's also do the same with our groups there. We'll grab all those groups that we created-- there they are-- and drag them in to Users. Now let's do the same thing for our computers. Now we don't have to do this for our domain controllers.

4:50They already have an OU, as you can see by little visual notification on the icon there. So those are good. But we still have FS-NUG, our file servers. We can drag that down here to our file server. And we have an ADMIN-NUG, which is our management workstation. We'll say this is a desktop, and we'll drag that into there. One more thing I want to show you here is how to delegate control. You'll notice here that I've got a group called IT HelpDesk. Let's say that we want to give all the members of this group the ability to reset passwords for anybody in this Users OU.

5:21All you do is right click on this OU and hit Delegate Control, and this will walk us through a pretty simple wizard here. We choose Next. We specify which group or groups or users we wish to delegate control to. We're going to just start typing in IT and hit Check Names. There it is-- IT HelpDesk. Now we hit Next. And here we go. We can delegate common tasks or we can create our own custom task. Let's just choose the second one here, Reset User Passwords, and force them to change at next log on. We hit Next. That's the end of the wizard, and now all the members of this group have the ability through Active Directory to reset passwords for any user inside of this OU.

5:58Good stuff. Just remember, when it comes to organizational units, keep your hierarchy simple. The more complex it becomes, the more difficult it will become to manage both delegation and group policy. I hope this has been informative for you, and I'd like to thank you for viewing.

0:00Permissions determine what resources our users can access and what kind of actions they can perform against them. In this Nugget, we're going to take a closer look at groups and implement a best practice for assigning permissions against them. [MUSIC PLAYING] AGDLP, we talked about it a few Nuggets ago briefly. It is a best practice for designing groups and assigning permissions to them to grant users in those groups access to resources on the network.

0:33This is a really solid best practice to follow, because if we don't and we start assigning permissions like the wild, wild west to users and global groups, things can get very messy very quickly. Now, before we jump into AGDLP, let's take a quick refresher of the three group scopes available to us. The first thing to note is that all three of these group scopes can contain user and computer accounts and also groups depending on the scope. Domain Local Group, for example, can contain global groups from the same domain and universal groups.

1:06And it's best to think of these as permission groups. This is what we want to assign permissions to. Global groups can contain other global groups from the same domain. And it's best to think of these as role groups. We create these based on our business model, either job roles or departments. Finally, we have universal groups. These can contain global groups from any domain in the forest as well as other universal groups and these are best utilized in a multi-domain environment.

1:36More on universal groups in a little bit when we talk about AGUDLP. But first, let's talk about this best practice known as AGDLP. Remember, A stands for Accounts. And it represents our individual user and computer accounts. G stands for Global Groups. And again, we modeled these after job roles or departments, and we place our users directly into them. DL stands for Domain Local Group. These groups have visibility in the current domain.

2:09And this is what we place our global groups into, and the P, assign Permissions to resources against. Now, let's highlight the benefits of this model by looking at a real world example. And in order to do that, we need some context here. So let's say that we create a global group called Sales. And we add all of our sales users into that global group. Now, our goal here is to provide our sales users with the ability to print to this printer and have read/write access to the sales share on this file server.

2:40So what we would need is two domain local groups. One we'll call RW, for read-write Sales Share. And another for printing to the printer, which will just call P, printer. So what we would do then is, again, assign those permissions to these domain local groups. So we give print permission to the P printer domain local group and read-write permission to the Sales Share. Now, all we need to do is add our sales users directly into those domain local groups.

3:11Here's why this model is awesome and extremely efficient. Let's say that we're constantly hiring new sales folks into the organization. All we need to do is create their user account, add them into that Sales global group and, voila, they automatically inherit all of the permissions that we assigned to those domain local groups. Another reason this is awesome and another reason why we don't assign permissions here at the global group level is let's say that marketing, quality assurance, production, all these other departments needed access to the printer. All we would do is add those global groups into this domain local group and they would be able to access that printer, which results in one permission that we assign to this domain local group, rather than the many permissions that we would need to assign to all of those global groups.

3:55So the end result-- this model results in a clean separation and less permissions to assign and manage. Now, let's add U into the mix, which, again, stands for Universal Groups. And this is useful in multi-domain environments when we need to grant users access to resources across domains. Here's the setup. On the left, let's say that we have west.nuggetlab.com. And on the right, we have east.nuggetlab.com. Let's say that we have some executive sales users that need access to all the sales resources across both of these domains.

4:32This is where universal groups come into play. So how this works is just like before, we have accounts. So let's say that we've got a western regional sales manager here and a eastern regional sales manager here. We add them into their respective global groups. But rather than add these global groups in the domain local groups, we add them into universal groups. We then add these universal groups into domain local groups, which will then give them access to all the sales resources in both domains. What's cool about this is that our sales managers will not need their own accounts in every domain, just in their source domain as they will automatically have access to those resources again through that universal group membership.

5:14What's not cool about this is universal groups are stored in the global catalog. So any changes made to them are replicated around, which can impact replication traffic across our domains and our forests. All right, with that, let's jump into the virtual lab and test out AGDLP. Here we are on our Windows 10 management box once again, ADMIN-NUG. Now, I've already launched the tools we're going to be working with here-- Server Manager and Active Directory Users and Computers. Let's actually start in Server Manager because what we're going to do is create a share that we're going to provide our sales users with access to.

5:46So the exact scenario that we ran through there on the whiteboard. In Server Manager, we'll head down to File and Storage Services and into Shares. From here we'll drop down Tasks and choose to create a new share. We're going to create a quick SMB share. Our location here is going to be over on FS NUG. We'll hit Type of custom path and browse through the F drive over there, where we have all kinds of folders. And let's create a share here on top of the sales folder in the F drive, which has a little bit of data inside of it. We'll keep the defaults here. The name of the share will be sales, which maps to the F colon backslash sales folder on that local machine.

6:20And this is how we will access it remotely through the UNC name. So we'll hit Next here. We'll accept the defaults here for other settings. And for now, we're going to accept the default for permissions. We'll come back into this once we get our domain local group set up and configured. So I'll hit Create. And now, we have a share ready to go. All right, our next step is to head into Active Directory Users and Computers and create a domain local group. Remember, a few Nuggets ago, we already created our global group. In fact, if we expand our Accounts OU and head into Users, there is our Sales and Marketing global group.

6:53And if we open this up and head into Members, you can see we've got three members. And we're going to need to test all of this out with one of these members to ensure they have access to that share. So we've got our global group in place. We've got our members added to it. Now, we just need a domain local group. So we'll right click on a user's OU, head over to New and down to Group. This is going to be a domain local group. And we will call this RW Sales Share, like so. Perfect. We hit OK. And now what's the next step? You guessed it. We're going to add Sales and Marketing into this domain local group.

7:25So we'll open it up, hit Members, hit Add. And now I'll just start typing in sales. We'll hit Check Names. There it is. And now, we've added our global group into this domain local group. Now, our final step is to assign read-write permissions to this domain local group onto that share. So let's head back into Server Manager, give that share a right click and head into Properties. And look at that, we can head right back into Permissions here and hit Customized permissions. Now, there's two kinds of permissions. We have permissions on the folder itself and share permissions.

7:56The best way to go about this is just leave share permissions alone, allow everyone full control. That way we only have to manage permissions in one spot. And Windows only really checks them in one spot. Now, what we're going to do is Disable inheritance. And we're going to remove all inherited permissions. So this is a good thing to do to start from scratch, because if we didn't do this, everybody would still have permission to share through those inherited permissions. So the only people that have permissions to this right now are administrators, local administrators, on that machine.

8:27We're going to hit the Add button here and Select a principal. From here, I'll start typing in RW for our domain local group. And look at that, RW Sales Share. And we're going to give them read and write as well as list folder contents and read and execute permissions against that share. There's some other things you can do in this dialogue as well. Look at more granular permissions. You can also add conditions. And you can choose what this applies to. We'll stick with all the defaults for now. And hit OK. And now, that domain local group has read, write, and execute permissions against this folder and any other folders that will eventually be created inside of the share.

9:02And that's it. We hit OK. And now, we're ready to test. Now, there's a number of ways that we could test this out. We can log out and log in as that user. But that's somewhat timely. A much easier way of doing this is just mapping a drive using those user's credentials. So what we're going to do here is right click on this PC in File Explorer and choose to map a network drive. We're going to check this box right here to connect using different credentials. We'll map this to the Z drive. And the folder will be fs-nug backslash sales.

9:32Now, the user we're going to use here is the Kevin account. And I know his login name is kevin0 and the password is the lab password. We hit OK. And if permissions are applied appropriately, we're not only going to be able to get into this folder, but we're also going to be able to create folders-- look at that, we created a folder-- and create files either in the root there or inside of this folder, because permissions are being applied to objects and sub-objects within this folder. We can create files. We can write to them.

10:03We can do everything that our permissions set grants us. Now, let's test this out as a user that isn't a member of this group. Let's just pick one here. How about Candy? I'm going to open up her profile. Her login name here, if we had over to Accounts, should be candy0. It is. So we'll be able to log in using candy0. And what we're going to need to do here is actually disconnect this drive entirely. So I'll give it a right click. And we'll choose to disconnect. Now, if it doesn't disappear from your left-hand nav, no worries. It has actually gone. And you can click on this PC and scroll down just to verify that it's gone.

10:35And you can also click on it to verify that it is gone. So all we need to do is right click on this PC again. And let's map another network drive. We'll map the exact same one here, connect using different credentials, and over to the fs-nug backslash sales. There we go. We'll hit Finish. And this time we'll enter in candy0. Again, same password here, lab password. We hit OK. It's going to open it up and say, oh, you do not have permission to access this folder. AGDLP, we should make a song or a chant about it, because it's awesome.

11:07And if you live by it, group and permission management will be a breeze in Active Directory. I hope this has been informative for you, and I'd like to thank you for viewing.

0:00Managing Active Directory is a big responsibility, especially for domain administrators who are responsible for, well, all of it-- the health, the state, and the structure. In this Nugget, we're going to take a look at some of those common management tests you'll be performing to keep Active Directory running smoothly. [MUSIC PLAYING] Let's get right to it and begin in Active Directory Users and Computers. Then we'll move on over to the PowerShell Integrated Scripting Environment, because automation and PowerShell really is the name of the game, especially when it comes to Active Directory Management.

0:37Management task number one, and arguably the most important for a domain administrator, is delegation. And I know we've talked about delegation back in our Nugget on organizational units, but let's hammer it home with a bigger example. Let's say that we are the domain administrator for nuggetlab.com-- a multi-site organization. We've got west.nuggetlab.com and east.nuggetlab.com with many sites underneath. Maybe we've got Los Angeles, and Las Vegas, and Seattle. We've got New York City, Atlanta, and Miami.

1:09And underneath these, we have branch office locations. Could you imagine being responsible for all of these objects across all of these sites? No, it would be more than a full-time job. So that's why as a domain administrator we would create organizational units to model this hierarchy. And then delegate responsibility to our site admins, who would then delegate responsibility to branch office admins, who would then delegate responsibility to help desk and desktop support, and anyone else who we could pass a chunk of Active Directory off to.

1:40The best part about it is once you have your hierarchy in place, it's really easy to delegate administrative duties to members of your IT staff. As we saw back in our OU Nugget, we just simply walk through the delegation of Control Wizard to determine which users and groups can perform which actions in Active Directory. Management task number two, keeping Active Directory clean. This is one of those areas that can snowball really quickly. So it's good to get a strategy and policy in place as soon as possible so you don't have to deal with a cluttered up Active Directory.

2:11Here's an example, I like to actually keep groups separate from users. So here's where we can use OUs for just simply organizational purposes. So I'm going to create a new OU here. And I'm going to call it Groups. And what I'm going to do then is drag these groups out of this user's OU and place it right into that group OU. And we've also got another group down here that we created, our IT Help Desk group. And I'll drag that over there as well. This, again, gives us nice, clean separation of the objects in Active Directory. Management task number three, use a naming convention for all of your objects in Active Directory, especially users and groups.

2:48This is another important one because it makes finding things, especially in large directories, much easier. And it just keeps people sane. And this is also something that you want to train or even come up with a policy for your Active Directory staff to follow when creating or renaming objects. Let me show you a couple of examples here. Let's take Candy Spoon as an example. Now notice that her user name and her email here is candy0. That's not a good naming convention. Typical ones for users are first letter of first name, dot, last name.

3:19Or just first name, dot, last name. In fact, we can head over to our account here and change this to candy.spoon. And we can do the same thing up here for the login name, candy.spoon@nuggetlab.com. And we can do the same thing over here in general, candy.spoon. There we go, that's a much better looking naming convention, and pretty standard here for users. And we can easily write just a little PowerShell script to change all of these in one fell swoop. We could implement something similar to this with groups as well.

3:49A common naming convention here is department, plus resource, plus permission, plus group scope. Here's an example, let's say this is our sales and marketing group that has read/write permission to our sales share. So we can go SalesMarketing-SalesShare-RW-DL. This will make it so much easier for us to find things in Active Directory based on this four part naming convention. Moving on, let's take this the rest of the way in the PowerShell Integrated Scripting Environment and start here with some Domain Controller Management.

4:22A common thing for domain administrators to do is, again, monitor the health and replication status of all the DCs in our environment. The first tool here is a command line utility called dcdiag. And here we're using the S Switch to target a specific domain controller, dc2nug. This will just simply run through all of the components in Active Directory and output their status. And what it will do is just run tests against them. So you'll want to see a bunch of passed in here. If you see any failures, pay attention to the error message and you can begin your troubleshooting journey by checking the Active Directory Event logs on that machine.

4:57This should always be your first stop when Active Directory begins slowing down or acting funny, just to verify that all those underlying components are working properly. Another great tool for domain administrators here is repadmin, which allows us to monitor the replication status. And you can even use this to kick off replication for the entire directory or for individual objects. But we can use repadmin / showrepl to show the last replication event. So this will show us the success or failure of that event. And you can see that we're in good shape here in our environment.

5:29We can also get a replsummary, which will show us any failures that have occurred during replication. Another good one here when you have multiple domain controllers in your environment and you need to verify if replication is or is not an issue. Now some common management tasks we can perform in PowerShell are account management and group management. Specifically here with accounts, we can use PowerShell to find disabled accounts, inactive accounts, which are accounts that have not logged in within a specific time period, as well as find accounts with password issues. Here's a good example of finding disabled accounts.

6:01We've got a couple of disabled accounts here in the guest account and Joe Smith. We can find inactive accounts, which we haven't logged in with any of those users we imported, which is why they're all going to show up as inactive. But they would fall off this list if we were to log in to a machine with them. And we can find accounts here with password issues, any passwords that are expired, or any accounts that are locked out. All common things that happen in Active Directory on a daily basis. And finally here we can use PowerShell to easily view group membership. To Get-ADGroup passing in a group and piping the results of that over to Get- ADGroupMemeber, will show us all of the members associated with the group.

6:38So there are the three members that are inside of the sales and marketing group. And we can also use this to view groups that a member belongs to. So if we want to see all the groups that the built-in administrator account belongs, this will show them. We can also see what groups Candy belongs to. And we renamed her, which is why Candy0 doesn't work. It's now Candy.spoon. And if we were to run this again, this time we can see that she's a member of both domain users and executive. There's a handful of some of the most common tasks you'll be faced with when managing Active Directory.

7:11Until next time, I hope this has been informative for you and I'd like to thank you for viewing.