Identification, Authentication, and Authorization services:
Currently run AFS Kerberos v4 (KA and PT servers) with local UM modifications. Our identification service is called uniqname (pronounced unique name). The UM uniqname is a unique identifier for students, staff, faculty, and alumni. Most, but not all, of our services use kerberos. The database is replicated on three machines; we wrote the software ourselves. We subsidize the cost of the uniqname for all three campuses. The cost comes out to close to $.50/month/uniqname for the entire uniqname infrastructure.
Uniqnames are distributed at orientation to new students; faculty/staff at fac/staff orientation (just starting becuase this was an extra step in the process); others when getting University of Michigan ID card. We used to allow students to pick their own. This was too time consuming so we now assign them. We developed an algorith that assignes uniqnames that fit into a number of cultures. When someone gets a uniqname, they are required to enter their SSNs 2x, then get an entity ID assigned (if typo's in SSNs, can end up with two entity Ids for the same person). We allow users to change their uniqnames, but we charge them for it ($25).
We assign uniqnames on a first-come/first-serve basis. If someone wants a uniqname belonging to someone else, they have to work it out - we will NOT take a uniqname away from someone just because someone else (no matter who) wants it. The uniqname takes precendence over x.500 group names. We have a distributed system for establishing uniqnames (maybe 100 places), but now that we do the handing out at orientation, the need for this is far smaller.
Changes since Last Year/Future
Exploring how to move from AFS Kerberos v4 to Kerberos v5. We haven't ruled out using DCE to provide Kerberos v5 but in general we've moved away from DCE as an overall direction, at least for now.
Working on a replacement service (with the working name of "the umbrella") that provides greater functionality and better performance. The umbrella is also designed to provide more timely processing of changes in individuals status in the UM community (e.g., change from student to alumni status.
Developing a kerberos-based authentication solution (KLP for Kerberos Local Plug-In) for secure access to web pages and applications
We'd like to get our public key work started again in the near future
Issues:
Biggest issue is how to define who is and is not a member of the University - many different definitions
Assuming a certain definition, does the corporate data support it?
We haven't purged the data yet since we don't yet have good working definitions or data to support the purge.
Accounting and Billing System:
The ABS provides a real time accounting system for tracking the charging and funding for distributed services. We allocate funds each month to an average of 36,000 users. Those users use the funds to purchase servbices. ABS takes care of the banking (credits, debits) and notifying the service providers (email, dial-in) about the status of a users's account.
Changes since Last Year/Future: Two big changes in the last year. One was the implementation of a requirement that users have sufficient funds in their accounts to pay for metered and subscription services (previously this had been in place for metered services only). Users who do not have sufficient funds have their accounts suspended until funds can be deposited or services cut back to fit within the account budget.
The second major change was a complete upgrade of the DBMS and utilities on the ABS server due to a MAJOR outgage just after sufficient balanace went into effect ;-)
We are beginning the redesign of the web pages that support ABS (checking for account balances, subscribing to services) because with KLP we will be able to use Navigator or Internet Explorer to access rather than having to use lynx (because of security issues).
Allocation and charging infrastructure may go away completely - this is under discussion.
Issues:
Same as for uniqname. Who are the eligible users.
Overhead is large - is it worth it? If not, how do we deal with a demand for services that is far greater than the supply.
Directory services:
We are still running ISODE X.500 servers (I think it is one master and three slaves, but it could be four). There are about 300,000 entries in the directory (individuals, groups, services). When a group is created, a check is made to ensure there is not uniqname of the same name and an alert is provided that says that uniqname takes precendence. We have a number of locally developed LDAP clients in use. In addition, we run a mail re-addressing service called Mail.500 which allow mail sent to <uniqname>@umich.edu to be delivered to the correct recipient. We also use this data to automatically create email groups based on classlist data.
Changes since Last Year/Future: We are making a transition from ISODE X.500 servers to LDAP (SLAPd) servers this summer. We have had a terribly year in terms of reliability. About once every two weeks (less often now), the slaves and master get out of synch and cause us to put the system into read-only mode until we can get things re-synched. This has been a huge hassle to users during the year and has made our directory hard to support.
Issues:
Printing:
Status: ITD runs a metered printing service which uses the ABS to deny service when the user is out of funds. We have had a good solution in place for the Macintosh for several years.
Changes since Last Year/Future: We are now implementing a SAMBA-based solution for the Wintel platform.
Issues:
File Service:
ITD provide a central file system service (the Institutional File System or IFS) based on AFS with local modifications. We currently run 17 file servers with a current maximum size of 28 Gig. each. We have had a solution in place for Macintosh access of IFS for several years using translators which convert from AFP to IFS and back. We are now running 7 of these translators. We have a total of 63,608 users.
For protection groups, we made modifications to AFS to allow groups within groups; the code can handle infinite levels of hierarchy, but the database can't really handle more than 10-20. We currently run 3 database server machines, each one with a ka, vl, pt server. Changes to any are sent to the others immediately; changes require a pre-commit of 2 of the 3 server machines to go forward. These groups are used for courses, departments, and other groups including groups of subscribers to services (subscription service in some cases automatically adds entry to protection groups).
Changes since Last Year/Future: We have been working on stabilizing the services. We are now implementing a SAMBA-based solution for Wintel access to IFS. Still in the decision stage is whether or not we'll use the native TransArc client for NT.
Public Sites:
Moving to NT workstation for the Fall.
Oracle:
Negotiating a site license agreement to replacement the 8 year old agreement we have been operating under. Oracle is the underpinning of our client-server administrative applications replacement effort (called M-Pathways).
Email:
Looking at Netscape IMAP server; hoping to move to IMAP4 this summer/fall.