Active Directory Administrative Center

0:00All right, so as we get started in this particular course, I want to point out first of all that this, as well as a few others that I have not recorded yet, are going to be add-ons to the original core material. That course is called Windows Server Administration Core Infrastructure for Enterprise IT. Yes, it's a long title and I had to look off screen to remember how to say the whole thing. I'll try to remember to link that down below here somewhere. The reason why I bring this up is because this whole course, starting with the core course that I just mentioned, is designed to bring someone from a beginning level of a server administration into a little bit of a higher level.

0:39So maybe, for example, you've been working the help desk for a while, you're kind of ready to get off the help desk, but you don't have a lot of server experience yet. Well, that's what this course is for, okay? So that core course is for you. And then this course, which revolves more around Active Directory topics, is going to get you a long way towards server administration. So again, I want to point out that these are all fundamentals. And even though everyone talks about the cloud and AI and everything going in that direction, you're always going to have some degree of local servers to administer.

1:17I just don't see a way around that. And even if you do move mostly towards the cloud, those servers are also very often going to be Windows Server 2025 or whatever the next version of server is. So fundamental knowledge about servers is going to be critical to all of that and on-premises or not on-premises, okay? So that having been said, let's move here into the first portion of this particular course, which is going to revolve around Active Directory Administrative Center.

1:49So how do you actually get to that and what's it used for? Well, it's primarily used to manage the objects within Active Directory. It is largely a replacement for Active Directory Users and Computers or ADUC or ADUC, as we sometimes call it as well. And you can still use that by the way. That's kind of the old school MMC-based tool that we would use. Actually, I'll show it to you. It's pinned right down here on my taskbar area. And this is what the original looked like. Now, also I'll point out that in the original core course that I mentioned earlier, we talked about this a little bit already, okay?

2:23But I'm kind of reestablishing some context here in case you haven't seen that course or you don't really even want to go into that course. I still recommend it. But if you want to just jump right in here to the Active Directory stuff, well, here we are, okay? So this is how I used to administer Active Directory for decades, okay? Active Directory Users and Computers. In fact, maybe it's my age. Maybe I'm a little resistant to change like a lot of other folks are. So moving over to Active Directory Administrative Center, I'll use it sometimes and sometimes I won't, okay?

2:57Sometimes I just kind of still gravitate back towards this old method right here. And so if you wanted to edit a user, for example, you double-click on it, you get this kind of tabbed interface and everything. And the whole thing, you know, the MMC console whole UI and way of doing things is a little bit year 2000-ish, okay? Which makes sense because that's when Windows, as we currently know it, came out anyway. However, we want to move on into more modern ways of doing things.

3:27So with that, we'll move into Active Directory Administrative Center. And, you know, Microsoft has changed a lot of different things, including even their Start menu here. So you just aren't going to find it right here when you first click the Start menu. You're going to need to go to All and then you can go down here to Windows Tools, okay? Once you're in that, it really just opens up this window and there it is, Active Directory Administrative Center. Which I've also pinned to my taskbar area. You can see it's already down there. Otherwise, it would say Pin To, but I have the option to unpin it.

4:00So anyway, it's already there. And I will point out, even though Microsoft calls this the more modern way of doing things and, you know, a little bit more up-to-date and all, it's actually been around for several years. And this is my opinion. Microsoft has never been known for the best UIs. That's why we have the macOS, okay? And a lot of the Linux operating systems as well have really appealing and easy-to-navigate UI nowadays. But Microsoft still has whatever this is, okay?

4:33Now, apart from that little minor jab against Microsoft for their UIs, let's get a look at this and what it is. And it is still a value. I don't mean to put it down entirely. So we start off with the Overview page here. And the first thing that we have here is a little tile that says Learn More. And these are just links to different places you can go to learn more about different functions within this particular tool. So if you're just trying to access some more information, that's where you would want to go. But most of what we'll be doing is really over here on the left.

5:04Now, also I'll point out, yours is not going to look like mine if you have one already. So by the way, we'll have a Playground Lab attached to this particular course, which is just a couple of servers, a couple of clients. And you can use that to poke around in here, administer something, figure something out. Just kind of, it's a playground, right? It's just a place for you to experiment on your own. And don't worry about breaking anything because all you have to do is to reset the lab and it'll go back to the way it was when you first started to work with it.

5:39I'll also include labs throughout this course in various parts so that you can get some hands-on experience there as well. Because you don't want to mess with this in a production environment. You want to be able to experiment with things and play around with things without an impact in the real world. Now, the other reason why mine might not look like yours is because most of what we'll see here, first of all, let me show you this. See these two little things you can click on? I don't even know what you would really call those. But we're currently in the list view. With the list view, it'll show you the most recently accessed portions of the UI that you have visited.

6:17There's not really a graceful way to reset this. You can delete a specific folder in I think it's app data folder. It's kind of clunky and awkward and you don't really just want to do that all the time. I thought about doing that here because I wanted to kind of start with a clean environment. But on the other hand, you're going to see this fill up as you use it anyway. The other thing you can do though is you can go over here to the tree view and that's a little bit more hierarchical in what you're accustomed to seeing. So here we're seeing a lot of the different same hierarchies you might see in Active Directory users and computers and stuff like that.

6:50Okay. So it might just be a little bit more familiar for you and something you might want to access that way. All right. So that is an introduction to how this whole thing works. If I click on, for example, the domain right here and I've only got one domain, but you may also have multiple domains in your environment. We also get a little bit of a hierarchy here. I just don't think it's as navigable as the tree view. But Microsoft seems to really like us to use this view. All right. So when we get into the next video, we'll start to explore some more specifics about this whole UI and how to make it work to your advantage.

0:00All right. So we got started in our last video by taking a look at Active Directory Administrative Center. We saw a little bit about the navigation basics there, but not a lot. We saw that we can open that from the Server Manager tools. Notice that I also did pin mine to the taskbar area because I expect to be able to use it a lot, and I don't want to have to fish for it every time I want to use it. You can also add navigation nodes for the various domains that you might have. So in a forested environment, this will be a little bit easier than Active Directory Users and Computers because the focus there is on a single domain, whereas in a forested environment with multiple domains, you have a little bit better navigability there.

0:38Now, I only have the one domain of nuggetlab.com for our particular labs and all of that stuff, so that's all we're going to really be working with here. You also have a couple of different views. First of all, there's the tree view for the basic containers themselves, organizational units, all the other containers, stuff like that. Then the default view here would be the one we saw in our previous video where it's a list view, and that's, again, also usable for just listing the objects. Now, it's a little bit of a six one, half dozen of the other. You pick whichever one you're more comfortable with, and there's not really a right answer to choose one or the other in every instance anyway.

1:15It depends on what kind of objects you're trying to access. We'll look at all this here in a moment. There's also the preview pane for the details. I will say this as well about ADAC as opposed to Active Directory Users and Computers, you get more information in the same screen, if you will, than you do with Active Directory Users and Computers. That's one of the things that's very useful in terms of making something more navigable is to just have more information.

1:47That's one of the good advantages there. You can also globally search across a forest, which again would include multiple other domains there. I'm going to go ahead and open up again Active Directory Administrative Center. Let's just take a look first of all. Now, again, remember all this stuff right up here is just educational. Let's just, if you want to go to Microsoft's web page about various things. But you can see right from the beginning here that we have more usability here because what do administrators frequently do? Well, frequently, we have to change somebody's password, don't we?

2:19They'll probably always be doing that, whether you're on a help desk, whether you're further up in IT. This is just stuff that we have to do all the time. I do find it interesting though, Microsoft did try to, when Active Directory first came out years ago, they tried to steer us all towards user principal names which look like e-mail addresses. So it might be phoenixusers01 at nuggetlab.com, phoenixusers08 at nuggetlab.com, something like that. Here, however, it seems like they just want you to use the old method here where you just enter in the flat name of the domain in the pre-Windows 2000 method.

2:58So it would be just like this, nuggetlab, backslash, and then the name of the user. Let's say phoenixusers08 here. Not case-sensitive, of course. So then I would just enter in the new password. This is just, again, an area where ADAC is very handy because it puts right to the beginning here, right in the first page that we access, the ability to do something like change that password without having to fish for that account. Because this account, it could be buried under five, six, 10 different organizational units in terms of its whole hierarchy.

3:33So it makes it a lot easier to navigate that way. Then you would just enter in the password and choose whether the user has to change the password of the next logon or not. If it's been locked, you can unlock the account. Mine hasn't been, so there's no sense in selecting that. It won't let me anyway. And then I simply click Apply. Bam, that's it. I didn't have to fish for the account. I didn't have to drill down through all kinds of hierarchies. It just does that right away right there. Also, this is a global search. Now, this again will help me to search an entire forest.

4:03Again, I only have the single domain, but imagine a organization that has a forest root and then, I don't know, six, eight, 10 different subdomains underneath that. They kind of branch out underneath it in a tree-like structure. Well, that's a lot of click-through to get to what you want to find. But I'm just looking for, let's say, a specific user account. Let's make a Tucson user 05 or 04 and press Enter. Bam, it just finds it right there. Again, prevents me from having to drill down through an entire hierarchy or to fish for the right domain, all that kind of stuff.

4:42And of course, from here, I have other options, which we're not gonna investigate all of this right now. I think most of those are pretty well self-explanatory, but there they all are regardless, okay? All right, so again, very, very handy way to be able to manage things like our accounts. Now, don't fear. If you do like to just kind of navigate your way through things, you can still do that. So if I expand this little arrow right here, click the little arrow right there, then it will give me the opportunity to expand out other things.

5:12So for example, I was at Phoenix Users. Now, since I was there recently, it pops up down here. Anything that I've accessed recently will show up down here. Tucson Users, Phoenix Users, and so forth. But if I have something else that I access frequently, like Phoenix Desktops, I don't actually have any right now, but if I did, I could pin that, and then now it'll appear right here, and it's a pinned item. Again, for easy access in the future. Oh, I guess I have desktops after all. I got four of them, in fact.

5:43If I want to unpin it, I simply click the little pin button again, and it unpins it, but it does still show up right here. Why? Because remember, it was used most recently. Now, a couple of other things I'll point out just briefly here, but we will get into that in a different course. It's also adjunct to this course, and that would be this dynamic access control and authentication. These are simply additional ways to secure your environment. So for example, the dynamic access control takes us way beyond just things like NTFS ACLs, access control lists, where you can give someone read access, change permissions, all the different kinds of permissions that you can apply there.

6:22Well, this takes it beyond that even, and allows you to say, yes, they can access it, but they also have to be a member of, I don't know, a certain department. So they have to be a member of IT, a member of HR, a member of sales, whatever. And one of the advantages of that as well is that you can create a security group for those users as well, like the sales users, all that kind of stuff. But sometimes we don't need to get that granular, or we want to just apply a specific property of a user's account for it to check against to see if they should access this.

6:57It has some similarities to simply creating a new security group and dropping the user in that security group, but it's a little bit more granular here as well. Now, let me go back to one of our users. Let me go to one of the Tucson users here, Tucson user seven, let's say. I don't know if you saw it, but just notice that as I parked here for just a moment, it popped up Tucson users right up here at the top of the list. Because again, I'm using it recently here. He's gonna ask a little summary. Most of the accounts that I've created here are just for lab purposes. So all of the details have not been filled out, like the office that they're in, or their email or webpage, all that kind of stuff.

7:32All right, I just filled in enough to create the accounts. By the way, these were all created in my previous course, the core, the server core course, using a script. And as you can see here, the only two actual requirements by the red little, I guess, mauve colored little asterisk right there are the full name of the user, which I have right there, and the SAM account name, which is another way to describe the domain backslash username, this whole format right here.

8:03And there you have that. But again, one of the efficiencies that we have here is that everything is, or not everything, but most things that we want to access are in the same UI right here, as opposed to something like ADUC, where we would have to click between various tabs and kind of fish for things a little bit more. Anyway, I'll leave that to you to further explore if you like. Notice another thing we have here is that there's a more information item that we see down here. And again, we get more granularity in all of these details down here.

8:34I tried to make the native view of this in a little bit bigger font as much as I can, but it is all just kind of famously very small. So I will zoom in whenever it makes sense to make it more visible. But again, so for example, here's the canonical name where it shows us kind of the breadcrumbs, if you will, to be able to access the location of that user using forward slashes. The alternative to that would be the distinguished name, which would name it something like OU equals Tucson users, OU equals Tucson, OU equals AZ, domain component equals com, and domain component equals Nugget Lab, that kind of stuff.

9:12Now, I haven't actually used this account. That's why it says it's never logged on. Let me try to find an account that has been logged on at one time or another, get a little bit better look at that. For that, I'll go into Phoenix. I think I've used my admin account recently here. So let's go to phoenixadmin01. And we can see here again, if I go down to more information, that yes, indeed, we have had more logons here. In fact, I've had 87 logons with this test account. When it was created, when it was modified, also we even have a bad password count, which by the way, if you have entered in the wrong password a couple of times, and then you log on and you say, oh, yeah, you know what?

9:50Now I remember the password. And you entered in correctly, then it clears this and resets it back to zero. So this will only show a number down at the bottom there if someone has logged in with the wrong path or tried to log on with the wrong password, and were never successful. Again, we also see additional details down here. I won't exhaust all of this. I'll just leave that to you. But you see a lot of the other additional items there that are also very handy, such as the SID, which is a unique identifier for each user account.

10:20Anytime I make a change to this account, it'll also change the update sequence number. This is how it is able to keep track of what's changed in an account or any other Active Directory object, and thereby can also synchronize it with other domain controllers that we have. So if another domain controller looks at this, and let's say that it's a current update sequence number was 12,000, what is that? No, 122,930. Then it will say, oh, well, this one's 934.

10:52Therefore it must be more current. So I'll need to pull down whatever has changed from this account, probably like a password change or group membership or something like that. So again, more data that we can work with, and it's a little bit more accessible than what we had in Active Directory users and computers.

0:00All right. So one of the problems that we sometimes have in Active Directory is that even experienced administrators can make mistakes, right? I mean, we're all human, and sometimes something gets deleted that we really shouldn't have deleted and can have a pretty big impact. Now, there is the Active Directory Recycle Bin, which as the name implies, is similar to what you would get with the Recycle Bin that's on your desktop. So if you delete a spreadsheet and you want to get it back, it's in the Recycle Bin. Just retrieve it. That's all you got to do, right? Similarly, we can now do that in Active Directory as well. I think this came out in, I want to say 2008, Server 2008. It might have been R2. Because prior to that time, we did not have a way to recover these objects. You could recover them, but it would have to be done through an actual recovery, a backup and restore operation, okay? And it got to be kind of messy at times as well. So Recycle Bin is a cleaner way to do this to recover an accidental deletion of an object. It could be a simple user account. It could be an organizational unit. It could be a parent organizational unit like this with multiple other organizational units and users and other kinds of accounts and all kinds of things, computer objects, all kinds of things. There could be thousands and thousands of accounts

1:20and objects underneath this parent. So if you delete that parent, you lose all of this, right? Devastating when that could happen, all right? Now, there's not really a lot of anecdotal evidence for this because when organizations have a deletion like that, they don't like to advertise that or brag about it. Oh yeah, we deleted this organizational unit and lost thousands of user accounts at the same time. Isn't that hilarious? So organizations don't like to publicize that. Nevertheless, I think you know that it happens and it can have a devastating effect because this is what's going to happen. All the users, and by the way, computer accounts if they're in those OUs, well, they can no longer log in. They effectively become a nobody, okay? As far as Active Directory is concerned, you don't exist anymore and your computer doesn't exist either. This could also affect, of course, various applications you need to use because most applications have to have some kind of an authentication involved with them. And especially I'm thinking of things like a web app or something like that that might depend upon Active Directory for some kind of authentication to occur there. Another thing that would happen is you're no longer subjected to group policy objects. Well, because of the fact that you don't exist anymore,

2:39a group policy object won't apply to you either. It could be security settings that now disappear as well. So there's a lot of cascading effects that can happen here when you have an accidental deletion like this. And in addition, if you do not have the Active Directory Recycle been enabled, and I'll show you how to do this coming up, then what objects get deleted, they become what we call tombstone and then there's a time limitation on tombstone objects. So a tombstone object is pretty much like a car that's had the engine removed. It's not really worth much anymore.

3:16What happens is those tombstone objects have all of their attributes stripped, group memberships, any of the other attributes that are part of that account. To recover that account then could take hours or sometimes days. It depends on the size of the organization and the availability and recoverability of your backups. And even with the backup, it's kind of a mess. So what do we do with this? Well, when we do have a recovery that we can do with the Recycle Bin, we can get back most of the common objects that you would want to recover that get deleted. Things like user accounts, groups, organizational units, and child organizational units like this.

3:58Some things to keep in mind and some limitations are it's not retroactive. So for example, before we started recording, do I have it? I have it here. Yeah. I ran this, well, it's kind of a long to scroll all the way up. So this is what I ran right here down at the bottom. I just wanted to see if there were any objects that were deleted. Okay. So I ran this PowerShell command, let get AD object. The filter is, is deleted true. And I want to show those deleted objects. And then this is what it dumped out. These are all a bunch of things that I've deleted. I don't even remember what all of them are, but I did delete one thing recently, and that was Tucson user 10. Okay. Now again, this is really just what we call a tombstone object. So it's really not very useful just to recover that account in any other way than to use a restore operation from a previous backup that was made of Active Directory. A better way to do it though, is to use the Active Directory Recycler. But now there is a way to enable this apart from Active Directory Administrative Center. We've had this before we had Active Directory Administrative Center, and you could enable this from Active Directory, excuse me, from PowerShell. This is irreversible by the way. So once you enable it, you can't disable it. Although I don't know why you'd want

5:15to. So first thing you have to do is to import module Active Directory. If it's not already present, I think I already had it, but I went in and ran it anyway and nothing seemed to happen. So I think I already had it. Anyway, then I wanted to enable an AD optional feature, and then there's a backtick here. In PowerShell, a backtick means that I can press return and add additional parameters or options to the PowerShell commandlet. Otherwise, all of these things, next to these double arrows, all of these things would be on one line all the way over here.

5:48I probably could have done it in this case, but sometimes it runs way over the edge of the border of the window, and I guess it'll be a little bit hard to read. But anyway, what we're enabling is the Recycle Bin feature. It is a forest-wide option, so bear that in mind. You don't do that on only a single domain. It's an entire forest and all of its child domains, if there are any. And then you would target it to whatever the root domain is. In my case, it's nuggetlab.com. I'm going to control C to get out of that because I don't want to actually press enter, accidentally press enter, because I don't want to do it that way. What I'd rather do is to go here in Active Directory Administrative Center and simply choose Enable Recycle Bin.

6:29Are you sure you want to perform this action? Once you've done it, it cannot be disabled. Kabam, and it is now done. Now, do bear aware of this message here. It's been enabled for this forest, but in an enterprise environment with lots of domain controllers and child domains and all that kind of stuff, it may not function reliably until all domain controllers in the forest have replicated. This can take hours. If you're a large global organization, it's probably going to be hours, maybe even days before it completely propagates throughout your entire forest. Just bear that in mind. Now, once that's been done, I also need to refresh this.

7:06I'm actually just going to close it and open it up again after a couple of seconds here. And then now, once I go into Nugget Lab here, I should see deleted objects. Now, I don't have anything there, even though you saw that I had a TucsonUser10, I think it was, had been deleted. But remember, that was a tombstone to objects. Let me delete another object. Let me go to a different Tucson user. So I'll select TucsonUser9, and I'll delete that object. You want to delete that object? Yes. Now, I'll go back to deleted objects, and there you go.

7:39There's TucsonUser09. Restoring it is quite simple. Notice that over on the right, I have a couple of options there. Restore, restore to, locate the parent, properties. That might be handy because I might not be sure that that's the right account that I want to recover. So I can right-click on it, look at its properties. I don't even really have anything in there, so there's not much to show because these are just kind of emptied out accounts. I can restore it to a different location. So I can decide, you know what, that user has moved anyway, they've moved to Phoenix, and I'm going to have to change their name anyhow. So I'm going to put PhoenixUsers. I could do that if I want. I can also locate the parent, and that will tell me where they were located. Here you can see we are now in TucsonUsers, and if I go to the tree view, we'll see that a little bit more explicitly right here. I'm glad I thought of that because I don't think I ever actually showed you the difference between these. Maybe I did, but I forgot. But anyway, just two different ways to look at the objects. Actually, I did. I think I remember right now, and now I'm going to just restore it. Bam, it is now restored to TucsonUsers, and there is TucsonUser09. Now, this might be a good time to show something else as well.

8:53If I go down here, if I double-click on the account, and now I go down here to more information, we'll see here that the update sequence number is quite high, 143, is that right? Yeah, 143,582. Every time you make a change to an account, it increments that. By the way, it doesn't usually increment it by just one. It's usually kind of significant, but it was first created. It was 25,049. Now, why am I pointing that out? Because when you restore an object, it has to increment the update sequence number by quite a lot in order to guarantee that it can properly replicate to any other domain controllers. There are instances in which, just imagine if we only incremented it by one number, so 143,581, 582, 583, like that.

9:46Well, in the time that it took me to delete that object in the first place, another administrator on a different domain controller may have changed something about that account, changed group membership, password, whatever. But when they change it, it also increments it. So they may have beaten me to the punch where they're already at 143,583 when I restore this. Well, that makes my object that's been restored look old. Therefore, anything that they did with it, we could overwrite this one. It gets to be kind of messy because you can start to get into some collisions and stuff like that. So that's why it increments it by a kind of a high number.

10:24Now, as an example, let's look at TucsonUser08, which I created at the same time I created TucsonUser09. And if I look at that one and go to more information, notice that here, it is a significantly lower update sequence number. So usually, it increments it by at least 100,000. And that just helps to guarantee that in the synchronization process with other domain controllers, it's not going to accidentally look as if that's old information. The same would happen, by the way, if we did a directory services restore mode restore, which is a special kind of restore you can do from a Active Directory backup. When you restore it, it's called directory services restore. It does a similar thing, increments it by quite a lot. Now, I kind of got off track here. So again, it's not retroactive. That's what I was showing you there with the TucsonUser10 account. I really can't get that back from the recycle bin. There are other ways to do it, but not through the recycle bin. However, you saw me recover the TucsonUser09 account because that was in the recycle bin. When you delete an account, it normally has a 180-day tombstone lifetime. And that's just to keep the object present. Even though all the attributes have been stripped out, this is without the recycle bin, it keeps the object around just

11:39kind of as a husk, just a shell of what the account used to be but without any attributes. Why? Because it needs to reflect the fact that on this domain controller here, I had a user account that we 86ed, we deleted. Sounds kind of fatal, but anyway, we delete that account. Well, we have another domain controller over here in some other continent or whatever. If we were to delete that user account and leave no trace whatsoever of that account, this other domain controller would still have that account. And then we would have a real synchronization issue here that would be all broken because we insist the account still exists. We insist that the account was deleted. What's going to happen? Okay. It just causes some Active Directory issues there that you really don't want to tangle with, believe me. So really, we have these tombstoned objects where they're tombstone because we need to use a garbage collection process to notify the other domain controllers that the object is actually deleted. And remember, the attributes will be stripped.

12:41So that's why we need a recycle bin because we want to get the attributes back as well. Otherwise, you might as well just recreate the account or use directory services restore mode to get that account back, which is a little bit messier, but doable. If there are nested OUs, well, this can get complicated. Okay. It doesn't have to be. So if I have an organizational unit here and another one here and another one here, let's say, if I deleted this top level OU, it will also delete the child, the children OUs and any of their contents, any of their objects.

13:14But if I recover that OU, then in turn, it should also recover using the recycle bin, all of these other child OUs and their contents. But if we messed it up and we deleted this, which in turn deleted this and which in turn deleted this and all the objects, if we only recovered this child OU, maybe we didn't realize that the parents were also deleted. So we recovered only this child, then it causes, again, kind of a problem because kind of this phantom organizational unit that doesn't really have a connection to its parents. I'll get into all the details with that, but again, it can get kind of messy there. And you may have to go to a more manual process to recover those. You'd have to recover manually the parents, the other objects, all that kind of stuff. And if it's a complex restoration where you have a lot going on with it, you probably need to go back to PowerShell instead of using the Active Directory Recycle Bin directly in ADAC. Although, ADAC is definitely the easiest way to go.

0:01All right, so here I've got my virtual machines running. This is what I've been using for the whole course, really. And there's a server here, actually a workstation, I should say, a Win11-01. It's got all the administrative tools on it. It would be something that an administrator would use. Most of us don't actually sit at a server. We sit at a workstation, and then we have these server tools installed there that allow us to remotely connect to our servers. But as you can imagine, even though it's just a lowly workstation, pretty security sensitive because of who's logging onto it, right?

0:33So for example, I'm gonna log on as phoenixadmin09, okay? And the password is something very, very secretive. As you can see right here, capital P at sign SSW0RD, okay? Not bad for a lab environment or whatever like that. I've really dumbed down our password policy just to make things easy and it's not a production environment. Of course, in production, we wouldn't wanna do that. Nevertheless, this might not be the best for an administrative account. Maybe phoenixadmin09, maybe they're a highly specific account that's an enterprise admin and a domain admin and all that kind of stuff.

1:12And we wanna lock that account down or we can apply this to an entire security group of administrators, for example. But anyway, you can see that I logged in just fine with that stupid password. Also here, I've gone back to Active Directory Administrative Center and let's go to phoenixadmin09 and I'll double click there. We'll see that if I click member of, sure enough, they're a member of domain admins, enterprise admins. That's a pretty weak password for somebody with that level of privilege. Even if it would be for other reasons, perfectly acceptable for my receptionist and my salespeople and other kind of generic users that we have in the cubicle farm.

1:51Not for this person though. So how can I tighten this up a little and make sure that we have good security here? Well, I can go back up here to the Nugget Lab local. And again, I can do this from the tree view or from the list view either way. And I'm gonna go down here to system and then there's this password settings container, okay? So once I double click that, I am now in the password settings container. If we take a look at the group policy management console, I'm gonna put a push pin in that for right now.

2:22I'm just gonna go to the group policy management console, gpmc.msc and take a look at our password policy, which is in the default password policy right here. That's where it is by default. Give me the default domain policy. And I'm gonna click on edit there. And if we click on the computer configuration policies, Windows settings, security settings, account policies, and then password policy, I could really dumb all of this down. And in fact, I'm gonna do that. Strip all of this stuff out. Some will be able to reset their passwords immediately.

2:55You can also, for some of these, just specify not to define the policy setting. That would be just as good there, okay? Password length, we'll just say even zero characters will be fine. Oops, I must've clicked too soon for that. There we go. Zero characters, no complexities required. I'll even disable that, okay? And so this is a really a horrible password setting, okay? And I'm exaggerating things a little bit here. You wouldn't do this in a production environment. But my point is, yeah, I could create an administrative account right now with these weak requirements for a password that might not be acceptable in any other context.

3:33So here in the password settings container, I need to set up a new password settings for my Phoenix Admin 09. And again, it could also be for a group. But I'll just say domain and enterprise admins. Then you'll also enter in a precedence. This is a little bit hard to describe, but you can actually have multiple levels of these passwords policies, password settings, okay? And you can set a number here. This is a little bit arbitrary. So I can say the number 10, okay? Now, if somebody is subject to both this policy and based on something like maybe group membership, they are also subject to a different password settings policy.

4:14Then whichever one has the lowest number would take precedence. So if there's another one that this user is also a part of, it applies to them in a couple of different ways, but the other policies are level nine instead of 10, like you see right here, then that other policy would take precedence. On the other hand, if there was another one that was, say, precedence number 11, then this one would win over there, okay? Now here you can see I'm setting up more requirements there.

4:45Let's say it's a minimum password policy of 10. You know, all of this is already more secure than our dumbed down policy, which I configured in the group policy management console. Password history of 24, must meet complexity. There's also this, by the way, protect from accidental deletion. We didn't use to have this when Active Directory first came out, but now it applies to a lot of different kinds of sensitive objects, user accounts even, organizational units, groups. Prevent things from being accidentally deleted.

5:16Minimum password age of one and enforce maximum password age of 42. Notice that we can also enforce an account lockout policy, which I didn't have before. So I can say, number of failed logon attempts allowed. Let's just say two. Oops, my alarm's going off. Sorry, hold on. Now I can't remember what I set it for. Was I supposed to be taking a nap right now? Maybe I should pause the screen and take a nap. Anyway, gosh, how old am I? Supposed to take a nap before they serve me my applesauce. So since it's a security sensitive account, you want to only allow two failed logon attempts.

5:51Maybe they fat fingered a logon. Maybe they remembered the logon incorrectly, the password that is. And since it's so sensitive, they only get two chances. After two failed logon attempts, it will lock that account and we'll have to find another administrator to unlock it. Or we can wait 30 minutes and then it would reset itself, but we'd have to wait 30 minutes of not being productive and sitting in the break room and gossiping about other employees and stuff like that. They probably locked themselves out on purpose. Okay, and similarly again here, the account is locked out for 30 minutes there.

6:24So sensitive admins, high security requirements. I'm just making stuff up. Okay, now we also have to decide who this applies to. So then I can add in, wherever I want this to apply, you'll have a good business reasons for doing this, but it's probably gonna be some kind of sensitive group like, I don't know, CEOs, or in this case, since it's IT related, let's say domain admins. So I'll just put in here domain admins, okay? And I'll just check the names and it checks out, okay?

6:56Click okay, and then there it is, okay? So I will now apply to all domain admins will have these password requirements if I wanted it to be that way. In my case, I really don't because I wanna keep my stupid passwords for demonstration purposes to make it easier for me to log in. Yes, it's all about what's easier for me, people. So we'll click on add here and I'll just gonna specify that one user, PhoenixAdmin09, I think it was. Yep, there they are, click okay. And now this specific policy will only apply to that one user.

7:30Now, believe me, I'm gonna pause here for a moment and talk about this. This has been the source of a lot of strife and arguments and darn near coronary heart attacks. I've seen in person, by the way. Yes, I've been right in the middle of these arguments. I did some consulting for a large defense contractor years ago now. And if I named them, you would know them right away. I had two administrators behind me. I was sitting at the desk and we were talking about this because we were talking about rearranging their whole Active Directory structure.

8:03And I had two administrators behind me while I was sitting at the keyboard, arguing back and forth. I can feel the spit flying back and forth here. And the guy on my right, he'd taken me to dinner the night before. And he was saying that I bought him a steak dinner, but I didn't realize until he started eating. He says, I'm not supposed to be eating this because I've got very serious heart issues. And the doctor doesn't want me to eat, I don't know, red meat or something, I don't know. It shows you how healthy I am. Anyway, so I knew that this guy on my right was very susceptible to a heart attack.

8:37And he is in this screaming match with this other administrator behind me all over things like these password policies. And they were also arguing about whether to consolidate into a single domain or multiple domains. At the time, this is years ago, they were arguing that, one of the administrators were arguing that they would have to have a separate domain because that's how we used to have to do this. In the past, if you had somebody that had separate password requirements, you had to put them in their own domain. So there were certain domains that only had a very small handful of accounts in them because those were the sensitive accounts.

9:14That's kind of a big set of overhead just for that one purpose. But who would you apply to? You know, IT admins, C-suite executives, CEOs, CFOs, CIOs, that sort of thing. People with different levels of security clearances, people who work on different sensitive projects, stuff like that, okay? So anyway, that was one example that I was telling you about with that defense contractor. I also ran into that with a large financial services firm that I was consulting for. They're kind of behind the scenes, you wouldn't know them if I named them, but they've got their tentacles in probably any financial organization that you will ever work with.

9:51Anyway, we're gonna do this just for Phoenix Admin 09, just to prove the point. Now I'm gonna switch over to that desktop and log that user out and back in again, okay? And by the way, what I'm using here is, you can see kind of in the background there, something from Sysinternals, and this is known as the Remote Desktop Connection Manager, and it just allows you to make remote desktop connections in one console instead of having separate windows for each connection. Anyhow, I'm logged back in now, and I just used that stupid password that I had before, capital P at sign SSWORD.

10:24Not the best password, but if I send a control alt delete there and change my password, I can enter in the old password, and the way the security policy is for all my other users, they could actually use a blank password. So I can try to submit that here, and it says it's unable to do so, why? Because the value does not meet the length, complexity, history, blah, blah, blah, okay? So it will not let me do that stupid weak password, okay? So there's my original password right there, I guess that's what it is.

10:54And you can see it right there. Now I have to make it something complicated and difficult. So I entered in a different password here, and you can see it right there. Still possibly a little bit easily guessable, but I had to enter this in, okay? It meets the complexity requirements, at least I think it does. And finally, I successfully changed the password, and we logged in, okay? So that only applied to that one user. Any of my other users could use a stupid password or a less secure password than what we set up for that one user.

11:25And that is the strength of using a fine-grained password policy. By the way, we don't really have it here because we don't need to, but you can also do all of this in PowerShell. It's just, why would you? You don't really set it in a lot of places, and it's just as easy or easier, really, to use the UI there in ADAC.

0:00Let's finish out here with a couple of simple items here, and one of those would be bulk operations. Now, we can actually do this as well in Active Directory users and computers, but just to finish it out here, we'll go with about Phoenix Admin 8-5 right here. With these several users right here, maybe we realized, I'm not sure we ever made them admins. I can right-click here and add them to a group, or maybe they're all disabled. I could disable them all and then enable them all, or maybe they're all locked out.

0:31I can unlock them all. I think you can see all those. Those are the options we have. I can also go to Properties if there's some other property we want to manage. Maybe they're all in the IT department. I would have to check that box and put them in the IT department. Now, likewise, I can also make them a member of a group here, but I'll just show you the different way to do that there. I'll just click, okay, now you can see if they're all in IT. I should probably do it for all those users. Anyway, now I can also add to a group in this way here as well, and I can make them domain admins.

1:03Not that I might necessarily want to do that all the time for a small organization to make so many domain admins, but I'm just showing you by way of demonstration what we're capable of doing right here. Now, notice also, we did show you this in the core course that I thought that's the basis of what I'm teaching here. But if I expand this out, remember, we also have this PowerShell history. For example, this last thing where I just changed their group membership, that's this last PowerShell cmdlet that we see.

1:34I can zoom in right down here at the bottom, set active directory groups at AD group. If I expand that out, we can copy all of that, go to a command prompt here, for example, or actually a PowerShell prompt, and I can paste that in here, and that would be the basis for some other script I want to do. Now, in this case, all those users that you can see here, Phoenix users, eight. Where's the other ones? Five, six. All the other ones that were in there, seven. You can't see the forest for the trees right now. But anyway, we see that in the identity, we added them all to domain admins.

2:08However, we see some other groups here, other users, what is it? Four, three, two. I don't think they're domain admins either. Let's confirm that first of all. These three right here, if I click on properties, and they're member of, yep, sure enough, they're just domain users. That would be easy enough to just add them into, using this add button over here on the right, to just add them in as domain admins. It's because I want to show you that we can also do this in PowerShell, using that as the basis, all of this right here, I can just change those accounts.

2:42So I haven't pressed enter yet, so I'm just going to go back over to each one of those accounts. What is it, two, three, and four? So I'll make that one two, three, and four. And all the rest of these I don't really need because they've already been added in. So I'll just select all the rest of those and delete them. And now I have Phoenix Admin four, Phoenix Admin three, Phoenix Admin two, and I think I did everything right. Then I'll just press enter here.

3:13And now if I go back into these accounts and go to their properties, member of, sure enough, they're all now domain admins here. So the point in showing you this is simply because I want you to understand that everything we do in Active Directory Administrative Center is backed by PowerShell. Any action you perform in here actually does a PowerShell cmdlet along with its various options and everything like that. And that's why it keeps a record of it all down here.

3:44Now it would be just as easy to use the UI for what I just demonstrated there. But if you have a more complicated situation and you need to use this as a basis for a script, for example, it's very easy to use this as your basis. And then you can just modify it for whatever script you might need.