Not everyone needs the same access to network management systems. Too often, we take the easy path when assigning access credentials on our important tools (and the network resources they manage) and treat all users the same. Do you forego the rigors of RADIUS/TACACs style authentication on your network components, or give everyone from installers to the helpdesk the same login credentials on your management systems?
How you administer your systems should be arrived at with the same care that shapes other operational practices. Accept anything less, and you’re probably lacking important pieces of the overall security and support puzzles.
By requiring anyone who needs system access to use their own credentials with permissions appropriate to their positions, you gain important audit trails and safeguards against misconfigurations. If a settings change mucks things up in an environment where lots of fingers are in the pie but everyone logs in with the same credentials, it’s hard to know who really did what. And those who need view-only rights shouldn't have access to GUI or CLI knobs and buttons outside of their scope, even if they are trusted staff. Don’t risk it!
TACACS at my current organization but previously just a small group of people who had the creds for network equipment and domain admin access to everything else. Since it was a very large organization with a very small group of tech support staff it wasn't hard to figure out who broke/upgraded/changed a system. I agree that RBAC is the best route to go; as some previous posters have replied - that's not always an option for very small teams.
we use a combination of AD groups and TACACS, depending on the device. Though I will say that we have blanket read-only account for SolarWinds. It makes user management a lot easier when there are literally hundreds of users who look at our environments daily. But there are only a handful of us that have any kind of admin access to those products. And for network gear, every user has their own individual login for auditing purposes.
I am just now setting up Orion with NCM plus other modules. I am using AD groups, but I think I might need a few AD user entries to get more granular. TACACS protects most of the devices. I am planning to use NCM to 'catch' those that aren't! This was a good discussion, especially for someone just getting set up! Thanks!
everyone but our admins get just view rights on everything our security is pretty good here and on most servers even admins have to sudu su just to do what we all need too we just have to use our log in so they know who is messing up.
RADIUS for some things, AD authentication for others. We also lock down via IP pretty aggressively both at the device/box and firewall, and we're still a small enough shop that this works. Default Solarwinds settings are quite restrictive, with only a couple of global administrators. To be fair, my hard-working colleagues are consumed enough with their own deliverables that I don't hear a lot of clamoring for admin privs on management systems.
I can give mental assent to the glories of RBAC and the privileges of least permissions, but the problem in my scenarios is that my clients are small, and I'm a consultant that at times looks like an MSP. For small companies, there is not enough bodies in the building to really have a role based breakdown of permissions for a system. Usually it's just one person managing things. Say Sharepoint, or a CRM tool. Or the main tech contact is me - so I have to have ALL the power! And in fact if I wanted to delegate, it wouldn't be possible because no one else wants to have it or can even handle it.
So instead, I end up creating a superuser, and maybe... maybe one other user account, depending on the system. It's a bad habit, but in some cases, it's the only habit to choose from. I suppose I will have to learn better if and when I get into larger contracts, clients, or jobs. Until then...
sudu su root.
Our company previously used role accounts for many things. Now that we are having more audits for things such as PCI and SSAE16 we are moving toward using individual accounts for everybody and trying to manage as much of that as possible from a central authentication system. We also have found NCM to be a huge help when it comes to auditing our network devices to see which accounts exist on which devices.
depending on what service it is, we use radius or tacacs. For regular users we use AD authentication. We do have generic logins for some switches, but they are not to log into important servers or other devices.
There is so much that should be done, but just isn't. There are a lot of people in IT that know enough to be dangerous, but don't have knowledge to understand when they are being dangerous. With inappropriate access, this can be a very bad thing. Some things to keep in mind are those things which you mentioned already. Shared accounts are a major problem with regard to accountability and should be avoided. Blanket access should not be granted for a simple task, but rather individualized access should be tailored to the user. Another item I have seen is with temporary acccess. Many times there are people that need access temporarily for a specific task or duty, with the idea being that the access will get removed after a set amount of time. Many times, though, that access is never removed. And the process of changing passwords after key employees leave is something that I have only seen done once in over 10 years. It is often just too time consuming and difficult to do.
With the Solarwinds systems I have administered, I have attempted to adhere to some of these standards. I have set up groups with varying levels of access, and have set up custom views for those groups. An example would be NCM--I set up a view where our LAN/WAN admins could view and administer their nodes in NCM, I had another view where appropriate IT management and executives could only read the NCM data, and everyone else couldn't even see the Configuration tab. I wish I could do this on a broader basis, but I do, or encourage, as much as I can. Given my newer security based role, I hope to increase my reach with this a bit more.
We set up different levels of access for help desk , System Administrators and Network Engineers on our Solarwinds Server. We Use AD groups to accomplish this. This is very important when many of the Solarwinds modules have the ability to make actually changes and restart processes on network devices and servers.
Hey Jeffery: Can you share more information on how did you set up different levels of access for help desk , System Administrators and Network Engineers on our Solarwinds Server. Is there a way to limit a set of users to do only discovery and no other management capabilities and how ? Any help appreciated also if you could link me to some documents around this would be helpful.
I use existing AD account groups and add them Solarwinds. I then assign different rights to each of these groups in the settings-->Accounts--->Manage accounts --->edit the group and you can set permissions for what each group can do. You could do the same thing with individual accounts.
So we have two groups IT Infra team and IT support so I want to give admin role to IT Infr and just ability to discover nodes to IT support is possible to get this granular ?
This is a much better strategy than giving people access to everything and saying "... and please never go here and do this or that because those are not in your scope". Curiosity and good-intentioned adventuring can do a lot of damage. Better to not provide the door at all rather than to provide it and say "don't walk through that door".
SolarWinds solutions are rooted in our deep connection to our user base in the THWACK® online community. More than 150,000 members are here to solve problems, share technology and best practices, and directly contribute to our product development process. Learn more today by joining now.