🚀 go-pugleaf

In article <5673@mccuts.uts.mcc.ac.uk> zzassps@uts.mcc.ac.uk (Phil Stringer) writes:

>were simple and as each new system came along, (every few years) we produced a
>piece of software to register users on the system and interface it to the accounting
>software written for that system. We now have a number of different databases and
>forms for users to fill in when they want to use our systems.
>
>	We are therefore now in a process of reviewing our procedures to try and 
>achieve a single easy to use unified system!

Here at UNM we have such a system. As I wade through tons of email and
news after 2 months of vacation, professional leave, personal leave, etc.
I found some  email requesting I submit a paper on it for presentation at the
LISA Conference coming up. Unfortunatly, deadlines have come and gone so
it probably won't happen this year.

The way it works (in a nutshell) is a list of all persons affiliated with the
university (students, faculty, staff, etc.) is generated on the IBM mainframe
and sent to the Unix system(s). Everyone on the list is entitled to an account
on any (all) of our systems.

Anyone wanting a computer account logs into any Unix system as the user "new"
where they are prompted for a variety of information including UNM ID number,
Name, date of birth, the system(s) they want accounts on (MVS, CMS, VMS, 
Unix, etc.), the login name they wish to use and the password they want.

The info is verified (real pearson, valid login ID, clever password) and
if all ok, thengivin some instructions on what to do, particularly if
there are any problems.

During the night, all the various systems are contacted, some RPC
magic happens and the necessary accounts are created.

Then there is user deletion, which is the bigger, more difficult part of the 
code. Each night, we look to see who has left the University. If they
have any computer accounts they are marked for deletion, thus begining a
~2 month process. (students gone for the summer are not deleted).

For the first month, the account is locked. What this means is that when
they try to log in, they get a message saying that the account is locked 
and will be going away soon, and if they feel this shouldn't happen
then call the specified number and explain it to a human. This also
insures that the whole account ends up on a monthly backup that is saved
for one year.

If nothing has happened, the the software assumes it is doing the right thing
and blows away all the files and re-directs mail back to the sender saying
the account has gone away. (This is done over 2 weeks, I can't remember the
exact process that happens). A couple of weeks later, a few more cleanup things
happen, can't remeber exactly what other than the mail re-direct is taken
out so mail just bounces with a user unknown message.

This whole process is done without human intervention. (Look ma, no hands!!!)
and seems to work rather well. The code is going through a cleanup process
this fall, with hopefully a release that is presentable to the public
by December or January. (there are currently some security concerns that
need to be resolved first).

--
Steve.
-- 

Steve.                    sfreed@ariel.unm.edu

In article <yvcnv6a@lynx.unm.edu> sfreed@lacerta.unm.edu (Steve Freed) writes:
>The way it works (in a nutshell) is a list of all persons affiliated with the
>university (students, faculty, staff, etc.) is generated on the IBM mainframe
>and sent to the Unix system(s). Everyone on the list is entitled to an account
>on any (all) of our systems.
>
>Anyone wanting a computer account logs into any Unix system as the user "new"
>where they are prompted for a variety of information including UNM ID number,
>Name, date of birth, the system(s) they want accounts on (MVS, CMS, VMS, 
>Unix, etc.), the login name they wish to use and the password they want.
>
>The info is verified (real pearson, valid login ID, clever password) and
>if all ok, thengivin some instructions on what to do, particularly if
>there are any problems.
>   [...]
>This whole process is done without human intervention. (Look ma, no hands!!!)
>and seems to work rather well. The code is going through a cleanup process
>this fall, with hopefully a release that is presentable to the public
>by December or January. (there are currently some security concerns that
>need to be resolved first).

Without human intervention, how do you verify ID?

Another way of looking at it is that anyone knowing the UNM ID number and
birthdate of someone can get accounts in the victim's name. This is particularly
bad for some staff/faculty who does not normally need an account and will 
never try to get one. The crook can get away with this for years!

In one of the recent issues of RISKS digest, there was discussion of problems
with a registration system like this.     


--
Stanley Chow            InterNet: schow@BNR.CA
Bell Northern Research  UUCP:     ..!uunet!bnrgate!bqneh3!schow
(613) 763-2831
Me? Represent other people? Don't make them laugh so hard.

A similar system (user self-registers, using student ID number as a
temporary authenticator) is in use here; and we got it from MIT Project
Athena.  Yes, an intruder knowning someone's name and student ID
number can open an account (if the real person hasn't done so already).
In our situation we don't consider this a big deal because we can't
keep students from sharing login names and passwords anyway.

If this isn't secure enough for you a solution I guess would be for the
master data base to send over not the student ID number but some unique
random-ish number or string of its own making; and then to send the same
number by paper mail to the person to use in registration.  Or if you
really want to have photo ID cards checked then have the person who does
the checking give out the made-up number.

A lot of things would be more secure if we didn't use the social security
number for anything except social security.
-- 
haynes@cats.ucsc.edu
haynes@cats.bitnet

"Any clod can have the facts, but having opinions is an Art."
        Charles McCabe, San Francisco Chronicle

sfreed@lacerta.unm.edu (Steve Freed) writes:
>Anyone wanting a computer account logs into any Unix system as the user "new"
>where they are prompted for a variety of information including UNM ID number,
>Name, date of birth, the system(s) they want accounts on (MVS, CMS, VMS, 
>Unix, etc.), the login name they wish to use and the password they want.
...
>This whole process is done without human intervention. (Look ma, no hands!!!)

schow@bqneh3.bnr.ca (Stanley T.H. Chow) writes:
}Without human intervention, how do you verify ID?

}Another way of looking at it is that anyone knowing the UNM ID number and
}birthdate of someone can get accounts in the victim's name.

Our registration process is similar, but every month it generates a postcard
for each new registrant, "Welcome to ... if you don't have the first clue
what we are talking about, someone is using the system in your name, please
call ...".  This is mailed to the person's official university address.

It does have a hands-on step though :-(  A clerk has to put stamps on the
ones for students living off-campus (we use on-campus mail for those with
an office faculty/staff/GAs and dorm residents, so it's not too many).

John
-- 
John Hascall                                       ``Live with it pink-boy!''
Project Vincent                                                              
Iowa State University Computation Center                     john@iastate.edu
Ames, IA  50011                                      515/294-9551 [fax -1717]

sfreed@lacerta.unm.edu (Steve Freed) writes:
...
}Anyone wanting a computer account logs into any Unix system as the user "new"
}where they are prompted for a variety of information including UNM ID number,
...
}Then there is user deletion, which is the bigger, more difficult part of the 
}code. Each night, we look to see who has left the University. If they
       ^^^^^^^^^^
Really?  Why so often?  We do deletions once a semester (I'd like to
do them each month, but we have to pay our Admin Data Proc Ctr for
each "tape").

John
-- 
John Hascall                                       ``Live with it pink-boy!''
Project Vincent                                                              
Iowa State University Computation Center                     john@iastate.edu
Ames, IA  50011                                      515/294-9551 [fax -1717]