pipe理层希望我创build一个脚本/应用程序/古老的神奇工件，允许现场技术人员在我们的configurationpipe理器服务器上执行任务（更新集合成员资格 – 通过WMI调用很容易完成），而无需实际给技术人员执行所述任务的权限。 想到的第一个解决scheme是创build一个具有必要权限的服务帐户，然后find允许技术人员在该帐户下运行命令的方式，而不实际向服务帐户泄露该帐户的凭据。 我想我可以通过非对称encryption技术来encryption证书，但是我对encryption还是很不了解，所以我会很困难的。
我正在看的另一个选项是创build一个自定义的WMI方法提供程序，它将使适当的WMI调用来完成我需要的一组约束内的任务，我想使用pipe理需要的工具对技术人员执行这些约束。 然后我只需在ConfigManager服务器上注册这个提供者，并给现场技术人员“Execute Methods”权限即可。
在我深深地打破我的org的SCCM服务器之前，疯狂的自定义WMI垃圾可能会让我的继任者难以修改或重新创build，有没有什么显而易见的东西让我感到愚蠢或不可行？ 否则，还有没有其他常见的做法可以让我们的技术人员执行一个他们没有专门做的任务呢？
你所说的是通过默默无闻的安全。 你想让一群技术人员有权做一些事情，但是你不想让他们进入一个巨大的，可怕的控制台，如果使用不当，可能会使他们陷入麻烦。 我知道了。 但这是错误的想法，因为这只是一个温暖的毯子，感觉舒适，但实际上并没有增加安全性。
我总是和公司一起看这个; 他们希望底层的技术支持人员能够重置AD密码，但他们不想让他们访问Active Directory用户和计算机RSAT工具。 所以他们创build一个网页或一些密码重置应用程序，使用服务帐户来完成这项工作。 你可以说它降低了恶意软件的攻击面（因为只有一个帐户你必须保证而不是20个或更多），但实际上你所做的只是隐藏恶意用户可以通过其他方式获得的信息无论如何，如果他们真的想。
底线是，您可以在技术人员的工作站上安装SCCM控制台，而不必让他们访问服务器本身，并且该控制台是完全可靠的。 你完全可以控制谁可以看到什么。 把它做好是一点点工作，但是肯定比没有维护的Rube Goldbergtypes的WMI脚本的工作less得多。
教技术人员如何正确使用控制台，明确责任范围，并给予他们足够的权限来完成工作。 如果他们发现一种意外的做法，你不打算让他们做，那是你的错。 如果他们故意做一些你不打算的事情，他们应该被解雇（或者如果他们做了一些聪明有用的东西，而没有破坏任何东西，他们也应该被提拔）。
大堂与pipe理，反对使用技术解决人的问题。 最终会给你带来更多的工作，鼓励他们认为networking比实际更安全。