Autor: jfarrabe

Continuando con las mejoras de Windows Vista vamos a comentar otro elemento de interés que interviene directamente en el comportamiento de algunas aplicaciones: la «virtualización de procesos». No confundáis la virtualización de la que hablamos en este Post con la virtualicación de aplicaciones mediante Microsoft SoftGrid, uno de los elementos principales del MDOP, del cual nuestro compañero Julián Blázquez ya hizo un Webcast

Probablemente a lo largo de vuestra experiencia con Windows XP o Windows 2000 os hayáis encontrado con aplicaciones como ciertos juegos, que aunque no deberían obligaros a ejecutarlas con privilegios administrativos dado que no ofrecían ventajas administrativas, debíamos ejecutarlas como administradores para que su funcionamiento fuera correcto. Esto es debido fundamentalmente a malas practicas de desarrollo, donde lo que prima es la funcionalidad y no la seguridad (algo que ocurre a menudo actualmente), de esta manera, estos juegos y aplicaciones intentan escribir en ubicaciones donde un usuario corriente no tiene permisos de escritura, como %WINDIR%, %PROGRAMFILES% o en claves del registro como HKEY_LOCAL_MACHINE, en lugar de escribir en otras como %USERPROFILE% o en «HKEY_CURRENT_USER» donde los usuarios corrientes tienen permisos adecuados.

Ya llevamos un año y medio de Windows Vista, y aun tenemos para largo para llegar a explicar todas las mejoras incluidas en este Sistema Operativo. Hoy revelaremos una bastante útil e interesante: la administración remota mediante WINRM, la implementación de Microsoft del estándar «WS-Management».

WS-Management también conocido como «Web Services for Management» (Servicios Web para Administración) es un protocolo estándar del «Distributed Management Task Force» (DMTF),  importante grupo del que forman parte empresas como IBM, Novell, HP, Sun Microsystems, Intel y Microsoft entre muchas otras.  Las especificaciones concretas de WS-Management las podéis obtener en PDF (y en inglés) en la siguiente dirección:

Retomamos el tema de «Windows Service Hardening» para comprobar otro aspecto de seguridad de Windows Vista: «Los SID de Servicio».

La seguridad en los servicios es uno de los aspectos que más se ha buscado potenciar en Windows Vista dada la importancia que tienen en la estabilidad y funcionalidad del sistema, a la cual ya nos aproximamos en el artículo anterior referente a este mismo tema:

http://geeks.ms/blogs/vista-tecnica/archive/2007/12/24/sistemas-de-integridad-en-windows-vista-i-windows-service-hardening-primera-parte.aspx

La problemática de restringir el acceso a un servicio en Windows XP

Una de las maneras más sencillas e intuitivas de mejorar la seguridad de cualquier aplicación o sistema es mediante «listas de control de acceso» o ACL en las que se describa que usuario o grupo puede tener acceso a un recurso indicado. Habitualmente el primer sistema de control de acceso que utilizamos son los permisos del sistema de archivos, de esta manera, si no queremos que un servicio sea capaz de acceder a un contenido concreto, solo tenemos que denegar, a nivel de disco, el permiso al usuario mediante el cual se ejecuta el servicio; no obstante esto no siempre es tan sencillo como parece.

La mayoría de los servicios en Windows se ejecutan gracias a los usuarios de bajos privilegios «LocalService» y «NetworkService» y al usuario de elevados privilegios «LocalSystem», de manera que si deseamos denegar el acceso de un servicio a un determinado recurso, y dicha denegación la realizamos para alguna de las cuentas citadas anteriormente, estaremos en realidad restringiendo el acceso a todos los servicios que hagan uso de esa cuenta. La solución pasaría por tanto por la creación de una nueva cuenta de usuario para el servicio al que deseamos denegar el acceso, sin embargo esto puede resultar contraproducente para la seguridad del sistema (y por tanto para la integridad del mismo) dado que los usuarios «NetworkService» y «LocalService» disponen de privilegios más bajos que los de cualquier usuario corriente, debiendo modificar las políticas del sistema si deseamos realizar una equiparación de privilegios.

La solución ideal a esta problemática sería usar los privilegios de «NetworkService» y «LocalService» y además poder establecer ACLs para denegar accesos al servicio deseado en particular sin que otros servicios se vean afectados. El sistema que Windows Vista incorpora para este fin son los «SID de Servicio».

La solución: Los SID de Servicio en Windows Vista

Las ACLs de Windows hacen uso de un identificador de seguridad y de usuario único conocido como SID (Security Identifier), que permite entre otras cosas que cambiemos el nombre y las propiedades de un usuario o grupo sin que por ello estemos interfiriendo en los permisos aplicados a estos. Existen SID bien conocidos de los cuales podéis encontrar una descripción en el siguiente enlace:

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

Para nuestro caso en particular tendríamos lo siguiente:

SID Local System:                 S-1-5-18

SID LocalService:                  S-1-5-19

SID NetworkService              S-1-5-20

Excepto para cuentas genéricas como las citadas, los SID deben ser únicos para cada sistema y cuenta, de ahí que puedan aparecer problemas de seguridad en la red al realizar una duplicación de un equipo mediante imágenes y que debamos usar herramientas como «Sysprep» o «NewSid» para solucionarlos.

Windows Vista hace uso de los SID para establecer permisos para los Servicios, de manera que se pueda aplicar una configuración de ACLs determinada sin interferir con otros servicios y aplicando a su vez los permisos propios del usuario con el que se ejecuta (LocalService, NetworkService y LocalSystem).

Para comprobar los SID aplicados a cada servicio haremos uso del «comando SC» que ya utilizamos en el anterior post.

Comprobando el SID de un servicio mediante el comando SC:

sc showsid [Nombre del servicio]

Nota: El nombre que debemos indicar en el comando es el nombre corto del servicio, es decir, aquel presentado en el campo «NOMBRE_SERVICIO» al ejecutar «sc query» (por ejemplo «WSearch» es el nombre corto de «Búsqueda de Windows»).

Es importante que introduzcamos correctamente el nombre del servicio dado que «sc showsid» calcula el SID a partir del nombre indicado, de manera que podría devolvernos un valor falso si introducimos el nombre incorrectamente, el hecho de que se calcule el SID a partir del nombre permite que el SID del servicio sea el mismo para cualquier equipo en el que nos encontremos, esto nos permite aplicar permisos mediante Scripts sin necesidad de consultar previamente cual es el SID a usar en ese sistema específico.

Comprobación práctica: Impidiendo el acceso del programador de tareas.

A continuación vamos a realizar una comprobación práctica de todo lo que hemos visto hasta ahora, para ello usaremos el comando «SC» para consultar el SID del servicio y el comando «ICACLS» para establecer los permisos.

El servicio «Programador de Tareas» ejecuta aplicaciones de manera periódica según una programación o eventos concretos, y dicha configuración se ubica en forma de archivos XML en %SystemRoot%System32Tasks. En nuestro caso, a modo de demostración práctica, vamos a prohibir al servicio de programación de tareas el acceso a dicha carpeta para comprobar de primera mano los errores que nos ofrece la aplicación.

La aplicación de este procedimiento causará problemas en el sistema, de manera que no deberíais aplicarlo en un entorno de producción. Si deseáis realizar la práctica os puede valer una máquina virtual de pruebas o cualquier «Virtual Lab» de Windows Vista de la Web de Microsoft.

Lo primero es obtener el SID del servicio, para ello debemos ejecutar lo siguiente desde el CMD:

Obtener nombre corto de servicio:

sc query

Obtener SID de Servicio:

sc showsid    

Como me imagino que los curiosos habrán notado ya, no es posible establecer permisos a un SID determinado a través de entorno gráfico, de manera que para poder realizarlo debemos usar la herramienta de línea de comandos «ICACLS», que sustituye al antiguo CACLS de Windows XP que era menos funcional.

Es una buena práctica, comprobar la ayuda del comando ICACLS para comprobar las potentes funcionalidades que ofrece con respecto a su antecesora CACLS (también disponible en Windows Vista), para ello debemos ejecutar «icacls /?». Podéis ver una descripción de sus funciones en el siguiente enlace:

http://technet2.microsoft.com/windowsserver2008/en/library/403edfcc-328a-479d-b641-80c290ccf73e1033.mspx?mfr=true

En el caso que nos ocupa debemos ejecutar el siguiente comando para denegar el acceso al servicio de «Programación de Tareas»:

icacls c:windowssystem32tasks /deny *S-1-5-80-4125092361-1567024937-842823819-2091237918-836075745:(F)

Nota: Dado que necesitamos privilegios para cambiar los permisos, deberemos ejecutar el CMD con Privilegios de Administrador, seleccionando la opción «Ejecutar como administrador» del menú contextual.

Una vez denegado el acceso al servicio, para comprobar si realmente se están aplicando los permisos indicados abrimos el complemento «Programador de Tareas» dentro de «Herramientas Administrativas» en el «Panel de Control». Comprobemos el error que nos aparece al abrir el complemento.

Por último, comprobemos mediante el entorno gráfico los cambios en los permisos NTFS que se han aplicado en %systemroot%system32tasks.

Impedir el acceso de escritura a un Servicio: 

Por último solo quedaría explicar un último parametro del comando SC: «sc sidtype [nombre de servicio][tipo]» donde «tipo» puede ser «none», «Unrestricted» y «Restricted».

El parametro «Restricted» nos permite restringir el acceso de escritura de un servicio a las ubicaciones donde no se le de permiso de escritura de manera explicita a su SID de servicio, a no ser que los permisos se establezcan para el grupo Todos.

De manera predeterminada un servicio en modo «Unrestricted» o «None» tiene acceso de escritura a las ubicaciones donde LocalService, NetworkService o LocalSystem (según cual de estas cuentas ejecute el servicio) tenga acceso. Los cambios realizados al tipo de SID tienen efecto la proxima vez que se inicia el servicio.

 El parametro «None» hace que el servicio se comporte como en Windows XP, omitiendo los permisos que se establezcan para el SID de servicio asociado (los permisos establecidos a través del SID no tendrían efecto).

Podemos consultar si un servicio esta en estado restringido mediante «sc qsidtype [nombre de servicio]».

Comprobación del tipo de SID para el Servicio «Firewall de Windows» :

Bueno, aquí acabamos con el tema del endurecimiento de Servicios de Windows Vista, pero no por ello la comprobación de tecnologías de Integridad, de manera que en futuros post iremos desgranando nuevos aspectos de la Seguridad de Windows Vista, para que podáis valorar vosotros mismos el cambio de perspectiva de este Sistema Operativo.

Retomamos de nuevo la seguridad en Windows Vista tratando esta vez sobre los sistemas de integridad «Integrados» en este sistema operativo. Es decir, vamos a ahondar un poquito más en que es lo que ha puesto tan nerviosas a empresas Antivirus como Symantec a parte de técnologias como el Firewall de Seguridad Avanzada de Windows Vista, el UAC o ASLR.

En próximos Posts hablaremos de tecnologías de integridad como MIC, UIPI, o el servicio TrustedInstaller, de momento, por hoy, nos conformaremos con acercarnos a las notables mejoras de seguridad de los Servicios de Windows: el conjunto de funcionalidades recogidas dentro de WSH (Windows Service Hardening), que vienen a ser las mismas siglas que «Windows Scripting Host» para los entendidos.

Limitaciones de los Servicios en Windows XP:

Windows XP (sistema muy defendido por los opositores a Windows Vista) sufría de carencias de seguridad en la manera de trabajar de los servicios, pese a las grandes mejoras realizadas en este ámbito con respecto a Windows 2000. Con todo eso, aun me toca oir a algún Tecnicoless (perdona Maligno por tomar prestado el término) que Windows 2000 es mejor que Windows XP…  En fin, anécdotas aparte, lo cierto es que nos encontrábamos limitados a la hora de trabajar con los servicios de XP, algo que los distintos tipos de malware no dudan en aprovechar.

Por ejemplo si en Windows XP queremos impedir el acceso a un recurso específico (como una clave del registro) a un servicio, debemos crear una cuenta de usuario y asignársela al servicio a modo de «cuenta de servicio», algo que además trae problemas al obligarnos a gestionar una política de control de contraseñas para mantener la seguridad de los servicios afectados.

Otro ejemplo de las limitaciones de XP es cuando deseamos que un servicio tenga acceso a un recurso al que el usuario «LocalService» no puede acceder, en estos casos nos vemos obligados a usar la cuenta de elevados privilegios «LocalSystem» o bien a crear una cuenta de servicio específica para acceder al recurso, con lo que volvemos al supuesto anterior.

Para complicar aun más la cosa, en Windows XP, cuando le asignamos a un servicio una cuenta con las que ejecutarse, ya sea una cuenta de servicio, o las cuentas LocalSystem, LocalService o NetworkService, automáticamente, dicho servicio obtiene todos los privilegios otorgados a la cuenta asignada, con lo cual el servicio obtiene un mayor nivel de acceso al equipo de lo que realmente deseamos, algo que posteriormente puede ser usado por los diferentes tipos de Malware para, por ejemplo, realizar una elevación de privilegios.

Windows Vista ha solucionado estos problemas gracias a Windows Service Hardening como describiré a continuación.

La solución: Windows Vista y Windows Service Hardening:

Vamos a estudiar desde el punto de vista práctico estas mejoras de seguridad de Windows Vista, para ello vamos a hacer uso de las siguientes herramientas de las cuales no viene mal ir familiarizándonos.

Comando SC: Es un comando extendido de edición y consulta de servicios (integrada en Windows Vista).

Process Explorer: Herramienta de SysInternals para obtener información extendida de procesos en ejecución. Esta herramienta la podéis descargar por separado en

http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx

o bien descargarlo como parte del Suite de SysInternals (paquete de utilidades cuya descarga es muy recomendable) 

http://technet.microsoft.com/en-us/sysinternals/0e18b180-9b7a-4c49-8120-c47c5a693683.aspx

Las mejoras tecnológicas referentes a la seguridad en los Servicios de Windows Vista deben pasar obligatoriamente por tres grandes áreas:

• Aislar los procesos de usuario de los servicios
• Conseguir que una mayor cantidad de servicios trabajen con bajos privilegios
• Solucionar las limitaciones presentadas por Windows XP

Aislamiento de servicios: Id de sesión 0

Aislar los servicios de los procesos de usuario es una solución óptima para mantener la seguridad de los sistemas, dado que, por un lado dificultamos que un proceso de usuario tome control sobre un servicio, y por otro lado dificultamos que un Servicio infectado interactue directamente con las cuentas de usuario buscando por ejemplo engañar a este para que intruduzca una contraseña en un formulario invocado para tal fín.

El aislamiento de servicios en Windows Vista se consigue gracias a los Ids de Sesión. Este sistema en Windows XP era utilizado para el aislamiento y control de procesos ejecutados por usuarios remotos (Remote Desktop  y Terminal Services) y para el servicio de cambio rápido de usuario. Según este sistema al primer usuario en iniciar sesión se le asigna el Id de sesión 0, en cuyo contexto también se ejecutaban los servicios del sistema; a los usuarios que iniciaban sesión posteriormente gracias a «Cambio Rápido de Usuario» o de manera remota gracias a los servicios RDP (Remote Desktop Protocol) se les iba asignando Ids de sesión consecutivos (id 1 para el segundo usuario, Id 2 para el tercero, Id 3 para el cuarto y así sucesivamente).  Mediante este sistema de Ids se impide que un proceso invoque interfaces de usuario (UI) para otros Ids de sesión de manera directa, mejorando la privacidad y la seguridad de cada sesión de usuario.

Windows Vista mantiene este sistema de aislamiento, pero añadiendo un cambio muy importante, los servicios del sistema siguen ejecutándose con sesión Id 0, pero el primer usuario que inicia sesión lo hace con Id 1, esto quiere decir que los usuarios y los servicios se ejecutan con Ids distintos, a diferencia de lo que ocurría con XP, a esto hay que añadirle además que los procesos ejecutados con Id 0 no tienen acceso al hardware gráfico, de manera que la única manera de interactuar con el usuario es mediante sistemas alternativos y más seguros como RPC o Named Pipes. En Windows Vista, ningún servicio puede mostrar directamente una interfaz gráfica en pantalla, protegiéndonos por ejemplo de engaños gráficos como cuadros de contraseñas, ventanas falsas etc.

Tanto en Windows XP como en Windows Vista podéis ver el Id de sesión con que se ejecutan los procesos desde el administrador de tareas agregando las columnas correspondiente en «Ver > Seleccionar Columnas»

Servicios con bajos privilegios

Conseguir que una mayor cantidad de servicios trabajen con bajos privilegios supone estar mejor protegidos de posibles bugs y su explotación por parte de un atacante, dado que en el peor de los casos, el atacante solo conseguirá acceso al equipo con los privilegios concedidos al servicio afectado.

Para entender correctamente la manera en la que Windows Vista consigue reducir los privilegios a los mínimos necesarios para que un servicio se ejecute tenemos que diferencias dos aspectos:

• Privilegios de servicio: Equivalen a los típicos privilegios de usuario que podemos editar desde las políticas de grupo (gpedit.msc) como «permitir el inicio de sesión local» o «Apagar el Sistema».
• Permisos de servicio: Son permisos NTFS aplicables a un servicio para proteger recursos como una clave del registro o una carpeta del Sistema.

En Windows Vista los servicios solo aplican los privilegios otorgados explícitamente, pasando por alto aquellos privilegios propios del usuario con que se ejecutan dichos servicios. De esta manera se corrige uno de los problemas que padecía Windows XP y que ya hemos descrito anteriormente: «Los privilegios no necesarios para el funcionamiento del servicio recibidos como consecuencia de ejecutar este con un usuario determinado, ya sea un usuario de servicio o los usuarios especiales LocalService, NetworkService o LocalSystem».

De todos modos, por compatibilidad con sistemas anteriores, si no se especifican unos privilegios propios para el servicio, este recibirá automáticamente los del usuario que efectúa la ejecución. Las buenas prácticas de desarrollo exigen el uso de este sistema de privilegios de servicios en Windows Vista, pero siempre estaremos a expensas de que las empresas de software realmente hagan uso de este (Microsoft si hace uso de él como veremos con alguno de sus servicios).

A continuación vamos a comprobar, gracias al comando «SC» y a «Process Explorer» este sistema de privilegios, pero antes es recomendable consultar el listado de privilegios existente con su descripción asociada en el siguiente enlace:

http://msdn2.microsoft.com/en-us/library/bb530716(VS.85).aspx

Ya conocedores de los privilegios existentes, tampoco está de más echar un vistazo a estos otros Links:

Privilegios otorgados a la cuenta LocalService:

http://msdn2.microsoft.com/en-us/library/ms684188(VS.85).aspx

Privilegios otorgados a la cuenta NetworkService:

http://msdn2.microsoft.com/en-us/library/ms684272(VS.85).aspx

Privilegios otorgados a la cuenta LocalSystem:

http://msdn2.microsoft.com/en-us/library/ms684190(VS.85).aspx

Como habréis comprobado en los enlaces de arriba, este sistema no es algo nuevo en Windows Vista, solo son los llamados «privilegios de usuario», pero descritos a un nivel más bajo de lo que normalmente estamos acostumbrados, y con la diferencia de que en Windows Vista estos privilegios son editables a nivel de servicio.

Comencemos con la práctica: El comando SC

SC es un comando existente en XP pero al cual se le han agregado nuevas e interesantes funcionalidades en Windows Vista. Este comando nos sirve para crear, eliminar o consultar el estado de los servicios de Windows. Escribiendo SC podréis ver un listado completo de sus opciones, las cuales podéis ver descritas en el siguiente enlace:

http://technet2.microsoft.com/WindowsServer/en/library/0a658e97-51d5-4109-b461-a474c799964e1033.mspx?mfr=true

Windows Vista incluye en el comando SC las opciones showsid, sidtype, qsidtype, privs y qprivs para gestionar y consultar las nuevas opciones de seguridad de sus servicios. Iremos repasando cada una de estas opciones en sucesivos post, por el momento echaremos un vistazo a las opciones privs y qprivs.

sc qprivs [nombre del servicio] muestra los privilegios otorgados sobre dicho servicio, es decir, qué es capaz de hacer la cuenta con la que se ejecutan dichos servicios para ese servicio. Por ejemplo podemos ejecutar «sc qprivs spooler» para ver la información de privilegios del servicio de cola de impresión como podéis ver en la imagen posterior.

El servicio de cola de impresión se ejecuta como LocalSystem, vamos a ver la diferencia de privilegios entre Vista y XP para un mismo servicio:

Privilegios del servicio de cola de impresión en Windows Vista

SeTcbPrivilege, SeImpersonatePrivilege, SeAuditPrivilege, SeChangeNotifyPrivilege, SeLoadDriverPrivilege, SeAssignPrimaryTokenPrivilege

Privilegios del servicio de cola de impresión en Windows XP

SeTcbPrivilege, SeImpersonatePrivilege, SeAuditPrivilege, SeChangeNotifyPrivilege, SeLoadDriverPrivilege, SeAssignPrimaryTokenPrivilege, SeCreateGlobalPrivilege, SeCreatePagefilePrivilege, SeDebugPrivilege, SeCreatePermanentPrivilege, SeLockMemoryPrivilege, SeIncreaseBasePriorityPrivilege, SeLockMemoryPrivilege, SeProfileSingleProcessPrivilege, SeTcbPrivilege

La diferencia está clara: mientas que Windows Vista establece sus propios privilegios en el servicio, Windows XP hereda los privilegios del usuario LocalSystem, obteniendo una gran cantidad de privilegios innecesarios que posteriormente pueden utilizados con fines maliciosos si el servicio muestra alguna vulnerabilidad.

De todos modos arriba aparece un pequeño «engaño», dado que no es lo mismo ver «los privilegios concedidos a un servicio» que los «privilegios efectivos de un servicio en ejecución». Por supuesto, esto es otra cosa aplicable tansolo a Windows Vista, por ejemplo, en el caso de arriba, a los privilegios del servicio de cola de impresión habría que quitar además el privilegio «SeLoadDriverPrivilege» dado que el usuario System tiene denegado dicho privilegio; es decir: «Se aplica siempre el caso más restrictivo entre los privilegios de servicio y los de usuario», al más puro estilo UAC.

Para poder ver los permisos efectivos con los que se ejecuta un proceso disponemos de la herramienta Process Explorer de SysInternals, para ello ejecutamos Process Explorer con privilegios de administrador, nos dirigimos al proceso deseado (en este caso «spoolsv«) y seleccionamos «Properties». Dentro de las propiedades podremos ver diferentes pestañas con información relativa al proceso, a nosotros nos interesa comprobar la descripción del «Token de Seguridad» del proceso, de manera que debemos seleccionar la pestaña «Security». Dentro de esta pestaña, en la mitad inferior, podréis ver los privilegios asignados al proceso para el propietario (Owner) de este, es decir, para el usuario System, de esta manera podreis comprobar que pese a que el comando «sc qprivs spooler» muestra el privilegio «SeLoadDriverPrivilege», en los privilegios asignados al servicio, este privilegio aparece como deshabilitado.

Process Explorer funciona tanto en XP como en Windows Vista, así que no esta de más comprobar, de manera práctica la diferencia de privilegios efectivos sobre un servicio, aquí os dejo un par de capturas de pantalla para que le echéis un vistazo.

Process Explorer en Windows Vista

Process Explorer en Windows XP

Por último solo queda añadir que si «sc qprivs» nos sirve para realizar consultas, «sc privs» nos sirve para agregar o quitar privilegios a los servicios, así que ya tenemos otra herramienta con la que juguetear. Por ejemplo imaginemos que deseamos dar al servicio SPOOLER la capacidad de elevar la prioridad de un proceso, para ello debemos realizar lo siguiente:

sc privs spooler SeTcbPrivilege/SeImpersonatePrivilege/SeAu

ditPrivilege/SeChangeNotifyPrivilege/SeLoadDriverPrivilege/SeAssignPrimaryTokenP

rivilege/SeAssignPrimaryTokenPrivilege/SeIncreaseBasePriorityPrivilege

(En negrita los privilegios agregados)

Comprobamos con qprivs si el resultado ha sido correcto:

Nota: Fijaros que hay que separar cada privilegio por «/» y que hay que volver a agregar cada privilegio existente en el servicio ya que por defecto el comando SC los sobrescribe, es decir que si hiciéramos un «sc privs spooler SeIncreaseBasePriorityPrivilege» desaparecerían los privilegios iniciales.

Bueno, esto es todo, suficiente por ahora ¿no?, en el próximo post comprobaremos otro aspecto de WSH: «Los SID de servicio». 

Creo que ya podemos ir haciéndonos una idea de por qué las empresas antivirus se han puesto tan nerviosas con Windows Vista, y esto solo es una muestra de «una» las tecnologías de seguridad de este sistema operativo.

Por cierto, las mejoras que han sufrido los servicios en Windows Vista (y Windows Server 2008) no solo hacen referencia a la seguridad, también han mejorado en estabilidad y rendimiento gracias otros elementos como el nuevo sistema de parada de servicios, el sistema de inicio retrasado, acciones ante errores no críticos o el nuevo entorno de control de cambios de estado. Os dejo algunos enlaces por si la curiosidad os puede y queréis profundizar en estos temas. Un saludo y hasta el próximo post.

Enlaces:

MSDN Windows Services Documentation

http://go.microsoft.com/fwlink/?LinkId=71274

Impact of Session 0 Isolation on Services and Drivers in Windows Vista

http://go.microsoft.com/fwlink/?LinkId=71275

NotifyServiceStatusChange

http://go.microsoft.com/fwlink/?LinkId=71279

Service Control Handler Function

http://go.microsoft.com/fwlink/?LinkId=71282

Windows Vista incorpora entre sus mejoras un elemento ya disponible en Windows 2003 R2: El administrador de impresión.

El Administrador de Impresión es una herramienta MMC que nos permite administrar de manera eficiente y de forma remota los servidores de impresión de nuestra empresa. Esta herramienta mejora sustancialmente el panorama existente de administración de impresión pudiendo controlar todas las impresoras de la red desde una única consola e incluso implementarlas a través de políticas de grupo, pudiendo de esta manera evitar el uso de scripts de inicio de sesión.

En este post echaremos un vistazo a esta consola de administración, la cual se encuentra en «Herramientas Administrativas» dentro del Panel de Control, o bien desde MMC agregando el complemento correspondiente.

Como podéis comprobar en la imagen, esta herramienta esta dividida en diferentes secciones que iremos analizando a continuación.

Filtros Personalizados:

En esta sección podemos crear nuestros propios filtros para visualizar en un solo vistazo las impresoras que no interesen. Existen cuatro filtros por defecto:

Todas las impresoras: Muestra todas las impresoras existentes de los servidores de impresión incluidos en la consola.

Impresoras con trabajos: Este filtro muestra a todas aquellas impresoras que tienen trabajos en cola a la espera de ser impresos.

Impresoras no preparadas: Este filtro muestra aquellas impresoras cuya cola de impresión no esta en estado «listo».

Todos los controladores: Muestra los controladores de las impresoras implementadas de los servidores de impresión agregados a la consola de Administración de Impresión.

Podemos crear nuestros propios filtros de manera intuitiva pulsando con el botón derecho en «Filtros personalizados» y eligiendo «Crear nuevo filtro de impresora».

En este filtro estableceremos las condiciones, como que la cola de impresión se encuentre en estado «Pausa» o que el número de trabajos en cola sea mayor que 5. Finalmente podremos establecer otras medidas como que cuando se cumpla el filtro se nos envié un correo electrónico (indicando el servidor SMTP adecuado) o se nos ejecute un script determinado.

Servidores de impresión:

En esta sección podemos agregar los servidores de impresión que deseemos tansolo indicando su dirección IP o nombre. Dentro de cada servidor listado en la consola podremos comprobar las impresoras de que dispone, sus controladores asociados, los puertos y los formularios existentes para el tamaño del papel que deseemos usar. Desde aquí podremos gestionar todos los aspectos de impresión de las impresoras del servidor que deseemos, como los puertos, los controladores, la seguridad, la cola de impresión, los formularios, imprimir páginas de prueba etc.

Impresoras Implementadas:

Dentro de esta sección aparecen listadas aquellas impresoras que se encuentren gestionadas a través de políticas de grupo. Para agregar una impresora a la gestión de políticas de grupo debemos encontrarnos dentro de un Dominio y habiendo ejecutado el administrador de impresión con un usuario con privilegios de escritura sobre la política de grupo que deseemos. Debemos seleccionar una impresora de las listadas en la herramienta, abrimos el menú contextual sobre ella y seleccionamos «Implementar con directiva de grupo» donde nos aparecerá un menú para seleccionar la GPO apropiada y donde aparecen dos chekbox para poder indicar si la política se aplicará a la configuración de equipo o de usuario.

Si comprobáramos mediante GPMC la política apropiada, veríamos que la impresora se encuentra incluida dentro de «Impresoras Implementadas» en el apartado «Configuración de Windows».

Como hemos comprobado en este post, esta herramienta supone una gran mejora en la administración de servidores de impresión.

Solo queda por añadir una cosa: «¿Esta hoja es tuya o es una impresión mía?» (Dedicado a la rana Rodolfo).

Nos vemos en el próximo Post.

Finalizamos
esta serie de post sobre las directivas de Windows Vista haciendo un repaso a
las nuevas directivas de red cableada y red inalámbrica disponibles para este
sistema operativo, en este caso además necesitaremos pertenecer a un dominio de
Windows Server 2008 (también conocido como LongHorn) o bien a un dominio de
Windows 2003 con el esquema de AD actualizado (el proceso se realiza con ADPREP
de manera similar al ADPREP de Windows 2003), de esta manera también empezamos
a introducirnos en el mundo de Windows Server 2008 que ya está a la vuelta de
la esquina.

Estas
políticas no están disponibles de manera local mediante gpedit.msc de tal
manera que necesitamos hacer uso de la versión de GPMC de Windows Vista (GPMC
2.0) dentro de un dominio, debiendo tener este además el esquema actualizado
para soportarlas (solo es necesario actualizar el esquema para estas dos
políticas, el resto funcionan correctamente dentro de un entorno Windows 2003).
No abordaré la actualización del esquema de AD en este post ya que merecería un
artículo aparte, así que dando por supuesto que el esquema esta actualizado o
que disponemos de un dominio de Windows Server 2008 lo siguiente que tendríamos
que hacer es invocar desde un equipo con Windows Vista a la herramienta GPMC.msc
(Group Policy Management Console), siendo la manera mas rápida la propia barra
de búsqueda del menú inicio. GPMC de Windows Vista es similar al de Windows
2003 pero en un entorno MMC 3.0, si no conocéis esta herramienta podéis echar
un vistazo a la siguiente guia:  http://www.microsoft.com/spain/technet/recursos/articulos/gpmcinad.mspx

Una vez que
nos encontremos en la consola de edición de la política de grupo que deseemos
cambiar nos dirigimos a «Configuración de Windows > Configuración de
Seguridad»  donde nos encontramos las
políticas de redes que estamos tratando en este post (como podéis ver en la
imagen).

La
política de red cableada permite que mediante GPO configuremos una
autenticación 802.1x (sistema cada día más presente en las empresas) para aquellas
cuentas de equipo a las que afecte dicha política. 802.1x es una solución de
autenticación que nació como método de autenticación telefónica y que requiere
un servidor RADIUS (conocido en Windows Server 2003 como IAS y en Windows
Server 2008 como NPS) y un dispositivo intermedio conocido como NAS (normalmente un Switch o un
Punto de Acceso Inalámbrico) que funcione como cliente de dicho servidor
Radius. La autenticación suele realizarse mediante certificados (presentando
cada cliente un certificado valido para la conexión) o bien introduciendo las
credenciales de un usuario permitido, todo a través del protocolo EAP (Extensible
Authentication Protocol) donde las subtipos más conocidos son LEAP (de Cisco),
EAP-MSCHAVv2, EAP-TLS y EAP-PEAP, siendo estos dos últimos los únicos que
podemos usar en esta directiva, es por tanto necesario disponer de una CA
(Certificación Authority) en la empresa que pueda emitir certificados validos
para los clientes o incluso para tarjetas inteligentes. Gracias a esta nueva
política los equipos cliente ya no requieren una configuración individualizada
mediante la pestaña «autenticación» de las propiedades de las tarjetas de red.
Todo esto se hace especialmente importante en Windows Server 2008 donde la
autenticación 802.1x es uno de los métodos posibles para la implementación del
famoso NAP (Network Access Protección).

Para crear la directiva pulsamos el botón
derecho del ratón en Directiva de red cableada y seleccionamos «Crear Nueva Directiva de Windows Vista»,
en la primera pestaña podemos poner un nombre y una descripción a la directiva,
así como configurar si deseamos desactivar el «servicio de configuración
automática de redes cableadas» lo cual deshabilitaría 802.1x en los clientes y
no nos dejaría editar el resto de opciones de la directiva.

Tras establecer el
nombre y la descripción de la directiva nos vamos a la pestaña «seguridad»
donde (como se aprecia en la imagen) podremos realizar una configuración mucho
más detallada del entorno 802.1x pudiendo elegir entre PEAP (usado con mucha
frecuencia en redes WIFI) o EAP-TLS (que aparece indicada por el texto «tarjeta
inteligente u otro certificado» en la imagen) siendo PEAP el método más seguro
de los dos puesto que realiza una doble autenticación. El botón propiedades del método de autenticación nos
permite configurar los aspectos comunes de EAP-TLS/PEAP como la CA de confianza o el uso de
tarjetas inteligentes; si nunca habeis configurado este sistema podéis echar un
vistazo al siguiente manual:

http://www.microsoft.com/spain/technet/recursos/articulos/peap_a.mspx

La
opción de «aplicar configuración avanzada» habilita una serie de checkbox que
permiten configurar el comportamiento de la comunicación EAPOL (EAP Over Lan)
donde podremos configurar los tiempos de espera para volver a solicitar
autenticación ante una autenticación denegada, el número de mensajes
EAPOL-start consecutivos enviados, el tiempo de separación entre cada uno de
estos EAPOL consecutivos etc., lo recomendable sería dejar la configuración por
defecto a no ser que se intente realizar algún tipo de depuración sobre la
comunicación.

Windows
Vista también trae una política mejorada de configuración de acceso inalámbrico
para los clientes del dominio, permitiéndonos crear políticas compatibles con
XP (no requieren actualización del esquema de AD) y políticas propias de
Windows Vista que son las que se muestran en la imagen. La función principal de
esta política es distribuir de manera segura la configuración de las redes
inalámbricas disponibles a los clientes de un dominio (perfiles, SSID, métodos
de autenticación, redes preferidas etc.), este aspecto es común tanto para
Windows Vista como para Windows XP con la excepción de que en las directivas de
XP no se pueden crear perfiles de configuración, con lo que no se pueden
exportar o importar las configuraciones en forma de archivos XML.

El resto de configuraciones son similares a las de XP a excepción de la pestaña «permisos de red»
de la directiva de Windows Vista que nos permite crear una lista de SSID
aprobados y denegados. Con todo esto simplificamos la tarea de configurar redes
inalámbricas a los usuarios y podemos asegurar que estos solo se conecten a aquellas
redes aprobadas por nuestra empresa consiguiendo una reducción en la necesidad
de soporte así como una mayor seguridad.

Bueno,
pues aquí doy por finalizado esta serie de post sobre GPOs en Windows Vista,
espero que haya sido de vuestro interés, seguiré en futuros post desvelando
nuevas características de este innovador sistema operativo, me despido hasta
entonces.

GPOs en Windows Vista I : Múltiples políticas locales

GPOs en Windows Vista II : Plantillas administrativas

GPOs en Windows Vista III : Integración con Active Directory

Políticas de Grupo en Windows Vista IV : Restriccion de hardware

Políticas de grupo en Windows Vista V : Directivas de red

6. Búsquedas en el Reproductor de Windows Media.

Para finalizar el análisis, me voy a centrar en cómo hacer búsquedas en Windows Media Player. Esto nos da la oportunidad de buscar elementos que se encuentren en la biblioteca o en un servicio de música en línea, aplicando unos criterios.

    6.1. Buscar elementos desde la biblioteca:

Para que la búsqueda sea fácil, es importante que cada uno de los archivos incluya información multimedia, como título, autor, etc. De esta forma podremos disponer rápidamente de nuestros archivos.

Para llevar a cabo una búsqueda desde la biblioteca, tan solo tendremos que:
-Hacer clic en la ficha biblioteca.
-Seleccionar una categoría.
-Introducir el texto que queremos encontrar en el cuadro de búsquedas (esquina superior derecha).

Distintas opciones para simplificar el campo de búsqueda.

Ejemplo de búsqueda seleccionando los intérpretes y añadiendo en el cuadro de búsquedas el nombre del autor:

De la misma forma, podemos realizar una búsqueda por el año, la clasificación del álbum, el género o por los archivos agregados recientemente a la biblioteca.

    6.2 Búsquedas avanzadas en el Reproductor de Windows Media.

Utilizando criterios de búsqueda (incluso se permite utilizar filtros booleanos), podremos seleccionar la información que más nos interese en cada momento; los siguientes ejemplos muestran como conseguirlo:

Ej.: Buscar el álbum de Aisha Duo pero solo la canción Despertar: «aisha duo despertar».

Ej.: Buscar el álbum de Aisha Duo pero no mostrar la canción Despertar: «aisha duo -despertar».

De la misma forma, para buscar una frase exacta, la incluiremos entre comillas («).

Ej.: Buscar todos los discos que pertenezcan al género jazz y rock: «Jazz OR Rock».

Disponemos además, de la utilización de atributos de información multimedia determinados (Atributo: elemento que busca). Por ejemplo, escribe Genre: Jazz para buscar los álbum que pertenezcan a ese género.

La siguiente tabla, extraída de la ayuda de Windows Vista, muestra los ejemplos de palabras de búsquedas y como se usan cada uno:

Con esto terminaríamos el análisis de búsquedas en Windows Vista. Espero que os haya gustado!!

Un saludo

Ya hemos comprobado las principales mejoras referentes al tratamiento de las políticas de grupo en Windows Vista. Podéis encontrar las referencias a continuación:

GPOs en Windows Vista 1

GPOs en Windows Vista 2

GPOs en Windows Vista 3

Solo nos queda echar un vistazo a las más de 800 nuevas políticas incorporadas para le gestión de este Sistema Operativo, por lo que en los próximos post iremos dando un repaso a aquellas políticas más destacadas. De momento podeis descargaros el listado completo de nuevas políticas en:

http://www.microsoft.com/downloads/details.aspx?familyid=41DC179B-3328-4350-ADE1-C0D9289F09EF&displaylang=en

A lo largo de este Blog algunos compañeros ya han hecho alguna referencia a ciertas políticas de grupo como aquellas para la gestión de UAC, Bitlocker o QoS por lo que no es necesario volver a ellas. En el presente post trataremos uno de los conjuntos de políticas más destacados: La Instalación de Dispositivos.

Hoy en día las memorias flash y otros dispositivos de almacenamiento USB están en manos de todos, ya sean PenDrives, MP3, tarjetas de memoria o discos duros externos, en las empresas de hoy en día donde el uso de disqueteras y los lectores de CD-DVD hace tiempo que está deshabilitados para prevenir posibles gusanos, ataques internos y robos de datos suponen un claro riesgo de seguridad, pese a que algunos de estos problemas los podamos paliar con otras herramientas como Rights Management Services (RMS) o las distintas soluciones antimalware, todos somos cocientes de la posibilidad de que alguien ajeno a un departamento pueda en un momento dado conectarse a un equipo y en menos de 5 minutos llevarse información confidencial de la empresa en un dispositivo USB o peor aun: que un empleado en su último día de trabajo conecte uno de estos dispositivos a un equipo y lo infecte de manera intencionada con un gusano o un rootkit. La mejor solución a este problema es a la vez la más sencilla e intuitiva: imposibilitar la instalación de dispositivos externos. Antes de Windows Vista teníamos que recurrir a soluciones de terceros para aplicar esta medida, pero gracias a las nuevas políticas incorporadas en este S.O. esta situación ha cambiado.

Las nuevas políticas de restricción e instalación de hardware las encontramos en «Configuración de equipo > Plantillas administrativas > Sistema». Dentro de las posibilidades de restricción de hardware tenemos dos conjuntos principales de políticas: «Acceso de Almacenamiento Extraíble» donde podremos deshabilitar las capacidades de lectura o escritura de distintos dispositivos e «Instalación de dispositivos» donde tendremos la posibilidad de restringir la instalación de los controladores de aquellos dispositivos que indiquemos, siempre que sus drivers no se encuentren ya instalados en el equipo.

La configuración de las políticas de uno y otro grupo son muy sencillas de configurar, simplemente habitamos o deshabilitamos las políticas según el comportamiento que deseemos, así, por ejemplo, si habilitamos la política «CD y DVD: denegar acceso de lectura» veremos que al intentar acceder a un CD en el equipo nos aparece una advertencia indicando «Acceso Denegado»

 
Así mismo si configuramos la política «impedir instalación de dispositivos extraíbles» comprobamos que al conectar un dispositivo extraíble, como una llave USB, nos aparece un globo de información indicándonos que no ha sido posible instalar el dispositivo.

 
Ambos tipos de políticas, las de «Acceso de Almacenamiento Extraíble» y las de «Instalación de dispositivos» tienen la capacidad de aplicarse a tipos de dispositivos personalizados, usando para ello el GUID de dicho tipo de dispositivos, es decir que teneros la capacidad de impedir el uso o instalación de diferentes dispositivos según su GUID. La forma más sencilla de saber el GUID de un dispositivo es comprobarlo en el «administrador de dispositivos» en la pestaña detalles de las propiedades del dispositivo a comprobar.

Por ultimo, en el caso de las políticas del tipo de «Instalación de dispositivos» tenemos la posibilidad de escribir un texto personalizado para el globo de información que nos aparece al no poder instalar los controladores.

 
Como habéis podido comprobar en este post, Windows Vista ha mejorado sustancialmente sus capacidades de administración en sus nuevas políticas de grupo, capacidades que sin duda no tardaremos mucho en verlas funcionando en muchas empresas de nuestro alrededor. Por mi parte continuaré descomponiendo el entresijo de políticas de Windows Vista en sucesivos posts. Me despido hasta entonces.

En este tercer POST sobre las Políticas de Grupo en Windows Vista nos introduciremos  en cierta medida en el comportamiento de estas en un Directorio Activo, ya sea de Windows 2000, Windows 2003 o Windows Codename LongHorn.

Las mejoras en el tratamiento de políticas de grupo no se quedan tan solo en las políticas locales, Windows Vista también ofrece sus ventajas en un entorno de Active Directory, de esta manera comprobaremos que tenemos la posibilidad de crear un repositorio centralizado de políticas de grupo en el Directorio Activo con los consecuentes beneficios en la replicación de estas y también veremos que podemos configurar políticas propias de Windows Vista a través de la consola GPMC (Group Policy Management Console) que ya viene incluida en este Sistema Operativo en su versión 2.0.

Edición de Políticas de Windows Vista en Active Directory:

Una duda que nos pueden surgir entorno a las políticas de grupo es cómo integrar las numerosas nuevas directivas de Windows Vista (como el Control Parental, Bit Locker, UAC etc.) en Active Directory para que estas se apliquen al resto de equipos con Windows Vista instalado, sabiendo además que dichas políticas no están presentes en Windows 2003. La respuesta es sencilla: Usando la herramienta GPMC.msc desde un equipo cliente del dominio con Windows Vista instalado.

La herramienta GPMC de Windows Vista nos posibilita editar políticas propias de este S.O. pero no en su totalidad, algunas políticas nos devolverán el siguiente error si intentamos configurarlas:

Para poder editar estas políticas deberemos disponer de «Windows Codename LongHorn» o actualizar el esquema de Windows 2003 para que soporte estas características mediante la versión de la herramienta adprep incluida en LONGHORN (Algo nada recomendable mientras LongHorn aun se encuentre en estado de Beta ya que las modificaciones en el esquema de AD no se pueden eliminar posteriormente). Las políticas afectadas por este problema son las siguientes:

• Administrador de directivas de red cableada
• Directivas de red inalámbrica (solo las propias de Windows Vista)

El resto de nuevas políticas (más de 800) no son afectadas por este problema, es decir que podremos configurarlas a través de la consola GPMC de Windows Vista. Esto es posible por que las modificaciones a través de GPMC son guardadas en un archivo binario llamado «Registry.pol» ubicado en la carpeta «User» o «Machine» según sea el caso de la carpeta «SysvolDomainPoliciesGuid_de_Politica» del maestro PDC desde el cual se replicará al resto de Controladores de Dominio. Es decir que aun que en Windows 2003 no veamos las plantillas administrativas y configuraciones propias de Windows Vista, los equipos clientes de Windows Vista si van a poder reconocer dichas configuraciones y aplicarlas.

Para hacer la comprobación podéis configurar una GPO en un dominio a través de la herramienta GPMC de Windows vista con alguna opción propia de este (como Bitlocker), conectaros desde otro equipo cliente con este S.O. instalado y usar GPMC o RSOP (conjunto resultante de directivas) para comprobar que dicha política también se le está aplicando a él.

El Repositorio Centralizado:

Cada vez que creamos un nuevo Objeto de Política de Grupo se crea una nueva carpeta en «SysvolDomainPolicies» del maestro PDC en la cual su ubicará su configuración, así como una copia de las plantillas administrativas de las que hace uso dicha política, las cuales podemos ver dentro de la subcarpeta «adm», que ocupa aproximadamente 4MB dependiendo de la cantidad de plantillas de las que hagamos uso. Esto significa que por cada GPO que realicemos se crearán aproximadamente 4MB de información redundante que luego se replicarán al resto de Controladores de Dominio, algo a tener en cuenta sobretodo en grandes infraestructuras con un gran número de GPOs y de Controladores de Dominio, y más aun si dichos DCs están distribuidos en diferentes «Sitios». Por ejemplo una configuración de 10 GPOs supondrían unos 30MB de información redúndate a replicar por cada Controlador de Dominio. Windows Vista ofrece una solución de optimización mediante un repositorio de plantillas administrativas centralizado, evitándose de esta manera la información redundante, ahorrando recursos y mejorando el sistema de replicación (algo ya de por si mejorado mediante el nuevo sistema de replicación DFS incluido ya en la versión R2 de Windows 2003).

Para crear dicho repositorio debemos copiar la carpeta «PolicyDefinitions» de la carpeta «%systemroot%» de un equipo con Windows Vista a la carpeta «SysvolDomainPolicies» de un Controlador de Dominio (preferiblemente el maestro PDC) desde el cual se replicará al resto de DCs. Como podéis comprobar, también aprovechamos las mejoras ya comentadas en anteriores post de las plantillas admx como la compatibilidad con distintos idiomas (archivos adml), aun que como es lógico, este repositorio centralizado no es compatible con Versiones Anteriores de Windows.

Para demostrar el correcto funcionamiento del repositorio probaremos a renombrar como *.old una de las plantillas *.admx de este (en el ejemplo he usado ParentalControls.admx), ya que si todo funciona como debería las configuraciones ofrecidas por dicha plantilla deberían desaparece al intentar editar una GPO mediante GPMC de Windows Vista

.

Las configuraciones de control parental han desaparecido demostrando que el repositorio esta funcionando correctamente, si volvemos a renombrar el archivo con la extensión correcta comprobaremos que dichas configuraciones vuelven a estar disponibles como puede verse en la imagen de abajo.

Como hemos comprobado a lo largo de esta serie de post sobre GPOs en Windows Vista, los cambios han sido sustánciales, pero no todo se queda aquí, en el próximo post iremos comprobando las políticas más destacadas de este nuevo Sistema Operativo y aquello que nos permiten hacer, me despido hasta entonces.

Continuamos este repaso por las
mejoras en las políticas de grupo de Windows Vista abordando en este segundo
post los cambios relativos a las plantillas administrativas.

Un repaso general de las plantillas administrativas:

Una parte fundamental de las
políticas de grupo son las plantillas administrativas, es decir, aquellos
archivos responsables de que podamos personalizar de manera sencilla el
comportamiento de nuestro equipo o los equipos de nuestra empresa a través de la MMC de edición de políticas de
grupo. En Windows XP y Windows 2000 las plantillas administrativas se
encontraban en la carpeta oculta
%Windir%inf en forma de archivos con extensión *.adm editables a través
del bloc de notas o con herramientas especializadas para ello. Echando un
vistazo al contenido de estos archivos podemos comprobar que no son más que ficheros
que vinculan una política determinada de la MMC de políticas de grupo a un cambio en el
registro de Windows, teniendo por tanto la posibilidad de crear nuestras
propias plantillas administrativas orientadas a nuestras necesidades o las de
nuestra empresa pero con el inconveniente de tener que estar familiarizado con
su modelo de configuración específico que sigue un lenguaje no estándar.

Desde el punto de vista del
administrador, las plantillas administrativas pueden vincularse o desvincularse
de una GPO a través del editor de políticas de grupo (gpedit.msc), donde, tanto
en la configuración de equipo como en la configuración de usuario, encontramos
una carpeta llamada «Plantillas Administrativas» que muestra las
configuraciones ofrecidas por los archivos *.adm mencionados anteriormente. Para
agregar o quitar una plantilla a nuestra configuración de políticas de grupo debemos
hacer clic con el botón derecho del ratón sobre la carpeta de plantillas
administrativas, y seleccionar «agregar o quitar plantillas». Por defecto
tenemos 5 plantillas vinculadas en nuestro equipo:

• Conf.adm: configuración
  de NetMeeting

• Inetres.adm:
  configuración de Internet Explorer.

• System.adm: configuración
  del sistema operativo

• wmplayer.adm:
  configuración del Reproductor de Windows Media

• wuau.adm:
  configuración de Windows Update

Podemos agregar nuevas plantillas
de productos Microsoft o de productos de otros fabricantes, un ejemplo de esto
son las plantillas de OFFICE 2007 o Internet Explorer 7 que se encuentras
disponibles para descarga en los siguientes enlaces:

Plantillas administrativas para
OFFICE 2007:

http://www.microsoft.com/downloads/details.aspx?FamilyID=92d8519a-e143-4aee-8f7a-e4bbaeba13e7&DisplayLang=en

Plantillas administrativas para
Internet Explorer 7:

http://www.microsoft.com/downloads/details.aspx?FamilyID=11AB3E81-6462-4FDA-8EE5-FCB8264C44B1&displaylang=en

Todas las políticas que vayamos
agregando son incluidas automáticamente en %windir%system32GroupPolicyAdm
(GroupPolicy es una carpeta oculta donde se guardan las configuraciones de
nuestras políticas locales).

En los siguientes enlaces podéis encontrar
más información referente a plantillas administrativas en Windows 2000 y XP:

http://www.microsoft.com/spain/technet/recursos/articulos/gpfeat.mspx

https://www.microsoft.com/spain/technet/recursos/articulos/secmod63.mspx

Plantillas administrativas en Windows Vista:

El concepto de plantilla
administrativa en Windows Vista es exactamente el mismo que en Windows 2000 o
XP pero con un par de cambios sustanciales:

• Formato
  estándar de configuración (XML): Windows Vista ha cambiado las
  plantillas administrativas *.adm por las nuevas *.admx siendo compatible
  con cualquiera de los dos formatos. Las plantillas *.admx están
  configuradas mediante el lenguaje de marcas XML desvinculándose así del
  formato específico de los archivos *.adm anteriores, y obteniendo todas
  las ventajas de XML como la portabilidad, la facilidad de configuración, la
  menor especificidad, una mejor integración con otros sistemas y
  aplicaciones etc. Además Microsoft ha puesto a disposición de los usuarios
  una herramienta llamada ADMX
  Migrator que permite transformar fácilmente cualquier plantilla en
  formato ADM al nuevo formato ADMX, así como realizar ediciones de estas de
  manera sencilla y sin tener que estar completamente familiarizado con el
  formato de dichos archivos.

ADMX Migrator es
descargable del siguiente del siguiente vínculo:

http://www.microsoft.com/downloads/details.aspx?FamilyID=0f1eec3d-10c4-4b5f-9625-97c2f731090c&DisplayLang=en

Las plantillas
administrativas con extensión .admx se encuentran ubicadas en %windir%PolicyDefinitions y son mucho
más modulares que los archivos *.adm dividiendose en aproximadamente 150
plantillas, cada una de las cuales encargadas de un tema en concreto, por
ejemplo IIS.admx para Internet
Information Server, WindowsMessenger.admx
para el Messenger o ParentalControls.admx
para las configuraciones de control parental.

• Independencia
  del idioma: Realmente esta característica se desprende también del
  lenguaje XML que permite hacer referencia a otro archivo donde, en este
  caso, estarán ubicadas las descripciones de cada una de las políticas,
  esto permite que la configuración de las plantillas administrativas sean
  independientes del idioma (característica recurrente en Windows Vista).
  Los archivos de idioma tienen el mismo nombre que los archivos de plantilla
  administrativa, pero con extensión *.adml y están ubicados en la carpeta
  de idioma correspondiente (es-ES, us-EN, fr-FR etc.) dentro de la carpeta %windir%PolicyDefinitions

           Las plantillas administrativas
con formato *.admx son vinculadas de manera automática al editor de                   políticas de grupo en el momento en que la añadimos a la carpeta PolicyDefinitions sin
ser necesario                hacer uso de «agregar o quitar plantillas» que queda reservado
para los archivos *.adm heredados.

En el próximo post abordaremos la
manera de crear un repositorio centralizado de políticas de grupo en Active Directory
para Windows Vista.