ATHABASCA UNIVERSITY
USING ROLE-BASED ACCESS CONTROL WITH ACTIVE
DIRECTORY TO SECURE NETWORKED COMPUTERS DURING
COMPUTER BASED EXAMS
BY
MARINUS M. L. BOOGAART
An essay submitted in partial fulfillment
of the requirements for the degree of
MASTER OF SCIENCE in INFORMATION SYSTEMS
Athabasca, Alberta
July 2008
© Marty Boogaart, 2008
i
DEDICATION
To Gwyn, who is the love of my life; and to my children, Kerry, Cole, and Chase, of
whom I am so very proud.
ii
ABSTRACT
Is it that we are witnessing a growing trend towards dishonesty, or is it a reflection of
the rapidly expanding Internet and intranet technologies that are merely providing all
students with new and irresistible opportunities to cheat? It is often difficult to detect
cheating; so it is better to simply prevent it. This paper explores Role-based access
control (RBAC) and its applicability to Active Directory as a means of restricting
student access to computer and network resources during computer-based
examinations. RBAC is a model for managing the security of computer-system
resources through the creation of user-roles. Roles provide users with the least
privileges to accomplish the work assigned to them. Active Directory is a directory
service that stores information about objects such as users, computers, and network
resources; but, it is more, in that it is integrated with Windows security, enabling
administrators to manage access to all directory objects. Two questions asked in
the introduction are: (i) "Can RBAC be easily applied to Active Directory?" and (ii)
"Can Active Directory's inheritance of privileges be managed in such a way that
limits to access may be easily and temporally applied?" The answer to both is no.
The bottom line is that Active Directory's DAC security is inherently not role-based,
nor does it purport to be role-based. Although Active Directory is not RBAC
compliant, it does possess enough security features that Lethbridge College may be
able to use scripting to simulate pseudo RBAC roles. This is an approach that is
recommended for further exploration.
iii
ACKNOWLEDGMENTS
I wish to acknowledge three people who helped make the writing of this essay a
pleasure and one person for contributing great, free software to the cause of secure
computer exams. Thank you Dr. Oscar Lin for your encouraging words, careful
review, and patient support as you guided me through the process of writing this
essay. Thank you to Dale Jarrell, who has enough to do, but still made time to
review my work and also encourage me. Thanks to Terry Allred, for setting up an
independent test network where I could play with Active Directory, and also for
acting as a sounding board as he listened to my ideas about Active Directory. And
special thanks go to Dalibor Malek, the author of the free, site-specific browser that
he calls Mango. I wrote him and asked about adding an option to prevent an SSB
from vectoring away from its target domain, and within two days he had added the
necessary option, which makes locking down an exam-browser free and easy.
iv
TABLE OF CONTENTS
CHAPTER I ............................................................................................. 1
INTRODUCTION........................................................................................... 1
CHAPTER II ............................................................................................ 7
ROLE-BASED ACCESS CONTROL (RBAC) MODEL ........................................ 7
Basic Security Concepts and Terminology .............................................................8
Information Security Risks..................................................................................8
Security Principles ..............................................................................................8
Access Control ...................................................................................................9
Access Control List (ACL) ................................................................................10
Permissions versus Privileges..........................................................................10
Authentication versus Authorization .................................................................11
User versus Subject .........................................................................................11
Other Terms .....................................................................................................11
Trusted Computer Systems Evaluation Criteria’s DAC and MAC ........................12
Discretionary Access Control (DAC) ................................................................12
Mandatory Access Control (MAC)....................................................................13
MAC Issues ......................................................................................................14
RBAC Introduction ................................................................................................14
Core RBAC ...........................................................................................................16
Hierarchical RBAC................................................................................................17
v
Separation of Duties (SoD): Static and Dynamic RBAC.......................................18
RBAC Summary ...................................................................................................19
CHAPTER III ......................................................................................... 22
MICROSOFT ACTIVE DIRECTORY IMPLEMENTATION ..................................... 22
The X.500 Directory Standard ..............................................................................23
Objects..................................................................................................................24
Containers ............................................................................................................25
Domain .............................................................................................................25
Organization Unit (OU) .....................................................................................27
Group................................................................................................................27
Site ...................................................................................................................29
Trees and Forests.................................................................................................30
Domain Trees...................................................................................................30
Forests..............................................................................................................32
Security.................................................................................................................32
Objects and Permissions..................................................................................32
Group Policy and Rights...................................................................................34
Rights Trump Permissions ...............................................................................38
Delegation of Administration.............................................................................38
Microsoft Authorization Manager (AzMan) ...........................................................39
Active Directory Comparison to RBAC .................................................................41
A Simple Demonstration of an Active Directory Implementation for Exam Security
..............................................................................................................................45
vi
CHAPTER IV......................................................................................... 48
ROLE ENGINEERING ................................................................................. 48
Role Engineering Approaches ..............................................................................49
Bottom-up Approach.........................................................................................49
Top-down Approach .........................................................................................49
Hybrid Approach...............................................................................................50
Scenario-driven Role Engineering ........................................................................50
Terminology......................................................................................................50
Composition of Work Profiles ...........................................................................51
The Scenario Model .........................................................................................51
Steps in a Scenario-Driven Process.................................................................52
CHAPTER V.......................................................................................... 55
CONCLUSIONS AND RECOMMENDATIONS.................................................... 55
REFERENCES........................................................................................... 59
APPENDIX A ............................................................................................ 65
Role Administrator Scenario: Move Students into a Restricted Role....................66
Step 1: Sentence description and picture.........................................................66
Step 2: Derive permissions and write as <operation, object> pairs .................66
Step 3: Identify constraints ...............................................................................67
Role Administrator Scenario: Return Students to Regular Roles .........................67
Step 1: Sentence description and picture.........................................................67
Step 2: Derive permissions and write as <operation, object> pairs .................67
vii
Step 3: Identify constraints ...............................................................................68
Step 4: Refine scenarios ..................................................................................68
Step 5: Define Tasks and Work Profiles...........................................................68
Computer Student Scenario: Access the Xcommon Directory .............................69
Step 1: Sentence description and picture.........................................................69
Step 2: Derive permissions and write as <operation, object> pairs .................69
Step 3: Identify constraints ...............................................................................69
Computer Student Scenario: Access the Xassignment Directory.........................70
Step 1: Sentence description and picture.........................................................70
Step 2: Derive permissions and write as <operation, object> pairs .................70
Step 3: Identify constraints ...............................................................................70
Computer Student Scenario: Run the Borland Builder IDE ..................................71
Step 1: Sentence description and picture.........................................................71
Step 2: Derive permissions and write as <operation, object> pairs .................71
Step 3: Identify constraints ...............................................................................71
Step 4: Refine scenarios ..................................................................................71
Step 5: Define Tasks and Work Profiles...........................................................72
Step 6: Define preliminary role hierarchy .........................................................72
viii
LIST OF TABLES
Table 1. Summary of RBAC Models .........................................................................21
Table 2. Active Directory as an RBAC Tool ..............................................................42
ix
LIST OF FIGURES
Figure 1. Core RBAC Relationships..........................................................................16
Figure 2. DNS Domain Tree Structure ......................................................................31
Figure 3. Group Policy Configurations ......................................................................35
Figure 4. Software Restriction Security Level ...........................................................36
Figure 5. Additional Rules .........................................................................................37
Figure 6. Network Shares .........................................................................................45
Figure 7. Organization Units and Groups..................................................................46
Figure 8. Assignment Directory Permissions ............................................................47
Figure 9. Xcommon Directory Permissions...............................................................47
Figure 10. Composition of Work Profiles...................................................................51
Figure 11. Simple ATM Scenario ..............................................................................52
1
CHAPTER I
INTRODUCTION
“The Internet has changed the dynamics of dishonest academic practice;
access is no longer for the knowing few but is there for the majority.” . They go on to
say, “The range of dishonest practice is limited only by students’ abilities to use
technology creatively” [1].
Those are discouraging words for academia; but, on the balance, it may be
that rather than indicating a growing trend towards dishonesty, students are merely
presented with new opportunities to cheat [2] [3]. This is what I have witnessed
during computer-based testing at Lethbridge College.
In the early nineties, we could manage our students’ use of computers by
supplying them with floppy disks from which they could retrieve the starting files for
an exam and upon which they could store their completed work. Even during the last
half of the nineties when Internet connections became available on our campus, this
was still a viable solution, since the vast majority of students were not yet familiar
enough with Internet technologies to pose a serious threat to exam security. The
situation has changed rapidly in the new millennium.
Practically all students are now familiar with email and instant messaging. At
Lethbridge College, students also have access to their own personal network
storage space, which they can access from any computer on campus. This is in
addition to the ability to store and retrieve vast amounts of information from tiny,
hard to detect, USB flash drives. On top of all that, the more network-savvy students
2
are also familiar with FTP tools and may have their own off-campus web-sites where
they can share exam information. I am not alone in realizing this. A recently
published list of e-cheating by students lists methods such as: looking at another
student’s computer, email communication, surfing the Internet, accessing
unauthorized sites, accessing other files/software, instant messaging, cell phone /
text messaging, and communicating openly [4]. Other ways to cheat during online
exams include: accessing other websites, seeding test computers with answers, and
bringing in disks containing solutions [4].
I witnessed my first case of instant messaging followed by open
communication during a computer based exam of spread-sheeting skills in 2004.
The testing tool was SimNet, a web-based application that simulates MS Office
applications in order to assess a student’s skill in using of the application.
Against faculty wishes, the lab portion of this class was scheduled in a new
facility called the Computer Commons, which is an open-access lab with about 150
computers. At that time we were not allowed to book sections of the Commons for
exams, so my class was somewhat spread about. I had made the mistake of giving
students the password at the start of the exam, rather than typing it in myself
(something that I now do). A young woman came in a half-hour late and sat at the
opposite end of the Commons, far away from where I had managed to seat the
majority of the class. Since I was able to monitor who was taking the exams, I was
surprised to see her name pop up on my computer screen. This meant that she had
somehow obtained the password without talking to me first.
3
As students finished, I recorded their marks and eventually the late starter
was the only one I still needed to record. Suddenly a recent exam-completer jumped
up from her station and ran over to the late starter. I followed her over and witnessed
that she was helping her friend complete the exam. I also noted that the late starter
had MSN open on her computer. I was surprised at how angry and hostile they both
were towards me for intervening in this behaviour.
As I thought about this, I realized that not only do we need to shut down
messaging tools like email and MSN, but that when using SimNet to test an
application, we also needed to shut down access to the application itself, since that
allows students to test their responses before committing them to the SimNet exam.
It appears that computer networks are not the only hi-tech sources of
e-cheating. Last year I had a student who always wore a Borg-like Bluetooth
earpiece to class; but, I did not allow him to wear it during exams. At that time I was
not yet aware of the report that 9 of 40 senior students at New Mexico State
University had been failed for using cell-phone text-messaging during an exam [5].
Other e-cheating tools include personal digital assistants, programmable calculators,
two-way pagers, and data-enable cell phones [6]. The possibilities to e-cheat appear
endless, but this paper will concern itself with locking down the computer through
network technologies that limit what students can and cannot do during an exam [6].
I do not actively seek evidence of cheating, because I do not have time to
perform the necessary forensics, nor do I relish the process of disciplining the
offenders who invariably deny, deny, and deny some more, the evidence. Even if I
did have the time to perform statistical analysis of exam results, in order to catch
4
80% of the cheaters I would also have to snag about 10 to 20 percent of the
innocent [7]. I only act on cases that are so blatantly obvious that I am compelled to
take action. Furthermore, Lethbridge College does not have a clear policy to support
discipline of the offenders. Hence my preference is prevention.
The ideal solution will use existing network technology (specifically Active
Directory) to allow any faculty member to easily manage a student-group’s set of
network-connected computers the ability to access local and web applications, local
and network drives, and Internet sites. This is a tall order. The adjective ‘any’ for
faculty member includes the IT-phobic among us, which may require too much
programming to be initially viable. The adjective ‘network-connected’ for computers
expands the scope beyond test-centre and general-purpose campus computers to
include student laptops, which the Lethbridge College engineering technology
programs have adopted and other programs are considering. The college’s regular
student-computers have boot programs that restore the hard-drive to a known state,
which facilitates management of its resources. It may well be that this known state
condition is necessary for managing a computer’s resources, which may put security
management of student laptops beyond reach for now.
There are software tools such as Net Meeting and SynchroEyes designed to
allow teachers to manage student computers during exams. The objective to ignore
these and to use Active Directory is two-fold. First, Active Directory is already paid
for while these add on programs are expensive, and second, our experience with
these tools is that they are not as robust as they should be.
5
I have used Net Meeting to view student computer monitors during exams
and I found that viewing twenty to thirty computers is difficult, tedious, and
furthermore I personally find doing it somewhat repugnant. One student told me that
he could tell when I access his computer, and during that exam he would look up at
me and nod every time I accessed his computer. He was not kidding me!
A few years ago I mentioned the exam-security issue at a meeting of college
instructors and a person from the Northern Alberta Institute of Technology said that
they had recently solved the problem by using Smart Technologies’ SynchronEyes
product campus wide. We obtained an evaluation copy and put it to the test. The first
thing that we noticed was that it was just another Net Meeting type tool. When we
tested it, there were only two of us in the computer lab at the time, so we were not
overloading it. I took the role of instructor and my partner was the student. I limited
the applications that he could use and sure enough, every time he started a
disallowed application it would shut down within a minute. He then opened a
command prompt, typed ipconfig/release, started the disallowed application, and
then typed ipconfig/renew. The application was not shut down and the instructor
station did not indicate a violation. A student with a wireless laptop could achieve the
same effect by toggling the computer’s wireless switch to start a disallowed
application, and once one student figures this out, that tool’s effectiveness is void.
Apparently using a tool that sits on top of the operating system is insufficient.
Hopefully using the network OS itself will be more robust.
The goal of this paper is to study Role Based Access Control (RBAC) and its
application to Microsoft’s Active Directory. The RBAC technology can be used to
6
define various student roles as learners and examinees and it defines how to use
these roles to control their access to computer-based resources during their various
tasks. Active Directory is a product that manages users and network/computer
resources.
Two fundamental questions to be answered in this research are, “Can RBAC
role definitions be easily applied to Active Directory?” and “Can Active Directory’s
inheritance of privileges be managed in such a way that limits to access may be
easily and temporally applied?” (By temporally I mean that an instructor should be
able to set a time limit on the students’ limited privileges so as not to have to
remember to restore them after the exam.)
There are currently few practical books on RBAC, which necessitates an
explanation of the model as presented in Chapter II. Chapter III of this paper
provides a description of MS Active Directory, insofar as the needs of this study.
Then Chapter IV describes a method to engineer RBAC roles, with an example
included in the Appendix. The hope is that this paper will be sufficient to justify the
necessary resources to enable a practical test of role-based access control of
computer based exams at Lethbridge College.
7
CHAPTER II
ROLE-BASED ACCESS CONTROL (RBAC) MODEL
Role-based access control (RBAC) is a relatively new standard model for
managing the security of computer-system resources. Prior to RBAC, the “standard
of due care” for many organizations was considered to be discretionary access
control (DAC) [8].
DAC, and its sibling, mandatory access control (MAC), were defined in the
United States Department of Defence’s 1983 standard titled, Trusted Computer
System Evaluation Criteria (TCSEC).
In 1992, after determining that current security products were insufficient for
the needs of the market, the National Institute for Science and Technology (NIST)
developed a proposal for RBAC [8]. RBAC was researched for over decade, and
was eventually accepted in 2004 as standard INCITS 359 2004 by the International
Committee for Information Technology standards (INCITS). INCITS is accredited by
the American National Standards Institute (ANSI) to develop industry consensus
standards for Information Technology [9].
This chapter has seven sections. It describes the RBAC model in sufficient
detail to allow a comparison to Microsoft’s Active Directory, which is the commercial
product used at Lethbridge College. The last section of this chapter facilitates this
comparison by presenting a summary table of mandatory and optional RBAC
features. To help understand RBAC, the first section introduces basic security
concepts and terminology. The next section describes RBAC’s predecessors, DAC
8
and MAC, providing a backdrop against which to appreciate RBAC. The remaining
four sections discuss RBAC itself.
Basic Security Concepts and Terminology
Information Security Risks
The three broad categories of information security risks are confidentiality,
integrity, and availability [8].
• Confidentiality – means that the information is only available to authorized
users. Fundamentally, this is read access.
• Integrity – means that the information is only altered by authorized users.
Think of this as write permission.
• Availability – means that the information is always available when needed.
Denial of service is the most familiar means to thwart availability to
information; however, a cracker who can bypass a system’s access
security will probably not have much trouble in damaging the system [8].
Security Principles
Two fundamental security principles are the principle of least privilege and
separation of duties.
• Least privilege – requires that a user is restricted to only those privileges
necessary to perform their job [10]. For example, if a user only needs
access to the information in a file, s/he should not be able to write to that
file, and certainly should not have administrative abilities that allow sharing
that privilege with others. Furthermore, any fields, files, or applications that
the user does not need should remain inaccessible.
9
• Separation of duties (SoD) – is necessary to reduce the possibility of fraud
and to ensure that conflict-of-interest policies are enforced [11]. This is
achieved by requiring two or more people to complete a function. A
business example is the purchasing function. First the purchasing agent
orders an item, next someone else verifies that the item is delivered, and
finally the accounts payable clerk authorizes payment of the associated
invoice. If a single person could perform all three of these activities, then
that individual could order an item from a fictitious company and pay for
product that was never received. The company still faces the risk in the
first case, but that would require collusion amongst three people.
Access Control
“Access is the ability to do something with a computer resource (e.g., use,
change, or view). [12]”
The following description captures the gist of an online document [13]. A
typical home computer system does not have access control mechanisms. The
owner is free to access all of the system’s resources (e.g., files, applications, and
peripherals). However, in multi-user, multi-computer systems, there is often a need
to manage the ability of users to access the system’s resources. The reasons for
access control include security, privacy, and legislated requirements.
Access control is the management of users’ privileges to access system
resources. In order to achieve access control, such a system needs to manage lists
of users, resources, and the privileges binding users to resources. Robust access
control utilities store access control lists in databases.
10
Access Control List (ACL)
An access control list (ACL) is a fundamental control mechanism attached to
an object that contains the names of subjects who have permissions for that object
[8]. A simple example is the UNIX system for setting a file’s read, write, and execute
(rwx) permissions for the user, group, and others. The UNIX file system example is a
limited ACL since it permits only one user and one group, whereas in general, an
ACL may contain many users and groups.
An advantage of ACL is that it is easy to answer the question, “What users
have access to object X?” however, it is difficult to answer the converse question,
“What objects can user X access?” since this requires inspection of each and every
object [8]. A problem with ACLs is that the proliferation of many users with varying
privileges across many objects creates an enormous administrative burden [8].
Permissions versus Privileges
Effectively, these terms both authorize users to perform operations; but, the
RBAC model distinguishes between them [8].
• Permissions – are assigned to RBAC roles which are defined at the
organizational level.
• Privileges – are assigned at the system level and are specific to that
system. For example, a file system has read/write privileges, while a
database system has insert/delete/modify privileges. An organization’s
information may be mapped across several systems, and so the RBAC
product must map organizational permissions into system privileges.
11
Authentication versus Authorization
These two terms are often confused, but they have different meanings.
• Authentication – is the process of verifying the legitimacy of a user’s
claimed identity [8]. The most commonly used method of authentication is
the ubiquitous password. Other methods include physical devices such as
keys and smart cards, personal identification such as finger prints and
retinal scans, or signature verification by use of public-private key pairs
through services such as VeriSign.
• Authorization – determines what a user is allowed to do [8]. Clearly
authorization requires authentication; but, once authenticated,
authorization manages the user’s permissions and privileges.
User versus Subject
• A user is a person who interfaces with the computer system [8].
• A subject is a computer process acting on behalf of a user [8].
• However, in order to simplify discussions, a user may also be considered
to be a subject [8].
Other Terms
The following definitions are taken from a 1996 paper [14].
• Access – A specific type of interaction between a subject and an object
that results in the flow of information from one to the other.
• Constraint – A relationship between or among roles.
• Group – A set of users.
• Object – A passive entity that contains or receives information.
12
• Resource – Anything used or consumed while performing a function. The
categories of resources are time, information, objects, or processors.
• Role – A job function within the organization that describes the authority
and responsibility conferred on a user assigned to the role.
• Session – A mapping between a user and an activated subset of the set of
roles the user is assigned to.
Trusted Computer Systems Evaluation Criteria’s DAC and MAC
The United States Department of Defence’s “Trusted Computer Systems
Evaluation Criteria standard (TCSEC)” defined two access control modes for military
systems: discretionary access control (DAC) and mandatory access control (MAC).
MAC is more restrictive than DAC, and DAC was soon adopted by commercial and
government organizations. “Throughout the mid-1980s and 1990s, many
organizations considered DAC mechanisms to be the standard of due care. [8]” DAC
and MAC are still used, and since these were the precursors to RBAC, they are
briefly described below. This provides a better perspective of RBAC.
Discretionary Access Control (DAC)
TCSEC defines DAC as, “A means of restricting access to objects based on
the identity of subjects and/or groups to which they belong. The controls are
discretionary in the sense that a subject with certain access permission is capable of
passing that permission (perhaps indirectly) on to any other subject (unless
restrained by mandatory access control). [10]”
DAC is convenient, but one issue is that the primary users of resources are
typically not the owners; the organization is the owner. A problem with DAC is that
13
the ownership tends to be transitive. For example, if a second subject is granted
read access to a file, that subject could copy the information to another file and thus
make that information available to yet another user.
Mandatory Access Control (MAC)
TCSEC defines DAC as, “A means of restricting access to objects based on
the sensitivity (as represented by a label) of the information contained in the objects
and the formal authorization (i.e., clearance) of subjects to access information of
such sensitivity. [10].”
To manage MAC, TCSEC employs two properties that relate the security
levels of subjects against the security levels of objects. They are the simple security
property (a.k.a. the simple security condition) and the *-property (read star-property).
• The simple security property – “The Simple Security Property states that a
subject (i.e., a process executing on a user’s behalf) must not be allowed
to read from storage repositories that are at a higher sensitivity level than
the subject’s current sensitivity level. [15].” This is also described as ‘no-
read-up,’ which makes immediate sense when you consider military
sensitivity levels (e.g., top secret TS, secret S, classified C, and
unclassified U.) A subject possessing an S security level may not read TS
level documents, but is allowed to read C and U level documentation.
• The *-property – “The Star Property states that a subject must not be
allowed to write to storage repositories that are at a lower sensitivity level
than the subject's maximum sensitivity level allowed for reading. [15]” This
is also described as ‘no-write-down,’ the importance of which takes a
14
moment’s reflection to understand. Consider that a subject with S security
level reads information at that level. Allowing the subject to then write that
information to a C or U level document would effectively grant that subject
the ability to lower the sensitivity level of the information. Thus the no-
read-up, no-write-down descriptions are easy ways to understand and
remember the effect of these two properties.
MAC Issues
Clearly MAC is a powerful tool for ensuring the confidentiality of information;
but, what about the integrity and availability risks? Does MAC ensure that
information is not altered by unauthorized users? The answer is no. Under MAC, a
user at the lowest sensitivity level is able to write up. The user may not intentionally
do so, but if a subject (i.e., computer process) invoked by the user is infected with
Trojan malware, then that subject has the ability to write to all files at the same and
higher sensitivity levels and thus could alter (integrity risk) or corrupt (availability risk)
those files.
Another issue is precision of control. For example, rather than granting the
user read-access to specific, job-related files, the read-down property permits
read-access to all files at that user’s level and lower. There is no cutoff mechanism
of just one or two levels or even better, for specific job-related-only files within any
level.
RBAC Introduction
With role-based access control (RBAC), access permissions are based on the
roles that a user plays in an organization. Roles are named after the positions held
15
within an organization, which simplifies the administration of access against jobs.
[12]
A primary business justification for RBAC is that mapping a large number of
users to a small number of well-defined roles reduces the administrative overhead of
managing system security [16]. “Roles can be updated without updating the
privileges for every user on an individual basis [12].” In implementing an RBAC
system, an organization should first apply it to roles that have the greatest number of
users and experience the greatest number of changes [16].
Note that in the first paragraph of this section, the phrase “roles that a user
plays” is plural. This is an important distinction since users often need different
permissions at different times in the performance of their functions. This facilitates
the concept of least privilege, since if a user was limited to one and only one role,
then that role would have to possess many permissions, not all of which may be
necessary at any one time [17]. Or alternatively, users would require multiple
accounts, which has its own problems.
An interesting side point to demonstrate the power and flexibility of RBAC is
that it can be used to enforce DAC and MAC, and Ferraiolo et al. dedicate an entire
chapter of their book to this [8].
The RBAC specification defines four models; core, hierarchical, static
separation of duties (SoD), and dynamic SoD. Core RBAC can stand alone, but it is
required in order to implement the other models. The SoD models may work with or
without the hierarchical model, and the literature discusses the SoD models in both
configurations.
16
Core RBAC
Prior to RBAC, a user was directly associated with a resource. RBAC
separates users and resources by introducing roles (Error! Reference source not
found.). Note that Figure 1 shows many-to-many relationships. A role may have
many users and a user may have many roles. Similarly, a role may have many
permissions, and a permission may be assigned to many roles. This is a key
difference between roles and groups, since some systems allow a user and/or a
permission to belong to only one group [8]. However, a group could be considered a
role if it meets the many-to-many criteria.
Figure 1. Core RBAC Relationships
Notice that there is no direct relationship between permissions and users. In
RBAC, users obtain permissions by being assigned to roles. “[The p]Permission
based on the individual user ID is in effect a loophole in the enforcement of [the]
security policy. [8]”
Permissions are atomic units of work within a computing environment and
define operations that are applied to objects.
A user may simultaneously activate more than one role at any time. RBAC
roles must be carefully crafted to match the worker’s duties in the enterprise.
Performance of these duties may span several systems (e.g., email, database, web
site, file system). When a user is mapped to a role, the RBAC system maps that
17
user to the various systems by creating appropriate user accounts, based on the
role’s permissions. In reverse, when a user is deleted from a role, the RBAC system
deletes the user’s permissions from all of the role’s associated accounts. (The
literature remains silent on this, but if a user has overlapping roles and maintains
one or more of those overlapping roles, then clearly the RBAC system must be
robust enough to maintain those accounts where the permissions overlapped.)
Hierarchical RBAC
Hierarchies are based on inheritance. RBAC’s role hierarchy model reflects
the fact that permissions often overlap across roles. For example, all users at an
organization may need access to email and internal web-pages. A base role
containing these fundamental permissions could be inherited by the user-specific
roles. Thereafter, common permissions for all users could be managed by modifying
this base role. This requires the core RBAC ability for users to activate multiple roles
at any time.
The hierarchy of RBAC roles allows these roles to reflect the hierarchy of
organizational roles. For example, at a hospital, an intern has a limited set of
permissions. A physician has all of the intern’s permissions, plus more, and so on up
the line to specialists like oncologists and ophthalmologists. These could be
inherited in a tree-like fashion, with the root being the intern’s role, which the
physician inherits, and so on.
In the design of a role hierarchy, there may be roles with no assigned users,
but exist only to be inherited (e.g., possibly the base role described in the first
paragraph of this section). These roles are called connector roles. This design
18
requires more roles, but usually results in the positive tradeoff of a lower number of
role-permission assignments [8].
The RBAC standard defines two types of role hierarchies, general and limited.
The familiar tree hierarchy is a limited hierarchy wherein each role has either a
single ascendant and one or more descendents, or vice-versa. The general
hierarchy permits a role to have both multiple ascendants and multiple descendents,
which permits a role to inherit from otherwise disjoint roots. Although the general
hierarchy is more versatile, the limited hierarchy is defined due to its widespread
usage [8].
Separation of Duties (SoD): Static and Dynamic RBAC
Separation of Duties (SoD) is not deemed an issue for securing networked
computers during computer based exams, so the following description is only
provided to complete the discussion of the RBAC standard.
Separation of duties requires two or more users to perform the complete
series of tasks in a high-risk operation. Since such a condition requires collusion to
cause damage, the risk to the organization is minimized [8]. For example, an IT
specialist who has the ability to create a new user account should not also have the
ability to alter the log files that reflect that creation, otherwise s/he could create
unauthorized accounts surreptitiously.
The RBAC standard defines two types of separation of duty models, static
and dynamic. Static SoD prevents a user from being assigned to mutually-exclusive
roles. Thus a user can only be assigned to one of two mutually exclusive roles and
19
not to both. Static SoD extends this restriction to inherited roles in the case where
the hierarchical RBAC model is also used.
Static SoD may be too restrictive for some job duties, where a superior user
may, at times, need to ‘change hats’ in order to function efficiently. The dynamic
SoD model allows for the design of RBAC systems to provide this flexibility, by
allowing users to be assigned to mutually exclusive roles, of which only one may be
active at any given time. Dynamic SoD is more difficult to implement and also
requires some type of auditing mechanism to prevent abuse [8].
RBAC Summary
The summary table below is provided to facilitate the evaluation of Microsoft
Active Directory (MSAD) as an RBAC management system at the end of the next
chapter. If MSAD does implement RBAC, then to what extent does it do so? Is
MSAD only core or does it also model hierarchical RBAC, and if it models
hierarchical RBAC, then does it support a general or only a limited hierarchy? What
about separation of duties? An access management product does not have to
implement SoD in order to be labeled RBAC compliant; but, does MSAD implement
SoD, and if it does, is it static SoD or dynamic SoD?
Someone with a cursory understanding of both RBAC and MSAD might
reason that MSAD implements RBAC. Seeking the answer via a search of the
Microsoft site using Google (e.g., site:micorosoft.com RBAC “Active Directory”) is
disappointing, because the results do not contain any form of the desired statement,
“Active Directory implements role-based access control.” The Microsoft product
called Authorization Manager (a.k.a. AzMan) makes the claim, “AzMan is a role-
20
based access control (RBAC) framework… [18].” So the answer for MSAD is no.
The initial question, “Can RBAC role definitions be easily applied to Active
Directory?” must now be modified to ask, “With or without AzMan, can RBAC role
definitions be easily applied to Active Directory?”
21
Table 1. Summary of RBAC Models
RBAC Model Capabilities
Core
• Users acquire permissions through roles
• User-role assignments may be many-to-many
• Permission-role assignments may be many-to-many
• Users may use multiple roles simultaneously
• Creates role accounts on all systems as needed
Hierarchical – Limited
• Allows inheritance of roles in a tree format. That is it
supports multiple ascendants with a single
descendant or it supports multiple descendants with a
single ascendant.
Hierarchical – General
• Allows multiple inheritance of roles in both directions.
That is it supports multiple ascendants and multiple
descendants simultaneously.
Static SoD • Enforces static separation of duties by preventing the
assignment of users to mutually exclusive roles.
Dynamic SoD
• Allows assignment of users to mutually exclusive
roles, but prevents them from simultaneously invoking
those roles at run time. This also requires an auditing
mechanism to prevent abuse.
22
CHAPTER III
MICROSOFT ACTIVE DIRECTORY IMPLEMENTATION
Its name accurately describes its primary purpose. Active Directory is a
directory service that stores information about objects such as users, computers,
and network resources [19]; but, it is more. Active Directory is integrated with
Windows security, enabling administrators to manage access to all directory objects
[20]. This access is based on the NTFS file system where resource owners can
permit access to other users at their discretion; thus, Active Directory’s security is
based on the discretionary access control mode (DAC) [19] [21].
The following description is exclusive focused on Active Directory 2003; but,
they are so similar, that roughly eighty percent of the description could also apply to
Active Directory 2000 [19]. Typically, general descriptions apply to both versions of
Active Directory, whereas specific details, such as those in the very next section, are
usually different.
This chapter has eight sections. The first section acknowledges Active
Directory’s roots in the X.500 directory standard. This is followed by four sections
that describe Active Directory itself: objects, containers, trees and forests, and
security. The sixth section overviews Microsoft’s Authorization Manager (AzMan),
which is billed as an RBAC tool, to determine its necessity for and applicability to the
purposes of this paper. Finally, the chapter ends with a section that summarizes how
closely Active Directory appears to address the RBAC principals, followed by a
section that demonstrates a simple application of Active Directory using RBAC
23
principals to secure, during an exam, computer and network resources that are
otherwise available to the students.
The X.500 Directory Standard
Prior to the advent of directory services, accessing a network resource
required locale knowledge such as resource name (e.g., file or printer) workgroup or
domain name, computer or server name, and possibly the path to a file’s folder. On
larger networks this approach becomes difficult for administrators and onerous for
inexperienced and casual users. A directory service can simplify management and
access of computer resources [22].
Telephone directories are familiar analogues to computer directory services.
Telephone directories use a simple method to access information. Subscribers find
phone numbers by searching the appropriate city’s directory for the target’s last
name and then by the first name or initial [20]. In a similar manner, Active Directory
uses the tree-like structure of the Domain Name System (DNS) to locate network
resources [23] [24].
Active Directory is based on the X.500 series of international standards that
describe electronic directory services; but, it does not strictly comply, and it also
substitutes the defined Directory Access Protocol (DAP) with the Lightweight
Directory Access Protocol (LDAP). Use of LDAP supplies the necessary access
services and offers a few advantages: (i) LDAP runs on the popular TCP/IP, rather
than DAP’s ISO/OSI requirement; (ii) LDAP’s inherent lightweight requires less client
computing resources; and (iii) LDAP is already the defacto standard for accessing
directory services. [20] [19]
24
In short, a client can query (e.g., access, update) objects in the Active
Directory database by using the protocols defined in the LDAP [23] [19].
Objects
Objects are instances of classes. Active Directory comes with 191 predefined
classes, each of which contains some subset of the 1070 predefined attributes
(a.k.a. properties) that describe them [19]. Attributes are classified as mandatory and
optional [22]. Active Directory is extensible, so if the default classes and attributes
are insufficient or inadequate, then the system administrator can modify the schema
to create, deactivate, and/or modify attributes and classes [19] [22].
Objects are units of information used by Active Directory to represent items
such as: users, computers, groups, printers, files, folders, services, and even Active
Directory entities such as domains, organizational units, configuration information,
and the schema [19] . Administrators create objects for users, computers, shared
printers, shared folders, groups, et cetera; while other objects are automatically
created by software installation programs [19].
Two fundamental and predefined Active Directory objects, computer and
user, have the following purposes:
• User object – is an account that a user can log on with (authenticate);
contains mandatory attributes (e.g., full name, logon name, and password)
and purely informational attributes (e.g., description, office, telephone
number); and is a security principal (i.e., is authorized via rights and
permissions) [19]. The location of the user object in the hierarchy dictates
which rights it inherits [19].
25
• Computer object – ties a workstation or server to the Active Directory via a
computer account; contains mandatory attributes (e.g., name) and
informational attributes about the computer (e.g., description); and is a
security principal (i.e., has rights and permissions). The location of the
computer object in the hierarchy dictates which rights it inherits [19].
Disabling a computer account prevents users from using a domain
account to log on to the computer [19].
For temporary data storage, Active Directory supports the creation of dynamic
objects with a predetermined time to live, after which they are deleted [19].
Containers
Containers are objects used to hierarchically organize other Active Directory
objects [23]. Containers are to objects as folders are to files. Containers can hold
objects and other containers; but objects, like files, only store information [19].
Primary Active Directory containers include domain, organizational unit (OU), group,
and site.
Domain
Domain is the most fundamental unit of Active Directory. Installing Active
Directory onto a Windows 2003 server, via the dcpromo command, promotes it to a
domain controller. The domain is named using DNS rules. For example, the first
created domain might be named sxam.ca. (Note: This DNS name does not have to
be available on the Internet, but the organization would be wise to register it.)
Domains are arranged hierarchically as discussed later in trees and forests. Every
domain controller belongs to only one domain; but, a domain may (and ideally
26
should) be managed by more than one domain controller. Likewise, other servers
and workstations also belong to only one domain [19]. In domains with more than
one domain controller, one of them (usually the first) is the master domain controller
[19]. The functions of the master domain controller are beyond the scope of this
paper.
The simplest Active Directory system for a small organization requires only a
single domain, and it could function without any other containers. How many
domains do you need? Microsoft recommends that organizations have a specific
reason for creating additional domains [19]. Additional domains have costs: (i)
additional licensed servers, (ii) increased network traffic for replication, (iii) it is more
difficult to move users and resources between domains rather than OUs, and (iv)
independent domains require individual administration [19].
Domains serve three purposes [19]:
• Replication unit – All controllers within a domain share all of their directory
information, so that over the duration of a replication interval, all of a
domain’s controllers contain the same information. Replication provides
the necessary redundancy to ensure uninterrupted operation in spite of
individual domain controller failures. Also, additional domain controllers
can improve server responsiveness.
• DNS namespace – An Active Directory domain is also a DNS domain.
• Administrative unit – Separate domains may be administered by different
people. Also, the domain is a security policy boundary where security
27
settings, such as password complexity, affect the entire domain. Different
domains could have different security policies.
Organization Unit (OU)
Organizational units (OUs) are logical entities (logical as opposed to
representing physical objects) used to group a domain’s objects, delegate
administration, manage user permissions and privileges, and control users’ visibility
of objects [19]. Tree-hierarchies of OUs are created by containing OUs within other
OUs, the top OU of the hierarchy (i.e., the root) is actually the domain itself [19]. The
administrator’s view of Active Directory resembles a file-folder, where OUs resemble
folders that contain other folders (containers) or objects [19]. OUs should be created
to match either an organization’s administrative structure (e.g., finance, registration,
academic) or its physical structure (e.g., Vancouver, Calgary, Toronto), or even
object types (e.g., printers, users) [19]. Second-level OUs could be created with
alternate criteria (e.g., Sales-Calgary, Sales-Halifax, Sales-Winnipeg) [19].
Group
Groups are not part of the Active Directory hierarchy. Objects (i.e., users,
printers, computers, and resources) must all belong to only one domain and only
one organization unit within that domain; but, they may have membership in more
than one group [19]. The purpose of groups is to assign permissions to a collection
of like-objects.
Active Directory has two types of groups: security and distribution; and both
types may have users, contacts, and computers as members. Security groups are
primarily used to assign permissions and group policies (rights) [19]. In general, all
28
users should only receive their rights via the groups that they belong to. Distribution
groups are lightweight groups that are not used by Active Directory itself, but may be
used by other directory-enabled services (e.g., an email server) [19]. This paper is
not concerned with distribution groups.
Both group types can have one of three scopes: global, universal, and
domain-local. Global groups are mainly used to organize user objects; domain-local
groups are mainly used to organize resource objects [23].
A group’s scope determines how it can be used across domain boundaries
[19]. The preferred membership ordering of objects, groups, and resources is:
user/computer object is a member of a global group which is a member of one or
more domain-local groups, which contain permissions for resources. The order may
not be reversed. That is, a domain-local group cannot be a member of a global
group, and so on.
User and computer objects may only belong to global groups within their own
domain, and although membership in global groups is recommended, Active
Directory does permit them to belong to domain local groups of any domain, or even
be assigned any domain’s resource permissions directly.
Resource objects may only belong to domain-local groups within their own
domain. Global groups may belong to domain-local groups of any domain, which is
how groups of users may, and preferably should, be assigned permissions to groups
of resources. [19]
Universal groups, which are new to Active Directory 2003, are aptly named
since they can accept both user and resource objects from any domain. (Note the
29
descriptive similarity between universal groups and RBAC roles.) This simplifies
administrative design, but it comes at the price of greater replication overhead which
could degrade performance in large networks [19].
The ease of universal groups is good for single domain networks where the
overhead cost is not an issue [19]. If the designer is certain that the application will
remain as a single domain, then the Active Directory design could avoid global and
domain-local groups altogether.
In large networks, universal groups are the only option when users from
different domains need permissions to resources in different domains [19]. The best
strategy for using universal groups in large networks maintains employment of global
and domain-local groups. Thus, within a domain, global groups of users would be
assigned membership to network-local groups of resources; while across domains,
global groups of users from one or more domains would be assigned membership to
a universal group that has membership in domain-local groups of one or more
domains.
As a final note, Kouti makes this association between groups and roles, “You
might want to create a group containing only one person. Usually only one person at
a time holds a role, so the group has only one member. For example, if some user is
taking care of backups this month, you could put her in a group and give that group
the appropriate permissions. When someone else takes over the role, you change
the group membership by removing the first user and adding the new user [19].”
Site
Sites are intraconnected by LANs and interconnected by WANs.
30
Domains form part of the logical structure of the Active Directory framework,
and as previously mentioned, domains are replication units. Domains controllers
may be at different physical locations that are connected by either a LAN or a WAN.
Replication over a WAN may be less efficient than it is over a LAN for two reasons:
(i) excessive consumption of limited WAN bandwidth and (ii) higher operating costs
for WANs.
Two tradeoffs to ameliorate these WAN replication issues are: (i) increase the
duration interval between replications and (ii) compress the replication data. A site
definition lets Active Directory know the physical structure of the domain so that it
can make these tradeoffs accordingly [19]. Furthermore, site information enables
Active Directory to route a user’s logon request to the closest physical domain
controller [25].
Trees and Forests
There are two differences between domain trees and forests: (i) trees have a
contiguous DNS namespace; forests do not, and (ii) trees define the scope of Active
Directory searches [19].
Domain Trees
In large organizations it may make sense to partition the administration of
users and resources into separate domains that are related in a tree structure.
Domain trees are organized by DNS rules. Suppose a first domain (root) is named
sxam.ca, then additional domains could form the tree hierarchy shown in Figure 2.
Since Active Directory uses the DNS, whether or not the root directory is connected
to the Internet is strictly an administrative decision rather than a technical hurdle. If it
31
is connected to the Internet, then the organization may also place a firewall between
the root directory and the rest of the tree as necessary.
Figure 2. DNS Domain Tree Structure
In Active Directory trees, domains establish two-way transitive trusts by
default. This means that if domain X trusts domain Y and domain Z trusts domain Y,
then domains X and Z also trust each other. Thus if a user authenticates on any one
of X, Y, or Z, she may access resources on all three domains as per her rights and
permissions without re-authenticating. Active Directory achieves this single-sign-on
by using Kerberos authentication as the default authentication mechanism [22] [25].
32
Forests
The trees of a forest do not share a DNS namespace. They do share a
common schema, a common enterprise configuration, a global catalog, and can
establish trust relationships [19].
An organization could duplicate (or not) the tree structure of Figure 2 using
sxam.net and sxam.org; but, the .net and .org suffixes define different namespaces.
Linking these additional namespaces to the master sxam.ca domain controller
creates a forest. In this example, the sxam.ca domain controller alone assumes
additional roles for the entire forest [19] [25]. The functions of the forest-wide roles
are beyond the scope of this paper.
Security
Active Directory authenticates users’ identities as they log on to the network.
Then based on their permissions and rights, it authorizes their access to the
system’s resources [19].
Objects and Permissions
Permissions are granted for objects. A single permission authorizes an
operation on a specific object. Permissions may be granted by the object’s owner
(DAC) and also by privileged administrators. Permissions that are not explicitly
granted are implicitly denied [21]. From best to worst, permissions should be granted
to: domain local groups, global and universal groups, directly to users [19].
Two types of permissions are special and standard. Special permissions are
singular controls. The three standard permissions (full control, read, and write) each
map into a number of special permissions. For example, selecting the standard read
33
permission activates the three special permissions: list contents, read all properties,
and read permissions [19]. If necessary, an administrator could fine-tune this for a
particular user or group by disabling one or two of these special permissions, or
vice-versa by adding one or more special permissions. [19]
The granular nature of permissions allows an organization to control which
attributes of which objects various users can see [19]. Suppose an organization
adds a salary attribute to its employee users, then it should only allow the payroll
department to see that the attribute even exists, and this is possible in Active
Directory [26].
Permissions may be allowed or denied and they may be inherited from those
assigned to higher containers. The order of precedence of permissions is (from
highest to lowest): non-inherited deny, non-inherited allow, inherited deny of the
immediate container, inherited allow of the immediate container, inherited deny of
the next container, inherited allow of the next container, and so on. Since deny
permissions take precedence, the administrator could create a group with a broad
set of permissions and then deny some of those for inheriting groups. [19]
Inheritance can be managed in a number of ways. Parent options allow
individual permissions to affect: the object and its children, only the object, only the
children, or only the immediate children [19]. Objects may also accept or decline all
inherited permissions [19]. However, group policy objects can force inheritance,
which takes precedence over blocking [19].
34
Group Policy and Rights
Think of group policies as the settings for user and computer, rights and
privileges. Group policies are stored in group policy objects (GPOs) which may be
linked (applied) to one or more sites, domains, and OUs [19] [25]. Similarly, sites,
domains and OUs may be linked to one or more GPOs [19]. Somewhat
counter-intuitively, group policies are not linked to groups, since the name is a bit of
a misnomer, which really means a group of policies, rather than policies for groups
[19].
There are two types of user rights: (i) the right to log on, and (ii) privileges to
manage system resources (e.g., creating shared folders, setting the system clock,
backing up, loading device drivers) [27] [28].
Group policies are stored in group policy objects (GPOs) where they can be
centrally managed. Some policies can also be stored in the computer itself, but
those decentralized policies are difficult to administrate.
A user may be affected by multiple policies (e.g., site, domain, all OUs in the
tree, and the local computer policy). In that case, the closest settings take
precedence, unless the No Override option is enabled in a higher level GPO. When
similar policies are set for both the user and the computer, the computer policy
prevails. [19]
If necessary, even finer control of the application of group policies is available
by filtering them dynamically using WMI (Windows Management Instrumentation)
filters based on criteria about the target that can be assessed via the associated
WQL query language [19].
35
Group policies are processed whenever a computer starts, a user logs on,
and (typically) every 90 to 120 minutes thereafter. They may also be manually forced
from the command line via a “gpupdate /force” command [19].
Group policies have two policy configuration sections called Computer
Configuration and User Configuration (Figure 3). User policies apply to those users
no matter what computer they log on to; computer policies apply to all users who log
on to that computer [29].
Figure 3. Group Policy Configurations
Group policies have three main categories for both user and computer
configurations [19]:
• Software settings: to install, upgrade and remove applications – in effect a
user’s applications can follow her around.
• Administrative templates: define registry settings – a user’s settings can
follow her around.
• Windows settings: for logon/logoff scripts, software restriction, Internet
Explorer settings, and folder redirection – among other things, a user’s
documents can follow her around.
36
Two ways to set software restrictions are: (i) allow running of all applications
except those that are specifically restricted, or (ii) prohibit running of all applications
except those that are specifically allowed [19]. Figure 4 shows a security restriction
that disallows users from using all software other than those excepted in the
Additional Rules section.
Figure 4. Software Restriction Security Level
The Additional Rules section is automatically populated with four unrestricted
rules (the first four shown in Figure 5) that are necessary for the operating system to
function. Disallowing these four rules results in a non-functioning environment. One
of the rules (the third rule shown in Figure 5) allows all executables in the Windows
directory to run. This includes programs such as notepad and calc. If necessary,
such programs can be disallowed individually as demonstrated by the sixth rule in
Figure 5.
37
Figure 5. Additional Rules
Notice that both Path and Hash type rules are used in Figure 5. The four
available rule types, in order of precedence, are [30]:
• Hash rules (highest precedence) – a hash code is generated by browsing
to the program file. The rule applies regardless of the program’s location.
Two disadvantages of this approach are: (i) it requires that all computers
have exactly the same version of the program and (ii) updating the
program file requires creating a new hash code.
• Certificate rules – are based on digitally signed certificates created by the
authors of the program and verified by a signing organization such as
VeriSign.
• Path rules – can be either a file or folder. Folder paths automatically
include subfolders. The path may be hard-coded or based on registry
variables. A disadvantage of using path rules to disallow programs is that
shortcuts to a program will allow it to run, so the administrator must also
specify shortcuts along with the program itself.
38
• Internet Zone rules – can identify software that is downloaded from
Internet Explorer zones. Thus users could be permitted to download and
run programs only from specific zones: Internet, intranet, restricted sites,
trusted sits, or my computer.
Rights Trump Permissions
Rights are applied to users and computers, whereas permissions are applied
to items like files, folders, and printers. For example, a user’s right log on to a
computer, to backup a hard drive, or to set the computer’s clock, are actions that are
not really applicable to most other objects.
An administrator’s right to take ownership of a file or folder may conflict with
his permissions to read or write to that file, but once he takes ownership, he gains
those permissions. So even though rights are typically not the same as permissions,
when the two conflict, then rights trump permissions.
Delegation of Administration
Delegation of administration is a new concept of Active Directory [26] [22]. It
is the ability to assign to users and groups, a continuum of rights and permissions
between the lowly guest account and the powerful system administrator. This allows
a system administrator to offload tasks to other administrative users by assigning
them some or all rights to different domains or organizational units. Additionally,
otherwise ordinary users could be granted just a few rights and/or privileges in order
to locally manage their own areas [19].
39
Microsoft Authorization Manager (AzMan)
“AzMan is a role-based access control (RBAC) framework that provides an
administrative tool to manage authorization policy and a runtime that allows
applications to perform access checks against that policy. The AzMan administration
tool (AzMan.msc) is supplied as a Microsoft Management Console (MMC) snap-in
[31].”
Microsoft's Authorization Manager (AzMan) was first introduced as part of
Windows Server 2003 [32]. By mid-2005, a Windows 2000 version of the AzMan
runtime component (only) was available for download [33].
As of this writing, Lethbridge College does not use AzMan, since as one of
the senior network technicians said in a private conversation, “It has no practical use
at the college….” Why would he say this? And clearly, in the absence of external
pressures for enhanced management of user rights and permissions, there is
wisdom in following the old adage, “Let sleeping dogs lie.”
As previously noted, Active Directory’s universal group, with its duality of user
membership and resource permissions, bears the appearance of an RBAC role.
Even without universal groups, the appearance of an RBAC role is still achievable by
placing a global group (of users) into a domain-local group (of resource
permissions). So what is missing? The following brief overview of AzMan is provided
to help in clarifying Active Directory’s shortcomings in regards to RBAC.
The discretionary access control (DAC) used by NTFS relies on access
control lists that are designed into the operating system (OS) objects. Not all
operations can be directly associated with a specific OS object, so the only way to
40
control access to specific actions within programs is to custom design securities into
the applications themselves. AzMan helps [34].
AzMan policies can be stored as separate XML files or directly inside Active
Directory. The policy file is associated with an application. The GUI snap-in
simplifies management of these policies by presenting a tree view of the access
permissions in terms of operations (the most atomic unit), tasks (collections of
operations), and roles (collections of operations, and/or tasks, and/or other roles).
Each operation has an associated unique numeric code that AzMan’s runtime
component can use to determine which aspects of an application’s operations
should be enabled. The application programmer can use the application
programming interface (API) of the AzMan runtime dll to query the aforementioned
RBAC policy, in order to determine which operations (that most atomic unit) the
program should enable for a user [35].
In short, AzMan provides: (i) a runtime API resource to reduce the burden of
programming RBAC securities into Windows applications, and (ii) a GUI tool to
simplify RBAC administration of applications, by mapping their operations into tasks
and roles. In other words, while Active Directory can control access to an application
by enabling or denying its file privileges, AzMan enables programmers to extend
access control into the application itself. Therefore, until we have (or create)
applications that access the AzMan API, as our network tech said, “It has no
practical use at the college…."
41
Active Directory Comparison to RBAC
Two facts already established are: (i) Active Directory’s authorization model is
based on discretionary access control, and (ii) according to the AzMan description,
true RBAC must extend into managing the internal features of user applications. The
RBAC capabilities of Table 1 that are not available with Active Directory are crossed
out in Table 2.
The loss of the general hierarchy in row three does not exclude RBAC status,
as the limited hierarchy of row two is sufficient. Also the loss of the last two rows,
separation of duties, is inconsequential to the goal of this research.
42
Table 2. Active Directory as an RBAC Tool
RBAC Model Capabilities
Core
• Users acquire permissions through roles
• User-role assignments may be many-to-many
• Permission-role assignments may be many-to-many
• Users may use multiple roles simultaneously
• Creates role accounts on all systems as needed
Hierarchical – Limited
• Allows inheritance of roles in a tree format. That is it
supports multiple ascendants with a single
descendant or it supports multiple descendants with a
single ascendant.
Hierarchical – General
• Allows multiple inheritance of roles in both directions.
That is it supports multiple ascendants and multiple
descendants simultaneously.
Static SoD • Enforces static separation of duties by preventing the
assignment of users to mutually exclusive roles.
Dynamic SoD
• Allows assignment of users to mutually exclusive
roles, but prevents them from simultaneously invoking
those roles at run time. This also requires an auditing
mechanism to prevent abuse.
43
Even though Active Directory is not RBAC, it does appear to have features to
accomplish the goal of limiting student access to computer resources during exams.
Although Active Directory is flexible enough that its application could easily violate
RBAC principles, the recommended rules of usage actually mirror RBAC concepts.
How well can Active Directory model RBAC and even more so, how well can it meet
the needs of securing resources during an exam? Consider the following points:
• Active Directory's DAC security mode allowing resource owners to grant
permissions to others should not be a problem if all critical resources are
owned only by administrators.
• Universal groups resemble RBAC roles in that they both permit
many-to-many relationships with both users and resources. Similarly, the
assignment of a global group of users to a domain local group of
resources also has the appearance of an RBAC role. However, not all of
Active Directories resources can be controlled by groups alone.
• For the purposes of this research a typical student requires two roles. One
as a regular student and another as an exam student. The regular role
allows the student to run all available applications and access three
networked directories: common, assignment, and personal. The exam role
restricts the available applications and switches access to two different
network directories: xCommon and xAssignment.
• Controlling applications is achieved via group policy, while controlling
folders is achieved via permissions. Group policies can be applied to
organization units, but not to groups; permissions can be applied to
44
groups, but not to organization units. In order to apply both policies and
permissions to a "role type" object, the administrator must create a
security group with permissions, inside an organization unit with one or
more group policies.
• This OU/group pairing requires a three-step process to move a user
between roles: (i) move the user from one OU to another, (ii) remove the
user from the old group, and (iii) add the user to the new group. This
non-trivial task is prone to errors, so switching roles for a whole class of
students will require scripting to make it feasible.
• Unfortunately, manually initiated switching of roles is not RBAC compliant.
In a true RBAC implementation, the system would recognize the student’s
role as regular or exam and automatically adjust accessibility accordingly.
• The previously identified ability to create temporal storage directories does
not extend to the necessary temporary reassignment of policies and
permissions, so Active Directory cannot be directed to automatically
restore regular roles after the exam.
45
A Simple Demonstration of an Active Directory Implementation for Exam Security
Figure 6 shows four shared directories created on the server: Assignment and
Common for the regular role, and Xassignment and Xcommon for the exam role.
Figure 6. Network Shares
Figure 7 shows two organization units created in Active Directory:
RegularStudents, which contains three more organization units named: CIT, BUS,
and Trades. Only CIT was populated with students. The CIT OU also contains a
security group called CITstudentGroup and the students are members of that group.
The RegularStudents OUs do not have group policies, but the ExamStudent OU
does have a group policy to restrict software access. That group policy is illustrated
in Figures 4 and 5. The ExamStudent OU also contains a security group named
ExamGroup.
46
Figure 7. Organization Units and Groups
Figure 8 shows how the two groups are permitted to the Assignment
directory. The CITstudentGroup has write permission, while the ExamGroup is
explicitly denied all permissions.
Figure 9 shows how the two groups are permitted to the Xcommon directory.
The ExamGroup has read permission, while the CITstudentGroup is explicitly denied
all permissions.
Moving students between the CIT OU/group role and the Exam OU/group role
using the previously described three-step process had the desired effects.
48
CHAPTER IV
ROLE ENGINEERING
The purpose of RBAC role engineering is to define a minimally complete set
of roles and role-hierarchies along with their associate permissions and constraints
[36] [8]. The process should incorporate a broad base of organizational inputs
including technical perspectives, business rules, and social aspects [8].
Role engineering is analogous to systems analysis, as evidenced by citations
in papers on RBAC role engineering that refer to sources discussing goal oriented
requirements engineering for systems design [37] [8] [38]. Like systems design, the
role engineering process is also described in terms of a life-cycle, with a final
maintenance phase [8] [39].
Although large organizations may have hundreds and even thousands of
roles, the typical user has between one and five roles [8]. Developing even hundreds
of roles is a huge challenge that should not be initially expected [40]. Rather, the role
model should start with easily defined roles for the largest groups of users and then
be extended if and as needed [8].
Despite Active Directory’s shortcomings as an ideal RBAC compliant system,
it still makes sense to engineer user roles in order to ensure that they adhere to the
principle of least privilege. Well defined roles also facilitate the role-maintenance
phase of the role-engineering life-cycle.
49
The next section of this chapter discusses three role-engineering approaches.
This is followed by a section detailing the scenario approach, which is used in
appendix A to define necessary roles as discussed in this paper.
Role Engineering Approaches
Three possible approaches are bottom-up, top-down, and hybrid.
Bottom-up Approach
In the typical bottom-up approach, the role-engineer examines existing
permissions for users associated with particular job-roles in the organization;
however, this may result in roles that do not adhere to the principle of least privilege
for a number of reasons. The common practice of cloning to assign user permissions
can give new users permissions beyond what they need to perform their jobs. Also,
as jobs change, additional permissions may be assigned, but obsolete permissions
are rarely deleted [8]. So this should be only the first step, and the resultant role
permissions must be validated through other means.
Top-down Approach
The top-down approach analyzes the organization’s goals and assigns
permissions accordingly. A shortcoming of this approach is ensuring that the roles
possess all of the necessary permissions. Failure to provide the necessary
permissions will result in excessive calls to the help-desk. Another shortcoming is
that of suitable granularity. An example of granularity is when a user needs access
to only one field of a database record, but gets permissions to all of the record’s
fields. This error may not result in help-desk calls, but it does violate the principle of
least privilege. [8]
50
Hybrid Approach
In the hybrid approach, roles are initially developed using the bottom-up
approach and then fine-tuned with top-down approached information [8].
While top-down goals declare requirements, the bottom-up scenario approach
(described in the next section) provides concrete procedural statements. Together,
these approaches are complementary, since goals can be used to identify scenarios
and scenarios can be used to identify goals [8].
Scenario-driven Role Engineering
The scenario-driven role engineering (SDRE) process is a bottom-up
approach that uses scenarios to describe the steps involved in performing scenarios
[41]. The role-engineer assigns access permissions to steps as needed. Appropriate
scenarios are grouped together into tasks and various tasks form work profiles,
which are akin to RBAC roles. Hence, a bottom-up approach.
Scenario-driven role-engineering was first presented in 2002 by Gustaf
Neumann and Mark Strembeck and is described in the remainder of this section
[40].
Scenarios provide a communicative vehicle between role-engineers and
non-technical stakeholders. This helps to ensure a better design and also addresses
the social aspect of role-engineering.
Terminology
The highest level SDRE grouping is the work profile, which is roughly the
same as an RBAC role. There are two differences. The first is that roles may be
arranged hierarchically through inheritance relations, whereas work profiles are all at
51
the same level. The second difference is that permissions are assigned directly to
RBAC roles, whereas they are derived for work profiles through their mapping to
tasks and scenario steps. With these two distinctions in mind, work profiles may
generally be thought of as roles.
The next level down is the task, which is a collection of steps (actions)
necessary to perform a job function. Example tasks for a worker at a sandwich
restaurant include: apportion food items, prepare sandwich to customer’s directions,
operate the till, clean eating area, and clean kitchen. The manager may have all of
those tasks except cleaning, plus additional ones such as receiving, bake buns, and
reconcile till receipts.
Composition of Work Profiles
The relationships between work profiles, tasks, scenarios, and steps are
many to many (Figure 10). For example the work profiles for the two sandwich shop
workers overlap in some tasks and differ in others. Likewise cutting tomatoes and
cutting cucumbers are really the same action, which require permission to possess a
knife at work; a step that is assigned to preparing both tomatoes and cucumbers.
Figure 10. Composition of Work Profiles
The Scenario Model
A scenario is drawn as a sequence of steps between the user and the
system. Figure 11 shows a simple example of a bank customer making a withdrawal
from an automated teller machine (ATM). This example is similar to the one
52
originally presented and faithfully reproduced as cited, except that in those drawings,
they forgot to give the customer the money [40] [8].
Figure 11. Simple ATM Scenario
Steps in a Scenario-Driven Process
There are seven steps in this process, the first four of which are iterated to
produce a complete scenario model. The process does not define when the model is
complete, so that is at the discretion of the role-engineer. The last three steps group
the scenarios into tasks and work profiles, which are then used to derive a
role-hierarchy and define the RBAC model. The steps are listed below.
1. Identify and model usage scenarios: Initially characterize each scenario
with a simple sentence, such as: copy a file from the common directory,
write a file to the assignment directory, or start an application. Then create
the scenario sequence of steps.
53
2. Derive permissions from scenarios: Identify and record each of the
necessary permissions as <operation, object> pairs. For example, <read,
common directory file> and <write, file to student desktop folder>.
3. Identify constraints: In the college system we need to ensure that students
cannot change other students’ assignment submissions or alter the
common directory documents.
4. Refine scenarios: Scenarios may be generalized. For example, scenarios
such as ‘run Word application’ and ‘run Excel application’ could probably
be combined into a single ‘run application’ scenario.
Iterate steps 1 to 4 until a satisfactory set of scenario model is produced.
5. Define tasks and work profiles: Combine scenarios to form tasks, taking
into account any identified constraints. For example, a programming exam
may require reading start files from the Xcommon directory, modifying and
testing them with a programming application, and then saving the file to
the Xassignment directory.
The tasks are grouped to form work profiles. For example, a student Exam
Role may include a programming task, an FTP task, and a documentation
task.
6. Derive preliminary role-hierarchy: Analyze the work profiles for
overlapping tasks and create hierarchically related roles. For example, all
students should be able to view their on-line marks, so this would be part
of a basic role that other student roles would inherit.
54
7. Define RBAC model: Here the role-hierarchy and its permissions and
constraints is catalogued along with other proposed or existing
role-hierarchies. The model is reviewed for redundancies and overlaps
and adjusted accordingly.
Appendix A presents a very simple set of scenarios to illustrate the process
for scenario-driven role engineering. Its purpose is illustrative only and should by no
means be considered complete.
55
CHAPTER V
CONCLUSIONS AND RECOMMENDATIONS
Two questions asked in the introduction were: (i) “Can RBAC be easily
applied to Active Directory?” and (ii) “Can Active Directory’s inheritance of privileges
be managed in such a way that limits to access may be easily and temporally
applied?” The answer to both is no. The bottom line is that Active Directory’s DAC
security is inherently not role-based, nor does it purport to be role-based.
Regarding the second question, Active Directory does not provide a
mechanism to assign rights and permissions for a limited length of time, so temporal
application is not available. Actually, the RBAC model itself has no temporal
requirement, so this is not an Active Directory shortcoming as far as RBAC is
concerned.
Considering the first question, a true RBAC system should permit users to
have more than one role, and the RBAC mechanism would adjust the authorizations
based on the user’s current role. When the user logs on, he is presented with a role
options screen and simply chooses the desired role. Now that is easy! If the student
does not select the exam-role, then he will not be able to access the exam
instructions nor submit the answers.
If, in Active Directory, a simple assignment of a class’ user group to a
restricted group would have provided the necessary limits to rights and permissions,
then this could have been considered easy. However, Active Directory’s design does
not permit applying software restrictions and folder permissions to the same
56
container. Thus users must be moved between two containers, and it turns out that
this requires a three-step process to modify each user’s role; a procedure which is
likely intimidating to most typical college-faculty and is most certainly error prone.
However, all is not lost, since as has been demonstrated, Active Directory
does have the ability to manage user rights and permissions. Given that, and Active
Directory’s ability to run scripts, the process of moving users between roles could be
automated. Also, Active Directory’s continuum of administrative delegation permits
the creation of role administrators with just enough authority to run these scripts.
Ideally the role administrator would enter a source class section and a target
restricted role into a script to move all of the users. The script should also create a
return script which is deposited in the role administrator’s directory. The return script
is necessary to ensure that the correct class is restored in case more than one class
section is moved to the restricted role at any one time.
As far as creating the aforementioned class sections in Active Directory,
Lethbridge College already possesses much of the framework to provide this. Each
and every term, a course is created in WebCT for every class section in the
Registrar’s database. Extending this tool to Active Directory may be quite feasible.
Of course it also needs to be reversible.
Another possible scenario has the role administrator enter into the script, a
text file containing the source student id numbers. The script would search Active
Directory for these students and move them to the target directory, while recording
their source containers for the return script. This approach would eliminate the need
to create containers for every course section in Active Directory.
57
This last scenario may be the best way to start, and I recommend that next
summer the Lethbridge College IT department uses a student STEP position to hire
a temporary programmer to create such scripts. This approach can then be tested in
the Learning Commons during the fall term of 2009. The Learning Commons
proctors would be given role administrator status and receive training in the use of
the scripts. Prior to the scripting, an interested group of faculty should meet to
develop a standard set of exam-roles, such as: web-based testing with no
application access (e.g., for SimNet testing); no Internet access, programming
applications only; limited Internet and FTP access, web-design application
programming. The design of these exam-roles and the scripts to manage them
within Active Directory may provide me with interesting future research work.
(Note: Limiting Internet access is easily and freely possible by using a site
specific browser (SSB) such as Mango [42]. The exam-role would provide
shortcut(s) to start the SSB with the allowed website(s).)
The reader may still have questions such as, “What is the current state of
research on computer-exam security?” and “Are there other solutions available?”
In my opinion, the answer to the first question is, “Little to none.” The abstract
of a 2006 IEEE paper started with this interesting statement, “Secure electronic
exams are one of the most difficult challenges in e-learning security. [43]” and then
in the introduction says, “Focusing on electronic exam management, to our best
knowledge, the only published work on this topic is due to Chadwick. [43]” It
continues to say that Chadwick only addresses the security of transferring the exam
materials by using public-key encryption techniques.
58
Regarding the second question, there are other solutions available. Sun
Microsystems offers RBAC for its Solaris OS; but, a vendor-neutral RBAC solution
that integrates with Active Directory is available from Identity Engines [44]. Also as
mentioned in the Introduction, there are software products that sit on top of the
operating system such as NetOp and SynchronEyes. A recent product that may be
worth investigating is Securexam by Software Secure [45], which received a patent
in January of 2007 [46] for all the same apparent features that NetOp and
SynchronEyes have. The providers of these software solutions require one to
request a price quote, which brings to mind the adage, “If you have to ask, then you
can’t afford it.” With that in mind, an in-house solution is well worth investigating.
The purpose of this research was to study the role-based access control
(RBAC) model as a tool for managing restrictions of student access during
computerized examinations, and to see if this model was applicable to Microsoft
Active Directory, which is the security product used at Lethbridge College. An RBAC
system would provide an ideal approach, but unfortunately, Active Directory is not
RBAC compliant. However, Active Directory does possess enough security features
that Lethbridge College may be able to use scripting to simulate pseudo-RBAC
roles. This is an approach that is recommended for further exploration.
59
REFERENCES
[1] J. Underwood and A. Szabo, “Academic offences and e-learning: individual propensities in cheating.,” British Journal of Educational Technology, vol. 34, 2003, pp. 467-477; http://0-search.ebscohost.com.aupac.lib.athabascau.ca/login.aspx?direct=true&AuthType=url,ip,uid&db=ehh&AN=10451326&site=ehost-live.
[2] J. Sheard, A. Carbone, and M. Dick, “Determination of factors which impact on IT students' propensity to cheat,” Proceedings of the fifth Australasian conference on Computing education - Volume 20, Adelaide, Australia: Australian Computer Society, Inc., 2003, pp. 119-126; http://portal.acm.org/citation.cfm?id=858403.858418.
[3] J. Underwood, “Digital Technologies and Dishonesty in Examinations and Tests,” Dec. 2006; http://www.cedma-europe.org/newsletter%20articles/misc/Digital%20Technologies%20and%20Dishonesty%20in%20Examinations%20and%20Tests%20(Dec%2006).pdf.
[4] C.F. Rogers, “Faculty perceptions about e-cheating during online testing,” Journal of Computing Sciences in Colleges, vol. 22, 2006, pp. 206-212; http://portal.acm.org/citation.cfm?id=1181901.1181936.
[5] G.A. Rosile, “Cheating: Making It a Teachable Moment,” Journal of Management Education, vol. 31, Oct. 2007, pp. 582-613; http://jme.sagepub.com/cgi/content/abstract/31/5/582.
[6] M. Hricko and S.L. Howell, Online Assessment and Measurement Foundations and Challenges, Igi Global, 2005.
[7] E.M. Anderman and T.B. Murdock, Psychology of Academic Cheating, Elsevier Academic Press, 2006.
60
[8] D. Ferraiolo, R. Kuhn, and R. Chandramouli, Role-Based Access Control, Boston: Artech House, 2007.
[9] “INCITS, InterNational Committee for Information Technology Standards - What is INCITS?”; http://www.incits.org/geninfo.htm.
[10] DoD, “Trusted Computer System Evaluation Criteria (TCSEC),” 1983; http://nsi.org/Library/Compsec/orangebo.txt.
[11] R. Sandhu, D. Ferraiolo, and R. Kuhn, “The NIST model for role-based access control: towards a unified standard,” Symposium on Access Control Models and Technologies: Proceedings of the fifth ACM workshop on Role-based access control, vol. 26, 2000, pp. 47-63.
[12] D. Ferraiolo and R. Kuhn, “AN INTRODUCTION TO ROLE-BASED ACCESS CONTROL,” NIST/ITL Bulletin, Dec. 1995; http://csrc.nist.gov/groups/SNS/rbac/documents/design_implementation/Intro_role_based_access.htm.
[13] “A Role-Based Access Control (RBAC) system for PHP”; http://www.tonymarston.net/php-mysql/role-based-access-control.html.
[14] R. Sandhu et al., “Role-based access control models,” Computer, vol. 29, 1996, pp. 38-47.
[15] D. Ferraiolo, J. Cugini, and D.R. Kuhn, “Role-Based Access Control (RBAC): Features and Motivations,” Proceedings of 11th Annual Computer Security Application Conference, 1995, pp. 11–15.
61
[16] J. Gilbert, “Practical Role Management: Real-World Approaches to a Complex Problem - SC Magazine US,” SC Magazine, Mar. 2008; http://www.scmagazineus.com/Practical-Role-Management-Real-World-Approaches-to-a-Complex-Problem/article/108305/.
[17] D. Ferraiolo, R. Kuhn, and R. Sandhu, “RBAC Standard Rationale: Comments on "A Critique of the ANSI Standard on Role-Based Access Control",” Security & Privacy, IEEE, vol. 5, 2007, pp. 51-53.
[18] Microsoft, “Windows Authorization Manager”; http://msdn.microsoft.com/en-us/library/bb897401.aspx.
[19] S. Kouti and M. Seitsonen, Inside Active Directory, Toronto: Addison-Wesley, 2005.
[20] C. Simmons, “Active Directory Concepts,” Windows IT Pro, Apr. 2000; http://www.windowsitlibrary.com/Content/596/1.html.
[21] Microsoft TechNet, “How Permissions Work,” Mar. 2003; http://technet2.microsoft.com/windowsserver/en/library/d043701a-5a2e-4001-b659-0c23c90f76f61033.mspx?mfr=true.
[22] J. Boyce, “Understanding Active Directory, part 1,” TechRepublic, Sep. 2000; http://articles.techrepublic.com.com/5100-10878_11-1060540.html?tag=rbxccnbtr1.
[23] Dan DiNicolo, Hands-On Microsoft Windows Server 2003 Administration, Thomson CourseTechnology, 2003.
[24] “Active Directory Tutorial,” Search WinIT, Jul. 2007; http://searchwinit.techtarget.com/generic/0,295582,sid1_gci1050336,00.html.
62
[25] J. Boyce, “Understanding Active Directory, part 2,” TechRepublic, Oct. 2000; http://articles.techrepublic.com.com/5100-10878_11-1060541.html?tag=rbxccnbtr1.
[26] R. Charrington, “How DNS and Active Directory work together,” TechRepublic Tutorial, Nov. 2000; http://articles.techrepublic.com.com/5100-10878_11-1047741.html.
[27] R. Gupta, Microsoft Windows 2000 Security, Thomson CourseTechnology, 2002.
[28] “Digging Deeper into UAC”; http://www.dushu.de/englishbook/sybex.administering.windows.vista.security/final/bbl0021.html.
[29] “How to Use Software Restriction Policies in Windows Server 2003”; http://support.microsoft.com/kb/324036.
[30] “Windows XP Security Guide,” Apr. 2006; http://www.microsoft.com/technet/security/prodtech/windowsxp/secwinxp/xpsgch06.mspx.
[31] Microsoft Developer Network, “Windows Authorization Manager,” Windows Authorization Manager; http://msdn.microsoft.com/en-us/library/bb897401.aspx.
[32] D. McPherson, “Role-Based Access Control for Multi-tier Applications Using Authorization Manager,” Jul. 2004; http://technet2.microsoft.com/WindowsServer/en/library/72b55950-86cc-4c7f-8fbf-3063276cd0b61033.mspx?mfr=true.
63
[33] Microsoft Download Center, “Download details: Windows 2000 Authorization Manager Runtime”; http://www.microsoft.com/downloads/details.aspx?FamilyID=7edde11f-bcea-4773-a292-84525f23baf7&displaylang=en.
[34] Tim Huckaby, “Role-Based Access with Authorization Manager,” Oct. 2003; http://windowsitpro.com/article/articleid/40496/role-based-access-with-authorization-manager.html.
[35] K. Brown, Dymystified Series: Getting Started with AzMan, 2007; http://channel9.msdn.com/posts/donovanf/Demystified-Series-Getting-Started-with-AzMan/.
[36] E.J. Coyne, “Role engineering,” Proceedings of the first ACM Workshop on Role-based access control, Gaithersburg, Maryland, United States: ACM, 1996, p. 4; http://portal.acm.org/citation.cfm?id=270152.270159.
[37] Qingfeng He, “A Goal-Driven Role Engineering Process for Privacy-Aware RBAC Systems,” 11th IEEE International Requirements Engineering Conference, 2003.
[38] A. van Lamsweerde, “Goal-oriented requirements engineering: a guided tour,” Requirements Engineering, 2001. Proceedings. Fifth IEEE International Symposium on, 2001, pp. 249-262.
[39] Q. He, A Structured Role Engineering Process for Privacy-Aware RBAC Systems, Department of Computer Science: North Carolina State University, 2003.
[40] G. Neumann and M. Strembeck, “A scenario-driven role engineering process for functional RBAC roles,” Proceedings of the seventh ACM symposium on Access control models and technologies, Monterey, California, USA: ACM, 2002, pp. 33-42; http://portal.acm.org/citation.cfm?id=507717.
64
[41] D. Shin et al., “On modeling system-centric information for role engineering,” Proceedings of the eighth ACM symposium on Access control models and technologies, Como, Italy: ACM, 2003, pp. 169-178; http://portal.acm.org/citation.cfm?id=775412.775434.
[42] “SSB - Wikipedia”; http://en.wikipedia.org/wiki/Site_Specific_Browser.
[43] J. Castella-Roca, J. Herrera-Joancomarti, and A. Dorca-Josa, “A secure e-exam management system,” Availability, Reliability and Security, 2006. ARES 2006. The First International Conference on, 2006, p. 8 pp.
[44] idEngines, “Ignition RBAC”; http://www.idengines.com/products/.
[45] SoftwareSecure, “Securexam”; http://www.softwaresecure.com/.
[46] Douglas Winneg and Raymond Hayland, “Securely executing an application on ... - Google Patents”; http://www.google.ca/patents?hl=en&lr=&vid=USPAT7165269&id=Pbp-AAAAEBAJ&oi=fnd&dq=secure+computer+exam.
65
APPENDIX A
The purpose of this appendix is to illustrate the scenario-based role
engineering process to define roles that can be used to specify the creation of
computer-based-exam security-container-pairs (i.e., pseudo-roles) in Active
Directory at Lethbridge College. It is illustrative only and by no means exhaustive or
prescriptive of the final product. A thorough role definition should involve all
interested stake-holders and will require thorough testing. However, scenarios
provide a simple means of communication between IT professionals and non-
technical stakeholders, which merits these examples. This appendix creates two
roles; one for the role-administrator and one for a programming-exam student.
In the role engineering process, any permission not explicitly allowed is
implicitly denied.
Since the IT department at Lethbridge College has already established an
effective security system using Active Directory, the regular roles do not need
definitions at this time. Effectively this will be a hybrid system with just a few newly
defined roles.
In the case of the role-administrator, we only need to add permissions, not
take any away. This can be accomplished by simply inheriting all of the rights and
permissions that are already available to the computer lab proctors and add some of
these users to another group which has rights to a role-administrator’s folder where
the necessary scripts reside.
66
Due to Active Directory’s design, and the fact that computer-exam-student
groups require restrictions to resources that are otherwise available, the rights and
permissions of these roles must be fully defined (and thoroughly tested), since
inheritance is not a viable option.
Role Administrator Scenario: Move Students into a Restricted Role
Step 1: Sentence description and picture
A role-administrator has all the rights and privileges of a regular computer lab
proctor, plus the ability to run scripts in the Role Administrator Folder.
Step 2: Derive permissions and write as <operation, object> pairs
• Access Role Admin Folder: <allow list contents, Role Admin Folder>
• Run the exam script: <allow execute, script file>
Show folder contents
Dbl click the exam script
Run the exam script
Execute script
Role Administrator Role Admin Folder
Verify permissions
Enter student file
Enter target role
Verify permissions
Move students
Provide return script
Access folder
67
Step 3: Identify constraints
The proctor should not be able to modify the script files:
<deny modify, script file>
The proctor should not be able to delete the script files:
<deny delete, script file>
Role Administrator Scenario: Return Students to Regular Roles
Step 1: Sentence description and picture
A role-administrator has all the rights and privileges of a regular computer lab
proctor, plus the ability to run scripts in the Role Administrator Folder.
Step 2: Derive permissions and write as <operation, object> pairs
• Access Role Admin Folder: <allow list contents, Role Admin Folder>
• Run the return script: <allow execute, script file>
Show folder contents
Dbl click return script
Role Administrator Role Admin Folder
Verify permissions
Identify the return file
Verify permissions
Move students back
Delete return script
Access folder
68
Step 3: Identify constraints
The role administrator should not be able to modify the script files:
<deny modify, script file>
The role administrator should not be able to delete the script files:
<deny delete, script file>
Step 4: Refine scenarios
Obviously the two operations could be combined into a single scenario, but
leaving them as separate descriptions tells a fuller story of what is supposed to
happen.
Step 5: Define Tasks and Work Profiles
In this simple case, the tasks are the scenarios. The work profile is the
combination of the two previous tasks, plus all of the other computer lab proctor
tasks already defined at Lethbridge College.
69
Computer Student Scenario: Access the Xcommon Directory
Step 1: Sentence description and picture
Allow student to copy file from the Xcommon folder to the desktop. Any folder
permissions not defined in these student scenarios are implicitly denied.
Step 2: Derive permissions and write as <operation, object> pairs
• Access Xcommon folder: <allow list contents, Xcommon folder>
• Copy file to desktop: <allow read, file>; <allow write, Desktop folder>
Step 3: Identify constraints
The student should not be able to write to the Xcommon directory:
<deny write, Xcommon directory>
The student should not be able to delete the files from the Xcommon
directory: <deny delete, file>
The student should not be able to modify files in the Xcommon directory:
<deny modify, file>
Show folder contents
Click/drag file to desktop
Permit operation
Student Xcommon Folder
Verify permissions
Identify instructions
Verify permissions
Access folder
70
Computer Student Scenario: Access the Xassignment Directory
Step 1: Sentence description and picture
Allow student to write a file from the desktop to the Xassignment folder. Any
folder permissions not defined in these student scenarios are implicitly denied.
Step 2: Derive permissions and write as <operation, object> pairs
• Access Xassignment folder: <allow list contents, Xassignment folder>
• Copy file from desktop: <allow read, desktop file>;
<allow write, Xassignment folder>
Step 3: Identify constraints
The student should not be able to copy files from the Xassignment directory:
<deny read, Xassignment directory>
The student should not be able to delete the files from the Xassignment
directory: <deny delete, file>
The student should not be able to modify files in the Xassignment directory:
<deny modify, file>
Show folder contents
Click & drag file to folder
Permit operation
Student Xassignment Folder
Verify permissions
Locate desktop file
Verify permissions
Access folder
71
Computer Student Scenario: Run the Borland Builder IDE
Step 1: Sentence description and picture
Allow student to edit a source file and create and run an executable from it.
Any application permissions not defined in these student scenarios are implicitly
denied.
Step 2: Derive permissions and write as <operation, object> pairs
• Run Borland Builder IDE: <allow execute, Borland Builder>
• Read and write desktop source file: <allow read and write, Desktop folder>
Step 3: Identify constraints
The student should not be able to run any other application. In Active
Directory, this is controlled by group policy.
Step 4: Refine scenarios
These three scenarios are unique and cannot be combined.
Run the application
Student Borland Builder IDE
Verify permissions
Edit/compile/execute
execute
Run Borland Builder IDE
Save file to desktop
72
Step 5: Define Tasks and Work Profiles
As before, these simple tasks are the scenarios. The work profile is the
combination of the three student tasks shown and no more. The student exam roles
are so restrictive that the regular student rights and permissions are not inherited.
Step 6: Define preliminary role hierarchy
The role administrator is part of a hierarchy, where the regular proctor role is
its junior from which it inherits its regular permissions. The exam student role is not
part of a hierarchy in this example, but it may be possible to layer application
permissions in organization units.
Step 7: Define RBAC model: This is not deemed relevant to this example.