LEM Thought of the Week: Realistically, how careful can you be about admin rights and shared passwords?

I've found that the two biggest features that alleviate the tension between the administrator and the user are: granular permissions and audit logging.

Granular permissions are the blessing that takes the cake.  Most administrators don't want to give users access to a system because there things they should not be doing.  That's great, how about we just prevent them from doing what they shouldn't but allow them to do what they should.  Not just blanket denying.  The old permission groups of admin, power, and user are no longer sufficient.  Granular permissions allow the administrators to be confident that the user is not able to do what she doesn't want them to do.  Remember that if you deny access to the system, you are now responsible for doing the work.  Let each user (including admins) do their work in the most efficient manner possible.  Of course, there is the darkside: developers need to design their system for granular permissions.  Not an easy task, not free effort (without a good framework) and not simple; but that's why we use software.  Invest the work once so users gain the benefits every day.

Coupled with the Granular permissions is the audit logging.  Help administrators keep an eye on users and ensure they are actually using their permissions.  If they don't use the functions, prune the permissions.  It's like Spandex: covers what it should without any extra.  (Underarmor is probably a better analogy).  The audit logging can be reviewed periodically.  Your admins are even more confident that the users are not doing improper activities and the users can streamline their processes.

In summation, make the line between administrator and user skinnier and flexible.  The old days of the masking tape straight line through the office have passed into legend.

First of all congrats on the little one.  Yes and they are the ultimate destroyers of "free" time.

I don't have much to say about it since we are guilty of it.  Although we do make attempts to change them regularly. 

Google Terry Childs.  Should we all take it that extreme.  Probably not, but kudos to him.  I worked for a company that rarely changed admin passwords and used about 3-4 regular password for everything.  Old employees were still able to connect and wreak havoc whenever they felt like it.  In one instance an fsck was run on a root partition while it was online and active .  The end results were not good.  I think it was brought up several times and of course it was always we will get to it.  But it never came to fruition.  If one were so inclined they could still connect to an old box they used to administer.  rm -rf /

nicole pauls congrats on the little one!

I think I am going to have to agree with aaron.damyen on this in that granting users granular permissions so that they can do what they need is the best option. Normally users have reasonable frustrations and as long as they have the ability to do what they need, they won't be frustrated to the point of taking action to steal passwords and root systems.  In short; provide a path of least resistance for your users so long as it's within reason.  At the same time I think there needs to be a zero tolerance policy when it comes to employees engaging in such activities as stealing passwords and rooting systems.

I agree shared passwords are not good but I think I'm guilty and yes, it's out of convenience and necessity.

I think "granular permissions" are a great theoretical solution, but don't always exist. I can't count how many times I've had to give a user admin access because the developers of one program or another wouldn't say what specific access was needed; they'd just say "they must be an administrator" . . . . . . .

I think when it comes down to it, full admin access does sometimes have to be given, but it should be monitored closely. Don't be surprised when you go to that computer and see the firewall disabled, a torrenting program installed, etc.

Regarding passwords, I think that's a little easier so long as you can convince management. There is no reason someone should ever share their password with anyone ever. If the person isn't around, then reset their password and give it to their manager in a sealed envelope or something.

I concur with user evanr--with the kudos--for your newborn. Very exciting times!

As to the root of your post/question, I believe the granular permissions scenario is best in this use-case. HOWEVER, the permissions should be attached to Active Directory Domain Services (AD for short), vis-a-vis, AD Groups. From this point, it is possible to nest Groups inside each other--to make mass changes--based on use-case and user role type.

We are currently implementing SolarWinds (SW) across a large enterprise environment, and we purchased most of the SW modules. Our process, successful (so far), is to:

1. Implement SW and all modules (first).
2. Next, create a User Access Rights Matrix--that details the hierarchy of Groups and the users within each Group--within the Matrix.
3. After the Matrix is complete and all of the appropriate people signed-off on the Matrix, we slowly begin to implement each Group--throughout our SW environment.
4. Following the Group-level implementation, we then continue to very slowly add the Users to the Groups--per the Matrix--ensuring that we are not overwhelmed by the new users and further ensuring that errors are prevented--by granting too many Access Rights--to each Group and each User.
5. Finally, we review and audit each Group and User--particularly Users that are unique and outside the standard Group/User use-case.

Thank you for a good question/post, because this is very important to a successful SW implementation--keeping it safe, maintaining performance, and ensuring a solid user experience.

Interesting topic. I think it's fairly obvious that the granular rights approach is the most effective to date. However, this really doesn't fix the problem of password sharing for the users who feel they need more rights, no matter what anyone says. Nor does it fix the more universal problem, that we (IT) share more passwords than most.

In the 'old days' it was pretty close to this:

(source: 'A Beautiful Mind')

Now, it's gotten a little bit better with apps like 'KeePass' (at least we are trying to encrypt things now). But I still see more clients using a common local login for network gear than I see using TACACS+. We all do it (most all anyways) and we justify it through rationalizations that we need to login constantly all over the network and don't have time to use a different password for everything. Which is kind of funny really, since TACACS+ would solve that problem.

Of course, we also have 10 million other things in our faces at all times and a complete redesign of the processes and behaviors we use behind authentication is unreasonable on the surface. But, just like everything else related to security, it just takes one incident...

I think ultimately we need to move away from passwords completely to something different and more secure.  Passwords have been around forever, they are insecure on both the technology side and the people side and they are a pain in the butt to manage.  I really think it's time for something new.  Some sort of wireless key fab that reads your bio-metric data for authentication that is linked to every place that you have an account?  Okay, I was just thinking out loud on that idea but it just feels like it's time for a better mousetrap.

I think that your second paragraph about pruning the permissions is interesting; a tool that could analyze and say "Yeah Joe bob has permission to view the accounting info directory, but hasnt used it in 5 months" maybe a process evolved and Joe Bob doesn't need that anymore, or maybe Joe Bob could just partner with someone in accounting and get the semi-annual report run by them. A tool that could find those infrequent uses that could potentially be closed would be interesting. A tool that found frequent uses of something thats supposed to be infrequent (Joe bob just ran 15 reports over three days and is only supposed to run one a month or so) would be equally interesting.

Working for the federal govt as a contractor, I must say that many things regarding abuse of rights for us boil down to "If you even attempt to do that, it will be logged. If it is discovered, you will be fired, and possibly prosecuted depending on what it is." The key part is "if it is discovered."

So our users have very few rights. Technical users have Elevated accounts in addition to normal user accounts, and AD group membership is used, along with GPOs.

Our site is almost heaven compared to the hospital where I used to work. At the hospital, doctors on the night shift in ER downloaded and installed various entertainment apps - some of which evaded detection by our poorly managed AV at the time. When HIPAA became a buzz word, we tried to remove rights, but it broke many apps. A medium sized hospital (100-500 beds) might have hundreds of apps and servers. Fortunately, over the years, medical software vendors finally heard the complaints and started cleaning this up ... a bit.

But the single greatest obstacle to managing rights in Windows is Microsoft Event Logging itself. What utter fertilizer! A single access attempt from the point of view of an application or user can trigger many dozens of log entries, most of which are useless gibberish. Various vendors have tried to make products that attempt to reverse engineer these entries, but it almost never works except for highly specific situations. There is no N in turnkey auditing solutions, in my experience - they are all turkeys.

Depending on how a user tries to access a file, you get hundreds of entries, and none of them come out and say "at time T, user U on PC P opened and viewed file F on server S." You have to suffer with many unnecessary log entries for the filescans, Kerberos tickets, etc. So you try to trim some of the logging, only to find that some of this is key stuff to reconstruct the chain of who it was, and what their IP was.

Windows itself needs to get a "who, from where did what" concentric logging - not the programmer debugging level logging it has now. Sure, keep both, for those that want it or need it.

And don't get me started on trying to audit changes made via Microsoft GUIs - the most basic need of change management in Windows. It's even worse than file access. So many kinds of objects in different data structures - some in AD, some in WMI, some in the Registry, some in ACLs on objects.

BTW, it would be great if SolarWinds would publish a list of minimum rights needed by which users and groups for all objects. It helps to get Dorothy back to Kansas after her goofy friends (like me) try to help by changing things. There are pieces of what I want in place now - where you can fix some file rights. Keep on that track, SW, it's a great thing. Make it a corporate standard for all of your apps.

=seymour=