Mais problemas de compartilhamento de arquivos no Windows

Question

Isso está me incomodando agora. Eu estou no processo de converter um servidor de arquivos autônomo que não foi adicionado ao nosso domínio para usar o AD Groups \ Users para os compartilhamentos de arquivos. Este servidor de arquivos costumava usar contas de máquina local para as permissões de compartilhamento. Eu obtive o fileserver juntou ao domínio então agora eu quero substituir as permissões de compartilhamento com as corretas do AD.

Talvez eu precise disso explicado para mim, mas, por algum motivo, não consigo fazê-lo funcionar. Por exemplo, eu tenho uma pasta compartilhada:

\fileserver\jsmith

Nesta pasta, as permissões Compartilhar são definidas para que o usuário do AD John Smith tenha Controle total. As permissões NTFS (Isso é o que está na guia Segurança, certo?) Estão definidas para isso:

FILESERVER \ Adminstrators - Controle total
PROPRIETÁRIO CRIADOR - Permissões especiais está marcada e desabilitada

SYSTEM - Controle total embora esteja desabilitado (assim como as outras caixas de seleção na coluna Permitir)
FILESERVER \ Users - Leia & Executar, Listar Conteúdo da Pasta e Ler (todos desabilitados)

Pelo que entendi (e talvez esteja errado), o usuário John Smith deve poder acessar o \filserver\jsmith e ser capaz de abrir arquivos e pastas, além de criar arquivos e pastas.

No entanto, este não é o caso. John Smith recebe uma mensagem de acesso negado ao tentar acessar esse compartilhamento.

EDIT : Para esclarecer, quando John Smith digitar o caminho UNC para o compartilhamento ( \fileserver\jsmith ) no Windows Explorer e pressionar Enter, ele receberá a mensagem Acesso Negado.

Talvez eu não esteja entendendo tudo isso. Então, qual seria a maneira "correta" de realizar o que eu quero: um usuário ou grupo do AD para ter o Read & Acesso de gravação a uma pasta compartilhada.

    

Answer 1

O usuário "DOMAIN \ JSmith" não deve estar recebendo "Acesso Negado" ao tentar acessar o compartilhamento, mas deve estar recebendo "Acesso Negado" ao tentar criar ou modificar arquivos hospedados nesse local. Você pode esclarecer o que você quer dizer com "John Smith recebe uma mensagem de Acesso Negado ao tentar acessar este compartilhamento". com minha declaração anterior em mente?

Em geral, "Permissões de compartilhamento" sempre deve ser definido como "Todos / Controle total". Eles são uma falha de hardware danificada pelo cérebro nos dias em que as pessoas podem compartilhar pastas hospedadas em volumes não-NTFS. (Alguém quer discutir sobre isso? Heh heh ...)

"Permissões de compartilhamento" são aplicadas pelo serviço "Servidor". Se os usuários conseguirem acessar arquivos por algum outro método (um "Compartilhar" mais alto no sistema de arquivos com diferentes "Permissões de Compartilhamento", arquivos exportados via IIS com algum outro protocolo, etc), as "Permissões de Compartilhamento" não serão aplicadas. Especifique suas permissões nas permissões de NTFS e, não importa o quanto os usuários acessem os arquivos, o driver NTFS aplicará as permissões desejadas.

Para fins acadêmicos, explicarei como o "Permissões de Compartilhamento" funciona (mas eu ainda encorajo você a defini-los como "Todos / Controle Total"): O serviço "Servidor" (que lida com a exportação "Compartilhado") pastas através do protocolo SMB) verifica se o NTFS subjacente permite a tentativa de acesso do usuário (leitura, gravação, etc) e, em seguida, verifica a tentativa de acesso do usuário contra as "Permissões de Compartilhamento". Se uma das permissões não permitir o acesso desejado, a tentativa de acesso falhará. A definição "DOMAIN \ JSmith" com a permissão "Controle total" em "Permissões de compartilhamento" não altera a permissão subjacente do NTFS. No nível do sistema de arquivos, "DOMAIN \ JSmith", um membro do grupo "DOMAIN \ Domain Users", possui a permissão Ler, Executar e Listar Conteúdo da Pasta por meio do aninhamento padrão de "DOMAIN \ Usuários do Domínio" no campo "FILESERVER" \ Users "quando você ingressou no domínio.

Você nunca deve nomear usuários individuais em permissões, exceto pastas criadas especificamente para esse usuário apenas, como pastas de perfil de usuário móvel ou diretórios base. Como esse compartilhamento é chamado "JSmith", acho que é um diretório inicial. Adicione "DOMAIN \ JSmith" com "Modify" ou "Full Control" (dependendo se você quer que JSmith possa modificar as permissões na pasta e nas subpastas ou não - "Full Control" dará a ele o direito) a ACL da pasta e você deve estar pronto.

Se uma pasta compartilhada for para alguma outra finalidade (por exemplo, para uma "função de trabalho" ou compartilhamento entre usuários), o Right Way ^(tm) para aplicar a permissão é criar um grupo que descreva a função associado ao acesso (como, digamos, "Departamento de compras"), conceder permissão à pasta NTFS para o recurso ao grupo (como, digamos, "Modificar") e colocar os usuários apropriados nesse grupo.

Quando uma função de trabalho muda ou a mudança ocorre, você precisa apenas colocar a "nova pessoa" nos grupos apropriados e seu acesso aos recursos é garantido. Se você tivesse nomeado usuários individuais em permissões, a única maneira de garantir acesso para um novo usuário seria visitar cada recurso e adicionar novas permissões (possivelmente removendo a permissão antiga se uma função de trabalho fosse alterada). Se você não mantiver uma boa documentação de onde aplicou várias permissões a usuários individuais, nunca poderá criar um novo usuário com os "mesmos direitos" de um usuário existente sem um esforço maciço de investigação em todos os seus recursos.

Mesmo que um grupo tenha um único membro, crie um grupo assim mesmo. Você se agradecerá mais tarde quando tiver que designar outra pessoa para o grupo.

Editar:

Uma lista de controle de acesso (ACL) é a lista de entradas de controle de acesso (ACEs) aplicadas a um recurso. A ACL é o que você vê na guia "Segurança" de uma guia "Propriedades" e na caixa de diálogo "Avançado". Cada linha da ACL é uma ACE. (Eu pensei em trazer "ACE" para ele, caso você o veja em documentação em algum lugar e imagine o que isso significa ...)

Você está vendo a mesma coisa na aba "Segurança" e na caixa de diálogo "Avançado", apresentada de forma diferente (com mais detalhes na caixa de diálogo "Avançado").

Estou tendo problemas para descobrir por que você pode estar vendo um "Acesso negado" ao acessar o compartilhamento, conforme descrito por você. Com o JSmith conectado ao seu computador cliente com sua conta de domínio e o computador FILESERVER associado ao domínio, você deve não receber um "Acesso negado". Você tem certeza de que JSmith está conectado com sua conta de domínio no computador cliente?

    

Answer 2

Você realmente é dingido pela mais restritiva das políticas de segurança em questão. Assim, se você tiver um compartilhamento que tenha permissões somente leitura em uma pasta com leitura-gravação, você obterá somente leitura. Da mesma forma, se você tiver um compartilhamento com permissões de leitura / gravação, mas a pasta for somente leitura, você terá somente leitura.

Não estou dizendo que é o jeito certo de fazer as coisas, mas vejo regularmente compartilhamentos com o Everyone RW, com toda a segurança das permissões NTFS da pasta compartilhada.

    

Answer 3

As contas de usuário necessárias têm, no mínimo, o diretório transversal se os compartilhamentos não estiverem na raiz da unidade?

Por exemplo: Se você tiver uma pasta chamada D: \ Users e as pastas lá, então essas contas precisam ser capazes de atravessar D: \ e D: \ Users, caso contrário, eles receberão um acesso negado. / p>     

Answer 4

Atualização: removeu instruções incorretas após o feedback do Evan.

Quando você trabalha com pastas compartilhadas, precisa pensar em dois conjuntos de permissões:

Primeiro, as permissões no próprio compartilhamento. Estes são como o segurança na porta da boate. Se o usuário que está se conectando não tiver permissões nesse nível, ele terá o acesso negado, não importando quais sejam as permissões na própria pasta.

Em segundo lugar, você tem as permissões na pasta. Se o usuário tiver acesso suficiente para passar pelo compartilhamento, mas não tiver acesso à pasta, ele será negado. Pastas não, de forma alguma, herdam as permissões do compartilhamento.

Em ambos os níveis, você pode usar contas locais ou de nível de domínio. Em um servidor de arquivos típico, você não terá nenhuma conta local além daquelas exigidas pelo Windows.

Se você estiver configurando esse compartilhamento para vários usuários, você deverá conceder permissões a um grupo de segurança que contenha todos os usuários que precisarão de acesso. Em seguida, você usa as permissões de nível NTFS no sistema de arquivos subjacente para obter um controle refinado sobre quem pode fazer o quê.

    

Answer 5

O que você precisa fazer, em vez de configurar um compartilhamento separado para cada usuário, é configurar um único compartilhamento de nível superior chamado "Usuários". Adicione permissões suficientes para isso no nível Compartilhamento, para que todos os usuários do seu domínio possam acessá-lo. Em seguida, sob esse compartilhamento, crie um subdiretório para cada usuário. Não compartilhe isso, basta definir as permissões necessárias do NTFS nele. Os usuários irão acessá-lo via \\ servername \ users \ username.