2010-02-11 25 views
10

OK aquí está mi problema:Ejecute el comando como administrador en el script de PowerShell. UAC

Estoy tratando de ejecutar un script de forma remota en un servidor.

Soy un administrador en ambas casillas, las excepciones de cortafuegos están en su lugar, el administrador remoto está habilitado y todo lo demás se ve bien que puedo ver.

invoke-command -ComputerName $ComputerName -ScriptBlock ` 
{ 
    cd C:\Windows\System32\inetsrv\; 
    ./appcmd.exe ADD vdir /app.name:<SiteName>/ /path:/<VDir Name> /physicalPath:<Path to files> 
} 

Sigo recibiendo el siguiente error en el retorno

ERROR (hresult:80070005, message:Failed to commit configuration changes. Access is denied. 

El servidor que está tratando de ejecutar en un servidor 2k8 cuadro R2 y estoy pensando en el problema es un problema de UAC. ¿Hay alguna forma de que esto se ejecute como administrador sin tener que hacer clic en Sí en un cuadro de UAC?

Este código se convertirá finalmente en un script que deberá estar completamente automatizado.

Cualquier ayuda sería muy apreciada.

+0

Bien, no es UAC. Inhabilité el UAC, el firewall y todo lo demás que podría pensar que interferiría. También hice el cambio de registro sugerido por tyranid. ninguno funciona es extraño. dice que la operación fue exitosa y luego da el mismo acceso. Se niega el error. – Tim

+0

¿Puedes ejecutar 'whoami/all' en la instancia remota de PowerShell y ver qué permisos tienes en realidad? – tyranid

+0

Ejecuté el comando y enumeré el nombre de mi cuenta de dominio, los grupos de los que soy miembro en el dominio y una lista de privilegios. todos los privilegios fueron a nivel de administrador y habilitados, uno de los grupos enumerados se encuentra en el grupo Administradores y todo se ve bien. – Tim

Respuesta

10

OK. Después de algunas investigaciones y pruebas, descubrí el problema. Después de desactivar el UAC y el firewall y el script aún no funcionaba, profundicé un poco más y descubrí que el problema principal era la forma en que invoke-command ejecuta los comandos. usa las credenciales de la persona que ejecuta el script para autenticarse en el servidor y luego intenta usar otra cuenta para ejecutar los permisos o disminuir los privilegios del usuario para que no se puedan ejecutar ciertos comandos.

Agregué el interruptor -Credentials al comando invoke y todo está funcionando bien ahora. Corregido ejemplo de código a continuación:

$user = New-Object Management.Automation.PSCredential("$UserName", $securePassword) 
invoke-command -ComputerName $ComputerName -Credential $user -ScriptBlock ` 
{ 
    cd C:\Windows\System32\inetsrv\; 
    ./appcmd.exe ADD vdir /app.name:<SiteName>/ /path:/<VDir Name> /physicalPath:<Path to files> 
} 
+0

¿Entonces cuando se escribe algo que requiere derechos de administrador, no hay mejor manera que tener el nombre de usuario y la contraseña en texto claro en el script? ¿De Verdad? ejecutar el servicio como administrador no es suficiente ... ¿Cuál es la mejor práctica para escribir, por ejemplo, una instalación de servicio de Windows que requiere derechos de administrador? –

+1

La alternativa es permitir que el usuario ingrese las credenciales a través del cmdlet Get-Credential. – riezebosch

-3

¿Hay alguna forma de que esto se ejecute como administrador sin tener que hacer clic en Sí en un cuadro de UAC?

Si esto fuera posible, se anularía completamente el punto de UAC.

Por lo tanto, parece que su única solución real es desactivar el UAC en la caja.

+0

Desafortunadamente, la desactivación de UAC no es una opción, ya que estará en servidores de alta visibilidad. Esperemos que alguien pueda encontrar una solución o una solución alternativa. Tal vez solo estoy haciendo algo mal. – Tim

+0

La otra alternativa sería tener todo lo que inicie estos scripts en ejecución elevada; luego puede generar otros procesos elevados sin requerir otra confirmación de UAC. –

+0

La única pregunta que tengo es que se transferirá de forma remota. Este script ejecutará diferentes comandos en varios servidores desde un servidor de administración. Entonces, el Servidor A (mgmt) ejecuta comandos de forma remota en los servidores 1, 2 y 3. Si el Proceso se está ejecutando como elevado en el Servidor A, se ejecutará como elevado en los Servidores 1, 2 y 3. – Tim

0

This parece indicar que debe asegurarse de que es un administrador local en la máquina remota (aunque es cierto que esto es específicamente para WMI). De acuerdo con this, puede cambiar una clave de registro para detener la aplicación de UAC a los inicios de sesión remotos para los administradores (busque LocalAccountTokenFilterPolicy). Eso no debería deshabilitar el UAC simplemente no filtrar el token si usa powershell/WMI de forma remota con una cuenta de administrador.

-3

Ajuste la opción (valor DWORD) "EnableLUA" que se encuentra en HKLM \ SOFTWARE \ Microsoft \ Windows \ CurrentVersion \ Policies \ System a 0 y reiniciar el sistema.

Esto deshabilitará el UAC sin ningún problema, lo haría para todos sus usuarios, ya sea con o sin permiso, depende de usted, porque el UAC de vista es tan horrible que creo que menos personas lo tienen en el mejor (al menos en vista) lo son. Este truco también funciona en Win7.

Diviértete con mi registro truco :)

PS: Pues resulta que también lo es censurar los comentarios que muestran cómo deshabilitar el UAC en lo que se refiere a mi post/hilo con la respuesta anterior (una respuesta diligente era remoto).

+2

No creo que te estén censurando en la forma en que lo dices en serio. Mi mejor estimación es que recomiendas algo que puede representar un riesgo de seguridad para un usuario casual. UAC está allí por alguna razón si esto se logra con éxito o no está más allá del alcance de esta pregunta;) – Kounavi

+0

@Kounavi bien sí, tienes razón, está más allá del alcance de esta pregunta, por eso respondí la pregunta e incluí mi otro comentario como un comentario lateral. si algo se hace de una manera tan horrible, se debe protestar y deshabilitar para enseñarles una lección a los desarrolladores, y más importante aún, dado que el desastre provocado por esto supera la seguridad que proporciona, esta fue una de las principales razones por las cuales Vista fue un desastre colosal. –

Cuestiones relacionadas