I realize that this title instantly sounds like a bad idea, so I'll justify the need in addition to describing the problem.
The need to change system time
I've recently set up a Windows Server 2012 Essentials system for a client, for the first time implementing a domain-based structure to a medical services office that previously had passwordless computers. It's a big change, and somewhat disruptive. They have 3 workstations, 6-8 employees, depending, and some flux of people moving through. The workstation I replaced is the one that is the best spot for their bookkeeper to post transactions, and in order to do so with the least pain, she's been changing the system time, until now. In the interest of not imposing a new workflow, I'd like to allow her to do so for the next few months, until they've moved off the system that requires that workflow.
Currently, only one other computer is domain joined - the other computer is running Windows XP Home, and will be domain joined when it is replaced. I fully understand the wisdom of not changing domain controller time willy nilly, but think not allowing it will be more disruptive to their business right now. Since they aren't an enterprise environment and are a small business trying to use its resources, I consider it pretty safe. Feel free to prove me wrong if I'm about to commit a true disaster.
My understanding is that the best way to give the bookkeeper this ability is to make her a part of the Server Operators group, since they have the Change the System Time permission in Group Policy. I thought about handing out that permission as a one-off, but the Server Operators group seemed like a good fit for this office since people will need some of the other permissions assigned to it (rebooting, etc).
The problem is, it doesn't seem to work, and I can't find any documentation as to why. I've verified she's a member of the group, run gpupdate /FORCE, rebooted the server, and she still can't change the time (but my admin account can). Other permissions related to the group (changing the timezone) seem to work as expected and she can do those functions. I've also verified that server operators have that permission in group policy on the default domain controllers policy, which seems to be applied. A UAC prompt asking for credentials continues to pop up when she tries to change the time.
As a result, I'm assuming I'm missing something and that I've not applied something correctly, something in the chain somewhere isn't set by default and I've assumed it is, or that something is forbidding that action, overriding the original permission.
The alternative that some may consider, since I'm already talking about giving her the ability to change the time, is to give her a secondary admin account to change time with. But I'm not willing to do that yet, since I believe a better, more secure, option exists, and part of the reason I went with the domain model in this office was because they'd previously made poor choices with admin credentials. I'd very much like to find a solution or workaround that doesn't give them any more permissions than they need to do their jobs effectively.
Does anyone have experience with this problem? Is the Server Operators group the correct route to be taking? Thanks for your help.
Edit: Long response to questions below. I do understand it can make basic functions fail. Mostly, they tend to log in once at the beginning of the day and stay logged in. My hope is that it won't interfere with other computers. If it does, we'll find a different workaround with them understanding the situation better. My understanding of the posting process is that they have to be posted with the same date as the day of service, but the bookkeeper is only in a few days a week. We're transitioning to a system that lets her set the time in the posting instead of systemwide.
The domain controller is being used as a workstation out of necessity. They don't have money for lots of computers, but I think they benefit from some of the advantages of having a domain, etc. It was a carefully considered tradeoff even though I understand it's well against best practices.