locked
Admin rights during login RRS feed

  • Question

  • I need to add a Domain Admin account to a login script so time will sync during login.

    How do I run these cmd's on XP so the user's PC then syncs time during the login?

     

    net stop w32time

    net start w32time

    net time \\data2 /set /yes

    Thanks!

    Thursday, December 1, 2011 1:58 AM

Answers

All replies

  • The time automatically syncs periodically. If you are getting messages in teh event log about sync failuer then it is an issue with the DC that is responsible for time.

    Restarting the time service wil lnot help this.

    The answer is that you cannot cause a script to run with admin privileges in a normal user account.

    What you want to do cannot be done.

     


    jv
    Thursday, December 1, 2011 3:21 AM
  • The time automatically syncs periodically. If you are getting messages in teh event log about sync failuer then it is an issue with the DC that is responsible for time.

    Restarting the time service wil lnot help this.

    The answer is that you cannot cause a script to run with admin privileges in a normal user account.

    What you want to do cannot be done.

     


    jv

    No it is a rights issue as we do not allow anyone the right to change time except domain admin. I need to run the script granting elevated privileges in the script to run these tasks else time does not sync unless you are a domain admin member. Running the script with elevated rights is something I recall seeing before. You may not have seen how to do this, others likely have.

    Thursday, December 1, 2011 5:35 AM
  • I know exactly what you are asking.  Tis comes up her eand on other forums constantly. 

    YOu cannot run a logon script with elevated rights.  Also what you are trying to d is not necessary in a domain that works correctly.  Syncing is automatic there is no need to script this.

    I have been doing Windowds and system development and administration for over thirty years.  Believe me when I say this is unnecessary and not possible.

    You can subvert the security of your systems in ways that can do this.  Yu can also create a complied aplication that can do ceratin things.

    Time sync can be forced by just remootely restarting W32Time.  It will autosync on restart always and it wil always sync with the doman controller.

     


    jv
    Thursday, December 1, 2011 6:50 AM
  • Duplicate of this thread which has already been moved to a more appropriate forum:

    http://social.technet.microsoft.com/Forums/en-US/winserverDS/thread/5edacfe7-7e91-4c14-934a-5bb76948e21b

    See answers in other thread also. You do not not need to use a script if the Windows time services are properly configured.

    Bill

    • Proposed as answer by Bill_Stewart Friday, December 2, 2011 6:57 PM
    • Marked as answer by Rich Prescott Saturday, December 3, 2011 6:42 PM
    Thursday, December 1, 2011 1:39 PM
  • If you are in a domain, time synchronization should happen automatically, as explained in the Directory Services forum. Perhaps you didn't find your thread after I moved it into the other forum. Use the link Bill provided. If time synchronization is not happening, you need to troubleshoot the problem. The other thread has links to explain how it works and how to troubleshoot. As explained in this forum, logon scripts can only run with the permissions of the user (unless you compromise security).

     


    Richard Mueller - MVP Directory Services
    Thursday, December 1, 2011 3:06 PM
  • I need to add a Domain Admin account to a login script so time will sync during login.

    How do I run these cmd's on XP so the user's PC then syncs time during the login?

     

    net stop w32time

    net start w32time

    net time \\data2 /set /yes

    Thanks!

    Scheduled task.
    • Proposed as answer by Rob Biggs Friday, December 2, 2011 7:23 PM
    • Unproposed as answer by Bill_Stewart Friday, December 2, 2011 8:08 PM
    Thursday, December 1, 2011 6:02 PM
  • Scheduled task.

    Problems:

    1. Does not scale well.
    2. Unnecessary if time service configured properly.
    Bill
    Thursday, December 1, 2011 6:11 PM
  • Scheduled task.

    Problems:

    1. Does not scale well.
    2. Unnecessary if time service configured properly.
    Bill
    Both are absolutely true, not to mention that there is a possibility for a user to hijack the script unless it is stored in a secured location. But regardless, it will perform the, non-scalar, broken work around :)
    Thursday, December 1, 2011 6:55 PM
  • The user can hijack the script no matter wher you store it.  You cannot protect an admin password in a script.

    The way I have done this in the past is to give the user the right to set system the time.  This can be done via Group Policy.  This is afairly benign right but is withheld by default because we normally do not want users to change the time or time zone.  Allowing this is safer than trying to use admin rights in a user logon script.

    Once set for the user the logon script can just run the commands like any other.

     


    jv
    Thursday, December 1, 2011 8:41 PM
  • The user can hijack the script no matter wher you store it.  You cannot protect an admin password in a script.

    The way I have done this in the past is to give the user the right to set system the time.  This can be done via Group Policy.  This is afairly benign right but is withheld by default because we normally do not want users to change the time or time zone.  Allowing this is safer than trying to use admin rights in a user logon script.

    Once set for the user the logon script can just run the commands like any other.

     


    jv
    A scheduled task does not store the password within the script, it passes the permissions assigned to the task to the script it's self. My reference to secure location was one in which the user does not have write access to the script so that they can not modify it to execute whatever code they desire.
    Thursday, December 1, 2011 10:09 PM
  • Lets try and get this together.

    The topic of your post is "Admin Rights during logon" - is that correct.

    What does a sheduled task have to do with a logon?

    A logon script is a logon script.  If you run a scheduled task during logon it still has the same security issue.  The password is readable in the file.

    Go ahead.  Put the password in the file.  It is your system.  I am just giving you a secure and more correct Windows way of doing this.

     


    jv
    Thursday, December 1, 2011 10:40 PM
  • One other note.  A scheduled task can be set to run under an admin account and it will do what you are trying to do.  There is no need to 'elevevate' or run under the current user.  THere is no need to save a password in a scrip.  The takse is registeered under WIndows and teh account logon is securely held in teh system; not is a file.

    Just schedule an admin task.

     


    jv
    Thursday, December 1, 2011 10:46 PM
  • Lets try and get this together.

    The topic of your post is "Admin Rights during logon" - is that correct.

    What does a sheduled task have to do with a logon?

    A logon script is a logon script.  If you run a scheduled task during logon it still has the same security issue.  The password is readable in the file.

    Go ahead.  Put the password in the file.  It is your system.  I am just giving you a secure and more correct Windows way of doing this.

     


    jv

    Riddle me this...

    Why would you put the password in a script, to elevate permissions of that script, when the very same permissions are being passed to it by the thread which launched it? The argument you are presenting is null. At question is not the 'correctness' of the script being ran but the technical feasibility of passing credentials without elevation of the user session being logged into.

    Thursday, December 1, 2011 10:49 PM
  • YOu are teh one that is asking to elevate a script-

    From your first post:

    I need to add a Domain Admin account to a login script so time will sync during login.

    How do I run these cmd's on XP so the user's PC then syncs time during the login?

    I assume that you want this domain account to run the code you posted by using a password to log in.

    I am saying you don't want to do this. It won't work and it is not safe.

    What threads are we talking about now.  There are no threads here.

    If you don't want to believe anything that nearly every one here has posted then we can't be of any help.

    Sorry.

     


    jv
    Thursday, December 1, 2011 10:56 PM
  • YOu are teh one that is asking to elevate a script-

    From your first post:

    I need to add a Domain Admin account to a login script so time will sync during login.

    How do I run these cmd's on XP so the user's PC then syncs time during the login?

    I assume that you want this domain account to run the code you posted by using a password to log in.

    I am saying you don't want to do this. It won't work and it is not safe.

    What threads are we talking about now.  There are no threads here.

    If you don't want to believe anything that nearly every one here has posted then we can't be of any help.

    Sorry.

     


    jv
    I believe you are confused. I will leave you to sort out the facts from your perceptions.
    Friday, December 2, 2011 2:57 PM
  • This seems to have gotten off-topic.

    The question needs to be marked answered - the OP's question is asking how to accomplish something that is a band-aid workaround for the fact that his domain's time is not synchronizing. The correct answer is to fix the time synchronization, not to use a band-aid workaround.

    Bill

    Friday, December 2, 2011 6:56 PM
  • Bill,

    I have been watching a few comments come in on this without reading and responding to each comment or suggestion and it looks to have gone off topic.

    I would suggest in my specific domain we have very restricted PC's (Health-care) and there are items that need to be timestamped and as such only Domain admin have rights to change time.

    This may not be standard practice in most domains and as such it seems to give issues on devices that are used by non domain admins at times, not very often.

    I will suggest something is not right and I am seeking the correct solution as there are likely many other domains similar to ours.

    I have looked at our GPO and it seems correct, our Servers are correct and only the XP machines have the problems and there are know time sync problems with XP from what I have read.

    Perhaps you may care to help me identify and fix the item rather than posting all the regular links and suggestions that seem to point to standard GPO settings?

    Friday, December 2, 2011 7:58 PM
  • Hi,

    Correct time service configuration does not require end-users to be administrators, and there are no commands that need to be run on client machines when things are set up properly. I would start with the documentation:

    Administering the Windows Time Service

    Other than that, I can't offer much more guidance as this is a scripting forum. The link I posted to the thread in the other forum is a more appropriate forum for this topic:

    http://social.technet.microsoft.com/Forums/en-US/winserverDS/thread/5edacfe7-7e91-4c14-934a-5bb76948e21b

    Bill

    • Edited by Bill_Stewart Friday, December 2, 2011 8:15 PM Clarification
    Friday, December 2, 2011 8:14 PM
  • Bill,

    I have been watching a few comments come in on this without reading and responding to each comment or suggestion and it looks to have gone off topic.

    I would suggest in my specific domain we have very restricted PC's (Health-care) and there are items that need to be timestamped and as such only Domain admin have rights to change time.

    This may not be standard practice in most domains and as such it seems to give issues on devices that are used by non domain admins at times, not very often.

    I will suggest something is not right and I am seeking the correct solution as there are likely many other domains similar to ours.

    I have looked at our GPO and it seems correct, our Servers are correct and only the XP machines have the problems and there are know time sync problems with XP from what I have read.

    Perhaps you may care to help me identify and fix the item rather than posting all the regular links and suggestions that seem to point to standard GPO settings?

    IWell this is goign to continue I guess.  It is a good discussion an dperhaps we can clarify a few things.

    There are no issues with XP syncing in a domain except when there are issues of incorrect configuration.  We need to be very aggressive looking at event logs to determine the cause of any time sync issues.  Mostly we see this in domains with incorrect proxy setup or with infected machies.  In some cases ist is caused by protocol failure after someone has attempted to force the XP machine to sync on a particular server as is being done here.

    Ther are about a dozen KB articles on various ways to detect and fix sync issues. They should eb expolited.

    I manage hundreds of XP machines and have never had a time sync issue except in the early days (pre-SP2) where there was an issue the detail of which I don't fully remember.

    In any case a user can sync time if they are granted the right to set the system time.    I know of one company that has done this as as solution even though I have provento them that it is no necessary.

    One other case I haev seen is when a remote office is connected without a local DC.  Sometimes the link may be too buey or down when the system attempts sync.  Thisis alright as a good PC can hold clock resolution for days before it becomes and issue.  Just sacn the registry and you will see that the systme is getting sync ervery couple of days.  You can safely ignore the failure.  Time is set up this way on purpose.

    Many years ago we couldn't allow a host to go unsynced because clock drift was extremely bad.  Since about 1998 computer clocks have been very stable.  They generally have a positive drift built in that cause addition of no more that a secon every couple of days.  Active Directory can handle up to 5 minutes of drift unless you are in a high security environmentt anf the AD skew has been tightened.

    I guarantee you that a manual sync is NO different than an automatic sync.  Just be sure the computer account in AD is not corrupted.  This should be noticable from Event log entries when teh computer contacts AD on a reboot.

    Just think about it.  WHat does a manual sync do that an auto sync does not do?

    I have been down this path.  I spen many days starign and stopping services and trying to understand what was happening.  In the end the issue was always the network or the computer account.

    There is a utility that can be used to daignose W32Time issues.  It is called w32tm.  Type w32tm -? at a prompt.

    You can also set up acustom log file for the time service and it will give you very good detail telling you where the auot sync is failing and why.

    http://support.microsoft.com/kb/816043

     I almost forgot - the most common cause of time sync uissues is that GP has been set up adn is applying to all machines and redirecting the time service to an external source which is not available.

    Check RSOP on a machine that is failing to see if it is receiveing time policy.

    The probelm can be that this has been done in the past but the policy is still affecting the PC.  Yuo willneed to find the policy key for this in the PC and delete it and then check the Time Service keys to be sure they are set correctly to obtain time sync from the domain.

     


    jv
    • Edited by jrv Friday, December 2, 2011 8:27 PM
    Friday, December 2, 2011 8:19 PM