\section{Guest Accounts}

There are two types of guests accounts.  In a normal guest account,
we sponser a user to have an account (usually placed in the sipb afs
cell), and we make a request to athena accounts to create all the data
necessary to support the account.  The home directory will reside on
a sipb machine.

\subsection{Normal}

These guest accounts are given to people who are doing work which we
feel helps out in the goals of SIPB.  These accounts are temporary,
generally a term or a year, and each accounts's existance re-evaluated
at the end that term or year.

The policy with these accounts was determined at the 11/25/91 meeting:

\begin{quotation}

\begin{center}\bf SIPB-sponsored Athena account policy\end{center}

There are concerns which prevent the SIPB from sponsoring guest
accounts for anyone who asks for them.  These concerns include:

\begin{itemize}
\item Licensing.  Some software available on Athena are licensed to the
  MIT community, and there are therefore some legal problems with
  giving people who are not currently members of the MIT community
  access to them.

\item Policy.  Clearly, Athena/IS believes that deactivating accounts is a
  necessary thing, and giving deactivated accounts back to anyone who
  asks might be considered a subversion of that policy.

\item Resources.  The amount of resources available for Athena accounts is
  limited.  Large-scale granting of guest accounts might tax both
  Athena's resources and the SIPB's.

\item Nepotism.  The SIPB does not wish to become known as an organization
  that uses grease to make life better for its friends, while not
  serving the user community as a whole, as its charter intended.
\end{itemize}

Furthermore, much of the functionality obtained through an Athena
account is available on public-access systems that can legitimately
give out accounts to anyone who asks and is willing to pay the
(usually not very high) fees.

Therefore, the SIPB chooses to restrict account sponsorship to two
classes of people:

\begin{itemize}
\item SIPB members.

\item Individuals who will use their accounts to further the goals of the
  SIPB (FTGOS).
\end{itemize}

SIPB members are entitled to sponsored accounts if for no other reason
than because "membership has its privileges."  Furthermore, SIPB
members are elected only when the membership feels that they will be a
worthwhile addition to the SIPB and help to FTGOS.  Therefore,
sponsoring accounts for members is considered a worthwhile investment.

Unfortunately, what is and is not "FTGOS" is currently somewhat
undetermined.  The mechanism for creating guest accounts currently
leaves that decision to the discretion of the member sponsoring the
account, although the SIPB Executive Committee (EC) may choose to
override a member's decision to sponsor an account.

When a SIPB member wishes to sponsor an account for a non-member, he
or she (the "or she" is assumed from this point forward) should
contact the EC through E-mail to the sipb-ec mailing list or through
some other channel, providing the following information:

\begin{enumerate}
\item The full real name of the sponsoree, including middle initial.
\item The social security number, MIT ID or some other 9-digit number
   which may be used by the sponsoree when he registers for his
   account.
\item The desired username for the account.
\item The address to which E-mail should be forwarded, if it should not
   be left on an Athena post office.
\item The FTGOS purpose(s) for which the account will be used.
\item If possible, a date after which the account will no longer be
   needed.
\end{enumerate}

Note that if the account being sponsored is the reactivation of a
deactivated Athena account, items 1 and 2 are not necessary, and the
username provided in item 3 is the username of the deactivated
account.

The sponsor should then wait at least three full business days after
the message has been delivered to the EC.  In that time, any SIPB
member may choose to respond to the sponsorship request, asking for
more details about the purpose of the account or questioning the
sufficiency of the reasons given.

If someone questions the account, the sponsor can argue with him, or
bring it up at a meeting, or whatever.  Among other things, the EC has
the authority to request that the sponsor or sponsoree come to a
meeting and justify the need for the account.  The final decision
about whether or not to grant the account is left to the EC.

When/if the account has been approved, the sponsor should send E-mail
to "accounts" with the information from items 1, 2, 3, 4 and 6 above.
If no expiration date was specified, then the date given should be
registration day of the term following the term following the current
term (e.g. an account sponsored in November should expire by default
around the beginning of the following September).  The message should
be carbon-copied to the EC.  Furthermore, if a home directory in the
SIPB AFS cell is necessary, the message should be carbon-copied to the
sipb-afsreq mailing list.

When an account is about to expire, the sponsoree must ask the sponsor
to responsor it, once again stating how it will be used to FTGOS, or
he must find a new sponsor for the account.

The Secretary of the SIPB will be responsible for keeping records of
currently sponsored guest accounts, including their expiration dates,
as well as for sending out notices when accounts are about to expire
(if Athena doesn't start doing so).

Notes:

\begin{itemize}
\item Approval is not required from the EC before creation of an account
  for a SIPB member.  Furthermore, such accounts need no expiration
  date.

\item Some scheme will have to be devised for incorporating current guest
  accounts into this system.
\end{itemize}

\end{quotation}


\subsection{Temporary ({\tt sipb\em n}) accounts}

There are 10 SIPB temporary accounts named {\tt sipb[0-9]}.  {\tt sipb0}
should never be given out.  The others may be given out to whomever may
need temporary access to the net or athena or whatever.  The policy
about these accounts is described here, taken from
{\tt /afs/sipb/project/guests/admin/HOW\_TO\_USE}.

\begin{itemize}
\item Decide that the person really does need a SIPB guest account.  This
is Athena; if he only wants to log in once to read mail, consider
logging him in as {\tt sipb0} in the office (but don't give him the
password).  There aren't any real hard-and-fast rules about use of
SIPB guest accounts, so just use your best judgement.

\item Choose an unused account from the list in the accounts file.  {\tt sipb0}
is normally reserved for testing, etc.

\item Check out the accounts file with RCS.  Using RCS insures we have a
log of who has been using the guest accounts and why.

\item Write down the user's real name, local contact (phone), permanent
email address if s/he has one, how long s/he will be using the account,
why the account is being given out, the current date and your username.
The easiest way to do this is to copy the information for {\tt sipb0} and
replace it with the correct info.  (Temporary accounts should be
restricted to two weeks.)  Then ask for a password, and change the
password of the account to this password.  Record all this information
(including the temporary password) in the accounts file.  It's a good
idea to make sure nobody has accidentally left the admin directory
world-readable or writeable.

\item check in the accounts file with RCS.

\item When the user is done, change the password back to the canonical
password, and email to {\tt sipb-afsreq} to clean up the account.

\item The script {\tt clean\_dir.csh} needs to be run to clean the directory
out.  It needs to be run with {\tt system:administrators} tokens in the
{\tt sipb} cell.  The argument is the account name.  The person who cleans the
account should then remove the information from the accounts file,
signifying this account is no longer being used, and can be given out
again.

\end{itemize}
{\em Marc Horowitz}