none
Powershell Passing Credentials doesn't work for anyting except local admininstrator

    Pergunta

  • function Start-Localeventviewer {
    	$cred = Get-Credential
    	$StartInfo = New-Object System.Diagnostics.ProcessStartInfo
    	$StartInfo.UserName = $cred.Username
    	$StartInfo.Password = $cred.Password
    	$StartInfo.Filename = "$env:windir\system32\mmc.exe"
    	$StartInfo.Arguments = "$env:windir\system32\eventvwr.msc"
    	$StartInfo.LoadUserProfile = $true
    	$StartInfo.UseShellExecute = $false
    	[System.Diagnostics.Process]::Start($StartInfo)
    }
    
    Start-Localeventviewer

    With the above code... on my machine... if I enter:

    Administrator - it works

    MachineName\Administrator - it works

    MyDomain\MyName - it doesn't work (I'm a domain admin)

    MyDomain\AnotherDomainUser - it doesn't work (Password entered by that person, is in a locl machine admin group)

    MachineName\LocalAccount - it doesn't work (non admin)

    MachineName\LocalAccount - it doesn't work (in local administrators group)

    Can anyone explain why only the Built-In Administrator account works?

    And... how to get other credentials working. 

    Thanks!

    quarta-feira, 15 de fevereiro de 2012 23:54

Respostas

  • 1. I don't want to run the process as myself NOR as the built-in administrator... which is why I was experimenting with alternate credentials.

    2. The console is ALREADY elevated from launching the powershell console "as administrator" and running the script

    3. Without the verb attempt... the only credential that works is the built-in administrator. Period.  I don't know how else to describe the issue.

    Pretty much... the process needs to run as a different domain account that has administrative rights.

    I hope the helps describe what I'm trying to do, so I don't get any more unhelpful remarks like: "So elevate.  The message is pretty darn clear."



    THe coole is only elevated for the account you are currently running with. As soon as you 'proxy' a new account you are no longer elevated so you need to elevate that account to do whatever you are trying to do.  Some thnigs  may not be allowed on your network due to policy. 

    If you are already elevated theen 'RunAs' is meaningless. 

    As noted above you cannot use both 'credential' and 'verb' in the same command at teh same time.

    Put all of that together and you cannot do what you seem to be trying to do.

    The problem is not with our recommendations but is with your desire to do something that is not possible.

    The line quoted comes from teh error message you posted.  It is not what we are posting except as a pointer.

    You posted this error: 

    Start-Process : This command cannot be executed due to the error: The requested operation requires elevation.

    At C:\Users\h9067wca\Documents\Scripts\!test2.ps1:3 char:15

    +     Start-Process <<<<  -file $env:windir\system32\mmc.exe -arg $env:windir\system32\eventvwr.msc -cred $cred

        + CategoryInfo          : InvalidOperation: (:) [Start-Process], InvalidOperationException

        + FullyQualifiedErrorId : InvalidOperationException,Microsoft.PowerShell.Commands.StartProcessCommand

    This is running under an admin opened console.  If I add the runas verb I get:

    Start-Process : Parameter set cannot be resolved using the specified named parameters.
    At C:\Users\h9067wca\Documents\Scripts\!test2.ps1:3 char:15
    +     Start-Process <<<<  -file $env:windir\system32\mmc.exe -arg $env:windir\system32\eventvwr.msc -cred $cred -Verb Runas
        + CategoryInfo          : InvalidArgument: (:) [Start-Process], ParameterBindingException
        + FullyQualifiedErrorId : AmbiguousParameterSet,Microsoft.PowerShell.Commands.StartProcessCommand

    Both errors explain clearly what you re doing wrong.

    So use credentials then elevate. Yuo must do that in order to make this work.  Start a second script that executes the process.

    start-process -file powershell -arg c:\scripts\elevate.ps1 -cred $cred

    Put the runas in the 'elevate.ps1' script.

    It seems like you are gong to a lot of trouble which makes me suspect you are trying to do something that maybe can be done in a more direct way.  If you would make your intentions clear maybe someone can show you how to do this.

    Your iritation shows that you are not very clear on how UAC or running with credentails works.  They are not the same thing.  When using credetials you are starting a whole new logon session.  You are not just changing your identity.  In WIndows you cannot change your identity. YOu always have to run in a new secured session when 'impersonating'.  The new session inherits absolutely nothing frpom the creating session so when you say tou are running from an elevated prompt you are not running elevated once you start a new process with new credentials.  Hence trhe statement "So elevate".  The error message was very clear.

    I understand that you are not a technicain or a programmer so much of this may be a bit confusing but you really need to follow Bill's link and read up on credentials and elevation.  You will need to fully understand this with Vista and later if you plane on running any kind of administrative tools.

    The usual way we launch tools in an admin process is to create a shortcut that elevates.

    Another thing to note is that running Event Viewer does not require elevation if you run it directly.

    Start-Process eventvwr.msc

    or just

    eventvwr.msc

    At the command line

    No need to run MMC then add the snapin.  The snapin already runs in MMC.

    All of this is pretty much basic Windows so I ma not sure why you are trying to run this elevated or with new credentials. The event viewer does not require admin credentials to run.  Just run it.

    You can also get events very easily using Get-WinEvent which takes credentials.  It can be run remotely against any Vista and later system,

    Most of the time when problems seem to be intractable it is because we are asking the wrong question or trying to do something in a way that was never intended by the designers of a system.


    ¯\_(ツ)_/¯

    • Marcado como Resposta W.Allen sexta-feira, 17 de fevereiro de 2012 15:51
    quinta-feira, 16 de fevereiro de 2012 10:36

Todas as Respostas

  • function Start-Localeventviewer { $cred = Get-Credential $StartInfo = New-Object System.Diagnostics.ProcessStartInfo $StartInfo.UserName = $cred.Username $StartInfo.Password = $cred.Password $StartInfo.Filename = "$env:windir\system32\mmc.exe" $StartInfo.Arguments = "$env:windir\system32\eventvwr.msc" $StartInfo.LoadUserProfile = $true $StartInfo.UseShellExecute = $false [System.Diagnostics.Process]::Start($StartInfo) } Start-Localeventviewer

    With the above code... on my machine... if I enter:

    Administrator - it works

    MachineName\Administrator - it works

    MyDomain\MyName - it doesn't work (I'm a domain admin)

    MyDomain\AnotherDomainUser - it doesn't work (Password entered by that person, is in a locl machine admin group)

    MachineName\LocalAccount - it doesn't work (non admin)

    MachineName\LocalAccount - it doesn't work (in local administrators group)

    Can anyone explain why only the Built-In Administrator account works?

    And... how to get other credentials working. 

    Thanks!

    username and password won't work in this context.

    Try it this way:
    Start-Process -file $env:windir\system32\mmc.exe -arg $env:windir\system32\eventvwr.msc -cred $cred

    This will launch the process correctly with credentials assuming your network admins have not blocked this.



    ¯\_(ツ)_/¯

    quinta-feira, 16 de fevereiro de 2012 00:49
  • Actually I tried it via Start-Process first... no go... same problem

    Here is the error under my credentials:

    Start-Process : This command cannot be executed due to the error: The requested operation requires elevation.

    At C:\Users\h9067wca\Documents\Scripts\!test2.ps1:3 char:15

    +     Start-Process <<<<  -file $env:windir\system32\mmc.exe -arg $env:windir\system32\eventvwr.msc -cred $cred

        + CategoryInfo          : InvalidOperation: (:) [Start-Process], InvalidOperationException

        + FullyQualifiedErrorId : InvalidOperationException,Microsoft.PowerShell.Commands.StartProcessCommand

    This is running under an admin opened console.  If I add the runas verb I get:

    Start-Process : Parameter set cannot be resolved using the specified named parameters.
    At C:\Users\h9067wca\Documents\Scripts\!test2.ps1:3 char:15
    +     Start-Process <<<<  -file $env:windir\system32\mmc.exe -arg $env:windir\system32\eventvwr.msc -cred $cred -Verb Runas
        + CategoryInfo          : InvalidArgument: (:) [Start-Process], ParameterBindingException
        + FullyQualifiedErrorId : AmbiguousParameterSet,Microsoft.PowerShell.Commands.StartProcessCommand

     

    quinta-feira, 16 de fevereiro de 2012 00:59
  • Actually I tried it via Start-Process first... no go... same problem

    Here is the error under my credentials:

    This is running under an admin opened console.  If I add the runas verb I get:

    Start-Process : Parameter set cannot be resolved using the specified named parameters.
    At C:\Users\h9067wca\Documents\Scripts\!test2.ps1:3 char:15
    +     Start-Process <<<<  -file $env:windir\system32\mmc.exe -arg $env:windir\system32\eventvwr.msc -cred $cred -Verb Runas
        + CategoryInfo          : InvalidArgument: (:) [Start-Process], ParameterBindingException
        + FullyQualifiedErrorId : AmbiguousParameterSet,Microsoft.PowerShell.Commands.StartProcessCommand

    Start-Process : This command cannot be executed due to the error: The requested operation requires elevation.

    At C:\Users\h9067wca\Documents\Scripts\!test2.ps1:3 char:15

    +     Start-Process <<<<  -file $env:windir\system32\mmc.exe -arg $env:windir\system32\eventvwr.msc -cred $cred

        + CategoryInfo          : InvalidOperation: (:) [Start-Process], InvalidOperationException

        + FullyQualifiedErrorId : InvalidOperationException,Microsoft.PowerShell.Commands.StartProcessCommand

    So elevate.  The message is pretty darn clear.

    You must run from an elevated session in order to run MMC in Vista and later.


    ¯\_(ツ)_/¯

    quinta-feira, 16 de fevereiro de 2012 01:19
  • Actually I tried it via Start-Process first... no go... same problem

    Here is the error under my credentials:

    Start-Process : This command cannot be executed due to the error: The requested operation requires elevation.

    At C:\Users\h9067wca\Documents\Scripts\!test2.ps1:3 char:15

    +     Start-Process <<<<  -file $env:windir\system32\mmc.exe -arg $env:windir\system32\eventvwr.msc -cred $cred

        + CategoryInfo          : InvalidOperation: (:) [Start-Process], InvalidOperationException

        + FullyQualifiedErrorId : InvalidOperationException,Microsoft.PowerShell.Commands.StartProcessCommand

    This is running under an admin opened console.  If I add the runas verb I get:

    Start-Process : Parameter set cannot be resolved using the specified named parameters.
    At C:\Users\h9067wca\Documents\Scripts\!test2.ps1:3 char:15
    +     Start-Process <<<<  -file $env:windir\system32\mmc.exe -arg $env:windir\system32\eventvwr.msc -cred $cred -Verb Runas
        + CategoryInfo          : InvalidArgument: (:) [Start-Process], ParameterBindingException
        + FullyQualifiedErrorId : AmbiguousParameterSet,Microsoft.PowerShell.Commands.StartProcessCommand

     

    You can't use -Cred and -Verb as they are in different parameter sets. Just use -Verb and it should work.

    Start-Process -file $env:windir\system32\mmc.exe -arg $env:windir\system32\eventvwr.msc -Verb Runas




    Boe Prox

    Please remember to mark the best solution as the answer using Mark as Answer. If you find a solution to be helpful, please use Vote as Helpful.

    Looking for a script? Check out the Script Repository
    Need a script written for you? Submit a request at the Script Request Page

    • Sugerido como Resposta jrv quinta-feira, 16 de fevereiro de 2012 02:36
    quinta-feira, 16 de fevereiro de 2012 01:58
    Moderador
  • Boe - good call.

    Start-Process : Parameter set cannot be resolved using the specified named parameters


    ¯\_(ツ)_/¯

    quinta-feira, 16 de fevereiro de 2012 02:36
  • 1. I don't want to run the process as myself NOR as the built-in administrator... which is why I was experimenting with alternate credentials.

    2. The console is ALREADY elevated from launching the powershell console "as administrator" and running the script

    3. Without the verb attempt... the only credential that works is the built-in administrator. Period.  I don't know how else to describe the issue.

    Pretty much... the process needs to run as a different domain account that has administrative rights.

    I hope the helps describe what I'm trying to do, so I don't get any more unhelpful remarks like: "So elevate.  The message is pretty darn clear."



    • Editado W.Allen quinta-feira, 16 de fevereiro de 2012 03:19
    quinta-feira, 16 de fevereiro de 2012 03:17
  • 1. I don't want to run the process as myself NOR as the built-in administrator... which is why I was experimenting with alternate credentials.

    2. The console is ALREADY elevated from launching the powershell console "as administrator" and running the script

    3. Without the verb attempt... the only credential that works is the built-in administrator. Period.  I don't know how else to describe the issue.

    Pretty much... the process needs to run as a different domain account that has administrative rights.

    I hope the helps describe what I'm trying to do, so I don't get any more unhelpful remarks like: "So elevate.  The message is pretty darn clear."



    THe coole is only elevated for the account you are currently running with. As soon as you 'proxy' a new account you are no longer elevated so you need to elevate that account to do whatever you are trying to do.  Some thnigs  may not be allowed on your network due to policy. 

    If you are already elevated theen 'RunAs' is meaningless. 

    As noted above you cannot use both 'credential' and 'verb' in the same command at teh same time.

    Put all of that together and you cannot do what you seem to be trying to do.

    The problem is not with our recommendations but is with your desire to do something that is not possible.

    The line quoted comes from teh error message you posted.  It is not what we are posting except as a pointer.

    You posted this error: 

    Start-Process : This command cannot be executed due to the error: The requested operation requires elevation.

    At C:\Users\h9067wca\Documents\Scripts\!test2.ps1:3 char:15

    +     Start-Process <<<<  -file $env:windir\system32\mmc.exe -arg $env:windir\system32\eventvwr.msc -cred $cred

        + CategoryInfo          : InvalidOperation: (:) [Start-Process], InvalidOperationException

        + FullyQualifiedErrorId : InvalidOperationException,Microsoft.PowerShell.Commands.StartProcessCommand

    This is running under an admin opened console.  If I add the runas verb I get:

    Start-Process : Parameter set cannot be resolved using the specified named parameters.
    At C:\Users\h9067wca\Documents\Scripts\!test2.ps1:3 char:15
    +     Start-Process <<<<  -file $env:windir\system32\mmc.exe -arg $env:windir\system32\eventvwr.msc -cred $cred -Verb Runas
        + CategoryInfo          : InvalidArgument: (:) [Start-Process], ParameterBindingException
        + FullyQualifiedErrorId : AmbiguousParameterSet,Microsoft.PowerShell.Commands.StartProcessCommand

    Both errors explain clearly what you re doing wrong.

    So use credentials then elevate. Yuo must do that in order to make this work.  Start a second script that executes the process.

    start-process -file powershell -arg c:\scripts\elevate.ps1 -cred $cred

    Put the runas in the 'elevate.ps1' script.

    It seems like you are gong to a lot of trouble which makes me suspect you are trying to do something that maybe can be done in a more direct way.  If you would make your intentions clear maybe someone can show you how to do this.

    Your iritation shows that you are not very clear on how UAC or running with credentails works.  They are not the same thing.  When using credetials you are starting a whole new logon session.  You are not just changing your identity.  In WIndows you cannot change your identity. YOu always have to run in a new secured session when 'impersonating'.  The new session inherits absolutely nothing frpom the creating session so when you say tou are running from an elevated prompt you are not running elevated once you start a new process with new credentials.  Hence trhe statement "So elevate".  The error message was very clear.

    I understand that you are not a technicain or a programmer so much of this may be a bit confusing but you really need to follow Bill's link and read up on credentials and elevation.  You will need to fully understand this with Vista and later if you plane on running any kind of administrative tools.

    The usual way we launch tools in an admin process is to create a shortcut that elevates.

    Another thing to note is that running Event Viewer does not require elevation if you run it directly.

    Start-Process eventvwr.msc

    or just

    eventvwr.msc

    At the command line

    No need to run MMC then add the snapin.  The snapin already runs in MMC.

    All of this is pretty much basic Windows so I ma not sure why you are trying to run this elevated or with new credentials. The event viewer does not require admin credentials to run.  Just run it.

    You can also get events very easily using Get-WinEvent which takes credentials.  It can be run remotely against any Vista and later system,

    Most of the time when problems seem to be intractable it is because we are asking the wrong question or trying to do something in a way that was never intended by the designers of a system.


    ¯\_(ツ)_/¯

    • Marcado como Resposta W.Allen sexta-feira, 17 de fevereiro de 2012 15:51
    quinta-feira, 16 de fevereiro de 2012 10:36
  • Agree - more understanding is needed. What is the specific problem/scenario you want to address?

    Bill

    quinta-feira, 16 de fevereiro de 2012 15:18
    Moderador
  • >>>

    The problem is not with our recommendations but is with your desire to do something that is not possible.

    <<<

    Well, that's what I was trying to find out... why it's not possible.  What good is passing alternate credentials to Start-Process, if it mostly doesn't work?

    I will try your code that involves a second script, though.

    >>>

    Agree - more understanding is needed. What is the specific problem/scenario you want to address?

    <<<

    We are trying to allow certain users to access event logs on servers, that we do not wish to give them actual logon access to.  On servers with 2008 R2 we can put them in the "Event Log Readers" group, but this won't work for our Server 2003 servers. These users do have admin rights to their local workstations.

    Writing a script to dump the data into a CSV or GridView is also unacceptable.  They supposidly need access to an actual event-viewer (This is a political thing).

    Running eventvwr \\servername works for me, but I obviously have access to all servers.  The idea was to make a dummy account, and pass the encrypted credentials with in a script to lauch the eventviewer under those credentials... which the dummy account would have access to the server, but the user would never see the password.

    The initial post came directly out of "Windows Powershell in Action", with only the application changed.  From that point I was just trying several different credentials to see what worked vs what didn't.... and only the built-in local-machine administrator account works (whether I launch the console as administrator or not)...  which is useless, for domain environments, in my opinion. Anyway... originally I was running start-process eventvwr -arguments \\servername... I was just trying to figure out how the credentials thing worked (or not).





    • Editado W.Allen quinta-feira, 16 de fevereiro de 2012 16:25
    quinta-feira, 16 de fevereiro de 2012 16:16
  • Ok... this works (sort of)....

    Script that is launched:

    function Start-Localeventviewer {
    	$cred = Get-Credential
    	Start-Process -FilePath powershell -argumentlist "C:\temp\Elevate.ps1" -cred $cred
    }
    
    Start-Localeventviewer

    And Calls the Second Script:

    Start-Process eventvwr -ArgumentList \\SERVERNAME -Verb RunAs

    So, pretty much, what I need is a way to pass the servername to the second script... which I'm not sure how to do since the -argumentlist is already taken for launching powershell.  I know I need to put a pram statement in the second script... but I'm not sure how to nest "argumentlists".

    Thanks for pointing me in the right direction.

    While UAC is a security benefit... it can also be an administrative hinderance.


    Obviously later, I will embed the credential in the script... the get-credential is just for testing.
    • Editado W.Allen quinta-feira, 16 de fevereiro de 2012 17:38
    quinta-feira, 16 de fevereiro de 2012 17:37
  • Hi,

    You could use the same script, test for elevation, and if not elevated, have the script call itself elevated. Here's a short proof-of-concept:

    param([String] $ComputerName)
    
    $identity = [Security.Principal.WindowsIdentity]::GetCurrent()
    $principal = New-Object Security.Principal.WindowsPrincipal($identity)
    $elevated = $principal.IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator)
    
    if (-not $Elevated) {
      start-process "$PSHOME\powershell.exe" -verb runas -argumentlist "-file ""$($MYINVOCATION.MyCommand.Definition)"" ""$ComputerName"""
      exit
    }
    
    "" | select-object @{N="Name"; E={$identity.Name}},
      @{N="Elevated"; E={$elevated}},
      @{N="ComputerName"; E={$ComputerName}} | ft -auto
    
    write-host -nonewline "`r`nPress ENTER to continue:"
    read-host
    

    HTH,

    Bill

    quinta-feira, 16 de fevereiro de 2012 18:02
    Moderador
  •  

    We are trying to allow certain users to access event logs on servers, that we do not wish to give them actual logon access to.  On servers with 2008 R2 we can put them in the "Event Log Readers" group, but this won't work for our Server 2003 servers. These users do have admin rights to their local workstations.

    And this is the real solution to your problem.  Just do the same for the WS2003 servers.  Create a group that allows reading the log and add it to the security of the Event Log service.  This is the way we have been doing this for since NT4 I believe.  In WS2008 Microsoft has just done this in advance because it is so common.

    Running eventvwr \\servername works for me, but I obviously have access to all servers.  The idea was to make a dummy account, and pass the encrypted credentials with in a script to lauch the eventviewer under those credentials... which the dummy account would have access to the server, but the user would never see the password.

    The initial post came directly out of "Windows Powershell in Action", with only the application changed.  From that point I was just trying several different credentials to see what worked vs what didn't.... and only the built-in local-machine administrator account works (whether I launch the console as administrator or not)...  which is useless, for domain environments, in my opinion. Anyway... originally I was running start-process eventvwr -arguments \\servername... I was just trying to figure out how the credentials thing worked (or not).

    Part of your problem is that elevation with the verb ‘RunAs’ is only for the local machine.  It has no meaning remotely or with alternate credentials.

    Again.  Event Viewer does not require elevation.  What is required is that the user’s account has read access to the event log.  You have it on WS2008 so just add a similar group to WS2003.

    Now create an MMC snap-in that is connected to the servers the users need to see and place it on a network share and place a shortcut on their desktop.

    There is no need for a script. In fact using a script is exactly the most difficult way to accomplish this task.


    ¯\_(ツ)_/¯

    quinta-feira, 16 de fevereiro de 2012 18:22
  •  

    You should all note that a standard user account only has access to the local event logs.  Remote event log access r4equires an administrator.

    Encrypting an administrators password into a user account is not secure because as long as the users account use the credentials they can be used any time by just retrieving them and using them as is.

    This is also a violation of Sarbanes-Oxley, HIPAA and nearly all corporate insurance policies governing liability and damage caused by a break-in.

    The Windows security model s designed around the concept of delegation of authority to perform tasks.  A user is not given rights in many places but the security infrastructure makes it easy to give a user rights through a Security Group.  That is why it is called a security group.  Place object in it an grant the group the rights.  The member objects now gain those rights.

    This is very basic Windows administration and used to constitute a  very large number of the questions on the MCP and MCSE exams.  It is still in the newer exams although it appears that n assumption has been made that most already understand this.

    You can use SC to set the group on the Event Log service.  Now anyone in the group can access the service remotely.  If yu need access to the security log you will need to grant the security token to the group also.

    Another excellent way to allow users to access event log records securely is to use WS2008 to subscript to the events and save them to a custom log.  Now anyone with access through the Event Log Readers group can access all of the events throughout the network with just one log view.  The events should be selected to just be those they need by provider and Event ID.

    In WS2008 we can also save the users a trip to the event log.  We can just filter the events and email them to the users or even send a network alert.

     


    ¯\_(ツ)_/¯

    quinta-feira, 16 de fevereiro de 2012 18:38
  • Well setting permissions on the event log service via group policy ala:

    http://support.microsoft.com/kb/324802/EN-US

    Didn't work.  And I haven't found SVCALCS.EXE yet (I have to dig to find old resource kits)

    What is SC?

    quinta-feira, 16 de fevereiro de 2012 21:10
  • Well setting permissions on the event log service via group policy ala:

    http://support.microsoft.com/kb/324802/EN-US

    Didn't work.  And I haven't found SVCALCS.EXE yet (I have to dig to find old resource kits)

    What is SC?

    The program is SC.EXE and is installed on all systems.

    Type: SC /?

    You may also have to address remoting issues.  Standard users do not normally have remoting capability.


    ¯\_(ツ)_/¯


    • Editado jrv quinta-feira, 16 de fevereiro de 2012 21:19
    quinta-feira, 16 de fevereiro de 2012 21:18
  • I should also mention that after setting security on the EL service you need to resart teh coputer.  The only time the security is applied is at startup. The EL service cannot be stopped and started.  You must restart the computer.


    ¯\_(ツ)_/¯

    quinta-feira, 16 de fevereiro de 2012 21:28
  • I should also warn you that if you just try and take the defaults in GP for a service it will not tell you the current settings.  If you enable the security it will overwrite teh security on the servic and may make the service unusable. 

    Be careful. Unless you are sure of what you are doing don't mke the change.

    SC can save the current SD so it can be replaced.  Do your testing on a LAB machine.

    A hung event log will prevent a machine from restarting.


    ¯\_(ツ)_/¯

    quinta-feira, 16 de fevereiro de 2012 21:38
  • Here is the KB for WS2003 for granting users access to teh event logs via policy, registry and GPO settings.

    Read it very carefully

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


    ¯\_(ツ)_/¯

    quinta-feira, 16 de fevereiro de 2012 21:41
  • This is beyond a pain in the rear.

    Before your post I tried the following for the eventlog service on a 2003 server:

    http://kevin.vanzonneveld.net/techblog/article/allow_windows_users_to_restart_service/

    And it did not work.  (Yes, I restarted the server) I got the sid of the group I wanted allow with get-qadobject.

    I will try the article that you linked and see if I have better luck.

    Thanks.

    quinta-feira, 16 de fevereiro de 2012 22:53
  • This is beyond a pain in the rear.

    Before your post I tried the following for the eventlog service on a 2003 server:

    http://kevin.vanzonneveld.net/techblog/article/allow_windows_users_to_restart_service/

    And it did not work.  (Yes, I restarted the server) I got the sid of the group I wanted allow with get-qadobject.

    I will try the article that you linked and see if I have better luck.

    Thanks.

    As I posted above.  That method cannot be used on the Event Log service.  It is for standard services.  Eventlogs have ther very own security settings.


    ¯\_(ツ)_/¯

    quinta-feira, 16 de fevereiro de 2012 22:56
  • I'm marking this as the answer since it pertains to the original question of passing credentials in Powershell... and how to elevate.

    As for the alternate solution of changing the eventlog security...  I'll keep working on that, but it has nothing to do with scripting.

    Thanks,

    sexta-feira, 17 de fevereiro de 2012 15:53
  • I'm marking this as the answer since it pertains to the original question of passing credentials in Powershell... and how to elevate.

    As for the alternate solution of changing the eventlog security...  I'll keep working on that, but it has nothing to do with scripting.

    Thanks,

    Just to be sure I used the article and set one server that had not already been set. It took me al of temn minutes to get GP to display the new options and a vpouple of minutes to mofify the sSDDL to add the ELReaders group with read privileges (same as Interactive just copy and change the SID).


    ¯\_(ツ)_/¯

    sexta-feira, 17 de fevereiro de 2012 16:09