ATHABASCA UNIVERSITY USING ROLE-BASED …dtpr.lib.athabascau.ca/action/download.php?filename=scis-07/open/... · athabasca university using role-based access control with active directory

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



vii


Step 4: Refine scenarios ..................................................................................68

Step 5: Define Tasks and Work Profiles...........................................................68

Computer Student Scenario: Access the Xcommon Directory .............................69




Computer Student Scenario: Access the Xassignment Directory.........................70




Computer Student Scenario: Run the Borland Builder IDE ..................................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.

47

Figure 8. Assignment Directory Permissions

Figure 9. Xcommon Directory Permissions

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


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.


• Access Role Admin Folder: <allow list contents, Role Admin Folder>

• Run the return script: <allow execute, script file>


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


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


Allow student to copy file from the Xcommon folder to the desktop. Any folder

permissions not defined in these student scenarios are implicitly denied.


• Access Xcommon folder: <allow list contents, Xcommon folder>

• Copy file to desktop: <allow read, file>; <allow write, Desktop folder>


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>


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


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.


• Access Xassignment folder: <allow list contents, Xassignment folder>

• Copy file from desktop: <allow read, desktop file>;

<allow write, Xassignment folder>


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>


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


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.


• Run Borland Builder IDE: <allow execute, Borland Builder>

• Read and write desktop source file: <allow read and write, Desktop folder>


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.

ATHABASCA UNIVERSITY USING ROLE-BASED …dtpr.lib.athabascau.ca/action/download.php?filename=scis-07/open/... · athabasca university using role-based access control with active directory

Documents