Join Mike Danseglio for an in-depth discussion in this video Overview and configuration, part of Windows Server 2012 Active Directory: File System and Storage.
- We've always had the ability, since NT was round, to take a file, set NTF permissions on that file, and prevent people from being able to access that file that shouldn't access it. Or give them a level access that maybe only read. One of the problems that we've always had with just that permission level was if anyone is a member of an administrators group on a computer, they've always had the ability to take ownership of a file, of a folder, and then give themselves permission to access that file or folder.
This has always been a dream of a hacker. Because they know that one of the shortcomings of NTFS is the ability of an administrator to take that ownership and then give themselves permissions. So if I had this administrators group, and I've got little Johnny over here, and Johnny's a member of the administrators group, and John's user account gets compromised and someone gets that user ID and password. And let's say they're a hacker. Or they're someone that wants to do damage.
Or they're just someone that wants to be as they call a "casual hacker", they just want to go out and they want to see what's in the folder. So they log on as John onto this machine or they access this machine as John. And they go to access this file, and they get access denied because of the NTFS permission. One of the things that has always been available to administrators in NT with the new technology file system is the ability to take ownership. John takes ownership of that file because he's an administrator on that machine. Once he takes ownership of that file, he now has the ability to set permissions on that file.
He could wipe out all the permissions that are there, or he could simply give himself permissions to access the file. He now goes and accesses the file, he views what he wants, then he has the ability to take himself back out of the access control list. So it was like he was never there. Now if we're not doing auditing, we never know that John even accessed that file or that folder. In most cases, auditing's not going to be turned on unless it's on very very sensitive corporate documents. So John just got away with changing a permissions on a file, added himself to the permissions, and then going and viewing the file.
That's an issue we've always had. That's because if we look at the file architecture of a standard file on a machine, we have a header, data, and a trailer section. Not concerned about the trailer section. But in the header section we have attributes, It's a hidden attribute, the read attribute, the archive attribute. But this also where NTFS permissions reside.
And if you're a member of the local administrators group, you always have the ability to read the header. Even though you may not have permissions to access the data, you always have permissions to read the header. And because you have permissions to read the header, you also have the ability to modify that header. So with the encrypting file system, or EFS for short, what this allows us to do is to encrypt this document or this file so that only the people who have been authorized to decrypt the file will be able to open the file and read it.
This will not prevent anyone that's a member of the administrators group from taking ownership of the file, changing permissions, and then adding themselves to it. 100% transparent to the end users. Once they've checked the box to make a file encrypted, they open it and close the file just like thye've always done in the past. So if I come in here and what happens is when a user goes to encrypt the file, we're going to use this feature called the Public Key Infrastructure, or PKI for short. And it's going to utilize what's referred to as a public key and a private key pair.
So to date myself a little bit, when I was a kid, I remember going down to the Ben Franklin nickel and dime store with Mama and Papa, and you'd go down there and they had these hearts you could buy. And supposedly no two hearts were the same, they were a little bitty locket, so I could buy the heart, and I'd go give it to my sweetheart, or my love of my life, at five years old we always had those loves of our lives, and we had the two sides to the heart. Supposedly no two sides ever, ever were matched.
So that if I gave this half of the heart locket to that love of my life, this would be my half of the heart, and no one could ever ever ever steal the heart away because they were the only pairs. Later did I find out when I was a little older that they were all die cut and they were all the same. So my heart kind of got broken. But EFS insures that these two pairs will always be unique. No one else in the environment will ever get these pairs. If I'm in a work group environment, this is created the first time a user encrypts a file. If I'm in a domain environment, they're going to be maintained and managed by active directory.
That allows me to have the same key pair as the user no matter what machine I log on to or I may go access. So let's call this our public key, and we'll call this our private key. Our private key will be put into our user's profile. So that when I go to access a resource, I'll be able to retrieve from my, basically my certificate store, my profile, my private key. My public key gets placed onto the front of the file, which was referred as a DDF.
It'll be the public key of my private/public key pair. It's my certificate. Now using my private and public key pair, we're going to create a symmetric key that actually will encrypt this data. So it's a symmetric key that actually encrypts it. We use our public and private key to encrypt the data. So now what happens is, any time I go to access this file, the local security authority subsystem says let me see your key.
There is my key. I gain access to the file. Piece of cake. What if we have good old Adam, the hacker, good old Adam the want-to-be hacker, good old Adam the casual hacker, has his public and private key pair. Adam's public key is not going to be involved in this demonstration, but here's Adam's private key. So what happens is, Adam goes to open my file.
The local security authority subsystem says let me see your private key. Adam presents his private key. It's close, but it doesn't match up. Even though Adam may have the NTFS permission of full control, because his private key didn't match up with my public key, he'll be given access denied. That insures that only the people who have been given the key pair can open the file.
Well, now we have a small problem. Our key is stored in our actual profile. So if our profile becomes corrupted, we lose our public key, or sorry, our private key. This is where it's nice if I'm in an active directory environemnt, my key can be regenerated or reestablished to me, or redistributed to me through active directory. I can also be using a corporate certificate authority in the environment to publish my keys.
If I'm in a work group environment, now we've got a problem. If I'm in a work group environment, the only key that was there was issued to me through the local security authority subsystem when I created my first encrypted file. So now what happens is, if my profile gets corrupted, I cannot decrypt any file that I've encrypted in the past. So Microsoft kind of built in a "oops" or an "uh-oh" situation for us, so if something like that were to happen. On the front of this file, there's going to be an additional header here called the DRF.
The DRF stands for Data Recovery Field. DDF was Data Decryption Field. And what the Data Recovery Field is going to do for me, is this is going to be the public key of a person called the Designated Recovery Agent, or the DRA for short. What the Designated Recovery Agent is is a person in the environment, who by default is the first administrator account and the first domain, or the first administrator account in each domain by default is a Designated Recovery Agent.
What the Designed Recovery Agent can do, is by default can decrypt any file in the organization that has been encrypted since they became a Designated Recovery Agent. One of the things that we can do as an administrator, or as OU Admin for instance, we can designate a different recovery agent inside of our department, so it's not the actual enterprise or the first administrator account in the domain. So that is how we encrypt. So how do we actually do this? If I bring up my Windows 8 computer, and I'm currently logged on as Rick T.
Let me get all my keys here out of the way. We don't need those anymore. Those are fancy keys, aren't they? So I come onto my Windows 8 computer here. I'm currently logged in as Rick. And if I want to come in, I want to encrypt the file, I'll bring up my Windows Explorer.
And I'm just going to create a folder on here that's already created called Data. I already have a file on here. I want to encrypt this file. So if I right click on the file, or secondary click, come down to Properties, come out to Advanced. This is where I can encrypt the file. Now, one thing I want to point out here really really quick is file encryption and data compression or file compression is mutually exclusive one the other. I cannot encrypt and compress the same file.
I can encrypt the folder and then compress the file in the folder, or vice versa. I can compress the folder and encrypt an individual file because the file will become just the opposite of whatever the other one is. So I hit Ok. I didn't get asked do I want to encrypt the file in the folder. If I hit OK, the folder itself is not really encrypted. What happens is, is the folder will get a bit set on it that says any new file placed in this folder will be automatically encrypted.
And notice that the folder turned green, and so did my file. So if I secondary click here as Rick, and I create another file, the file is open. If I secondary click on here and I go out to Properties and I do an Advanced, and I do a Details, it'll show me who my Designated Recovery Agent is. And my current Designated Recovery Agent is the first administrator account on the domain.
So encrypting a file is 100% transparent to the user. Other than the fact that it looks green to them, if they double click on the file, it opens, they close the file, it closes. The actual encryption process occurs 100% behind the scenes for the user. So if I log off as Rick, I'm going to do a switch user to the administrator account, and also if I log in as the administrator account I come in that same directory structure.
Because I am the administrator, I can oops... I'll have to import my key. That's the reason why. But normally I would be able to open that file as the Designated Recovery Agent. If I secondary click on here and I do a new file, notice the file is automatically encrypted. Because the fact the folder has been totally encrypted. By default, I'm the only person who can encrypt and decrypt that file. The person who encrypted and decrypt is the file. The person who encrytped it, and the Designated Recovery Agent, by default are the only two people who can decrypt the file.
Well what if I have a file server? And up on this file server, we have sensitive data, but more than one person needs to access it. In Windows XP and Windows Server 2003, Microsoft gave us a new capability in EFS. The ability to add what's called an authorized user. So what I an do here is, as long as that person has encrypted a file on this machine, they are on this machine's registry. So if I come into this file that the administrator encrypted, I come to Advanced, I come to Details.
Notice up here so two can currently access this file. If I click Add, there's the Rick key. I can Ok. I am now just added Rick T as an authorized user for this file. So now whatever permissions Rick T has on this file, that's what Rick T can do on the file. This right now, I'm doing everything locally. I'm not going through a Network Share. There is a gotcha through a Network Share. in Windows 2008, Microsoft implemented a new feature on a Network Share.
If I bring back up my server, and I'm going to bring up Acrive Director Users and Computers. If I have a server that's got a Network Share on it. By default, we do not allow encryption on that machine. And that's not through turning off EFS, that's through this check box that's in the properties of the machine, under Delegation. By default, a machine is not trusted for delegation which means as long as this box is checked, there's no EFS capabilities.
Except for local. I can log onto that machine locally, and I can encrypt files. But I cannot encrypt files over the network. So if I want to encrypt files over the network, my minimum choice is trust this computer for delegation to any service. This will allow us then to be able to encrypt a file or folder on this machine over the wire. This is where it shows up for... in Active Directory Users and Computers.
And in the Active Directory Administrative Center. If I just double click on computer account and i scroll down, you get Delegation again. Trust this computer for delegation for any service This will allow us then to encrypt files on that machine remotely. Until those boxes are checked, or those radio buttons are selected, we're not going to be able to encrypt files on those machines remotely. By default we cannot encrypt a file on a machine remotely.
So we've looked at in this session we've looked at what EFS is and why we have it, and to kind of defeat the, for lack of other words, the back door to get into an NTFS file. We looked at how to encrypt a file, for an individual user. We looked at how to determine who the Designated Recovery Agent was, and then finally we looked at how to add an authorized user into the environment. And while we were at it, we showed you how to delegate a machine for trusted, or delegate the trust, so we can encrypt the files over the wire.