Sé que a todos nos cuesta lograr un equilibrio entre mantener las estaciones de trabajo de nuestros usuarios bloqueadas pero aún utilizables. Tengo un problema real con un cliente cuyos usuarios instalan constantemente barras de herramientas, juegos, malware, etc. Realmente quiero poder quitarles los derechos administrativos locales (y también los de administración). El problema es que dependen de un puñado de aplicaciones mal escritas que requieren derechos de administrador local para ejecutarse correctamente. Antes de que nadie lo sugiera, no es posible deshacerse de estas aplicaciones.
Me doy cuenta de que puedo crear accesos directos personalizados a estas aplicaciones usando el comando runas y guardando las credenciales del administrador local. El problema con esta solución es:
- Debo proporcionar manualmente las credenciales de administrador local para cada usuario.
- Algunos de los programas se basan en datos del perfil de usuario local y no funcionan correctamente si se los "engaña" haciéndoles creer que se están ejecutando con el perfil NombreDeEquipo\Administrador.
Lo que me encantaría es instalar alguna aplicación o aplicar una Política de grupo que me permita especificar aplicaciones a las que se les debe permitir elevar los permisos del perfil local. ¿Existe una solución como esta disponible?
¿Cómo manejan todos los demás bloquear las estaciones de trabajo y seguir admitiendo software heredado o mal escrito?
Respuesta1
Es raro que un paquete de software realmente necesite derechos de administrador, sino que escribe en un área del registro o del disco duro a la que los administradores normalmente tienen acceso y otros usuarios no. Esto puede parecer quisquilloso, pero es fundamental para solucionar este problema.
Puedes utilizar el proceso.monitor editar: gracias gracityherramientas de Microsoft para monitorear lo que están haciendo las aplicaciones y asignar derechos a esas áreas a los usuarios.http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx
Luego puede usar Políticas de grupo para aplicar ACL de seguridad tanto a archivos como a carpetas y partes del registro. Una causa común de este problema es que el programa escribe en su carpeta de instalación en c:\archivos de programa, o en su configuración global en el registro de la máquina en HKey Local Machine.
Respuesta2
Puede obtener algunos consejos útiles del otro hilo sobre este tema:Aplicaciones heredadas que requieren privilegios de administrador en XP
Luego debería poder configurar el sistema de archivos y los permisos de registro necesarios mediante un GPO.
Respuesta3
EncuentroMonitor de procesoy microsoftKit de herramientas de compatibilidad de aplicacionesútil cuando se intenta hacer que funcionen las aplicaciones heredadas. También hayLuz de error LUA, pero no lo he probado.
En cuanto al bloqueo, otorgaría derechos de administrador local a aquellos usuarios que sepan lo que están haciendo y que no vayan a destruir cosas "accidentalmente". (esta es sólo mi opinión)
Respuesta4
Estoy muy en desacuerdo con no dar nunca acceso de administrador local. Perdería una enorme cantidad de tiempo si empleara esa práctica. Sin embargo, es difícil medir la confianza en el administrador local cuanto más crece su organización. Considere emplear una política de "Tierra Quemada" para otorgar al administrador local un formulario firmado que acompañe la concesión del mismo. Dicha política sería "si lo rompes, estarás solo, pasaremos unos minutos mirándolo y luego lo borraremos y volveremos a cargar".