Sebastian del Rio: Varios

Denegar ejecucion de Software

Tue, 19 Jun 2007 16:13:06 GMT

If you missed the first part in this article series please go to Default Deny All Applications (Part 1).

Introduction

Since Windows XP, administrators around the world have had the option to define Software Restriction Policies (SRP) for their client computers to control what software is allowed, or not allowed, to run. So far too few organizations have implemented this functionality despite the fact that it could actually bring a very high level of security, depending on how it is enforced. In this second article about SRP we will look at how to implement what we could also refer to as “software filter policies”.

Danger zone

Before we get too far it is important to point out that, prior to introducing SRP on production computers, you should plan and test them thoroughly. This can be done in Active Directory (AD) by isolating a single test machine or user object in an Organizational Unit (OU) or by setting “Apply Group Policy” permission on the Group Policy Object (GPO) to only that single test-machine or -user account. SRP can even be used on Stand-alone computers if you don’t want to touch the production environment at all. I would recommend you use virtual machines for basic testing and ‘production-like’ machines for the final tests. After heavy testing, the SRP should be implemented on pilot users in groups – it’s better to take small steps than hurrying into disaster!

The overall process

Mistakes in the design or implementation of this can cause considerable user frustration, and even loss of money or productivity, so watch out as you go along. This takes a lot of planning work, testing and probably some maintenance from the day it is introduced in the production environment. From that point on you will be able to sleep tight at night…

The following list gives a quick view of what to have in mind when introducing SRP in a Windows environment.

When designing the SRP setup, different decisions must be made, for example:

Decide between user and computer GPOs: what AD objects should the SRP policies apply to?
Decide between a Blacklisting (BL) and a Whitelisting (WL) approach (WL is recommended if possible)
If using the BL approach, a list of everything that should not run must be made
If using the WL approach, a list of everything that should run must be made
Decide what SRP options to use (enforcement, designated file types, administrator exceptions etc.)
Decide what type of rules to use (path, HASH, certificate or Internet zone)

When testing the SRP setup, different steps must be taken, for example:

Test the basic functionality in a virtual lab (using Virtual PC/Server, VMware or similar)
Test the functionality in your environment by using ‘production-like’ machines (and user accounts)
Test with small groups of pilot users in steps of 5-10 users over a few weeks, then scale up
Continue to the next pilot group only after successful implementation for the previous pilot users
Be sure to test all the different user types and machine types you need to secure with SRP
Be sure to test upgrade scenarios, like patching of the operating system, upgrading third party applications, migrations etc.
Also focus on performance on the different hardware in your organization. Implementing SRP will in most cases affect system performance a bit, depending on how it is implemented (see the part about Trusted Publishers)
Sometimes applications launch other applications, make sure this is under full control
By default Desktop and Start Menu shortcuts (.LNK) are blocked, make sure to modify this as needed
Be sure that any admin scripts (e.g. login scripts in SYSVOL/NETLOGON shares etc.) are able to run

Before introducing SRP in production, some procedures should be in place:

Introduce a written workflow on how applications, updates etc. should be tested, approved and introduced on the network, so everybody is aware of the procedures required
Be sure that management knows SRP pros and cons and that they agree on the decision to introduce it
Have a fallback plan on how to get rid of the SRP GPOs fast, for certain users, groups, computers, sites etc.
User education: inform users why SRP is important and what the procedure is to acquire new software
A small tip: Put descriptions on SRP rules, over time a good naming convention will save you some time

Different paths to SRP

Configuring a Software Restriction Policy is basically only a few steps:

Creating a User or a Computer GPO and placing it on a Site, Domain or OU (or as a local policy) and enabling SRP within the Group Policy. The SRP settings are located here (see Figure 1):

Computer Configuration| Windows Settings | Security Settings | Software Restriction Policies
User Configuration | Windows Settings | Security Settings | Software Restriction Policies

The first time SRP is introduced in a GPO, the option “New Software Restriction Policies” will be available.

Figure 1

Setting the Default Security Level. Figure 2 shows how the level is set by right-clicking the wanted level and choosing “Set as default”.
- The default level is ‘Unrestricted’ which means that all software can run and that additional rules for disallowed software should be made – this is also known as Blacklisting.
- The most secure level is ‘Disallowed’ which means that no software can run and that additional rules for allowed software should be made – this is also known as Whitelisting.
- By default the system creates a few rules that allow the operating system to run without any inconvenient blocking
  NB! If those rules are removed or changed without any thought, the affected system(s) could become unusable.

Figure 2

With Windows Vista and Longhorn we have a new level called ‘Basic User’ which allows programs to execute as a user that does not have Administrator access rights, so the user can access resources accessible by normal users only. This level is not addressed any further in this article.

File types can be removed and added to fit any environment, but the default file type list includes the most common executables: BAT, CMD, COM, EXE, HTA, LNK, MSI, OCX, PIF, REG & SCR and in addition these extensions: ADE, ADP, BAS, CHM, CPL, CRT, HLP, INF, INS, ISP, MDB, MDE, MSC, MSP, MST, PCD, SHS, URL, VB & WSC.
Note: As the Designated Files Type Properties dialog states, the list is “in addition to the standard program file types, such as EXE, DLL and VBS” – I haven’t been able to get a complete list of those, but I have confirmed that VBS, VBE, JS and JSE are blocked even though they are not in the list. I would have preferred a single list administrators around the world could change as needed, but that’s how it is.

Figure 3

Setting up exceptions to the Default Security Level. These are known as ‘Additional Rules’. Please see the subject “Additional Rules” in this article for further information.
Configuring ‘Enforcement Properties’. See Figure 4, this includes:
- “All software files”: We have the option to check DLL’s (Dynamic Link Libraries) when they are executed too. This is not a default setting and will have some impact on both performance and planning/implementation/maintenance tasks.
- “All users except local administrators”: Here we can choose whether or not SRP should apply for Local administrators. By default all users are hit by SRP. This policy option is only relevant for computer policies.
- “Enforce certificate rules”: Option to choose whether or not to use certificate rules should be applied. Note: As stated in the dialog in Figure 4 “Certificate rules will negatively impact the performance of your machine”.

Figure 4

Configuring ‘Trusted Publishers Properties’, also known as Authenticode policy options (see Figure 5). In this dialog we can choose who should be able to select Trusted Publishers for certificate rules. We also have an option to verify whether a certificate is revoked or not, and/or to check if the timestamp is valid when it is added.

Figure 5

Additional Rules

When configuring Additional Rules, a method - or a couple of methods - on how to indentify software should be decided. We have 4 different software identification methods available:

HASH rules

HASH’es are cryptographic fingerprints that remain regardless of the file name and location. These are especially good when using WL, but not that effective when BL (the reason for this is partly described by the ProduKey example in my first SRP article): An MD5 or SHA-1 HASH gives strong software identification of the ‘ProduKey.exe’ binary file, so allowing a specific HASH value to run makes sure that only that version of the executable can run. However, disallowing a specific HASH only affects one version (or compilation) of the application and a smart user can change the file pretty easily so it is identified as another (unknown) piece of software. The word ‘unknown’ is very important in this matter – it’s really the key to decide between BL or WL – do we want users to be able to execute software we don’t know, yes or no?

If users should not be able to run an old version of a specific application, let’s say it’s ‘buggy’ and causing system crashes, using a ‘deny this HASH value’-rule would be a good decision. Please keep in mind that a new version of a given application will always result in a new HASH value that must be allowed – or disallowed.
Certificate rules

Certificate rules uses signed hashes and provides very strong software identification, but as we trust a given certificate we actually trust all software signed with that specific certificate. This could be a good thing or a bad thing. It’s a good thing if we, for instance, get an application from a third party vendor who signed all the significant files in the application (maybe including DLLs), so instead of making a given number of HASH rules we can just create a single rule that trusts the certificate and we are up and running. But, let’s say I trust a digital certificate used to sign some tool from Microsoft (or any other software vendor) – now my users are able to run all applications signed by that specific certificate… Hmm, so the problem is to know exactly what applications were signed by that certificate? Without that knowledge we don’t know what we have allowed. Instead of allowing just the single application we needed for our users, we might have allowed hundreds of applications from the vendor to run on our systems.

Testing of Certificate rules can be done by using these tools: File Signing Tool (Signcode.exe) & Certificate Creation Tool (Makecert.exe).
Path rules

Path rules are the most common and “easy-to-use” rules we have. Path rules can deny or allow a file on a specified location (e.g. “C:\Scripts\Script.VBS”), a filename (e.g. “Script.VBS”), a folder (e.g. “C:\Scripts”), a UNC path (e.g.”\\SERVER\SHARE\File.VBS”) or a registry path (e.g. “%[Registry Hive]\[Registry Key Name]\[Value Name]%”). Path rules can use environment variables (e.g. “%WINDIR%”) and the wildcards ‘?’ = one char (e.g. “\\SERVER??\Share\Script.VBS”) and ‘*’ = any number of chars (e.g. “*.VBS”).

If you are using path rules a few things need to be addressed:
- If a given folder path is set, this also effects all executables in all subfolders
- If a user has write access to a folder that is set to Unrestricted, the user can copy any file to that directory and execute it from there. The design should take care of this issue, perhaps by introducing ACL (Access Control List) settings by the use of Group Policies
- If the user has write access to an executable that is specified as Unrestricted, the user could overwrite that executable with another one to circumvent the SRP
- If a folder path includes environment variables, like %TEMP%, even a limited user could change the user environment variables by using the SET command to another path (SET TEMP=C:\MyFolder) – and suddenly the user can control what software can be run by copying executables or scripts to that path.
As stated above, users may try to rename or move disallowed files – or overwrite unrestricted files to circumvent the SRP – this is why HASH or Certificate rules are normally considered ‘best choice’.
Internet Zone

Internet Explorer security zones can be used to control software installation and applies to only Windows Installer packages (.MSI) that are run from one of the default Internet zones. These rules are not that common to use.

When multiple rules are used they are evaluated in the order mentioned above, the default rule will be evaluated as the last rule – the most specific match will take precedence.

SRP Limitations

Some limitations of SRP must be taken into consideration. The scope of Software Restriction Policies is not the entire operating system as you might expect. SRP do not apply to the following code:

Drivers or other kernel mode software installed
Any program executed by the local SYSTEM account
Macros inside of Microsoft Office documents (we have other ways to block those by using group policies)
Programs written for the common language runtime (these programs use the Code Access Security Policy)

Conclusion

Software Restriction Policies demands a special, and time consuming, workflow when introducing new software and updates in the environment, but besides from that it brings a level of security so much higher than with the “default allow all” setup. Some environments might not be suited for SRP, but my guess is that most networks have computers and/or users for which the SRP technology is ‘spot on’.

It takes dedication, understanding and hard work to implement a “Default Deny” policy – which might be why it is seldom done… One thing is certain, implementing such policies in the correct way will make sure the network administrators can sleep much better at night.

Over the next couple of years it will be interesting to see if Microsoft will continue to develop this part of the Group Policy environment - or if something even better arrives, who knows…

External links

KB 324036 How To Use Software Restriction Policies in Windows Server 2003

Technet: Using Software Restriction Policies to Protect Against Unauthorized Software (Vista/Longhorn)

Technet: Software Restriction Policy for Windows XP Clients

If you missed the first part in this article series please go to Default Deny All Applications (Part 1).

Crear archivos ejecutables , a partir de un script.

Thu, 05 Apr 2007 12:12:52 GMT

Les dejo una utilidad excelente en el caso de que necesitemos encapsular ciertos script, por ejemplo si tenemos codigo que no queremos que otro vea , como ser un password en texto plano.

Se trata de una utilidad de Windows vista / Windows XP iexpress.

En la siguiente URL encontraran informacion al respecto.
http://www.petri.co.il/create_executable_with_iexpress.htm

Agregar informacion al registro - Muy interesante.

Wed, 04 Apr 2007 14:35:22 GMT

RegPol

Description

This command line utility enables you to import .REG files even if the Group Policy is set to restrict the registry editing tools.

If you use this policy setting, just use regpol.zip to import .REG files instead of the traditional 'Regedit –s' and 'Reg import'.

Requirements: Windows 2000/XP/2003

Current version: 1.2.8

Version highlights: Minor fixes

"Windows Registry Editor Version 5.00" error
“Subscript out of range" error

Download

Download regpol.zip (11kb)

Adrestore.exe de Sysinternals

Wed, 07 Mar 2007 15:25:13 GMT

AdRestore v1.1

Server 2003 introduces the ability to restore deleted ("tombstoned")
objects. This simple command-line utility enumerates the deleted objects in
a domain and gives you the option of restoring each one. Source code, is
based on sample code in the Microsoft Platform SDK. This MS KB article
describes the use of Adrestore:

840001: How to restore deleted user accounts and their group memberships in
Active Directory

http://www.microsoft.com/technet/sysinternals/Networking/AdRestore.mspx

Escritorio Remoto - Multiusuario

Tue, 14 Nov 2006 13:04:52 GMT

http://www.golod.com/2005/10/enabling-multiple-remote-desktop-sessions-in-windows-xp-professional-and-media-center-edition-2005/

Cómo impedir la ejecución de software en nuestro equipo

Sun, 12 Nov 2006 00:17:56 GMT

Cómo impedir la ejecución de software en nuestro equipo

El presente artículo es parte de una serie que voy a estar publicando los proximos dias y cuya finalidad es el de dar información de utilidad para el mejor uso del Windows Xp. No hace referencia a ninguna acción dolosa e ilicita, ni a cracks, seriales, parches, keygens o similares. Son artículos completamente tecnicos tomados de los años de participacíon en los newsgroups de microsoft

El editor de políticas de Windows es una herramienta que nos permite habilitar o deshabilitar determinadas características de nuestro Sistema Operativo y que tiene políticas precisas que permiten gestionar a nivel local las diversas funcionalidades de nuestro Windows XP. En este artículo veremos cuáles son las políticas que nos permiten restringir la ejecución de software de terceros, y también nos acercaremos al Editor de Políticas de Seguridad Local, que nos permite restringir la ejecución de programas mediante la implementación de políticas de hash.

Método 1. El editor de políticas
El editor de políticas, presente en la versión Prof de Windows XP y que podemos iniciar tecleando desde inicio/ejecutar, la palabra gpedit.msc, contempla la posibilidad de restringir la ejecución de software mediante la política No ejecutar aplicaciones de Windows especificadas, ubicada en la rama Directiva de equipo local / Configuración de usuario / Plantillas administrativas / Sistema

Al hacer doble click sobre ella accederemos al cuadro de configuración de está política, cuya gestión es bastante simple e intuitiva (véase figura 1). Basta con habilitarla seleccionando la opción correspondiente y presionar el botón Mostrar, el cual nos presentará un nuevo cuadro de dialago en el que tan sólo nos bastará teclear el nombre del comando cuya ejecución deseamos restringir para presionar a continuación el botón agregar.

Esta misma tarea puede ser llevada a cabo mediante el editor del registro (regedit) en Windows XP Home. Para ello, desde inicio /ejecutar, tecleamos regedit, y navegamos hasta la rama

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\

Una vez situados en la rama correspondiente desde el menú edición /nuevo creamos una nueva carpeta llamada DisallowRun.

Para gestionar desde aquí las directivas de restricción de software, deberemos crear un valor alfanumérico REG_SZ¸ desde el menú edición/nuevo. A este nuevo valor le pondremos de nombre un número correlativo, es decir, en nuestro caso, como acabamos de crear la rama aparecerá vacía, por lo que el nombre de la clave a crear para nuestro primer ejecutable a restringir será el 1, al siguiente le correspondería el 2 y así sucesivamente. Sólo nos basta hacer doble click sobre la clave recién creada y agregar el nombre del ejecutable del programa que no queramos que nuestros usuarios puedan utilizar. Una vez finalizado nuestro trabajo, veremos algo parecido a lo que presentamos en la figura 2

MÉTODO 2. Restricción mediante políticas de seguridad local y HASH de archivo (sólo WinXP Prof).
Con la anterior restricción no impediremos que nuestros usuarios puedan ejecutar los programas si se les ocurre cambiar el nombre del ejecutable que los lanza. Es decir que si tenemos algún listillo en nuestra máquina es posible que nuestras precauciones no nos sirván para nada. Y, ¿qué hacemos en este caso? Pues sencillo: crear un regla de restricción de software mediante hash. Este método nos asegura mediante un algoritmo matemático que no se ejecutarán los archivos indicados, ya que no guarda memoria del nombre del ejecutable sino de un hash generado a partir del mismo y que varia ante cualquier modificación del archivo. Esto nos asegura que se impedirá la ejecución de ese archivo aunque le modifiquemos el nombre o lo cambiemos de carpeta.

Para implantar esta forma de restricción de software tendremos que ir a Panel de Control /Herramientas administrativas / Editor de Políticas de Seguridad Local, y navegar hasta Configuración de seguridad / Directivas de restricción de software, una vez situado sobre esa rama en concreto hacemos click con el botón derecho del ratón, en la opción Reglas adicionales y, a continuación elegimos Regla de nuevo hash. Se nos crearán dos nuevas carpetas y nos quedará algo parecido a lo que presentamos en la figura 3,

Para implantar nuestra política debemos hacer clic con el botón derecho del ratón sobre reglas adicionales y elegir Regla de nuevo hash, sólo nos resta elegir el nombre del archivo cuya ejecución queremos impedir y hacer clic en aceptar. A partir de aquí “configuración de seguridad local” calculará el valor de Hash para ese archivo en concreto y nos impedirá su ejecución, aún variándolo de nombre o de carpeta. En nuestro ejemplo, hemos impedido la ejecución de Windows Media Player en el sistema.

La verdad es que esta herramienta tiene múltiples posibilidades, ya que con gpedit, todas las políticas se aplican por defecto a todos los usuarios, pero con la Directivas de Seguridad Local, es posible especificar a que grupos de usuarios queremos impedir la ejecución de programas. Veámoslo con un ejemplo,

Somos administradores de nuestra máquina y ya hemos restringido la posibilidad de que se ejecute Windows Media Player. Por defecto la política se aplicara también a nosotros, para variar este comportamiento, basta con abrir las directivas de seguridad local, y navegar hasta Directivas de Restricción de software. Una vez ubicados, y sin movernos de esa carpeta, nos situamos en el panel de la derecha y hacemos doble clic sobre obligatoriedad. En ese cuadro de dialogo veremos varias opciones, una de ellas nos permite que estas restricciones se ejecuten para Todos los usuarios excepto los administradores locales

Trabajar con el registro desde la Linea de Comandos.

Thu, 09 Nov 2006 19:15:53 GMT

http://freyes.svetlian.com/registro/registro.htm#_Toc95851852

Permisos NTFS en windows y acceso denegado a los archivos.

Sat, 28 Oct 2006 16:36:56 GMT

Permisos NTFS en Windows XP/2000/2003
Las reglas de NTFS

Los permisos NTFS pueden concederse a usuarios individuales o a grupos de usuarios. Como es posible que un usuario pertenezca a más de un grupo, puede conceder a un determinado usuario permisos diferentes para el mismo archivo o la misma carpeta. En este caso se concederá el permiso NTFS menos restrictivo. Estos principios se ilustran mejor con un par de escenarios.

Escenario 1

Sara pertenece al grupo CONFIANZA y el grupo CONFIANZA tiene concedido acceso de Modificación para la carpeta Documentos. Sara también pertenece al grupo LECTORES y el grupo LECTORES tiene concedido permiso de sólo lectura para la carpeta Documentos. Como se concederá el menos restrictivo de los permisos NTFS, se concederá a Sara acceso de Modificación para esta carpeta.

Excepción a la regla

Sólo hay una excepción a esta regla. Si se configura el permiso Sin acceso, siempre se aplicará este permiso, independientemente de cualesquiera otros permisos pudieran haberse concedido. El escenario 2 ilustra los efectos de utilizar el permiso Sin acceso.

Escenario 2

Sara pertenece al grupo CONFIANZA y el grupo CONFIANZA tiene concedido acceso de Modificación para la carpeta Documentos. Sara también pertenece al grupo LECTORES y el grupo LECTORES tiene concedido permiso de Sólo lectura para la carpeta Documentos. Sara también pertenece al grupo TODOS (se trata de un grupo predeterminado de NT al que pertenecen todos los usuarios) y el grupo TODOS tiene concedido el permiso Sin acceso. En este caso, Sara no tendrá acceso a la carpeta Documentos porque se aplica la excepción a la regla de NTFS.

Permisos NTFS estándar para carpetas
Nota Los permisos estándar no se pueden personalizar.
Para configurar permisos de carpeta NTFS en el Explorador de Windows

Haga clic con el botón secundario del mouse (ratón) en la carpeta seleccionada.
Seleccione Propiedades, seleccione la ficha Seguridad y haga clic en el botón Permisos.

Sin acceso	Deniega el acceso a un usuario o a un grupo de usuarios. Un usuario puede ver el directorio o el nombre de archivo, pero no puede tener acceso al mismo. Precaución Tenga cuidado de no aplicar este permiso al grupo Todos, ya que si lo hace denegaría el acceso a todos los usuarios, incluso aunque tuvieran concedido un permiso menos restringido. Éste es el error más común que cometen los Administradores al implementar la seguridad NTFS. Consulte el escenario 2, anteriormente en este artículo.
Listado	Los usuarios pueden ver los nombres de archivo, pero no pueden consultarlos ni ejecutarlos.
Lectura	Los usuarios pueden leer y ejecutar archivos, pero no pueden hacer cambios a los mismos.
Adición	Los usuarios pueden agregar archivos a la carpeta, pero no pueden verlos ni ejecutarlos.
Adición y Lectura	Los usuarios pueden agregar archivos a la carpeta, así como verlos y ejecutarlos.
Modificación	Los usuarios pueden leer, ejecutar, escribir y eliminar archivos o carpetas, pero no pueden cambiar los permisos del directorio o los archivos que contiene. Los usuarios a los que se les haya concedido acceso de Modificación para una carpeta pueden eliminar otras carpetas de la misma que ellos hayan creado, pero no pueden eliminar la carpeta para la que se les haya concedido acceso de Modificación.
Control total	Los usuarios pueden leer, ejecutar, escribir y eliminar archivos o carpetas dentro del directorio para el que se les haya concedido Control total. También pueden cambiar los permisos para el directorio y los archivos que contiene. Los usuarios con este permiso también pueden tomar posesión de archivos y carpetas. Hablaré de la posesión en la parte II de esta serie.

Permisos NTFS estándar para archivos
Los permisos estándar que pueden aplicarse a los archivos son menos que los que pueden aplicarse a las carpetas.

Sin acceso	Deniega el acceso a un usuario o a un grupo de usuarios. Un usuario puede ver el nombre de archivo, pero no puede tener acceso al mismo.
Lectura	Los usuarios pueden leer y ejecutar archivos, pero no pueden hacer cambios a los mismos.
Modificación	Los usuarios pueden leer, ejecutar, escribir y eliminar el archivo, pero no pueden cambiar los permisos para los archivos que no poseen.
Control total	Los usuarios pueden leer, ejecutar, escribir y eliminar el archivo. También pueden cambiar los permisos para el archivo y tomar posesión del mismo.

Correcion de errores de asignación de permisos , y acceso denegado.

Muchas veces el administrador esta asignando los permisos , o mismo los usuarios estan efectuando este procedimiento en sus shares , cuando sacamos todos los permisos , y nos quedamos sin acceso a nuestra propia carpeta, bueno ahora describiremos la manera de siempre que se cuente con una cuenta de administrador o con privilegios, tomar posesion de estos archivos , y poder cambiar su permisologia.

Cómo tomar posesión de una carpeta

NOTA: debe haber iniciado sesión en el equipo con una cuenta que tenga privilegios administrativos.

Para tomar posesión de una carpeta:

1.	Haga clic con el botón secundario del mouse (ratón) en la carpeta de la que desee tomar posesión y, a continuación, haga clic en Propiedades.
2.	Haga clic en la ficha Seguridad y, después, haga clic en Aceptar en el mensaje de seguridad (si aparece alguno).
3.	Haga clic en Avanzadas y, después, haga clic en la ficha Propietario.
4.	En la lista Nombre, haga clic en su nombre de usuario, en Administrador si ha iniciado sesión como Administrador o en el grupo Administradores. Si desea tomar posesión del contenido de dicha carpeta, haga clic para activar la casilla de verificación Reemplazar propietario en subcontenedores y objetos .
5.	Haga clic en Aceptar. Aparecerá el siguiente mensaje, donde nombre de carpeta es el nombre de la carpeta de la que desea tomar posesión: No tiene permiso de Lectura sobre el contenido del directorio nombre de carpeta . ¿Desea reemplazar los permisos del directorio por permisos que le concedan Control total? Todos los permisos serán reemplazados si contesta Sí. Haga clic en Sí.
6.	Haga clic en Aceptar, y vuelva a aplicar los permisos y la configuración de seguridad que desee para la carpeta y su contenido.

Cómo tomar posesión de un archivo

NOTA: debe haber iniciado sesión en el equipo con una cuenta que tenga privilegios administrativos.

Para tomar posesión de un archivo, siga estos pasos:

1.	Haga clic con el botón secundario del mouse (ratón) en el archivo del que desee tomar posesión y, a continuación, haga clic en Propiedades.
2.	Haga clic en la ficha Seguridad y, después, haga clic en Aceptar en el mensaje de seguridad (si aparece alguno).
3.	Haga clic en Avanzadas y, después, haga clic en la ficha Propietario.
4.	En la lista Nombre, haga clic en Administrador, o haga clic en el grupo Administradores y, después, haga clic en Aceptar. El Administrador o el grupo Administradores es ahora el propietario del archivo. Para cambiar los permisos de los archivos y las carpetas que hay bajo esta carpeta, continúe en el paso 5.
5.	Haga clic en Agregar.
6.	En la lista Escriba los nombres de objeto que desea seleccionar ( ejemplos ) , escriba la cuenta de usuario o de grupo a la que desea conceder acceso al archivo. Por ejemplo, Administrador .
7.	Haga clic en Aceptar.
8.	En la lista Nombres de grupos o usuarios , haga clic en la cuenta que desee (por ejemplo, Administrador) y, después, haga clic para activar las casillas de verificación correspondientes a los permisos que desee asignar a dicho usuario. Por ejemplo, Control total [Permitir]. Cuando termine de asignar permisos, haga clic en Aceptar.