I’ve long been aware of this particular feature within Application Manager, but had yet to see a real-world application of it. However, recently I did some work for a client with a very large infrastructure and a lot of delegated administrative access to servers and clients. It turns out that some server support groups had been adjusting the time on their managed servers to bring it into line with their local times, conveniently forgetting that the servers were hosted in an overseas datacenter.
Now, allowing servers to fall out of synchronization time-wise is pretty bad. Firstly, your logs are now going to be completely inaccurate. There are also the effects this can have on hosted applications – think a database application that relies heavily on time accuracy, and the resultant screw-ups that can occur as a result of this being skewed. If the servers are DCs that have been erroneously adjusted, then you’re going to have a world of problems with replication just to start with. Some applications even flat-out refuse to start if an incorrect date and time is detected – it can cause that many issues.
Of course, there is probably something you could do with a server admin group that changed the time on their managed systems without proper due diligence – I think shooting them, or at the very least handing them their notice, would be high up everyone’s lists. But in this case, once the people involved had been harshly warned about their conduct, management wanted to put into place some way to prevent a user with administrative access from actually being able to change the system time. How could we achieve this? Well – enter AppSense Application Manager.
First we need to open the Application Manager Console and create a new Group Rule, as we only want to apply this rule to a particular group of (incompetent) Administrators. If we applied it across-the-board to all local Administrators, nobody would be able to change the system time! So we will use a specific Active Directory group to apply this configuration. We choose the group “EMEA Server Support”, and this group is designated as “Restricted”, as we are going to restrict their execution options slightly.
Now, we have a couple of options as to how we could restrict the user from being able to change the time. We could use remove the user right “change the system time” from this user by setting up a custom User Rights Policy, or we could use the “Builtin Restrict” pre-built policy to simply reduce the user’s rights when they launch the required Control Panel applet to change the time. It is simpler to use the latter option, so that’s what we will opt for in the first part of this example – although we will come back to the other option later.
So, next we will need to add a new Component to the Restricted Items section under our Group Rule
Select Date and Time from the list of options selected. These Components refer to particular applets called by Control Panel, mmc.exe and other programs
Click OK and you will be presented with an option to select a User Rights Policy to apply to this Component. As we haven’t created any custom ones (yet!), we simply have the choice of the Builtin Elevate (which adds administrative rights to the user) and the Builtin Restrict (which removes administrative rights from the user). We want to select Builtin Restrict as below
Now, that’s all that is actually required! Save the configuration into your Management Center with a sensible name, and then deploy it to a test system. Log onto the system with administrative privileges, and see if you can change the system time by clicking on the time in the system tray and choosing Change date and time settings | Change date and time
Great news – it works! But what if the administrative user decides to run time or net time from the command prompt – will our configuration stop the change then? Let’s find out…
…and as you can see the answer is a resounding no. This is because the “de-elevation” of privilege is only occurring when the Date and Time applet is run. So how can we stop the admin group from being able to change the date or time from the command prompt as well? We could de-elevate on the launch of the command prompt – but that would kill a whole host of functionality they may need. What we need to do is actually remove the specific rights that actually relate to this administrative function – and as I alluded to earlier, we can use a custom User Rights Policy to alter the user right for Change the system time. Will this work? Let’s go back to our configuration and have a try.
First we need to go to the User Rights Policies node and create a new one, before giving it a sensible name. Then switch to the Privileges tab of your new policy and change the SeTimeZonePrivilege and SeSystemTimePrivilege to Remove as shown below
Now, we need to go back to our Group Rule and add the required files to the Applications tab under User Rights. I’ve added the cmd.exe program from both the system32 and syswow64 folders because I am working on an x64 platform and you don’t know when people might launch this from unexpected areas. I’ve also added the applications as both File and Signature items to show you both the options, but either one should suffice.
Also, you need to make sure each item has the Apply policy to child processes option ticked, in case the user uses something like net time which calls out to a different command (net.exe in this case)
So when all of the items are added to the Applications tab, you need to make sure that you select the correct User Rights Policy for each one as below (i.e. the one we created previously!)
Now let’s save and deploy this configuration to our test machine, log on as an administrator who is part of the target group and try each of our net time, date and time commands from an elevated command prompt
Success! Now our target group have administrative privileges but can’t change the system time and date to create problems.
Bear in mind that if you remove these privileges in this fashion, they can be a little annoying to reinstate. You will actually need to change the configuration and then restart the Application Manager service to get the changes to revert – simply deploying an updated configuration doesn’t seem to make it go away.
One final word on this. Administrators do have the power to get around almost anything. If someone was determined to change the system date and time, the easy way to do this would be to simply stop the AppSense services and change it. However, this sort of thing isn’t intended to be bombproof – merely to stop someone in the server admin group (in this case) from unintentionally altering something that could have serious knock-on effects. If your admins are in the habit of shutting down core system services (that are possibly outside of their management remit) just to do what they think is right, then clearly you’ve got an issue that you’ll need to look beyond IT and into the HR department to solve 🙂
And before I forget, Happy New Year everyone, rather belatedly!
Share
