Yuma 4×4

Media and Communications

Protecting Your AD with Randy Franklin Smith

Protecting Your AD with Randy Franklin Smith

[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. [LAUGHTER] 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. [APPLAUSE] 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. Thank you. [MUSIC PLAYING]

Leave comment

Your email address will not be published. Required fields are marked with *.