Discussion Locked

Changing System Time

0 helpful
19 replies
Closed to new repliesThis discussion is closed. It stays readable, but it takes no new replies.

Can anybody see any problems with giving domain users the right to change system time. It'll save me from logging on and doing it for them but this right is restricted to Administrators and server operators by default.
Any comments
Peter

19 replies

by bill cassada

Yes, if you are using Exchange the timestamp for email is based on the geographic region selected. If a user on the east coast, for example, correctly sets the time for his/her machine, but fails to or incorrectly selects a time zone, then the timestamps will be off on the email for that user. It's not difficult to fix at all, but causes a little confusion sometimes. Other than that I can't think of any dire consequences off the top of my head.

by agibbs

I certainly don't see any problem with giving your users access to do this, it certainly couldn't hurt much. Before doing so, I would strongly consider using the login script to synchronize workstations with your PDC each time they log in -- just add a line that reads:
net time \\ /set /yes
into your login script, that will sync the time on the workstation with that on the PDC each time the user logs in.

--Aaron

by nsa13

Pete,

Giving users the right to change the system clock and calander won't really effect your security posture and is usually a convinience to your users. While users can mess up there own time/dates and that will have an effect on Exchange emails most users won't be that smart to try something like that.

Anyways, as answered in #2 thats your best solution. But, I think that if you use the net time command that its success is based on a user having either local admin or change system time rights in the domain. So, you would still need to grant the user that right.

Cheers!

Also, if you don't want the PDC to be your central time keeper, you can make it another box, have it RAS to the atomic clock, reset itself and then have your users workstations sync with it. just a thought..

by nsa13

Pete,

Giving users the right to change the system clock and calander won't really effect your security posture and is usually a convinience to your users. While users can mess up there own time/dates and that will have an effect on Exchange emails most users won't be that smart to try something like that.

Anyways, as answered in #2 thats your best solution. But, I think that if you use the net time command that its success is based on a user having either local admin or change system time rights in the domain. So, you would still need to grant the user that right.

Cheers!

Also, if you don't want the PDC to be your central time keeper, you can make it another box, have it RAS to the atomic clock, reset itself and then have your users workstations sync with it. just a thought..

by nsa13

Pete,

Giving users the right to change the system clock and calander won't really effect your security posture and is usually a convinience to your users. While users can mess up there own time/dates and that will have an effect on Exchange emails most users won't be that smart to try something like that.

Anyways, as answered in #2 thats your best solution. But, I think that if you use the net time command that its success is based on a user having either local admin or change system time rights in the domain. So, you would still need to grant the user that right.

Cheers!

Also, if you don't want the PDC to be your central time keeper, you can make it another box, have it RAS to the atomic clock, reset itself and then have your users workstations sync with it. just a thought..

by bill.parks

Yes, one of the most important elements of corporate computer use is the ability to track time. As Bill mentioned in post #1, not only will email times be potentially off, but the ability to exploit that is definately more significant.
Imagine a corporate user in a legal bind, his ability to "go back in the past" and send out a corrective email is not something the business should allow. Local file time stamps are also affected by this. Think carefully and consult your executives before allowing this.
An alternative is TimeServ, or W32Time, both found in the resource kits. These allow you to sync NT machines to a central time source. These run as services and are not affected by typical user interaction.
I agree with Bill, in post#1.

by bobspearing

Bill is dead right about confusion, I was using win98 to edit system policies on the NT server, when I checked the server the files had last been edited the following day !
The user of that workstation had set his system to pacific time.
As you can imagine it raised my heartbeat for a while.
Bob

by gowen

If you want to remove the hassle of having to modify the time of all the computers on your network, then you should think about deploying something like Tardis. See http://www.kaska.demon.co.uk/ for details.

It can find out what the right time is in various ways including using networked timeservers, GPS (The Global Positioning System), and by listening for time broadcasts over a LAN. You can even configure it to use one machine on your network as the master time source.

by blackbeard

Many good replies... Assuming that your clients are NT workstation:
-using NET TIME in the login script will still require you to give permissions that will allow users to manually change the time.
-i'd go with the suggestion of using the TIMESERVservice rather than TARDIS. Timeserv is free and Tardis is shareware. You can set the timeserv service to run as a system acct and don't have to grant the user any permissions. If you roll out a standard timeserv.ini file, all the workstations can be pointed to a master time server. Then you can have that master server synchronizing it's time with an atomic clock over the Internet. We actually use Tardis on our master time server because we're behind a firewall and it supports using port 80 through a proxy server. Timeserv will only use the standard NTP port. We didn't want to open another port on our firewall.

This discussion is closed to new replies.