Tyler Jacobs - A Miser's Guide to Hardening Active Directory

All right. Hi everyone. My name is Tyler. I hope you've had a good day. So, uh, this is my talk on the miser's guide to hardening active directory. So, if you're not here for that, you're in the wrong room. I need you to figure that out on your own. Uh, this is my first conference talk. So, uh, I got a C++ in public speaking, so you're in for a treat. and I have ADHD. So, you're in for a bit of a ride. So, let's do it. All right. Some more about me. Tyler said that already. Uh online, I go by Pullman Jim. Uh so, you may have seen me on the Active Directory subreddit. I

kind of hang out there cause a lot of trouble. Uh other than that, uh I've been doing it for about 20 years. 10 to 12 of that has been in the identity space. Uh, I work for a large healthcare company, so I uh I'm not putting their name on there because I just didn't want to, but it's not like it's a secret. So, um, yeah, that's kind of about me. Um, I I Yeah. Um, the contact details are on there. I also have them at the end, too, so you don't have to worry about trying to keep track of that. Let's get into it. So, what am I going to talk about today? So, first of all, show of hands.

Who thinks AD is going to be around in 10 years? Cool. All right. Yeah, it's not going away. Uh AD is not dead. It's not dying anytime soon. In fact, the current trends I'm seeing from like my friends at Microsoft and whatnot, they're saying that it's actually going the opposite direction. More organizations are adopting it than they did last year and so on. So, it's it's not going away anytime soon. The challenge is though, security isn't free. We got cloud, we got AD, we got Entra, we got all these things we have to secure. So, how do we keep maintaining an arguably legacy system if we're not keeping track of stuff? So, uh that's the hard part. So, today that's

what we're going to try to do. We're going to try to start somewhere. This is not going to be like a deep dive on any one of these topics. I do have slide notes for everything and bonus slides that are more deep divy. So, if you're looking for that stuff, I will have it. But, uh I can't talk about everything because AD is so big. So I'm going to keep it simple and the whole focus is the hardest part of any project is starting. So and then some disclaimers slash what is this not uh a lot of the tools and scripts and stuff I'm going to talk about have the likelihood of tripping EDR so keep that

in mind. Don't run prod unless you've gotten permission first. Uh most of the tools are free some are not. I don't work for anybody on the list here. So if I recommend a tool or a vendor because I've tested it and I liked it. Um but nobody gave me money to do that. So um also a lot of the free tools require emails. So uh you can either use like a temp email address or I have done the best I can for any of the links I have to include the straight up uh download link and no email. And obviously this is not an exhaustive list. I cannot list everything you could possibly do in ad.

So we're just going to we're going to go with it. And of course, opinions are mine. Don't blame my employer, blame me. All right, let's get into it. So, another question for the group. Who here has backups of their active directory? Who here tested them in the last year? You should get on that. Yeah, BC Oops, I push I pushed the button. BCR is kind of boring. It's probably why we don't see a lot of talks about BCDR, but uh it's kind of important. And if you're smart, you know, like the reality is is most organizations, you'll go out there, you'll buy a product, you'll use a product, you'll back up, you might do testing, and if you're really smart, you

might do a tabletop like once every couple years, but they're not shiny. They're not cool. But this might be the most important thing you ever do because they will save your butt if you're not careful. So, why are backups important? Well, they get you from oh crap to okay. The challenge though is we tend to think of VCDR like this. A comet, meteor, fire, whatever. Everything's gone. Arto crisp. The reality is what happens if you see that screen? I like to call this the red screen of F, by the way. So, you know, um, what if you see that on your domain controllers? What do you do when you do your tabletop exercises? Has anybody ever asked the question, if my

entire identity system's down, what do I do? Entra AD, they're connected. If one goes, the other one usually goes. Can you get to your phones? If your AD is down, a lot of phones require authentication. Now, can you get to your teams? Where's all that at? You have to have a plan. You have to have a mechanism of getting through that. You have to have options. Now, for the bad news. Backups cost money. Tyler, this is a measer guide. Why are we talking about money? Well, that's just how it goes. You have to spend money sometimes. So, this whole thing, if you're going to spend money on something, my advice, spend it on backups. Are they worth it?

Yes. If you drop the entire cost of your IT budget for a year on backups, it will be worth it. Uh, I've seen it myself. Um, and the reason I recommend that over, you know, other things is because of that first point there. you want that support. When you're in a BCR incident, you're you're your your butts out there. You're in trouble. And being able to call for some help is a real is a real benefit. So, that's really why I I say, you know, go for enterprise backups. Um the other things are good, too. Don't get me wrong. You want good backups, but the support is what sells it. So, how do we find a good backup solution for AD?

Um well, you have to start with kind of building a VCR plan. And that's where the business tolerance comes into it. So when I'm talking about business tolerance is how far back do I need to go potentially? So do I need to retain 30 days, 90 days, 180 days? Please don't go longer. Tombstone lifetimes. Um what happens if you have to go back further than that? Have you planned that with your leadership teams? How much data is an acceptable amount of data to lose? That's another question to ask. Um, the execs in the room will love to say that no downtime, no no lost data. But the reality is you can say that in the

mirror, but that doesn't change the fact if you have a VCR incident, if you have downtime, you're going to lose something. It's just how it goes. And you have to ask the question, what are you protecting against? We like to think the meteor. I like to think of the red screen of app. That's where I kind of go for it. All right, let's build a let's what are our technical requirements? Well, the obvious one is, can it actually restore? Be surprised how often that answer is no. Can it restore AD is the kind of the specifics on that. Can it be secured AD backups? What do they have? The AD database. What's in the AD database?

Passwords or password hashes. But can it be secured? You don't want to just drop this backup on the network and expect anybody to go get to it. You want to harden that. So, it needs to have arbback rollac control. and it needs to have uh encryption on it. So, make sure it can be secured. Is it supported? I know I talked about support, but you want to make sure that you have somebody to call if you need help. Is it resilient? So, this comes back to a couple things. The first is can it be uh protected against the red screen of death on your backups? Can you make sure your backups aren't going to get

crypted? Can you actually get to your VCDR solution while AD is down? You'd be surprised how many VCDR solutions have a dependency back on AD. That's a problem. So, and then the other thing to think about is the 321 rule. If you haven't heard of this one, three copies of your data, two physical media types. I personally think cloud and on-prem count as physical media types in this case, and one of those has to be off-site. Um, the off-site thing, cloud doesn't count because the network spanning and stuff with cloud and on-rem cloud is may may as well be in the same bubble at this point. There's no difference there. So, actual off-site location and the plus ones kind of come

out in the last few years. One of those copies should be right protected or mutable or something like that. Oh, by the way, VM snapshots are not backups. Let say it again. VM snapshots are not backups. Despite what your vendors might say, they are not backups. Uh I can go into this like forever really comes down to they have the same problems as regular backups and you also introduced the dependency on the underlying VMware systems or VM systems, excuse me. So V uh snapshots are not backups. All right, let's talk about some real solutions. Tyler, you put Windows Server backup up there. Is that a real solution? Yes. Why? It's free. free and okay or somewhat okay is better

than not free and not used Windows Server backup is available. You can restore Windows from it. It is still supported by Microsoft. It works. It's not the best. It's not the prettiest but what you got. Um also we're talking about the immutable thing. It is not immutable by default. So the way you can get around that off-the-shelf NAS solutions usually have some sort of built-in uh immutable storage. So you have worm write once read many or they'll just straight up call it something else. Um pretty much anything off the shelf true could do it. Um I put Azure on there because we are in the cloud world. So for the for the cloud hipsters, yes, you can use Azure

backups. They're not great for this kind of recovery though because of some of the dependencies and the weirdness with how Azure works. But it can be done. Just not my favor. Okay, those are okay. Let's talk about something crazy. So, who here has used an IFM install before stall for media? So, IFM is install for media. And what it is is you effectively take a snapshot, different kind of snapshot of the AD database, the registry and sysfall. And the way that works is you run some commands, it stores those on local disk. They are not encrypted. So be careful with this and normally you use that to preede new domain controller so you don't have to

wait for replication. There's a guy his name is Michael Graphneter if I'm pronouncing that right internal system tools he wrote one of those scripts can actually take your IFM and it does nothing shared restore of ad. So you can build a completely new system, nothing like the name is different, nothing the same except for the disk, the disc layout the same and you can restore your IFM to that and it will not know the difference. It will look just like it did before. It's a wild product or a wild tool. Um, speaking of products, so a lot of the big vendors, they're doing that behind the scenes. They just don't tell you. The downside with this is wildly not

supported. Um, if you call Microsoft, they might help you and you're kind of on your own because it's all free. Um, and oh, it's extremely manual. Like there's no like automation within that. You kind of have to do it yourself to that. And the bottom thing, uh, not so enterprise. That's something I'm working on. It's actually a wrapper for the other thing that'll be in my GitHub in a couple weeks. Sorry about that. All right. So, kind of wrapping up the plan here. Get a backup solution. Make sure it can do AD restore the full Make sure it can restore the full forest and make sure it's secured and resilient. Make sure you're not using snapshots. And for

the love of God, back up multiple DCs and test your backups. All right, let's stop talking about backups for a second. This is my favorite slide. So, when I was, you know, putting a talk to do this for the first time, they send you like a guide of how to do talks right. And one of the rules was don't put more than 20 words on the screen. So I put all the words on the screen. Um but seriously, this is not the words aren't important. The the idea is important. This is what cyber security looks like anymore. There's a thousand tools. If you're in the identity space, there's even more tools. If you're doing AI, there's even more

tools. There's tools. There's tools. There's tools. There's tools. And the challenge that we run into is we get so wrapped up in tools that we stop thinking about what we already have and we start chasing the shining. So my suggestion here is pause. Don't go buy new tools. Look at what you have. See if it's deployed all the way. See if it can do what you need to do. It may not. And that's fine. You have to do that. Also, uh, keep an eye on your vendors. They love to tell you to do things with this you shouldn't. And ask questions about your cyber security security tools. A lot of times we just kind of put this

implicit trust that oh well it comes from this bigname cyber vendor. It's it's safe, right? I can give it domain admin. It's not going to cause any problems, right? Who's auditing the auditors? Who's looking at that? Push back. Fight for it. Not saying these are bad tools. Just saying they need some scrutiny too. That said, when I talk about tools, we're getting into like the performance stuff. And so this whole thing is framed on operational risk is still risk. We spend a lot of time talking about cyber stuff in the security space and like what bad things can happen with, you know, hacks and whatnot. The reality is is operational risk is still risk. If

the system is down, you know, the strong bad the system is down. Uh if the system's down, is that any better to the business than if the system is compromised? Think about that. So, we need to have a plan. What do you have already? We have scum. Most places have scum. Some have scum. If you're running system center at all, you'll have scum. I hate scum. I hate it so much. Uh, but keeping to my own mantra. It is there. If you've already got it, so use it, but don't use scum. Here's my recommendation. Use Zavix. But Tyler, there's a lot of other tools out there. Why Why are you saying Zavix? I don't care what you use. This is the

one I like. Zavix is free. You can pay for it, but it's free. It does all the things you need to do to monitor. Um, the biggest downside I've had with Zavix is it is not like Windows friendly out of the box. It's very Linux focused. Like when I was trying to set it up originally way back when, I couldn't find any AD templates or I found them. They just were terrible. So on my GitHub, I have AD templates. Not saying they're perfect, but they're better than what I found online. So, if you're into that, go check it out. Talking about performance, let's talk about some of the stuff you need to do to kind of get this off the ground.

Okay, we need to get this solution. It's going to take time to get it off the ground. Where do I start? Configure advanced audit policies. Now, there are two types of audit policies. There's traditional, they suck. There's advanced, they're better, they're more granular, they're really they're really good. Honestly, the two are incompatible. If you have them both enabled, you're going to cause problems. Go for the advanced, please. Uh, as far as which ones, look at the baseline stuff. I'm going to talk about that a little bit later, though. Data collector sets. These don't get a lot of love. They are really great at capturing all the kind of uh performance events and uh event logs and putting them into like a

nice package to kind of store. The downside, they're per system. They're kind of clunky, but they do get the job done. My advice with data collector sets is they're really great for troubleshooting. If you have like a reoccurring incident that kind of keeps popping up, data collector sets are a great way of capturing a tremendous amount of data that you wouldn't normally want to capture. Also, if you're kind of building out like your own Zavix templates or pick your tool of the week that doesn't have templates, the data collector sets have a built-in AD template for them. That would be a great place to start like picking out settings from. So, I recommend that. But get a tool. It's really bad that

thing. Whatever you want to do. Don't have to use AVIX. Find what you like. Oh, and please look at your tool. Like whatever you do, having all this data is important. If you're not doing anything with it, it's not it's not it's not useful. So, make sure you're looking at it. Make sure you're alerting on it. So on. All right. Let's talk about best practices for a second. So the natural place to start always for me is the Microsoft security baselines. They're free download and they do the job. They come up per OS version. They include GPO templates and they include a bunch of tools. So if you're not using these, I recommend looking at them.

They're free. They get the job done. The coolest things about them are the templates that you can Sorry, I keep breathing in the mic. I'm not used to this. uh they're free downloads and you can go in there and the templates actually have all the settings that the the baselines have. I do not recommend just dropping that in environment cuz you will cause an outage if you're not ready for it. Those are good to compare with which is the second tool there, the policy analyzer. You compare your tools, your group policies versus theirs, and you're set. My favorite thing on this list though is the reference dock it comes with. It has a reference that

shows the group policy setting mapped to a register key for most settings. It is so helpful to just have that I have it like bookmarked with my Excel. So I use that all the time. These are a great place to start. They are not as comprehensive and they're Microsoft only but they're a place to start and they're good. All right. Originally I wanted to do like a raise your hand if you've used DIS digs but this is not spot the Fed so I'm not going to do that. But DISA digs are US government focused baselines. They're not just Microsoft. That's the biggest difference here is they're not just Microsoft. You go on the Dissa website, it's literally pages, pages of

stuff that you can scan with them. They're awesome. The biggest downside is they have a lot of weird government stuff in there, like you have to use the government PKI or the government NTP servers. So, you kind of have to tweak that a little bit. They also have group policy templates. They have lots of guides. But my absolute favorite thing and the reason I always recommend Stigs even if you're not federal government stuff is the Scap tool. Scap tool is a free download. It can run local or remote and it will actually do compliance checks against systems to tell if they're compatible with the baseline that this will push it out. They're really, really good. They

are super great. And I have a theory that the format that they use is all XML. So I think I can teach my AI to rewrite them so that it doesn't have the weird government stuff. But I haven't tried that yet. I like disakes. The other big player is CIS benchmarks. They're good. I'm not going to say they're bad. I don't like them because they cost money. So the you can download the guide for free. You have to give them your email. You can download their light scanner for free, but you cannot download their scan the all the things for free. They require payment for that. Um and it's not like super cheap either. So, I like them and there's a lot of

things that use them because they are really good, but that's the thing I found the limitation. I've not figured out how to get around that yet. Um, they are extremely comprehensive though, too. All right, let's talk about some individual settings and what to do about them. So, LDAP signing and LDAP S. There is a setting in group policy that says require signing. LDAP signing or LDFS meet that setting, either one. Tyler, what's the difference between the two? So glad you guys asked. LDAP signing is effectively you take the authentication header and LDAP session and you encrypt that or you really you just use NLM or curvos to do the authentication. The rest of it is unencrypted which is just

LDAP data. It doesn't matter at that point. LDAPS is you take the whole LDAP message and you shove it into a TLS packet and you pick it off across the network. The difference there is LDFS requires PKI where signing is just using the native Windows off. The big reason to do these is simple binds AD. A lot of things still use simple binds. If you didn't know, simple binds is basic off. It's plain text password on the network. It will be gotten. You can log for this. There's a lot of information out there on logging it. Microsoft's been trying to kill it for years. The other one talking about is SMB signing. Uh, SMB signing is truly

wonderful. It protect pro protects against man-in-the-middle attacks and helps with NLM relay stuff. The crazy thing about this is is just about everything supports it. It's been around since like 95, I think. I can't remember the exact date. Everything supports it for the most part. So, it's it's easy to get in there and it has few consequences. So, I'm obviously do some testing, but I've seen SMB signing rarely cause issues in hardening. This is kind of like a whole bucket thing. So in October, Microsoft is going to try to kill NLM on server or NLM v1, excuse me, on server 2025 and like Windows 11, I think 25H2 or something like that. Um, I wish them

luck because I don't think it's going to happen. I think it should happen, but I don't think it's going to happen. So in comes in two flavors. There's one and there's two. One really bad, two is kind of bad. Um, they both are trying to get they're both trying to be gotten rid of, but one is the one they're after right now. Get bigger auditing. Start tracking down your NLM and figure out what's what's causing it and and start working on that. But it's going to take time. Just accept it. Well, if we're not using NLM, what are we using? Kerros. Well, it's it's it's perfectly secure, right? There's nothing we have to do to make

Kerros better. RC4. Got to love RC4. It won't die. Um, it's a big one. Look at your keros encryption types. Microsoft dropped a patch this last month or early April that takes care of a lot of RC4 stuff that's causing a lot of headaches for people in July. They're making it even harder. So, keep your eye on it. Um, just set your encryption types. That's honestly the truth to set your encryption types. And then Kerros delegations. This is probably the scariest thing because Karos delegations can really eat you real fast. Now, if you don't know what Ker Bros delegations are, they are basically user impersonation, which sounds super scary. It's actually an intentional thing in

the system. You think about it, you don't want to give the guy coming in through your website direct access to SQL Server. So, you put something in the middle. So, it has to proxy that that authentication through. That's where delegations come in. The thing is is pre I think 2008, there was only one kind of delegation. It was called unconstrained, which means you can pretend to be anybody. Hi, I'm Tyler and I'm a domain controller today. And next thing you know, you've owned everything. So, you got to turn off the unconstrained delegation. There is constrained delegation that has a couple settings that you don't want, but if you turn off unconstrained delegation, you're going to do a lot of good for yourself.

All right, so where do we go with our baselines? First, start with the Microsoft Aines. download them, review them, find the ones that have low impact that aren't going to cause incidents to turn them on and start turning those on. You know, do your change control, get them turned on. And then you have to balance that with risk. Anything bigger that's going to require time, get those get the information in front of your leaders, start getting that sorted through. Deploy stuff to non-correct servers first. Find a test server, find something. Coordinate with your departments as you deploy it. You don't want to make anybody mad because they will come after you. Ask me how I know.

and then start looking at STIGs. Like I said, I really like STIGs. If you're into CS benchmarks, you do your thing. That's fine. All right, let's talk about passwords. So, NIST did some awesome stuff a couple years ago and they released new password guidelines. In those kind of just like recap of it, they said that password length is better than complexity, so get rid of complexity. They recommended bad password lists. I don't know about you guys, but there weren't a lot of products that did that back when they suggested that. So, that's a hard one. And then they recommended passwordless or pass keys. Well, we're talking about on-prem AD. So, I'm not sure how that's going to

work either because there's not a lot of passwordless options for AD. So, and then they also said forced uh expiration for passwords is not a good idea, which means don't force reset your users like every 90 days. All right. So, what do we do about these settings? Well, let's start with a bad password list a little bit. Well, the truth is Oops. Microsoft has had these forever. uh they've had them as password filters. The downside, if you were to go to that link that I kind of hiberate out, but if you were to go to that link, it literally just tells you how to program your own password filter, which just sounds absolutely insane because if you

get it wrong, you get blue screens. So, don't do that. Nowadays, we have Entra password protection, formerly known as Azure password protection, and probably going to be known as like defender for co-pilot passwords in like 2 weeks or something. I don't know. They're just really about co-pilot stuff. Um, this is a cloud solution. It's not free. Does require P1 or P2 licensing, but it does work really, really, really well. The way it works, clouds reduce configuration. You build a proxy server on prem that talks to the cloud. It pulls down the settings. Then on your domain controllers, you install an agent that talks to the proxy server to pull down the settings. Why there's so many layers? The idea is so that your

domain controller wouldn't have to go all the way to the internet because your domain controllers don't talk to internet, right? We we've got Okay. Um, some other options if you don't want to spend the money on P1 or P2 licensing, there are some open source tools. Lithnet password manager or password protection. I like their products. They have some really cool stuff. Um, there's no screenshots of it because it's literally like you run the command and it's on. So, um, it's really cool. The other one I just have to throw on there because I love it. Um, it's passfilt built by a guy named Ryan Reese who is an engineer at Microsoft. It is not a

Microsoft tool. It's just written by a Microsoft guy. It has been around for ages and he updated it like a few years ago and it's really actually competitive now. It's like skill uh uh service- wise. So, I'm going to make you guys mad next. Let's talk about pass keys passwordless or just talk about MFA in general. So most MFA solutions for on-prem are security theater. Why? You're just protecting RDP. That's like putting a lock on your front door and not even just leaving your back door just wide open. Somebody's going to walk in still. RDP is great to secure it, but we like the the MFA and the passwordless solutions and and stuff like that.

password list doesn't look translate to on prim and MFA on the front door just doesn't matter. I have nothing against MFA in general, but that's just not enough for actual security. The downside is auditors love MFA. So, we're we're going to struggle. Now, going to the Pasis thing real quick. Microsoft says you should not sync privilege accounts and I agree with them in certain contexts. So, we can't do some of the Microsoft things. So, what do you do for MFA or for pass keys? Well, first of all, Duo does have a free tier, so use that if you just want to get the auditors off your back. I'm just going to say that if you are syncing

some stuff, use MFA, Microsoft MFA intra. But the big one, search base off. This doesn't get this does not get enough love. It's pretty good. It doesn't do all the security things, but it's pretty good. And it's actually fairly easy to set up. The PKI is the hard part there. Uh, and I say smart cards, get UB keys. Nobody uses smart card. Um, but it works really well. All right, so kind of like a real quick rehash of password stuff and then we'll go on to a little bit more. So, first of all, use fine grain password policies if you're not. Uh, fine grain. So, normally in AD you have one password policy to rule them all.

Well, fine grain password policies, you can spread that out a little bit. So, what I recommend uh to kind of meet the guidelines out there is start with three policies. You have one that's for users that's 16 characters or bust. One for your privilege users that's 21 characters and your service accounts get 32. It's how I like that's how I do it. The other thing I'm going to throw out there so one of my pentester friends really hated this option is changing lockout policies. He's like but the brute force attacks. I was like yeah but help desk calls. Um so change your lockout policies. Most compliance tools will say like 3 to five. And if you have to be

compliant, do what you got to do. But if you can get away with it, bump it up to 15. I say the rule 15 rule is 15 bad passwords in 15 minutes locks you out for 15 minutes. Keeping it simple. You can change those numbers to fit your stuff. Brute forcing is still an issue, but with these numbers, it's not like an extreme issue. It's not like you're just turning it off. Yes, there's a greater chance of brute forcing. That's where the monitoring comes in. Just pay attention to what's going on. Look at what's happening. And you will you will make a lot of people happy. Like you will win hearts and minds by doing this

because your help desk team will love you. All right, let's talk about the fun stuff. It's hard. Let's do some hardening of ad. This is where normally somebody like spends the rest of their time talking about taring. So I have three slides about taring, but I'm not going to talk much more about it. I love taring. I love the concept of like separating the tiers and and securing the different tiers different ways. The problem is everybody talks about it. So there's a plethora of content about taring, but nobody ever finishes their taring projects. I've never seen it done. I've done two of them and I've never been able to finish. And the challenge that creates is you

get this kind of false sense of security that now my environment is secure. I've tiered it. It's secure, but the holes are still there. But it's a good process. So where do we go? If it doesn't work, why are we still doing it? It does work. You do it right. My recommendation, don't boil the ocean. Start with your tier zero. Start with the biggest, scariest accounts and find them. So, your domain admins, your account operators. Please don't use account operators. Uh this is your global admins. Those kind of things. Find those. Get them dedicated accounts for that privileged access. Get them off. If they're checking email with it, that's wrong. You should only manage tiered systems with tiered

accounts. And then find where those dependencies are. That one is where things fall apart with taring projects. People don't ever do that next step. How much access does SECM have on a domain controller? Scum. What about your EDR? Well, we can't touch EDRs. They're they're perfect. They're they're flawless. We we we have to trust them. Well, that's what happens when don't you can't trust anything. Zero trust, right? We're putting these stuff on our stuff and we're not actually looking at them and securing them fully. So, we got to be aware of that. So, we're going to get started with tiers. Um, I recommend secure jump posts first. All of my security friends hate me recommending that because like you

have to go pause. Pause the same problem as tearing. If you don't go all the way, you leave a lot of vulnerability vulnerability holes. So, just admit from the beginning that we're going to be doing secure jump hosts and you'll save yourself some time and frustration. Graduate to pause. That's where I want you to go. Um, use the protected admins group or sorry, protected users group. Um, this one does not get a lot of love and the reason is is because people have had bad bad experiences with it. If you're intelligent and smart about how you set it up, you will have a really successful deployment. Uh, generally just do it with your highly privileged

stuff first. Do your tier zero and don't worry about anything else. Do not put your break glass, your said 500 account in there or um service accounts. you'll cause some issues. And then I said it already, please use dedicated accounts for your privilege management. Please don't check your email. That kind of stuff. All right, real quick. How do I find this tier zero? I recommended that earlier. You find it. I want to recommend two tools. They both might trip edrs, but one of them definitely will. The first one is Saras's uh forest druid. It's a free tool. It does very similar things to the other one which is Blood Hound that does like attack path

mapping and it tells you these things. Um they both have pros and cons. The Simpish one is less likely to trip EDR and it's a good place to start kind of playing with it. It's free download, super easy to get set up. Just kind of requires some work kind of getting it to really show everything you want to see. All right. Something doesn't get talked about much is auditing ACL's. Um there's a lot of things that you can get access to an ad that gives you a lot of control over the domain. So rather than listing this whole thing, look at places where privilege lives. That's those places. But the one I want to draw

everybody's attention to is the executive users owe you. We talk about securing admins. We talk about securing privilege. If somebody compromises your CEO's account or your CFO's account, is that bad? What's the consequences of that? I'm not saying go full in in securing them like you would a domain admin necessarily, but at least monitor that OU for strange things. Uh risky permissions. What permissions should I pay attention to? Well, mostly full control. Full control gets thrown around so much and it's not needed most of the time. Find full control and start getting rid of it. What stuff has too much? So, and accounts probably wasn't the right word here, but basically, if you're looking at these ACL's, you see these groups

that have everybody in the environment in them, that's usually not good. Your domain users, authenticated users. Uh, the two things I want to point out, though, is everyone, which is on a lot of places that shouldn't be, so get it off there. And the pre Windows 2000 compatible access group. That group has been around since pre Windows 2000. And the idea is it gives a lot of access in the domain. and by default either everyone or authenticated users is in it and it's just too much permission. So start ripping that out and you'll save yourself a lot of headaches. How do we audit an all these ACL? I want to recommend a couple of tools. The

first one is by a friend of mine. Uh he's a pin tester. He's been doing this for a while. It's AD delegator. I hate the name, but I love the tool. It is specifically focused on finding permissions or and ACL's that are compromised usually during attacks and pin tests. So he really focuses on the things that actually matter. The other one is the ADA ACL scanner. It's very similar except it just dumps out all your ACL into a big report and so it makes it a little bit easier to view. I recommend using either of them. There's a decent chance it'll make your EDR a little upset though. All right, let's talk about hardening service accounts for a minute. So, what

is a service account? Talking about like traditional on-prem stuff, let's not talk about onre because that could take forever. Um, well, a service account is account that runs a service or has a spin. What's a spin? A spin is a service principle name. Service principle names are part of the three-headed dog of Keraros. So, Cerberus, Keraros, same thing. You have the client uh the KDC, the domain controller head. You have the client head, which is the part that's requesting access. And you have the server or service as I like to say more because I think it's more accurate. That is the thing being requested access to. And so SPNs are the means of identifying services on a Microsoft network. They

have a kind of a standard format. There's a whole bunch of them out there. Well, what do we do? How do we what do we do once we start finding these service accounts? How do we harden them? Well, first you have to find them which is a whole thing by itself like literally you can do an entire talk on hard on just finding service accounts. I have a article in the notes a friend of mine wrote that is wonderful. It's probably like it should be like printed and put into every 80 training everywhere. Um it's really good for that. The next thing is find those service accounts with passwords that are older than 365 days and reset the passwords.

Obviously work for the teams. You'll create outages if you don't, but get those 365 passwords out of there because they're going to be too old. Find any account that's not a dedicated service account that has a spin and get rid of it spin or make it a dedicated service account. There's queries for do that. They're in my notes, don't worry. You can find them there. Um, find accounts that have accesses log on a service. Um, that's a little bit harder to do because you have to go look at those individually, but it's worth doing. But the big one is use manage service accounts. So, I'm going to talk about two types of managed service accounts. Uh, the first

is group manage service accounts. If you're not using these, this is a bandwagon to get onto. They manage their own passwords. They manage their own service principles and they're non-interactive by design. You cannot log into them interactively. You can get a shell if you're crazy and use PS exact, but don't do that. They work on multiple systems. They are extremely hard to kerost, which is the primary attack against service accounts. The big downside with them is they're Windows only. Now, there are some articles out there saying that you can do them with Linux and stuff. It's not supported, so I don't recommend it, but you do what you want to do. These are great. If

you're not using them, please start using them. Um, you'll run into challenges with applications that request passwords. Like you'll it like puts a password prompt up there wanting the username and password. A lot of times those won't work work with GMSAs. So that's where they kind of struggle. App vendors still struggle with GMSAs for some crazy reason. The other one I'm going to talk about is brand new and I'm I'm going to talk about it, but I'm going to tell you not to use it yet because I think server 2025 needs a little bit more love before it should be prime time in production. But these are DMSs, delegated managed service accounts. Uh these are straight up black magic.

Like I just they blow my mind. So the idea here is rather than replacing service accounts with GMSAs, let's link the two together and completely abandon the traditional service accounts password. They're completely not used anymore. So the way that works is you set up the DMSA and you point it to the service account. Then when the authentication occurs behind the scenes, AD detects that, oh, it's a legacy service account. It uses machine identity and machine authentication to determine that that's actually coming from a valid source. And in in the network stuff, it flips the password to use the DMSAs instead. So the service account has no idea this is happening and just everything goes on as normal.

It's really neat. It's brand new. I am not an expert on it, but I put links in the stuff from people who are. Did have one big exploit with bad successor. I think that's mostly been patched now, but there's still some access issues that can still cause it. So, recommend taking a look at those, but give 25 some time to bake. So, talking about access, let's talk about local admin accounts. So, who here uses Laps? Who here knows that Microsoft changed Laps a couple years ago? Yeah. Um, Laps is amazing. If you're not using it or something like it, I recommend it. So, there's two versions of Laps. There's legacy Laps, which has been around for a while, and there is

Windows Laps, which is not been around as long as the new one that they released. Um, the big difference there is legacy labs required you downloading the agent, installing it, whereas Windows Laps is now included inside of Windows. Um, they both require a schema update, which is not as scary as it sounds, but they're different schema updates. Like, thanks, Microsoft. I know why they did it, but still, it's just frustrating. The kind of big limitation with both of them is they really only affect one user, which is usually the SID 500 built-in administrator, local administrator account. Um, they're really good. I recommend using it. I don't really care which one you use, though. Windows Flaps is much better.

old laps stored it in plain store the password in plain text in ad which sounds terrible it was like pro like ACL protected but still Windows lapse much better could do auto rotation it's good so I recommend using laps if you can the other one worth talking about is just hardening your local admins in general I recommend removing domain admins from local admins on systems it's not strictly necessary but just get out of the habit of using your domain admins everywhere that's the idea uh create a GPO to block your block your privilege login to the client systems and please just get your users out of domain or out of admins. I know that's like way easier

said than done but it's you're going to do a lot of work like you can do all these things. You can set up app locker on your endpoints and make it where nothing can get into them but if people have local admin they can just go around it. So you need to start backing that off if you can. I know it's hard trust me you'll have exceptions just how the world goes. So, let's talk about kind of our overall action plan as we wrap up here. First, if you don't have backups, get them now. Start testing them. Baselines, start with low impact, work your way up. Harden your tier zero admins. So, that means find them. Give them dedicated

accounts. Harden your users with spins. Get this get the service principal name off of them or give them a dedicated uh administrative account. Deploy labs and then start working on your audit policies. And then from there, where do you go from there? Honestly, the world's world's your oyster. Go where you want. The next thing I would recommend though, start running Purple Knight or Pain Castle. They're both free vulnerability scanning tools for AD. They're both really really good. Um, what they recommend, start working on that. Uh, if you're running Active Directory Certificate Services, please look at Locksmith. Uh, Locksmith 2 is on its way out, but Locksmith is a great tool. The dev puts a lot of energy into it. It's a

really, really great tool. do your scap scans, look at your backups again, and then start working your big projects. So, it'll take time. Just start one thing at a time. That's kind of you have to the with the cyber uh the securing of AD that I've done, I've done it really methodically, like one step at a time, slow and you build that momentum and it starts becoming this like you kind of like juggernaut. You're just charging through things at that point. All right, that's all I have for today. So you uh I will have the GitHub uh will have my slide deck. Um also I recommend checking out the R Active Directory wiki. Uh I spent a lot of time curating

that. I've got thousands of resources on there at this point. A lot of tools that we've reviewed. That's good stuff. Um hit me up on any of the socials. Um and then um QR codes, my LinkedIn and GitHub also.