Para compilar un .exe a partir de un script, necesitamos un compilador, el problema aparece cuando no tenemos disponible ninguno comercial, con un interface amigable etc.
Desde que .Net Framework apareció, tenemos una posibilidad gratuita para poder compilar, eso sí, no todo el mundo conoce como hacerlo funcionar, Intentaré explicarlo paso a paso.
Read more…
Hola:
El articulo de hoy es muy sencillo, se trata de un tipo de objeto muy potente que almacenará colecciones de pares de datos. Veremos como utilizarlo y posibles aplicaciones.
Los que tengais experiencia con perl, es parecido a un array asociativo, es decir asocia pares nombre-valor n veces. Es muy útil cuando estamos trabajando scripting, ya que para tareas repetitivas y no demasiado complejas, no es necesario utilizar una DB para almacenar los pares.
Read more…
Una de las cosas que siempre eché en falta en VBS fué que cuando seleccionaba un script, si le pulsaba al botón derecho buscando “ejecutar como” o “run as”, al tratarse de un fichero VBS no lo mostraba. ¿Queria esto decir que no podia ejecutar el script bajo unas credenciales diferentes?.
El caso es que no, en realidad el problema es que un script no es un ejecutable. En el caso de VBScript, en realidad lo que ocurre cuando hacemos doble click sobre el mismo, al estar la extension .vbs asociada al interprete (cscript o wscript) se llama al ejecutable y al usuario nos hace “transparente” la operacion, ya sabeis, los chicos de MS procuran siempre hacertelo cómodo, aún cuando lo que consiguen es añadir una capa más a entender si quieres estar al tanto de qué está ocurriendo…
Bueno, la respuesta es sencilla ahora, ¿como ejecutamos un script bajo otras credenciales? Si abrimos una consola de comandos, podemos usar una sentencia de este tipo:
runas /profile /user:DOMINIO\USUARIO “cscript.exe c:\scripts\test.vbs”
esto funcionará, pero… hay otro problema, ¿que ocurre si hay espacios en la ruta? es decir, en el caso anterior, funciona porque no hay espacios en c:\scripts\test.vbs, pero y si fuera c:\mis scripts\test.vbs ? La respuesta es que fallaria.
Ahora explicaré algo sobre los carácteres de escape… bajo comando, debes escapar las comillas con \” , de esta forma, no lo considera el final del entrecomillado, es decir, para que el espacio sea considerado, puedes poner:
runas /profile /user:DOMINIO\USUARIO “cscript.exe \”c:\mis scripts\test.vbs”\”
De esta forma, considera un bloque la ruta al script, y otro bloque el comando cscript y la ruta como argumento.
Ahora que ya está explicado, voy a aprovechar para explicar como saber el dominio del usuario que está ejecutando el script con vbs. Lo primero, voy a explicar que es el RootDSE. A partir de LDAP 3.0 , rootdse es la raiz del arbol de directorio en un servidor de directorio LDAP, es decir, rootdse no es parte de ningun espacio de nombres, solo hace referencia a la raiz. En un directorio activo, por tanto, coincide en la mayoria de los casos con el nombre del directorio. Por ejemplo, si yo tengo un dominio miempresa.local , su DN (Distinguished Name) sería dc=miempresa,dc=local . Pues bién, esto coincide con el defaultNamingContext (atributo de rootDSE).
Explicado esto, este script nos dará el dato que necesitamos:
Set objRootDSE = GetObject(”LDAP://RootDSE“)
strDNSDomain = objRootDSE.Get(”defaultNamingContext”)strdnsdomain = replace(strdnsdomain,”DC=”,”")
strdnsdomain = replace(strdnsdomain,”,”,”.”)msgbox strdnsdomain
Ya sabeis, cualquier duda que surja, dejarla en comentarios y lo vemos!
Saludos,
Nota:
Por cierto, hice un copiar y pegar directamente desde la página porque no tenia mi biblioteca a mano, y si os falla, es por las comillas, simples y dobles, que cuando las pega en el notepad las cambia por otras…. Recordad modificarlo, todo en el script que aparece con dobles comillas son dobles comillas (de las de mayusculas + 2) y todas las comillas simples, son comillas simples (de las de la derecha del 0)