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.)


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

These are my WanderingThoughts
(About the blog)

Full index of entries
Recent comments

This is part of CSpace, and is written by ChrisSiebenmann.
Twitter: @thatcks

* * *

Categories: links, linux, programming, python, snark, solaris, spam, sysadmin, tech, unix, web

This is a DWiki.
GettingAround
(Help)

Search:

Page tools: View Source, 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.