Making Zero Trust Real with Active Directory

This is Dan Conrad from One Identity, and today I'm going to talk to you about zero trust and how that applies to your lives today, in regards to Active Directory specifically. On the agenda, we're going to talk about some things relating to zero trust. So first off, I want to define a baseline and what zero trust is from its core, and then figure out how to apply that to Active Directory. I'm going to look at native Active Directory and figure out how that fits with a zero trust architecture. Does it fit? Is it a square peg in a round hole? And then I'm going to talk to you about how Active Directory can play in a ZTA world and see if it's even possible. Throughout this discussion, I'm going to talk to you about some environments and some examples and show you a few demonstrations. So I have to look back to the origin of the word zero trust. It's a marketing buzzword that sounds great, but if you go back, every vendor has their own definition of what zero trust should be. If we trace it back to as far as 2010, we see the Forrester researcher based on the realization that traditional security models operate on the outdated assumption that everything inside an organization's network should be trusted. So let's take a look at that phrase right there, the assumption that everything inside an organization's network should be trusted. You can think about that from a physical access perspective, whether you're talking about port security, the different layers of the OSI model. In regards to Active Directory, the concept of Active Directory being the single sign on solution that it is, lives on the assumption that everything joined to the directory has a trust relationship with that directory and therefore should be trusted. Microsoft's terminology when joining systems together, whether it's machines or networks, is called a trust relationship. So it sounds to me like the definition here of zero trust is the opposite of what Active Directory provides. So it's clearly defined as a concept. So zero trust is not something you can go down to your local security store, or wherever that would be, and go get you a bag of zero trust. It doesn't work that way. It's really just a concept, a lifestyle, a mentality, a way to think. There are definitions that I'm going to talk about in a few minutes from this, but in its clearest form, it's a concept, just like you would consider least privilege. In the past, we always looked at least privilege, but you couldn't necessarily say what exactly those least privileges were and what they exactly should be in every scenario. We're going to compare zero trust to least privilege, but this is a mentality way of thinking. Consider it the zero trust lifestyle. In reality, zero trust is not, not trusting at all. It's a different way to trust, a different way to establish trust, and a different way to consider that the systems and the applications and the networks are trusted so that when they talk to each other, they can do that in a very secure manner. And you can ensure that the right people get the right access to the right systems at the right time for the right reasons. And that does apply differently for systems, applications, and networks and many other things. You can think of it from a physical security layer as well. Just because somebody is allowed in your building, doesn't mean they're allowed in every room of your building all the time. So let's establish some terminology here, or some rules of the road. So the ZTA is defined by NIST, so we're going to use that term, zero trust architecture. So this is more of a goal for systems, applications, and networks. It's not like tomorrow you're going to turn on the ZTA functionality of all your networks, and it's just going to work that way. You have to have that as an end goal in place. If you're dealing with legacy systems that don't really confine to modern authentication or modern architecture, you may have to find ways to manipulate those or overlay into those so that they can fit the zero trust architecture, always with a goal to get to zero. So getting to the least trust possible so that the systems interact in a secure way. So new systems, retrofitting, they all operate differently. We've got to figure out how to make those work together. Let's talk about just-in-time access. Now this is one that One Identity relates to zero trust, and this is elevated privilege only when required. And you'll see how this fits into one of the NIST seven tenets of zero trust coming up. And then I like to take the term zero standing privilege and compare that to the least privilege model. If you look at the least privilege model in regards to Active Directory, managing the directory and the permissions within Active Directory, you always wanted to give people the exact permissions they needed to do just what they needed to do. If somebody only needed to reset passwords on users, then you would assign that permission just to reset passwords. A zero standing privilege would be the account that I'm using to do this has no privileges to do it until I need to do that. And then we compare that to persistent privilege versus just-in-time access. So persistent privilege relates directly to that least privilege model, but the permissions, or the privileges, are persistent. So you set them and forget them. Whereas, just-in-time access is the concept that I will be granted the permissions when I need them and then turn them back in, or they will not be granted when I don't need them. Think about getting into your building and getting physical access, where if somebody comes into your building, they may need access to the comm closet for a certain period of time. But they don't necessarily need access to that comm closet every day, all day, any time they want to get in. When I talk about zero trust, I'm specifically relating to the NIST SP 800-207. So zero trust, as I said before, was a marketing term that started around 2007. It turned into a marketing term. I can't say that it started out that way. But it started in 2010 and started moving into different vendors and defining it different ways. But then NIST decided to clearly define what zero trust architecture is. And in August 2020 they released a pamphlet. Feel free to go and look that up. If you're used to reading NIST documents, it's not a bad read or a very difficult read. It's much simpler and straight to the point than many of their other documents. Within this 800-207, there's a section called the seven tenets of zero trust. So it's great that it can take this entire document and boil it down into basically seven tenets so that you can use it in a very abridged form. You can get to the point. And then you can go off, and you don't have to read a lot of the sections that may not affect what you are actually working on. You'll see things like, look at number two, all communication is secured regardless of metro network location. So this is things like encryption on the wire. So when systems talk to each other, when an application talks to a database and things like that, this communication itself will actually be encrypted. Obviously, these are such diverse tenets of zero trust that not every system that claims to be zero trust enabled will address all seven of them. At One Identity we're dealing with these three specific seven tenets of zero trust, so the access to individual enterprise resources is granted on a perception basis, access to resources determined by dynamic policy, and then all resource authentication and authorization are dynamic and strictly enforced before access is allowed. We're going to take these three concepts and apply them specifically to Active Directory and how Active Directory is managed to make it more secure and make it fit into a zero trust architecture. Now we're all used to Active Directory administration. Actually those that are familiar with Active Directory, know how it's administered. Typically, from a top level you would delegate the right permissions at the OU level for the right people to do the right things. Hopefully you followed best practices in that space, and you're not delegating individual rights to people. You're doing it to group memberships, and things like that. But typical administration is done through Active Directory users and computers. We know that. When you apply least privilege to that model, it lets you do things that are very specific and unique. And you can get very granular, somewhat granular, in what you need to do. But you're still tied to the OU structure, and you're tied to that Active Directory security model. Within that, the person that you delegate permissions to has what we call persistent access. At the top tier, you end up with admins that have unlimited persistent access. So those are the accounts that can be very vulnerable to exploit in an Active Directory environment. When you're talking about an SSO solution, those are what the attackers are going after, any of these highly privileged accounts that are most likely to get them access to what they would need, whether that's to compromise the entire directory or search around for specific things like finance data or intellectual property. This is the old way of doing administration in Active Directory that's still very prominent today. When you wander around Active Directory and do what it is you do as an administrator, this is going to generate an NTLM hash. And this is one of the vulnerabilities of the SSO solution I'd like to address. So as an admin, say a top tier admin, domain admin, enterprise admin, even a schema admin, does things in Active Directory, and they go from system to system, they log on interactively many times. When you log on interactively to a server or workstation in the environment, whether you're a privileged credential or just a basic user credential, you leave an NTLM hash, or it generates an NTLM hash, on that system, and it's stored in memory. That gives you access to things and signs you on and authenticates you in the old way so that you can have ease of use across the entire directory structure. This is a little bit of a problem. So in privileged environments around Active Directory when we bring those hashes in, this is what the attacker goes after. I've had many customers ask me, how long would it take you to compromise a 16 character password with many different character requirements? Well it doesn't really matter anymore, because nobody really goes after passwords. You could take a hash and convert it into a password, but I don't need to do that. I will just use the hash. If I have the hash, why would I go back and look for the password? If I really wanted to, I could actually change the password on the account and use the account without ever knowing the previous password. So what we want to do in a zero trust environment when we're talking about Active Directory is a different way of thinking about administration. From the way administrators operate on a daily basis when they're touching objects and attributes in Active Directory to the way that they will log on interactively and the way they'll use credentials. If you take this from a delegation perspective and you've got a low level admin, what you want to do is you want to detach from those built-in Active Directory native permissions. So we do that with a tool called Active Roles. I'm going to talk about that in a few minutes. And Active Roles will give you access to the directory and just the pieces you need, regardless of the OU structure of the permissions model in native Active Directory, allowing you to remove the native permissions so that those individual accounts can't get exploited. But when you talk about elevated permissions on things like domain admin accounts or accounts that have rampant permissions across the entire directory that are really going to need to be there no matter what, there's a way to control these that the SSO functionality of these privileged accounts can't get exploited. And the way we do that is we take your admin and we vault those credentials. So if I'm an admin, hopefully my D Conrad account doesn't have unlimited domain admin permissions across the directory, but I use a separate account when I'm doing administration. So maybe I have a D Conrad ADM account or a Dan ADM account. In this case, I would take that ADM account, and I will vault it so that when I'm not using it, no person will know the password for that account or be able to authenticate to that. When I need it, I simply connect to the vault and check it out. When I check it out, I'm able to use it any way I did before, whether it's through sessions or I need to enter a credential to do something. Then I can run across the network, do whatever I need to do in an audited fashion so that my credentials are known that I have them checked out. When I'm done with it, I simply check them back in. Then the vault solution will reach out and touch anywhere that I use those credentials, specifically in Active Directory, and change the password. When I change the password in Active Directory-- you can see the hash down at the bottom-- the hash is nullified. The hash will still be there. The hash will still be resonant in memory on any system that I've logged in without rebooting, but it won't be valid anymore. So I can't authenticate against it. Additionally, the password vaulting solution, in this case known as Safeguard, will change the password but also disable the account. So not only is the password no good, but its credentials-- you can't authenticate against a disabled account. In addition to that, we're going to take a few extra steps, and I'll talk about those in just a second. So this is what it would look like. So if you're a Windows admin, a UNIX admin, even any other admin, what you're going to need to do is vault those credentials. So obviously the vulnerabilities in a UNIX environment are much different than they are in an Active Directory environment, but they have a strong need to be vaulted and managed so that no person has unlimited credentials or unlimited access to something. So within the tool called Active Roles, we have the ability to detach those permissions. But then within Safeguard, we have the ability to vault credentials. When those two work together, we get something known as just-in-time provisioning. Just-in-time provisioning will ensure that the credential that I'm using will be in the right group when I need to use it and remove from the group when I'm no longer using it, further breaking that kill chain. So this is what Active Role is. So Active Roles itself allows you to remove the persistent native access. It allows you to pull the native permissions out of Active Directory so that they don't necessarily need to be attackable within Active Directory. So when the permissions exist in AD, they're vulnerable. When we remove them from Active Directory, that doesn't matter anymore. But then it gives me dynamic control of the access. So that can be based on your current Active Directory group membership, time of day, really a lot of things that go along with it, and we can tie that back to native groups. It gives me the ability to build these native groups very dynamically and to change them on the fly as they need to be changed. And then Active Roles itself works with my Safeguard solution for what we call just-in-time provisioning. You'll see it here referenced as JIT. And this addresses the item number 4 that I had in one of the seven tenets of zero trust, so access to resources determined by dynamic policy. Active Roles is a tool that lets you build and use that dynamic policy, whether that applies to direct access to Active Directory or dynamic creation of groups. The other solution that I'm using here is called Safeguard. Safeguard has two sides to this, the main one I'm using is called Safeguard for Privileged Passwords. So this is the solution that is my vault, my credential vault. So it is the person that sits behind the scenes and knows what all the passwords are and takes care of changing them for me. It's also going to disable the accounts when they're not in use. So that kill chain is broken and the account can't be authenticated against. It ensures that no person has a credential. So I don't have to worry about going to a security person and have them pull it off some spreadsheet that they have. And it itself works with the Active Roles just-in-time service. So that just-in-time, again, is the piece that's going to watch for an account being checked out of Safeguard and then make sure it goes into the correct groups so that I can use it when I need to. But it's also going to reverse that process. So when I'm done using it, it's going to disable the account and remove the group membership and change the password. So the hashes are no good, the account can't be authenticated against, and it's not a member of any privileged groups anyway. If you take that a little bit further, you bring in Safeguard for Privileged Sessions. This is a solution that gives you something called Gateway authentication access control. The Safeguard for Privileged Sessions is a protocol proxy for our session protocols, things like the 3389 ports, your Microsoft terminal services, and your SSH ports, and really anything else that uses a session management, things like SQL Management Studio. When we proxy those sessions, that gives us a lot of capabilities, things like command limitation so that you can control what commands that people can and can't run. And this can all be based on Active Directory or group membership or roles within other systems. And then it gives us a great, very dynamic, access control on a per session basis. So every literal session within those tools gives you complete control over what can happen within that session and who can access it. So we see this applies to two of the items I have from the NIST seven tenets of zero trust, where all resource authentication and authorization are dynamic and strictly enforced, and it's on a per session basis. So let's take a quick look at what Active Roles and Safeguard do. So Active Roles and Safeguard for zero trust. This is a diagram of the just-in-time provisioning. So you'll see on the left, you've got your Windows admins. In this case, I've referenced UNIX admins because UNIX admins in my environment-- the UNIX environments are joined to Active Directory, and I dictate who can authenticate on those UNIX platforms directly based on Active Directory group membership. So in my environment, you need to be in a group called UNIX admins to SSH onto a UNIX platform. My UNIX environment, I don't allow people to check out passwords. I just allow them to check out sessions. So in this case, if I'm a Windows admin and maybe I need to deploy an agent to a domain control or something that requires a domain admin level credential, I'll simply connect to Safeguard itself. And then when I check that credential out of Safeguard, Safeguard is going to tell Active Roles the group that it needs to go in and Active Roles is going to do that for me. When I'm done with it, three things are going to happen. The accounts are going to become disabled, the password is going to be changed, and the group membership is going to be stripped back to zero so that these accounts aren't vulnerable. Let me show you how that looks in my lab. So here's my lab. As you can see, I've got Active Directory, and I've got my Safeguard interface. Let me just open up Active Directory Users and Computers for a moment to show you the old way of doing business. So minimize here. So this is Active Directory Users and Computers. I'm logged on as an account, D Conrad. I don't have any permissions in native Active Directory. I can see things, but I can't really do anything with them. So if I wanted to do something to an account here, I really don't have permissions to do that. So I want to disable the account. I really can't. What I need to use is Active Roles. So I can go into Active Roles and I can manipulate Active Directory just like I need to fit any environment that I need. So if I go into my test OU or something, if I want to go into my users OU, and I can disable accounts or do whatever I need to do because Active Roles is proxying this for me and dynamically evaluating my permissions for me. The way I manage my privileges, so if I need to be a domain admin in my environment, I have a pool of accounts that I can use. So I've got a temp domain admin account right here. And I call it temp, because it's not always a domain admin account. You can see by the big red X that it's disabled, but then it's not a member of any groups other than a default domain users group. So if I wanted to use that account or if I need a domain admin credential for something, I can simply come in to Safeguard, and I can check it out. It's a member of my domain. So I select the domain, and then I go through and select the account. So this is the account right here. And then here I can fire off a workflow approval. So if we needed to go to a security department for approval or something like that, you can do that. In this case, I have this set up for automatic approval, so I can just go get this at my leisure. And you'll say pending account restored. Now it says the accounts available. So if I come back over into Active Directory and look at it, you can see the red X is gone, so the account is now enabled. So now I can authenticate. But it's also a member of the domain admins group. Well it's actually nested in the domain admins group via another group. I don't allow users to be assigned directly to the domain admins group, but it goes into this nested group right here. So I can go use this credential any way I would need to. So like I said before, if you needed to do something like deploy a agent to a domain controller, you can go see that password right here and go use it, just like you would anything else. Then at the end of the day when you're done using it, you simply check it back in and it reverses the process. So now should be stripping the group membership back out. So now the account is as useless as it was when it started. So we're comparing a couple of things here. First off, Active Roles has removed the native permissions, or allowed me to remove native permissions in Active Directory, so that now Active Roles is talking to the directory on behalf of me. So with that, I'm able to do anything I need to do in Active Directory. And you can still delegate permissions the same way you did before, just you have to have permissions to do that. Again, delegating permissions is a permission that's assignable within Active Roles. It's very granular. Additionally, it's auditing in the background, so everything that happens by Active Roles, it's auditing its own actions. So you can go look at a record of that. In Safeguard, whenever I'm checking out privilege credentials, I know who had a credential when they had it. When I'm done using it, I can check it back in, and I can track those actions as well. So that the accounts that-- the initial statement this everything is trusted and everything is persistent, that doesn't have to be so when you bring in Safeguard and Active Roles and have them work together. In this case, they're working specifically to do very specific things. I can take that to the next level, and I can take it off to a session management perspective. So for instance, maybe I needed to log on to a specific server in my environment to do something with a session. I can do the same thing through Safeguard. In this case, I'll log on to my domain controller using a domain admin credential. And I'll take the same account I had before, which was temp domain admin one, and we can see here that it's back to its normal state with no group membership. So to be able to log on to a domain controller, I need to be in the domain admins group. So I'm simply going to request that. And then I'm going to submit the request. This goes off for workflow approval and comes back. Now the account's going to be enabled, and I can go use it. So we'll take a look at it again. So now I can see it's in the right group. Now instead of being able to retrieve the password, I've simply got a button right here that'll launch a session onto that domain controller for me. At this point, me as a person, I have no idea what the password is and don't need to know what it is, because it's going to log me directly onto that domain controller. And in this case, I'll be able to do whatever it is I need to do as that domain admin. And we can see we've got Server Manager here. And we'll just launch a command prompt. And do a quick who am I, So we can see that I'm SGTempDomAdmin1. So I can log back off, and my session is still available if I needed to use it again, still in the same group. But now when I'm done with it, I simply check it back in and the process is reverted. So at that point, you think about the zero trust model. No person knew the password in any one time. The account itself wasn't trusted until it actually got the right group membership and it was enabled. So the zero trust model fits very appropriately when Active Directory is manipulated appropriately. So I've been doing this for the domain admin groups and obviously those very specific groups that come canned in Active Directory. But this can be done for anything that requires or relies on Active Directory group membership for assignment of privileged roles or specialized roles. So if I needed an application or an account to mess with a specific application, go make changes to it, I need to authenticate against Active Directory, and you want to vault that account, you can do that as well. I've done that right here. So I created SG special security app admin one. You can do the same thing with that. The way I'm doing this is I'm using groups that I saw right over here, and I'm dynamically manipulating these groups. So I can use it for things like these type applications or even UNIX administration. Now UNIX Administration doesn't directly relate to zero trust for Active Directory, but in this case it does, because my UNIX machines are joined to Active Directory. So anything that relies on Active Directory group membership or privilege elevation can be managed through the just-in-time provisioning features of Safeguard and Active Roles from One Identity. And the other important piece to consider here is that the user I'm acting as here, the Daniel Conrad account, or D Conrad in my environment, has no native permissions in Active Directory. He's simply been granted rights to check things out and do things a certain way. My permissions in Active Directory are specifically limited to this OU, actually this OU, so I can't create users. I can't create computer objects. Honestly, I can only create users in this OU. I can't do anything else. And then I can manage the users in that OU. I'm not allowed to create groups. I'm not allowed to create computer objects, printers, contacts, anything outside of that OU or anywhere. So even though I have the illusion of full control of the users, I'm not allowed to do things beyond that. And everything that I do in the tool is completely audited. So when you look at the trust of native Active Directory, there's really nothing there tied directly to my account. It simply runs through Active Roles, and it's very dynamic. And it controls it based on whatever policies that I have in place. When I have those policies in place, everything is going to be audited, and everything is going to be controlled in a very orderly fashion. Keeping my-- not only very secure but very organized. Keeps my directory very organized for me. Let's jump back over to the slides for a minute. So we just talked to you about the just-in-time provisioning and Active Roles in Safeguard for zero trust. Let's take a look at the rest of the One Identity portfolio in regards to zero trust. A lot of it ties back to some of the same concepts. So whether we're dialing that into Active Directory specifically or we're taking those permissions across the board and invoking things like SSH key management and session management, we're wanting to withdraw the trusted agents from the users themselves. So a person knowing passwords, or a person having secrets, or a person having SSH keys to have unlimited access is something we want to get away from. We had to very much wrap controls around that. Just from a permissions perspective, it's a good thing to do, but also from an auditing perspective. We can do that across the Active Directory environment in regards to your vault, but we can also take that outside of your Active Directory environment into things like Azure and into things like UNIX and Linux and AIX any of those operating systems, even down to network devices. So that no people need to have passwords in their head, and those passwords can be cycled every time they're used. So that the people being trusted aren't going to be a problem in your environment, and it doesn't expose that vulnerability. So thanks for listening to the zero trust presentation, specifically around zero trust for Active Directory. One Identity addresses zero trust if you can see our weblink right here on the URL on the screen. So take a look at that. There's some great information there. And we even bring in some other solutions, like Change Auditor for Active Directory and how that can help you in a zero trust environment by not only auditing but locking things down, great ways to do different things, and how to get things to interact with different solutions in Active Directory. I've been your presenter, Dan Conrad. Feel free to reach out to me on LinkedIn, be glad to hear from you. Thanks for your time.