Going Wild With Administrative Accounts

Today I got a question that reminded me that I have not written a whole lot about how to manage the accounts used by system administrators. The question was whether I could think of any reasons why you would share an administrative account between several people, other than for the sheer convenience of it.

My answer is that I cannot think of such a reason. There is one edge case, used in ultra sensitive environments, where you share an account between multiple people, but each of them knows only a portion of the password. This is not done for convenience though, it is done so that no single one of them can make changes without the others knowing. The system could only be compromised through collusion between them.

Other than that, I cannot think of a single good reason for sharing administrative accounts. In general, there are two extremes when it comes to this. On the one side is a single account, used by everyone, for every purpose on every system. On the other extreme is an account per purpose, per person. Somewhere in between is the happy medium.

We have tried getting closer to the multi-account extreme here at Microsoft, but it is causing some pain for administrators. We also use Smart Cards for high level administrative accounts. I have heard of people who have as many as 28 of these Smart Cards to keep track of. This obviously inreases security on one side, but at the same time, you have to imagine that the administrators will eventually start looking for ways to circumvent the policy for their own convenience, thereby decreasing security. One might argue that they should be able to deal with this level of complexity and that this is why we pay them so much, but as most people do not think they are paid enough, they will try to make life easier on themselves.

Where exactly the happy medium is probably differs by environment, with risk management philosophy, and with the quality of the administrators. However, unless you start with some form of analysis of the security requirements of the systems, and classify the systems into different categories of requirements, there is very little chance to get a reasonable division of the accounts. Again, risk management and thinking about the security requirements underlies all the other things we do.

Comments

• Anonymous
  May 12, 2006
  The comment has been removed
• Anonymous
  May 12, 2006
  The comment has been removed
• Anonymous
  May 14, 2006
  Much as this may shock you Susan, but if any of the six of you were hit by a truck, the first thing I would miss is certainly not the blogs.
• Anonymous
  May 14, 2006
  I have come across certain dodgy server applications that, due in part to their age and the way they were written cannot be installed as a service. They have to run within an interactive session and they require (at times) monitoring. Obviously, these applications also require administrative privilige.
  Therefore, the account used to run these applications must remain logged in. In small companies, this quite often results in the administrative account used being known by a number of people. In small companies, this might not matter that much - Susan's "trust, truck and asset factor" - but in larger organisations that have the resource and money to ensure that these sort of situations do not occur, there is no justifiable reason why and administrative account should be shared amongst multiple people.
  Of course, one still has service accounts with administrative privilige and, in most cases, the credentials to such accounts are documented - it's an operational requirement.
  Should a rogue admin wish to hide his tracks, he only has to subvert one of those accounts to effectively anonomise his actions. One can always audit access to such documentation, but it's another layer of complexity to put in place. Of course, most MS applications don't require service accounts with admin rights any more but there are exceptions...
  Essentially, we're up against the same security triangle. Security, cost, ease of use ... pick two.
• Anonymous
  May 15, 2006
  There seems to be a disconnect between different sections of Microsoft on the best use of an Administrative account.  That is not really surprising considering how large the organization is and that each section will be looking out for its own products and technologies first.  
  
  This comes up because the security gurus are telling network and system admins to delete the Administrator account or set the password for it to be different for every machine; but on the other hand, to get WMI scripts to run on remote machines, the person running the script has to be logged on with an account that has admin rights across the organization and the passwords can not be different.
  
  So, as has already been pointed out, you have to choose between ease of use, so you can run a script once to collect all the information you need, and security where that script must be run locally every time you want the data.  If Microsoft really wants to promote more secure computing, something has to change.
• Anonymous
  May 15, 2006
  Dan, I've seen many of those apps as well. I can't tell you much more than that they are fundamentally broken and should not be used. I have had them as well, and had to use them. I also made sure that the vendor go no more money until they implemented the app as a service as they should have done in the first place. That is really the proper way to do it, and until the customers that pay them start enforcing that, the vendor's will keep writing apps that are really designed to run on Windows 95.
• Anonymous
  May 15, 2006
  Jonathan, there is probably disconnects. It is hard to chase down all these, but I try when I find them. For instance, I was able to get the password assessment page for consumers improved.
  
  That said, using an account to run remote WMI scripts on several systems is not necessarily a problem, as long as you use a domain account. That is really what they are designed to be used for. The problem comes up when you expose systems with one set of very sensitive security requirements to systems that are not as sensitive, by using the same accounts on all of them.
  
  Setting passwords on all those Administrator accounts is a hassle. That is why I wrote the passgen tool for the book.