Resultados inesperados ocorrem se você definir segurança de arquivo usando o grupo diretiva ou modelos de segurança

IMPORTANTE: Este artigo foi traduzido por um sistema de tradução automática (também designado por Machine Translation ou MT), não tendo sido portanto traduzido ou revisto por pessoas. A Microsoft possui artigos traduzidos por aplicações (MT) e artigos traduzidos por tradutores profissionais, com o objetivo de oferecer em português a totalidade dos artigos existentes na base de dados de suporte. No entanto, a tradução automática não é sempre perfeita, podendo conter erros de vocabulário, sintaxe ou gramática. A Microsoft não é responsável por incoerências, erros ou prejuízos ocorridos em decorrência da utilização dos artigos MT por parte dos nossos clientes. A Microsoft realiza atualizações freqüentes ao software de tradução automática (MT). Obrigado.

Clique aqui para ver a versão em Inglês deste artigo: 321470
Este artigo foi arquivado. É oferecido "como está" e não será mais atualizado.
Sintomas
Se você tentar definir as permissões do sistema de arquivos usando a diretiva de grupo ou modelos de segurança em arquivos e pastas que têm o Microsoft Windows NT 4.0 estilo Access Control Lists (ACLs), você pode enfrentar resultados inesperados. Especificamente, você pode modificar as permissões da pasta se as pastas não são explicitamente definidas para ser configurado. O arquivo ou pasta que é afetada herda permissões quando ele não foi configurado para fazer isso. Como resultado, a pasta afetada pode ter mais reduzida permissões de acesso.

Esse problema pode ocorrer se você estiver usando um modelo de segurança em que as ACLs de dois ou mais estão sendo definidas que estão hierarquicamente em si, e quando uma das seguintes condições for verdadeira:
  • Você está usando um volume que foi acessado remotamente por um computador de cliente Windows NT 4.0.
  • Você está usando um volume recém-formatado.
  • Você está usando um volume que foi migrado do Windows NT 4.0.
  • Você está usando um volume no qual o cacls.exe foi usado para definir permissões.
Causa
Esse problema ocorre porque o mecanismo de configuração de segurança não interpreta corretamente ACLs do Windows NT 4.0 estilo como sendo protegido contra herança.
Resolução
Para contornar esse problema, use qualquer uma das soluções alternativas que são descritas nesta seção.

Solução alternativa 1: Modificar o modelo de segurança para proteger pastas que podem ser afetadas

Você pode usar modelos de diretiva de grupo ou segurança para configurar arquivos ou pastas para que elas são protegidas de ter as permissões substituídas. Para fazer isso, clique em não permitir que permissões nesse arquivo ou pasta a ser substituído quando você define as permissões do sistema de arquivos.

No cenário que é descrito na seção resumo, se você proteger C:\Data\Private, permissões herdadas não são aplicadas para a pasta depois que a diretiva é aplicada. O modelo de segurança inclui as seguintes entradas:
[Segurança de arquivo]
Computer_drive \Data\Private",1,"D:PAR(A;OICI;FA;;;WD)"
Computer_drive \Data",0,"D:PAR(A;OICI;FA;;;WD)(A;OICI;0x1200a9;;;BU)"
Computer_drive \Data\Public",0,"D:AR(A;OICI;FA;;;WD)(A;OICI;0x1200a9;;;BG)"
Se você clicar em não permitir que permissões nesse arquivo ou pasta a ser substituído , você também impedir que as pastas em C:\Data\Private sendo afetadas.

Observação : você não pode usar caracteres curinga (1) para especificar várias pastas.

Solução 2: Usar vários modelos para aplicar a segurança do sistema de arquivo

O problema descrita na seção "Resumo" somente ocorre quando a segurança do arquivo de sistema é definida em vários níveis na mesma hierarquia de pastas no mesmo modelo. Portanto, se você criar modelos que afetam somente o sistema de arquivos no mesmo nível na hierarquia, você pode impedir que o problema ocorra.

Por exemplo, 1 modelo aplica permissões a c:\Dados e modelo 2 aplica permissões a C:\Data\Public. Nesse cenário, você pode aplicar os modelos individualmente em qualquer ordem. Se você fizer isso, C:\Data\Private não é afetado.

Configurações de modelo 1:
[Segurança de arquivo]
Computer_drive \data",0,"D:PAR(A;OICI;FA;;;WD)(A;OICI;0x1200a9;;;BU)"
Configurações de modelo 2:
[Segurança de arquivo]
Computer_drive \data\public",0,"D:AR(A;OICI;0x1200a9;;;BG)"

Solução 3: Substituir todas as permissões

Se desejar que todas as subpastas a ser controlada usando somente as permissões herdadas são entregues por modelos ou diretiva de grupo, você pode usar modo sobrescrever. Para substituir todas as permissões, clique em Substituir permissões existentes em todas as subpastas e arquivos com permissões herdáveis na caixa de diálogo Template Security Policy Setting que aparece quando você configurar grupos restritos.

Por exemplo, se você usar a pasta C:\Apps para fornecer um ponto de instalação para programas, convém garantir que todos os usuários tenham acesso de leitura somente para essa pasta e subpastas que contêm os programas. Nesse cenário, você pode usar modo sobrescrever. Se você usar o modo sobrescrever, qualquer ACLs de estilo 4.0 do Windows NT são convertidas em ACLs de estilo do Windows 2000.
Situação
A Microsoft confirmou que este é um problema nos produtos da Microsoft listados no começo deste artigo.
Mais Informações
A versão do sistema de arquivo NTFS no Windows 2000 usa a funcionalidade de herança e as permissões herdáveis. No Windows 2000, um arquivo ou pasta pode ter permissões explícitas e herdadas. Por padrão, as permissões são herdadas dos recipientes que são superiores na hierarquia de pasta, a menos que essas permissões são bloqueadas.

As permissões em arquivos ou pastas podem ser representadas por uma linguagem de seqüência de caracteres conhecida como SDDL (Security Descriptor Definition Language). A lista a seguir descreve alguns das seqüências de caracteres que definem o comportamento da herança:
  • "P" SDDL_PROTECTED: essa seqüência significa que a herança de recipientes que são superiores na hierarquia de pasta está bloqueada.
  • "AR" SDDL_AUTO_INHERIT_REQ: essa seqüência significa que objetos filho herdam permissões provenientes deste objeto.
  • "AI" SDDL_AUTO_INHERITED: essa seqüência significa herança é permitida, supondo que "P" também não é definida.
Uma pasta NTFS formatadas no Windows 2000 que tem herança bloqueada normalmente tem P sinalizador e o sinalizador AI definido, por exemplo:
C:\Data:D:PAI(A;OICI;FA;;;WD)
Por outro lado, se você definir uma ACL usando o utilitário Cacls ou o utilitário Xcacls, a ACL não inclui o sinalizador de P ou sinalizador AI. Portanto, herança não afeta a um objeto que esteja configurado dessa maneira.

Cenário de problema de exemplo

Existe a seguinte hierarquia de pastas em um volume:
  • C:\Dados
  • C:\Data\Public
  • C:\Data\Private
As seguintes permissões são definidas:
  • C:\Data:D:PAI(A;OICI;FA;;;WD): Todos Full Control, bloquear herança
  • C:\Data\Public:D:AI(A;OICIID;FA;;;WD): Todos Full Control, herdado
  • C:\Data\Private:D:(A;OIIO;FA;;;BA)(A;CI;FA;;;BA): Interno Administradores controle total
Use o seguinte comando para definir as permissões no C:\Data\Private:
cacls c:\data\private /g administradores: f
Para reproduzir o problema, use a diretiva de grupo para configurar as seguintes restrições sistema arquivo:
  • C:\Dados: Todos Full Control, leitura de usuários, bloquear herança
  • C:\Data\Public: Convidado leitura, herança habilitada
Depois de aplicar a diretiva, ocorrem as seguintes permissões:
  • C:\Data:D:PAI(A;OICI;FA;;;WD)(A;OICI;0x1200a9;;;BU)
  • C:\Data\Public:D:AI(A;OICI;FA;;;WD)(A;OICI;0x1200a9;;;BG)(A;OICIID;FA;;;WD)(A;OICIID;0x1200a9;;;BU)
  • C:\Data\Private:D:AI(A;OIIO;FA;;;BA)(A;CI;FA;;;BA)(A;OICIID;FA;;;WD)(A;OICIID;0x1200a9;;;BU)
Depois que você executa esse procedimento, o sinalizador AI agora está definido no C:\Data\Private. Como resultado, permissões de controle total todos (WD) e permissão de leitura BU (usuários) são herdadas.

Aviso: este artigo foi traduzido automaticamente

Propriedades

ID do Artigo: 321470 - Última Revisão: 12/07/2015 10:42:02 - Revisão: 3.2

Microsoft Windows 2000 Server SP1, Microsoft Windows 2000 Server SP2, Microsoft Windows 2000 Service Pack 3, Microsoft Windows 2000 Professional SP1, Microsoft Windows 2000 Professional SP2, Microsoft Windows 2000 Service Pack 3

  • kbnosurvey kbarchive kbmt kbenv kbprb KB321470 KbMtpt
Comentários