En alguna ocasión podremos necesitar que nuestro grupo de soporte técnico sea miembro del grupo de administradores locales de todos o algunos equipos en nuestro dominio.
Lo primero a tener en cuenta sería definir si la política alcanzará a todos los equipos o sólo a unos específicos, ya que si es a estos últimos, debemos crear una OU y agregar allí los objetos 'equipo' a los que queremos que afecte. Si es a todos, podemos vincular la GPO a nivel de dominio sin problema.
Antes de comenzar con el procedimiento creamos un grupo y en él agregamos a los usuarios de nuestro equipo de soporte técnico.
Ahora, el procedimiento es el siguiente y lo haremos para que afecte a todos los equipos en el dominio:
Administrador de políticas de grupo > Objetos de directiva de Grupo > nuevo > escribimos un nombre para la política
una vez creada, vamos a ella, clic derecho > editar
dentro de la GPO navegamos por: Configuración del equipo > Configuración de Windows > Configuración de Seguridad > Grupos Restringidos
allí:
Clic derecho > agregar grupo > clic en 'examinar'.
En 'ubicaciones' vamos ha ubicar el nombre del equipo local.
Le damos en buscar y seleccionamos el grupo 'administradores' que corresponde a los Built in.
Cerramos las ventanas con 'aceptar' en todas y vemos que nuestro grupo queda agregado en la lista de grupos restringidos.
Damos doble clic sobre él > y en la sección de 'Miembros de este grupo'hacemos clic en el boton 'agregar' y examinamos en nuestro directorio activo en la ubicación del dominio.
Buscamos el grupo que deseamos que sea miembro de los administradores locales, en nuestro caso el grupo de soporte técnico, lo seleccionamos y cerramos todas las ventanas con 'aceptar'.
De la misma forma podemos agregar al grupo admins. del dominio que desaparece cuando agregamos nuestro grupo, así tendremos ambos grupos como administradores locales en todos los equipos del dominio.
Nos vamos para una estación de trabajo que se encuentre unida al dominio y en una ventana de comandos ejecutamos:
gpupdate /force
luego ejecutamos:
net localgroup administradores
nos debe mostrar en la lista, los grupos de soporte técnico y admins del dominio (si lo agregamos)
Un Saludo,
---
Walter J. Taborda
MCP, MCSA / MCSE Windows Server 2003
VS Vision Sistemas
Envigado, Antioquia, Colombia
tel: 371 54 49 - 378 03 38
celular: 313 797 53 33
walter.taborda@NOSPAMvisionsistemas.com.co
www.visionsistemas.com.co
jueves, 18 de junio de 2009
jueves, 11 de junio de 2009
Orden de las reglas en ISA Server
Para que las reglas apliquen correctamente deben tener un orden lógico y consecuente con el diseño que se quiera implementar.
Luego del análisis y de tener en el papel las restricciones, los usuarios, lo permitido, lo denegado, los diferentes protocolos y todo lo que se involucre en las políticas, debemos crear las reglas y ordenarlas de la siguiente forma:
1. relgas que permitan el tráfico entre la red local y el local host.
2. reglas de publicación de servidores
3. reglas para denegar (anónimos)
4. reglas para permitir (anónimos)
5. reglas para denegar (usuarios autenticados)
6. reglas para permitir (usuarios autenticados)
7. regla predeterminada de ISA Server
Existen dos formas de administrar la navegación:
a. permitir todo e ir denegando lo necesario
b. denegar todo e ir permitiendo lo necesario
Yo recomiendo la opcion 'b', pues es la más segura, aunque inicialmente la carga administrativa es mayor, pero luego de unos pocos días de afinamiento la carga disminuye y se torna color de rosa, pues los resultados son geniales.
La opción 'a', es de administrar todo el tiempo y más complicada pienso yo, pues es negar sitio por sitio que se va encontrando o denunciando y es un trabajo de nunca acabar, pues los usuarios siempre encontrarán sitios similares al que fue denegado anteriormente.
---
Walter J. Taborda
MCP, MCSA / MCSE Windows Server 2003
VS Vision Sistemas
Envigado, Antioquia, Colombia
tel: 371 54 49 - 378 03 38
celular: 313 797 53 33
walter.taborda@NOSPAMvisionsistemas.com.co
www.visionsistemas.com.co
Luego del análisis y de tener en el papel las restricciones, los usuarios, lo permitido, lo denegado, los diferentes protocolos y todo lo que se involucre en las políticas, debemos crear las reglas y ordenarlas de la siguiente forma:
1. relgas que permitan el tráfico entre la red local y el local host.
2. reglas de publicación de servidores
3. reglas para denegar (anónimos)
4. reglas para permitir (anónimos)
5. reglas para denegar (usuarios autenticados)
6. reglas para permitir (usuarios autenticados)
7. regla predeterminada de ISA Server
Existen dos formas de administrar la navegación:
a. permitir todo e ir denegando lo necesario
b. denegar todo e ir permitiendo lo necesario
Yo recomiendo la opcion 'b', pues es la más segura, aunque inicialmente la carga administrativa es mayor, pero luego de unos pocos días de afinamiento la carga disminuye y se torna color de rosa, pues los resultados son geniales.
La opción 'a', es de administrar todo el tiempo y más complicada pienso yo, pues es negar sitio por sitio que se va encontrando o denunciando y es un trabajo de nunca acabar, pues los usuarios siempre encontrarán sitios similares al que fue denegado anteriormente.
---
Walter J. Taborda
MCP, MCSA / MCSE Windows Server 2003
VS Vision Sistemas
Envigado, Antioquia, Colombia
tel: 371 54 49 - 378 03 38
celular: 313 797 53 33
walter.taborda@NOSPAMvisionsistemas.com.co
www.visionsistemas.com.co
Etiquetas:
ISA Server
Suscribirse a:
Entradas (Atom)