El usuario en el grupo de Administradores no tiene los mismos derechos que el Administrador (Win 2012 R2)

He creado un administrador de usuario y lo puse en los Grupos de Administradores (local, no hay AD). Pero este usuario administrador no tiene los mismos derechos que el propio usuario administrador.

Ejemplo 1: un archivo es propiedad de SYSTEM y el Grupo de Administradores tiene control total. Si intento agregar permisos para un usuario a este archivo, no funciona para el usuario administrador. Con el administrador se trabaja sin ningún problema.

Ejemplo 2: La configuración de seguridad mejorada de IE está DESACTIVADA para los administradores y ACTIVADA para los usuarios. Para el administrador, esto está bien, para el usuario administrador todavía está activado.

¿Es este un problema de configuración? Si es así, ¿qué debo hacer para corregirlo?

permissions windows-server-2012-r2 users

— Maarten
fuente

Esto no debería comportarse de esta manera. Asegúrese de que esta cuenta local esté realmente en el grupo de administradores locales. Mientras está conectado con ese usuario, puede ejecutar WHOAMI /GROUPS /FO LISTpara verificar que realmente son parte de los grupos correctos.

— TheCleaner

¿Se ha desconectado y vuelto a iniciar sesión con el nuevo usuario después de hacerlo miembro de los grupos de administradores? Su token de acceso no cambiará durante la vida de la sesión actual en esa máquina

— Mathias R. Jessen

@TheCleaner: estos son los grupos de los que es miembro: Todos, NT AUTHORITY \ Cuenta local y miembro del grupo Administrators, BULTIN \ Administrators, BUILTIN \ Users, NT AUTHORITY \ REMOTE INTERACTIVE LOGON, NT AUTHORITY \ INTERACTIVE, NT AUTHORITY \ Authenticated Users , NT AUTHORITY \ This Organization, NT AUTHORITY \ Cuenta local, LOCAL, NT AUTHORITY \ NTLM Authentication, Etiqueta obligatoria \ Nivel obligatorio medio

— Maarten

Como no está en un dominio, me pregunto si es un problema de UAC. Si desactiva UAC (Control de cuentas de usuario) en el servidor, ¿funciona entonces? social.technet.microsoft.com/wiki/contents/articles/…

— TheCleaner

El problema de los derechos (ejemplo 1) parece estar bien después de deshabilitar el UAC. El IE ESC sigue siendo un problema.

— Maarten

Respuestas:

Esto podría ser causado por el Control de cuentas de usuario , una característica (odiada por muchos) que hace que, incluso si tiene derechos administrativos, no los tenga a menos que los solicite explícitamente. Existen dos políticas distintas que rigen el comportamiento de UAC (ambas se encuentran en Computer settings\Windows settings\Security settings\Local policies\Security options), una para la cuenta integrada Administratory otra para todos los demás usuarios administrativos:

Control de cuenta de usuario: Modo de aprobación de administrador para la cuenta de administrador integrada (deshabilitada de manera predeterminada)
Control de cuentas de usuario: ejecute a todos los administradores en modo de aprobación de administrador (habilitado de forma predeterminada)

Lo que esto significa es: de forma predeterminada, la cuenta integrada Administratorno se ve afectada por UAC, mientras que todos los demás usuarios administrativos sí lo están ; por lo tanto, es posible que un usuario administrativo (diferente del incorporado Administrator) no tenga realmente derechos administrativos, incluso si es un miembro del Administratorsgrupo.

Más información aquí .

— Massimo
fuente

Deshabilitar la segunda configuración me solucionó el problema en Windows 10. ¿Puede explicar por qué existe esta configuración? ¿Cuál es el punto de tener un grupo Administrador si los miembros de ese grupo no tienen acceso a ninguno de los permisos de dicho grupo de manera predeterminada?

— Mordred

El punto es (supuestamente) que UAC impide que los usuarios con derechos administrativos se disparen accidentalmente en sus pies, porque tienen que solicitar explícitamente al sistema que les otorgue los privilegios que deberían tener (usando "ejecutar como administrador" al iniciar un programa).

— Massimo

Sin embargo, la implementación es tan inestable (por ejemplo, no puede usar "ejecutar como administrador" en el Explorador de Windows porque siempre se está ejecutando y no puede iniciar otra instancia con derechos elevados) que la mayoría de los usuarios avanzados terminan deshabilitando UAC por completo , para poder usar realmente su computadora.

— Massimo

UAC ha existido desde Windows Vista, pero es aún peor en Windows 8 y posterior (incluido 10), porque deshabilitar UAC efectivamente impide que las aplicaciones Metro / Modern se ejecuten: por alguna razón desconocida, parecen necesitar realmente UAC para funcionar, y ni siquiera comienzan si UAC está deshabilitado.

— Massimo

Tuve una situación similar y la arreglé siguiendo los pasos de http://clintboessen.blogspot.com/2013/05/you-dont-currently-have-permission-to.html (que son para una situación diferente). Esto es lo que tenía y lo que hice:

Dos computadoras, sin dominio de Active Directory, una con Win 8.1 (nombre W81 por ejemplo), otra con Server 2012 (nombre w12 por ejemplo)
Dos usuarios locales en w12: [UsuarioA] con ContraseñaA y [UsuarioB] con ContraseñaB. Ambos pertenecen al grupo local [Administradores].
Dos usuarios locales en w81: [UsuarioA] y [UsuarioB] con la misma ContraseñaA y ContraseñaB que los usuarios correspondientes de w12. Ambos pertenecen al grupo local [Administradores].
Comparto una carpeta en w12: a. Nombre compartido: Temp1 $ b. Compartir permisos: [Todos], Control total c. Permisos NTFS: [Administradores], Control total. Ningún otro grupo tiene permisos NTFS aquí
Conectado en el W12 como [UsuarioA], intento acceder al recurso compartido usando UNC \ w12 \ Temp1 $. Recibo un error que dice que no tengo acceso. El recurso compartido se encuentra. Simplemente no hay acceso.
Conectado en el W81 como [UsuarioB], intento acceder al recurso compartido usando UNC \ w12 \ Temp1 $. Me sale el mismo error. RESTAURAR w12 NO AYUDA.
Si agrego [UsuarioA] y [UsuarioB] explícitamente a los permisos NTFS, ahora tienen acceso al recurso compartido utilizando los pasos 5 y 6.
Ejecuté GPEdit.msc en w12, fui a:

Configuración del equipo -> Configuración de Windows -> Configuración de seguridad -> Políticas locales -> Opciones de seguridad

y usé la configuración para las recomendaciones n. ° 1 y n. ° 3:

# 1, Control de cuenta de usuario: Modo de aprobación de administrador para la cuenta de administrador incorporada: Deshabilitado. # 3, Control de cuentas de usuario: ejecute a todos los administradores en modo de aprobación de administrador: deshabilitado.

Y no tocó el # 2: # 2, Control de cuentas de usuario: Comportamiento de la solicitud de elevación para administradores en Modo de aprobación de administrador: Solicitud de consentimiento para binarios que no son de Windows

Reinició la máquina y la situación no volvió a suceder.

— Jelgab
fuente

El permiso para acceder al recurso compartido (permiso Compartir) no es lo mismo que el permiso para acceder a un archivo (permiso NTFS). Están y deberían estar separados.

— artifex