IBM i Security Basics – Implementation

By Rich Loeber

In my last blog, I wrote about how to create a security policy for your IBM i.  This time, I’ll take a broad overview look at how to best implement your policy on your IBM i.

Some of your security policy will be implemented globally through the setup of your IBM i system values.  Much has already been written about this and is generally available from this website and others.  I do not want to duplicate that.

What is unique to each application, however, is the object level security setup that protects your basic data and programming elements.  This is what I want to explore here by reviewing a few key practices that, over time, will simplify your security administration task.

The first of these key practices is implementing your object level security based on group profiles.  Security can be implemented by individual profiles or by groups.  Each user profile on your system can be assigned to a single group along with up to fourteen supplemental groups.  A group profile is nothing more than an additional profile that is defined to your system but is set up so that it cannot be used for logon purposes.  Its only purpose is to control object access.  Once a group profile has been created, you can then add individual profiles to the group by placing the group profile in the GRPPRF (Group profile) field or in the SUPGRPPRF (Supplemental group).  With group profiles implemented, you no longer have to create object access rules for each profile, just for the group profile.  By reference, the rules for the group will then apply to each individual user profile that is included in the group.

With your security policy document, check it to identify the specific groups that you are going to need and get them set up on your system.  Then, code the individual users into each group.  When people leave the company, you will not have the issue of having to get all of your security setup modified.  Plus, adding a new user profile will be greatly simplified by not having to maintain an extensive set of individual object accesses.  When you are all set up, you can generate listings for each group using the DSPUSRPRF (Display User Profile) command with the *GRPMBR option.

The other key practice that I want to discuss today with your security implementation is the use of Authorization Lists for object security.  An individual object can be controlled by entering profile information directly associated with the object or by reference to an Authorization List.  When you store your profile access rules directly with the object, then you cannot make updates to these rules when your object is in use.  Using Authorization Lists, however, removes this obstacle and saves you from a lot of late night sessions.

Also, with an Authorization List, you can create a single security configuration that can then be applied to multiple objects on your system.  At the individual object level, just reference the Authorization List and the rules created in the list will apply to the object.  From your security policy, you will find general rules that apply within an application.  These can easily be assign to an Authorization List.

But, you ask, what about exceptions?  Every security policy is going to have exceptions and you can deal with them as they arise.  I try to discourage them by asking that a clear business case be made for each exception.  The response, “well, it would just be a lot easier” is no longer acceptable.  Those kind of exceptions these days can easily lead to banner headlines that will be embarrassing to you and to your company.

If you have any questions about anything included in this tip, you can reach me at rich at kisco.com,  All email messages will be answered as quickly as possible.

IBM i Security Basics – Policy

By Rich Loeber,

If you are a security officer for your IBM i, then securing databases on your IBM System i is your primary responsibility.  Good security starts with a clearly defined policy.  This tip will help focus on how you can create this policy.

Before you start creating a security policy, you will have to get your user community involved.  A security policy created and implemented without end user participation is destined to always be a problem.  If your end users, however, are asked to participate and buy into the policy, then the results will be a much smoother implementation.  If you find resistance to participation in policy creation, get management on your side.  Whatever you do, don’t create the policy on your own as an IT project.

The first decision you need to make when formulating your security policy is what your overarching objectives are going to be.  You have two choices at this point:

  • You can decide that your policy will be very strict
  • You can decide that your policy will be relaxed

With a strict policy, access to every object in your system will be determined and enforced at the operating system level.  Each user’s specific requirements will be analyzed and then encoded in the security implementation provided by the IBM i OS.  With a more relaxed approach, you can decide that users will have broader access to objects on your system with strict access rules only for certain pre-defined data assets.  In actual practice, most IBM i shops adopt the second approach, but your auditors will love you if you go for the first one.

Once you’ve made this decision to your general approach, then proceed to make a list of the applications on your system.  For each application, you will need to define the owner of the application.  This will be the person who will have to make final security decisions.

Within each application, you should then list the data assets created and used by the application with a note on each one as to it security status.  Some applications will need little or no security while others will have very strict requirements.  Make sure that your users are in full agreement about the nature of each data asset and its security requirements.

When deciding on the security requirements for each asset, there are three things to consider:

  • Is this information that should be restricted from all employees?
  • Is this information that is critical to the way you do business?  Does it give your organization a competitive advantage in the marketplace?
  • Is this information crucial to your day to day operations?

Obviously, payroll falls into the first category and is the classic data type for this consideration.  But, you may have other data assets that also come into play.  Included in this would be any data assets that record credit card information, banking information or any other personal identity information for your employees or your customers.

An example of the second data type would be a Customer Master database or a Contact database.  These are compiled databases that clearly help you to do business and that you do not want falling into the hands of competitors.

Finally, an example of the last type of data asset might be your month to date sales database or your current accounts receivable.  These are management tools that are needed to maintain your day to day business operation.

With each of these assets defined, you can then describe the type of security that you want in place.  When you are all done with each application, have a final review and signoff by the user (or owner) for each application.  Only after this legwork has been done can you consider how to best implement the security requirements.  More on that step soon.

If you have any questions about anything included in this tip, you can reach me at rich at kisco.com,  All email messages will be answered as quickly as possible.

Are You An Accidental Security Officer?

By Rich Loeber

How can you be a more effective security officer given that you probably are in the job completely by accident?  This tip will explore this idea and provide some suggestions for you.

Computer Security, as a specialty, is still fairly new.  Chances are, you did not get into this field by taking it as a major in college or going to a technical school and specializing in the field.  As I look back over my career, I can recall lots of people who ended up working in various segments of IT who came from some of the wildest original intentions.  One guy I worked with came from a background as a pitcher for the Pittsburgh Pirates followed by a long career as a plant manager for a chemical plant.  Another started out in college to be a psychiatrist.  For my part, I never even went to college but got started in IT right out of high school working as an input/output control clerk.  I suspect that we are all “accidental” security officers.

So, how do you become an effective security officer considering that your training and education probably did not prepare you for it?  It’s a very good question to ask yourself.

I recently published a couple of tips about how to learn the security officer position.  I encourage you to check these two articles out, Learning To Be A Security Officer and Learning …. Part 2, as a starting point.  But, for today’s consideration, you need to do some introspection before heading out to become a better security officer.

A lot depends on what you did prepare for in your career.  If you prepared to become a programmer, then you probably don’t need to concentrate on the programming aspects of the security officer function.  In fact, you may have a tendency to stick with these tasks because they are most familiar to you and you are very comfortable with them.  It is a fact of human nature that we tend to go where we are appreciated and where we can demonstrate competency.  So, if you find yourself hanging around where you already know how things work …. it is time to move out.

To become an effective security officer, you need to back fill the areas of learning that you never prepared for in the first place.  This is where the introspection comes in.  For my part, I started out as an application programmer.  When I got to the whole area of security, it was a new arena for me and I found that communications and networking were my weakest spots.  I still have trouble fully understanding how TCP/IP works and how to really secure it so that it is foolproof (if that is even possible).  Worse, the people who do know how TCP/IP works all appear to speak a foreign language that is liberally peppered with three and four character acronyms that I’m supposed to know the meaning of.

Once you’ve identified your “weak” area or areas, then you need to identify resources that can help you to understand concepts and strengthen your security consciousness.  I always try to start by finding a peer or an associate who knows that stuff and pick their brain.  Then, I see if they can give me recommendations on reading materials, websites and publications that can help.

I also have to confess to you that I am still a reader of technical manuals and IBM Redbooks.  Having them all on-line is a real benefit these days and when I have spare time, I will often go browsing in the manuals library to find what’s new and see things that I haven’t read before.  I know that the manuals can be pretty dry reading, but they really do contain the manufacturer’s explanation of how things are supposed to work.

I’d love to hear from you if anything here strikes a chord with you.  Do you have an unusual story of how you ended up as an accidental security officer?  Send it in.  You can reach me at rich at kisco dot com,  All email messages will be answered as quickly as possible.

How Much Security Is Too Much?

By Rich Loeber

Last time, I posed the question “Just how much security is enough security for your IBM i?”  This tip will explore the contrary thought of “Just how much security is too much?”.  Is there a point where security is just too much for your installation?

First, we need to admit that all security involves overhead expense.  If you are running security software features in the operating system, they take some computing resources to perform access validation routines.  When you run additional security validation, such as exit point processing, that adds more processing overhead.  When you require users to regularly change their passwords, that requires time every so often on the part of every user on the system to reset their password to a new value.  When someone has a problem during the normal course of their business day that ends up being related to security, this is additional overhead not only on the part of the end user but also by your support staff.  No matter how you look at it, good security costs money.

But, is there a point where you have too much security and the benefits are outweighed by the security protection deployed?  I think the answer is a clear yes, in certain circumstances.

Some time ago, I did a consulting gig for a large company located in North America.  This company had a very aggressive security implementation for outside vendors.  And, they apparently use a lot of outside vendors who need access to their network.  They had a complicated VPN installed which required a remote token generator be shipped to me.  When the token arrived, it included indecipherable instructions on how to gain access which ultimately did not work.  It was a long and drawn out process, but it ended up taking me three days and countless hours of trial and error with various members of their support desk team to get access to their system just to get started on a project that was behind schedule at the outset.  Once I got into their IBM i processor, I found that my profile had not been properly set up and there was a further delay in getting started.

In this case, the costs associated with the security implementation became excessive.  I was on the clock for this entire experience and the customer ended up paying dearly for this wasted time.  For this customer, I’d conclude that too much security was in place or that the security deployed was insufficiently funded.  The whole point was to provide a secure signon to their IBM i from a remote location, but the number of layers needed to get through was just too much.

When is there too much security?  One check is to see if normal business transactions are regularly stopped due to security checking.  If people in your organization can’t get their normal day-to-day work done due to security hurdles, then maybe there is too much security in place and a review of your setup is in order.

Another check is to see if your support costs are on budget or running way over.  If you’re spending significantly more money on support and that can be traced to security issues, that’s another red flag that something is quite wrong in your security environment.

I know that some of you security officers out there are going to cringe at this, but security is always a compromise between operating efficiency and data integrity.  You need to have a good balance, tempered by an honest assessment of what you’re protecting.

If you have any questions about this topic you can reach me at rich at kisco.com,  All email messages will be answered as quickly as possible.

How Much Security Is Enough?

By Rich Loeber

Just how much security is enough security for your IBM i?  This tip will explore this question and, hopefully, get you thinking about your own environment.

In the good old days, enough security meant that you had a lock on the computer room door and you actually used it.  Keeping people out of the computer room was all that was necessary.  Then along came CRTs and cabling started reaching outside the computer room environs and security became more of an issue.  Someone came up with the idea of requiring a CRT user to log into the system using a user identifier and a password.  With that little invention, things seemed to get back under control.  But, before long, along came PCs followed closely by client/server applications and then the Internet.  Now what do we do?

For many shops, a strict reliance on the user profile and password is still the watchword of the day.  But, is that enough given today’s technology?  I think not.  The problem with today’s networked environment is that you can never be absolutely certain who is at the other end of the line.

But, what is enough?  The concept of the Firewall has captured the hearts of many security officers to address this issue.  In fact, for many companies, the firewall is the be-all and end-all of their security plan.  “We’ve got a firewall in place!” …. case closed.  But, is that enough along with your user profile/password implementation?  Again, I think not.  Multiple studies of computer break-ins and data compromises reveal that fully half of all such incidents are inside jobs committed within the boundaries of the firewall “protection”.

What you really need is a multifaceted approach to security.  You need passwords, a firewall, and more.  In the old days, if the bad guy could get into the computer room, he could do some damage.  But, if you had multiple doors with multiple locks, it would take him longer to break in and you’d have a much better chance of catching him in the process.  In a way, today’s environment needs to be thought of in this same way.  Relying on a single security defense is just not enough today.  You have to deploy multiple defense strategies to be successful.

For your IBM i installation, this should include all of the security tools that are at your disposal.  It means implementing object security based on a coherent company-wide policy.  It means strictly limiting those profiles that have all object authority.  It means implementing exit point security with object level controls there as well.  It means controlling which IP addresses you are going to trust and allow access into your system.  It means having a good user profile and password maintenance plan in place with regular rotation of passwords.  It means quickly rescinding access rights for people who leave or change job assignments.  And the list goes on and on.

I suppose that it is a true statement that no computer system is 100% secure.  But, if you build enough fences that have to be climbed and add enough doors that have to be unlocked, the result will be as secure a system as is possible.  What you don’t want to do is make it easy, which unfortunately is all too common in today’s IT shops.

If you have any questions about this topic you can reach me at rich at kisco.com,  All email messages will be answered as quickly as possible.

Watch Out For FTP “Script Kids”

By Rich Loeber

Some time ago, I wrote about the dangers of having an open FTP server running on your IBM i.  At that time, I advised that FTP was a clear point of potential entry into your system by persons with malicious intentions.

Since then, I’ve been observing repeated attack attempts on my personal IBM i in my office and I’ve identified a particular type of attack that has me worried.  It is what is called a “Script Kid” attack.  It is called this because the attack is mounted using an FTP script so it can be repeated over and over again on any target.  The word “Kid” is used because it is so easy, even a child could mount the attack.

Typically, a “Script Kid” attack will repeatedly attempt to log on to your system using a well known profile name.  Fortunately for IBM i security officers, the most common profiles used by the Kids are ADMIN and ADMINISTRATOR which are very popular profiles in the Unix world.  Good news for us as these attacks will generally get nowhere on the IBM i.

However, not all Kids stick with this basic attack form.  One that worries me a lot happened a few weeks ago and is the event that prompts this writing today.

This Script Kid started signon attempts through FTP using common first names.  Each name made 3 signon attempts, each using a different password.  I’m sure the script called for commonly used passwords such as “password”, “security” or the same value as the user profile.  Scanning through the log of rejects for this attempt, I see a very comprehensive list of first names used such as ABBY, ABIGAIL, ABRAHAM, ABUSE, ACCOUNTS, ADAM, ADRIAN, ALAN, ALBERT and so on.

On the surface, this attack pattern seems like it would fail miserably as long as you have good password policies in place.  And, as far as preventing access to your system, this is a true statement.  However, this kind of attack could have a devastating impact on your system by cycling through commonly used profiles and causing them to be disabled by the operating system.  Most IBM i shops allow for three logon retries when an incorrect password is entered.  After the third attempt, the profile is disabled and can only be reactivated by a security officer.  You could easily find yourself suddenly inundated with requests to reactivate disabled accounts all over your shop, bringing work on your system to a halt.  (For password resets, our iResetMe software can help.)

So, how can you defend against this type of attack?  For me, on my small test machine, I just shut down the FTP server when I saw the attack start up.  But that is not an easy option for most of you.  In my shop, I intentionally set up a phony profile on the system with the user profile of “ADMIN”.  I set it up to disable on the first bad password attempt and I designed the profile in such a way that it could not be used to gain access regardless of whether it resulted in a successful logon or not.  Then, I had our system monitoring software (we use our own SNDWEET for this), watch for messages in the QSYSMSG message queue.  When I am texted that the ADMIN profile has been disabled, then I know that an attack is under way.

The best solution is to have profile names that are uncommon.  Don’t use first names for your profiles.  A good solution is to pick profile names based on a combination of first and last name.  For those accounts that come with your system from IBM, the infamous Q profiles, make sure that none of them are used for regular production purposes.  You should keep these profiles on your system in a disabled state.  Sooner or later, a Script Kid is going to get around to putting QSYSOPR, QUSER and QSECOFR in their list of profile names to try.  You should also keep a backup security officer profile available in case QSECOFR gets disabled.  Finally, and I’ve said this many times before, never allow a profile to be created on your system using the default password.

If you have any questions about this topic you can reach me at rich at kisco.com,  All email messages will be answered as quickly as possible.

Learning To Be A Security Officer – Part 2

By Rich Loeber

In a recent post I started a description of how you can learn the job of being a security officer in the IBM i world of computing.  This post will continue that thought by talking about how you can effectively use a security consultant, and learn from them in the process.

In the first post I talked about the need to read and to stay current with technology.  In addition to what I mentioned in that post, I also want to recommend to you the book “Inside Internet Security: What Hackers Don’t Want You To Know” by Jeff Crume.  I found a used copy at Amazon.com.  It is a real eye opener for those of you who have only been thinking about the IBM i side of the security question.  The book is a little dated, but still contains a lot of good information that is clearly presented without a lot of acronymic netspeak that can be so confusing.

But today I want to talk about using a consultant.  The classic definition of a consultant is “someone who borrows your watch to tell you what time it is”, and to a certain degree, this is true.  But a good consultant will explain to you every aspect of your situation.

The best way I know of to tell you about using a consultant is to describe a situation from my past.  I had been working for 20+ years as a programmer, systems analyst and IT manager when I started consulting for a local direct marketing company.  I was there for about 6 months trying to address the multitude of issues that this fast growing company was experiencing.  The owner decided to bring in an expert and found a guy for $2000 per day (plus expenses, a fortune at that time) to spend a day with us.  We cleared our slates, got several key people together and followed the expert around for the day as he walked through the entire operation.  What an eye opener that was.  In one day, we identified every issue that needed to be fixed, quite a long list.  We turned this into a roadmap of sorts and started knocking items off.  That one day visit ended up changing the entire course of the company for the next 10 years.  It was more than worth the investment.

A security consultant should be able to do this same thing for you.  But you need to use the consultant effectively.  This starts by selecting a qualified person.  Develop a list of people from reliable sources.  Then check references to make sure that you’re getting what you need.  Once this is done and a date has been set, make sure that you have everyone needed completely available.  When the consultant arrives, the clock will be ticking and if you’re off doing something else, it will be a waste of time and your company’s money.  Clear the decks completely.  Don’t even take phone calls or check your email or texts.

While the consultant is with you, be completely honest with them.  If you hide things because you’re embarrassed by them, then your feedback from the consultant will be incorrectly skewed.  Go through everything that you’re doing and take copious notes on what the consultant has to say.  You’ll be amazed, if your consultant is good, at what you find out and you will learn to do a better job in the process.

After the consultant leaves, don’t just go on with business as ususal.  Make a list of the areas that the consultant brought up that need attention.  Then, develop an action plan to get each item on the list addressed.  And, make sure you have the right attitude as you go through this exercise.  The objective is not for you to come out looking good (which is often the case when reacting to an audit), but to address security exposures and get them closed.  Most consultants appreciate followup, so don’t be afraid to get back in touch with the consultant with questions and clarifications after the initial consultation.

That day we spent with the consultant completely changed my understanding of how a direct mail company should operate and it has stayed with me.  Your investment in a security consultant will do the same for you and for your company.  Consultants are expensive, but the alternative of having security exposures, could not only be costly but devastating to your company.

If you have any questions about this topic you can reach me at rich at kisco.com,  All email messages will be answered as quickly as possible.

Hacking Report For Our IBM i – 2013 in Review

By Rich Loeber

In January of 2013 year, we issued our first Hacking Report for our IBM i system.  At that time, I promised to publish additional reports of what we are seeing on this test server.  This is our final report for the 2013 and I want to wrap of this one year experiment with our fourth quarter results and some observations about the entire year.

During the final three month period for 2013 we observed a hacking results that were remarkably consistent with the three previous quarters.  The bulk of hacking attempts mounted against our test server were once again in the area of FTP Signon and Telnet Signon.

Once again, someone knocked on the door of our test server 14 times a day trying to gain access.  This attack rate was remarkably consistent for the entire year.

Some interesting things to note ….

Thanks to our SafeNet/i exit point control software, we successfully thwarted 847 attempts to gain access via FTP and another 428 attempts to get a Telnet signon session during the final quarter of the year.   For the year, we was almost 4000 FTP hack attempts and just under 2000 Telnet tries.  The take home lesson is that you absolutely must take life on the Internet seriously.  Our server is small potatoes and does not have any high value assets on it, but hackers are there knocking at the door on a regular basis anyway.  I think it is just because it is there and they have been unsuccessful.

Brute force FTP attacks continued during the final quarter.  Once again, the profile named ADMINSTRA was the most popular one used.  In fact, this was true for each quarter during the year.  Other profile names used included ADMIN, REMOTE, SCANNER, SYS, BACKUPEXEC and WWW-DATA.  Once again, and this was consistent during the whole year, none of the typical Q profiles were attempted.

We also continue to see certain IP addresses with repeated access attempts.  The leading violator for the final quarter traced back to The RIPE network in The Netherlands.  The next two highest both traced back to the Asia Pacific Network Information Center in Australia.

For the full year, our server posted close to 1 million network transactions.  This is nothing in today’s computing environment, some of our customer’s servers can record that level of activity in just a few minutes.  But, taken as a whole for the year, 0.5% of those network access attempts were not authorized by us.  Hackers, you have to take them seriously.  Failure to do so will get you in the headlines as the next Target.

This will conclude our year of tracking hacker activity on our server.  If you have questions about details of the report, feel free to contact me directly by email (rich at kisco.com).

Learning To Be A Security Officer

By Rich Loeber

I have been asked several times recently “How did you learn so much about security on the IBM i?”.  In this tip, I will try to let you know how I got to this point and, perhaps, it will help you on your journey as well.

First, you have to remember that I have been working on computer systems since my first job as a data control clerk in 1965.  During that time, I’ve moved through just about every aspect of the computing field from data entry clerk, system operator, programmer, systems analyst, project manager, department manager, independent contractor and software developer.  All along the way, security issues have come up and had to be researched and dealt with.  So, I guess some longevity contributes to where I am today.  But, old age is not an option to a lot of aspiring security officers for today’s IBM i installations.

As I think back over this history, several concepts come to mind that have helped me strengthen my understanding of computer security.

First and foremost is reading.  I am, by nature, an avid reader.  Over the course of my career, I have found that reading is crucial to staying current on what’s going on in the field.  This is more true today than it has ever been since things are changing faster now than at any time that I can recall.

When choosing what to read, I’d recommend a holistic approach that includes general computing topics, IBM i specific topics and security topics.  In today’s world, this means reading magazines, Internet publications and technical manuals.

There are a few magazines that are still in print for the IBM i world, although it is hard to know how much longer that will last.  Almost all of their content, however, is available on-line at websites maintained by the publishers.  Some of these charge a fee for access, but the charges are not prohibitive and the content is generally well worth the price of admission.  These publications tend to focus on “what’s new” topics, but their archives are a good source of general information that you will find most helpful.

For security topics on your IBM i, there is nothing better than going to the source …. the security manuals that come with your system.  These are available on a CD that came with your system and also on-line from the “IBM i and System i Information Center” (http://publib.boulder.ibm.com/eserver/ibmi.html).  The current manuals for all supported versions of the operating system are there along with an extensive library on security topics.  You can’t find better details than looking at these documents from IBM as they tell you exactly how the designers intend for security to be implemented on your system.  I know, reading the manuals can be tedious, but they’re really not that bad.  When I’m writing a tip for publication, I often find myself mired in them to get the exact details of how something works, according to IBM.

Another good way to stay current on what’s going on in the IBM i security field is to participate in an on-line discussions forum.  For me, I like David Gibb’s “midrange.com” (http://www.midrange.com/).  You can sign up for quite a few different forums and then just sit back and monitor the traffic via email.  The group that participates is great at answering your questions and you can read what others are doing.  I’m amazed at how much I pick up just by monitoring the email traffic.

So, the first step in improving your understanding of security is reading.  One thing to remember is that reading takes time.  I have the luxury these days of being able to set my own schedule and I make time for reading a priority.  You will need to dedicate time during your busy week for this activity.  Failure to do so could leave you out of date.

If you have any questions about this topic you can reach me at rich at kisco.com,  All email messages will be answered as quickly as possible.

Rescinding Access Rights

By Rich Loeber

Most of the time, as an IBM i security officer, you are concerned with granting access rights to users.  To do this, you need to know what the user’s job responsibilities are and what they will be doing within the computing environment.  Based on existing security policies for your shop, you then configure security for each user so that they can get at the computing resources they need to do their job easily, smoothly and securely.

Once you have a user set up and running, however, I think they seem to fall off our radar since we’re then occupied with getting the next user(s) setup and configured.  You tend to address those areas where you have immediate demands at the expense of others.

One important thing to keep track of, however, are situations where access rights need to be modified or rescinded.  The most glaring situation is when someone leaves the company.  You should have a clearly developed plan of action to implement when someone leaves.  This plan should include:

  • Deactivating their user profile
  • Identifying any objects owned by their profile and reassigning them
  • Removing access rights for objects not owned by them
  • Deleting the user profile after all else is done

Just deactivating a profile is not sufficient.  Batch jobs can still be run under an inactive user profile and those jobs will still have rights to the object set that was defined for that user.  So, you must take the additional action of removing those access rights.  Rescinding access rights is just as important to a secure installation as granting those rights.

Chances are, your IBM i is currently sitting with loads of unnecessary access rights in place for people who are long gone.  Each one of those access rights is a potential security exposure and should be dealt with.  You should review the way the user was initially configured when their access rights were granted and then go through and reverse the process.

Making this work depends you being in the loop when someone leaves the company.  In a small shop, you normally learn this by word of mouth.  But, in any size shop, a formal notification process needs to be put in place to guarantee that inactive profiles are dealt with promptly.  This can be especially important if someone leaves on bad terms.  A firm procedure has to be in place with your HR staff and it must be enforced.

The other situation you need to be prepared for is when someone has a change in job responsibilities.  In this situation, you will not only need to grant new access rights for the user, but you will also have to backtrack and possibly remove some earlier rights that have already been granted.  Again, careful coordination must be worked out with your HR folks.  You are more likely to hear about this through less formal channels since the user will need to get reconfigured in order to start their new responsibilities.

If you have any questions about this topic you can reach me at rich at kisco.com,  All email messages will be answered as quickly as possible.