PDQ Deploy console must be run as an administrator (Server 2012)



  • Shane Corellian

    Hi Brad,

    Jason mentioned the current ticket that you have asking this same question.

    The requirement to run in elevated mode has been in PDQ Deploy since we merged the free and pro versions into one application back in 2011. If I recall the call out in the documentation regarding the permissions requirements to the database are there because a few of our customers had removed the default Administrator access to %ProgramData% to only allow specific accounts that, in their environments, didn't include the console or background service accounts. 

    The technical reasons for requiring that the console run in elevated mode are due to necessary access to HKLM, %ProgramFiles%, %ProgramData% and the fact that in early free app when someone wouldn't run the console as an administrator there were often authentication issues (even if the "deploy user" had admin rights) when it came to connecting to the remote target's Service Manager.

    There are also other non-technical reasons for this requirement. If we didn't require the console to run in elevated mode then a regular user could open PDQ Deploy and simply start deploying software and even making changes to previously set credentials.

    To help avoid confusion we will modify the documentation to specifically mention that elevated mode is required.

    Comment actions Permalink
  • Brad Black

    Hi Shane,

    I appreciate the response from the team but I do think the approach is coming in the wrong direction.  I mean that with all due respect because I have always appreciated the product capabilities and support your team has put forth in a relatively inexpensive package.  To scale well and bring in the medium/large businesses that have strict security principles is where I have difficulties in the logic.

    On the technical end those edits you mentioned has two points but think of the audience using the software:

    a) Any admin should know how to change permissions where needed on the three locations

    b) How does the logged in system user become problematic if the PDQ is really using the deploy credentials

    c) An admin can set PDQ to run as admin by default without having to specify it each time

    On the non-technical side:

    An admin can easily restrict who can and cannot login to a workstation/server remotely or interactively.  Using a group to allow logins is easy in any ldap structure and would keep regular users without the need to use PDQ off the system entirely.

    So, I guess what I'm trying to convey is that all the concerns I've heard so far are negated by Administrators or PDQ clients following basic enterprise security principles in my mind.  It seems to penalize the broader scope customers but like I said earlier I do like the value the software brings to the table.  As I transition from a mindset of small shop to large shop myself I have struggled with conceptual changes to the models I had established but in the end I have to evolve.  My questions were to hopefully express those views in a way that could entice positive change for the product.  I do wish that instead of simply changing the documentation to reflect more accurate statements that the group would consider changing the operational model.  Thank you again for the follow-up.

    Comment actions Permalink
  • Bret L

    This is a huge problem for me also ... is this going to be fixed?

    Since this server requires access to c$ of remote computers giving techs admin access to this box is a big issue

    Comment actions Permalink
  • Sharon Pulsifer

    I have the same problem as we strive to implement a least permission environment.

    Comment actions Permalink
  • Brad Black

    What I cannot begin to understand is...

    PDQ is such a great and useful product.  It solves a lot of problems for us at a good price point.

    That said, the individuals responsible for this part just plain and simple are dropping the ball.  First, don't write information to protected locations and write them to more public locations for simply starting the app.  Two, your customers know how to modify permissions as needed if you will define what is really taking place to cause it to happen.  At least that limits scope versus the need to be an overall admin on a machine.

    I'm just glad others have also thought this is an issue versus the alternative that I just was completely out of my mind.

    Comment actions Permalink

Please sign in to leave a comment.