
You all have highlighted for the entire day. Yes, I know this is a sexy topic. I'm really excited to be here. Just a little bit about me. My name is Adam Steve. I actually live on the weekends in Utah. I'm on the road every single week. I've been on both coasts this week. I started in Virginia, Washington, D.C. and now my flight goes back home later tonight. So it's just like this every week. I work for Opportunity. I do identity and access management and security. So the problem I see most organizations is you have your identity management folks and you have your InfoSec folks and they hate each other. That's pretty much how it works.
So at the end of the day, what? really does. It's just admin want. It's not a beer. What they really want is getting loved by an auditor. That's really why we work so hard. It's so that when we get audited, We don't get yelled at. So ultimately, why do system that admin to do security and still they pass an audit? It really is. Okay. So I'm going to split this talk in two. The first half we're going to kind of talk about what are the trends in Active Directory, kind of why some of these mistakes are happening because of where we're going and system administrators that aren't on where we're going. They're not keeping up. In the second half, we'll talk about
those top 10 things that commonly I see in organizations. And I work with Fortune 500 organizations and small pop shops. These consistent things that when I walk in, I'm like, yep. Sorry, guys. To be honest, I've yet to walk into an environment and go, good job, good job.
I'll even walk in right after Microsoft leaves and it's still a mess. So let's talk about the... So first off, why do organizations even want Active Directory? What do companies use Active Directory for today? So it comes down to one of a couple reasons. First, they want to do authorization
and authentication. Authentication, who can tell me the difference between authorization and authentication? Wait, wait, I got tickets. Go for it. So authentication is who you are, authorization is what you can do. Yeah, what you have access to. Absolutely right, thank you. So the next big thing we see is device management. Now, device management, when it comes to vulnerability management, it comes down to usually one of two things. The reason why a box is vulnerable is one of two reasons. It's either a missing patch or a bad configuration setting. Usually pretty much it's one of those two things. Okay? So most organizations when it comes to Windows machines use group policies to an active directory to enforce those security
settings on their computers. Now in most organizations, One of the common problems I see is you have someone, executive that's a little special snowflake that went out to Best Buy on a weekend and went and bought a Mac. And now what you have in these organizations is this organization does really well at Microsoft patch management, configuration management, but they don't do very well at Mac. So a lot of organizations struggle, and the problem I have is is a lot of these executives that go out like Matt on their own are your high value targets. It's the CFO in the company. So, you know, something to think about is how do I create this global organization-wide program that's consistent across any device you do, whether it's a mobile device or
whether it's a Linux server. It doesn't matter as long as it's consistent. Now, there are all these applications that are out in the cloud, okay? So you've got Salesforce.com, you've got ADP, you've got all these applications now. And all of your users are like, I need access to these applications. Well, it's not uncommon for me to go into an organization and see that, hey, when a new user is created, when they're first hired in the company, it takes help desk. over two hours per user to go and create every one of their accounts they need to do their job. 50 separate accounts is not, I would say, is not uncommon. They need 50 separate application accounts to do their job.
Most organizations are going, wait, hold on, this is literally taking us, costing an organization millions of dollars in man hours just to manage all of this. A lot of organizations are, hey, can we figure out how to consolidate this down with active directory? And the biggest problem I see is not the provisioning of the users. The biggest problem I see is the deprovisioning of those users. So when the person leaves the company, how do we turn off all their access in a timely manner? Also,
When it comes to information about you, about you as the user, okay, what's your first name? What's your last name? What your job title is? Is active directory typically the most authoritative source for that information? Where do you typically see the most authoritative source for what your job title is? HR or HR. Yeah, it's your HR system.
with keeping attribute information synced up between all these different applications. You saw all those different applications like Salesforce and most organizations are going to role-based authentication and authorization. They're doing role-based management. Here's your job role, here's your access. Well, when you have all these 50 different applications, You need to make sure that your job title is up to date and current because you want to make sure that the second you switch roles, that access follows you. You have some type of automated system that can enforce role-based management. I know even if those of you that work at small companies going, how can I do this? This sounds like only big companies have these problems. No. Even really
small companies have the same problem. End of the day, how do I link them all together? I have all these different systems that I got to link together with this attribute information. And typically what we see now is in most organizations are now driving it to Active Directory and then Active Directory is pushing data back out to these other systems. So for example, your telephone number, the most important source of your telephone number might be in the phone system, And that pushes it into Active Directory. And then you have some type of layer that will sync that data back into the HR system. You know, common applications that we're seeing that are using these methods, these are Okta,
Ping Identity, Microsoft Identity Management, otherwise known as MIM or FIM. Microsoft loves acronyms that make absolutely no sense.
Or in a lot of organizations, they've just written their own PowerShell scripts or VB scripts to keep all this data in sync between these applications.
So how does it work in a lot of organizations? This is just an example. Basically, a user just logs into a portal with their Active Directory credentials. Once they log into that portal, they then can just select their application. Most of the vendors support integration with web applications in two ways. The first is federation. That kind of built-in way, like with SAML or OAuth or OpenID. These are these industry standards now that allow us to easily integrate with Active Directory or some type of other identity source. The other way that these applications, these common vendors will do is that don't support it is via web injection. And they'll actually inject a username and they'll inject
a password. And so someone from help desk has to go in and manually type in that username and password or has to have the user set the username and password. But they only have to log in once. Once it's in, they just click the application. So they have that single sign-on experience. So we talked about federation. So basically, if I'm trying to go to salesforce.com, it sees that I'm not authenticated. So then we push you back to your own identity provider and ask you to authenticate. Usually that's like an active directory that they've installed, Active Directory Federation or an Okta or a King. you authenticate against that, then you return back to Salesforce.com, and now you can present
your credentials. The way we do file security today in Windows is broken. It really is. The reason why it's broken is what happens if you go to a file share and you have some really sensitive data with a lot of credit cards into it, You've spent all this time walking down that file server. You've spent time turning on logging so you can see who's logging it, who's touching it and everything. What happens if a user hits control C and then goes to another location and just pastes that file into a different location? What happens to the security? Does the security follow that file? No, the security does not follow the file. This is a huge problem because in organizations,
when we go out and do data loss prevention scans and we see where the sensitive data is, every time I've done one of these data loss prevention scans to identify where the credit cards are on the entire network, every single time they come back and go, oh, I had no idea we had credit card data there. I had no idea. And that's usually what happens is security doesn't follow files. Now, building to Windows now, we have this new option of dynamic access control, which gives you the ability built in for free. This isn't buying a third-party utility. There are third-party utilities that can expand this functionality, but built in, you have the ability to do Content-aware
file security. So basically, when you go save a file on a file server, the file server actually scans the file. It looks inside the file and goes, whoa, there's a credit card in that file. So I'm going to stamp a meta tag on that file and now attach that whenever you try to access that file, it looks at those meta tags. It checks into Active Directory In an Active Directory, you can say, okay, only members of this group can access any file in the entire organization that has a meta tag of credit card data. And it doesn't matter where that file lives now. If you copy that file into a different file location, the security moves with it because it's content-aware
file security.
basically just how you set up Content Awareness and setting these tags.
What's nice is when a regulatory auditor comes in. You have a PCI auditor or you have a FFIEC auditor come in for, or a FINRA compliant auditor come in. When they come in to audit you, they'll say, well, where is that sensitive data on your network? Well now I literally go into the windows and just hit print on a report and it prints a nice little report of exactly, okay, here's the location of every file that has a social security number in the entire network. Usually when I hand them that report they usually fall out of the chair. They always get this big smile and literally I have gotten hugs for this. Now, also, when you set up this meta tag, set up this information and stuff,
you can now set up intelligent rules, okay? So you can actually say, okay, no one has touched this file in 10 years. Automatically
delete the file or automatically archive it up to an AWS
S3 storage or automatically take it off our network. Ultimately, you want to get stale data off your network. So you now have the ability to create these automated rules that automatically, dynamically help move your data around for you and get off your network. The other big hot topic that you're hearing, Gartner says that this is one of the hottest topics of 2017. This is adaptive authentication. Can anyone explain what adaptive authentication is?
No? The hottest topic in 2017, not even for a red ticket? You already got one. Oh, okay, over here, over here. So adaptive authentication will take a number of factors before it starts applying multi-factor authentication. So for example, your IP address, have you looked in from this IP before, yes or no, and maybe we can force you to ask you for a second factor or third factor. So how does it augment multi-factor authentication? Is it replacing it or is it enhancing it? It's enhancing it. It's adding additional analytics to a multi-factor. So in a lot of organizations, what they'll do is say, I'm going to start building rules, so I'm not just going to force everyone to do two-factor authentication. What I'm going to do is
I'm going to build rules. And I'm going to only force them to do multi-factor authentication, you know, log in with their, have an app on their cell phone or a little token attached to their key chain. I'm only going to see that if they're logging in from like an outside network or they're logging in from an IP address in China or based on all these conditions. Some of the other big players in the market are even getting smarter than that. and using adaptive authentication on websites to get rid of passwords altogether. Yes, they are actually removing passwords off of websites. And the way they do this is when you go and log into a website, they look at your IP address, they look at
what time you're logging in, they actually fingerprint any data that your browser will deliver to the web server, they're logging. So this includes what what fonts you have installed, okay? It also records the rhythm that you have your password, your password cadence. If I type in my password, if I have a password, a password one, yes, that is the password I use, and you try to type the password of password one, it is very difficult for him to type the password exactly the same rhythm that I type the password. And so you can start actually identifying people. You can start building reputations based on sessions. So the next thing you come back to the site,
you can actually create a risk score of and be able to fingerprint and say, oh, I know that this is that same person that logged in before. I know it's him because all these factors have not changed. So I'm going to go ahead and let them log in without a password. It's a very hot topic right now. End users are raving about it right now. I'm working for one of the top five hotel chains in the world, and they're having problems with the use of CAPTCHA in Asian countries. This is really difficult for, in Asia, doing CAPTCHA information. It's hard to just tilt an Asian character on its side You know, it doesn't work as well. So let's talk about those top 10
mistakes. Okay, I know the joke everyone in this room is thinking right now. The first mistake that companies make in Active Directory is using Microsoft. Let's spit it out of the room. I don't know if it exists right. Okay, so. No, no, no, no, no, okay. So really, you know, we talked about, as we talked about before, the concept of creating a way, an automated way to keep active information. And then, like we talked about before, content aware file security. I can make decisions now, not just based on security groups. I can say only members, only people with this job title are allowed to access this file. Other, like in SharePoint, other ways, claims-based authentication, where you're making a claim, you're not using security groups yet. You're
using attribute information. When you go this direction, syncing attribute data is more and more important. You can't have still data in your active directory.
The next one is what we talked about before. the problem of more and more organizations using a lot of different kinds of devices. And then helpdesk saying, we only support Windows, sorry. It's very common. So how do you have this consistent support answer for mobile devices, iOS, Android devices? How are you gonna handle patch management to these devices? How are you going to do secure configuration management to these devices? You can have a consistent response because endpoint security is huge. I mean, it really is huge.
Ooh, this next one. So one of the other things is, one of the other common problems is fragmented authentication stores. So your Windows folks, they use Active Directory. Your Linux people, they spin up their own open LDAP. You might have your Apple folks spin up their own Apple identity server. Okay? So now you have, what forensically, if someone, if a bad guy gets in, forensically, I have to now pull all these different authentication stores to find out and merge all these log files. It makes sense for an organization to centralize their authentication. Even if they can't centralize their authorization, it makes sense to centralize authentication. So to have your Macs authenticated against Active Directory makes sense. To have your Cisco
devices authenticated against Active Directory through Radius makes sense. A lot of organizations are moving towards this. the first response I hear from network admins is, well, I would never do this because I do not want to give control, I don't want to give the ability for a domain admin to log into a Cisco device. Well, when you set up security, you can make it so that security is not inherited. So you can actually make it so that for certain objects in Active Directory, A domain admin does not have access to it. So put a lot of thought in when you're creating an identity and access management system to create locations where maybe domain admins don't have access.
Okay so Mimikatz. Who can explain what Mimikatz is?
It's a tool that can be ran on any Windows machine that pulls the hashes and passwords and user names of the machines in the LSAT system. Yes. It is one of the, in the last 10 years, one of the most evilest and coolest tools at the same time. I love this. So you can see here in the screenshot here from the tool. So I ran this tool, this tool, And you can see here, what it did is it went out, it saw this username, here's the username. It shows me what that person's ID number is, their SID, okay? It tells me what domain it is, and it's able to actually show what the actual password hash is. Does Active Directory actually store the actual password
in the database? No. It doesn't actually store the actual password. What it does, when you type your password in it, it runs it through an encryption algorithm and that big, long, nasty, long random text output, that's what we store in Active Directory. We store the password hash in Active Directory. Lots of problems with password hashes right now as computers are becoming stronger and stronger and storage is becoming cheaper and cheaper. creating databases of those password hashes. So basically if a password is less than 10 characters today, I can look it up in a database in under 30 seconds if I can get a hold of that hash. So if I can get my hands on that
hash, game's over. Well, but with Maniacats it goes a step further. It actually looks in a memory for unencrypted passwords. You can see here at the very bottom, it actually was able to grab the password out of memory. The problem with MemeCats is the patch that Microsoft released, if you just install a patch, it doesn't protect you against MemeCats. There's additional steps that you have to take. You need to follow this Microsoft KB article. Did I put it up there? Yes. Follow that Microsoft KB article. after you apply and make sure that you've set up the special security groups that you need to protect against this. This is a common problem that I see. For those that are taking pictures, if anyone just leaves me
your contact information, business card or whatever afterwards, I'm more than happy to email these slides out so you don't have to take rigor, you know. Yes.
I'm more than happy to share these slides out for you guys.
Next one. It drives me crazy, okay? When I go into a organization and I go and talk to one of the domain administrators and I see that he's logged into his desktop with domain administrator. I want to kill him. Because what happens if his machine gets a virus? Oh yes, it happens, everything goes sideways, and your life is horrible because all of a sudden your domain admin now got hit with CryptoLocker, and now everything's hit with CryptoLocker, and yes, yes, it is ugly and it's nasty. You never want to allow your Your domain admin should be logging into their own machine with what's referred to as a privileged account. So every domain administrator, anyone, not just domain administrators, anyone that requires privileged access or elevated
access, okay, anyone that requires elevated access should be using two sets of credentials. They should be logging into their computer as a regular user, and then they should be doing run ads or logging into a jump server with their elevated credentials. Microsoft now,
their reference architecture that Microsoft recommends now is to actually make three tiers. Is to actually make the first tier of just domain controllers, the second tier of just servers, and the third tier of endpoints. What you do is you make it so that you can only log into that tier with those accounts. So domain admins cannot log into a workstation. Domain admins cannot log into a server. They can only log into other domain controllers. You make it so that a server administrator cannot log into a workstation. And you do this by removing interactive login, and setting up some other things. If you want to learn more about this design, just Google the Microsoft reference architecture for active directory.
So what I typically see in organizations when they set separate accounts, we want to make it so it's easy and searchable. So that's why I recommend that you do a panda at the very beginning of the username some type of standard, so like A dash or ADM dash, so it's easy to be able to search for those kinds of accounts. Doesn't that mean an attacker can do the same? Explain. If I know that all admin accounts are going to start with ADM dash, as I move laterally and I'm looking for accounts, that means that kind of narrows down my scope. But as an attacker, when I do pin testing, One of the first things I do is enumerate domain admin. Okay? So I look
there and then I see what other groups that domain admin is a member of. And usually based off the group name, I can pretty much tell if that group is giving privileged access. So my question to you is yes, you are correct. but I don't think it's very difficult to do today without it.
Another very common mistake that I see, this is very common, is Windows time. As we start to put more systems authenticating against active directory, it is more and more important that Windows time be completely consistent across the organization. I have seen inconsistent Windows time cause numerous of problems around the organization. Like for example, random filled logins, taking 10 minutes to log into a desktop have been attributed back to time, okay? So what you want to do is all of your workstations get their time from a domain controller. That's default, okay? All of the domain controllers get their time from a special domain controller that's referred to as a PVC, the primary domain controller. You can only have one of those in the entire forest, okay?
So all of the domain controllers contact the PVC and say, I'm going to pull my time from you. Then what you have to do is first off you need to configure that primary domain controller to point to an external time source. Then you also need to configure that primary domain controller to be, to tell it, you have to set seven different registry keys to tell it that it is really an authoritative time server. And the way you do that, those are those seven keys. And if you follow that Microsoft KB article there at the top,
That will tell you exactly the actual, there at the bottom, that's the actual command that you need to actually issue from the command line of the primary domain controller. I actually, what I do in my organizations is I create a group policy that does a WMI lookup to determine who the PDC is and then it applies a group policy that automatically sets that.
to just the PVC. Yeah, go for it. Wouldn't you want your domain controller a little more isolated and segmented than talking to an external server for time? So that there's not a way in directly from the internet to your domain.
What's your thoughts on that? You can have your own time with clients. You can. You can purchase your own authoritative time server that is authoritative. The important part is you need to, Your PDC needs to be pointed to some type of a forward of time source. The problem we have with most domain controllers today are virtualized. The problem with virtualization is that the time within an operating system is counted by clock cycles. And as we're time shifting processing through virtualization, it causes minor discrepancies in time.
Those discrepancies in time can build up over time. And so the time can be slightly off between your domain controllers. Which doesn't sound like a huge deal, but if you're doing a forensic investigation, and I've had to do forensic investigations in the past before that have led to litigation and it goes to court, you have to show that all of your log files really do line up. You know, even a half a second in a log file can make a huge difference.
Windows PKI or Windows Microsoft Certificate Services, over 90% of organizations I see have Microsoft Certificate Services installed. One of the reasons why you need to install Microsoft Certificate Services or some other PKI solution in your organization is if you want authentication to go over LDAP encrypted, it needs a certificate on the domain control. So see how it says LDAT SSL? Okay. See how it says port 636? Port 636 does not open on domain controller unless a certificate is installed on the domain controller. So if it doesn't have a certificate, you will only see port 389 open. You will not see port 636. So it does not allow the ability to encrypt authentication requests that come over LDAT binds.
Also, Microsoft has also said that when replication is occurring over between your domain controllers, if you do not have an SSL certificate installed on the domain controller, the replication is not encrypted.
Token blue. I'm not talking about my wife.
Okay? Token blue. Now, when you authenticate, okay, you log in, you're given a Kerberos ticket. Think of it as your ticket, okay? And if I want to access a resource in Windows, what I do when the ticket was given to me from the domain controller, on it was stamped my username and all the groups that I'm a member of. And so if I go access a resource with that, with that Kerbos ticket, the resource looks at your ticket and goes, oh, you're authorized for this resource because I see that this, you're a member of this security group stamped on your ticket. That was also one of the big problems with Mimi Cats is using Mimi Cats, you could actually forge tickets and do
golden ticket attacks. So you could forge your own Kerbos ticket.
So what happens over time is as an organization gets more and more groups, they use more and more groups in their organization, there's a finite limit on how big that TURBRO's ticket can be by default. The max size that that ticket can be is only 10K. And it's not uncommon in organizations that they will have too many groups. All of a sudden, a user tries to access a resource and won't let them access the resource. The problem is it's not that he's not a member of the right security group. The problem is that he ran out of space on his Kerbos ticket to have all of his groups stamped on it. So you need to monitor and watch to see what the biggest ticket
size in your organization is. If you follow that Microsoft K-DEPA article there at the bottom, that will tell you how to monitor how to run the script. That will go out and query every user in your organization and tell you what the biggest ticket sign is. If you do have users that have bigger than that 10K, there are things that you can do to increase it. More modern operating systems like Windows 2012 out of the box have come with an increased limit. But pretty much functionally, there's a hard cap right around 47K. So it's just something you have to keep an eye on. And it really depends what kind of group you're using. For example, when you create
a group, there's several kinds of groups. There's domain.local groups, which means that you don't only have members of that group that are just in that domain. You can have global groups, which means that you can You can have members of groups that are in the same forest or you can have universal groups that span multiple forests. The problem is when you use universal groups, it takes more space on the token. So just be something to be mindful. There's maintenance that you can do to reduce those ticket sizes. Yeah, I...
One of the things that keeps me busy is I go to these organizations and I do these active directory health assessments. So I see these things all the time. And one of the things that I consistently see is the problem is that Windows, active directory just runs. And it can be completely unhealthy and it still runs. The problem is that sysadmins don't consistently do everything they need to do to actually go monitor and actually go actually check the health. No one's doing the lube oil and filter every 3,000 miles on Active Directory. So typically the tools that I use to say if my Active Directory is healthy, the things I use at least once a week is DC Diag, everyone does that.
You want to make sure that replication's not broken. That's my spread admin tool. Microsoft actually released instead of using that ugly little command line tool here at the bottom, I like pretty little GUIs. Yes. Yes, I do. I do like pretty little GUIs. And so Microsoft released this tool that made this nice little GUI for replication.
The way that Microsoft Active Directory replication now is using a mechanism called DFS. It's the same DFS that we use for file replication as well. And so we need to make sure that file replication is working in your environment. Or if it breaks, replication breaks between your domain controllers. So that's another thing that you need to, using the DFS diag tool. There's this myth that when you remove a domain controller from a domain, that you're done. I wish that I could honestly say that Microsoft did a good job of cleaning work, cleanly removing a domain controller when you remove it, it doesn't. It is not uncommon for bits and pieces of it to still exist. And
domain controllers still trying to replicate to it even though it's gone.
If you follow this Microsoft article here, it'll tell you a complete step-to-step guide of the locations that you should look to make sure that you don't have any orphaned domain controllers, domain controllers that no longer exist. It tells you the locations with ADSI edit you're going to need to look at, the locations in DNS, all of these things that fragments can remain that can cause your Active Directory to not be healthy. Another common thing is when you log in, you need to specify what subnets should authenticate to what domain controllers. And if you don't go in and specify what subnets should be talking to what domain controllers, you can live in a condition of where your employees in Asia,
even though there's a domain controller sitting in Asia, they're coming all the way to the U.S. to authenticate because it just randomly picks one. if it's subnet, it's not defined. That can also cause issues.
Missing SRV records, that's another common thing. When you turn your computer on, the first thing it's going to do is query DNS of giving you a list of those domain controllers. Those are actually called SRV records in DNS, and sometimes, You can have missing SRV records or you can have orphaned domain controllers still exist with SRV records.
Okay, so I go into an organization and I go to the help desk and I see that everyone in help desk is a domain admin. And I ask them, why do you need to be a domain admin? They're like, well, don't you have to log into a domain controller to be able to create users? No. If you download the Microsoft Remote Server Administration Toolkit, you can download all those tools that you need to create users on your own computer and then you just do a run as and run as your privileged user. You don't have to log into a domain controller. You would laugh how many times I say this. It's pretty funny. Remember, vulnerability management, there's three key steps to vulnerability management. You run a
vulnerability scan. That's like a tool like a Nessus or an Exposé or OpenVos. You identify, you want to focus on not just tracking what missing patches are missing in your organization. You want to track what vulnerabilities you have in your organization. Don't focus on patch management, focus on vulnerability management. So once you identify a vulnerability, you then want to go through to classifying it. What is our risk with this vulnerability? Then let's go remediate that vulnerability, whether it be a configuration setting or a patch. The next important step people tend to forget about is that arrow that goes back to the top again. is to conduct another vulnerability scan, again, to actually validate the vulnerability has actually been removed. There's a common myth
that when you install a patch, that it fixes the vulnerability. It's not uncommon for you to install a patch and a particular DLL didn't get installed correctly or a particular registry didn't get updated. So even though Microsoft says that the patch was installed, if you say, hey, is this patch just installed? Yes, patch installed correctly. If you don't check those registry keys and those DLLs, you don't know if the vulnerability is actually gone, okay? So that's why you need to conduct another vulnerability scan to actually check those. Also, if you use the free tool that's called the NVSA tool, Microsoft baseline security analyzer tool will actually check those DLLs and registry keys for those patches.
I love to upset my admins. Okay. There is an option in, since 2008, R2 that you can run a version of Windows that doesn't have a GUI. I know. It blows my Windows admins minds. They're like, well, I can't administrate anything without a GUI. I'm not a Linux guy. Come on. So what you do is you use those RSAT tools. You don't need to do everything from the command line. And the things that you do need to do from the command line is people have created these awesome PowerShell scripts that if you run this PowerShell script, see this little pretty GUI that it made? That's actually a PowerShell script here at the bottom. Microsoft released the
S config. You just type S config and it gives you this nice old school DOS menu that you can set these things. The beauty of this is you don't have Internet Explorer installed on domain controller, which means less patches, which means less late nights that we have to make change controls and stay up until 3 a.m. patching domain controllers. I love Windows Core, it's awesome. The first time an assistant logs into the box after you're upgraded, I've gotten calls saying, oh, we've got hacked. Like, there's no GUI.
Okay, here's my contact info. Any questions? More of a comment, since 2012 and 2012 R2 and 2016 now,
you can flip back and forth between server core and GUI. Good point, yes. 2008, 2008 R2, you had to install it as one of the other . Yeah, so now you can turn it on and off. I recommend turning it on. So you can do a full install in the first place, computer everything, all your pretty pictures and stuff, and then remove the GUI part . And then for troubleshooting, if you're if an assistant admin is not comfortable troubleshooting from a fan line, you can just turn it back on. I love that, by the way. Great feature. Thanks for bringing that up. Any others? Yeah. Question regarding the information that you can retrieve from an unprivileged account, is
there any way to mitigate all that information that's been out? I know you can set up. Yeah. For every object in an active directory, every single object, whether it be an account, a group, every object you can set full ACLs on. You can create an access control list for every single object, which means you can actually say only these users can even see any information about domain admin groups or
list who's a member of this group. So a great Active Directory architect will think about what accounts actually, what people actually need to see to do their job. Do they actually need to see every object in Active Directory? Should a regular user be able to list every group or every user in Active Directory? No, they shouldn't. They don't need to, but commonly people have read access across the entire course. Not every environment. Not mine. Not mine. I've seen. It was I've seen. So it's pretty much. I piss off so many pen testers. Trust me. Any other questions, guys? Great. Hey, thanks, guys. Appreciate it.