2

Management wants me to create a script/application/ancient magical artifact that allows field technicians to perform a task on our Configuration Manager server (updating collection memberships - very easily done via WMI calls) without actually giving the techs the permissions to conduct said task. The first solution that comes to mind is creating a service account that has the requisite permissions, then finding a way of allowing techs to run commands under this account without actually revealing the service account's credentials to them. I suppose I could do this via asymmetric cryptography to encrypt the credentials, but I'm fairly clueless about encryption, so I would have a very difficult time with this.

Another option that I'm looking at is creating a custom WMI method provider that will make the appropriate WMI calls to accomplish the task I need within a set of constraints that I would like to enforce on the techs using the tool that Management wants. Then I'll just register this provider on the ConfigManager server and give the field technicians "Execute Methods" permissions to it.

Before I get knee-deep into breaking my org's SCCM server with crazy custom WMI junk that will probably be difficult for my successors to modify or recreate, is there anything obvious that I'm missing that makes this stupid or infeasible? Otherwise, are there any other common practices that I'm oblivious to that would allow the kind of execution-by-proxy for our techs to conduct a task they don't specifically have permissions to do?

HopelessN00b
  • 53,795
  • 33
  • 135
  • 209
Prosun
  • 203
  • 1
  • 2
  • 9
  • What version of sccm is this? – MDMoore313 Jun 18 '14 at 22:06
  • 2012 R1. Potentially going to R2 in the next few months, but no definite plans at this point in time. – Prosun Jun 18 '14 at 22:06
  • They want people to do something w/out giving them permission to do it? – MDMoore313 Jun 18 '14 at 22:07
  • Essentially, yes. They want field techs to be able to update the membership of collections used for application deployment, but they don't want the techs to have any type of permissions whatsoever to said collections for fear that they'll break something (since these collections are used globally in our environment). – Prosun Jun 18 '14 at 22:08
  • it doesn't look like there are any special permissions involved. I'd try giving them read rights to the collection and see how that works. http://technet.microsoft.com/en-us/library/bb680891.aspx – MDMoore313 Jun 18 '14 at 22:15
  • @Prosun I think you're hitting a fundamental problem that's deeper than technology. If you want someone to do something, they need permissions to do it. And that means they can screw it up as well. ... so, yeah, probably your best shot is the custom, nasty, difficult to maintain WMI provider you mention. Then again, that's because the better approach is to only give modify rights to people you can trust with them, and/or regularly verify/audit to make sure a mistake doesn't snowball into a disaster. – HopelessN00b Jun 18 '14 at 22:19
  • @BigHomie Good to know, I'll try making a case with the Grouchy Ones about allowing Read access to the collections (the techs don't have that right now). – Prosun Jun 18 '14 at 22:22
  • @HopelessN00b I definitely acknowledge that the problem exceeds technological constraints - some aspects of the organizational culture are nothing short of disastrous around here. I think I know what I need to know, but I'm curious if other folks have dealt with this issue and might have thoughts that would sway Management one way or the other if I give them a hard choice about what it'll take to pull this off. – Prosun Jun 18 '14 at 22:26

1 Answers1

2

What you're talking about is security through obscurity. You want a group of techs to have permission to do something, but you don't want to give them access to a big, scary console with lots of buttons that could get them into trouble if used improperly. I get it. But it's fallacious thinking because it's just a warm blanket that feels comfortable but doesn't actually increase security.

I see this with companies all the time; they want to give low-level help desk techs the ability to reset AD passwords, but they don't want to give them access to the Active Directory Users and Computers RSAT tool. So they wind up creating a web page or some password reset app that uses a service account to do the work. You could make the argument that it lowers the attack surface for malware (as there's only 1 account you have to secure instead of 20 or more), but in reality all you're doing is hiding information that a nefarious user could get by other means anyway if they really wanted to.

The bottom line is that you can instal the SCCM console on a tech's workstation without giving them access to the server itself, and that console is fully securable. You have full control over whom can see what. It's a bit of work to get it right, but certainly a lot less work than the unmaintainable Rube Goldberg-esque WMI script thing you're talking about is.

Teach your techs how to use the console properly, establish clear boundaries as to the scope of their responsibilities, and give them just enough permissions to do their jobs. If they find a way to accidentally do something you did not intend for them to be able to do, that's your fault. If they deliberately do something you did not intend, they should be fired (or promoted if they did something cleverly useful without breaking anything).

Lobby hard with management against using technology to solve a people problem. It winds up being more work for you in the end, and it encourages them to think that the network is more secure than it actually is.

Wes Sayeed
  • 1,902
  • 6
  • 28
  • 43
  • I think you're spot on - naturally, our help desk is stuck with said AD password reset utilities. And I really like what you bring up about doing "something cleverly useful without breaking anything." This is definitely the best way to go. – Prosun Nov 03 '14 at 17:00