none
How to enable a low privilege user to run an administrative script ? RRS feed

  • Question

  • Hello

    I have a problem which seems to come from the lack of "sudo" in Windows.

    I want standard low privileges users to be enable to run a script that will give them a result (i-e DB status on Exchange). I don't want to give them any right, so the only solutions i think about are

     - to make a scheduled task on a server, and give them only the right to launch the task (but i'd prefer them not to be able to log on the server, so i don't like it)

     - To create a webpage (ASP.NET, i guess) that runs the script when they click a button. I'm not a dev, i won't be able to do it easily but i think i will have to.

    Do you have better ideas please ?

    Saturday, February 15, 2014 3:44 PM

Answers

  • - to make a scheduled task on a server, and give them only the right to launch the task (but i'd prefer them not to be able to log on the server, so i don't like it)

    You could indeed make use of a scheduled task like so, without granting the users admin privileges:

    1. Create a scheduled task to perform two actions:
      a) Check once every x minutes if a local semaphore file exists. If it does, execute the script (which must reside in a protected folder), then delete the semaphore file.
    2. Give the user a shortcut to generate the semaphore file.
    Saturday, February 15, 2014 8:26 PM

All replies

  • - to make a scheduled task on a server, and give them only the right to launch the task (but i'd prefer them not to be able to log on the server, so i don't like it)

    You could indeed make use of a scheduled task like so, without granting the users admin privileges:

    1. Create a scheduled task to perform two actions:
      a) Check once every x minutes if a local semaphore file exists. If it does, execute the script (which must reside in a protected folder), then delete the semaphore file.
    2. Give the user a shortcut to generate the semaphore file.
    Saturday, February 15, 2014 8:26 PM
  • It is possible that Forest brook's suggestion may be workable for you.

    However I would note that you cannot bypass the UAC prompt, and this is by design.

    A sudo-like capability is also missing by design. More information here:

    FAQ: Why can't I bypass the UAC prompt?

    Bill

    Sunday, February 16, 2014 4:59 AM
    Moderator
    1. Create a scheduled task to perform two actions:
      a) Check once every x minutes if a local semaphore file exists. If it does, execute the script (which must reside in a protected folder), then delete the semaphore file.
    2. Give the user a shortcut to generate the semaphore file.

    Yes, that's the way i forgot to write that i already thought of, and that seems to be the less unclean after the website that runs with privilege account. It's doable in my environment.

    I was in fact expecting a true clean way :-(



    Sunday, February 16, 2014 1:04 PM
  • It is possible that Forest brook's suggestion may be workable for you.

    However I would note that you cannot bypass the UAC prompt, and this is by design.

    A sudo-like capability is also missing by design. More information here:

    IMO, the reasons given in this article are bad : "Privilege escalation due to setuid and sudo has plagued Unix-like systems for many years" This is false when correctly set.

    Signed scripts could include authorizations to be ran from some chosen users...

    Thanks for the link anyway :)

    Sunday, February 16, 2014 1:11 PM
  • Signed scripts could include authorizations to be ran from some chosen users...

    This is not possible in Windows because an process that can escalate inside of a user process allows the user process namespace to access the processes security context. This makes it possible for the process to see the credentials of the script. The password also has to beencoded in a way that he user can decode so it is almost the same as giving out the admin password.

    UAC is designed to protect an admin.  Bypassing authentication or merging it with a users context defeats the security.

    The closes we can come is to delegate the authority carefully or to provide a proxy service that is secure.

    Access to read the Exchange DB status can be delegated without giving admin access to Exchange.  Post in Exchange forum to learn how to set up Exchange read-only operators.

    I recommend that this should be done as a set of reports exposed through a web site.  The reports can be generated daily or more frequently.  This would be more consistent with other management scenarios.


    ¯\_(ツ)_/¯

    Sunday, February 16, 2014 2:49 PM
  • Access to read the Exchange DB status can be delegated without giving admin access to Exchange.  Post in Exchange forum to learn how to set up Exchange read-only operators.

    I recommend that this should be done as a set of reports exposed through a web site.  The reports can be generated daily or more frequently.  This would be more consistent with other management scenarios.

    In fact, i have a very vast environment (300k users), several forests and don't want to give tools and rights if really unnecessary.

    I can accept to give the right to run a given script, not to give any rights on Exchange/AD/SCCM/Lync to some persons (hosting teams, or IT managers, in my case).

    I already have some running scripts that send reports daily, but for SOME scripts, i need them to be launched when ordered by some people.

    Sunday, February 16, 2014 3:15 PM
  • Well...Windows is Windows.  It cannot be made to work like Unix.  You need to understand how delegation is designed for Windows.  If a user needs access to a number for business reasons then there are mechanisms in Windows to delegate that value.  We can control almost every value individually.  If a user needs a number then what is the issue with giving then read access to that number?  How is that different from running a script to give them the number?

    Technical stubbornness is a huge impediment to technical learning.  Any technician or engineer who insists on using only old ideas will certainly not evolve into the newer technologies.

    Learn to think the Windows way and these things will not seem so difficult.


    ¯\_(ツ)_/¯

    Sunday, February 16, 2014 3:21 PM
  • IMO, the reasons given in this article are bad : "Privilege escalation due to setuid and sudo has plagued Unix-like systems for many years" This is false when correctly set.

    This is indeed a matter of opinion and could be debated endlessly. One point of view would be that if it is possible to configure an application so as to make it woefully insecure, then it shouldn't be allowed to be configured that way at all. I don't necessarily agree with that opinion, but some will disagree.

    My point isn't to completely agree with the article in every detail but rather to explain why Microsoft has made the willful decision to exclude a sudo-like feature.

    It is possible to use a semaphore solution with a scheduled task, but keep in mind that such scheduled task will only execute silently in the background.

    Bill

    Tuesday, February 18, 2014 2:35 AM
    Moderator