To put some sort of context around this month’s blog article on non centralized security or how to get to centralized security. I want to start with just briefly talking about Windows Security. Now, as you can see here, I am logged on to this computer. A little Ctrl-Alt-Delete and I get the standard screen. I am clearly logged on as someone. I change my password and everything else. Having logged on like that Windows has created for me a security token that represents my user account. It contains the Globally Unique Identifiers (GUI); they are called security identifiers when they are used for security. That token contains all of the SIDs, both from my user account and every group account I belong to. So, my User account and all my groups. Any time I go to contact a server to get a file for instance, that server has to determine if I am allowed to have access to that file. Jump in here and look at any random folder like Windows. Take a look at the Properties. On the Security tab you’ll see the Users and Groups that have access to this.
Generally what these access control lists (ACL) contain is a bunch of SID’s or Security Identifiers. We as humans have no use for that information. So when this dialog is built it actually goes to the security authority and gets the name that is associated with each one. In the case of local accounts, that happens pretty quickly. But when you have been looking at one of these in Windows and you see a really large one. I’m sure you have seen the question mark over here, or maybe you have even seen a SID listed here instead of the name. While the dialog box goes out to a Domain Controller or Global Catalog Server and translates those SIDs into the names you see here.
So this is what an Access Control List consists of, a list of SIDs that have permissions and what permissions they have. So, I can click on Administrator and I can see that there are no explicit conditions except for these special ones applied. If I wanted to Edit this or get at something else then I would be able to get in and change those things. Each Access Control List consists of Security Principals that is Groups and Users. Each one of those acts as Access Control Entries or ACEs. Also has a grant or deny along with one or more permissions like grant read or grant write, so forth.
The actual permissions, the authorizations that allow you to access a file is stored with the file or folder, or its parent. The point being that it is stored on a file server. Same thing in Exchange or SharePoint, all the permissions are stored at the point where they are being used. Even though those permissions might be applied to one or more principals drawn from Active Directory. That’s what all of these Users and Groups are.
So when I talk about the need for centralized security, I’m not talking about centralized authentication. Authentication being the process of proving that you are in fact Administrator, or you are in fact Don Jones, or Guest, or any of these other security Principals. We do have centralized authentication through Active Directory. What we don’t have is centralized authorization. In other word it is very easy for me to go to a particular log and see when Don Jones has logged into the system. It is very difficult to access what files that person is trying to access or what files they even have permission to access, simply because all of that information is stored in so many separate places. I essentially have to inventory every single possible resource to see who has permissions on all of them. That makes doing any kind of security auditing or reporting extremely difficult.
For example, it would be easy enough for me to go into Server Manager here, on the file server. I can go into Diagnostics/ Event Viewer/Security log. This log will show me all of the security information that I could possibly want to look at, but it’s just for this server. If I wanted file access on another server, I would have to go that server. Even if on the single server, if I wanted to see everything that you had permission to. I would have to walk through a lot of dialog boxes. There are some command line ways to help that out.
For example, here in Windows PowerShell there is a Get-Acl cmdlet. If we give it a path, it will give us the entire access control list for that path. If I say Get-Acl C:\ you can see that these are the permissions that have been assigned to that. If I look at C:\Windows I can see which permissions have been assigned to that one as well. A majority of the permissions on a file server start at that top root directory and inherit downward unless you change it. You’ll notice there is not a bunch of recurs here. Pipe it to this cmdlet and then see what kind of permissions come up. It would take a long time to watch that run through.
In fact, let’s take a look at a do-it-yourself tool for reporting on all the permissions of all the resources on this server. I’ll start with dir-recurse, of course you could start in a different folder, but we’ll start at the top level. I’ll pipe those path to get ACL, and here we go. This is definitely going to take awhile. I could pump this out to a CSV file or perhaps an XML file. Ultimately searching through here is going to be awfully time consuming, largely due to these extremely distributed nature of these permissions. Not only are we talking about permissions being distributed across many different servers, but even within a server the permissions are individually distributed down to the individual resource. There is no centralization for the authorization process, and that what makes managing and auditing and enforcing the right permissions for the right people on the right resources so difficult. That’s the topic of this month’s blog article.