Programar Backups Routers Cisco

Regularmente hago copias de la conflagración de los Routers de mi red, lo hago copiando la "running-config" a un archivo de texto vía TFTP con el comando "copy running-config tftp:". En estos dias pense "mm, seguro que debe haber una forma de programar esto, alguna especie de cron", y efectivamente, se pueden programar tareas en los equipos Cisco con el comando Kron. El procedimiento es bastante sencillo,  primero se crea una lista de los comandos que queremos ejecutar y luego se especifica cuando se realizara esta tarea creando un "ocurrence". Bien, lo primero que necesitaran es un servidor TFTP, les recomiendo este. Luego que tengan su TFTP server funcionando, se logean a su Router para configurar el Kron. Una vez estén dentro, crearemos la lista de comandos que queremos ejecutar:

Router(config)#kron policy-list NombrePolitica

Donde "NombrePolitica" es el nombre que le daremos al listado que estamos creando. Presionamos enter y como podremos ver en el Promp, estaremos dentro del "Policy-list" que acabamos de crear. Aquí entonces agregaremos los comandos o acciones que queremos que se realicen automaticamente, en nuestro caso, sera copiar la configuración del Router al servidor TFTP. Ejecutaremos entonces lo siguiente:

Router(config-kron-policy)#cli sh run | redirect tftp://IP-TFTP-SERVER/nombre-archivo.cfg

luego:

Router(config-kron-policy)#exit

En la primera de las 2 lineas anteriores, iniciamos escribiendo "cli" y luego escribimos "sh run", como saben este comando mostrara la configuracion actual del router. Luego agregamos " | redirect tftp://ip-tftp-server/archivo.conf", lo que hacemos con esto es tomar la salida del comando anterior y redireccionarla a nuestro TFTP server. Como se imaginaran tendran que sustituir "IP-TFTP-SERVER" por la dirección IP de su servidor TFTP, luego escriben el nombre del archivo que se creara con la conflagración del router. Esto sera un archivo de texto, pueden ponerle o no extensión, en mi caso prefiero ponerle ".cfg". Como en este caso solo queremos programar la copia de la configuración, salimos de la edición de la lista con la segunda linea: "exit". En caso de que quieran programar otros comandos, deben tener pendiente que kron no soporta comandos interactivos, o sea, comandos que necesiten alguna acción o respuesta del usuario. Ya tenemos el listado de las acciones que realizara kron, ahora tenemos que indicarle cuando las realizara. Para esto ejecutamos el siguiente comando:

Router(config)#kron occurrence Nombre-ocurrance at 23:00 Sun recurring

luego:

Router(config-kron-occurrence)#policy-list NombrePolitica

En las lineas anteriores creamos el "occurrence" con el comando "kron occurrence", a este tambien le asignaremos un nombre que no tiene necesariamente que coincidir con el listado que creamos anteriormente. Luego especificamos el horario en que se ejecutara, en el caso de este ejemplo correra a las 11 de la noche de cada Domingo (23:00 Sun), como queremos que estas acciones se realicen recurrentemente agregamos al final "recurring", y presionamos "enter". Como pueden ver, el promp cambiara nuevamente indicando que estamos dentro de la configuracion del "occurrence". Aqui entonces indicaremos el listado que creamos anteriormente con el comando "policy-list NombrePolitica", y que como se imaginaran tienen que remplazar "NombrePolitica" por el nombre que le hayan puesto al listado (Policy-list) que crearon al inicio. Con esto ya tenemos nuestra "tarea" programada en nuestro router o switch. Podemos confirmar o verificar que se haya programado correctamente con el siguiente comando:

Router#sh kron schedule

Con esto veremos la fecha próxima en que se realizara la tarea que acabamos de programar. Bueno, hasta aqui este post, el primero del 2013, y como siempre espero que les haya sido de utilidad. En caso de que no hayan entendido mi explicación pueden leer mas sobre esto en esta pagina.

FTP Server (modo Pasivo) detras de IPTables

Digamos que tienen un su red un servidor FTP el cual utilizaran para colocar unos archivos que otros descargaran. No pondrán este servidor FTP diréctamente de cara a Internet, sino que en el Firewall redireccionaran los puertos de FTP hacia ese servidor servidor Internet utilizando reglas NAT o PAT. Como seguro saben, FTP utiliza 2 puertos IP: el puerto 21 y el puerto 20. El puerto 21 es el puerto de control, en el que se inicia la conexión al servidor, y el puerto 20 se utiliza para la transferencia de datos. Por lo que lo primero que haríamos seria configurar nuestro IPTables para que redirija estos 2 puertos a nuestro servidor FTP interno, utilizando reglas como estas:

-A PREROUTING -p tcp -i eth0 --dport 20 -j DNAT --to-destination ftp-server-interno.23:20

-A PREROUTING -p tcp -i eth0 --dport 21 -j DNAT --to-destination ftp-server-interno:21

Y luego:

-A FORWARD -p tcp -s 0/0 -d ftp-server-interno -m multiport --dports 20,21 -j ACCEPT

Debería funcionar cierto? bueno, funcionara siempre y cuando indiquen en su cliente FTP que utilizaran FTP  en modo "activo", que es este modo que acabamos de describir. En este modo el cliente hace la solicitud de conexión al servidor al puerto 21, aquí se le indica al servidor el puerto local que el cliente utilizara para esta conexión y entonces el servidor inicia una nueva conexión hacia el cliente al puerto que este le indico. O sea que el servidor inicia una conexión hacia el cliente luego de la negociacion inicial, lo que significa que si el cliente esta detras de un Firewall la conexión no se podra lograr, y como la mayoría de Routers ADSL y Firewalls bloquean todo el trafico entrante no se permitiría esta conexion hacia el cliente. Por esto es muy probable que las reglas de mas arriba no funcionen. Aquí un pequeño gráfico del funcionamiento de este modo:

Ahora bien, para evitar que el servidor inicie una nueva conexión hacia el cliente, se creo el modo "FTP Pasivo", en este modo el servidor luego de la negociación inicial le envía el cliente un puerto aleatorio para la transferencia de datos y el cliente entonces hace la conexion a este nuevo puerto. Así se evita el problema de filtrado del lado del cliente. Este puerto aleatorio se escoge dentro del rango de puertos TCP 1024 al 65535. En el siguiente gráfico se muestra el funcionamiento de este modo:

Esto quiere decir que tenemos que crear una regla que redirija este rango de puertos a nuestro FTP interno? Por suerte no, para esto utilizamos los módulos "ip_nat_ftp"  y "ip_conntrack_ftp" junto a las reglas que definimos mas arriba. Con esto, IPTables sabra el puerto aleatorio que se negocio para la transferencia de datos y lo direccionará a nuestro FTP Server. Para habilitar este modo ejecutamos:

# modprobe ip_conntrack_ftp

# modprobe ip_nat_ftp

Para hacer esto permanente y no tener que ejecutarlo en cada reinicio o incluirlo en algun script, solo tenemos que modificar el archivo /etc/modules y agregar:

ip_conntrack_ftp

ip_nat_ftp

Con estos módulos y utilizando las reglas de IPTables que les mostre mas arriba (las 2 que crean el DNAT y la de FORWARD que permite el  trafico de estos puertos hacia nuestro FTP server) tendremos nuestro servidor FTP funcionando detrás de IPTables. Como siempre, espero que esto les haya servido de ayuda y les haya econimizado unos minutos de busqueda en Google.

Habilitar acceso SSH en VMWare ESXi 4.1

Mucho tiempo sin agregar contenido al blog, pero ya me estoy reintegrando a la blogsfera y creo que le dedicare mas tiempo en este año, ya que me estoy poniendo viejo y algunas cosas se me olvidan, y en vez de ponerme a buscar entre mis sites "Favoritos" la pagina donde encontré la solución al problema creo que es mas fácil buscarlo aquí... y claro también para economizarle a ustedes tiempo buscando en Google, y hablando de tiempo ya esta bueno de preámbulo, entremos en el tema del post.

En VMWare 4.1 se ha cambiado la forma de habilitar el acceso SSH al host, ahora es mas fácil. En un pasado post le explique como habilitar este acceso en ESXi 3.5, había que dar varios pasos y modificar un archivo. Ahora solo tenemos que hacer lo siguiente:

1) En la consola local del equipo donde habilitaremos SSH, o sea que no utilizaremos aquí el "VMWare Infraestructure Client" sino que trabajaremos localmente en el equipo. La consola local se ve de esta forma:

2) Cuando estemos frente al equipo y estemos viendo la imagen de arriba, presionamos "F2" para acceder a las opciones, al hacer esto el sistema nos pedirá la clave del usuario "root", esta es la misma que se utiliza para acceder al host utilizando "VMWare Infraestructure Client". Escribiremos el password y presionamos "Enter".

3) Luego que escribimos el password se nos presentan las opciones de configuración que podemos hacer desde esta consola, como cambiar el password de root, cambiar la configuracion de la red, etc. la opción que nos interesa es "Troubleshooting Options", nos situaremos encima de esta con el teclado y presionamos "Enter".



4) Dentro de esta opción encontraremos "Enable Remote Tech Support (SSH), que es la opción que nos habilitara SSH en nuestro host, hacemos clic encima de esta opción:

 



Ya con esto podremos tener acceso a nuestro host VMWare a traves de SSH. Para desactivarlo se siguen los mismos pasos, en esta opción aparecerá "Disable Remote Tech Support (SSH)", se presiona "Enter" encima y ya esta. Como ven ahora es mas sencillo. Espero que esto le haya sido de ayuda. 

Instalacion de Samba en Centos y Conexion con Active Directory (Parte 2)

Hola nuevamente!

Como recordaran, en el post anterior instalamos Samba y otros paquetes y librerias necesarios para hacer que nuestro Centos participe en un dominio Active Directory, pero no hicimos ninguna configuracion en ninguno de los paquetes porque.... bueno, porque generalmente escribo de noche y me estaba cayendo del sueno. En esta ocasion haremos las configuraciones necesarias y dejaremos nuestro equipo siento parte del dominio Windows. El escenario que utilizaremos sera el siguiente:

Un dominio Active Directory llamado "TEST-LAB.COM"

Un controlador de dominio y DNS Server llamado "DC-SRV01", con la IP 10.0.1.70

Un equipo Linux (Centos) que sera parte del dominio, y utilizara la IP 10.0.1.71

La version de Windows que usare en este ejemplo es Windows Server 2003, pero se puede hacer tambien sin problemas con Windows 2000 Server. Bueno, habiendo dicho esto, podemos empezar con las configuraciones en nuestro equipo. Lo primero que debemos comprobar, y creo que no hace falta mencionarlo, es que nuestro equipo Centos tenga conectividad con el controlador de dominio, esto lo comprabamos haciendo un simple "ping" hacia el servidor. Una vez comprobamos que estamos conectados, indicamos al equipo Centos que utilice al controlador del dominio como DNS Server, para esto modificamos el archivo "/etc/resolv.conf" e incluimos la IP del servidor de dominio (10.0.1.70).

Como ven, tambien incluimos el nombre del dominio local al lado de "search". Tambien modificaremos en archivo "/etc/hosts" e incluiremos el nombre del controlador del dominio y su direccion IP, esto en caso de que la resolucion de nombres por DNS falle en algun momento. Luego de modificado el archivo "hosts" debe verse de esta manera:

Ahora pasaremos a modificar el archivo "/etc/nsswitch.conf", en este agregaremos o editaremos (si ya estan presentes) las siguientes lineas de manera que queden de esta forma:

passwd: files winbind
shadow: files winbind
group: files winbind
protocols: files winbind
rcp: files winbind
netgroup: files winbind
hosts: files winbind dns

Lo siguiente es configurar Kerberos, para esto modificamos el archivo "/etc/krb5.conf". Si no vamos a utilizar otro Servidor Kerberos a parte de nuestro controlador de dominio, podemos elimiar todas las lineas de este archivo y dejar solo las lineas que nos interesan. El archivo luego de modificado debe quedar de esta forma:

Como pueden ver, en la seccion "default_realm" se especifica el nombre del domino al cual queremos pertenecer (en letras mayusculas). Mas abajo se especifica el nombre completo del controlador de dominio (FQDN) en letras minusculas. Ahora pasamos a configurar Samba. Como hicimos la configuracion de Samba compilando los fuentes, es muy posible que la carpeta "/etc/samba/" (que fue la carpeta que especificamos para guardar la configuracion) este vacia. Nos moveremos a esta carpeta y crearemos un archivo llamado "smb.conf", en este incluiremos las siguientes lineas:

[global]

security = ads

password server = 10.0.1.70

encrypt passwords = true

workgroup = test-lab

realm = TEST-LAB.COM

netbios name = Centos-Box

idmap uid = 10000-20000

idmap gid = 10000-20000

winbind enum users = yes

winbind enum groups = yes

winbind use default domain = yes

winbind separator = +

Lo mas importante a tener en cuenta en estas lineas es que en la linea "password server" especificamos la direccion IP de nuestro controlador de dominio, en la linea "realm" insertamos el nombre del dominio tal y como lo especificamos en el archivo de configuracion de Kerberos. Y en la linea "netbios name" especificaremos el nombre con el cual queremos que nuestro equipo sea insertado al domino, este nombre no tiene que coincidir necesariamente con el nombre de nuestro equipo Centos. Ahora, lo que haremos sera iniciar Samba y Winbind, ya que como no los hemos configurado para iniciar durante la carga del sistema, deben estar desactivados. Para activarlos ejecutamos los siguientes comandos:

[localhost@root ~]# smbd start
[localhost@root ~]# nmbd start
[localhost@root ~] winbindd start

Podemos confirmar que Samba ya esta en ejecucion ejecutando el comando "netstat -nat", la salida de este comando debe mostrarnos que los puertos 445 y 139 estan en estado "LISTENNING", tambien lo comprobamos ejecutando "ps -aux", en este listado deben aparecer los servicios smbd y nmbd. Lo que sigue ahora es solicitar un "Ticket" al servidor Kerveros, que es nuestro controlador de dominio, para ejecutamos el comando "kinit" y le proporcionamos credenciales validas en el dominio, o sea, un usuario y un password, en este caso usuaremos el usuario "Administrator". Antes de solicitar el ticket, debemos asegurarnos que ambos equipos, el controlador del dominio y el equipo Centos tengan la misma hora, o por lo menos que la diferencia de hora no sobrepase los 5 minutos. Para sincronizar nuestra hora con la del controlador del dominio podemos utilizar el comando "net time":

[localhost@root ~]# net time set -I 10.0.1.70

Una vez hemos sincronizado los relojes podemos solicitar el ticket, para esto utilizamos el siguiente comando e inctroducimos el password cuando nos lo pida:

[localhost@root ~]# kinit Adminsitrator@TEST-LAB.COM

Si todo sale bien, a este punto ya tenemos nuestro ticket kerberos, podemos confirmar que ya lo tenemos con el comando "klist":

Por ultimo, vamos a ejecutar el comando "net join" para agregar nuestra maquina Centos al dominio, lo haremos utilizando nuevamente las credenciales del usuario "Administrator", al presionar "enter" se nos pedira el password de este usuario.

[localhost@root ~]# net join ads -S dc-srv01.test-lab.com -U administrator
Enter administrator's password:
Using short domain name -- TEST-LAB
Joined 'CENTOS-BOX' to realm 'test-lab.com'

Si recibimos ese mensaje, ya hemos insertado nuestro equipo al dominio Active Directory exitosamente!. Al ser parte del dominio podemos tener acceso a la lista de usuarios y grupos del dominio, podemos utilizar el comando "wb-info" para probar la conexion y para obtener la lista de usuarios y grupos, como se muestra en el siguiente grafico:

Espero que esta informacion les haya sido de provecho, en un proximo post usaremos esta membresia a Active Directory para permitir acceso a Internet a los usuarios miembros de un determinado grupo de usuarios utilizando el Web Proxy Squid.

Instalacion de Samba en Centos y Conexion con Active Directory (Parte 1)

Continuando con la configuracion de nuestro equipo Centos, pasaremos ahora a instalar Samba y Winbind y configurarlo para hacernos miembros de un dominio Windows. La idea es que este equipo pueda reconocer a los usuarios creados en nuestro dominio Windows y poder autenticar usuarios contra este dominio, esto lo usaremos mas adelante para dar acceso a Internet a los usuarios de un determinado grupo del dominio usando el proxy server Squid. Para ser parte del dominio Windows (Active Directory) necesitaremos tambien instalar Kerberos y algunas librerias y headers de LDAP, para esto ejecutaremos el siguiente comando:

root@localhost ~]# yum install krb5-workstation krb5-devel openldap-devel

Ahora pasaremos a la instalación de Samba, para esto sera necesario descargar los fuentes de Samba desde este link, la version estable actual al momento en este post en la 3.4.5 y esta sera la que utilizaremos. Como veran, no instalaremos Samba desde RPM's sino que los compilaremos en nuestro sistema, de esta forma podremos agregar y cambiar algunas opciones al momento de la instalacion. Es importante tambien que guardemos los fuentes de esta instalacion, ya que seran necesarios en caso de querer desinstalar Samba en un futuro (tambien la vamos a necesitar en la instalacion de Squid), asi que haremos una carpeta en nuestro folder "home" y la llamaremos "sources" (o cualquier otro nombre que deseen) y aqui descargaremos los archivos de instalacion, para esto hacemos lo siguiente:

root@localhost ~]# mkdir sources

root@localhost ~]# cd sources

root@localhost sources]# wget www.samba.org/samba/ftp/stable/samba-3.4.5.tar.gz

Una vez hemos descargado los fuentes, utilizaremos el comando "tar" para desempaquetarlos:

root@localhost sources]# tar -xzf samba-3.4.5.tar.gz

Ya teniendo nuestros archivos de instalacion desempaquetados, entramos a la carpeta samba-3.4.5 y dentro de esta, a la carpeta source3 donde encontraremos el ejecutable "configure", al cual ya deben estar acostumbrados si han compilado programas anteriormente. Este ejecutable se encargara de revisar y confirmar que nuestro sistema tenga todo necesario para instalar Samba de acuerdo a los parametros que le especificaremos y si nuestro sistema contiene lo necesario, creara un archivo "Makefile" en base al cual se crearan los binarios de Samba. Ejecutaremos "configure" con los siguientes parametros:

root@localhost source3]# ./configure --prefix=/usr --localstatedir=/var --with-configdir=/etc/samba --with-privatedir=/etc/samba --with-fhs --with-syslog --with-utmp --with-swatdir=/usr/share/swat --with-shared-modules=idmap_rid --with-libsmbclient --with-automount --with-ads --with-acl-support --with-ldap

Si nuestro equipo pasa la prueba y termina el proceso sin nungun error, entonces estamos listos para continuar con la instalacion y crear los binarios, en caso de que nos devuelva algun error, debemos revisar que paquete o libreria hace falta en nuestro sistema o revisar las especificaciones que le pasamos al script "configure". Si todo sale bien, la salida de este script debe verse de esta manera:

Ahora ejecutaremos el comando "make", el cual se encargara de crear y compilar los binarios de Samba en base a la informacion recogida por el script "configure", este proceso puede tomarse varios minutos. Si este proceso no nos devuelve ningun error, ejecutamos entonces el comando "make install", este se encargara de crear los directorios necesarios e instalar los binarios y librerias compiladas anteriormente

root@localhost source3]# make
root@localhost source3]# make install

Una vez terminados estos procesos, tendremos instalado Samba/Winbind en nuestro equipo, ahora necesitamos configurarlo. En el proximo post veremos entonces la configuracion necesaria tanto de Samba como de Kerberos y otros archivos del sistema para lograr la conexion con Active Directory.

Dejando a un lado los Privilegios

Hoy en día, navegar y estar conectado a Internet puede representa un gran riesgo de seguridad, ya que por el simple hecho de visitar un sitio Web podemos quedar infectados con algún Maleware y sin darnos cuenta acabamos siendo parte de una Botnet. Y esto no se queda en la navegación en Internet, podemos también recibir un correo con algún archivo PDF, especialmente manipulado, que explote alguna vulnerabilidad en nuestro lector de PDF y es el mismo caso. Pero también podría ser un documento Power Point, Word, o cualquier otro tipo de archivo, incluso un archivo MP3.

Las vulnerabilidades que se descubren en estas aplicaciones (que últimamente son el mayor vector de ataque) generalmente permiten “ejecución de código”, o sea, que el atacante puede manipular un documento o sitio web e insertar en él código que será ejecutado en el computador del usuario si el programa con el que este lo abre es vulnerable. Existe un principio de seguridad que nos dice que debemos utilizar cuentas de usuarios con el menor privilegio posible, es decir, cuentas "limitadas" o "sin privilegios administrativos". Utilizar nuestro equipo con una cuenta de usuario limitada nos ayuda a disminuir considerablemente el riesgo de infección de virus y Maleware ya que, al abrir algún archivo el contenido del mismo se ejecuta bajo el contexto de seguridad del usuario logeado, es decir, con los privilegios del usuario que lo invoca. Por esto, si nuestro usuario tiene privilegios administrativos en el equipo, el atacante podría ejecutar o instalar cualquier programa en nuestro sistema. Y peor aun si nuestro usuario tiene privilegios de “Administrador de Dominio”.

Utilizar cuentas con privilegios administrativos, sumado a no mantener los sistemas operativos y aplicaciones actualizadas son, a mi entender, las principales razones del porque las Botnet y el Spam (ya que a veces utilizan las botnet para envío masivo de SPAM) continúan creciendo. En los ambientes Unix y Linux esto no es nada nuevo, el usuario “root” es el “todopoderoso” y las demás cuantas que se crean son simples usuarios. Si se quiere se puede elevar el privilegio de un usuario creado al nivel de root, pero por defecto se crea sin privilegios. El caso de Windows es algo diferente: Al instalar el sistema operativo la cuenta “Administrador” se crea por defecto y se nos pide un password para esta, luego se nos pide un nombre para una cuenta de usuario, pero esta es creada, por defecto, con privilegios administrativos.


Cuentas limitadas en Windows XP (utilizando “runas”)

Aunque es lo recomendable, a veces resulta un poco tedioso utilizar en el día a día una cuenta limitada y alejarnos de nuestro privilegio de Administrador, sobre todo cuando en nuestro trabajo necesitamos con frecuencia instalar/desinstalar programas, hacer modificaciones en el registro, etc., en algunos casos para realizar algunas de estas tareas tendríamos que cerrar nuestra sesión y entrar con un usuario Administrador. Para evitar esto podemos utilizar el comando “runas”, este comando nos permite ejecutar comandos o programas en el contexto del usuario que especifiquemos, por ejemplo, Administrator. También podemos utilizar runas en el entorno grafico haciendo clic derecho sobre un programa o aplicación y moviéndonos en el menú hacia “Run As”, el cual nos permitirá indicar el usuario con el cual queremos ejecutar la tarea. Por ejemplo, si queremos abrir una consola de comandos para ejecutar desde ella comandos o aplicaciones con privilegios de administrador, ejecutamos el siguiente comando:

runas /user:DOMINIO\USUARIO cmd.exe

Donde “DOMINIO” corresponde al nombre del dominio al que pertenece la cuenta y “USUARIO-ADMIN” es el usuario con privilegios con el cual invocaremos la consola, por ejemplo, Administrador. Cualquier comando o aplicación que llamemos desde esta consola se ejecutara con los privilegios del usuario que especificamos, de esto forma podemos ejecutar desde aquí, por ejemplo, regedit.exe (editor del registro), netsh, etc. En caso de que, por ejemplo, necesitemos ejecutar alguna utilidad del Panel de Control (Control Panel) como “Add/Remove Software” y alguna Política de Grupo (GPO) nos prohíbe el acceso a esta utilidad. Podemos ejecutar de forma grafica “runas” haciendo clic derecho encima del archivo “appwiz.cpl” y luego moviéndonos hacia “Run As” e indicando un usuario con privilegios para ejecutar esta utilidad (el archivo “appwiz.cpl” se encuentra en “c:\windows\system32\”, mayormente las utilidades del Control Panel se encuentran en esta carpeta con extensión “.cpl”).

· Usuario Limitado en Windows Vista (User Account Control)

Como vimos anteriormente, aun con “runas” puede resultar un poco tedioso trabajar con una cuenta limitada. En Windows Vista, Microsoft intentó mejorar esto con el (odiado por muchos) “User Account Control”. La idea de UAC es precisamente controlar las actividades del usuario y programas en el sistema requiriendo la debida autorización antes de realizar alguna tarea que necesite la elevación de privilegios. UAC resulto molesto por los constantes mensajes requiriendo al usuario elevación de privilegio. El problema es que aunque el usuario tuviera privilegios de Administrador (todavía en Windows Vista cuando se instala el sistema el usuario que se crea tiene privilegios administrativos) UAC de todas formas informaba al usuario que para realizar tal o cual tarea necesitaba elevar sus privilegios, a lo que el usuario solo tenía que hacer clic en “Aceptar” y eso era todo. Por eso muchos optaban por desactivarlo y en algunos casos hasta desinstalar Vista y volver a XP.

Estos problemas con UAC se han disminuido considerablemente a partir del SP2 de Windows Vista. Ahora si nuestro usuario tiene privilegios administrativos en el equipo podemos realizar cualquier tarea sin que UAC nos solicite elevación de privilegios (porque ya lo tenemos). Ahora con UAC es más fácil dejar a un lado los privilegios administrativos y vestirnos de usuarios comunes y simples. UAC nos permite utilizar nuestra cuenta limitada y en caso de que necesitemos realizar alguna tarea como instalar/o desinstalar un programa, utilizar alguna utilidad del “Administrative Tools” o cualquier otra tarea que requiera privilegios elevados, el sistema nos pedirá las credenciales correspondientes, evitándonos la fatiga de tener que utilizar “runas” para llamar dicha utilidad. Si utilizan Windows Vista, les recomiendo que (si no lo han hecho) descarguen e instalen el Service Pack 2 desde este enlace y habiliten nuevamente UAC (que me imagino lo tienen desactivado) para que comprueben ustedes mismos las mejorías. Y también claro, que dejen a un lado los privilegios administrativos y se vistan del más simple y “des-privilegiado” de los usuarios y solo utilicen las cuantas administrativas para ciertas tareas. Al principio puede resultar un poco incomodo, pero valdrá la pena acostumbrarse. Bueno, como siempre espero no haberles hecho malgastar su tiempo con este post y que esta información les haya sido de provecho.