UAMS, A Study in System Administration Automation

---- UAMS, A STUDY IN SYSTEM ADMINISTRATION AUTOMATION By ROLAND JOSEPH STOLFA Bachelor of Science Oklahoma State University Stillwater, Oklahoma 1986 Submitted to the Faculty of the Graduate College of the Oklahoma State University in partial fulfillment of the requirements for the Degree of MASTER OF SCIE CE May, 1997 UAMS, A STUDY IN SYSTEM ADMINISTRATION AUTOMATION Thesis Approved: Thesis Adviser Dean of the Graduate College ii ACKNOWLEDGMENTS I sincerely thank my graduate advisor Dr. George Hedrick for the kindness, guidance, help and time he has given me during the years it has taken me to write this thesis. Without the encouragement and help he has given me, the completion of this work would have been impossible. I also sincerely thank Dr. Blayne Mayfield, Dr. Mitch Neilsen, and Dr. John Chandler for serving on my committee. My special thanks goes to Mr. Mark J. Vasoll for the encouragement and inspiration he has shown me during the course of developing the code associated with this thesis. Special thanks also go to Mr. Russ Smith (Mathematics Department), Mr. Rod McAbee and Mr. Clay Couger (College of Engineering) Architecture and Technology) Mr. Brad Barnes (College of Veterinary Medicine), and Mr. James Alexander (Computing and Information Services) for their support. My respectful thanks goes to my wife Mrs. Dr. Lisa Y. Tresp, D.V.M and our daughter Ms. Victoria F. Stolfa and our son Mr. Kevin M. Stolfa for all the love, encouragement and support they have given me in writing this thesis. iii TABLE OF CONT ENTS Chapter Pag 1. INTRODUCTIO /HISTORY 1 1.1 Background . . .. . 1 1.2 Problem Statement . 2 1.3 Organization . . . . 3 2. LITERATURE REVIEW 4 2.1 Asmodius 4 2.2 ACMAINT 4 2.3 GAUD . 5 2.4 newu .. 5 2.5 Uniqname 5 2.6 SH ARE II . 6 2.7 simon . . . 6 2.8 GeNUAdmin 6 8 3. UAMS TODAY . . . 3.1 3.2 The Database . 8 3.1.1 The Database Descript ion . 3.1.2 Global Fields 10 3.1.3 Local Fields . 11 3.1.4 DB Views l.l 8 12 URJ's 3.2.1 12 Automatic Rights lV 3.2.2 Granted Rights . 12 3.2.3 Expiring Rights . 13 3.2.4 Anti Rights 13 Rights Alias File 14 3.3.1 Slave side 14 3.3.2 Master side 15 3.4 Shell Strings. . . . 15 3.5 Universal Computing Identifiers. 15 3.5.1 Background . . . . . 15 3.5.2 Creation Heuristics . 16 3.5.3 Special Case Users 17 Security Issues . . . . . . 17 3.3 3.6 3.7 3.8 3.6.1 URI's & Access Control 18 3.6.2 Configuration Spoofing 18 Initial Password Creation 19 3.7.1 Background . . . . 19 3.7.2 Creation Heuristics . 19 Runtime Configuration . . . 20 3.8.1 3.9 The UAMS Master/Slave Configuration File 20 21 Server/Client Model 21 3.10 Clients . . . . 3.10.1 U IX 21 3.10.2 POP . 23 3.10.3 Card Key Lock System 23 3.10.4 Novell . . . . . . . . 23 3.11 Master/Slave Server Model 24 3.12 Master to Slave Messages 25 v 3.12.1 Batch Load . . . . 25 3.13 Slave to Master Mes ages 27 3.13.1 User Query . 27 3.13.2 User Remove 28 3.13.3 Voting and Expiration of Records. 2 3.14 Summary . . . . . . . . . . . . . .. .. . 4. CENTRALIZED FLAT NAM ESPACE SYSTEM 29 31 4.1 What is it? 31 4.2 Benefits .. 31 4.2.1 Provided to the Individual Users 31 4.2.2 Provided to the System Administrator 32 4.2.3 Provided to the University. 33 Costs . . . . . . . . . . . . . . . . . 33 4.3.1 Preliminary Costs and Tasks 34 4.3.2 Continuing 35 4.3 4.4 36 Summary . . . . . 37 5. BLACK BOX DESCRIPT ION OF A CFNS 5.1 5.2 Minimal Data Struct ures Needed 37 5.1.1 People Database . . . 37 5.1.2 Association Database 37 5. 1.3 Cross Reference Database 38 Supported Client/Server Functions 39 5.2.1 Make Return Set 39 5.2.2 Query By . 39 5.2.3 Return Set 40 5.2.4 Vote For Set 40 vi 5 .2.5 Merge Ids . . . . . . 40 5.2.6 Create A New User. 41 5.3 How it all Fits Together 42 5.4 Other Issues . . . . . . . 42 5.5 5.4.1 Data Base Inconsistencies 42 5.4.2 Purging the Data Base of Old Records. 43 Summary . . . . . . . . . . . . . . . . . . . . . 43 6. PROPOSED F UT URE WORK AND CONCLUSIONS 6.1 6.2 Future Work 44 44 . .. 6.l.1 UAMS-lite 44 6.1.2 Real Time Access to t he Master UAMS Site. 44 Conclusions...... . . . . . . . . . . . . . . . . . 45 BIBLIOG RAPHY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. APPENDIX A: 46 48 GLOSSARY VIl LIST OF TABLES Table Pag 3.1 Logical Record . 8 3.2 Physical Records 9 3.3 Global Fields of the Database 10 3.4 Departmental Fields of the Database . 10 3.5 Example UCI Generations . 17 5.1 People Database . . . 37 5.2 Association Database . 38 5.3 Association Database, Example 1 38 5.4 Association Database, Example 2 . 38 5.5 Cross Reference Databa..<;e 39 5.6 Return Data Set Fields 40 5.7 Merge RP e P arameters 41 viii LIST OF FIGURES Figure Page 3.1 Sample datafeed for UNIX client system 22 3.2 Master /Slave and Server/ Client Relationships . 24 3.3 User Query Event Sketch . . . . . 3.4 ~ . 26 Master Side Processing of User Query 27 3.5 Sample Slave to Master VOTE Data Feed 28 IX CHAPT ER 1 INTRODUCTION/HISTORY 1.1 Background Prior to the development of The User Data Base System, UDB, at Oklahoma State University the two support staff members at Oklahoma State University Computer Science Department had to mainta in over 40 machines manually. This included all the normal system administration of hardware, backups, mail, and news, as well as account creation. T hey often found t hemselves in search of a machine on which a user wanted an account, logging-on, creating the account, t hen finding the user and informing them of t he initial password. In many instances, several days might pass between the request and the creation of the account due, in part , to playing "telephone t ag." Another scenario would involve the creation of enough accounts for an entire class. This typically implied that there were no initial passwords for those st udents. As time passed, access to the t wo terminal labs that the department runs for graduate students also became a chore. This involved keeping track of many keys to t he labs in question. Mon itoring the labs, and the equipment contained therein, became enough of a worry t hat a set of magn tic st rip readers and a card key access system was installed on six doors in the department to monitor t he use of the rooms. With the advent of etwork File System (NFS) hosts/ servers, file shari ng amongst one user's account on several machines became a problem due to NFS needing the IIumeric user identifiers to be the same on all systems. This involved merging many separate password files, sort ing out what id's were in use on what, machine, and then changing the numeric user id's on all machi nes across the network. In short, there was no real solution to t he user account creation, deletion, and management problems for a university. This situation lead to the original development of T he User Data Base System, UDB, in 1987. Furt her refinements lead to the presentation on UDB at the Large Installation Systems Administration Conference in 1990 (available as OSU-CS-TR-90-04) (SV90bj. 1 2 After the first paper on UDB, several other coli ges and departmen ithin OSU decided to participate in the types of services UDB was providing. How ver, to e."(tend UDB to that domain would have required all departments that wanted to participate share one datab on one ho t. The OSU Computer Science Department found itself in need of a system of providing datab ervic to a majority of the campus. A system was needed that could maintain a campus wide flat name space, for both logins, or Universal Computing Identifiers (UCI) as we call them, and numeric u r id's (NUrD), allowing separate administrative entities a.ccess to only those pieces of information that directly relate to their organization. The result of this was the User Account Management System (UAMS) [Sto93]. As it stands today, UAMS (the term that describes the current merger of UDB and UAMS) is a centralized database of user id's, supporting several departments and colleges within the university in a distributed manner. 1.2 Problem Statement HistoricaJIy, the Computing and Information Services group on campus had not issu d personalized user id's (or P UDs) to students . However, in 1992, CIS reversed th mselves on this topic. In the ensuing three years, the number of PUDs handed out by CIS has exploded . In 1995, a new fe , the Student Technology Fee, was established as a tax on the students to supply services for the students as directed by the students. One of the side effects of this is that the students wanted to have email accounts for all students starting in the fall of 1995. The CIS department now provides P UDs to all incoming freshmen, in part to meet their obligation to the Student Technology Fee Committee. In order to do this, CIS intends to support a Centralized Flat Name Space (CFNS) system for the entire campus. Using this system, all users would have exactly one user login name across all platforms on campus. However, UAMS has UCls for virtually all OSU users (approximately 15000 at this time) . In addition, the UAMS system has many of the features that CIS finds desirable for their support of computing on campus. As a result , CIS has offered to merge their PUD database with the UCI 3 database maintained by UAMS in the Computer Science (COMSC) department if COMSC d velops the code to support this merger on the UAMS side and if COMSC will a.dvise CIS in the developm nt of their part of the code to support t his merger. The resulting CFNS will be acces ible by all of the current UAMS supported departments , and will allow CIS to expand the CFNS concept to the ent ire university. The problem, and the fo cus of this thesis, is the result of the joint effort between t he COMSC Department and CIS here at Oklahoma State University to implement a centralized fi a t name space system for the entire campus, based on UDB and UAMS, and further to deal with the merging of the two elatabases of information (PUDs -vs- UCIs). One of this thesis' goals is to describe how such a modified UAMS system would work, whom it would benefit, and how much work it would require to achieve the goal of a centralized flat name space system. 1.3 Organization The thesis is divided into the following chapters: • Chapter 2: A discussion on previous work related to user account generation and maintenance software. • Chapter 3: Internals of U AMS today, given as an example of a working distributed flat name space system. • Chapter 4: Centralized Flat Name Space Systems Described. • Chapter 5: Black box description of a CFNS. • Chapter 6: Conclusions and Proposed Fut ure Work. • Appendix A: Glossary. CHAPTER 2 LITERATURE REVIEW National refereed publications in this area started in about 1988, as that is when the Large Installation System Administration Conferences of the USENIX Association began. Several other account maintenance systems have been reviewed. Some of their high points are summarized below. 2.1 Asmodius In Asmodius [EVS88], a distributed database system and reliable datagram socket connection protocol is described to perform some of the same fun ctions as UDB. Further, the implementors of Asmodius chose to rewrite and replace several of the standard operating system utilities, such as passwd. These modified utilities then communicate to a centralized daemon which would in t urn modify the central database and communicate the changes t o other daemons running on those systems under Asmodius' control. These daemons then modify their local copy of the database and actually change associated operating system specific files, such a..'l /etc/passwd. However, Asmodius utilizes daemon programs running on hoth t he server and the clients that rely on TCP lIP networking facilities. Although these faciliti s are gain ing popularity h r at Oklahoma State University, not all hosts at OS U have T CP lIP, hence this approach was not usable. 2.2 ACMAINT In ACMAI T [CKCS90], a celltral database was presented to allow a single system administrator to manage computer account creation across a heterogeneous set of computers. ACMAINT, like Asmodius, was designed around modifying several of the operating system utilities (passwd, chin, and chsh to name a few) to communicate with a centralized database. This database then transmits the "change" information to a daemon running on each network attached host under ACMAINTs control to perform the change. In ACMAINT, the "change" daemons do not keep track of the entire database, nor do they keep a view of the database appropriate to their system. Instead, these daemons are strictly in charge of 4 5 processing change requests. This is the major difference between A modiu and ACMAINT. However, ACMAINT utilizes daemon programs running on both th erv rand th client that rely on TCP lIP networking facilities. Again, as t hese facilities are not univer ally pr ent in the OSU environment, ACMAINT was inappropriate for use here at OSU. 2.3 GAUD In GAUD [Urb90], a central database is accessed by many hosts over Remote Procedure Call (RP C) protocol to allow access by the various offices t hat might allow or deny access to a particular user to a particular machine. FUrthermore, GAUD has as design goal the maintenance of extra data to assist in various financial accounting procedures. In addition, GAUD maintains a list of wh re a users home directories reside on a distributed NFS file server farm. However, GAUD suffers from th e reliance on the availability of source code to the operating system, an item not all universities have. Furthermore, at OSU, RPC is not available on all hosts, hence its unsuitability. 2.4 newu In newu [SV90a], describes a fun ctionality t hat is already in UDB; ie. t h ability to cr ate and d ) te accounts on a foreign host. In addi tion, newu manages disk quota issues for t he users it administers. However, newu suffers from the same problem UDB had, in that it only worked within one administrative entity. FUrt her, newu was developed to deal with t he workload associated with adding one user to many machines. It does not provide any mechanism for dealing with groups of adds and deletes, such as seen in a university environment around the change of semester enrollmen t flux. 2.5 Uniqname In Uniqname [DLM90j, a system of merging existing accounts wi th a 'global view' is presented . T his is the result of severa) different computer systems, and incumbent user populat ions, existing prior to the development of Uniqname. Uniqname also attempts to address a few divergent issues, such f 6 as X.500 email addresses, Kerberos authentication, and AFS ecurit ystems. As UDB started wit h a unified 'global view', Uniqname offered a solution to something that was not a problem in our case. In addition, it presents a solution to several problem that UDB did not even attempt to address such as t hat of preferred mail box address . 2.6 SHARE II In SHARE II [BGMR94]' an overall object oriented resource control system for areas such as CP utilization, memory use limits, and disk quotas is presented. It controls many asp cts of system administration that through source code modifications to both the kernel and several oper ating system utilities. In addition to these areas, SHARE II also deals with user account management. As not all sites here at OSU have the source to the operating system, this is not a viable alternative. 2.7 simon Simon [Fin92] presents a system similar to UDB that relies on a commercial database system . Simon receives data from the registrar, from payroll processing, and has spe ial case "guests" m nually entered. It then produces a resu lting view of who should be on a system. In addition , this system manages some aspects of a charge back ystem. As these t hings are undesirable here at OSU, this system was not a viable alternative to UDB. 2.8 GeNUAdmin In GeNUAdmin [Har94]' Harlander describes an automatic system administration tool used to control various operating system parameters, tuning variables, user default variables, file system mounting options, and user accounts across a network of heterogeneous computer platforms. One of the design goals of GeN Admin is to allow ease of administration by performing various consistency checks to bot h t he operating system configuration and the user population. Since it involves many more aspects of system administration than UDB, much of GeNUAdmin can be ignored. The user administration aspects of this paper describes replacement code for several , 7 system utilit ies, such as 'passwd'. Since this is something t hat UDB was explicit ly designed to avoid , this system was not a viable alternative to UDB. CHAPTER 3 UAMS TODAY This chapter describes the internal organization and the operating principals behind UAMS as it exists today. This chapter is included so the reader will have a better understa.nding of bot h the history and the fun ctionality that is being sought. 3.1 3.1.1 The Database The Database Description Conceptually, the database is a relational database with a single relation, consisting of the fi elds shown in Table 3.1. These fields have evolved through the development of UAMS and the uses to which it was put. Due to the operational use of these fields however, the logical record is divided into six physical records (Table 3.2). These six physical records are then stored in a hashed database. Originally this was done using Ken Thompson's DBM (as supplied wit h UNIXl). However, as the size of the database grew, it exceeded DBM ' capabilities. At that time, the Gnu Project's GDBM was chosen to replace DBM . For each of the physical records (shown in Table 3.2), a DBM key=value pair is generated. T ypically the first charact er of the physical record name is prep ended to th e NUID to form the key. The value I UNIX is a trade mark of X/Open. osuid issue fulIname uci nuid passwd epasswd major auto granted comment lupdate Student/Faculty identification number (unique) Student/Faculty ID card issue number Full name of the individual, as defined by the uni versity Universal Computing Identifier (unique) Preferred Numeric User ID for NFS (unique) Clear text password DES encrypted password text Student department affiliation Automatic enrollment rights Manually granted rights Comment field Last update time of this record Table 3.1: Logical Record 8 9 General Record Student/Faculty identification number Student/Faculty ID card issue number Full name of the individual , as defined by the university Universal Computing Identifier Preferred Numeric User 10 for NFS (DBM key) Clear text password DES encrypted password text Student department affiliation Last update time of this record osu.id issue fulln ame llci nuid passwd epasswd major lupdate Automatic Record Preferred Numeric User 10 for NFS (DBM key) Automatic enrollment rights nuid auto l nuid granted I Preferred Numeric User ID for NFS nuid comment I Preferred Numeric User ID for NFS I Comment fi eld osujd nuid OSU ld Map Record I Student/Faculty identification number (DBM key) I Preferred Numeric User ID for NFS uci nuid I Universal Computing Identifier (DBM key) I Preferred Numeric User ID for NFS I Manual Record (DBM key ) I Manually granted rights Comment Record (DBM key) UCI Map Record Table 3.2: Physical Records 10 osuJd issue fullname uci nuid major auto Student/Faculty identification number (Unique) Student/Faculty ID card issue number FUll name of the indi vidual, as defined by the university Universal Comput ing Ident ifier (Unique) Preferred Numeric User ID for NFS (Unique) Student department affiliation Automatic enrollment rights Table 3.3: Global Fields of the Database passwd epasswd granted comment lupdate Clear text password DES encrypted password text Manually granted rights Comment fi eld Last update time of this record Table 3.4: Departmental Fields of the Database is typically the plain text contents of the field; in t he General record case, the valu.e points to a structure that contains the listed fields. In the operation of this relational database, an UCI to OSU _ID record exists for each user, as does a General Record. Each user who has any enrollment data has a corresponding Automatic Recore!. A Manual Record exists for each user who has sp cial rights on the server. The COMMENT record exists for the system administrators to keep a textual tag to be associated with the llser . 3.1.2 Global Fields The data analysis concluded that all slave UAMS sites across campus must share some part of the the global database of logical records maintained on the master site. The slave UAMS sites would treat this data as read-only, allowing the master UAMS site to overwrite these fields when needed. The global fields are treated as read-only on the master UAMS site aft er the initial creation of he users record. This is because the entire list of uc rs and NUIDs a re kept unique on the ma..'lter DAMS site. Once generated uniquely on t he master site, these global data fields can be transmitted to any of t he slave UAMS sites while still guaranteeing the data integrity; ie. no duplicate NUIDs (Table 3.3). I vcrs or f 11 3.1.3 Local Fields The local data fields are unique to each administrative UAMS ite. They are not transmitt d either from the slave to the master site or vice versa. This allows each UAMS site to have control over the special case users without infringing on any other 3.1.4 AMS site (Table 3.4). DB Views As of the development of UAMS, the database was further modified to be distribut ed between a master and several slave UAMS servers. The mast er server maintains the uniqueness of UCI's and NUID's, receives the data feed from the central university database, and handles request s for new users from slave servers . Slave UA MS servers contain a view of the master UAMS database, appropriate for the department that is running the slave server. Slave servers are also where a departmental UAMS administrator configures the different clients. This arrangement allows different UAMS administrators to configure their respective views of the database to affect their department in a manor that is consistent with that department 's wishes. It also allows for different, sometimes conflicting URIs, or niversal Rights Identifiers as we call them, to be used within different slave UAMS servers without interfering with the other departments. One consequence of this splitting of each logical record into a global and local part is that each administration is able to set t he default init ial password, while maintaining the same UCI. This helps maintain some level of security among UAMS hosts. Using this arrangement disables one user, knowing their UCI on one UAMS administ ered host, from loggi ng in ad-hoc to other UAMS administered hosts based purely on the knowledge of the original password. It also implies that an individual user's account information on one system has minimal use on another, as the init ial password is different between UAMS administrations. Each administrative UAMS site also has a separate and unique GRANTED right field for each user in t heir system . This allows each site to specify unique (and possibly conflicting) URIs to give access to djfferent clients (hosts, etc.). On the master UAMS site, the GRA NTED right field is also 12 used to select those special case users such as "root" 2, who need to visit a slave UAMS site in addition to those users destined to go to t he slave site because of enrollment inform tion. However, since the GRANTED right field on t he master DAMS site does not go with the record to the slave site, the slave UAMS site never sees that URI. Another result of this data analysis is that each department is allowed their own comment field (COMMENT) for each user. That way, any comments on a user are held in the confidence of the commenting department. 3.2 3.2.1 URI's Automatic Rights The data held in the "auto" rights field contains information related to enrollment and employment. Contained in a separate physical record, this field is a list of all relevant courses t his user is enrolled in this semester. In addition, all employees of the university that happen to be in the UAMS system have are given a dummy enrollment record to indicate the department for which they work, and what kind of an employee (student, faculty, etc.) this user is. All data in this field expires autom atically when UAMS receives new data from the central university database. These rights take the form of a comma separated list of text strings. This fi ld of th logical record was split into a separate physical record because t he data contained in it must to be updated each time a new university database data feed is received. Having this as a separate field simplifies the update process by allowing the system to simply remove all automatic records in one pass. The program that receives t he enrollment data can simply reload the course enrollment data by regenerating all the automatic records. 3.2.2 Granted Rights The data held in the GRANTED rights field are speCial case rights given on an as needed basis. Such things allow users such as "root" to have an acco unt on all machin es without concern that their accounts could be deleted automaticall y at some point in the fu ture . In addition, there are 2 On most NIX sys tems, there is a special account used for system administration tasks. It is typically called "root" and is a privileged account. 13 always special case users who need an account (or access to a room via the card key ace s y t m) for a specified period of time but they would not otherwise be granted that right. This field of the logical record was split into a separate physical record becau e it was found that there were very few of these compared t o the number of total users in the database (10: 1 on average) . 3.2.3 Expiring Rights Any GRANTED right may have an expiration date of the form "-YYYYMMDD" appended to it. Upon a periodic 3 scan of the database, all GRANTED rights that have reached their expiration date are removed from that user's record. 3.2.4 Anti Rights As in a lmost any other university setting, students will be students. As UAMS was a pplied to an ever larger body of students, it was inevitable that a student would need to be prohibited from using a machine due to an infraction of the rules. Shortly befor e this became necessary the author developed the anti-right. With this GRANTED right, a user could be excluded from a machine, regardless of other rights. For example, the user "foo" is to be prohibited from using machine "A" . However, "fo o" is granted access to t hat machine due either to a class enrollment right (in an Auto fi eld in this us r's record ), or to their Major (if they are a guest on th at machine, indicated by a URI in this user's GRA NTED field of, say, "A", t he GRA TED right "A" is simply removed) . If t his was done, the next time UAMS received this user's enrollment data from the central university database, t he Auto field enrollment right would return. At this time, the Major code would be restored also. As these are not solutions, the anti-right was developed. In the case of "foo" , a GRANTED anti-right would be given as "!A". In fact, in order to lock "foo" out for a specified period of time, an expiration date could be added, giving an expiring anti-right of "!A-YYYYMMDD " . These anti-rights do nothing abnormal to the record of th e user. Instead, they alter the list of users selected to go to a site, "A" in this case, to exclude t his user. If this same user has other 3 This process is typically activated once a day, but may also be initiated on demand. 14 GRANTED rights, for in tance t his user has an account on the same d partment's POP serv r, their POP server rights are unaffected. 3.3 Rights A lias File The Rights Alias File, or RAF, is t he central control mechanism within UAMS. The definitions within it control which records are selected to go to which other clients. It also defines which URls may be given to a user manually in the GRANTED right field of their record. As may be guessed, looking at the manual page on RAF that comes with UAMS [St096], all blank lines and lines that begin with "#" are comments. All other lines are broken into t hree colon ":" delineated fi elds. The first field is an alias for all lines referenced with t he same alias. The second field is t he list of explicit URIs are to be used as a selection criteria for this alias. The third field is an optional command field associated wit h this alias. In short, the rights for a particular alias indicate all records that are t o be extracted and passed thru the optional command to generate the information necessary for the client that the ali as represents . It is possible to maintain a list of users with a particular URI without actually using the list in any alias line. This is done by leaving the first and t hird field blank and listing all th URls of interest in in the second field. 3.3.1 Slave side On a Slave server, the RAF is typically concerned with mapping which URIs into which client sid e programs. Each installed Slave server comes with several client side programs. Among the more useful ones are "genJolls," [Sto96] a program that prints out a class roll sheet for an instructor to use when determining the login name and password for each student in a class. Another useful program is "gen_unix," [Sto96] which prepares a data feed to a (possibly remote) site for the creation of user accounts on that site. 15 3.3.2 Master side On a Master server, the RAF is generally a spartan affair t hat simply map which classes of users go to which slave site. A program called "gen-'1Sd" [St096] does this job. When it is fin ished , a data feed is shipped to a given slave site that contains the "global" part of the master site 's database for most of the records that the given slave site has . 3.4 Shell Strings The Bourne shell and awk playa big part in UAMS. However , taking advantage of the DB M database requires a clean method of getting the dat a from the OBM to the shell and vice versa. The Bourne shell has environment variables of the form "name=value". It also has a met hod of evaluating a string of "name=value" pairs where each pair is separat ed by a semi-colon (i .e . "eval" ). Hence, the UAMS program "udbget" [Sto96] extracts t he data from the DBM into a string of "name=value" pairs with each of the requested fields semi-colon separated. Further, the AMS program "udbput" [St096J parses the same type of string and inserts the updated data back into t he DB M. 3.5 3.5.1 Universal Computing Identifiers Background A major part of the emphasis of the original UAMS was devoted to the generation of "meaningful" user id's. Previously, all user accounts were generat ed in the form of "prefi x_count" where each user shared a "prefix" wit h a ll classmates and had a unique "count". For example, a file st ructures class with three st1ldents would have three user log on account names generated as "fs1," "fs2," and "fs3." This complicates the administrative job by hiding the person behind a "f81" account (as the faculty member assigned the accounts to the students) . In addition, some users had multiple accounts. This was the result of one student enrolled in several different classes, each with a different computer account for the programming assignments for that class on the same machine. 16 3.5.2 Creation Heuristics More meaningful user names were desired . A few experiments wit h the enrollment data led to the following extensible heuristic <1. 1. First, all illegal characters are removed from the full name. These include such things as hyphenation and punctuation. Then t he name is converted to lower case. 2. If a person 's last name is greater than seven (7) characters and their first name is greater t han three (3) characters and less than or equal to seven (7) characters, t hen their fi rst name is designated as "word!" and their last name is designated as "word2" . Otherwise, their last name is designated as "wordI" and t heir first name is designated as "word2." 3. Following is the list of checks for uniqueness. When one of these datb.~e probes determines that the UCI is not found in the database, then t hat VCI is assigned to this user. The first one to be chosen ends the algorithm. (a) Up to the fi rst seven characters of "wordl." (b) The fi rst character of "word!" followed by up to the first six characters of "word 2. " (c) Up to the first six characters of "wordl," followed by the first character of "word2." (d) The first five characters of "wordl," the first character of "word2" and the fi rst character of t his user's middl e name. (e) The first seven characters of "word2." (f) The user 's initials; i.e. first character of fi rst , middle, and last names concatenated. (g) The first initial, their middle initial, and up to the first 5 characters of their last name. (h) Up to the first six characters of "word2" followed by the fi rst character of "word!." (i) Up to the first five characters of their first name followed by their middle initial and t hen their last initial. 17 Name Bogus Jay Serendipity Bogus Serendipity J ay 3A 3E bogus serindi jay bogus 3B 3F bserend bjs jbogus bsj 3C 3G boguss bjseren jayb bsjay 3D 3H bogus j serendb jaybs bogusj 31 bogusjs bogussj Table 3.5: Example UCI Generations Table 3.5 shows sf'veral of the possibilities for a pair of fi ctitious users. 3.5.3 Special Case Users To handle the special case users such as "root" required several special considerations. Fir t, these users did not have OS U-.lDs, any enrollment data, and quite seldom a FULLNAME. To cover these cases, as well as the case of the occasional guest account (or odd software package) that did not have an OSU-.lD, a simple heuristic was formed: taking the proposed VCI (say "root" ) and using a "+" prepended to the VCI as the OS U-.lD. Thus "root" would have the OSU.lD of "+root ". This simplifies some areas of system administration. For instance, all of the users with a plus in their OS V -.lD field have no OS U st udent or staff id . Therefore they need not be selected for loading into the card key lo ck software5 . Also, they a re typically what we call "mechanical acco unts," ie. they come with a n operating system and do not have a physical person behind them. So when scan ning t he password fil e for accou nts to set no-login, t he system administrators can llse UAMS as an aid in t his process 3.6 6. Security I ssues As in any large dat abase project of this sort, security issues that are in direct contradiction to the general purpose of the project arise; namely providing the user data. In U AMS, there a re several types of security imposed on the access to the data to make t he dat a fairly secure . .tit is extensible, but has served our needs for the last two years. ·5 As described in [SV90b], the Computer Science Department runs a card key lock system on several labs within the department . 6 This is not an enforced func tion of UAMS, merely an example of llsing t he da.ta UAMS maintains. 18 UAMS assumes that each user on the system belongs to a group of their own . Each user id number and their group id numb er are identical (for any user) , and t hese numbers are unique amongst all others on the system. The following security discussion REQUIR ES that this be o. 3.6.1 URI's & Access Control When all of the programs, shell scripts, and configuration files of a new master, slave, or client UAMS code set are installed, it is assumed that these fil es are "chown(l)"ed to a part icular u er. In the case of the UArvIS master and slave code, this user is assumed to be "udb." T he installatioll script provides all t he "correct" file permissions for every file installed. Once all t he files are owned by the assigned user, the progra ms and data are secure from t ampering. Access is granted to the data contained in the database via URI's given the user in question. If t he default UDBPRIVis selected (during configuration), a user must possess the "udb_priv" URI before being given access to the data. This privilege is typically, and most securely, a GRANTED right, outside of the conventional name space of all ot her URIs on the system thus avoiding accidentally giving a user a URI that will allow them access to the database. Once a user has attempted to run a C program component of UAMS, a library module written in C, aUow.c [St096] to be precise, is used to determine if that user has been granted the correct. URI. If the user is allowed, access is granted . If the user is not allowed, the attempt to gain access is logged and the user is refused access to t he database . . one of the shell scripts within UAMS access the database directly. They all rely on C progra ms to perform the access on their behalf. Thus, using "allow.e" in the C programs secures all the data contained in the database. 3.6.2 Configuration Spoofing As discussed in Section 3.8, the configuration can be changed by defining one simple environment mf'~hanis variable. This does not, however, change the URI needed to gain access to the database. This is configured into SRCROOT/h/udb.h during t he configure/ compilation stage in order to prevent this kind of security attack. 19 3.7 3.7.1 Initial Password Creation Background In the past, accounts were typically generated without passwords or a single initial pas word for the whole class. This posed several problems. Sometimes a malicious user wouLd log onto as many of the accounts as possible and set a password on that account. T his prevented t he rightful user from logging in. Another case t hat has occurred is where a new graduate student has been given an account for the class he or she is teaching. These accounts were also generated without passwords. However, some of these new students didn't know that a password should be set, thus allowing anyone t o log into t heir account where such things as grades , student id to student name mappings , etc. may be found. 3.7.2 Creation Heuristics At account creation time, UAMS generates a random password and associates it to the new account. The generation of the password proceeds as follows: 1. A random number is generated and divided modulo the number of words in the word list. This word is retrieved and is called "wordl." 2. A random number is generated and divided modulo the numb r of separator characters. T his character is retrieved and is called "word2" 3. Another word from the word list is chosen, as in "I" above, and is called "word3." 4. The password is generated by concatenating "wordl," "word2," and "word3." Several examples of t he result of this algorithm would be: sue lcat bob$dog imp!yack This word is then passed to the DES encryption algorithm that comes wit h UNIX to generate the encrypted password, and this is also associated with the account. On export versions of Unix, this will not work, due to the non-DES algorithm being installed in the system libraries. 20 Both the plain text version of the password and the encrypted ver ion are say d in t he database. Only t he plain text version is t ruly needed; however, the regeneration of t he encrypted version is a very time consuming process (using the DES algorithm). It is for t his reason t hat we g nerate the encrypted version only once and then save it for all fut ure uses. Users are encouraged to change their password as soon as possible, so that it no longer matches the UAMS database. Their current actual password is not ~ to r e d , only an initial value for the creation of a new account is stored. 3.8 Runtime Configuration This section covers the run-time configuration process once a production environment is set up. 3.8.1 The DAMS Master/Slave Configuration File The file udb.cfg [Sto96] cont ains t he central configuration file in either a master or slave UAMS site. It is a plain text file and contains comments that outline what the variables contained in it are for , as well as configuration comments that allow the program "subst" 7 to provide reasonable defaults for all variables. In shell scripts During the running of any of t.he shell scripts within the UAMS package, "udb. cfg" is read fi rst . This is the whole purpose in editing in the path to UDBRO 0 Tjconfig/udb . fg during the con figure/compilation stage for all the shell scripts. This is also where the "PATH" environm ent variable is set. As soon as any shell script is started, the assignment of "PATH" in t his file overrid es a ny previous value that eit her the user or any external wrapper script may have set . In each script, there is a variable "UDB_N AME" that is set to the name of the shell script that is running, BEFORE "udb.cfg" is included into the running shell script . This allows for user defined triggers to be placed within "udb.cfg" to do special t hings. One such thing, of great use during debugging phases of the system, is to "set -x" (based on the UDB_ AME of the module to deb ug) . 7 The shell script program "subst" is a part of the USENET news reading package "C-News" . 21 In C programs Within the UAMS package, in cfgstr.c [Sto96], there is a library C function that parses most of the data from UDBROOT/config/udb.cfg and makes it available for use within the C fun ctions. Any procedure may access the variables defined and set in " udb.cfg" in much the same way that shell scripts do. In each program, after the user has been validated as authorized to run the program in question , "udb.cfg" is read in and parsed to give the program the same definitions. The UDBCFG environment variable. In the previous two sections, UDBROOT/config/udb.cfg has been treated as a fixed path. In fact, it is not. The environment variable UDBCFG may override the definition of UDBROOT/config/udb.cfg at any time. UDBCFG must point to a file that contains all the same variables as the defa ult one (in UDBROOT/config/udb.cfg), with possibly different right hand sides, to make the system rUIl. Both shell scripts and C programs used in UAMS obey this convention. 3.9 Server/Client Model A server/client relationship exists between any UAMS site and a system that is administered by the owner of the UAMS server . III this system, any server, either a master UAMS or a slave UAMS, may provide a data feed to a client system. T he format of the data delivered to the client is client. specific, and typically is lIsed to generate some end product specific to tha t client . 3.10 Clients Since there are several UAMS clients, this section concentrates on the largest example, the UNIX client. The other clients available as UAMS clients will also be hriefl y discussed. 3.10.1 UNIX This collection of shell scripts reads a data feed from a UAMS master or slave site (Figure 3.1) and generates the correct password file , group file, and login directories for each new user described , -. I ... 22 uci:epasswd:fullname:granted:major:auto:nuid Figure 3.1: Sample datafeed for U IX client system in the data feed. It also deletes from the password and group files all users no longer in the data feed. Furthermore, all URIs are propagated to all client UNIX systems from their administering UAMS server to allow the generation of the URI database for each host . This allows each departmental machine to make use of all of the enrollment data, the major code, and all of that departmental UAMS server's unique URIs for its own purposes . One of the uses of the URIs that has been implemented at OSU is the ability to run various programs (similar to access control lists). Another is the automated maintenance of mailing lists. In addition, the UNIX client can provide the following services: • Validate that certain users remain in the data feed. Without these special users, the data feed will not be installed. • Validate that the data feed is for this site. • Generate a URI database of which users have what rights on this system . • Generate from the URI database , AT&T System V "cron.allow" - "eron.deny" type security fil es, from any given URI on the system. • Generate an additional/etc/group line based on any given URI. • Generate mailing lists based on: - Any right that any user on the system has, generates a mailing list. - Any user that has a right outlined in a list , generates a mailing list. 23 Interface to the Multi-channel Memorandum Distribution Facility (MMDFII) [III84] mail transport system mailing list configuration mechanism. 3.10.2 POP The Post Office Protocol (POP) client came about because there was an interest within several departments to provide mail to personal computers. The POP system, as distributed with the RAND Corp. :vIH mailer, was chosen by some of them to fill this need. This system had to be configured for users , just as the UN IX hosts did. As POP uses a password file that is ill many ways similar to the UNIX password file, this client required several minor changes to one of the existing 'lients, allowing it to run with minimal system administration. 3.10.3 Card Key Lock System Although not a system that anyone can log into, the Computer Science Department uses a n IdentaCard brand card key access system to log access to the department's various labs and facilities. It is included here to show that seriously non-standard systems can be supported in a clean and efficient manner. 3.10.4 Novell The Novell s version 3.11 client came about because of one of the other department al UA MS administrators. Within the other department, a Novell network was used t o link together several persona l computers within a student lab. However, all of these computers had to be configured for users, with much the same information, just as the UNIX hosts that UAMS already served. As t.hi s is just another type of host , using unique login names and passwords. Consequently, a new cl ient was written to provide the information. After researching the Novell manuals and considering the options, the Novell client was written to generate a data file for the Novell user administration program "MAKEUSER." The UNIX shell script "gen ..novell" [St096] would keep a list of the users currently authorized for a , ovell site, compa re that with what UAMS was giving it , a nd generate add and delete commands as necessary. 8 Novell is a registered trademark of Novell Inc. 24 Dotting implies separate adm inistration r------ Master Server - - 1 r - - - - - - - - I I ____ ____ J Figure 3.2: Master/Slave and Server/Client Relationships This preserved the feel of the UNIX client , without having to write a program for a personal computer. 3.11 Master/Slave Server Model In order to facilitate the sharing of data, a simple master/slave model was chosen (Figure 3.2). This represents t he administrative association of the "glob al fi elds" of the UAMS databases among one another. Hence there must be a mast er UAMS site. This is the site that receives the enrollment data from the registrar. It is also the only UAMS site that can definitively assign UCls and UIDs. Whenever any slave UA MS site needs a ucr and NUrD for a user new to it, then it must defer to the master UAMS site for t.he definitive information. The master UAMS site also maintains the master copy of the enrollment data for all users of all slave UAMS sites. T his data is given to the mast er site after the participating UAMS departments authorize the master UAMS site to have this data. The master/slave model allows the master UAMS site to selec t all of the records for a slave UAMS easily. This typically is based on enrollment data held in the Auto and Major records (for students). Additionally, to select all non-standard records (for such things as "root" , "uucp" , faculty, etc.), a specialized GRANTED right , unique to that slave UAMS departmental administration, is used. -- 25 To provide each participating department autonomy over their users , only the "global fields" are shared among the different UAMS sites. This implies that any URI given to a user on th master system as a GRANTED right is not propagated to any other UAMS slave site. This includes the specialized GRANTED right , as the GRA TED field is not in the "global fields" list of data being shared. This also allows each departmental UAMS to have overlapping (and possibly duplicated) GRANTED right URIs. Further, it allows each departmental UAMS to use the COM MENT field as they determine, without having to conform to some standardization scheme. 3.12 3.12.1 Master to Slave Messages Batch Load Once per day, the master site checks its database to determine whether it has been modified. If it has been modified, then the master site prepares a data feed for all of its slave sites. This is on the design assumption that a ll slave sites would be interested in any changes to the databas . The data feed to the slave sites is timed to trigger a cascade of the data to t.he clients of that part.icular slave server site. The processing of "new" data feed is performed before the slave sites processin g for dat.a feeds from that slave site for its client sites (Figure 3.3). The actual data feed is composed of the "global fields" of the database (Section 3.1.2). These are encapsulated with data to aid in tb validation of the data in the data feed and elec tronically mailed from the master to each slave server site. Which records are sent is based on the selection criteria set out for the slave in the mas ter site's RAF (Section 3.3), This data feed is augmented by a password and an encrypted password at the slave site. In addition, t he last updated time is set for this record. Through the record's history on this slave site, the last update field is updated every time the record is modified by either a "batch load" data feed or by the slave site administration modifying the data. -26 uCI=Joe osu_id= 111223333 nuid=-l fullname="Joey Smith" o Master=A ~ START:CEA T_ASD:udbqry CEAT_ASD:l 1 1223333: Joey Smith:joey,js END: udbjoe I granted=OFF_CEAT - mc -E~ uci=joeys osu_id=111223333 nuid=1234 fullname="Joe Y Smith" o uci=joeys osu_id= 111223333 fullname="Joe Y Smith" nuid=1234 Time ~ I granted=CEAT_ASD Igranted=OFF_CEAT cronjob gen_asd CEAT_ ASD ~ cronjob START:CEAT_ASD:maiijob udbput 111223333:Joe Y Smith: 1234:joeys ... gen_unix OFF_CEAT END START:OFF_CEAT:mkaccts o DBM record vi w joeys: ... :Joe Y Smith: 1234:0FF_CEAT .6. END: Email message between hosts Figure 3.3: User Query Event Sketch o 27 if (osujd is 'OT in the master ite' DBM) if (some requestedjd field is non-blank) if (reque tedjd_l is NOT inuse) assign requestedjd_l to osujd; else if (requestedjd _2 is OT inuse) assign requestedjd_2 to osujd; else if (requestedjd_3 is OT inuse) assign requestedjd_3 to os uJd; fi fi if (uei field is still blank) create uci for osujd using fullname; fi create nuid for OSlLid from unused list; fi tag record for return to client for three weeks update lupdate to today's date Figure 3.4: Master Side Processing of User Query 3.13 3.13.1 Slave to Master Messages User Query Th e user qu ery mes age is generated on a slave site when the administration of the slave site attempts to create a user 's recoro for which there is no pre-existing data on that particlliar slave site. As shown in Figure 3.3, t his message is generated, transmi tted, and processed in real time when the slave site's administrator first reques ts the creation of new user da ta. The record contains the OSU.lD, F ULL. A ME, and (optionally) the requested Ucrs for this user. On the master site, the process outlined in Figure 3.4 is triggered by the receipt of the record and is used to fulfill the request. At the end of this procedure, the (possibly) new record is given expiring GRA TED right on the master site that will select this record to go back to the requesting slave site via the rules in the master site's RAF file. This GRANTED right is typically set to expire in t hree weeks. This allows the slave site up to three weeks to receive notification of the creation of this new record. At the end of this period , the GRA TED right that for cibly shipped this record to the slave site is expired from the GRANTED field of the master site's record (see Section 3.2.3). 28 llci:osujd:nuid Figure 3.5: Sample Slave to Master VOTE Data Feed The mechanism whereby the slav · site keeps this record active on the master site is covered in Section 3.13.3. 3.13.2 User Remove When a slave site finall y needs to remove a user record from its site, it generates a "user remove" record . This typically is due to the slave site running a program that determines that t he record in question does not have any propagation to any of tha t slave's clients, and furth er, has not had any activity for a period of one year (see the manual page for "udbpurge(l)" [St096]). On the mas ter site, this record triggers a check of this user's record to make sure no GRANTED right record on the master site continues to propagate this record to the slave site. As in the case of the "user query" record, this record is generated, t ransmitted, and processed in real time. This record's usefulness has been great ly augmented by the "vote" record, descr ihed in Section 3.13.3. 3.13.3 Voting and Expiration of Records Once a month, all slave sites "vote" for those VCI, OSU...ID, UID tuples that they have in use. On the master site, each "vote" is checked to determine whether the VCI, OS ...ID, NUID tuple is correct. If there is any problem, th e record and its source are noted in a log fil e for hum an intervention. Otherwise, the LUPDATE fi eld for the user record associated wi th the tuple is updated to the current date. On the master site, a record continues to exist until the following conditions are met: 1. There are neither any AUTO nor GRA TED rights associated with the user. This is typically associated with the person no longer being enrolled at the university. - 29 2. The record has not been touched in a period of one year. This is indicated b a on y ar old LUPDATE field. Special case users, like "root" and "uucp" are voted for by all slave sites every month , t heir records never expire at the master site. However, if a user 's record meets the criteria above after dropping out of school, the record on the master is eliminated. This a llows t he user's UCI and NUlD to be reused for the first new person who enters the university and who has a fullnam e that matches the generation criteria outlined in Section 3.5. Each slave follows the same process. Each record is scanned to determine whether it meets the criteria outlined above. If it does, that record is removed from this slave site. As soon as the record is removed, this slave site no longer votes for that user . When all slave sites do not vote for this user, the one year clock starts. At the end of the year, the user's record is removed from the master site (as outlined above). The listed procedure implies that. once a person leaves the university, their record actually sits on the master site for a period of two years. The first year is spent awaiting the slav sites to expire the record on their local da tabase, the second from t he master site. This gives a user a period of two years in which to reenter the university and still have the same UCI and NUlD . 3.14 Summary The merger of UDB and UAMS provides to the asu environment most of t he features necessary for a CFNS. Among the most important is t he concept of one user id (UCI) and one numeric user iel ( UID) per user (a.<; ba.<;ed on the aSUjD number). Unfor t unately, one fact that prevents UAMS from filling the role of CFNS totally is that not everybody in the institution has a record in UAMS. This is because UAMS only receives records for those users whose clepartments have requested to be part of the UAMS project. Furthermore, as only those departments t hat have asked to join in the services that UAMS provides participate in the system, not all departments are served. With th e creation of CF S services at the instit ution level, t he central goal of one UCI and one - 30 NUID per OSU..lD can be achieved. The central administration of the in titution can imply assign one CI and one UID per OSU..lD for all members of the instit ution. In addition , a centrally maintained CFNS can provide CFNS services to a wide variety of platforms given a tandardiz d protocol to many departments. This then is the goal of UAMS and this thesis. - ..... CHAPTER 4 CENTRALIZED FLAT NAMESPACE SYSTEM 4.1 A Centralized Flat What is it? amespace System is a mechani m whereby al l users of an enterprise's computer systems has exactly one unique login name. In the case of most computer operating systems, thi is extended to include one unique numeric id also. These two pieces of data are linked to some part of the user's university data, such as employment records or enrollment data. Over the life time of the user's association with t he university, the unique login name and Ilumeric user id are stable, that is they do not change without good cause 1. In all database views of the university database that include t he unique login name and numeric user id, the same data is shown, to all users. Further, there exists at most one view of t he data where either of these fields will be changeable associat ed with either becoming enrolled for the first time or upon employment by the university. As has been covered in t he previolls chapter, UAMS was designed to solve many of these problems for the cooperating departments. However, viewed in the larger sense of a CFNS for t he entire university, many of the problems that UAMS solves are duplicated with good reason. 4.2 Benefit s The benefits of having a CFNS installed and operational within t he university varies depending upon the point of view. The following sections describe the benefits to t he individual users, the system administrators, and the university 4.2.1 3.'3 a whole. Provided to the Individual Users Listed below are some of the benefits users may see as a result of a CF S. 1 Some of the "good causes" include marriage, divorce, and legally having a name change. 31 32 Uniqueness When a user first enters t he CF S system, they are given a unique login. In theory, they will have this account name for their entire as ociation wit h the enterpri e. This allows such things as backups and mail to be uniquely identified with a user across t he enterprise. Since this information is keyed to user 's association with the university, even years hence, each user can be identified uniquely and the user 's files retrieved with a good level of certainty that they are being retrieved for t he correct ''"<j ....I '~ I person. ~' I '~ I '" Adultness Closely related to uniqueness (covered above), there is the benefit of adultness that is imp osed Oil users. \Vhen a user is given only one user id and is told that that id will be theirs for their entire university st ay, any and all acts perpetrated by this user will be attached t o t his id also. Hence, doing malicious acts from the given id might be viewed by the more t houghtful user as "poor." Interdepartmental data sharing In the past if a user wanted to have t he same data in two accounts, their only real opt ions were along t he lines of mailing the data between the two acco unts. Wit h a CF S in place on all of the hosts involved, it is possible to automount t he data across depar tmental boundaries wit.hin the enterprise. This is a direct result of havin g the UCI and NUID tJw same for each user on any CFNS administered host . In fact, an enterprise wide file server might be employed to provide a cent ralized repository for all user data. Individual depart ments can then concentrate their computing facilities on providing computing platforms that are appropriate to t hat department's needs and leave t he file backup and maintenance functions to a centralized service organization . 4.2.2 Provided to the System Administrator In addition to the benefits that the user sees, a system administrator at a university also sees the benefit s listed below as a result of using CFNS. po 33 Start of semester crush At the beginning of each semest er, there is a large enrollment influx of new user, mo tly students. To create all of these accounts by hand would be impossible. With a CF S in talled campus wide, adding an entire class of students to any machine across campus is as simple as adding a few lin s to a configuration file , running a new enrollment data base through the system, and installing the resulting password file . This entire process can take as little as 30 minut es . Mail lists In t he past, different instructors have tried to keep track of which students are in their class for purposes of a class mail list. CFNS automates this procedure and makes sure th at the list is correct, up to the last enrollment data feed . 4.2.3 Provided to the University In tll(' larger pict ure, a CFNS provides the following for all UNIX clients administered from one site : • One login name and nl1meric user id for a user for their entire association with the enterprise. • One account per user per machine, even if m ore thaI! one class is taught on t hat machine. Therefore, there is no a mbiguity in which class acco unt maps to which user (t here is only one account). • Abilit y to authenticate backups for many years to come. Ie. ownership of t he backups for t he user "bob" can be identified as belonging to the person with OSU id number "111223333". • No 'inactive users' on mailing lists as these are updated each t ime the password fil e is modified. 4.3 Costs The development of UAMS, both on a site basis and later on t he wider university basis , addressed many of the problems outlined in this thesis satisfactorily. However, these solutions did come at a cost, and as with any CFNS implementa tion "after the fact," some of these costs a re quite large. 34 4.3.1 Preliminary Costs and Tasks The establishment of a campus wide centralized flat name space system implie an incredible amount of work t o arrange at this late date in the development of OS U's campus computing environment. One major tasks is the associating of an OSU id number with each and every user 's account. Special numbers must be assigned to the mechanical accounts, such as "root" and "uucp," so that t hey can participate in much the same way as normal users. Once all of the UCI 's on all systems have an OS U id number associated with them, each user's account must be compared against all others across campus. This determines whether u er has any ·'11 ." ot.her accounts a cross campus (as determined by the uniqueness of the OSU id number), as well as whether there is anyone else with the same UCI across campus (as determined by the required uniqueness of the UCI's). Those users who have the same UCI all across campus i>hould have no change. Those users who have multiple login names that are not unique must be dealt with individually. Since some users must have their login names changed to meet the new criteria, there can be some negative emotional response. Some users may even t ake offense at th is entire process . A few sp eculative situations may arise as a result. 1. The user "bob" on one system whose name is changed to sometbing ete, say "bsmith ," must unsubscribe to all mailing lists before the switch, then resubscrilw wit.h t.he new login name to avoid loosing his mail. Analogously, if someone else bas a login changed to "hob," the ma il may get misdirected. 2. Professor "smith" comes back from vacation and is now "j srnith " . After several failed attempts to login, the professor comes to the system administrator to ask what happened. After hearing the explanation, the professor is displeased with the change. In fact, professor smith has been putting email address on the net , in research papers, etc., as a source for some data/program/etc. that [sJhe is providing t o the net community. Now the linkage between 35 "smith" and professor smith (as jsmith") must be reestablished. Also, the person who receiv s "smith" as a user id is inundated with requests for which there is no reasonable r span e. 3. Some user, "tom," knows the change is about to happen. Wanting to be offensive to t h person who will be inheriting the "tom" account , this user posts something extremely offensive/stupid to USENET. After the change, the new person, possibly an upper level administrator , receive ' "tom" as a user id. Due to the propagation delays thru USENET. the new owner of "tom" now receives the replies to t he postings made by the original "tom," for which t here is no reasonable response. It must be stressed that the better informed the user population is about both why these changes are happening and how t hey can benefit , the less reluctant it will be. Hence, the defusing action to be taken well before events get out of hand is to inform the user population of the benefi ts of t.his change. 4.3.2 Continuing One of t he continuing problems that UAMS must deal wi th on the OSU campus is t hat of OS JD changing. A bit of background is in order: In t he early 1980's , OS U started giving it's students photo iel's with a printed OSUJD number. These numbers typically looked like 000123456, and were created with t he idea t ha t one day they would be replaced by Social Security numbers. In fact , in 1986 or so, OSU made that switch and all students had to pay the bill of approximately $10 for a new OS U photo id. Unfortunatel),', this was mandated by t he finan cial aid department , which said, in so ma ny words, "to get financial aid on this campus, you must have your OSU.lD match your Social Securi ty Numb er." For most of the natively born Am ericans, t his was not a problem. However , for the international student body, t his was a bit more involved. The solut ion for OS U is to give an international student a photo id wit h one of the old style 000123456 OSUJD numbers, since the administration had to be able to track the student, when th ey first arri ved on campus. Then later , after the student had applied for a Social Security number, .t. 36 change the st udent 's OS .JD number to the Social Security number. Fr.·om that time forward, all enrollment data contains the new number. The affect this had on UAMS was suddenly, the user wit h OSUJD number 000123456 was no longer enrolled in anything. Hence that user 's account , say "bob" , was closed. At the same time a new user with OS UJD number 111223333 was enrolled in some new classes. As the user name "bob" was already in use, a new one "bsmith" was created, along wit h a new UID, password. etc. The user would then come in and ask, "why doesn't my account work anymore?" . After a bit of investigation, the two records for this person would have to be tracked down and merged, along with the data in their, now , two separate directories. The user would be reinformed as to what the "bob" account's password was, then the merge would be fin alized. Typically the next day, the user "bsmith" would be removed from the system and the user "bob" would be reattached to the fil es that used to belong to that user, completing the process. Upon the installation of a CFNS, this "problem" should go away. With a centralized authority in charge of keeping track of the UCI and NUID when a user's OS UJD changes, no UCI and 110 NU ID change should occur since no "new" record is being created. However, until the legacy accounts are merged into the CFNS, t his merger process takes on a larger scope. ow, instead of one user 's account on one system in one department, t he capabili ty exists for one user 's account merger to affect literally dozens of individual accounts spanning the entire university. 4.4 Summary This chapter has covered some of the costs and benefits associated with the change in paradigm to a Centralized Flat Namespace System. Although most of the costs can have wide ranging consequences , they are for the most part one time costs. This fact makes these costs more bearable. ~l .. CHAPTER 5 BLACK BOX DESCRIPTION OF A CFNS This chapter defines what a Centralized Flat Name Space system that would interface with UAMS would look like. Many of the terms used in t his chapter have the same meaning as in the previously sections about U AMS. 5.1 Minimal Data Structures Needed The CFNS needs a subset of the database field s that UAMS uses. Due t o the operation al usage of the CFNS (as outlined below) , these structures are best split among several constituent databases . These databases would be joined (on t he OSU J:D field) to form the appropriate fields for the given request. These databases are described below. 5.1.1 People Database This database would be comprised of fields, each operationally described in Table 3.3, and presented in Table 5.1. The People Database would be joined to the others descried in this section to form the overall view of t he da tabase. It would be maintained by that part of t.h e registra.rs system that deals with name changes among students . These tend to occur as a result of marriages and divorces , but other causes do a rise. This relation could also he used to maintain other data, such as preferred email addresses . 5.1.2 Association Database The layout of this database is presented in Table 5.2. The Asso ciation Database would be th e primary location for selection criteria in the creati on of views of the CFNS database. The main mechanism for this is the use of the subf ield code would indicate what kind of data subf i e ld osujd issue fullname Student /Faculty identification numb er (KEY) Student/Faculty ID card issue number Full name of the individual, as defined by the university Table 5.1: People Database 37 38 osujd subfield code subfield data St udent/Facul ty identification number (KEY) A type for t he data field below The content of type listed in the subfield code a bove Table 5.2: Association Database osujd subfield code sub field data Student/Faculty identification number (K EY) MA JOR A numeric major code Ta ble 5.3: Association Database, Example 1 data would contain. This allows a simple selection criteria to elimin ate larg numbers of the records cont ained in this database. In Tables 5.3, 5.4 show two examples of how records in t his database could look. In the fi rst case, the record is identified as a major code record where the actual major code is cont ained ill the subfield data would be, in this case , a four digit number. In t he second case, t he record is identified as an enrollment. record where the actual class number (depar tment prefix, course number, section, and type) would be contained in the subfield data. This relat ion would be joined to the ot hers to form t.lte overall view of t he database. Th is database would be linked into that pa rt of the registrars system that deals wit h enrollment an d college affiliation, among others. 5.1.3 Cross Reference Database The final CFNS database would be the cross reference database. T his would be used t o form j oins across the databases of the CFNS. It would be described as stated below , each fi eld as described ill Table 3.3. This relation would be joined to the others to form the overa ll view of the database. This osujd subfield code sub field data St udent/Faculty identificat ion number (KEY ) ENROLLMENT , Spring of 1996 A class t hat the given user is enroJled in Table 5.4: Association Dat abase, Example 2 "1 " "1 ~= ::> "4 "l 1;1 . "" 39 osujd uci nuid Student/Facul ty identification number (KEY) Universal Computing Identifier (KEY) Preferred Numeric User ID for NFS (KEY) Table 5.5: Cross Reference Database database would be linked into that part of the registrars system that deals with t he instances of a student changing an OSU student/staff id number. This relation is the key to the CFNS. It contains the crux of what the CFNS is designed to maintain. The contents of each of the individual fi elds within it is unique. Th at is for anyone 4: user recorded in this data field, their OS UJ:D, their UCI a nd their NUID would be uni que among all other entries in this database. This relation, along with the others previously mentioned in t hi section, duplicates the data content of the global record out of UAMS. 5.2 Supported Client/Server Functions For the following discussion, a database remote procedure caUs (RPC ) wiII be th e model for the interaction between the server and the clients in the CFNS system. This is in part driven by the need to secure the data t.hat exists on t he server from those who would be accessing the da t.a. The RP C procedures would have access to the data. The RPC user would have access to the RP C, bllt not to the data. Hence the RPC user is insulated from the data by t he view of the data the following RPC functions provide. 5.2.1 Make Return Set This RrC will create an empty data set that will contain t he keys into the CFNS that are selected by the Query By functions . This RPC has one argument, the Site Name that may be used by the Vote For Set command and the Return Set cornrnallcL 5.2.2 Query By This RPC will add CFNS keys to the return index data set created by Make Return Set. There are five different instances of this RPC , each having as an argument the search key as given by t he 40 osujd issue fullname major uci nuid auto Student/Faculty identification number Student/Faculty ID card issue number Full name of the individual, as defined by the university Student department affiliation Universal Computing Identifier Preferred Numeric User ID for NFS Automatic enrollment rights Table 5.6: Return Data Set Fields instance. Namely, these five return types would be OSUJD, NUID, UCI, class prefix, and MA JOR ., " " .1 " ~I code. 5.2.3 Return Set This RPC returns one record for each user who has a key specified in the return index data set , created by the Make Return Set RPC call and populated by the Query By RP C caU(s) . These records will contain the data outlined in Table 5.6. 5.2.4 Vote For Set This RP C will add a vote record for t he Sit e Name (that was specified in the Make Return Se t RPC call) for each CFNS record that has a key specified in the return index data set created by the Make Return Set call. 5.2.5 Merge Ids This RPC is used to handle the cases where a user is ent ered into the CF S database wi t.h two different OSU id numb ers. This RPC will have four arguments as show in Figure G.7. The first argument would be referr ed to as the "old" OSU id number. This is typically the original OS U id numb er that was assigned to the student prior to that student 's acquiring a Social Security numb er. The second argument would be referred to as the "new" OSU id number. This is typically t he Social Security number sty le OS U id number. For the purposes of t he merger, this will be the resulting OS U id number for this user after the merger. 41 old_osujd new_osujd ucUoJ<eep nuid_toJ<:eep Indicate the OS U student/staff id number of t he record t hat is to be considered the older of the two to merge Indicates the OS U student / staff id number of the record t hat is to be considered the newer of the two to merge This parameter indi cates whether the uci in the record indicated by old_osu...id or t he uci in the record indicated by new _osu jd should be kept in the new record This parameter indicates whet her the nuid in t he record indicated by old_osujd or the nuid in the record indicated by new_osu...id should be kept in the new record II Table 5.7: Merge RP C P arameters " 'I 'I "~ I The third argument would say that in t he resulting merger of the "old" and t he "new" OS U iel number records, either tIl(> "old" record '8 UCI or the "new" record 's UCI would be retained. The fourth argument would say that in the resulting merger of the "old" and the "new" OSU id number records, either the "old" record's NUID or the "new" record 's NUID would be reta ined. Experience with UAMS has shown that one of the most troubling aspects of keeping t he database sYllchronized with the real world is maintaining the veracity of the OSUJD numbers. This is in part due to the fact that due to certain restrictions placed upon the keeping of student records for financial records, their OSUJD !l1Jmbers a re preferred to be their Social Securi ty Numbers . However, due to the way the enrollment system works, when a user changes their OSUJD number, the only indicat ion is t hat one user, with an old style id number, drops all enrollment and another with a similar (but not necessarily the same) name enrolls in some (but not necessarily all) of the same classes. This RPe is a concession to the reality that t he CFNS database will most likely never be ill complete synchronization. This RPC will allow the various site administrators to do some database auditing. 5.2.6 Create A New User This RP C allows sites other than the central enterprise administration to create new users, previously unknown to the system. It takes as arguments an arbitrary OSU JD numb er l , a text string that will 1 Typically these users will have a "+" record as described in Section 3.5.3. .: 42 be considered the FULLNAME field, a Suggested UCI, and a Suggested NU ID. It then would follow the general UCI creation heuristic as outlined in Figure 3.4. Lastly, it would return the generated data as outlined in Table 5.6. 5.3 How it aU Fits Togethe r The key concepts presented in Figure 3.3 and Section 3.13 are what the previously out lined RPCs would replace. These messages, passed between the CF S database server and the departmental 'I " "slave" UAMS servers, would provide t he individual departments t ha t currently participate in the UAMS system the same basic services. The only real change t o Figurereffig:udb qry would be to eliminate the time delays between events. This would allow faster transaction processing time2 . Once the CFNS database and server were in place and operational, the slav U AMS database servers could be migrated away from the current master UAMS server onto the CFNS database server. Further, as the individual departments would still have t he fun ctionality of their slave UAMS servers, their day to day operations should not be impacted . Hence all of the services th at these slave UAMS servers supply to their departments should not change. In addit ion, as the constituent databases outlined in Sect ion 5.1 , once joined by the various RPCs outlined in Section 5.2 , would eliminate the need for t he master UAMS server 's database. In fact, t he ent ire reason for t he master UAMS server would be eliminated with the creation of a CFNS. Thus t he master UAMS server could be halted. 5.4 Other Issues There are several other issues tha t will no douht come to light in the process of t ry ing to implement a CF S. Some of those foreseen are covered in the t he following sec tions. 5.4.1 Data Base Inconsistencies As has been ment ioned, synchronization of the CFNS that UAMS has ma int ained with t he data from th e regist rar has been difficult. Wit h the advent of a CFNS supp orted and maintained as part 2 Al though it would allow it , the CF S would not necessarily force it. .,II a I; 43 of the central campus computer enrollment system , notification of changes in data can be provided to the CF S automatically. Hence, the entire scenario given in S ction 4.3.2 can be avoided. 5.4.2 Purging the Data Base of Old Records The database that UAMS currently maintains contains many cases of "duplicate ids" . This is a result of the OS U id changing problem outlined above. In t he final version of the CFNS database, these users would have their records merged under their current OSU_ID number to consolida te the logins and to assure the "one user , one login" premise of the CFNS. This will be simplified once the CFNS is in place as the central university administrative da.tabase has the mapping of which old style OSUJD maps to which user as part of their historical database. This mapping, here to unavailable to U AMS, will make the merger of these two records technically a fairly easy procedure. In the practical implementation of this purging, some of the same problems addressed in Section 4.3.1 may occur. In addition, the merging of files from t hese t.wo distinct user accounts may prove quite difficult. 5.5 Summary In talking about a CFNS, this chapter has shown how a CFNS will face many or t.he same problems currently faced by U AMS. Further, a CFNS properly interfaced to t he central cam pus admini strative databases would be able to c1eal with some of t hese problems in a far more automated way than currently available to UAMS . These concepts suggest that a CF S would allow a performance beyond what is currently available from U AMS while not sacrificing those services current.ly a vaila ble to the individual participating department.s. CHAPTER 6 PROPOSED FUTURE WORK AND CONCLUSIONS 6.1 Future Work The ultimate form this code may take is hard to ga uge at this point. This section presents a few of the directions the UAMS project could take. This is of course, not a complete list. 6.1.1 UAMS-lite Given that empirical tests of speed prove satisfactory, one thing that conld be done with UAMS would be to move the entire database onto a central host and use a commercial databa and a commercial access system to grant access to the data remotely. Then the only blocks of code existing in the UAMS-lite would be those involved with processing these data streams into the correct format for a given client. This approach would allow all of the current "manual" maintenance of t.he relational database that is UAMS to be offioaded onto the commercial database engine. Further, as the da tabase would t hen truly be a relational database, the time currentl y spent maintaining the inverted indices into the DBM based database would be eliminated. This approach would violate several of t.he original design goals of t he original UDI3. It would involve the use of a commercial database engine and <1, presumably, commercial access method , both of which would be purchased. Further, t he use of these commercial products might limit which kinds of platforms could t hen b e UAMS-lite servers. 6.1.2 Real Time Access to the Master UAMS Site One of the original design goals of the original UDB was to avoid using such things as TGP lIP networking. At the time, there were several systems within the Computer Science Department that simply did not have TCP lIP networking interfaces. This caused UDB , and later UA MS, servers to rely on electronic mail interfaces as the da.ta transport method between servers. Currently- however. all of the UAMS server sites have TCP lIP. Hence, server to server commu- 41 ~ I 45 nications could be moved from the currently slow email batch processing system to a mor direct group of peers topography_ 6.2 Conclusions The current state of this project affords the system administrator an extremely useful set of tools for managing the user accounts across a heterogeneous computer network. These tools will continue to be used here at OS U for many years to come and should be easily modified to support any new operating system that the Computer Science Department might choose to run. I i ) I II 1/ ~ I BIBLIOGRAPHY [BGMR94] Andrew Bettison, Andrew Gollan, Chris Maltby, and eil Russell. Share ii - a user administration and resource control system for unix. In Usenix Conferen ce Proceedings, Large Installation Syst ems Administration V [USE94], pages 51- 60 . [CKCS90] David A. Curry, Samuel D. Kimery, Kent C. De La Croix, and J effrey R. Schwab. Acmaint: An account creation and maintenance system for distributed unix systems. In Usenix Conference Proceedings, Large Inst allation Systems Administmtion IV [USE90j, pages 1- 9. [DLM90] William A. Doster, Yew-Hong Leong, and Stephen J. Mat tson. Uniqname overview. In I I Usenix Confe1'ence Proceedings, Large Installation Syst ems Adm i ni,~tmo IV [USE90], I't! pages 27- 35. [EVS88] II Mark E. Epstein, Curt Vandetta, and J ohn Sechrest.. Asrnodeus - a daemon servant for th e system administrator. In USBNIX Conf erene Proceedings, S7J.mm er USENIX '88, pages 377- 391. USENIX Organization, .June 20-24, 1988, [Fin92] Jon Finke. Automated userid management - simon management system . III Community Workshop , pages Subjec t Area 3, Paper 5. Rensselaer Polytechnic Institute, 1992 . [Har94] M. Harlander. Central system administration in a heterogeneou, unix environ ment: Genuadmin. In Usenix Conference Proceedings, La1'ge Installation Sy.9t em8 Admini.s tratzon V [liSE94], pages }- 8. [III84] II Douglas P. Kingston III. 'lrndfii: A t echnical review. In Usen ix Conference Proceedings, Summer Conference, Salt Lake City, pages 32- 41. USENIX Organization, 1984 . 46 47 [Inf91] Information Builders, Inc. EDA API/SQL and EDA /Structured Query Language Reference Manual, 1991. [Sto93] Roland J. Stolfa . Simplifying system administration t ask : The uams approach. In Use nix Conference Proceedi.ngs, Large Installation Systems Administration VII, page 203- 208, Monterey, California, USA , November 1-5 1993. USENIX Organization. [Sto96] Roland J. Stolfa. Uams: The man pages. Techni cal Report OS U-CS-TR-96-2, Oklahom a State University, Computer Science Department , 219 Math Sciences Building, Stillwater OK 74078, May 1996. [SV90a] Stephen P. Schaefer and Satyanarayana R. Vernulakonda. newu: Multi-host user setup. In Us enix Conference Proceedings, L arge Installation S ystems Administration IV [USE90j, pages 23- 26. [SV90b] Roland J. Stolfa and Mark J. Vasoll. Udb - user data base system. In Us enix Conference Pr·oceedings, Large Installation Sys tems AdministratIon IV [USE90J, pages 11 15 . [Urb9U] Michael rban. Gaud: Rand's gronp and user database. In Usenix Co nfer·ence Proceed- mgs, Large Installation Syst ems Administration IV [USE90], pages 17- 22. [US E90] USENIX Organization. Us enix Co nference Pmceedings, Large In. ~ t(l ation S ystems A tl- rninistmtion IV, Colorado Springs, Colorado, USA, October 17-19 1990. [ SE94] USENIX Organization. Usenix Conf erence Pr·oceedings, Large Installation Systems Admimstmtion V, San Diego, California, USA, 1994. APPENDIX A GLOSSARY 48 49 CFNS Centralized Flat Namespace System. Account management paradime where each phy ical user is granted one and only one login name and one and only one numeric user id number. Login Name A text string that is used as a nmemonic for the computer to distinguish one user from another. Login Names are typically converted to a UID by the operating system improve performance. See also P UD and UCI. NFS The Network File System. Used to allow heterogenious computer systems to share fil es across a computer network. NUID Numeric User IDentification. Used by operating systems to internally differentiate users. Password An access control mechanism common among commercial operating syst ems to secure the dat a belonging to any user. POP Post Office Protocol. A method of storing and retrieving electronic mail from a centralized spooling/ storage site. PUD Personalized User iDentifier. A t erm used by the Computing and Information Services group on campus to describe personally chosen login names. Synonomous to UCI. RAF Rights Alias File. Central configuration mechanism on a server site t hat defines which URI's affect the transfer of a user's data from the server to a given client. See Sectioll 3.3, RPC Remote Proceedure Call. A set of rout ines the a llow application programs to execute proceedure calls across the network. Destination machines may be heterogeneous[Inf91]. VAMS The User Account Management System. Was t he successor to UDI3. VCI Universal Computing Identifier. Synonomous to login name for most purposes. See Section 3.5. 50 UDB The User Data Base system . Existed as a distinct software package from 1987 through 1990 . Predecessor to U AMS. URI Universal Right Identifier is a text string given to an UDB jUAMS record that associated that record with some group of other records . Examples include class enrollment right, major codes, etc. VITA Roland Joseph Stolfa Candidate for the Degree of Master of Science Thesis: UAMS, A STUDY IN SYSTEM AD MI ISTRATIO N AU TO MATIO Major Field: Computer Science Biographical Data Personal Data: Born in Ardmore Oklahoma, on December 20, 1963, t he son of of James and Pauline Stolfa. Education: Graduated from Ardmore High School in 1982; attended St. Gregory 's College 1982-1984; graduated from Oklahoma St at.e University, Stillwater Oklahoma in 1986 with a Bachelors of Science in Computer Science., Completed the requirements for the Master of Science degree wit. II a major in Comput er Science at Oklahom a State University, May 1997. Experi ence: Syste m Administrator , Depa rtment of Electrical and Computer Engineering, Oklahoma State University, August , 1985 to May 1987. Data Communication Specialist , University Computer Center, Oklahoma State Uni versity, January 1988 to July 1988 . System Ad ministrator, Computer Science Depa.rtment , Okla homa State University, July 1988 t o present .