We are in the process of implementing DSC in our production environment and question came up. We are using a pull server for the configuration. But what is to stop a rogue admin from changing the LCM from pull to push and creating a new mof file?
I should add we are using DSC to lock down the server with the recommendations from the Microsoft Security Baseline.
The threat of being fired and prosecuted is what stops a rogue admin.
Honestly - I know it seems sarcastic, but the answer is to manage administrative privileges. If someone has access to a trusted account, you can’t stop them. The LCM doesn’t have any provision for stopping an admin from doing admin stuff.
For example, perhaps nobody should have an admin account. Instead, they have to log into a JEA endpoint to perform tasks, and it’s configured to log every command they run.
From an enterprise level, you cant do much without taking admin permissions. This is the same problem we have with group policy changes. If someone has the permission as a byproduct of broader permissions, we rely on logging and monitoring to alert us but what we should do is lower the amount of permissions as a general rule.
From a server level, you might be able to run the LCM say every 24 hours via your CI\CD pipeline or a scheduled task. Though this can be altered by the rogue admin pending his knowledge of the activity, setting monitoring and alerts telling you something hasn’t run according to plan (although that in itself can be altered by the rogue admin).
As Don said, sometimes the answer is 0 admin.
In a secure environment we normally have 2 admin accounts with random names and long (15+) passwords stored in an electronic vault and 2 in physical vault with process in place for who is allowed to ask for its retrieval and who is allowed to approve it and all of it is logged. But even if you go the JEA way (highly encouraged), remember that once you give someone any permission to do a job, even JEA will not stop that admin from causing havoc. He wont be able to stop the IIS server, but he could change some DNS settings to point requests to a different server or a fraud site.
Locking down servers with DSC isn’t the right way, or definitely shouldn’t be the only way. Use local group policy, enterprise group policy and DSC to create layers, which might give you the monitoring and logging you need to catch foul play early on. I would use DSC for everything that affects the daily applicative role of the server. If that server is a web server then I would make sure IIS is always installed via DSC. However, I would not use DSC to setup the terminal services profile settings, that I would do with enterprise group policy and even local group policy.
As DSC and orchestrating it becomes more mature, more and more things will cross between group policy and DSC, there are even group policy dsc resources and converters that people created and placed on GitHub that you can look for if interested, but certain things will never be moved and those are primarily user policies. Don has some very nice movies about this which I highly recommend watching.
It boils down to levels of trust as we are dealing with humans, at least until AI takes over 
Hi. I am implementing DSC into production this month too, just deployed to non-production. We are looking at JEA in the future but for now we are alerting/monitoring on when LCM is changed. Currently, we use SCCM baselines to do our DSC healthcheck which includes checking the LCM. If changed, we write to event log and an alert is fired. In the future, we will use SCOM for this. Good luck with your implementation.