Security is probably one of the things I see companies spend the most time and effort on. Excepting, of course, for those companies who just don’t care (and yes, they’re out there), or who can’t spare the time that security requires. Why do Microsoft’s products have such complicated security? How does it work, and how can we leverage that architecture to make it better, more automated, and easier to control? I’ll focus on the file system for this article, but the same substantial truths apply to Active Directory, Exchange, services, SQL Server, the registry, SharePoint, and much more.
ACLs, DACLs, SACLs, ACEs, and SPs.
Most Microsoft products follow a similar security metaphor, although they may use different names for the elements involved. Let’s start with the file system, which uses an architecture shared by the registry, Active Directory, and several other Windows elements. Although SQL Server and other products use similar concepts, they implement them in very different ways, and I won’t be focusing on them in this article.
Consider the securable, which is simply some resource to which security will be applied: A file, folder, OU, user, registry key, or whatever. Each securable has two Access Control Lists (ACLs): A Discretionary Access Control List (DACL) and a System Access Control List (SACL). The DACL is used to control access to the securable, and the SACL is used to determine how access attempts will be audited. Both of these are capable of being entirely blank, and inheriting their settings from their parent container. Both types of ACL can also have additional entries, above and beyond what they inherit from their parents, or they can rely entirely on their own entries and not inherit from their parent at all. An ACL entry is called an ACE, or Access Control Entry. An ACE consists of three things:
A Security Principal, or SP. This is expressed as a Universally Unique Identifier, or UUID, and may represent either a user or a group. This is one of the things that actually makes security complicated for us humans: Because a UUID is stored, extra work is required to look it up and translate it into a user or group name that we can make sense of.
An Access Mask, which defines a set of permissions, such as Read, Write, and so forth. The exact permissions available will depend on what you’re securing. Files, for example, will obviously have different available permissions than, say, Users.
A Type, which will either be Grant or Deny. This indicates how the Access Mask is applied. If the Access mask is for Read and Write, and the Type is Deny, then the SP has been denied Read and Write permission on the securable. For SACLs, the Type is usually Success or Fail, indicating what actions will be audited. So, if the Mask is Read and the Type is Fail, then failed read attempts will be audited.
The order of ACEs, as they appear on the ACL, is important. The system reads these from the first ACE to the last. The user’s effective permission set is a combination of whatever permissions are applied through the ACEs. If one ACE grants the user Read, and another (perhaps a group membership) grants the user Write, then the user’s effective permission is Read and Write. A Deny permission applied anywhere in the process is final: That permission cannot be re-granted by a later Allow on the DACL.
When a user attempts to access a file, Windows’ Kerberos protocol builds a ticket, which is transferred to the user and can only be read by the server that contains the file. The user presents the ticket to the server in order to gain access. The ticket lists the UUID (which, by the way, we tend to call a Security Identifier, or SID) of the user, and of every group the user belongs to. The server compares that list to the DACL and SACL on the file to determine what permissions and auditing behavior will be applied to the user’s access attempt.
From a security management perspective, this architecture is difficult to manage because it’s so distributed. Each securable knows who it will allow and deny, and who will be audited and who won’t. There’s absolutely no central control, no central repository, and no central logging. It’s impossible to quickly determine what securables a particular user has access to, because you’d have to scan through every single securable to determine that. It’s even difficult to determine who will have access to a given securable, because you have to expand all the group memberships, which can be complicated - especially in multi-domain environments with complex trust arrangements.
Another problem is that the ACLs only reflect the current state of security. There’s no version-control, so it’s impossible to tell what access someone may have had in the past. That’s a deal-breaker for most auditors, who not only want to see the current security configuration, but also want to verify that it hasn’t changed in the past.
Microsoft is well aware of the complexity of the current security architecture, and is hoping to change it, probably toward something called claims-based authentication, which is simpler and can be centrally managed. We’re already seeing some minor inroads toward that end in specific Microsoft products, but not yet in the base OS or in Active Directory. Integrating a brand-new security architecture into the OS is incredibly complicated and risky (I’m sure you remember what a hurdle Active Directory initially presented!). Until that happens, we’re stuck with a complex, hard-to-manage and hard-to-maintain security system. So what’s the answer?
A Best Practices Shopping List
Let’s be clear on something: You’re not going to achieve markedly better security management on your own, using only native tools. Even if you’re an expert scripter, you’re dealing with a fundamentally complex and highly-distributed architecture that was designed in the late 1980s, and was never envisioned as supporting the massive, distributed environments that we enjoy today. You’re going to need help. The trick, I believe, is in figuring out exactly what practices you should be following, and what capabilities you need to add to your environment. If you can build some of these on your own - fantastic. My experience, however, is that professionally-built tools (whether free or commercial) offer a bigger bang for the investment. Let’s look at some of what you’ll need.
Centralized permissions storage. First and foremost, you need to get all of your permissions into one place. Now, there’s currently no way to make those the active permissions, meaning you can’t bring everything into one place and have all your file servers look at that place for permissions. Today, the best you can do is to copy all of your permissions into a single database. This often involves installing an agent of some kind on every server, although agent-less solutions are also out there. I find that locally-installed agents can be more accurate, because they’re able to “shim” the operating system APIs so that they receive immediate notification of permissions changes, and can immediately copy that information to the central database. Such databases can also store historical permissions, in addition to the currently-active ones. Let me be clear that getting all of the permissions into a central database is the lynchpin for everything that follows. You can’t achieve any of what I’m going to propose unless you have this in place.
Centralized auditing log. This is actually easier to achieve in newer versions of Windows Server, which support event forwarding, since that feature lets you get all of your audit events into a single log. Don’t underestimate the overhead that can create, especially in a busy, heavily-audited environment. In some cases, third-party auditing tools can provide the same feature with less overhead - even if it’s a simple utility that forwards Windows Security log entries to a syslog server. Some solutions can bypass the native event logs entirely, and instead capture information using a locally-installed agent that taps into Windows’ own APIs.
Reporting. With all of your permissions in a single database, reporting becomes a million times easier. Now, you can easily find out who has access to what. A permissions database will often synchronize things like group membership from Active Directory, so that it can accurately report on permissions granted through nested group membership, cross-domain membership, and so forth.
Enforcement. With permissions in a central place, you open up an interesting possibility: Use the central database to define permissions. Rather than syncing permissions from the securables to the database, you go the other way, pushing the database-defined permissions out to the securables (often through a locally-installed agent of some kind). In some cases, a local agent might re-download the permissions from the database anytime a local permissions change occurs, ensuring that the database is not only accurate, but that it is authoritative. You’ll also see this feature referred to as auto-remediation or something similar.
Workflow. With permissions in a single place, and especially if you’re using them as an authoritative permissions source, you can finally implement and enforce change management practices for permissions. Changes can be reviewed, approved, and annotated in the central database, and once approved can be deployed to the securables - or even scheduled for deployment. That also implies a change log of permissions changes, and potentially even the ability to rollback unwanted changes, or changes that caused a problem.
Assuming the solution that provides these capabilities knows how to talk to various products, you could easily centralize those products’ security into a single place. Imagine controlling AD, file, Exchange, SharePoint, and SQL Server permissions from a single console! You can more easily meet any management, security, or auditing requirement across multiple platforms that way. Such a solution could, if it offered the appropriate automation interfaces (I’m hoping for PowerShell cmdlets, myself), even become part of an automated provisioning system, pushing the correct permissions for new users as soon as the user was created, moved within the company, or left the company.
These five practices I’ve outlined are the ones that any company - small, medium, or large - can benefit from. True, the need might be more pressing in a bigger company with more permissions activity, but even smaller companies can benefit tremendously from the easier permissions management. For example, imagine taking IT completely out of the loop on permissions changes: A business manager could decide who was allowed to have what permissions to resources under his or her control, and could make that change using a simple tool or even Web-based interface. There would be no more need for IT to keep track of who was allowed to have what, or for IT to play middleman in mediating permissions requests from users.