vista-tecnica

Hola,

Aprovechando que hoy es domingo, voy a dejar publicado el resumen de los artículos que se han ido publicando en el blog de Vista-Técnica. Así es más fácil seguir su lectura.

¡Saludos!

User Account Control (UAC)
Artículo en 6 partes escrito por Julián Blázquez

– User Account Control: Parte I de VI
– User Account Control: Parte II de VI
– User Account Control: Parte III de VI
– User Account Control: Parte IV de VI
– User Account Control: Parte V de VI
– User Account Control: Parte VI de VI

Bitlocker
Artículo en seis partes escrito por Juan Luís G. Rambla

– Bitlocker: Parte I de VI
– Bitlocker: Parte II de VI
– Bitlocker: Parte III de VI
– Bitlocker: Parte IV de VI
– Bitlocker: Parte V de VI
– Bitlocker: Parte VI de VI

Superfetch, ReadyBoost y ReadyDrive
Artículo en 4 partes escrito por Juan Francisco Arrabe

– SuperFetch: Parte I de IV
– SuperFetch: Parte II de IV
– SuperFetch: Parte III de IV
– SuperFetch: Parte IV de IV

Protección contra Buffer Overflow (DEP & ASLR)
Artículo en 4 partes escrito por Chema Alonso

– Protección Buffer Overflow: Parte I de IV
– Protección Buffer Overflow: Parte II de IV
– Protección Buffer Overflow: Parte III de IV
– Protección Buffer Overflow: Parte IV de IV

Business Desktop Deployment (BDD)
Despliegue masivo con Windows Vista. Artículo en 5 partes escrito por Joshua Saenz

– Business Desktop Deployment: Parte I de VI
– Business Desktop Deployment: Parte II de VI
– Business Desktop Deployment: Parte III de VI
– Business Desktop Deployment: Parte IV de VI
– Business Desktop Deployment: Parte V de VI

Firewall de Windows Vista
Artículo en 2 partes escrito por Juan Garrido

– Firewall de Windows Vista: Parte I de II
– Firewall de Windows Vista: Parte II de II

Versiones de Windows Vista
Artículo en seis partes escrito por Juan Luís G. Rambla

– Versiones de Windows Vista: Parte I de VI
– Versiones de Windows Vista: Parte II de VI
– Versiones de Windows Vista: Parte III de VI
– Versiones de Windows Vista: Parte IV de VI

GPOs en Windows Vista
Artículo en 4 partes escrito por Juan Francisco Arrabe

– GPOs en Windows Vista: Parte I de IV
– GPOs en Windows Vista: Parte II de IV
– GPOs en Windows Vista: Parte III de IV
– GPOs en Windows Vista: Parte IV de IV

Hola a tod@s! 

Me llamo Juan Garrido, en la community me conocen por Juanillo y me pasaré de vez en cuando por este blog para dejar algún que otro articulillo. Hoy os vamos a hablar del nuevo Firewall de Windows Vista. 

El tiempo parece que avanza cada día más rápido, y junto a él, estamos nosotros. Nunca antes el mundo había sido tan pequeño. Y esto se lo debemos en gran parte a las comunicaciones. Mensajería corporativa, correo interno, streaming para reuniones que antes serían imposibles, VOIP, gente que viene de otras empresas, ejecutivos con sus portátiles que van de una oficina a otra, etc…

Todo esto sería maravilloso si pasase exactamente así. Pero la realidad no es siempre de color de rosas y una red, por pequeña que sea, se puede convertir en un campo de batalla, si no tomamos las debidas precauciones.

Vivimos en un tiempo en el que las redes corporativas y las no corporativas son cada día más complicadas de administrar. Comerciales que conectan sus PDA a los portátiles o equipos de sobremesa, conexión de dispositivos de almacenamiento externo, tener que realizar operaciones en distintas redes, como por ejemplo, aeropuertos, ejecutivos que van de oficina en oficina y necesitan conectarse a la Red, etc..

Desgraciadamente, junto a este tipo de comportamiento, pueden venir a veces acompañados de la mano ciertas amenazas de seguridad como pueden ser Malware, Exploits, Spyware, DOS, Script-Kiddies, etc..

Y aquí es donde entra en acción un Firewall. Algo que ayude a minimizar los riesgos, sin perder un ápice de experiencia.

Antiguamente (y no hablo de mucho tiempo atrás) poniendo firewalls en el perímetro, podíamos permitirnos el lujo de tener a nuestros clientes sin firewall, pero hoy en día, con las nuevas técnicas de ataque, es casi de obligado cumplimiento defender en profundidad tanto a nuestros servidores como a nuestros clientes. Al fin y al cabo ellos serán los que utilicen la tecnología que les podamos proporcionar. Y por qué no aportarles tecnología y seguridad?

Dicho esto, en esta ocasión vamos a hablaros del nuevo Firewall de Windows Vista.

El Firewall de Windows Vista ayudará a mitigar estos desafíos que hemos comentado en líneas anteriores. Y por qué decimos mitigar? Pues porque un Firewall no es una panacea. La seguridad al 100% nunca está, ni estará garantizada. Un Firewall podrá reducir la superficie de ataque a una computadora, pero nunca asegurarla al 100%.

Dicho esto y sin haberme cogido los dedos  J, vamos a ver las nuevas características o features del nuevo Firewall de Vista.

Por caminos que no quede…[;)]

Este es el nuevo aspecto de las consolas MMC 3.0. A los administradores les resultará más fácil adaptarse a este tipo de consolas, ya que por defecto se mantendrá el mismo diseño en otras aplicaciones, como las nuevas versiones de ISA Server y los nuevos productos de la familia Forefront por ejemplo, que traerán un aspecto parecido.

Por un lado vemos la parte derecha, que nos presenta varias opciones. Desde exportar/importar directivas, hasta establecer filtros en base al perfil, estado de conexión o por grupos.

En la parte izquierda tenemos las opciones de configuración y monitorización de reglas. Podremos configurar tanto las reglas de entrada como las de salida, y monitorizar el estado de conexiones y actividad del Firewall.

En la parte central podremos ver el estado en que se encuentra nuestro Firewall. Podremos ver los perfiles de conexión que trae por defecto Windows. Perfil de dominio, perfil privado y perfil público, accesos para crear reglas de entrada o salida y un apartado de recursos y documentación.

Para acceder a las propiedades del Firewall de Windows con seguridad avanzada, podremos hacerlo de dos formas.

Pinchar con el botón derecho del ratón en Firewall de Windows con seguridad avanzada, tal y como se muestra en la imagen:

En este último post sobre el Control de cuentas de usuarios de Windows Vista trataremos las posibles configuraciones que podremos realizar sobre el tratamiento que pueden sufrir las aplicaciones.

Una de las principales configuraciones que realiza UAC (por defecto) para el tratamiento de las aplicaciones es la virtualización del registro y archivos del sistema. Dicha configuración permite que las aplicaciones heredadas que no se podían ejecutar con privilegios de usuario estándar, ahora tengan total funcionalidad sin suponer un riesgo para el sistema. ¡Nunca jamás un usuario necesitará privilegios administrativos por culpa de una aplicación!

El funcionamiento de estas aplicaciones es totalmente correcto, debido a que cuando acceden al registro o archivos del sistema (a los que no tiene permiso) lo hacen sobre un registro o archivo virtual. Permitiendo acceder a la información correcta, pero evitando así modificaciones peligrosas o errores que puedan surgir por falta de privilegios para las tareas que la aplicación realiza.

Esta configuración viene definida por la directiva virtualizar los errores de archivo y escritura de Registro por ubicaciones de usuario que por defecto viene habilitada.

¿Qué ocurrirá cuando se necesite instalar aplicaciones de forma remota?

Uno de los problemas que a priori nos podemos encontrar en un entorno empresarial, con el control de cuentas de usuario, es la instalación de aplicaciones mediante GPOs o SMS. Pues bien, no existe tal problema.

Tenemos la posibilidad de convivir con el nivel de seguridad del UAC y permitir administrar los equipos clientes, mediante instalación de aplicaciones remotamente, sin tener que aceptar la elevación de privilegios por parte del usuario.

Para realizar esta configuración contamos con una directiva, detectar instalaciones de aplicaciones y pedir confirmación de elevación, que indica dicho comportamiento. La directiva por defecto está habilitada, obligando a aceptar la elevación de privilegios. Pero si la desactivamos, únicamente permitimos la elevación automática de privilegios para aquellas instalaciones que se produzcan a través de GPOs o SMS.

Por lo tanto el control de cuentas de usuario se adapta a las necesidades que pudieran surgir en la administración de los equipos clientes por parte de los administradores.

¡Recordad! El control de cuentas de usuario es uno de los máximos responsables de la seguridad tan elevada con la que cuenta el nuevo sistema operativo de Microsoft. Configurémoslo y asumamos los riegos que corremos con cada una de las configuraciones.

Disfrutad del UAC.

Referencias

• Control de Cuentas de Usuarios (0): ¿Sistemas Seguros?


• Control de Cuentas de Usuarios (I)


• Control de Cuentas de Usuarios (II)


• Control de Cuentas de Usuarios (III)


• Control de Cuentas de Usuarios (IV)

Llega la hora de preparar en despliegue de la imagen que hemos estado preparando durante las últimas entregas de esta serie de artículos.

Pero, antes de iniciar las tareas de preparación, me gustaría explicar algunos conceptos y opciones de despliegue que BDD 2007 soporta.

Con BDD 2007 podemos realizar básicamente dos tipos de despliegue de sistema operativo: Light Touch (LTI) y Zero Touch (ZTI). Ambos tipos comparten un conjunto de scripts y archivos de configuración comunes.

·         Scripts

·         Archivos de configuración

·         Base de datos de Configuración

·         Variables de entorno

·         Archivos Log

Los scripts proporcionan un modo de automatizar el proceso de implantación y generan archivos log del proceso que han ejecutado para poder realizar un seguimiento o identificación de problemas durante alguna fase del proceso. Para que los scripts se ejecuten correctamente, éstos interpretan los archivos de configuración, los cuales están localizados en la carpeta Control del punto de implantación (Deployment Point) y se crean con los asistentes del Deployment Workbench.

La base de datos de configuración es una extensión lógica de los archivos de configuración. Permite centralizar y almacenar la configuración en una base de datos SQL Server. Durante el proceso de implantación, los scripts consultarán la base de datos según se necesite. Sólo se recomienda esta opción si podemos garantizar que los equipos cliente disponen de una conexión permanente y de alta velocidad al servidor SQL, si no es así, deberemos utilizar los archivos de configuración almacenados localmente en el equipo de despliegue.

La diferencia entre Light Touch (LTI) y Zero Touch (ZTI) consiste más bien en la infraestructura que hay detrás y en la cual nos basamos para realizar el despliegue. Mientras que LTI se realiza con herramientas gratuitas como son BDD 2007, WAIK y WDS, Zero Touch requiere, además de estas herramientas, SMS 2003 SP2 con OSD Feature Pack. La incorporación de SMS en el proceso de preparación y despliegue de sistemas operativos aporta un mayor grado de automatización, sobre todo cuando queremos incluir paquetes de software de terceros junto con una implantación muy personalizada.

En nuestro laboratorio seguiremos los procedimientos de Light Touch, que a pesar del nombre, también se pueden automatizar muchas de las fases y tareas de implantación para que sea un proceso completamente desatendido.

Tanto ZTI como LTI utilizan un archivo denominado bootstrap.ini para especificar propiedades que posteriormente se utilizarán en otro archivo de personalización llamado CustomSettings.ini. Bootstrap.ini  proporciona la información necesaria del punto de distribución, SMS OSD Feature Pack, Windows PE y opciones locales de teclado. En la siguiente tabla vemos algunas de las propiedades que se pueden utilizar en LTI y ZTI:

Estos archivos se crean desde el Deployment Workbench cuando se crea el punto de implementación (Deployment Point). Después de que estén creados podemos hacer cualquier cambio manualmente en los archivos.

Pero esto no termina aquí. Todas las tareas de implantación se ejecutan siguiendo un guión que también podemos personalizar. A esto le llamamos el secuenciador de tareas. Las fases o tareas se definen en un archivo llamado TS.xml, en el cual se identifica la secuencia correcta de ejecución de todo el proceso de implantación.

Las fases incluidas en TS.xml son:

·         Fase de validación: realiza las verificaciones necesarias para garantizar que la instalación del sistema operativo puede proseguir.

·         Fase de captura de estado de usuario: lee la información de los archivos de configuración, bases de datos y equipo local para determinar cómo se debe ejecutar el proceso de instalación y a captura del perfil de usuario. También identifica el espacio necesario para guardar el perfil completo utilizando USMT, invocando a ScanState.exe.

·         Fase de preinstalación: En esta fase se confirma que toda la información necesaria se ha recogido en los escenarios de actualización y reinstalación de equipos. En los escenarios de nueva instalación y remplazo de equipos, es en esta fase donde se recoge toda la información necesaria para la instalación ya que la captura de estado no se ejecuta.

·         Fase de instalación: En esta fase se instala el sistema operativo en el equipo de destino

·         Fase de post instalación: Se actualiza sysprep.inf, sysprep.xml o unattend.txt con la información recogida en las fases anteriores.

·         Fase de restauración de estado de usuario: En esta fase de hace una llamada a LoadState.exe para restaurar el perfil de usuario que previamente se ha capturado.

Pues bien, en TS.xml se identifican todas estas fases, junto con los pasos necesarios en cada una de ellas y según el escenario de implantación. Además se identifican las tareas necesarias para despliegues con SMS OSD Feature Pack.

Si volvemos a nuestro laboratorio, podemos encontrar el secuenciador de tareas en las propiedades del “Build” o paquete de despliegue que tenemos ya creado. Si seleccionamos la etiqueta Task Sequence observaremos cada una de las fases que hemos comentado.

Lo realmente interesante de todo esto es el grado de personalización que BDD 2007 ofrece, ya que, además de las tareas ya creadas, podemos insertar en cualquiera de las fases, nuestros propios scripts y pasos que sean necesarios para hacer que el sistema operativo final esté  totalmente adaptado y personalizado para nuestra organización.

Por ejemplo, supongamos que queremos incluir una tarea que copie los archivos de instalación de una aplicación de línea de negocio al disco local y que además inicie el proceso de instalación. Supongamos además que todo esto ya lo tenemos creado en un par de archivos llamados copiaLOB.bat e InicarSetup.bat.

Lo único que tendríamos que hacer es determinar el punto de inserción de la nueva tarea, e invocar los archivos .bat en el orden adecuado. Un punto de inserción lógico para este ejemplo sería dentro de la fase de post instalación y probablemente justo antes del reinicio del equipo. Nos situamos en la tarea inmediatamente superior y seleccionamos en el secuenciador de tareas Add > Group. Posteriormente vamos a agregar dos tareas, por lo tanto Add > Task dos veces. Ahora solo completamos los datos necesarios de las tareas y el grupo:

·         Nombre del Grupo: Copia e instalación de LOB

·         Nombre de tarea 1: Copia de archivos, Command Line: C:copiaLOB.bat

·         Nombre de tarea 2: Inicio de instalación, Command Line: C:InicarSetup.bat

Fijaros que debemos hacer referencia a la ubicación de los archivos .bat, los cuales deben estar previamente copiados y disponibles en la imagen .wim que acabamos de instalar. Para ello nada mejor que utilizar imageX para abrir, montar y copiar los .bat necesarios para esta tarea.

Todos los cambios se ven reflejados en el archivo TS.xml del build que estemos modificando, en nuestro caso VIS01, localizado en “C:DistributionControlVIS01TS.xml”.

Una alternativa a los .bat es utilizar scripts en formato .wsf, tal y como los utiliza BDD 2007 para secuenciar sus tareas. Para ello haremos una llamada a “cscript.exe %SCRIPTROOT%NombreDeScript.wsf”.

Una vez que hemos hecho todos los cambios necesarios, personalización de fases y tareas, copia de archivos en la imagen .wim y hemos verificado que el paquete de despliegue está correctamente creado, llega el momento de crear el punto de implantación o Deployment Point.

Para ello nos situamos en el nodo que lleva este nombre y con el botón derecho hacemos clic en New. Veremos el asistente de creación de punto de implantación, y observaremos cuatro opciones disponibles que os comento a continuación:

·         Lab or single-server deployment (LAB). Opción predeterminada que crea un punto de distribución (recurso compartido como distribution$). Con esta opción utilizamos el punto de distribución local como punto de implantación (Deployment Point).

·         Separate deployment share (Network). Esta opción crea un Nuevo punto de implantación (Deployment Point) como nuevo recurso compartido de red. Recomendado en escenarios en donde se utilizarán servidores de archivos en red desde los cuales se centralizará la implantación

·         Removable media (Media). Esta opción crea un recurso compartido en donde se crearán imágenes para realizar una implantación basada en CD, DVD, Discos Duros externos o dispositivos  USB. Ideal para escenarios en donde haya equipos desconectados o con limitaciones en la conexión que puedan afectar el proceso de instalación remota.

·         SMS 2003 Operating System Deployment (OSD) Feature Pack (OSD). Si seleccionamos esta opción crearemos un recurso compartido que posteriormente se utilizará en la creación de imágenes para SMS 2003 OSD Feature Pack. Específico para escenarios de implantación ZTI.

Según la opción que hayamos seleccionado, tendremos que dar respuesta a algunas preguntas que nos hará el asistente. Estas preguntas determinan el comportamiento inicial del proceso de instalación del Sistema Operativo y modifican el archivo CustomSettings.ini y Bootstrap.ini

En nuestro escenario, utilizaremos la segunda opción, es decir, Separate Deployment Share para que así podamos observar el recurso compartido que se crea y los archivos de configuración que hemos comentado anteriormente. Por lo tanto ejecutamos el asistente y vamos contestando cada una de las preguntas, con los siguientes valores:

·         Deployment Point name: NETWORK

·         Allow users to select additional applications on Upgrade: NO

·         Ask user to set the local Administrator Password: NO

·         Ask user for a product key: NO

·         Server name, Share Name, Path for share: dejamos los valores por defecto

·         Specify user data defaults: Do not save data and settings

Una vez que hemos creado el Deployment Point podemos acceder a sus propiedades haciendo doble clic en el contenedor correspondiente. Desde aquí podemos editar y configurar con un mayor nivel de detalle todas las opciones del punto de implantación.

Otro aspecto a tener en cuenta es que el recurso compartido no se crea realmente hasta que no llevamos a cabo una actualización de archivos, es decir, el punto de implantación no es funcional hasta que todos los archivos necesarios no se hayan copiado al recurso compartido. Para ejecutar esta tarea le haremos clic con el botón derecho al contenedor NETWORK que acabamos de crear y seleccionamos Update.

Bien, hemos llegado al final de este artículo, en la última entrega veremos cómo terminamos de configurar el punto de implantación y ejecutamos la instalación del sistema operativo.

Hasta entonces, saludos a todos.

Como prometí en un post de réplica hace unas semanas, vamos a iniciar una serie de entradas en el Blog, sobre las diferentes versiones que nos ofrece Microsoft para Windows Vista y sus características. Analizaremos que sistema nos puede resultar más interesante y cual se puede ajustar más a nuestras necesidades. Para ello además de este, se postearán 3 más dedicados uno a las versiones domésticas, uno a las versiones empresariales y uno la versión Ultimate y al contrato de licencia para las versiones de Windows Vista.

Desde hace ya algún tiempo, Microsoft ha ido generando versiones diferenciando sus características y realizando una marcada diferencia entre el mercado doméstico y el mercado empresarial, ofreciendo funcionalidades diferentes para cada sector, a la vez que se ajustaban los costes en base a estas funcionalidades. El problema se presentaba en que en muchas ocasiones se acababa pagando por funcionalidades que nunca se acababan utilizando o si disponía de una versión queríamos utilizar funcionalidades aportadas por otra versión. De cara a intentar llegar a todos los posibles mercados y aportar diferentes funcionalidades se han propuesto hasta 6 versiones diferentes de producto con sus elementos diferenciadores.

A estas alturas algunos se estarán preguntando porque tantas versiones y no una y que cada cual decida que tener… Llevémoslo a otro sector y hagamos una comparativa. Un buen día decido cambiar de coche y me acerco al concesionario x buscando precios para un coche que ha salido nuevo y del que me gustaría disfrutar. Bueno, pues resulta que cuando nos ponemos a hablar con el vendedor resulta que del modelo del coche elegido tenemos tropecientas versiones: que si con clima, AA, elevalunas, las llantas, la pintura, el navegador, velocidad de crucero, sensores de distancia y lluvía, ordenador de a bordo, etc. Nadie se sorprende, compramos uno base y le empezamos a añadir funciones hasta que nos cuadra sus prestaciones y sus precios, y nadie se asusta (o sí), claro lo que queremos es todos los accesorios con el precio más barato, pero ya sabemos que eso no nos lo da nadie.

De cara al nuevo Sistema Operativo Cliente de Microsoft, nos ofrecen las siguientes versiones: Starter Edition, Home Basic, Home Premium, Business Edition, Enterprise Edition y Ultimate Edition.

 En post posteriores analizaremos las diferentes versiones, en este veremos la versión de Starter Edition. Esta versión que ya tuvo su homónima en la versión de Windows XP, no llegará a España, debido a su función. El objetivo con esta versión es hacer llegar a países menos desarrollados a nivel informático un producto que les permita la iniciación a la informática, limitando algunas de sus funcionalidades originales para poder funcionar en máquinas con menores prestaciones. Se incorporará en equipos nuevos, de bajo coste, en formato OEM (Original Equipment Manufacture), a través de distribuidores Microsoft OEM.

Incorpora muchas de las funcionalidades de la versión Home Basic, incluidas aquellas correspondientes a los mecanismos de seguridad: Windows defender, control parental, mecanismos de seguridad de I.E. 7.0 y uso de cuentas estándar. También incorpora los elementos de conectividad con Internet y de dispositivos. No incorpora las funciones de Aero, ni la aportación visual que si acompaña otras versiones, al igual que todos aquellos elementos destinados a mecanismos de tipo empresarial.

Referencias Externas

 —————————————————————-

Descripción general de versiones

Windows Vista Starter

En este nuevo post abordaremos las posibilidades de configuración que presenta el control de cuentas de usuario con respecto a los administradores. Con respecto a esta configuración es conveniente empezar matizando el tratamiento que reciben los usuarios que pertenecen al grupo de administradores frente al super-usuario administrador.

El tratamiento especial que recibe la cuenta integrada del administrador consiste en liberar a dicho usuario del control, restricciones y en definitiva las protecciones que ofrece el control de cuentas de usuario al resto de cuentas.

Esto supone un riesgo para esta cuenta, pero la idea y recomendación por parte de Microsoft es dedicar su uso únicamente a aquellas tareas que el resto de administradores no pueden realizar. De todos modos podremos configurar el UAC para que proteja también al administrador.

Configuración de UAC para los administradores

Por un lado nos encontramos una directiva que configura el comportamiento sobre el usuario administrador. Esta directiva es la siguiente:

Modo de aprobación de administrador para la cuenta Administrador integrado

Las posibles configuraciones que nos ofrece esta directiva van a proporcionar los siguientes comportamientos al UAC:

·         Habilitada: indica al control de cuentas de usuario que el super-usuario administrador se comportará como el resto de usuarios de la máquina.

·         Deshabilitada (por defecto): el administrador queda excluido del control de cuentas de usuario. Carece de control de seguridad en todas sus acciones.

Mientras que para el conjunto total de los usuarios con privilegios administrativos, las configuraciones que permite realizar el control de cuentas de usuario dependen de la configuración de varias directivas.

·         “Ejecutar todos los usuarios, incluidos los administradores, como usuarios estándar”: Esta directiva configura el comportamiento del UAC con respecto a los administradores.

·         Deshabilitada: el control de cuentas de usuario dejará de proteger la ejecución del entorno de estos usuarios. ¡CUIDADO! Dejamos de distinguir la aplicaciones que ejecutamos nosotros de las que se ejecutan aprovechando vulnerabilidades del sistema.

·         Habilitada (por defecto): UAC protege a los administradores con el mismo interés y control que al resto de usuarios del equipo.

·         “Comportamiento del indicador de elevación para los administradores en Modo de aprobación de administrador” Esta configuración establece el comportamiento del indicador de elevación de privilegios para todos los administradores.

·         Pedir consentimiento (predeterminado): cada vez que se desee realizar una configuración se debe pedir el consentimiento del usuario. Solo dicha aplicación se ejecutará con los privilegios necesarios. ¡Es necesario leer el mensaje de elevación de permisos, no sea que nos ESTEN engañando!

·         Pedir credenciales: El administrador necesita insertar de nuevo sus credenciales para que la tarea pueda ejecutarse. ¿Se te olvida siempre bloquear la sesión cuando abandonas tu puesto?

·         No preguntar: no necesita el consentimiento del administrador. Se ejecuta sin más. ¡Muy peligroso!

Referencias

• Control de Cuentas de Usuarios (0): ¿Sistemas Seguros?


• Control de Cuentas de Usuarios (I)


• Control de Cuentas de Usuarios (II)


• Control de Cuentas de Usuarios (III)

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.

Para preparar el laboratorio podéis leer los  artículos anteriores “Despliegue masivo de Windows Vista con BDD 2007 (I de V)”  y  “Despliegue masivo de Windows Vista con BDD 2007 (II de V)”

En esta tercera entrega de esta serie destinada al despliegue de Windows Vista abordaremos la personalización del «Build» o paquete de despliegue que dejamos creado en el artículo anterior.

Recordemos que el “build” será el producto final que utilizaremos para realizar el despliegue, por lo tanto debe  estar lo más ajustado a las necesidades de la organización como podamos. Desde configuraciones de escritorio, Internet Explorer, Red, Firewall, hasta la instalación de aplicaciones de línea de negocios (LOB), actualizaciones, controladores, etc.

Por lo tanto, estas tareas de personalización las haremos con dos herramientas fundamentalmente: Windows SIM (Windows System Image Manager) e ImageX. Ambas herramientas son componentes de Windows AIK.

Si abrimos las propiedades del “Build” que ya tenemos creado, en la etiqueta settings, observaremos que podemos, desde aquí comenzar a modificar algunos parámetros como el nombre de la organización, contraseña de la cuenta Administrador (creada siempre en Windows Vista pero deshabilitada por defecto), página de inicio de Internet Explorer  y el número de licencia (CD Key) de la edición de Windows Vista que hemos adquirido.

En realidad todos estos parámetros, junto con muchos otros, forman parte del un fichero de instalación desatendida que se llama unattend.xml, el cual sustituye a los diferentes formatos que debíamos de gestionar en versiones anteriores cuando diseñábamos despliegues de Windows XP con RIS (sysprep.inf y unattend.txt). Con el botón “Edit Unattend.xml” abrimos la herramienta Windows SIM y podemos editar todos los detalles de respuestas que se pasarán en cada una de las tareas durante el proceso de instalación de la imagen del Sistema Operativo.

Para aquellos acostumbrados a desarrollar aplicaciones con Visual Studio, verán que el entorno es bastante familiar, ya que cada uno de los componentes o paquetes que forman parte del archivo de respuesta unattend.xml, son en realidad objetos con propiedades que podemos editar. Básicamente el entorno de trabajo se divide en cinco áreas:

1.       Distribution Share: Panel de exploración del recurso compartido de distribución, con los elementos y componentes que se han incluido en pasos anteriores como paquetes (actualizaciones de sistema) y controladores “out-of-box”

2.       Imagen Windows: Panel en donde podemos visualizar los paquetes que ya están actualmente incluidos en la imagen WIM, como paquetes de lenguaje, funcionalidades, características y el núcleo del sistema. Estos paquetes se pueden agregar al archivo de respuesta para personalizar la instalación y realizarla sin intervención del usuario

3.       Archivo de respuesta (Answer File): En esta sección veremos los paquetes que ya están incluidos en unattend.xml. Podremos editar sus propiedades, para realizar finalmente el despliegue desatendido que queremos lograr

4.       Propiedades: Cada vez que seleccionemos un paquete del archivo de respuesta o de la imagen de Windows, veremos sus propiedades y las podremos modificar para ajustarlas a los requisitos de la organización.

5.       Mensajes: Al utilizar las herramientas del menú Tools, obtendremos las respuestas de la acción realizada en este panel de mensajes.

Por ejemplo, supongamos que queremos configurar las particiones que tendrá el disco de los equipos en donde instalaremos Windows Vista. Pues bien, para ello debemos agregar al archivo de respuesta unattend.xml el componente necesario y configurar las propiedades. Uno de los aspectos más interesantes de Windows SIM es su nivel de detalle en cada una de las tareas. Para realizar esta configuración seleccionaríamos de la lista de componentes en el panel de imagen Windows, el objeto:

·         x86_Microsoft-Windows-Setup_6.0.6000.16386_neutralDiskConfiguration

Con el botón derecho lo agregamos al archivo de respuesta.

Una vez integrado, podemos crear nuevos discos y nuevas particiones para cada disco. Siempre con el botón derecho, pero esta vez directamente en el archivo de respuesta, seleccionamos:

·         Disk Configuration > Insert new disk.

·         Disk / CreatePartitions > Insert new CreatePartitions

·         Disk / ModifyPartitions > Insert new ModifyPartitions

Cuando ya tenemos el disco creado y las particiones que necesitamos, debemos configurar las propiedades de cada disco y partición, por ejemplo:

·         Disk:  DiskID = 0, WillWipeDisk = true

·         DiskCreatePartitionsCreatePartition: Extend – false, Order = 1, Size = 25000, Type = Primary

·         DiskModifyPartitionsModifyPartition:  Active = true, Extend = false, Format = NTFS, Label = WindowsSystem, Letter = C, Order = 1, PartitionID = 1

Ahora debemos asegurarnos que el sistema se instalará en la partición que se ha creado para tal fin. Para ello abrimos las propiedades del objeto ImageInstallOSImageInstallTo. Este objeto se agrega automáticamente cuando se crea el archivo de respuesta, pero debemos comprobar que DiskID y PartitionID tengan los valores correctos. En nuestro ejemplo DiskID debe tener un valor 0 (Disco 0) y PartitionID un valor 1 (Partición 1).

Otros aspectos que se pueden configurar automáticamente son:

·         x86_Microsoft-Windows-Setup_6.0.6000.16386_neutralUserData

o   Aceptación de EULA

o   Nombre completo

o   Organización

·         x86_Microsoft-Windows-Setup_6.0.6000.16386_neutralUserDataProductKey

o   Licencia de producto (CD Key)

·         x86_Microsoft-Windows-Setup_6.0.6000.16386_neutralDisplay

o   Profundidad de colores

o   Resolución horizontal

o   Resolución vertical

o   Refrescamiento

·         x86_Microsoft-Windows-UnattededJoin_6.0.6000.16386_neutral

o   Dominio o grupo de trabajo al que unir el equipo

o   OU para el equipo

o   Contraseña de equipo

o   Credenciales de cuenta con permisos para agregar equipos al dominio

·         x86_Microsoft-Windows-TCPIP_6.0.6000.16386_neutral

o   Configuración de interfaces de red

o   Configuración IPv4 e IPv6

o   Puertas de enlace

·         x86_Microsoft-Windows-Sidebar_6.0.6000.16386_neutral

o   Gadgets presentados y configuración de Sidebar

Como podéis observar, son muchos los componentes que se pueden configurar de forma desatendida. Por lo tanto, si queréis profundizar en la arquitectura y componentes de Windows SIM, podéis visitar http://technet2.microsoft.com/WindowsVista/en/library/f3b1573b-4915-4532-933a-57ee2bcddf921033.mspx?mfr=true

Una vez finalizada la tarea de personalización de unattend.xml, el siguiente paso es guardar toda la configuración (File > Save Answer File). Por defecto se guarda en C:DistributionControl<Nombre del Build>unattend.xml. Si lo editamos con el Bloc de notas, comprobamos que efectivamente, toda la configuración que hemos ido agregando con Windows SIM está guardada en la estructura XML.

Otra herramienta que podemos utilizar para capturar y modificar imágenes WIM es imageX. El propósito de imageX es completamente diferente del de Windows SIM. Mientras que Windows SIM nos permite editar imágenes WIM y crear, a partir de los componentes incluidos, un archivo de instalación desatendida, imageX la vamos a utilizar en pasos inmediatamente anteriores o posteriores a la creación de unattend.xml.

Utilizaremos imageX para capturar una imagen a partir de un equipo de referencia. En nuestro caso, hemos iniciamos esta serie de artículos con la imagen en DVD de Windows Vista, por lo tanto no hemos tenido la necesidad de capturar una imagen previa. Sin embargo, si podemos tener la necesidad de que, una vez creado todo el entorno de despliegue, queramos modificar la imagen final WIM. Por ejemplo, actualizar unas librerías de unos controladores, o agregar una serie de archivos que utilizarán nuestros usuarios o aplicaciones en la organización.

Para ello, no es necesario volver a repetir todos los pasos y crear nuevas imágenes cada vez que realizamos cambios. Basta con montar la imagen actual e incorporar o actualizar los archivos necesarios. Fijaros que el montaje se realiza a partir de una carpeta previamente creada, y podremos navegar por toda la estructura de carpetas de la imagen .wim como si de un árbol de carpetas locales se tratara.

La herramienta la podéis encontrar en C:Program FilesWindows AIKToolsx86, es realmente sencilla de utilizar. Los modificadores que admite son los siguientes:

·         Append – Agrega un nuevo volumen de imagen a un fichero .wim existente

·         Apply – Aplica un volumen de imagen a la unidad especificada

·         Capture – Captura un volumen de imagen en un nuevo fichero .wim

·         Delete – Elimina una imagen de un fichero .wim con múltiples imágenes

·         Dir – Muestra una lista de archivos y carpetas en un volumen de imagen

·         Export – Transfiere una imagen de un fichero .wim a otro fichero .wim

·         Info – muestra las descripciones XML del fichero .wim

·         Split – Separa un fichero .wim existente en múltiples partes wim de solo lectura

·         Mount – Monta una imagen con acceso de solo lectura en la carpeta especificada

·         MountRW – Monta una imagen con acceso de lectura y escritura en la carpeta especificada

·         Unmount – Desmonta la imagen montada en la carpeta especificada

·         Compress – Establece el nivel de compresión a ninguno, rápido o máximo

·         Commit – Aplica los cambios realizados a una imagen .wim montada

Aquí van algunos ejemplos del uso que podemos darle a imageX

·         Si queremos crear una imagen a partir de un equipo de referencia debemos ejecutar el comando

o   imageX /capture /compress maximun C:  E:ImagenesmiWindowsVista.wim “Imagen de mi Windows Vista”

·         Si queremos aplicar esta imagen a un disco nuevo ejecutaremos

o   imageX /apply E:ImagenesmiWindowsVista.wim 1 D:

·         Opcionalmente se puede crear un fichero de configuración en donde se incluirán las exclusiones que se tendrán en cuenta durante el proceso de captura de la imagen. Dicho fichero debe tener extensión .ini y puede ser algo como esto:

En nuestro laboratorio, vamos a ver cómo podemos montar y modificar la imagen a partir de la cual estamos realizando todo el proceso de despliegue. Recordemos que la imagen .wim que estamos utilizando proviene del DVD de Windows Vista, por lo tanto si queremos agregar algún archivo o carpeta a dicha imagen, debemos montarla en modo lectura y escritura, hacer los cambios necesarios y posteriormente aplicar los cambios.

La imagen está en C:DistributionOperating SystemsWindows Vistasourcesinstall.wim

Para montarla vamos a crear una carpeta que será nuestro punto de montaje, por ejemplo C:ImagenVista. Para montar la imagen debemos saber qué imagen montar, recordemos que en un único fichero .wim podemos almacenar múltiples imágenes. En nuestro laboratorio tenemos en install.wim todas las ediciones de Windows Vista, por lo que si queremos saber en qué orden están guardadas, podemos hacerlo con:

·         imagex /info «C:distributionoperating systemswindows vistasourcesinstall.wim»

Observaremos que la información proporcionada está en formato XML. Debemos localizar la etiqueta <IMAGE_INDEX> Y <NAME> para saber el índice de la imagen que buscamos.

Según nuestro fichero .wim, la edición Ultimate está en la posición 4, por lo tanto montaremos esta imagen:

·         imagex /mountRW «C:distributionoperating systemsWindows Vistasourcesinstall.wim» 4 C:ImagenVista

Ahora podemos ver el contenido de la imagen en C:ImagenVista y navegar por la estructura de directorios. Podremos crear carpetas, agregar ficheros o modificar contenido. Por ejemplo, si queremos agregar o actualizar los controladores disponibles en nuestra imagen para la posterior instalación de dispositivos, entonces basta con agregarlos a WindowsSystem32DriverStore.

Una vez realizados los cambios debemos aplicarlos con la siguiente instrucción:

·         imageX /unmount /commit C:ImagenVista

Bien, hemos visto cómo podemos crear, editar y aplicar imágenes .wim con las herramientas Windows SIM e ImageX. En la siguiente entrega de esta serie comenzaremos las tareas de preparación del despliegue y las pruebas con un cliente que sin tener un Sistema Operativo instalado, deberemos iniciar ya sea con un CD de arranque de Windows PE o mediante PXE.

En este último post sobre bitlocker, vamos a definir como se realiza la implementación en Windows Vista. Antes de realizar la implementación, necesitamos haber definido inicialmente una estructura de disco consecuente para la implantación de Bitlocker.

            Inicialmente necesitamos para habilitar bitlocker 2 particiones formateadas en NTFS. Una de las particiones, la activa, es el volumen de sistema, que contendrá todo el sistema de arranque y no se cifrará, esta partición no cifrada además de mantener todo el arranque, nos permitirá cargar el boot loader y arrancan otro sistema operativo que pudiera estar coexistiendo en nuestra máquina y en otra partición diferente de aquella que vamos a cifrar. La otra partición, almacenará el sistema operativo y es aquella que podemos cifrar. Únicamente mediante bitlocker se puede cifrar esta partición.

            Una vez que tenemos definido y creado nuestro sistema de almacenamiento siguiendo estas características, procederemos a habilitarlo. En el caso de que no poseamos el chip TPM, siempre podremos optar por utilizar un Stick USB para el almacenamiento de las claves.  Para utilizar esta metodología deberíamos habilitar la directiva correspondiente tal y como definimos en post anteriores.

            Posteriormente a la definición del método para el almacenamiento de las claves, el sistema nos presenta la posibilidad de guardar una password de recuperación. El almacenamiento de la misma se puede realizar en un dispositivo USB, en una carpeta o bien imprimirse. Esta clave debiera quedar bien resguardada, tanto por motivos de seguridad, como por motivos de administración, puesto que nos permitirá recuperar el disco cifrado, en caso de contratiempos, aunque nos lleváramos el disco duro a otra máquina diferente del que hallamos implementado el cifrado del disco. Esta password de recuperación es única para cada sistema donde hayamos implementada por bitlocker.

            Finalizaremos la aplicación de Bitlocker, reiniciando la máquina. Se realiza un pre-arranque donde se comprueban las condiciones para su implementación y la compatibilidad. Si supera este proceso, se procederá a la implementación del cifrado. Una vez completado en el siguiente proceso de arranque, en función del escenario de implementación que hayamos utilizado, bien por PIN o USB, nos lo solicitará para proceder con el proceso de carga del sistema operativo.

            Uno de los mecanismos que tenemos que tener siempre presente es el de la recuperación en caso de una contingencia. Para ello deberemos disponer de la clave de recuperación bien que se encuentre en un dispositivo USB, o lo hubiéramos impreso. Durante el arranque si el sistema está bloqueado nos pedirá la clave de recuperación. Inicialmente nos solicitará la llave USB o bien introducir manualmente la clave que tuviéramos en papel. Este mismo mecanismo deberemos implementar en el caso de que el hardware haya provocado fallos y tuviéramos que llevarnos el disco a otra máquina.

Referencias Externas

 —————————————————————-

– Bitlocker III: Escenarios de bitlocker.

– Guia para la implementación de bitlocker.

– Extensión del esquema para la implementación de claves de recuperación en Directorio Activo.

En esta nueva serie de POST iremos tratando las mejoras en Windows Vista relacionadas con las políticas de grupo. En el presente post trataremos sobre el soporte de Windows Vista de  varias políticas de grupo locales (LGPO).

Un repaso general:

Las políticas de grupo o GPO son una de las características más interesantes del directorio activo y de personalización del comportamiento de nuestro equipo o de los equipos de una red. Gracias a las GPO podemos controlar desde qué herramientas están disponibles para los usuarios hasta que permisos NTFS deseamos establecer en nuestras unidades, es decir podemos modificar aspectos como el comportamiento de protocolos, auditorias del sistema, difusión de certificados, restricciones de contraseñas, restricciones de usuario, comportamiento de componentes del sistema y un largo etc. tanto a nivel local como a nivel de dominio, siguiendo la regla de prioridad LSDOU (del ingles Local, Site, Domain, Organizational Unit). En el fondo la mayoría de las configuraciones de una GPO son cambios en el registro de Windows del equipo final, el cual, según sea el caso, va a permitir o restringir ciertas acciones. Todo esto es configurable, con las explicaciones oportunas, a través del MMC (Microsoft Management Console) de edición de políticas de grupo (gpedit.msc).

LGPO en Windows Vista:

Windows Vista trae consigo una serie de mejoras relativas al funcionamiento y uso de las políticas de grupo que iremos desgranando en sucesivos post, hoy partiremos de la posibilidad de usar varias políticas locales permitiendo así una personalización de estas por usuario o según se pertenezca o no al grupo administradores.

En Windows XP cuando creábamos alguna LGPO esta se aplicaba al equipo y a todos los usuarios, algo que no siempre es lo más optimo según las configuraciones que deseemos realizar, es por ello que por Internet podemos encontrar formas de hacer que las políticas configuradas no afecten a los administradores como se puede comprobar en el siguiente artículo de Microsoft.

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

En Windows Vista ya tenemos implementada la posibilidad de realizar una gestión de políticas diferenciada, para ello debemos seguir el siguiente proceso:

Ejecutar MMC > Archivo > Agregar o quitar complementos > Editor de objetos de directiva de grupo

Nota: No confundir «editor de objetos de directiva de grupo» con el complemento de «administración de directivas de grupo» también conocido como GPMC y que ya viene integrado como parte de Windows Vista para la administración de GPOs en un dominio.

Al pulsar sobre el botón «agregar» para agregar el complemento y antes de seleccionar cualquier otra opción debemos hacer clic sobre el botón «Examinar» donde además de la posibilidad de aplicar la LGPO a otro equipo distinto desde la pestaña «equipos» nos aparecerá una nueva pestaña llamada «usuarios» donde podremos seleccionar entre las cuentas de usuario existentes o entre los grupos «administradores» para aplicar políticas propias a usuario con privilegios administrativos y «no administradores» para la creación de políticas que afecten al resto de los usuarios; finalmente solo tenemos que pulsar en aceptar para empezar a editar las políticas de usuario correspondientes (obviamente esto no afecta a las políticas de equipo que se aplican a todos por igual).

Alguno ya habrá caído en la cuenta de que mediante este método existe la posibilidad de existencia de conflictos entre políticas, por ejemplo tendríamos un conflicto al aplicar una política concreta sobre un usuario corriente llamado Pablo y esa misma política pero con una configuración diferente aplicada a todos los usuarios no administradores. Para resolver este tipo de situaciones y partiendo de que quien edita las políticas locales en conflicto es normalmente la misma persona, podemos concluir que normalmente la configuración deseada es la ultima modificación realizada; partiendo de esto, Windows Vista aplica aquella configuración que haya sido editada la última.

¿A quien le apetece restringir las funciones del Panel de Control de sus usuarios o modificar el comportamiento de Internet Explorer sin afectar a algún usuario específico? Con Windows Vista ya podeis hacerlo.

En el próximo POST trataremos sobre el cambio en el formato de las plantillas administrativas y su independencia del idioma.