Deciding the meaning of 'disabling' an account (and the value of procedures)

July 29, 2011

One of the things that the challenge of disabling an account has made clear to me is that it's far from clear just what disabling an account means to different people. I think we can all agree that the user of a disabled account shouldn't be able to use any of your authenticated services any more, but as alluded to in my first entry there are a number of other things where it's not clear what should happen.

For example: should the disabled account still get email? Should their files remain visible and accessible to other users? Should their personal home page remain visible? Should they still be visible in your user directory, and if so should they be marked in some way? If they're the responsible person for local mailing lists, what happens to those?

(I'm separating this from the issue of completely disabling someone's access to your services even in the face of passwordless ssh access and the like.)

There's no set right answer to these questions. A lot depends on your specific environment and what generally happens after you disable an account. For example, if disabling an account is often reversed (so you're actually suspending it temporarily), you'll likely want a different set of answers than if disabling an account is almost always a prelude to deleting it entirely. However, you do want to have answers for these questions when you're disabling an account, in part because different answers mean that you do different things on a technical level.

(For example, if you want a user's email to still work you probably can't rename their login, even though that's a great way of disabling any crontabs and at jobs that they have sitting around.)

This brings up the value of either automating the process of disabling accounts or documenting a procedure for it. Doing either of these is going to cause you to confront these questions and come up with answers for them (well, doing either of these thoroughly). Even if the answers are 'it depends, we have to decide on a case to case basis', at least you now have written down that you need to ask the questions, come up with an answer, and take certain steps based on what the answer is. What results is both awareness and consistency; you know that these issues exist, you've thought about what the right thing to do is, and you're probably going to do the same thing every time.

You can still get awareness of these issues without having a set procedure for disabling accounts, but now you're at the mercy of remembering them all on the fly. If you forget, your 'answers' to these questions now only happen as side effects of whatever else you're doing to disable the account, and they may or may not be what you actually want to happen. And if you disable accounts in different ways at different times, you can get different outcomes without intending it, eg you thought that locking the password was equivalent to expiring the account but it turns out that they have different side effects.

(This is of course yet another example of where checklists are a good idea.)


Comments on this page:

From 70.26.87.112 at 2011-07-30 10:44:44:

(For example, if you want a user's email to still work you probably can't rename their login, even though that's a great way of disabling any crontabs and at jobs that they have sitting around.)

Not necessarily. A few jobs ago we used Postfix as the MTA, but a combination of the "core" and qmail LDAP schemas for internal mail routing.

So a person's public e-mail address (user@example.com) would be stored in the "mail" attribute:

http://www.zytrax.com/books/ldap/ape/core-schema.html#mail

Once it hit our main relays (after scanning/filtering), it would be forwarded to a particular geo-specific mail host. We had offices in multiple cities, and so the mail would be transferred to user@milan.example.com, user@tokyo.example.com, etc. This latter 'forwarding' address would be stored in the "mailAlternateAddress" attribute:

http://www.zytrax.com/books/ldap/ape/qmail.html#mailalternateaddress

If a person's status changed at the organization (quit, fired, mat/pat leave) we could change all the attributes of the account and not affect mail flow. We could keep the public address the same, but send someone's mail to their manager (handy in the sales department). (The qmail schema also has an "accountStatus" attribute.)

Of course the same thing could be done with alias files and virtual user tables, but if you want to automate the process (and are using LDAP), it can be quite easy to generate an LDIF file to run against the directory service that modifies the desired attributes in a algorithmic fashion.

Regardless, thanks for all the posts on this subject to date, as it's been a neat discussion and I think useful to help people think about the matter.

Written on 29 July 2011.
« A directory service doesn't make it easy to disable user accounts
One of my testing little dirty secrets »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Fri Jul 29 23:19:07 2011
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.