Todavía estoy usando el arranque dual en algunas de mis computadoras, por lo que tengo dos instalaciones de Windows 7 en ejecución. La mayoría de los datos están en una partición en un disco duro independiente que utilizan ambas instalaciones.
Para ciertos archivos necesito configurar el permiso NTFS; si lo hago usando una cuenta de usuario o un grupo de Windows personalizado, funciona bien en una instalación. Al iniciar la segunda instalación, el usuario no tiene acceso a los archivos porque las entradas en las ACL son específicas de la cuenta de la primera instalación (y se muestran como "desconocidas" en el cuadro de diálogo de seguridad).
Para solucionar este problema, podría utilizar uno de los grupos integrados de Windows. Sus ID son los mismos en todas las instalaciones de Windows.
La pregunta es ¿cuál de los grupos integrados utilizar? Quiero darle al usuario la menor cantidad de permisos adicionales posible:
Administrators S-1-5-32-544
Backup Operators S-1-5-32-551
Cryptographic Operators S-1-5-32-569
Distributed COM Users S-1-5-32-562
Event Log Readers S-1-5-32-573
Guests S-1-5-32-546
IIS_IUSRS S-1-5-32-568
Network Configuration Operators S-1-5-32-556
Performance Log Users S-1-5-32-559
Performance Monitor Users S-1-5-32-558
Power Users S-1-5-32-547
Remote Desktop Users S-1-5-32-555
Replicator S-1-5-32-552
Users S-1-5-32-545
No quiero utilizar administradores, operadores de respaldo ni usuarios avanzados porque las cuentas de estos grupos tienen permisos poderosos. ¿Cuál de los restantes es el menos 'poderoso'?
Tampoco puedo usar 'Invitados' porque no deberían tener acceso a los archivos.
Tampoco puedo usar 'usuarios' porque todos los usuarios normales están en ese grupo, pero no todos los usuarios deberían tener acceso a los archivos en cuestión.
Respuesta1
1 palabra. Usuarios.
Los usuarios son básicamente todos los que pueden ser autenticados localmente por esa máquina.
Respuesta2
Parece que en Windows Vista y más tarde el grupo 'Usuarios avanzados' perdió casi todos sus poderes y sus miembros son esencialmente tan poderosos como los miembros del grupo 'usuarios'.
Por lo tanto, el grupo de usuarios avanzados es un buen candidato para el requisito dado.
Además, el grupo 'Replicador' no tiene derechos de usuario adicionales y AFAIK no tiene permisos sobre ningún objeto seguro. Es un grupo heredado de la época de Windows NT.
Si utiliza servidores, el grupo 'Operadores de impresión' es otro candidato.
Editar: Resulta que tanto el grupo 'Usuarios avanzados' como el de 'Operadores de impresión' no funcionan para este propósito. Incluso cuando un usuario es miembro de estos grupos y los grupos tienen permisos de escritura para un recurso, el usuario no tiene acceso de escritura al recurso.
Al igual que el grupo de administradores, estos grupos son especiales y cuando un usuario está en el grupo obtiene un token dividido al iniciar sesión. Los permisos obtenidos a través de la membresía de este grupo no están en su token de usuario estándar y, por lo tanto, no tiene acceso al recurso.
Puedes ver esto escribiendo
whoami /groups
El grupo 'Usuarios avanzados' tiene un atributo de:
Group used for deny only
El grupo 'Usuarios de escritorio remoto' no tiene esto, pero tiene el efecto secundario que permite al usuario iniciar sesión a través de RDP. Así que el único grupo que se puede utilizar para esto es elReplicantegrupo
Respuesta3
Un enfoque muy experimental sería hacer que ambas instalaciones de Windows utilicen la misma base de datos de usuarios (SAM).
Si pudiera copiar el archivo SAM ( \Windows\System32\config\SAM
) de la instalación 1 en la instalación 2, los usuarios serían idénticos hasta el nivel SID.
Un enfoque similar sería crear un grupo en cada instalación y luego intentar editar el archivo SAM de una instalación, cambiando su SID o el utilizado por la otra instalación. Como las herramientas de restablecimiento de contraseña modifican el SAM, esta podría ser una forma posible.
Nunca probé esto yo mismo; por lo tanto, antes de probar estos enfoques, asegúrese de tener una copia de seguridad completa de su sistema...