none
Diferencia en los scripts de usuario y de política RRS feed

  • Pregunta

  • Buenas,

    En mi empresa como venia de winnt pues los usuarios llamaban a un generico que montaba las unidades de red y después hacia tareas de actualización con un script. Pero como muchas veces teníamos que actualizar programas nos obligaba a poner a los usuarios como administradores locales de las maquinas.

    Pues ahora quisiera poder quitar a los usuarios del grupo de administradores locales. Pero he visto que en la política se puede poner un script de inicio y no sé que diferencias tiene entre ponerlo en la política o en la Usuarios y equipos poner el script en script de inicio de sesión.

    Esa es mi pregunta principal, pero ya quería aprovechar para hacer otra consulta. En el paso para poner a los usuarios administradores como usuarios avanzados, me recomendais alguna pauta??

    Muchas gracias,
    lucia
    jueves, 26 de marzo de 2009 8:42

Respuestas

  • Las diferencias son que el Logon Scipt o sea a nivel de usuario se correra con credenciales Locales o sea con las credenciales del usuario logueado. El Startup Script se ejecuta con la cuenta local de sistema.

    En cuando a poner los usuarios como administradores o usuarios avanzados eso me parece que es = Problemas :).

    Personalmente preferiria verificar que privilegios precisan y solo darle los que precisen para su dia a dia.

    Slds
    Sebastian del Rio
    Saludos. Colabora con el foro y vota si el mensaje es util.
    • Marcado como respuesta Bolita jueves, 26 de marzo de 2009 20:38
    jueves, 26 de marzo de 2009 19:41
    Moderador

Todas las respuestas

  • En ambiente NT ponerle el script en las propiedades del usuario era la única opción, porque no había GPOs.
    Por compatibilidad, aún ahora se siguen ejecutando esos scripts almacenados en el NETLOGON.

    A partir de W2000 y con GPOs es recomendable hacerlo por GPO.

    La diferencia entre hacerlo por máquina o por equipo, es sobre todo por el contexto de seguridad con el que se ejecuta. Los de máquina se hacen con la cuenta System, y los de usuario con el usuario que inicia sesión.

    Además, hay Inicio de máquina, inicio sesión usuario, cierre sesión usuario, apagado de máquina.

    Lo único a cuidar es que en lugar de ponerlos en el NETLOGON, lo debes copiar a la ventana que se abre cuando pulsas el botón Show Files, y luego asignarlo.

    Guillermo Delprato - MVP - MCT - MCSE - MCSA - MCTS:AD Buenos Aires, Argentina
    • Marcado como respuesta Bolita jueves, 26 de marzo de 2009 20:38
    • Desmarcado como respuesta Bolita jueves, 26 de marzo de 2009 20:45
    jueves, 26 de marzo de 2009 19:41
    Moderador
  • Las diferencias son que el Logon Scipt o sea a nivel de usuario se correra con credenciales Locales o sea con las credenciales del usuario logueado. El Startup Script se ejecuta con la cuenta local de sistema.

    En cuando a poner los usuarios como administradores o usuarios avanzados eso me parece que es = Problemas :).

    Personalmente preferiria verificar que privilegios precisan y solo darle los que precisen para su dia a dia.

    Slds
    Sebastian del Rio
    Saludos. Colabora con el foro y vota si el mensaje es util.
    • Marcado como respuesta Bolita jueves, 26 de marzo de 2009 20:38
    jueves, 26 de marzo de 2009 19:41
    Moderador
  • Sebastian del Rio dijo:

    Las diferencias son que el Logon Scipt o sea a nivel de usuario se correra con credenciales Locales o sea con las credenciales del usuario logueado. El Startup Script se ejecuta con la cuenta local de sistema.

    En cuando a poner los usuarios como administradores o usuarios avanzados eso me parece que es = Problemas :).

    Personalmente preferiria verificar que privilegios precisan y solo darle los que precisen para su dia a dia.

    Slds
    Sebastian del Rio


    Saludos. Colabora con el foro y vota si el mensaje es util.


    Ojala fuera todo tan facil... pero en una empresa con 1500 usuarios... como que no nos podemos complicar... y para ir poco a poco habiamos pensado en ir quitando privilegios, ya que la variedad de programas es muy heterogéneo... Pero un buen primer paso es quitar a los usuarios como administradores.


    La verdad es que una cosa que me disgustó mucho del directorio activo es que en cierto modo obliga al usuario a ser administradordel equipo para instalar las aplicaciones suministradas por nosotros, es decir, a nivel de equipo la distribución de software va correctamente pero a nivel de usuario (a traves de agregar quitar programas) pide que sea administrador, cosa que no lo veo lógico porque si es un software suministrado por el administrador del dominio no debería pedir permisos especiales al usuario, ya que el administrador del dominio confía en ese software.

    Yo estaba empezando a pasar los scripts del "usuarios y equipos" a los gpos porque lo veía mas correcto, pero realmente es una faena que no sé si tiene algun beneficio... y como no encontraba mucha información al respecto he decidio preguntaros.
    jueves, 26 de marzo de 2009 20:47
  •  Es justamente en una red con tanta cantidad de usuarios que las posibilidades de automatizar de AD te dan los beneficios.

    Piensa esto ¿qué es más fácil para ponerle a los usuarios un script de inicio? ¿ir usuario por usuario? ¿o enlazar una GPO a OU o dominio?
    Creo que no tiene discusión :-)

    Que los usarios sean administradores de sus máquinas suele traer problemas, y más en una red de ese tamaño. El control de las aplicaciones no pasa porque tú se las des a los usuarios, sino en que puedas manejar qué aplicaciones puede o debe tener cada usuario, o inclusive determinar cuándo no las tendrá más.
    Para eso desde W2000 tienes la posibilidad de Publicar o Asignar aplicaciones por GPO. Los usuarios las tendrán disponibles, o inclusive las pueden instalar, sin necesidad de que sean administradores locales.

    Además, si los usuarios son administradores de sus máquinas, no tienes ningún control sobre ellas, en el momento que los "molestes" con algo la sacan del dominio y hacen lo que quieren.
    Inclusive podrían instalar aplicaciones que comprometan toda la seguridad de tu red.

    Revisa las posibilidades de AD, que realmente son muchas e importantes, te ahorrarán mucho trabajo y mejorarán notablemente tu red.

    Guillermo Delprato - MVP - MCT - MCSE - MCSA - MCTS:AD Buenos Aires, Argentina
    viernes, 27 de marzo de 2009 13:00
    Moderador
  • Los usuarios las tendrán disponibles, o inclusive las pueden instalar, sin necesidad de que sean administradores locales.


    Eso te puedo asegurar que no es así. Creé un msi para poder pasar unas aplicaciones que tenemos y me pedía privilegios de administrador (guardaba datos en fonts y en system32), y me pareció un fallo... ya que si yo apruebo el software es porque confio en él, y así consigo que mis usuarios no sean administradores.
    lunes, 30 de marzo de 2009 13:22
  • ¿Asignado o publicado? ¿por máquina o por usuario? porque, como te mencioné hay que hacerlo por GPO, no alcanza con tener un MSI.

    Además hay más posibilidades dependiendo cómo creas el MSI

    Guillermo Delprato - MVP - MCT - MCSE - MCSA - MCTS:AD Buenos Aires, Argentina
    lunes, 30 de marzo de 2009 20:23
    Moderador
  • Lo publiqué por GPO y usuario porque no son aplicaciones para todo el mundo (imaginemos el programa de contabilidad solo lo instalará la gente que lo necesite). Iba a agregar quitar programas y podía ver la lista de programas que había autorizado, pero el usuario no tenía derechos administrativos en la máquina por lo que fallaba la instalación.

    El msi era sencillo... copiar los archivos a las ubicaciones (system32, fonts, carpeta programa), crear los links y añadir algunas ramas de registro. Y me daba errores de permisos :( por lo que me cayó mi gozo en un pozo.

    Muchas gracias Guillermo por tu tiempo.
    Lucia
    martes, 31 de marzo de 2009 7:44
  • Tienes más opciones para tu caso, por ejemplo puedes *asignar* por máquina aplicando la GPO sólo a los equipos que estén en una determinada unidad organizativa. O también puede filtrar la GPO por grupos y asignarla a los usuarios de determinado grupo (departamento)

    Sigo insistiendo :-) que debe haber un problema con el MSI... porque justamente es para que instalen aplicacioes los usuarios comunes.


    Guillermo Delprato - MVP - MCT - MCSE - MCSA - MCTS:AD Buenos Aires, Argentina
    martes, 31 de marzo de 2009 17:21
    Moderador
  • Creé el msi con el Install Aware Studio Admin, y solo hacía lo que te he dicho... copiar ficheros y ramas de registros. Por lo que me quedé sorprendida al ver que no funcionaba y me pedía permisos administrativos. En un rato probaré con el msi de acrobat reader por usuario raso a ver si funciona.
    miércoles, 1 de abril de 2009 7:36