The following list is good practice regardless of the conditions of the tech's departure. In the case of a firing, these are all the more important, and will require more planning.

Basic Authorization

• change basic usernames & passwords for all services above.
• ensure that the emails for all services above are valid and pointing to your new techie or a generic tech account.
• contact service providers and ensure that they all have the new contact name, phone number and email.
• tell your clients that the departing techie is no longer working there.

Company Resources

• back up and then delete the techie's email and other files.
• you'll want to close down their email account and set up an alias so that future emails are forwarded to either an auto-responder or the techie's successor. Anyone can send an email spoofing that it is from this email, but you usually don't want an employee being able to respond to company emails. There may be an alias set up forwarding the email to a non-company email account.
• remove the exiting tech from any company mailing lists, irc channels, and billing or time-tracking software / services
• remove them from any remote-access accounts (VPN networks, Remote Desktop, dial-in modems, etc.).

Server/Network

• disable (and eventually delete) the departing tech's personal account.
• change root passwords.
• audit user accounts (especially for ssh and sudo access).
• audit cron and at jobs.
• audit file ownership (ie. for suid root executables or files without owners).
• audit daemons / services.

Domain Names

• ensure admin/tech contact info is set to successor or generic company email.
• you can find out what your admin email address is by going to DNSStuff.
• change passwords.

Web Hosting

• make sure that you have a new person listed as the technical contact with your ISP, if the site is on shared/virtual hosting. This may need approval or action on the part of the client.
• change as many passwords as it is practical to change (note that changing database passwords will often require changes to web site configs).

Email Hosting

• change admin passwords.

Mailing Lists

• change listmaster password.
• change as many list passwords as is practical.

Databases

• change root passwords, and as many non-root passwords as possible.

Backups

• verify that they are running appropriately, and that archives exist and are capable of being extracted successfully.

3rd Party Services

• change passwords.
• ensure contact info is directed at the successor or generic address.

Reports

• change email addresses for reports and logs.
• change passwords / encryption keys for remote logging and monitoring services.

Troubleshooting

If you don't get the required usernames/passwords, or if they don't work when you try to login, you can often do the following to regain access and restrict the departing employee's access.

Domains

• usually you need to go to the registrar and send them extensive proof that you are the lawful owner of this domain name. If there is a dispute about ownership this could get messy.
• remember the tech contact email is pretty useless, it's all up to the admin email address these days.

DNS Zone Files

• if you control the domain you can always mirror the existing zone file and switch it to another provider.

In-house Servers

• if the root password is unknown, you will have to reset it from single-user mode or, if that is also password-protected, by rebooting the computer onto a CD or USB filesystem and changing the root password manually.

Dedicated/Virtual Server Administration

• your hosting provider may be able to reset the root password if you don't have one that works.
• if you've got root or sudo access you can usually reset passwords for any databases, mailing lists, apache permissions, and so forth.

Web/Email/Mailing List/3rd Party Services

• your hosting provider will be able to reset the passwords if you do not have them. They will often listen to who pays the bills, which might mean bringing in the client or ensuring that payments are made on a company credit card or account.

Application Level

• audit who has access to which accounts on all applications, especially those with admin access.
• hopefully you will never have to audit the site's code to ensure that secure files are not being sent to an unauthorized source. In most instances this isn't something that is a concern. If it is, however, it may be best to set up everything fresh on a new server.

Other Useful Links

• http://www.freelancecomputers.com/are_you_doomed.htm
• http://del.icio.us/tag/sysadmin+security
• http://www.usenix.org/publications/library/proceedings/lisa99/full_papers/ringel/ringel.ps
• http://www.eits.uga.edu/wsg/sun/security/vatech_sunos_list.html