¿Cómo verifico si el script por lotes actual tiene derechos de administrador?
Sé cómo hacer que se llame a sí mismo con runas, pero no cómo verificar los derechos de administrador. Las únicas soluciones que he visto son trabajos crudos de pirateo o uso de programas externos. Bueno, en realidad no me importa si es un trabajo de pirateo, siempre y cuando funcione en Windows XP y versiones posteriores.
windows
batch-file
cmd
admin
Flacs
fuente
fuente
Respuestas:
Cuestiones
La solución de blak3r / Rushyo funciona bien para todo excepto Windows 8. La ejecución
AT
en Windows 8 da como resultado:(ver captura de pantalla # 1) y volverá
%errorLevel%
1
.Investigación
Entonces, busqué otros comandos que requieren permisos elevados. racionallyparanoid.com tenía una lista de algunos, por lo que ejecuté cada comando en los dos extremos opuestos de los sistemas operativos Windows actuales (XP y 8) con la esperanza de encontrar un comando al que se le negaría el acceso en ambos sistemas operativos cuando se ejecuta con permisos estándar.
Finalmente, encontré uno -
NET SESSION
. Una solución verdadera , limpia y universal que no involucra:FOR
buclesAT
(Windows 8 incompatible) oWHOAMI
(Windows XP incompatible).Cada uno de ellos tiene sus propios problemas de seguridad, usabilidad y portabilidad.
Pruebas
He confirmado independientemente que esto funciona en:
(ver captura de pantalla # 2)
Implementación / Uso
Entonces, para usar esta solución, simplemente haga algo como esto:
Disponible aquí, si eres flojo: https://dl.dropbox.com/u/27573003/Distribution/Binaries/check_Permissions.bat
Explicación
NET SESSION
es un comando estándar utilizado para "administrar las conexiones de la computadora del servidor. Usado sin parámetros, [muestra] información sobre todas las sesiones con la computadora local".Entonces, aquí está el proceso básico de mi implementación dada:
@echo off
goto check_Permissions
:check_Permissions
bloque de códigonet session >nul 2>&1
STDOUT
) anul
STDERR
) al mismo destino que el manejador numérico 1if %errorLevel% == 0
%errorLevel%
) es0
, esto significa que no se han producido errores y, por lo tanto, el comando anterior inmediato se ejecutó correctamenteelse
%errorLevel%
) no es0
, esto significa que se han producido errores y, por lo tanto, el comando anterior inmediato se ejecutó sin éxitoCapturas de pantalla
Windows 8
AT
%errorLevel%
:NET SESSION
en Windows XP x86 - Windows 8 x64 :Gracias, @Tilka, por cambiar tu respuesta aceptada a la mía. :)
fuente
net session
éxito (ERRORLEVEL = 0), pero en realidad no tiene derechos de administrador. Usaropenfiles
(ver la respuesta de Lucrecio a continuación) no tiene este problema.La solución de Anders funcionó para mí, pero no estaba seguro de cómo invertirla para obtener lo contrario (cuando no eras un administrador).
Aquí está mi solución. Tiene dos casos, un caso IF y ELSE, y algunas ilustraciones para asegurar que la gente realmente lo lea. :)
Versión mínima
Rushyo publicó esta solución aquí: ¿Cómo detectar si CMD se está ejecutando como Administrador / tiene privilegios elevados?
Versión que agrega mensajes de error, pausas y salidas
Funciona en WinXP -> Win8 (incluidas las versiones de 32/64 bits).
EDITAR: 28/08/2012 Actualizado para admitir Windows 8. @BenHooper señaló esto en su respuesta a continuación. Por favor vota su respuesta.
fuente
AT
no funciona en Windows 8, pero he encontrado una mejor solución. Lo publiqué como respuesta aquí, en realidad: stackoverflow.com/questions/4051883/… (o simplemente puede desplazarse hacia abajo, lo que sea).Más problemas
Como señaló @Lectrode, si intenta ejecutar el
net session
comando mientras el servicio del servidor está detenido, recibirá el siguiente mensaje de error:En este caso, la
%errorLevel%
variable se establecerá en2
.Nota El servicio del servidor no se inicia mientras está en modo seguro (con o sin conexión de red).
Buscando una alternativa
Algo que:
Así que inicié una máquina virtual Windows XP de vainilla y comencé a desplazarme por la lista de aplicaciones en la
C:\Windows\System32
carpeta, intentando obtener algunas ideas. Después de pruebas y errores, este es el enfoque sucio (juego de palabras) que se me ocurrió:El
fsutil dirty
comando requiere derechos de administrador para ejecutarse y fallará de lo contrario.%systemdrive%
es una variable de entorno que devuelve la letra de unidad donde está instalado el sistema operativo. La salida se redirige anul
, por lo tanto, se ignora. La%errorlevel%
variable se establecerá0
solo en caso de ejecución exitosa.Esto es lo que dice la documentación:
Más investigación
Si bien la solución anterior funciona desde Windows XP en adelante, vale la pena agregar que Windows 2000 y Windows PE (entorno preinstalado) no vienen con
fsutil.exe
, por lo que tenemos que recurrir a otra cosa.Durante mis pruebas anteriores, noté que ejecutar el
sfc
comando sin ningún parámetro daría como resultado:Es decir: sin parámetros, sin fiesta . La idea es que podamos analizar la salida y verificar si tenemos algo más que un error:
La salida del error se redirige primero a la salida estándar, que luego se canaliza al
find
comando. En este punto, tenemos que buscar la única parámetro que se admite en todas las versiones de Windows desde Windows 2000:/SCANNOW
. La búsqueda no distingue entre mayúsculas y minúsculas, y la salida se descarta redirigiéndola anul
.Aquí hay un extracto de la documentación:
Uso de muestra
Aquí hay algunos ejemplos de pegar y ejecutar:
Windows XP y posterior
Windows 2000 / Windows PE
Se aplica a
---
fuente
SFC
cheque para todos los sistemas, debe ser un poco creativo. Por alguna razón, comenzar con Windows 8SFC
solo genera caracteres individuales. Para analizar con éxito la salida, debe hacer lo siguiente:setlocal enabledelayedexpansion
for /f "tokens=* delims=" %%s in ('sfc 2^>^&1^|MORE') do @set "output=!output!%%s"
echo "%output%"|findstr /I /C:"/scannow">nul 2>&1
(3 líneas separadas). Esto debería funcionar en Windows 2000 a través de Windows 2012 R2. En una nota al margen, prefiero FINDSTR porque generalmente procesa las cosas más rápido que FIND.fsutil
solución, pero, por lo que puedo ver, parece mucho más flexible que mi solución. Aunque, no tan elegante, tal vez. ;) Me alegra ver que, entre nosotros, estamos obteniendo una excelente, fácil y flexible solución de detección de administrador fijada. :)fsutil dirty query >nul
cuando se eleva, esto devuelve texto de ayuda y% errorlevel% = 0fsutil dirty query >nul
, sin embargo,fsutil dirty query %systemdrive% >nul
aún funcionaDos formas más: rápido y compatible con versiones anteriores.
fltmc
El comando está disponible en todos los sistemas Windows desde XP, por lo que debería ser bastante portátil.Una de las soluciones más muy rápido probado en
XP
,8.1
,7
- hay una variable específica=::
que se presenta sólo si la sesión de consola no tiene privileges.As de administración no es tan fácil crear variable que contiene=
en su nombre se trata de manera relativamente fiable para comprobar para admin permiso (no llama ejecutables externos, por lo que funciona bien)Si desea usar esto directamente a través de la línea de comando, pero no desde un archivo por lotes, puede usar:
fuente
=::
variable es más bien un error - representa una unidad no existente, por lo que probablemente se solucionó en win10.=::
está definido para CMD sin administrador en Windows 10 1709. De todos modos, no es una forma confiable, puede forzarlo a que se defina fácilmente incluso en sesiones de CMD de administrador:subst :: c:\ & for %a in (::) do %a & set,
fuente
solución alternativa:
fuente
openfiles
y verificar ERRORLEVEL es suficiente.openfiles.exe
no funciona en WinPE, por lo que el script siempre devolverá que el usuario no es administrador.1>
y2>&1
se explican en microsoft.com/resources/documentation/windows/xp/all/proddocs/… .nul
se refiere al dispositivo nuloNo solo comprueba sino que OBTENES derechos de administrador automáticamente,
también conocido como Automatic UAC for Win 7/8 / 8.1 ff. : Lo siguiente es realmente genial con una característica más: este fragmento de lote no solo verifica los derechos de administrador, ¡sino que los obtiene automáticamente! (y prueba antes, si vive en un sistema operativo compatible con UAC).
Con este truco, no necesita más tiempo para hacer clic derecho en su archivo por lotes "con derechos de administrador". Si lo ha olvidado, para comenzar con derechos elevados, ¡UAC aparece automáticamente! Además, al principio se prueba, si el sistema operativo necesita / proporciona UAC, por lo que se comporta correctamente, por ejemplo, para Win 2000 / XP hasta que se pruebe Win 8.1.
El fragmento combina algunos buenos patrones de lotes, especialmente (1) la prueba de administración en este hilo por Ben Hooper y (2) la activación de UAC leída en BatchGotAdmin y citada en el sitio de lotes por robvanderwoude (respeto). (3) Para la identificación del sistema operativo por "patrón VER | FINDSTR" simplemente no encuentro la referencia).
(Con respecto a algunas restricciones muy pequeñas, cuando "NET SESSION" no funciona como se menciona en otra respuesta, siéntase libre de insertar otro de esos comandos. Para mí, ejecutar en modo seguro de Windows o servicios estándar especiales inactivos y tales no son casos de uso importantes - para algunos administradores tal vez lo sean)
fuente
start
: abre el script en una nueva ventana. Si desea ver los resultados, agregue unpause
al final de su secuencia de comandos. Además, es difícil de detectar, cuando "nos mantenemos" elevados, y cuando hay una repetición. Puede usar un argumento de línea de comando para eso: github.com/tgandor/meats/blob/master/lang_lawyer/cmd/…Tengo dos formas de verificar el acceso privilegiado, ambas son bastante confiables y muy portátiles en casi todas las versiones de Windows.
1. Método
* Funciona en XP y posterior
2. Método
* Funciona en XP y posterior
Ejemplo de trabajo
Un script que borra la carpeta temporal
Mostrar fragmento de código
fuente
En el script por lotes Elevate.cmd (vea este enlace ), que he escrito para obtener derechos de administrador , lo he hecho de la siguiente manera:
Esto se prueba para Windows 7, 8, 8.1, 10 e incluso Windows XP y no necesita ningún recurso, como un directorio especial, un archivo o una clave de registro.
fuente
La forma más limpia de verificar los privilegios de administrador usando un script CMD, que he encontrado, es algo como esto:
Este método solo usa CMD.exe incorporado, por lo que debería ser muy rápido. También verifica las capacidades reales del proceso en lugar de verificar los SID o las pertenencias a grupos, por lo que se prueba el permiso efectivo . Y esto funciona desde Windows 2003 y XP. Los procesos de usuario normales o los procesos no elevados fallan en la sonda de directorio, donde como administrador o procesos elevados tienen éxito.
fuente
Lo siguiente intenta crear un archivo en el directorio de Windows. Si tiene éxito, lo eliminará.
Tenga en cuenta que 06CF2EB6-94E6-4a60-91D8-AB945AE8CF38 es un GUID que se generó hoy y se supone que es improbable que entre en conflicto con un nombre de archivo existente.
fuente
was generated today and it is assumed to be improbable to conflict with an existing filename.
excepto si dos personas usan este códigoEl whoami / groups no funciona en un caso. Si tiene el UAC totalmente desactivado (no solo la notificación desactivada), y comenzó desde un mensaje del Administrador y luego emitió:
ejecutará no elevado, pero emitirá:
dirá que estás elevado. Está incorrecto. He aquí por qué está mal:
Cuando se ejecuta en este estado, si IsUserAdmin ( https://msdn.microsoft.com/en-us/library/windows/desktop/aa376389(v=vs.85).aspx ) devuelve FALSE y UAC está completamente desactivado, y GetTokenInformation devuelve TokenElevationTypeDefault ( http://blogs.msdn.com/b/cjacks/archive/2006/10/24/modifying-the-mandatory-integrity-level-for-a-securable-object-in-windows-vista.aspx ), entonces el proceso no se ejecuta elevado, pero
whoami /groups
afirma que sí.Realmente, la mejor manera de hacer esto desde un archivo por lotes es:
Debería hacerlo
net session
dos veces porque si alguien lo hizo deat
antemano, obtendrá la información incorrecta.fuente
whoami /groups
no está proporcionando la información incorrecta. Es solo que lorunas /trustlevel
coloca en un lugar inesperado: ejecutar sin privilegios de administrador pero con un alto nivel de integridad. Puede confirmar esto con Process Explorer. (Esto puede ser un errorrunas
pero no es un errorwhoami
).runas /trustlevel
Cuando eres un administrador local y UAC está deshabilitado, emitir ese comando runas desde un indicador de administrador te colocará en un contexto de seguridad de "usuario básico". Mientras está en ese modo, no puede realizar operaciones administrativas. Intente "net session", o fsutil "o cualquier otra utilidad que requiera acceso de administrador. Sin embargo," whoami / groups "le dice que está elevado. Cuando no lo está. El hecho de llamar a GetTokenInformation devuelve" TokenElevationTypeDefault "lo indica.fuente
whoami
no es compatible con Windows XP.Algunos servidores deshabilitan los servicios que requiere el comando "sesión neta". Esto da como resultado que la verificación del administrador siempre diga que no tiene derechos de administrador cuando pueda tenerlos.
fuente
Editar: copyitright ha señalado que esto no es confiable. Aprobar el acceso de lectura con UAC permitirá que dir tenga éxito. Tengo un poco más de script para ofrecer otra posibilidad, pero no es de solo lectura.
Respuesta anterior a continuación
Advertencia: poco confiable
Basado en una serie de otras buenas respuestas aquí y en los puntos planteados por and31415, descubrí que soy fanático de lo siguiente:
Pocas dependencias y rápido.
fuente
Nota: Verificar con cacls para \ system32 \ config \ system SIEMPRE fallará en WOW64 (por ejemplo, de% systemroot% \ syswow64 \ cmd.exe / 32 bit Total Commander) para que los scripts que se ejecutan en el shell de 32 bits en el sistema de 64 bits se repitan para siempre ... Mejor sería verificar los derechos en el directorio Prefetch:
Win XP a 7 probado, sin embargo, falla en WinPE como en Windows 7 install.wim no existe tal dir ni cacls.exe
También en winPE Y wow64 falla verificar con openfiles.exe:
En Windows 7, el nivel de error será "1" con información de que "el sistema de destino debe ser un sistema operativo de 32 bits"
Es probable que ambas comprobaciones también fallen en la consola de recuperación.
Lo que funciona en Windows XP - 8 32/64 bit, en WOW64 y en WinPE son: pruebas de creación de directorios (SI el administrador no bombardeó el directorio de Windows con permisos para todos ...) y
y
cheques.
También una nota más en algunas ventanas XP (y otras versiones probablemente también, dependiendo de los ajustes del administrador) dependiendo de las entradas del registro que llaman directamente a bat / cmd desde el script .vbs fallará con información de que los archivos bat / cmd no están asociados con nada ...
Llamar a cmd.exe con el parámetro del archivo bat / cmd por otro lado funciona bien:
fuente
Literalmente, docenas de respuestas en este y preguntas vinculadas y en otros lugares de SE, todas las cuales son deficientes de esta manera u otra, han demostrado claramente que Windows no proporciona una utilidad de consola incorporada confiable. Por lo tanto, es hora de lanzar el tuyo.
El siguiente código C, basado en Detectar si el programa se ejecuta con todos los derechos de administrador , funciona en Win2k + 1 , en cualquier lugar y en todos los casos (UAC, dominios, grupos transitivos ...), porque hace lo mismo que el sistema en sí cuando Verifica los permisos. Señala el resultado tanto con un mensaje (que puede silenciarse con un interruptor) como con el código de salida.
Solo necesita compilarse una vez, luego puede copiarlo en
.exe
todas partes, solo depende dekernel32.dll
yadvapi32.dll
(he subido una copia ).chkadmin.c
:1 MSDN afirma que las API son XP + pero esto es falso.
CheckTokenMembership
es 2k + y el otro es aún mayor . El último enlace también contiene una forma mucho más complicada que funcionaría incluso en NT.fuente
PowerShell alguien?
fuente
Aquí hay otro para agregar a la lista ;-)
(intente crear un archivo en la ubicación del sistema)
El
MODE CON
reinicializa la pantalla y surpresses cualquier texto / errores al no tener el permiso para escribir en la ubicación del sistema.fuente
Alternativa: utilice una utilidad externa diseñada para este propósito, por ejemplo, IsAdmin.exe (software gratuito sin restricciones).
Códigos de salida:
0: el usuario actual no es miembro del grupo de administradores
1 - Usuario actual miembro de Administradores y ejecutado elevado
2 - Usuario actual miembro de Administradores, pero no se ejecuta elevado
fuente
fuente
Explicaré el código línea por línea:
Los usuarios se molestarán con muchas más de 1 líneas sin esto.
Punto donde comienza el programa.
Establezca el nombre de archivo del directorio que se creará.
Crea el directorio en
<DL>:\Windows
(reemplazar <DL> con letra de unidad).Si la variable de entorno ERRORLEVEL es cero, entonces eco mensaje de éxito.
Ve al final (no continúes más).
Si ERRORLEVEL es uno, repita el mensaje de falla y vaya al final.
En caso de que el nombre de archivo ya exista,
goto end
vuelva a crear la carpeta (de lo contrario, el comando no permitirá que esto se ejecute).Especifique el punto final
Eliminar el directorio creado.
Pausa para que el usuario pueda ver el mensaje.
Nota : Los
>nul
y2>nul
están filtrando la salida de estos comandos.fuente
net user %username% >nul 2>&1 && echo admin || echo not admin
fuente
admin
Creo que la forma más simple es tratar de cambiar la fecha del sistema (que requiere derechos de administrador):
Si la
%date%
variable puede incluir el día de la semana, solo obtenga la fecha de la última parte delDATE
comando:fuente
:(
Encontré un usuario que puede usar
net session
aunque no sea administrador. No busqué por qué. Mi solución es probar si el usuario puede crear una carpeta en la carpeta de Windows.Aquí está mi código:
fuente
Una colección de los cuatro métodos aparentemente más compatibles de esta página. El primero es realmente bastante genio. Probado desde XP arriba. Sin embargo, es confuso que no haya un comando estándar disponible para verificar los derechos de administrador. Supongo que simplemente se están centrando en PowerShell ahora, lo que es realmente inútil para la mayoría de mi propio trabajo.
Llamé al lote 'exit-if-not-admin.cmd' que se puede llamar desde otros lotes para asegurarme de que no continúen la ejecución si no se otorgan los derechos de administrador necesarios.
fuente
Aquí está mi valor de 2 centavos:
Necesitaba un lote para ejecutar dentro de un entorno de Dominio durante el proceso de inicio de sesión del usuario, dentro de un entorno de 'sala de trabajo', viendo a los usuarios adherirse a una política de "bloqueo" y vista restringida (distribuida principalmente a través de conjuntos de GPO).
Un conjunto de GPO de dominio se aplica antes de un script de inicio de sesión vinculado al usuario de AD. La creación de un script de inicio de sesión de GPO era demasiado permanente ya que el perfil "nuevo" de los usuarios no se había creado / cargado / o estaba listo a tiempo para aplicar un "eliminar y / o Anclar "barra de tareas y elementos del menú Inicio vbscript + agregar algunos archivos locales.
por ejemplo: El entorno de perfil propuesto para el 'usuario predeterminado' requiere un acceso directo ".URL" (.lnk) ubicado dentro del "% ProgramData% \ Microsoft \ Windows \ Start Menu \ Programs * MyNewOWA.url *", y el "C: \ Users \ Public \ Desktop \ * MyNewOWA.url * "ubicaciones, entre otros elementos
Los usuarios tienen varias máquinas dentro del dominio, donde solo estas PC de 'sala de trabajo' requieren estas políticas.
Estas carpetas requieren derechos de 'Administrador' para modificar, y aunque el 'Usuario de dominio' es parte del grupo local 'Administrador', el siguiente desafío fue UAC.
Encontramos varias adaptaciones y amalgamamos aquí. También tengo algunos usuarios con dispositivos BYOD que requieren otros archivos con problemas permanentes. No he probado en XP (un sistema operativo demasiado viejo), pero el código está presente, me encantaría retroalimentar.
Las PC de dominio deben regirse lo más posible por los conjuntos de GPO. Las máquinas de grupo de trabajo / autónomas pueden regirse por este script.
Recuerde, aparecerá una ventana emergente de UAC al menos una vez con una PC de grupo de trabajo BYOD (tan pronto como se requiera la primera elevación a 'Permisos de administrador'), pero a partir de este momento, la política de seguridad local se modifica para uso administrativo. las ventanas emergentes desaparecerán.
Una PC de dominio debe tener la política "ConsentPromptBehaviorAdmin" de GPO establecida dentro de su política de "bloqueo" ya "creada", como se explica en la sección "REFERENCIAS" del script.
Nuevamente, ejecute la importación secedit.exe del archivo '.inf' predeterminado si está atrapado en todo el debate "A UAC o No a UAC" :-).
por cierto: @boileau Verifique su falla en:
Al ejecutar solo "% SYSTEMROOT% \ system32 \ cacls.exe" o "% SYSTEMROOT% \ system32 \ config \ system" o ambos desde el símbolo del sistema - elevado o no, verifique el resultado en todos los ámbitos.
fuente
Otra forma de hacer esto.
fuente