Accountmgmt Help ---------------- See also the man page for accountmgmt (8).

The following topics are covered in this help document:

MENU

The accountmgmt tool presents a menu of options that help to manage accounts on the server. Administrators can only administer accounts for their departments. If you try to modify an account that is not within your department, a message will appear on screen to that effect. Likewise, any information displayed is limited to your department.

Administrators who are Providers of Service (POS), such as local support providers (LSP) or lab assistants have further restrictions on which tools they can use. A POS will see a restricted menu with the following options:

  1. Account status
  2. PennCard status
  3. Administration history
  4. User reports
  5. Browse user records
  6. CHFN
  7. Password reset
  8. Email forwarding

Where possible, we have made the administrator's input case insensitive. Obvious exceptions to this rule include the password and the full name of the user.

Where possible in the command line version of account management, we have allowed for abortion of any operation. At most prompts, you can just type "q" to quit the operation.

STATUS

You must supply either the username of the account or the user's PennID number as an argument to this option.

Used to show a user's record as it appears in the server password file, billing database and server user database, how much quota the user is currently using, any email forwarding information known by the system for the user, and last usage by the user.

Lock information:

If the user's account has been locked, a notification will appear at the top of the status listing. A user can be locked for three reasons:

  1. The account is using Basic Security but no password has been set for the account. The administrator must either change the service for this account so that it is using Enhanced Security, or a password must be set for the account.
  2. The account has been disabled. The account administrator can reinstate the account, if necessary.
  3. The system administrator has locked the account for security violations. The administrator should contact the system administrator.

Pass DB:

The password entry includes: the username, a password holder field, the userid #, group #, personal information including full name of the user, home directory for the user and the user's login shell.

If the account is using basic security, the password is housed in a different database but is stored in an encrypted form. We cannot decypher the encrypted password and therefore will never be able to tell a user what the current password is.

The personal information housed in the password entry is used by host-based mail clients like Mutt and Pine for the mail header of email messages sent by the user. If a user wishes to change this information, the user must contact the administrator who can use the CHFN command in the administration interface to change the user's real name.

Bill DB:

The entry from the Billing database includes: the username, the user's full name, last four digits of the SSN, PennID #, account type, quota, billing record #, billable flag, organizational #, organizational description, budget code #, date of creation, date of deletion, date last invoiced.

If an account has been reinstated, the date of creation will be the date of reinstatement rather than the original date that the account had been created as reflected in the entry from the user database.

User DB:

For each account on the server, there is a one line record in the server's user database that contains the following information in colon-delimited fields:

  1. username.
  2. full name.
  3. org code. The organizational code contained in the budget code paying for the account. For students, this is the school code as extracted from the PennCard record; "other" will appear if no school code appears in PennCard.
  4. SSN4.
  5. date of creation. If a student's school changes and the org field is updated, the old school code will be stored in this field.
  6. quota assigned.
  7. account type. A three-letter code indicating the usertype, accounttype and security. Usertype can be either "A" for faculty/staff or "S" for students. Accounttypes can be either "I" for individual accounts, "G" for group accounts or "N" if the user does not have a PennCard record. Security type can be either "S" for basic security accounts or "E" for enhanced security accounts.
  8. permitted. For student accounts only, if the user does not have one of the valid school codes in his/her PennCard record, an account can still be created for that student but that student must then be permitted. This field will show the school code of the administrator who permitted the user, otherwise, only "N" will appear.
  9. PennID. For more information, see: http://www.upenn.edu/penncard/card/about.html
  10. deletion date. If the user has been disabled, this field will include a "*". Once the account is actually deleted, the "*" will be removed. If the account was created with an automatic expiration date, this field will include a ">" and the expiration date.
  11. full name of group owner.
  12. email address of group owner.

A deleted user will remain in the server user database so that you can continue to see status information for deleted users.

Old org:

If a student's school changes and the organization field is updated, this is the old school code before the update.

SPAM FILTERING STATUS:

Information about use of server-side spam filtering includes:

  1. Level: the current level of filtering. This value can be:
    • disabled - the user has opted out of spam filtering
    • tag only - the user has opted to tag mail as spam but not to move it to the caught-spam folder
    • 4 - very high
    • 5 - high
    • 6 - medium
    • 7 - low
  2. Expire interval: how many days filtered spam is kept in the caught-spam folder before it is automatically deleted
  3. Registered: date the user first registered for spam filtering
  4. Last modified: date the user last made changes to the spam filtering profile

Group accounts owned:

The list of group accounts owned by the user.

Last login:

The last time that the user logged into the system using either telnet or ssh.

IMAP usage:

The last time the user accessed the system using an IMAP client since February 17, 2001 when we started to archive IMAP usage.

POP usage:

The last time the user accessed the system using a POP client.

Webmail usage:

The last time the user accessed the system using Webmail.

Temporary quota:

The date that a temporary increase to the user's quota will expired.

VERIFY

Used to retrieve the PennCard record of a user. You must supply either the username of the account or the user's PennID number as an argument to this option.

If the current PennCard school code differs from the school code in the student's server record, this option will update the server user record. If the PennID in the PennCard record differs from the user's PennID in the server record, this option will update the server user record.

REPORT

This option will let you choose to view one of several reports to help you to manage problems with your users' accounts. You will have the option to view the report online or to have it mailed to you.

  1. Quota Problems - This is the daily report that is already mailed to you that lists users within your department that are over quota or nearing their quota limit.

    Users who are over quota will have trouble running programs on the server including host-based mail clients. You can increase a user's quota by selecting the option "Quota" above but please advise the user to do some housekeeping before automatically increasing quota. Users who are over quota will no longer receive mail. Users will have to delete messages or move messages to their local workstations.

  2. Report of all active users - This is a list of all of the users in department who currently have an account on the server.

  3. Report of all users - This is a list of all of the users in your department, including accounts that have been deleted.

  4. Report of users with above normal quotas - This is a list of all user in your department who have been assigned more than the base quota for either the home or mail spool. This report does not include users who have been assigned a temporary increase in quota.

For account administrators, we also have available:

  1. Directory Load - Nightly, we upload information from the server that feeds the online Directory. This report is the list of unusual occurrences from that load.

    "NOT_YOUR_RECORD" - the user's record is owned by another agent, and the server record will not update the Directory information.

    "MISSING REQ DATA" - the server user database record is missing information and the user's record will be marked as "expired" in the Directory. This will definitely cause a problem for the user especially if the user is also using the Classlist Service. You can use the "Update" option to correct the user's record. If this doesn't fix the problem, you can get help by contacting email-help@isc.upenn.edu

    "INSERTED" - this is a new record that has been added to the online Directory.

    "RECORD_NOT_FOUND" - Instead of creating the PennCard record and PennID, the bulkload process will skip loading the record for anyone who doesn't already have a PennCard record and PennID. A user must already have a PennCard record to be loaded into the Online Directory. If your user doesn't already have a PennCard, he/she will need to contact the PennCard Office about getting a PennCard. For more information, please see http://www.upenn.edu/penncard/obtaining.html

  2. PennCard ineligible server accounts - This is a list of users who may be ineligible for a server account based on the user's PennCard record. This report is used as the basis of annual account deletions. A student is eligible for an account on the server if the current PennCard record shows a valid school code and the PennCard is not expired. This report lists the reason for ineligibility, the username, SSN, school code at the time of creation, permitted field and any comments from the server database record.

    Students who appear on this report will be considered for system-wide account deletions if they have not been permitted. This report will list students who are permitted despite meeting the ineligibility criteria as this will give the administrators an opportunity to review whether the student should continue to be permitted to have an account on the server.

    Students may appear on this report for the following reasons:

    "no identifying number" - the server user database record does not contain an SSN or PennID and therefore we could not verify the user's eligibility.

    "invalid school code" - the PennCard school code is not one of the valid school codes.

    "expired [date]" - Although the user may have a valid school code in the PennCard record, the PennCard has expired.

  3. Annual Deletions: The server database records of all accounts that were deleted in last annual deletion.

BROWSE

Used to browse through the server user database. To search for a string, you must specify in which field you want to search. Tab to the field you want to search and then type your search string. Browse will retrieve and display the entire user record from the server user database that contains the search string if you are an administrator for that user. Otherwise, you will see a summary of that user record.

When browsing through multiple screenfuls of records the following commands may be used to move around quickly:

n(ext) - to scroll down one screen p(revious) - to scroll up one screen e(nd) - to jump to the last screen of entries h(ome) - to jump to the first screen of entries q(uit) - to exit out of the browse routine and back to Accountmgmt b(rowse) - to enter a new search string

A status bar (like [95% (231 lines) remaining]) will be displayed at the bottom of the screen indicating what percent of the listing and how many lines exist below the screen you are currently viewing.

CHFN

Traditionally, "CHFN" stands for "change full name" and is used to change a user's full name and other personal information that is stored in the passwd database. You must supply the username of the account as an argument to this option.

CHFN will allow you to change the full name of the user. This information is used by the "finger" command and also used by other applications on the system like the "vacation" command. The full name is used by mail clients like Mutt and Pine for the full name of the user that appears in the mail header.

PASSWD

Used to change the local password of an account that is set to basic security. You must supply the username of the account as an argument to this option. When changing the password for a user, do not use email to transmit the new password. It is far safer to give the new password to the user in person or by phone, if necessary.

This program calls the system "passwd" program which will allow you three chances to pick a secure password for the user. Because of our stronger password vetting rules, we will call the system "passwd" program three times, thus giving you three opportunities to pick a secure password for the user. After every failed attempts to pick a secure password, you will be offered an opportunity to:

  1. review some rules for selecting a secure password
  2. choose to try again
  3. abort choosing a new password for the user

Please remind your users that they should not give their passwords to anyone including an administrator.

It is always a better idea to let the user change the password for his/herself. Exchanging passwords with a user in a secure manner can add delay to allowing access to the account for the user.

If the user knows the current password, he/she can login into the server and just type "passwd" from either the MAIN MENU or UNIX prompts. The user will be prompted for the current password and then prompted to type the new password twice.

If the user doesn't know the current password, the user can still change the password if he/she knows his/her PennKey/password. The user can use our Account Services web interface to change the local password at: http://pobox.upenn.edu/webmail The user should make sure the "Account Services" radio button is selected and then authenticate with their PennKey/password. If they are validated, they will be presented with a menu of options, including one to change their server password.

Please note that an account which is using enhanced security over basic security does not have a local password set, and therefore cannot be changed.

FORWARD

Used to set a forwarding email address for an account that has been deleted. You must supply the username of the account as an argument to this option.

You can only set a forwarding email address for a fully deleted account. You cannot set a forwarding email address for an active account. The owner of the account can set his/her own forwarding address by typing "forward" at the MAIN MENU prompt and following instructions. The owner may also use our Account Services web interface to setup forwarding at: http://pobox.upenn.edu/webmail The user should make sure the "Account Services" radio button is selected and then authenticate with their PennKey/password. If they are validated, they will be presented with a menu of options, including one to setup mail forwarding.

You are given the opportunity to set a forwarding address for a disabled account during the disabling process.

UPDATE

Used to update the server user database. You must supply the username of the account as an argument to this option. You can change the full name, account type, user type, accounting information, PennID, SSN, login shell or permitted status. Update can also be used by account administrators to permit a user who is no longer eligible for an account and to store comments in the user's server database record.

If you opt to the change the full name, you will also be asked if you want to run "chfn" for the user. Please see "CHFN" below. Update will also give you the opportunity to change the account's type of security (basic or enhanced). Information on these two types of security can be found at:

http://www.upenn.edu/computing/email/service-descriptions.html

For account administrators, you will be given two choices for the permitted field, either your administrative department or "N". If you wish to permit the user, type in your administrative department. Permitting the user will allow this user to have this account indefinitely. A permitted user is not considered when determining which accounts should be deleted during the annual deletion process. The administrator must either manually delete the account or unpermit the user. If you wish to unpermit the user, type "N". Unpermitting the user may also result in your no longer owning the record so be careful when setting this flag. If the user is no longer eligible for an account on the server, it might make more sense to just disable the account. You will also have the opportunity to enter comments in or delete comments from a user's database record. "STATUS" will display these comments.

You can also either set an expiration date for an account or remove an expiration date for an account if it exists.

QUOTA

Used to change the quota for an account. You must supply the username of the account as an argument to this option. You will be shown the current quota assigned for the user and asked to choose a new quota.

Accounts are given 40MB of disk quota for their home directory on account creation.

You have the option of setting a temporary increase in quota. This temporary increase will not be written to the user database or in the Billing database and will be deleted after the specified period. You can only temporarily increase quota for up to 30 days.

CREATE

Point of service (POS) administrators are not allowed to use the create function and should request that the account administrator for their organization handle account creation.

Used by account administrators to create a new account. For individual accounts, you will be prompted for the user's PennID number.

For student account creation, this option will retrieve the PennCard record and search for a valid school code. If the new user does not have a valid school code, you will be asked if you wish to permit the new user.

You will be prompted to set a password for the new account during the account creation process.

You can opt to create an account and set an expiration date for the account. If you set an expiration for the account, a mail message will be sent to the user warning them of the expiration date and an entry will be written into the deletion field of the user database with the expiration date, prepended by ">", e.g., ">Jun 30 2001". The process that weekly deletes disabled accounts will also check to see if an account has an expiration date. If it is 30 earlier than the expiration date, this process will send out a warning message to the user that the account will be deleted every week until the expiration date has passed, at which point the account will be deleted.

Student accounts are automatically deleted through the annual deletion process and it is not necessary to set an expiration date for a valid student.

BULK

This option allows account administrators to bulk create accounts on the server. Users who do not have a PennCard record cannot be bulk created. This option is only available through the command-line version of accountmgmt.

If a user already has a registered PennName, we will use that PennName as the username on the server. Normally, a user will already have a PennName if they have registered for a PennKey.

If a user does not already have a registered PennName, this process will automatically register the first available appropriate username as a PennName for the user. This PennName will then become the single name-space associated with the user across campus systems including PAS and will be assigned as the username on the server. Although the PennName automatically chosen will be based on the user's name, it might not be what the user might have chosen for his/herself but PennNames cannot be changed once assigned.

Before using this option, you must first prepare a file containing information on the users for whom you'd like to bulk create accounts. The information should be in the following format:

123456789:Firstname M Lastname

where "123456789" is the PennID of the new user. Only one entry must be written to a line. Create this file and store it in your home directory. You will be prompted for the name of the file.

The system will create passwords for your bulk accounts. You will also be asked if you want to force the user to change passwords. If you opt to have the system force password changes, the user will have to change the system generated password the first time that the account is used. We recommend opting for the forced password change and we may require this forced password change in the future.

Rather than exchange system generated passwords with the user, we recommend that the user change his/her own password. The user can telnet to the server with the username, "new" and set his/her own password once the account is created.

The activity from your bulk creation session will be appended to a file in your home directory called "bulkload.log". You can examine this file to understand why an account was not created. Look for these error messages in your copy of "bulkload.log":

"123456 not a PennID or SSN" - The first field in your input file must contain either an 8-digit PennID or a 9-digit SSN. Your file has the wrong number of digits.

"abcdef is not an identifying number" - The first field in your input file is not a number. You may have typed the wrong filename when prompted during the bulk creation process.

"123456789 has no PennCard record" - We do not bulk create an account if we cannot find a PennCard record for the identifying number. You can manually create the account and PERMIT the user.

"123456789 not in Pobox schools" - According to the user's PennCard record, the school code is not one of the eligible school codes. We will only bulk create accounts for users with eligible school codes. You can manually create the account and PERMIT the user.

"123456789 found in Pobox database" - The user already has an active record in the server user database associated with the identifying number supplied. This should indicate that the user already has an active account on the server. You can do a STATUS on the identifying number to confirm.

"123456789-[username] found in Password file" - The username assigned by PennNames already has an active account on the server. This error indicates that there is a conflict somewhere. Either there is a PennNames conflict or a conflict between the server user database and the system Password file. STATUS or the UNIX finger command will help you to investigate but you may need to contact the ISC administrator for help.

"123456789-[username] found in System aliases" - The username assigned by PennNames is already a system alias. You will need to contact the ISC administrator to resolve this conflict.

"123456789 lockfile detected" - An account is already being created for this user. Either the user is trying to create his/her own account as user, "new", or some other administrator is trying to create an account for this user or there has been a problem with your bulk creation process. If the latter, please contact the ISC administrator for help.

"System Error, password was not set for 123456789" - If you have asked that the program generate passwords for your accounts, the program will try to create a secure password that is acceptable to the system but the program can fail to create a password that passes the system's password vetting rules. When this happens, the account will be created but you will have to go in manually and set a password for the account.

A list of the accounts that were created will be written to your home directory. The contents of the file will be

123456789 Firstname M Lastname username password

where "123456789" is PennID that you supplied. The file will have the same name as your input file with a ".rpt" extension. If your file of user information is named "test.load", the report file will be named "test.load.rpt", e.g.

If the same budget code is being used for all accounts that need to be created, a POS on Pobox can prepare a bulk creation file as described above and send a request to pobox-admin@isc.upenn.edu requesting the bulk creation of accounts. Please include the location of the file and budget code.

DISABLE

Point of service (POS) administrators are not allowed to use the disable function and should request that the account administrator for their organization handle account disabling.

Rather than deleting accounts immediately, this option allows an account administrator to "disable" the account for a specified period before actually deleting the account and files associated with that account. You must supply the account username as an argument to this option.

You will be prompted for the number of "grace days" to be assigned to the user. During this "grace" period, the account and all files associated with the account will remain on the system but the user will not be able to use the account and any mail sent to the user will be bounced back to the sender unless a forwarding email address has been supplied.

The purpose of this procedure is to provide the means to easily recover an account if it has been determined that the account should not have been deleted.

An account that has been disabled and all files associated with that account will be deleted on the first Monday after the grace period has expired. We will not be able to recover any files after the grace period has expired.

When disabling an account, you will have the option to set an email forwarding address if one is available. This address will be removed if the account is reinstated and will not be stored anywhere else.

You will also have the option of turning on autoreply and setting an autoreply message. If autoreply is turned on, a message will be sent to any user who sends mail to the disabled account. The system will send the contents of a file in the user's home directory called, ".autoreply". If that file doesn't exist, the system will send a system default message. Through this option, you can create an autoreply message that will be written to the user's .autoreply file and will overwrite any existing .autoreply. This autoreplying will only be in effect during the disabling period. Once the account is either reinstated or deleted, autoreplying will be removed.

When an account is disabled, the deletion date field of the user's server database record will be updated with the date of the disabling. An asterisk will follow the deletion date to indicate that the account is only disabled. When the account is deleted from the system, the asterisk will also be deleted but the user record will remain in the server user database for future reference.

Student accounts are automatically deleted annually based on the expiration date in the user's PennCard record.

REINSTATE

Point of service (POS) administrators are not allowed to use the reinstate function and should request that the account administrator for their organization handle account reinstatement.

Used to reinstate a disabled account. You must supply the username of the account as an argument to this option. This option will immediately enable the account and the user can again access the account with the last password assigned. Any forwarding address supplied during the disabling process will be removed and the deletion field in the user's database record will be cleared. If autoreplying has been turned on, autoreplying will be turned off. This option will not delete the .autoreply file in the user's home directory if one existed.

You can only reinstate an account when it is disabled. Once an account has passed the specified grace period and has been deleted, you must create a new account for that user.

HISTORY

Used to display the recent administrative activity for an account. Valid arguments to this command are the username or PennID number. The activity for an account displayed consists of the date of the activity, the username of the administrator that took the action, the action taken and the result of the action, including success and failure messages.

ACCESS

Used to add or remove shared Kerberos access for an account. You must supply the username of the account as an argument to this option.

This option will add or remove an entry in the user's .k5login file. When using this option, the administrator will be prompted for the username that they would like to add or delete access to the account for. Once the username is entered, the administrator will be asked if access to the account should be added or removed for that user. Access to a user's own account may be added using this option, but it may not be removed.

ADMIN

Used to display the list of administrators for your organization and to request the creation or deletion of administrative privileges for a user. When requesting the creation of administrative privileges, you will be prompted for the username of the person to be authorized. All administrators must have an account on the server.

You will be prompted to select what kind of administrative authorization you wish to give to the user - either full administrative or POS privileges.

Your request to grant administrative privileges to a user is mailed to the ISC administrator. You will receive an email response when your request has been fulfilled, usually within two working days.

ANNUAL ACCOUNT DELETION

For student accounts, during the first week of October, we bulk delete accounts for users who are no longer eligible for an account. We cull our list of accounts to be deleted from the Ineligible Pobox Account report above. Any user who has an expired PennCard or whose PennCard record does not contain one of the participating school codes and who has not been permitted will be deleted.

Beginning in August, you should start to review this list of ineligible accounts to see who has been permitted but otherwise would not be eligible for an account. This is a good time to review whether the account should continue to be permitted. After September, this list will grow considerably since it will then include May graduates whose PennCard expired on August 31 after graduation.

Beginning the second week of September, we will start to send notices to users whose account will be deleted. These users will receive 4 notices before the account is deleted and will be advised to contact the school computing administrators if their account should not be deleted.

The administrator should first do a VERIFY to determine if the user's status has changed since the mailing of the deletion notice. If VERIFY shows a future PennCard expiration date and a correct school code for the user, the student will not receive any more deletion notices and no further action is necessary.

If verify shows that there is still a problem, the administrators should work with the student to correct the problem. The student can go to the PennCard Center to have their PennCard updated if the expiration date is incorrect. If the school code is incorrect, you must work with Student Records to correct the problem.

If all else fails and you want to prevent the deletion of the account, you can permit the user by using the UPDATE menu option. Permitting the user should only be done as a last resort. If you permit the user, this will take the user out of the normal administrative path and will allow the user to have an account on the server indefinitely. It will be up to the administrator to determine when a permitted account will be deleted. A permitted account will only be deleted if the administrator manually deletes them or unpermits them, thus putting the user back into the normal administrative path.

If a user whose account is slated for deletion wishes mail to be fowarded to another account, the user should create a .forward file in his/her home directory or type "forward on" at the MAIN MENU prompt. We will forward mail for a deleted account for three months.

The bulk deletion process, just like the manual deletion process, actually disables the account and keeps all user files on the system for 30 days after the deletion date. If an account has been mistakenly deleted, you can use the REINSTATE menu option to restore the account for 30 days after the deletion date. Once this grace period has passed, there is no way to restore the account although you can create a new account for the user.

EMAIL ADDRESS DOMAINS

The domain of an email address is everything that comes after the @ symbol in the address. For example, in "joeuser@pobox.upenn.edu," the domain would be "pobox.upenn.edu".

The ISC email server hosts several domains, including:

Which of these domains a user has assigned to their email address depends upon the organization that they belong to. While all users will receive a pobox.upenn.edu domain address, a Med school student, faculty or staff member will also receive a mail.med.upenn.edu address. In that case, both username@pobox.upenn.edu and username@mail.med.upenn.edu will be active for that user, and the same mailbox will receive mail for both addresses.

Students will also receive a dolphin.upenn.edu domain address in addition to their pobox.upenn.edu address and any other addresses they are eligible for.

If a user has a need for an additional domain address, a request should be sent to: email-help@isc.upenn.edu

There is no functionality in account management to enable or disable these domain addresses.