Project Status
02/01/96
Notes from U Michigan DCE conference call 1/31:
U Michigan AFS/Kerberos V4 Environment
Production since 1991.
70,000 users managed by 3 kerberos servers.
2 realms: umich.edu and umich engineering dept. Name space
from both realms are shared.
AFS configured for one or more filesets per user.
Large population of Mac and Windows K4 clients. Locally
developed AFS translator for Mac file system access.
Use a number of read only clones to minimize load on central
AFS file servers.
They managed to include departmental systems in their campus
wide realm/cell by simply making the capability available.
Most of their departments were looking for direction concerning
security. They still get all the comlaints when things don't
work ;-)
U Michigan DCE/Kerberos V5 Directions
Requirement to support DCE/K5/K4 and DFS/AFS concurrently. Looking
K4 support in DCE 1.2. They haven't looked into CyberSAFE. They
are interested in the Argonne K5 mods we have used to make K5 clients
and servers inter-operable with DCE.
Under the new enviroment they hope to keep any user UUID active who
has ever been associated with the university. They are projecting
a security server namespace of +500,000 principals.
They are working with Gradient on Mac and Windows DCE code. The Mac
developers libraries should be available now from Gradient. This is
DCE 1.1. Binary release should come soon.
They have done some scaling tests with the older OSF and IBM DCE software.
This paper can be found from the Michigan web site. Basically their
findings show linear resource utilization scaling up to 50,000 principals
in the DCE security server. Lookup time seems to be constant with
populations 50k or less. Experience very long delays when master server
is checkpointing. They don't have any experience with the new DCE
code that we are using on AIX. They plan to use AIX as their server
but only recently got the new release of the code. Thus they didn't
have any comments concerning hierarchical cells.
http://dcewww.citi.umich.edu:8080/
They advised limited use of the DCE CDS (Cell Directory Server). It
turns out that most of the scaling problems are related to CDS caching
validation. The CDS uses a timed algorithm that causes inconsistancies
between multiple CDS servers. They are looking at using a locally
developed protocol (Lightweight Directory Access Protocol - LDAP) as
an interface to X.500 directory services to replace the CDS. This
means we will be rethinking moving Li to CDS. Options include scaling
the existing Li with a CDS-like interface or moving Li to a standard
database/transaction system. The good news is that the DCE security
server doesn't suffer the same problem.
They recommended that we send someone(s) to Decorum (DCE users group)
and would like to collaborate on DCE deployment and scaling issues.
Other topics of interest:
They use "Livingston" terminal servers to obtain K4 login credentials
at dial-up login time.
Dial-ip software is made available to students when registering for
classes.
Have a subscription service for dial-ip, disk, computing resources.
This is where the all-umich-affiliates name space comes in.
They have a student technology fee.
U Mass has a campus DCE implementation called project Pilgrim. They
use locally developed middleware to interface legacy application to
the DCE authentication and authorization services.
http://info.pilgrim.umass.edu/
01/16/96
A conference call has been setup between C&C and U Michigan to discuss
DCE/Kerberos issues on Jan 31.
Rick DeCamp from CyberSAFE will visit on Jan 25 to discuss the CyberSAFE
evaluation and address some of our concerns.
Jim
Date: Thu, 11 Jan 1996 11:02:06 -0800 (PST)
From: Yonah Karp
Subject: users with multiple userids
55,355 people were in the list of users in Li Jim Fox sent early
Weds a.m.
Of these, 55,031 are UA account holders.
Of the 55,031, 1771 have more than one userid. (This is 3.2%.)
# userids # people == # fac/staff + # students + named accts
2 1700 612 1057 31
3 53 19 31 3
4 13 4 9
5 5 0 5
Named accounts are things like SYS (sys and bin), UBS (ubs and
uwace), PERS (pers and personnel), accounts that look related to
lists, etc.
Yonah
Date: Tue, 9 Jan 1996 17:03:06 -0800 (PST)
From: Yonah Karp
Subject: Notes from 1/8/96 unif namespace meeting
Other points you remember? Please send them along.
======
FF/YK/JF
Frank, Jim F and I will look at the NDC aufs. (Jim
already ran li reconciliation against the NDC aufs.)
ML Mary Ellen et al will look at the exceptions we can't
handle algorithmically.
JF We need to pinpoint users who have no obvious individual
responsible for the account (i.e. owner). Jim F will
generate a list of people from li who don't look like
students or staff from their account names. The list
will include account, userids & related hosts, and mail
forwarding.
OS We discussed using the (newly added) owner field in li to
track responsibility for a particular account. If
someone leaves the U, we currently don't have a way of
disassociating them from such an account. Oren promised
to have Client Services think about this one.
YK Our clients should be adding owner for supplemental
accounts even before we make the change to add owner for
everyone. E.g., addid should force user (C&CI) to add
the owner via the owner's SSN. Yonah will work on this.
ML/JF
The issue of tracking who has securid cards arose again.
We had previously discussed creating a mechanism
(auf-like?) which would contain securid# and account
name. This probably needs to be revisited (between Mary
and Jim F in particular.)
Yonah
From: Jim Fox
Date: Fri, 5 Jan 1996 16:58:18 -0800 (PST)
>
> JimF -- Remove hosts chasqui, quipu, and leonardo from li.
Done.
> JimF -- Make sure clients are grabbing high uids so the <30k uids
> are available for Frank.
If the 'want' request includes the 'highuid' keyword
then uid>32K is issued, else uid<32K is issued. I think
saul mead and homer use the highuid keyword.
> JimF -- Get list of multiple userids.
Given to SteveI.
Date: Fri, 5 Jan 1996 16:30:23 -0800 (PST)
From: Yonah Karp
Subject: 1/5/96 notes -- li & staffdir
JimF -- Remove hosts chasqui, quipu, and leonardo from li.
JimF -- Make sure clients are grabbing high uids so the <30k uids
are available for Frank.
JimF -- Get list of multiple userids.
JimF -- Get list of users whose accounts don't look like SSN's or SN's.
JimD -- Bring up setname at coord meeting. We suggest that a
message go out telling folks that setname will be
turned off in a month. Discuss how to do implement
(modify setname so that only people who are changing
two usernames to one can use it??).
Frank -- Be available to let us look at gecos in bank/ red passwd
files so that we can make sense of the people we find.
Yonah -- Generate a list of users in li who are not in validation files.
Yonah -- Make available uid/ userid pairs from NDC clusters.
JimF -- 'Validate' uid/ userid pairs from NDC clusters to find
problems.
Also, we now know --
New bank/ red accounts go in as 'caccluster' into li. There are,
however, several hundred
All @u addresses go through li.
Frank needs to continue to have <30K uids for his clusters.
If you folks have any other items that aren't included above,
please tell us.
Yonah
Date: Fri, 3 Nov 1995 17:22:14 -0800 (PST)
From: Yonah Karp
Subject: Uniform namespace meeting minutes 11/2/95
Present: Jim DeRoest, Frank Fujimoto, Jim Fox, Steve Ingersoll,
Jim Blankenship, Ken Lowe, Keith Mason, Lori Stevens,
Sid McHarg, Yonah Karp
We met to talk about a uniform name/ uid space. Our long-term
goal is one person == one uid == one userid == one primary
password. The security mechanisms DCE and Kerberos are part of
what drives this project; also, another goal is to be able to
track an individual's account usage. We identified the
following issues as we work towards this uniform space.
Issues
======
A series:
Userids different from everywhere else.
Some applications grant privileges based on prefix
of userid, e.g. PAYnnnn, ISOnnnn, ADPnnnn.
Leonardo is MCIS machine, and it may be difficult
to get buy-in from those users.
Single password would be a problem for some A16 software.
Some local software would be ok to put in password
hook -- other software won't. However, may not need
local password validation if coming from the outside.
Also, possibly MCIS has a Kerberos cell running.
Change in serial number length for Securid. Securid
currently has a 6 digit serial number. New cards
will have an 8 digit serial number, and the protocol
to talk to security server may change because of this.
NDC clusters:
Two types of uids (two time periods of their creation):
uids which match with li, uids that don't.
Need to sift through accounts to see scope of problem.
Eventually will need to change uids on these systems.
Maxuid problem -- uids need to be < 30k.(Ultrix)
bank/ carbon/ green may have people who are > 30k on UA.
Some userids different too. May conflict with same userids
(but different users) on UA.
1000 accounts total, so problem somewhat manageable.
UA clusters:
Multiple uids (high/low) per account -- 3500
Multiple usernames per account -- both technically and
politically a problem.
Multiple accounts per responsible person (many systems):
Solution -- use 'owner' field Fox put into li
Need clients that will give/ use, need to be able to search
li by owner field, give li owner info
Obscure hosts & buyin:
Need to investigate later.
VMS accounts:
Userids often different from everywhere else.
One approach is to ignore -- Max going away.
Username for Ingres different/ connected to the app.
Action items
============
Vitcos, robinhood et al
Fox/ Blankenship figure out dups/ conflicts
A series userid conflicts
Fox/ Keith Mason figure out dups/ conflicts
Multiple uids per account on UCS systems
UCS fixes
Multiple usernames
Yonah addresses with larger group (coordination/ consulting)
Li clients -- "owner" field
Yonah will modify new/ addid (creation) clients to put owner
information into li
Fox will modify li-querying clients to allow queries by owner
A series auf's currently being sent
Fox will have li load all of them
Letcher Ross uid/nebula hook
Yonah contacts Letcher/ Frank
NDC hosts
Frank sends aufs to li
Yonah/ Frank/ Fox address duplicate issues, examine scope
Another issue is that DCE doesn't ignore < 1000 uids, like much
of the other software does. We'll have to deal with those issues.
Some of the above issues may be resolved with use of multiple
cells/ realms. While we are considering this possiblity amongst
ourselves, performance is a concern. We will need to deal with
multiple cell issues anyway because we'll likely be needing to
communicate with campus DCE/ Kerberos cells/ realms.
One need to be addressed quickly is to get a security server up.
It is clear that this is a large, complex project, and is
long-term -- and will take careful coordination.
Yonah
Back to AST Home Page