Security Principals, ACE, ACLs, DACLs, and SACLs

As a follow up to an earlier post I made on Advanced NTFS Permissions I thought I’d post some notes I made recently on Security Principals, ACE, ACLs, DACLs, and SACLs

Security Principals

A security principal is an entity that can be authenticated by the system, such as a user account, a computer account, or a thread or process that runs in the security context of a user or computer account and Security groups of these accounts. The important thing to remember is that each principal is automatically assigned a security identifier (SID)when it is created and that these are unique. This is why a domain computer cannot access domain resources if its account is deleted even when a new account with the same name exists.

Access Control Entry (ACE)

An Access Control Entry (ACE) is an element in an access control list (see below). Each ACE controls or monitors access to an object. We see an ACE when we look in the list of security principals which have access tab on an object.
Access Control Lists (ACL)
Broadly speaking an ACLs are the lists of security principals (users, groups and computers that have access to an object. There are two types of ACL. The DACL and the SACL.

Discretionary access control lists (DACLs).

DACLs identify the users and groups that are assigned or denied access permissions on an object. If a DACL does not explicitly identify a security principal it will be denied access to that object.

System access control lists (SACLs).

SACLs identify the users and groups that you want to audit when they successfully access or fail to access an object. Auditing is used to monitor events related to system or network security. A SACL can be found by selecting the Advanced Security settings on an object button and selecting the Auditing Tab


Exchange Problems

Last week, we were unfortunate to have a major problem with our Exchange 2007 service. The server process (store.exe) that runs the mailboxes was crashing every 5 minutes or so. As the process that was failing is fundamental to the service working, it was important to try and diagnose the issue as quickly as possible.

The most difficult part of this diagnosis was that the error was so generic and wasn’t providing any relevant information as to what to look at. Exchange is a complicated and awkward piece of software at the best of times, so the problem was compounded by unsatisfactory logging of what was happening.

We were able to determine that the problem happened on both nodes of a cluster, so it looked likely that it was related to the database or even at a more granular level.

When dismounting databases to try and narrow down the issue, we noticed that when one particular database was dismounted that the problem went away. Sadly this meant a significant amount of downtime for the mailboxes on this affected database, particularly as we needed to obtain diagnostic information for Microsoft to investigate the problem, as it’s a fault that isn’t documented anywhere.

We narrowed down the problem to when a particular message (that was queued on one of our Hub Transport Servers) was trying to be delivered that the mailbox server crashed. We deleted the item from the queue and everything started to work OK. It wasn’t long before the problem reoccurred. We could then correlate (using the wonderful tool that is Powershell) that the second message that was causing a problem was scheduled to be delivered to the same mailbox as the first.

This indicated that the problem was common to one mailbox. We isolated that mailbox away from our production server to provide some stability to the thousands of other users that have mailboxes residing there. Once that mailbox was moved, the other mailboxes were fine, so it seemed as if the problem was really narrowed down.

We could reproduce the crash by replaying the problem message into the test system, so we were now at the stage where we could try and determine what it was about these two messages that caused the problem.

The problem seemed to be caused by some fault in a user’s rules. We had fortunately found the needle in the haystack and at the same time we were able to hopefully provide enough diagnostic information to Microsoft so they can thoroughly investigate why a problem with one user’s rules was enough to crash the entire server. That really is a big failing of Exchange.

One issue we noted was the user who had the problem mailbox was exclusively using Outlook 2003. If the user had moved to Outlook 2007, the problem would have been somewhat alleviated. Outlook 2007 alters the rules format.

It was an incredibly stressful couple of days and underlined the fact that email is a business critical system. We are still waiting to hear back from Microsoft, but should the problem reoccur, we should be much quicker in being able to diagnose the fault.

Time to move on from the Windows 7 Release Candidate

If you are still running Windows 7 RC (I’m sure a lot of people are because it was pretty darned stable), the time to move on is fast approaching.

From 15th February, warning messages will start, saying that from 1st March Windows 7 RC will shutdown every 2 hours. You really want to be off the RC by then because you will lose any unsaved work.

If you continue to use the RC through the bi-hourly shutdowns, on 1st June 2010 the RC will cease to meet “genuine” Windows criteria and will not be able to download anything that checks whether the copy of Windows is genuine. You’ll also lose your wallpaper, but by that point that’s the least of your worries! 😉

I’ve still got one machine running the RC – that will change this weekend!