[MUSIC PLAYING] One of the most important hurdles to making the move to the cloud is security. Everybody is challenged with that. How do you address this new hybrid environment? How do you solve any of the challenges you're dealing with?
And I'm really looking forward to bringing up Randy Franklin Smith. He is a Microsoft MVP. Randy writes on Windows security issues for publications like Windows IT Pro. Everybody familiar with that?
Yeah, so if you are familiar with that-- you're already clapping. That's amazing right there. Nicely done. I do want to bring Randy up to the stage. Randy? He's our next speaker.
So when Quest gave me the choice of a topic, which is really cool when you get to do that, I said I want to do something that's really valuable. And I said, let's make a session about the one command that if you run it in your Active Directory environment, and if all of these companies that you saw in the opening video had run beforehand on their domain controllers, they would have shut down all of these attacks. They just would not have happened.
So good, I see some laptops out. You're ready. I'm going to spell this command for you. S-H-U-T.
But then I got to thinking, it's going to be a pretty short presentation. So seriously, though, if you have some chewing gum, put it in your mouth. Start chewing, because we're going to drop in altitude really fast, pretty much down to ground level, because I did want to make this a technical and practical session. So here goes.
Recent security features in Active Directory. And I think it's safe to say, and I am really happy. I want to hear from you guys later. I'll be over at some of these other venues here at Quest later. And I'd like to hear about which ones you're currently-- that you're already using.
But when I talk to your colleagues, we're not using most of these. Even though I think recent may be a little bit of a stretch, because when we look at Active Directory 2019, there's nothing to talk about, in fact, in terms of new security features. There's one really cool one that I look forward to showing you in 2016.
Now, the rest of these, believe it or not, were introduced-- when you start counting up the years-- a long time ago. But the funny thing about it is the way they were introduced in 2008, they were kind of buried. You had to use PowerShell or other commands, or sometimes there was nothing. You just had to go into ADSI edit in order to use them.
And so no momentum happened with those features. Then in 2012, they were surfaced higher in the UI and made more accessible. But we'd kind of forgotten about them by then. And I think that is maybe why most of us aren't making good use of these.
So to wit, what are we talking about? All right. In the next few minutes, we'll talk about password setting objects, authentication silos. That's probably my favorite one right there. We could be doing a lot to combat one of the things that you saw.
Did you see him typing or playing with Mimikatz in the opening video? It's a really cool video. But right there, we could knock down a lot of credential harvesting attacks. But I'm getting ahead of myself.
Dynamic access control, a way of setting up your audit policy globally for the whole forest, group managed service accounts. So managed service accounts got a bad name. That got fixed with the next version of AD. But again, we kind of lost momentum there.
So I look forward to showing you that. And then there's a couple other cool things. And I'll finish up with the most truly recent feature, and that's temporary group membership.
So password setting objects. How many of you are using those already, know what they are? OK, good. So it's good I put this in here.
Back in the day, when I was teaching Active Directory security and auditing, one of the things I always had to break to the audience is if you want more than one password policy-- so you want some users with this password policy. You want other users with a different minimum password length or password lockout policy. Multiple domains. You actually had to set up multiple domains to do that.
Well, that went away a long time ago. In 2008, we got the ability to have granular password policy. So if you want your privileged users to have stronger passwords or you want to make exceptions for a certain set of users-- very bad practice. And I hope it doesn't happen anymore.
But back in the day, your C-level executives-- we have a special requirement. We want to relieve them from ever having to change their password or even have a password, maybe. So we had to create another domain to do that. And I'm sure none of you guys ever did anything like that.
But when is this valuable? There's some interesting things going on about passwords right now. Of course, passwords are still here. We've got to deal with them. And sometimes our compliance requirements get very prescriptive and specific. And we have to implement those.
So that's one place where we could use password setting objects. The other thing is-- and this is, I'm kind of channeling BOFH here-- but users that complain. This is a feature that can really give you some satisfaction with dealing with those users that complain. I'll show you how to do this.
So this has been surfaced since Windows 2012 in the UI. And it's simply a matter of creating an object, password setting objects. You can see where it is in the screen print there. And now you get all of those same password settings that we used to only be able to configure at the domain level right there in that object.
So after you've created a password setting object, it doesn't do anything until you go down there towards the bottom and you add some groups or individual accounts. And then voila. Those users are then subject to whatever our password policy is here. And it more or less ignores what's defined at the root of the domain.
And just to level set, of course. Where do you go to configure the domain level auto policy in AD? You go to the root of the domain, and you edit that Group Policy Object. And if you've got more than one GPO there, it's whichever one takes precedence in the way you have things set up.
But once you do this, you create that group of users, stick a few members in there that you want to get back to, you can make life pretty miserable for them. So if for no other reason you use this policy, at least I've given you something that gives you a little bit of cathartic release and revenge on those folks.
So kind of a no-brainer. But assign PSOs to groups, not individual users. Do you have an overlapping group? So you have group A, group B, and some people are a member of both of those. Which PSO takes precedence?
Well, it all depends upon the precedence number that you give them. The lower the number, the higher the precedence. Meaning the lower the number, the lowest number wins.
Now, I want to say one more thing about passwords before we move on. And that is it might be time to rethink your password policy. And these decisions, unfortunately, may be kind of above our pay grade.
But I really love and want to draw attention to this Special Publication, specifically Appendix A, Strength of Memorized Secrets. A password's a memorized secret. And they couldn't just call it passwords. You know, it's the federal government, right?
So anyway, here's the point. Maybe some of you were on my webinar where I talked about this. They're saying, look, stop making users change their passwords on a regular basis. Stop requiring 20-character passwords. And don't make life miserable.
Don't create all of these dynamics that encourage humans to do the human thing and make up passwords that are easy to guess. So it's a complete rethinking of password policy. And I think it's probably going to take a long time for corporate security policies to catch up with it, because it's just throwing out the old way of thinking.
But this is based not upon anecdotal surmising of what's best for securities. It's based on evidence. It's like evidence-based medicine for passwords.
OK, let's move on. Let's talk about a setting that is the closest thing to doing what I thought of as far as my tongue-in-cheek goal for this webinar. And that is authentication silos. This could have a huge impact on the bad guys that get into our systems and then start credential harvesting attacks.
And I use that term because pass the hash is just one way that you can steal passwords. And we don't need to get into all of those other details and ways-- golden tickets and on and on. The bottom line is credentials and derivatives of credentials just are littered throughout our network.
And they have a long life. They have a long window of opportunity for the bad guys. And so here's one way where we could really compartmentalize our risk and our exposure or limit our exposure on these accounts or on these credentials.
So the thing with your average Active Directory, Windows-centric environment is that you are set up in such a way that anybody can authenticate to any other system on the network, in general. And that was the beauty of Active Directory and domains-- one user account works everywhere you go. That's a good thing.
But oftentimes, your strength can become your weakness. And so that is so true since Mimikatz and all of these other tools and methods for credential harvesting have come out. And we just make it easy. Once you've logged onto a system, your credentials are still out there months later oftentimes.
So you log on one time with an account. Then that system gets compromised, or maybe downstream another system gets compromised. They laterally move along.
They finally hit this system that you logged on to five months ago, and voila. They've got your credential. They can take over your account, whoever yours is.
So authentication silos allow you to carve that domain up a little bit for selected groups of users. Now, this is a central tenet to a method from Microsoft that's very good that's gotten a lot of press about the last year or so. And that is the Red Forest.
That's essentially what we're doing with Red Forest. But it's only there to protect our top-level domain admins. Now, if you prevent anybody, any bad guy, from getting your domain admin accounts, are you done? Would that prevent all of these attacks?
It would sure help. But there's a lot more accounts out there that we need to protect besides just our domain admin accounts. And so authentication silos are really something you should look at. Let me ask. Who's using authentication silos?
OK, good. So this is applicable. What this allows you to do is to carve out your domain. Think of all the users and groups in your domain. And these aren't just end users, of course, but everybody in IT, user accounts for applications and services, stuff like that. And then think about all the endpoints-- all the workstations, all the servers.
Should everybody be able to log on or at least authenticate to every other system on the network? Absolutely not. And so that's another thing I want you to think about here.
This isn't just about protecting privileged accounts. This is about making-- I think our networks have a little bit to learn from police states, where free travel is just not an assumption. The network out there doesn't need to be modeled after the culture that we're used to living in, because packets and user accounts and stuff like that, they don't have feelings. They're not granted all of these inalienable rights.
So let's make things a little bit harder for the bad guys. And let's figure out-- and the larger your organization, the more opportunity you have to do this. Let's come up with some demographics or sets of users and figure out that, OK, out of our 10,000 or 5,000 or 50,000 accounts out there, and as many endpoints, which systems does this group of users really need to ever authenticate to? And then let's restrict it that way.
And that's how you do it. Authentication silos. You basically take a set of users and a set of computers and say, no matter what all the other security policies are-- no matter what the log-on rights are, no matter what permissions are on file systems or whatever-- this set of users can only authenticate to this set of systems. And it will get stopped right at the domain controller before a ticket is ever created.
And that's an important point. Authentication silos only apply to Kerberos. You also need to use a group called Protected Users, because since this only applies to Kerberos, then we need to restrict these user accounts to Kerberos in the first place.
Where do you go to configure authentication silos? It's deeper than what I can get into in today's presentation. But I've got a webinar there. You're welcome to go watch it at any time.
And the thing that I want to leave you with here is to think beyond just using this to protect your admin accounts. Let's just set up some high-level boundaries within the network. Why?
Do you see what that'll do? That'll slow down lateral movement. Lateral movement is one of the critical success factors for a bad guy. So we want to take those CSFs away from the bad guy.
OK, dynamic access control. How many of you-- again I want to gauge the applicability here. And that is everything in this particular session or this feature is about-- not session, this feature section-- is kind of dependent upon file servers. So how many of you, file servers are still a going concern? You're concerned about the security on file servers? All right.
I think it's probably a little more than that, because how many of you don't have file servers anymore, and you just have everything up in OneDrive or-- well, let me ask you that. Don't have file servers, everything's up in Box or OneDrive. OK. So file servers are still a thing.
So the idea here is could we get away from folder-based access control, folder-based permissions, where-- is that really the right way to control access to files? It's location, which folder it happens to be in on a file server. Wouldn't it be better if the permissions that govern who can read that file, who can modify it, were based upon what kind of data, what kind of information was in that document?
That's what dynamic access control allows you to do. It allows you, just up at the top of your domain, it allows you to say things like, well, the only people who should be able to look at personnel data is human resources folks in general. And just think of how powerful that would be.
We don't really care about where that file ends up on our network. We're just going to set up a high-level rule that makes sense. That would solve a lot of problems.
Here's the thing, though. If we're going to implement this, this is not strictly-- or exclusively, I should say-- this is not exclusively an Active Directory feature. This is file-server based. And we need to install the File Server Resource Manager feature or role on our file servers.
Here's the other thing. You need to classify your data. And you have some fairly rudimentary capabilities within File Server Resource Manager to classify those files. You can do it either by folder or by content.
So you can code up your own regular expressions or just basic wild card rules. And then File Server Resource Manager will periodically go out there and scan every file on the volume. And then it will classify.
If it sees a Social Security number, it'll classify it as PII. If it sees a recipe for Coke, it'll classify it as-- what is it called? Intellectual property. Stuff like that. To the degree that you have third-party file classification technology, obviously you can apply that to this.
But I just want to be forthright and point out that this applies to file servers. This particular feature doesn't help you when you get to SharePoint and beyond. Now, is that to say there aren't file classification processes out there?
Obviously not. There's lots of them in the cloud. Office 365 and so on. But this session is about Active Directory. And that's where dynamic access control begins and ends, on your file server.
So with this, you build your rules, figure out your different types of users. And the other aspect to this is we get this capability for auditing. And I honestly think this may be where you would use dynamic access control first, and that is with file access auditing.
So this is just a quick screen print to show you what it looks like to set up file classification rules. And then this is pointing out that we take into account properties that you define on your files that say, OK, if we see this kind of content and classify it as such, then we take into account claims about the user. So there's a claim about the user that says, if I'm-- you set up a rule that says, if I'm a member of HR Group in AD, then I'm classified as a human resources person.
It may sound pedantic, but it's part of the settings that you make up here. And now you just make a rule up that says personnel data can be accessed by HR. Otherwise, we need to set up special exceptions for it.
So DAC is not a trivial undertaking. The classification is what makes DAC really powerful. And there's just an awesome article at somebody else's blog that, if you're interested in DAC, there's a whole series that I would suggest starting there to learn about it.
But I was already moving on to, I guess, the thing that interests me more about DAC. And that is global object access audit possibility. So this is a way of defining centrally what your audit policy should be, which files you want to audit, and what types of access to those files. And as you know, file access auditing is one of the pain points, enduring pain points, in the whole Windows environment.
So this has the potential to help a bit. And this is what it looks like. So here we are saying that, basically, if the user is a member of this group or if the device that they're even running on-- see, that's one of the other interesting things that you can do with both dynamic access control and global audit policy that I haven't mentioned yet. And that is you can define these rules based upon the type of device that they're on.
So maybe if this is a device in the call center for your health care insurance company, and this is at your-- this is a call center PC, and the user is authorized to look at this data, it's not real interesting. But wouldn't be interesting if we saw the same user accessing this data from their cell phone or some other device that is not what you would imagine a call center person using? So what could that mean?
It could mean that their credentials had been compromised. And so now that data is being accessed from some other compromised endpoint on the network. And that is exactly what a persistent attack looks like as credentials are harvested and as bad guys move from endpoint to endpoint.
So that's another aspect of this here. And maybe you can't control access with this because you're not super sure that your file classification rules are that effective. You don't want to just put all your eggs in one basket and trust dynamic access control for that-- for access control.
But it may be really useful for defining what gets audited and what gets popped up on the radar for your SOC analysts to look at. So think about that. OK.
Service accounts. Changing passwords on service counts. Pain point, right? I mean, that just is something that has bedeviled us for a long time. And it's important to do, because service accounts have a lot of authority.
Those are the trusted accounts that your applications are running as. Those are the accounts that have access to the data that you're trying to protect. And yet, they're very hard to protect because as soon as we set up an account and configure a service to start running as them, then that password is stored out there.
We know some of our admins have that password, probably, unless we are super good with privileged account management. And an admin leaves. The auditor, back when I had an auditing practice, comes in, says, why have you not changed your SQL Server service account passwords in two years?
I can see you've had two DB admins leave during that time. You can't tell me they didn't have their passwords, because I see you don't have a privileged account management system set up. And it goes on and on like that.
Well, we're afraid to change them because we don't know everything that'll get broken, and so on. So that is the problem that Managed Service Accounts-- so cross out Group-- that's the problem that Managed Service Accounts was intended to address. And it was introduced in 2008.
But nobody used it, even though it gives you-- it solves these problems. You define it one time. And now you get automated password management, your service principal names are registered, and so on. Nobody used it because it had a lot of problems.
And this is straight from this TechNet article. I love the candor with which this person wrote. He says, after we totally harshed your mellow, you didn't even bother to check to see if you could use Managed Service Accounts.
So that's why, even though this has been around a long time, we're not using it. But it's totally been improved. All these problems have been addressed in 2012 under a name that I think might do it a little bit of disservice. But it's called Group Managed Service Accounts. But basically, this is the Managed Service Account that we've always wanted and that you will come to know and love, or you will come to love as you get to know it.
Group Managed Service Accounts address all of those problems here. So you can use them on more than one server. And applications like Exchange and SQL do support Group Managed Service Accounts. They did not support MSAs. You can even use them for other things like scheduled tasks.
And they're really easy to use. It's just a matter of taking advantage of these new attributes and this new object that was added to AD. So this is the actual object that makes this possible.
Now, the cool thing is you don't have to mess with things down at this attribute level in order to use them. Next slide, I'm going to show you the PowerShell commands. But the bottom line is this allows us to set the account up.
We specify which computers or groups of computers-- that's the other beautiful thing here. You don't have to assign this to computer A, B, and C. You can associate it with a group. And as computers come and go, even transient virtual machines-- think about that-- they get the ability to use this managed service account.
There's an interval that specifies how frequently the system just automagically changes the passwords. You truly do not need to know-- you don't know-- the password of these Group Managed Service Accounts. Your DB admin leaves. Revoke their ability to log on with their account.
You don't have to worry about changing the passwords on these accounts, because you don't know it. They don't know it. It's beautiful. It's the way it should be.
How do you do it? You run a new AD service account. You then install that on whichever systems where you need it. And then you test it to make sure it works.
Then you go to whatever service accounts you need, and you put in the appropriate account name. And you need to put a little dollar sign on it so that Windows knows this is a special-- this is a Group Managed Service Account. And you're done. It's beautiful. It works. And we should be using it.
OK. Maybe you know about this. I don't know if I should really call it an AD feature. But I'm going to, because it's part of the Active Directory Administration Center tool.
And it's really simple. But sometimes the simplest things make the biggest difference in your job. How many of you would like to use PowerShell more? Great.
This makes it really easy. Anything that you can do in a deck, you can instantly find out how could I do this next time in PowerShell. And it's simply a matter of using it.
Just look down towards the bottom and make that part of ADAC bigger. And you just have an automatically scrolling history. Everything you do in ADAC, boom. There's the PowerShell.
Because that's what it's actually doing. Whatever actions you perform in the GUI, it renders that in PowerShell and then runs it. So you know this is going to work. It's just a matter of taking the dynamic pieces of data and replacing it with variables. And voila, you've got your PowerShell script. Start automating stuff.
Same goes for Server Manager. So anything you do in Server Manager, it builds a PowerShell history for you. So it's not just AD. Start using PowerShell more.
OK, here's my last feature. And this is really awesome. This is the big one in 2016. And that is Temporary Group Membership. How many of you are using it?
We need to start using it, too. The idea is-- and even a little company like mine can use it, because when I've got a heavy-lifting problem, I hire another subject matter expert there to help us. And we have to remember to go disable their account.
If I'm just smart, I would put them into whatever groups they need as a temporary member. And if I forget to revoke their permissions, it just happens. And it's so easy to use the way it's been set up.
And don't get upset. I know you've had this feature in Active Role Server a long time. But this is one little thing they've added to Active Directory. And that is just this.
First of all, you've got to enable-- I love this command. Enable AD Optional Feature. But once you set that up, it flips some bit somewhere in Active Directory.
And now the same command that you might have been using for a long time-- Add AD Group Member-- so here, we're adding yes, that very cool character to the Domain Admins group. But we're adding this extra parameter.
And again, the name, to me, leaves a little something to be desired. Member Time to Live, time to-- TTL. Anyway, it's how long should Saul be a member of the Domain Admins group? 15 minutes.
And what am I doing there? I'm creating an AD object called a time span, which makes it very easy. You don't have to figure out how many milliseconds are in 15 minutes.
And does it work? Yeah, it absolutely works. Try it. Try it out at lunch. All you have to do is then, to see that it works, is say, well, show me who's a member of Domain Admins. And by the way, include that property, the member TTL.
And you'll see Saul's in there. He's in there. He's in there 15 minutes. Bing. He's gone.
It's very cool. And Windows does a little bit of extra work to clean that up from existing access tokens that are built throughout the network, too. So you don't have to go out there and force a log off.
So it's pretty cool stuff. And it's yet another thing that didn't get a lot of press. But it's easy to use. And I hope you do start using it.
Oh, yeah. This shows up in the audit log, because that was something somebody brought up is, well, how do you know when a user is only added for a temporary amount of time? And so we've got that right there in that little Expiration Time field. If you can't read it, that's what it says down there at the bottom.
But that's how you know, when you're looking at the audit log, if someone was only added for a temporary amount of time. And that's important because what is your control for detecting inappropriate AD group memberships? If it is scanning and doing periodic snapshot comparisons, this could actually fly underneath the radar.
So oftentimes, new security features can be a double-edged sword. So if you follow me, what I'm saying is a bad guy could say, you know what? I'm just going to add myself to the Domain Admins group with this back-door account to perform something and then immediately, or within a very short period of time, have myself removed.
And I won't even have to run the Remove AD Group Member, thus creating a little bit less noise, because AD will take care of that for me. So if you're not planning to use-- I guess the moral of the story is if you're not planning to use temporary group memberships, watch that field there in your audit locks.
So this, of course, could be useful for just-in-time administration, meaning that this person needs authority on this particular server or this particular part of AD for this ticket. And we want that window to be closed up automatically. We don't want to have to remember to do that.
Or it could be useful for longer-term projects. And of course, this has a very nice fit with best practice privileged account management too. Those are the features.
And here's the thing. I didn't talk about the cloud in this, even though we know that's the biggest thing there is going on. But here's the cool or interesting thing about Active Directory.
Active Directory hasn't moved to the cloud yet, has it? You might have-- and I'm sure you do have-- hybrid Active Directory environments. But you can't have Azure AD, at least right now, without Active Directory in an enterprise-size environment of any consequence.
So AD-- on-prem AD-- this is really the point I'm trying to express here. On-prem AD is still the center of everything, including what's going on in the cloud, including your security up in the cloud. Because if you have a hybrid AD environment, which way do things, for the most part, replicate?
Things begin with an on-prem AD account, with your on-prem AD group memberships. So if that's not done right, then it just flows up. The risk just flows up to every other reliant party, whether that's something in the cloud or some other reliant party application.
And here's the other interesting thing. If the security of your lowly Windows Server domain controllers is insufficient, then that compromises your cloud, too. So as we're focusing on addressing all the challenging issues of cloud security, don't forget about AD. It's still the foundation of everything. Thank you.
Thank you, Randy. It was great to hear you share some of those insights about securing Active Directory. I'm actually looking forward to changing some of my settings, Stephen, on your temporary group memberships.
You know, I was expecting that after that. So I appreciate that. Totally understand.
No, we really want tech to be an engaging and interactive experience with the experts. We're happy that Randy is going to be with us for the next couple of days. And he'll be presenting a session tomorrow on a hybrid AD track. So please join him.
Yeah, absolutely. Thank you guys so much. And, yeah, I think there's a break, and then we go to sessions. So thank you.