10 votos

¿Este es un enfoque recomendado/válido para los permisos de servidor de archivo?

Los servidores de archivos son un hecho de la vida en ELLA y tengo la curiosidad de si hay prácticas generalmente aceptadas (no me atrevo a usar la palabra "mejor" aquí) cómo crear grupos y solicitar permisos para administrar el acceso de cliente a una carpeta compartida en un servidor de archivos.

En mi trabajo actual, me terminó heredando un buen lío de diferentes maneras de hacer esto, que van desde decenas de grupos en la Acl para sólo poner a los usuarios individuales directamente en el sistema de archivos. Mi tarea era la de limpiar el desorden y llegar a algún tipo de estandarizar la forma de acercarse a este en toda la empresa (grande, medio ambiente, 150k personal, 90k los equipos cliente, 100 de los servidores de archivos).

Desde mi comprensión de la cuestión, parece que como mínimo necesita un grupo requerido por el nivel de acceso al recurso protegido. Este modelo parece dar la mayor flexibilidad en las que no es necesario tocar el sistema de ficheros permisos de nuevo a menos que usted necesita para apoyar un nivel de acceso diferente. La desventaja es que usted tendrá que crear más grupos que con re-usando el mismo grupo a través de múltiples recursos compartidos.

Aquí hay un ejemplo que muestra lo que quiero decir:

Hay una parte llamada "los Resultados de la Prueba" en un servidor de archivos con nombre FILE01 y usted tiene la gente que necesita acceso de sólo lectura, lectura-escritura de acceso y control total. 1 recurso protegido * 3 niveles de acceso = 3 grupos de seguridad. En nuestro ANUNCIO entorno, podemos crear estas como universal de los grupos, de modo que puede fácilmente agregar usuarios o grupos a partir de cualquiera de los dominios en el bosque. Dado que cada grupo únicamente se refiere a una carpeta compartida y nivel de acceso, los nombres de grupo incorpora los "clave" piezas de datos y los permisos son así:

"FILE01-Test Results-FC"  --  Full Control
"FILE01-Test Results-RW"  --  Read & Write
"FILE01-Test Results-RO"  --  Read Only

Normalmente, también se incluyen la incorporada en el SISTEMA de cuenta y los Administradores integrados con Control Total de acceso a la información. Cualquier cambio que realmente consigue lo que el acceso a este recurso que ahora se pueden controlar mediante la pertenencia a grupos en lugar de tener que tocar la ACL (ya sea mediante la adición de "Papel" de los grupos de representación de negocio específico de funciones como Gerentes, Técnicos, Analistas de QA, etc. o simplemente individuales de los usuarios para el acceso).

Dos Preguntas:

1) esto Es realmente un recomendado o enfoque válido para el manejo de permisos o me estoy perdiendo algunos más simple, más elegante solución? Yo estaría especialmente interesado en las soluciones que el uso de la herencia, pero todavía conservan la flexibilidad de no tener que re-ACL gran parte de los sistemas de ficheros cuando las cosas cambian.

2) ¿Cómo está el manejo de permisos del servidor de archivos y la estructura de grupo en su entorno? Puntos de bonificación para aquellos que también están trabajando en entornos de gran tamaño.

7voto

Jim B Puntos 18849

Ese enfoque no está mal. Como una regla que nunca uso individual de los usuarios para agregar permisos de uso de un grupo. Grupos, no obstante, puede ser utilizado a través de los recursos. Por ejemplo HR podría tener RW acceso a los archivos, mientras que los GERENTES podrían haber R. también puede configurar el Acceso Basado en la Enumeración. Echa un vistazo a el siguiente webcast:

Webcast TechNet: Administración de Windows Server 2003 de la Serie (Parte 4 de 12): Grupo de Gestión (Nivel 200)

El acceso basado en la enumeración puede hacer la vida más fácil de ver:

Enumeración basada en el acceso

ABE puede ayudar a reducir el número de diferentes acciones que se han de administrar.

5voto

James Risto Puntos 1011

Mi enfoque es no utilizar el archivo/directorio de nivel de permisos de archivo; uso de archivo de nivel de recurso compartido de los permisos, y el conjunto de todo el sistema de ficheros del servidor de datos de la unidad para el Control Completo de Todos (que se convierte en irrelevante).

A través de los años (10+), he encontrado que los permisos de NTFS son más complejos y conduce a más errores. Si los permisos se establecen mal, o la herencia que se rompe, se exponen datos y es difícil de encontrar y ver. Además, usted está expuesto a la de mover/copiar problema ... a los usuarios mover archivos también mover la ACL del archivo, mientras que la copia hereda el destino de la ACL.

Utilice su lectura/escritura de los grupos de la misma, pero sobre todo el recurso compartido de archivos mediante Comp Mgmt MMC. No hace plena ... los usuarios disparar a sí mismos con parciales de conocimiento/la mejor de las intenciones.

2voto

Zypher Puntos 26466

Su enfoque es básicamente la forma en que me iba a acercarse a ella.
Las únicas cosas que me gustaría añadir son estos:

1) me gustaría añadir a su "roles" esquema de la evaluación de lo que necesitan a través de servidores no en un solo servidor, usted está probablemente va a ejecutar en los valores atípicos para esto, pero mi teoría con esos es que cuando te encuentras con ellos, crear otro grupo. en mi experiencia, donde hay un valor atípico hay muchos.

2) creo FIRMEMENTE que re-evalute la necesidad de que los grupos Universales para todo, como tomar un replicación de golpear con ellos como con los miembros y los grupos dentro del grupo Universal se replica en los servidores de Catálogo Global, mientras que con Dominio Local y Global, sólo el grupo se replica en los servidores de catálogo global. Así que si usted hace un cambio en un grupo universal inicia una replicación, mientras que a nivel mundial y local de dominio no.

1voto

BlankVerse Puntos 85

El enfoque propuesto se parece bastante sólido. Una cosa a tener en cuenta a pesar de que es la manera en la que inicialmente configurar los recursos compartidos de archivos. Es recomendable tener un nivel superior compartir, que contiene subcarpetas que, a continuación, asignar los permisos de grupo. NTFS continuación, puede omitir el "Recorrido de la Carpeta/Ejecutar Archivo" en la carpeta de nivel superior y el acceso a la subvención a la subcarpeta.

La estructura tendría el aspecto \servername\sharename\grupo-carpeta con permisos de recurso compartido que sólo necesitan que se establezca en el "nombre de carpeta", y el real permisos de NTFS conjunto en el "grupo de la carpeta" carpeta.

El servidor de archivos será capaz de realizar mejor con este tipo de instalación también.

General otras cosas que me gustaría hacer es tener una convención de nomenclatura para los grupos que el nombre del grupo es el mismo que el del grupo nombre de la carpeta (con el FC/RW/RO anexa si se desea), y el palo de la UNC de la carpeta en la descripción del grupo (por lo que su script de inicio de sesión puede leer de nuevo y establecer una asignación de unidad de esa manera, y también de modo que usted puede ver más fácilmente lo carpetas compartidas aplicar para que los grupos).

1voto

Chris Doherty Puntos 71

El estándar de la práctica he estado usando para servidor de archivos de Windows desde Windows 2000 (establecidos en la Marca Minasi del dominio de Windows Server serie, a fin de buscar allí para obtener más información) es el uso de grupos locales en el propio servidor de archivo para la nidificación.

Considere, por ejemplo, un servidor de archivos llamado KERMIT en un dominio llamado de los MUPPETS.

Decir KERMIT tiene un par de archivos compartidos:

\\KERMIT\Applications
\\KERMIT\Finance
\\KERMIT\Sales
\\KERMIT\Manufacturing

Crear grupos locales a KERMIT para el acceso y dar permisos en el sistema de archivos exactamente como usted lo ha especificado (es decir, un grupo por nivel de acceso por acción)

KERMIT\Applications-RO
KERMIT\Applications-RW
KERMIT\Applications-FC
KERMIT\Finance-RO
[...]

Debido a que estos son grupos locales, usted puede poner cualquier otro tipo de grupos o usuarios a los que queremos en ellos - los grupos locales de dominio, grupos globales, universales grupos, cuentas de usuario de cualquier dominio del bosque. La gestión de derechos es ahora de local en el archivo del servidor de los grupos más bien que el sistema de archivos o el ANUNCIO.

Esto le añade una capa adicional a su gestión de grupos, pero tiene el beneficio de permitir que (dicen) del sitio local a los administradores a gestionar sus propios servidores de archivos sin necesidad de nada más que de derechos de Administrador para el servidor de archivos. Si usted tiene un federado especie de sucursal de la estructura, donde cada oficina del tipo de las que hace su propia cosa con sus servidores, esto puede ser un beneficio real. Puede que no quiero tener que dar AD derechos de administrador a una docena de sitio local de administradores.

También mantiene que su ANUNCIO está lleno de un montón de grupos (un grupo por nivel de acceso por acción por cada servidor puede aumentar muy rápidamente), y minimiza el grupo de replicación entre la GCs. Se le permite reservar tus grupos de ANUNCIOS para los roles en lugar de los permisos.

Si su entorno es rigurosamente estandarizado y todos los servidores de archivos son idénticos y se replica, entonces esta es, obviamente, una capa más de grupos que no necesita. También, si usted sabe que necesita un determinado grupo de ANUNCIOS a tener los mismos derechos en un recurso compartido que existe en cada servidor de archivos, usted va a necesitar algún tipo de automatización para mantener eso.

En pocas palabras, el más diferente de los servidores de archivos son los unos de los otros, los más, usando la máquina de los grupos locales tiene sentido. Los más de ellos son similares, la más desea utilizar el sistema que está utilizando actualmente.

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: