Hyper-V Server Authorization, Part 1

“What is your name?” crowed the Bridge Keeper of the abyss in Monty Python and the Holy Grail. Invariably, the next question was “What is your quest?” Like the user name and domain name in typical username/password authentication systems, these should be easy, although some days I’ve typed my username or domain incorrectly, and sometimes people aren’t so clear on their quest. But that’s another story.

It is the next question and its answer which are possibly unique per person. In the aforementioned story, getting that wrong is simply disastrous, whether it be ambivalence of affinity to a frequency in the electromagnetic spectrum or ignorance of ornithological species differentiation in terms of unladen velocity. In the wonderful world of computing, the proper authentication is the critical precursor to specific authorization and accounting.

In terms of Windows authentication, the correct username and passphrase combination or smart card and PIN validation yield a user’s security access token (SAT). This token contains a user’s security identifier (SID), the SIDs of the groups they are a member of, some user rights (privileges), and other associated information. In recent versions of Windows (Vista, Server 2008, Seven, and Server 2008 R2) there could be a split token for administrative and non-administrative identities. Through this token obtained via authentication, all Windows authorization and accounting is derived.

That’s the prologue. Many services hosted on Windows have management and end user roles associated with them, along with assignments of abilities through permissions to different users and groups. Operating systems and devices classically offer discretionary access control (DAC) to resources. For example, the Windows registry, NTFS file system, and Active Directory (AD DS and AD LDS) all utilize security descriptors which include ownership, auditing, and permissions. The permissions for each value, file, or object area specified in thee security descriptors’ discretionary access control list (DACL).

Such permissions lists are “discretionary” in the sense that owners of resources, and other users who have been delegated with “take ownership” or “change permissions” permissions could potentially modify the initial security controls, including the permissions and auditing, which had been established for those resources. Therefore, the security of the system is at their discretion. This discretion is a violation the prime directive of another sort of access control called mandatory access control (MAC). As the name implies, the security controls in such a system are indeed mandatory. Everyone, including owners and delegates of resources must follow the security rules established by the central security authority without discretionary exception. Because many systems administrators, and of course resource owners and delegated administrators, want flexibility, DAC is far more commonly implemented than MAC. Again, Windows is primarily a DAC-based system.

In the story of the aforementioned bridge keeper, when King Arthur queried the bridgekeeper, it was shown that the bridgekeeper was subject to the same controls as everyone else, therefore that is an example of MAC not DAC – just in case you were wondering.

In the next part, we will actually focus on RBAC and Hyper-V.


In this article

Join the Conversation