I was tasked with adding some users to Active Directory today. I did all of this, however, I had a list of 20 users to add. Of this list, it listed 5 users already added.

The list's instructions were basically to just add the users, so I did. There is no way I can get passwords of existing users from AD so for testing purposes I changed these passwords of the existing accounts. Unfortunately, these accounts are in use (don't know how often).

My senior dev said it's fine learn from your mistakes you weren't to know (I did make a similar mistake just days before but that was due to attention to detail and was 100% my fault but I am still doing ok in my job - I'm on probation - as my senior dev always says).

There has been no client impact (yet?). How big a mistake is this?



If the accounts are physical users, there's very little problem. They'll have to contact support to get their password reset. The trouble depends on how senior the person is and how much trouble is involved in them contacting support; a remote user with a laptop is going to have more trouble than someone who sits next to the person that can change their password.

If the account is used by a process, the trouble depends on whether that password is known and how many places might require changing if it isn't.

Generally, unless you have a pattern of making mistakes, I doubt you need to worry. Obviously I'm not your manager.

  • There isn't much involved in contacting support, but the users may be senior. – GurdeepS Jul 4 '09 at 11:42

If they're physical users, there must be a way to trace those users back to real people. Be proactive and notify them their password has been changed and they will need to contact support. If you silently sit there and "hope nobody notices", it's liable to get you fired when they trace the problem back to you. Acknowledge what happened and take steps to correct it. And if you're not the one to take the phone call, make sure they know what happened too, so they can respond quickly and appropriately to complaints.

Push comes to shove, it's only 5 users. It's not like an entire office of a large corporation will be flooding support with phone calls. Assuming it takes 5 minutes to reset a password, we're looking at a total of 25 minutes lost somewhere. Humans make mistakes, and in the world of such mistakes, 25 minutes with a very clear solution isn't too bad.

As David Pashley says, however, if they're used by a process and aren't physical people, hopefully the password is known and can be set back. If not, this could be a sticking point.

As a side question, if the list showed 5 users were already added, why didn't you just add and test only the other 15? Answer this and you can answer your own question of how bad a mistake it was (or whether it even was an avoidable case).

  • It'd take less than 25 minutes. Password management is a very quick thing (on AD). I am a junior dev. I just didn't know of the internal procedures in the company (eg I need authorisation to work with existing accounts). They are physical people. When the passwords are set, the client gets an email with the credentials. Hopefully I can find this. I didn't just add the other 15 because of the post below yours. – GurdeepS Jul 4 '09 at 11:24

You'll know when a mistake is really bad. The phones will ring off the hook, whoever answers the phones will give you dirty looks for a week, etc...

Sounds like you already have a decent idea what the actual impact on your users was (minimal to none). You did what you were told ("adding users") without taking the initiative to first check if any of those users existed. I must say, though: one of the most important "skills" for system administration is "attention to detail"; I'd rather hire a junior admin with almost no experience on my particular platform who has strong attention to detail than a junior admin somewhat experienced on the platform without it.

I suggest that in the future, concentrate on how to mitigate (minimize the impact of) mistakes instead of eliminate mistakes. Everybody makes mistakes, you can't avoid it happening now and then. Learn from them. Expect them.

  1. Worst Case: you make a mistake and try to cover it up. Sometimes you get away with it, sometimes it backfires.
  2. Best Case: you make a mistake, it's on a test system/environment and nobody has any reason to care except you (maybe means you have to spend 15 minutes recreating the test system/env). Heck, you can call these mistakes "experiments" or something, even.
  3. Reasonable Case: you make a mistake, you immediately let anybody that can help mitigate (boss, senior sysadmin, helpdesk staff, users affected) know and minimize the actual impact to business
  4. Alternate Reasonable Case: you make a mistake and have a backout plan that allows for immediate repair (copy the config file, edit it, break it, put the original back)

For instance, if the helpdesk knows that users X, Y and Z may have had their password accidentally reset, when user Y calls about not being able to log into the system, they can immediately assist them with the correct solution instead of wasting 5 minutes with unnecessary troubleshooting because the mistake got covered up.


Sounds like poor instructions to me (at least, the way you have told the story...) Why were you given a list with duplicates? If this is part of a regular process (say, adding new users once a week) then you need to investigate the process that produced the list to prevent the next junior guy making the same mistake.

  • I have no idea why the list contained duplicates. That gave me the impression that the existing accounts hadn't been signed off/given to the client, because they could be changed. I am working on this site with someone and he said "the client will want access, let me know when", so I'm not sure if the client has access but then the site has content on it (which we put up). – GurdeepS Jul 4 '09 at 11:26

Not the answer you're looking for? Browse other questions tagged or ask your own question.