Visitor Accounts

The below is out-of-date for the easiest provisioning of wireless-only accounts. Please see: Help Desk Guide: Network Access for Visitors

We have some pre-allocated reusable accounts used for short-term visitors. For those visit on a regular basis, it's reasonable to allocate a permanent account. For others, a reusable account is reasonable for durations up to a term.

Introduction

There are three types of reusable account. One provides wireless access only; another is a real computing account on the core.cs systems, good for storing files, exchanging e-mail, and publishing WWW pages. The third type also has a real computing account on the student.cs systems. The userinfo command can be used to determine what resources each particular userid has.

A list of the reusable accounts (a.k.a. temporary accounts) is maintained on the machine cs-xh-admin.cs.private.uwaterloo.ca in the directory:
/software/local_cs-xh-admin.cs.private.uwaterloo.ca/data/accounts-visitors-csNNtmp/ . The visitors.txt file contains information on the different types of temporary accounts and instructions on their assignment to responsible individuals. Ideally, at any given time, there will always be several accounts available and not in use. (It must be possible to give these accounts out on a moment's notice).

visitors.txt is used only by people, not automatically by computer programs, so think of anything you put in it as notes to other readers. To read and change it, your account will need to be in the UNIX "sponsor" group.

UW accounts (e.g. for wireless access) need to have their WatIAM password reset. CS accounts need to have their CS password reset. Accounts in both realms should have the new password set to the same value in both systems.

As with all accounts updates, useful summaries should be mailed to accounts@cs. (That is, inform accounts@cs if you allocate a vistors.txt account because of a request not sent through accounts@cs ).

Conferences and Wireless Accounts

  • You may use a single wireless only account for multiple people when hosting conferences
    • always change the password after the conference
  • ICR area presentation rooms: ICR also has wireless accounts set aside for conference use . Contact Jean or Vera

Questions to Answer

  • does the visitor already have an account ?

  • has the visitor had an account in the past ?

  • who is sponsoring the account ?

  • how long is the account needed ?

  • is wireless access sufficient, or will a computing account be needed (e.g. for file storage, email, WWW page publishing) ?

Visitor account types

WatIAM + CS core + student.cs

  • The following accounts have access to WatIAM (ie: wireless), CS core and student.cs machines: cs01tmp - cs05tmp
  • note that these accounts require the most work to reset, so should be the last choice, unless all of those account types are actually needed

WatIAM + CS core

  • The following accounts have access to WatIAM (ie: wireless), and CS core machines: cs06tmp - cs16tmp

WatIAM

  • The following accounts have access to WatIAM (ie: wireless) only: cs17tmp - cs27tmp
The information about which account names have which access is probably more reliably recorded in the visitors.txt file (described in the next section) itself.

Visitor Temporary Account Setup

If a temporary account is appropriate:

  • login to the machine cs-xh-admin.cs.private.uwaterloo.ca using ssh

  • type:
    cd /software/local_cs-xh-admin.cs.private.uwaterloo.ca/data/accounts-visitors-csNNtmp/

  • edit the file visitors.txt, using your favourite text editor, e.g. `vi` or `pico`

  • go to the
    ==== Available ====
    section

  • pick the first unused account of the appropriate type

  • Move the line to the
    ==== In Use ====
    section

  • add the date (YYYY/MM/DD), and the sponsor, and who the account is for to the entry for the account

  • add another line indicating when the account can be reset In most cases, the request for an account includes a well-specified period for which it is needed. In those cases, specify that end date. In other cases, it is necessary to indicate who should be consulted when to determine an actual end date.

Example

This:

userid cs10tmp password  sb9Lm]p (encrypted WUui3eYZzuvz.)

would become this:

2009/11/04 for recruiting visitor with Shai Ben David
IN USE userid cs10tmp password  sb9Lm]p (encrypted WUui3eYZzuvz.)
Can be reset on November 19

Send email to requestor(s)

At the same time you should look at the general state of the visitors.txt file. If the number of accounts in the "Available" section is low, but the notes indicate there are accounts actually available, consider resetting a few accounts to rectify that situation.

After the Reset Date

In most cases, the request for an account includes a well-specified period for which it is needed. After the end of that period the account can and should be "reset". The password should be changed so that the previous user does not know it, and the home directories (if any) cleared so they contain no personal information from previous users.

In other cases, you need to repeatedly contact the party you (or someone else) indicated in the entry to determine when an account is actually no longer needed.

Ideally, very soon after the "may be reset" date, accounts would actually be reset and moved back to the "Available" section of the visitors.txt file to ensure that there's always a good supply of accounts easily available, but there's not always immediate time for that. Instead, move the multi-line entry for the account to the

===== Accounts Requiring Resetting =====

section, so that it is more obvious there are some accounts not in use, but requiring resetting.

When necessity (lack of accounts in "Available") or convenience dictates, do the work required to move accounts back to the "Available" section. As the next section details, that work required involves resetting (all) the passwords, and recording the date and new password.

In practice, the time after you have handed out an account is a good time to review the general state of the visitors.txt file. If it is convenient, actually reset a few accounts. But, if nothing else, move from "In use" to "Accounts Requiring Resetting" any entries which have actually passed their "may be reset" date.

Preparing the Account for future Re-use

When there are very few accounts in the "Available" section of visitors.txt, or preferably before, you need to do some preparation so accounts can be moved there.

For each account in the

===== Accounts Requiring Resetting =====

section of visitors.txt, you need to do all the work described in the next few sections. (Or at least, for as many accounts as you choose to do in a session). And in some cases it may be convenient to do the work to reset accounts in the

===== In Use =====

section to move directly to "Available".

Obtain a "random" password

We need to change the password to something we know and also something the previous user does not know. We eventually record that in visitors.txt so the account can later be quickly given out when needed by another user.

Determine a new password for the account.

To do that, on cs-xh-admin.cs.private.uwaterloo.ca type:

   cs-xh-admin% password userid +r
   OK to change userid's password to "dwyXEePC"? no
   cs-xh-admin% 
   

(Use your own userid, and be sure to type no in response to the question so you don't actually change your password). Unfortunately, the result you get doesn't fit the WatIAM nor CSCF password rules. So modify the password you get by changing one middle letter to a digit (best not "0" or "1"), and another to a "safe" other character, say "." (dot/period). Save that password somewhere.

In our example, assume we will use dw4XE.PC as the working password. (I have tested that in WatIAM). (But obviously, because its written here, will never use that password). Save the password in a private file somewhere. You will need to use it a couple of times and eventually record it in vistors.txt.

Setting password in WatIAM

(This requires appropriate WatIAM access of course). At the time of writing, you needed to do...

  • Enter your WatIAM userid and password

  • Select the "Passwords" tab

  • Setup something like [Account id] [starts with] cs0tmp
    • Click "Find"

  • On resulting page, enter password into each of two boxen
    • Click "Change Password"

  • On resulting "Change User Password Results" page
    • You must click "OK"

  • Select "Logout"

Maybe test it...

  • Enter username (e.g. cs01tmp) and password
    • should get "Logged in as: cs01tmp"

  • Select "Logout"

Setting password on =linux.student.cs or linux.cs

Cleaning home directories on =student.cs or core.cs

Then for any real computing accounts you must clean up any home directory and mailbox usage.

Sign on to the account using, and thereby testing, its newly-changed password to do...

    cs-xh-admin% ssh -x core.cs -l cs01tmp
    Password: 
    Last login: Fri Mar 19 12:05:42 2010 from cs-xh-admin.cs.
    
    Terminal type is xterm
    xdisplay: Time out occurred
    @core[2]% rm -f /var/mail/cs01tmp
    @core[3]% rm -rf * .??*
    @core[4]% init_home
    Copying "/software/accounts/config/share/init_home/.aliases" to "/u2/cs01tmp/.aliases"
    Copying "/software/accounts/config/share/init_home/.cshrc" to "/u2/cs01tmp/.cshrc"
    Copying "/software/accounts/config/share/init_home/.login" to "/u2/cs01tmp/.login"
    Copying "/software/accounts/config/share/init_home/.logout" to "/u2/cs01tmp/.logout"
    Copying "/software/accounts/config/share/init_home/.mailrc" to "/u2/cs01tmp/.mailrc"
    Copying "/software/accounts/config/share/init_home/.profile" to "/u2/cs01tmp/.profile"
    @core[5]% 
    @core[6]% vi .cshrc
    @core[7]% history -c
    @core[8]% 
    

You need to edit the .cshrc file to remove the line...

                /software/accounts/data/standard/first_login

If there is a student.cs account too, repeat that procedure on student.cs.uwaterloo.ca.

Move the information in the =userids.txt file

Only after the home directories have been emptied, and the password has been changed can you move the "userid" information line from the "Resetting" section to the bottom of the "Available" section, deleting any other comment lines and removing the "IN USE" tag. Make sure you leave the correct password.

Visitor Permanent Account Setup

This is the same as setting up any non-student permanent account.

Edit | Attach | Watch | Print version | History: r18 < r17 < r16 < r15 < r14 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r18 - 2016-06-03 - AdrianPepper
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback