Você está offline; aguardando reconexão
Entrar

Não há suporte para seu navegador

Você precisa atualizar seu navegador para usar o site.

Atualize para a versão mais recente do Internet Explorer

Cliente, serviço e programa problemas podem ocorrer se você alterar as configurações de segurança e atribuições de direitos do usuário

O suporte para o Windows XP terminou

A Microsoft terminou o suporte para o Windows XP em 8 de abril de 2014. Esta alteração afetou as suas atualizações de software e opções de segurança. Saiba o que isto significa para você e como permanecer protegido.

O suporte para o Windows Server 2003 termina em 14 de julho de 2015.

A Microsoft terminou o suporte para o Windows Server 2003 em 14 de julho de 2015. Esta alteração afetou as suas atualizações de software e opções de segurança. Saiba o que isto significa para você e como permanecer protegido.

IMPORTANTE: Este artigo foi traduzido pelo software de tradução automática da Microsoft e eventualmente pode ter sido editado pela Microsoft Community através da tecnologia Community Translation Framework (CTF) ou por um tradutor profissional. A Microsoft oferece artigos traduzidos automaticamente por software, por tradutores profissionais e editados pela comunidade para que você tenha acesso a todos os artigos de nossa Base de Conhecimento em diversos idiomas. No entanto, um artigo traduzido pode conter erros de vocabulário, sintaxe e/ou gramática. A Microsoft não é responsável por qualquer inexatidão, erro ou dano causado por qualquer tradução imprecisa do conteúdo ou por seu uso pelos nossos clientes.

Clique aqui para ver a versão em Inglês deste artigo: 823659
Sumário
Configurações de segurança e atribuições de direitos de usuário podem ser alteradas em diretivas locais e diretivas de grupo para reforçar a segurança em computadores membros e controladores de domínio. No entanto, a desvantagem do aumento de segurança é a introdução de incompatibilidades com clientes, serviços e programas.

Este artigo descreve incompatibilidades que podem ocorrer em computadores cliente que estão executando o Windows XP ou uma versão anterior do Windows, quando você alterar as configurações de segurança específicas e atribuições de direitos de usuário em um domínio do Windows Server 2003 ou um domínio do Windows Server anterior.

Para obter informações sobre a diretiva de grupo para o Windows 7, Windows Server 2008 R2 e Windows Server 2008, consulte os seguintes artigos:Observação: O conteúdo restante deste artigo é específico para o Windows XP, Windows Server 2003 e versões anteriores do Windows.

Windows XP

Clique aqui para ver informações específicas do Windows XP
Para aumentar o reconhecimento de configurações de segurança mal configurado, use a ferramenta Editor de objeto de diretiva de grupo para alterar as configurações de segurança. Quando você usar o Editor de objeto de diretiva de grupo, as atribuições de direitos de usuário são aprimoradas nos seguintes sistemas operacionais:
  • Windows XP Professional Service Pack 2 (SP2)
  • Windows Server 2003 Service Pack 1 (SP1)
O recurso avançado é uma caixa de diálogo que contém um link para este artigo. A caixa de diálogo aparece quando você altera uma configuração de segurança ou uma atribuição de direitos de usuário para uma configuração que ofereça menor compatibilidade e seja mais restritiva. Se você alterar a mesma segurança usuário ou configuração de atribuição de direitos diretamente usando o registro ou usando modelos de segurança, o efeito é o mesmo que a alteração da configuração no Editor de objeto de diretiva de grupo. No entanto, a caixa de diálogo que contém o link para este artigo não aparecem.

Este artigo contém exemplos de clientes, programas e operações que são afetadas pelas configurações de segurança específicas ou atribuições de direitos do usuário. No entanto, os exemplos não são autoritativos para todos os sistemas operacionais da Microsoft, todos os sistemas operacionais de terceiros ou para todas as versões do programa que são afetadas. Nem todas as configurações de segurança e atribuições de direitos de usuário são incluídas neste artigo.

Recomendamos que você valide a compatibilidade de todas as alterações de configuração relacionadas à segurança em uma floresta de teste antes de introduzi-las em um ambiente de produção. Floresta de teste deve refletir a floresta de produção das seguintes maneiras:
  • Versões de sistema operacional cliente e servidor, cliente e programas de servidor, versões de service pack, hotfixes, alterações de esquema, segurança grupos, associações de grupo, permissões em objetos do sistema de arquivos compartilhados pastas, o registro, o serviço de diretório do Active Directory, grupo e local Configurações de diretiva e o tipo de contagem de objeto e local
  • Tarefas administrativas são realizadas, administrativas ferramentas usadas e sistemas operacionais que são usados para executar tarefas administrativas
  • Operações são realizadas, como a seguir:
    • Autenticação de logon de usuário e computador
    • Redefinições de senha por usuários, computadores e administradores
    • Navegação
    • Definir permissões para o sistema de arquivos, de pastas compartilhadas, para o registro e para recursos do Active Directory usando o Editor de ACL em todos os sistemas operacionais de cliente em conta todos os ou domínios de recursos de todos os sistemas operacionais de cliente de todas as contas ou domínios de recurso
    • Impressão de contas administrativas e não administrativas

Windows Server 2003 SP1

Clique aqui para ver informações específicas do Windows Server SP1

Avisos em gpedit. msc

Para ajudar os clientes que eles estão editando um direito de usuário ou a opção de segurança que poderia ter negativamente afetam sua rede, dois mecanismos de aviso foram adicionados a gpedit. msc. Quando os administradores editarem um direito de usuário que pode afetar toda a empresa, eles verão um novo ícone semelhante um sinal de rendimento. Eles também receberão uma mensagem de aviso que tem um link para o artigo 823659 da Base de dados de Conhecimento Microsoft. O texto desta mensagem é o seguinte:
Modificar essa configuração pode afetar a compatibilidade com clientes, serviços e aplicativos. Para obter mais informações, consulte <user right="" or="" security="" option="" being="" modified="">(Q823659)</user>
Se você foi direcionado para este artigo da Base de Conhecimento um link em gpedit. msc, certifique-se de ler e entender a explicação fornecida e o possível efeito da alteração dessa configuração. A seguir lista os direitos de usuário que contêm o texto do aviso:
  • Acesso a este computador pela rede
  • Faça logon localmente
  • Ignorar a verificação completa
  • Habilitar computadores e usuários para delegação confiável
A seguir lista as opções de segurança que têm o aviso e uma mensagem pop-up:
  • Membro do domínio: Criptografar ou assinar digitalmente dados do canal seguro (sempre) os
  • Membro do domínio: Requer alta segurança (Windows 2000 ou posterior) de chave de sessão
  • Controlador de domínio: Servidor LDAP requisitos de assinatura
  • Servidor de rede Microsoft: assinar digitalmente a comunicação (sempre)
  • Acesso à rede: Permitir Sid anônimo / conversão de nomes
  • Acesso à rede: Não permitir enumeração anônima de contas e compartilhamentos
  • Segurança de rede: nível de autenticação LAN Manager
  • Auditoria: Desligar o sistema imediatamente se não for possível registrar auditorias de segurança
  • Acesso à rede: Requisitos de assinatura de cliente LDAP
Mais Informações
As seções a seguir descrevem as incompatibilidades que podem ocorrer quando você alterar as configurações específicas de domínios, domínios do Windows 2000 e Windows Server 2003 domínios Windows NT 4.0.

Direitos de usuário

Clique aqui para ver informações sobre direitos de usuário
A lista a seguir descreve um direito de usuário, identifica as configurações que podem causar problemas, descreve por que você deve aplicar o direito de usuário e por que você deseja remover o direito de usuário e fornece exemplos de problemas de compatibilidade que podem ocorrer quando o direito de usuário é configurado.
  1. Acesso a este computador pela rede
    1. Plano de fundo

      A capacidade de interagir com computadores Windows remotos exige o direito de usuário acesso a este computador da rede . Exemplos de tais operações de rede incluem:
      • Replicação do Active Directory entre controladores de domínio em um domínio ou floresta comum
      • Solicitações de autenticação para controladores de domínio de usuários e computadores
      • Acesso a pastas compartilhadas, impressoras e outros serviços do sistema estão localizados em computadores remotos na rede


      Usuários, computadores e contas de serviço recebem ou perdem o direito de usuário acesso este computador pela rede sendo implicitamente ou explicitamente adicionado ou removido de um grupo de segurança que tenha esse direito de usuário. Por exemplo, uma conta de usuário ou um computador pode ser explicitamente adicionada a um grupo de segurança personalizado ou um grupo de segurança interno por um administrador ou pode ser implicitamente adicionada pelo sistema operacional a um grupo de segurança computado como usuários do domínio, usuários autenticados ou controladores de domínio empresarial.

      Por padrão, contas de usuário e computador são concedidos ao usuário acesso este computador pela rede direito quando grupos computados, como todos ou, preferencialmente, usuários autenticados e para controladores de domínio, o grupo de controladores de domínio de empresa são definidos em controladores de domínio padrão objeto de diretiva de grupo (GPO).
    2. Configurações de risco

      A seguir estão as definições de configuração prejudiciais:
      • Removendo a segurança de controladores de domínio da empresa grupo desse direito de usuário
      • Removendo o grupo Usuários autenticados ou um grupo explícito que permite ao usuário a usuários, computadores e contas de serviço direito de se conectar a computadores na rede
      • Removendo todos os usuários e computadores do usuário à direita
    3. Razões para conceder esse direito de usuário
      • Conceder o direito de usuário acesso a este computador da rede ao grupo controladores de domínio empresarial atende aos requisitos de autenticação que deve ter a replicação do Active Directory para a replicação ocorra entre controladores de domínio na mesma floresta.
      • Esse direito de usuário permite aos usuários e computadores acessar arquivos compartilhados, impressoras e serviços do sistema, incluindo ativo Diretório.
      • Esse direito de usuário é necessário para que os usuários de acesso email usando versões anteriores do Microsoft Outlook Web Access (OWA).
    4. Motivos para remover este direito de usuário
      • Usuários que conectam seus computadores para a rede pode acessar recursos em computadores remotos que têm permissões para. Por exemplo, esse direito de usuário é necessário para um usuário conectar compartilhado impressoras e pastas. Se esse direito de usuário é concedido a todos no grupo, e se algumas pastas compartilhadas tiverem de compartilhamento e NTFS permissões do sistema de arquivos configurado para que o mesmo grupo tenha acesso de leitura, qualquer pessoa pode exibir arquivos Essas pastas compartilhadas. No entanto, esta é uma situação improvável para novas instalações do Windows Server 2003 porque o compartilhamento padrão e NTFS permissões no Windows Server 2003 não incluem o grupo Todos. Para sistemas atualizados do Microsoft Windows NT 4.0 ou Windows 2000, isso vulnerabilidade pode ter um nível mais alto de risco porque o compartilhamento padrão e o permissões do sistema de arquivos para esses sistemas operacionais não são tão restritivas quanto as permissões padrão no Windows Server 2003.
      • Não há nenhuma razão válida para remover o Enterprise Grupo controladores de domínio do usuário certo.
      • Geralmente, o grupo Todos é removido em favor de o grupo Usuários autenticados. Se o grupo Todos é removido, o Grupo de usuários autenticados deve receber esse direito de usuário.
      • Domínios de Windows NT 4.0 atualizados para Windows 2000 não concedem explicitamente o usuário acesso a este computador pela rede da direita para o grupo Todos, o grupo Usuários autenticados ou o grupo controladores de domínio empresarial. Portanto, quando você remover o grupo Todos da diretiva de domínio Windows NT 4.0, replicação do Active Directory falhará com uma mensagem de erro "Acesso negado" após a atualização para o Windows 2000. Winnt32. exe no Windows Server 2003 evita esta configuração incorreta ao conceder que esse direito de usuário de grupo de controladores de domínio empresarial quando atualizar controladores de domínio primário (PDCs) do Windows NT 4.0. Conceda ao grupo de controladores de domínio de empresa deste direito se não estiver presente no Editor de objeto de diretiva de grupo do usuário.
    5. Exemplos de problemas de compatibilidade
      • Windows 2000 e Windows Server 2003: Duplicação dos seguintes partições irá falhar com erros de "Acesso negado" conforme relatado por ferramentas de monitoramento como REPLMON e REPADMIN ou replicação de eventos no log de eventos.
        • Partição do Active Directory Schema
        • Partição de configuração
        • Partição de domínio
        • Partição de catálogo global
        • Partição de aplicativo
      • Sistemas operacionais Microsoft todos:Autenticação de conta de usuário de computadores cliente de rede remota falhará a menos que o usuário ou grupo de segurança que o usuário é um membro tem esse direito de usuário.
      • Sistemas operacionais Microsoft todos:Autenticação de contas de clientes de rede remota falhará a menos que a conta ou a conta é membro de um grupo de segurança tem esse direito de usuário. Esta situação se aplica a contas de usuário, contas de computador e contas de serviço.
      • Sistemas operacionais Microsoft todos:Remover todas as contas deste direito do usuário impedirá que qualquer conta de logon no domínio ou acessar recursos da rede. Se grupos computados, como controladores de domínio de empresa, todos ou usuários autenticados são removidos, você deve conceder explicitamente este direito de usuário a contas ou a grupos de segurança que a conta é membro de acessar computadores remotos na rede. Esta situação se aplica a todas as contas de usuário, todas as contas de computador e todas as contas de serviço.
      • Sistemas operacionais Microsoft todos:A conta administrador local usa uma senha "em branco". Conectividade de rede com senhas em branco não é permitida para contas de administrador em um ambiente de domínio. Com essa configuração, você pode esperar receber uma mensagem de erro "Acesso negado".
  2. Permitir logon local
    1. Plano de fundo

      Usuários tentando fazer logon no console de um computador baseado no Windows (usando o atalho de teclado CTRL + ALT + DELETE) e contas que estão tentando iniciar um serviço devem ter privilégios de logon local no computador host. Exemplos de operações de logon local incluem administradores que log consoles de computadores membros ou controladores de domínio em toda os empresa e usuários de domínio que estejam fazendo logon computadores membro para acessar suas áreas de trabalho usando contas não privilegiadas. Os usuários que usam uma conexão de área de trabalho remota ou serviços de Terminal devem ter o usuário Permitir logon local direito nos computadores de destino que estão executando o Windows 2000 ou Windows XP porque esses modos de logon são considerados locais para o computador host. Usuários quem está fazendo logon em um servidor que possui o Terminal Server habilitado e que não têm esse usuário à direita pode ainda iniciar uma sessão interativa remota no Windows Server 2003 domínios se eles têm o direito de usuário Permitir logon pelos serviços de Terminal .
    2. Configurações de risco

      A seguir estão as definições de configuração prejudiciais:
      • Removendo grupos de segurança administrativa, incluindo operadores de conta, operadores, operadores de impressão ou operadores de servidor e o grupo interno Administradores da diretiva do controlador de domínio padrão.
      • Remoção de contas de serviço são usadas por componentes e por programas em computadores membro e controladores de domínio da diretiva do controlador de domínio padrão.
      • Removendo usuários ou grupos de segurança logon o console de computadores membro no domínio.
      • Remoção de contas de serviço definidas no banco de dados Gerenciador de contas de segurança (SAM) local de computadores membro ou computadores do grupo de trabalho.
      • Remoção não-criadas contas administrativas que são autenticadas nos serviços de Terminal está sendo executado em um controlador de domínio.
      • Adicionar todas as contas de usuário no domínio explicitamente ou implicitamente por todos grupo o direito de logon Negar logon local . Esta configuração impedirá que os usuários de log qualquer computador membro ou qualquer controlador de domínio no domínio.
    3. Razões para conceder esse direito de usuário
      • Os usuários devem ter o direito de usuário Permitir logon local para acessar o console ou área de trabalho de um grupo de trabalho computador, um computador membro ou um controlador de domínio.
      • Os usuários devem ter este direito de usuário fazer logon em uma sessão de serviços de Terminal está sendo executado em um computador membro com Windows 2000 ou o controlador de domínio.
    4. Motivos para remover este direito de usuário
      • Falha ao restringir o acesso de console legítimo contas de usuário podem resultar em usuários não autorizados a baixar e executar código mal-intencionado alterar seus direitos de usuário.
      • Remoção do direito de usuário Permitir logon local evita logons não autorizados nos consoles de computadores, como controladores de domínio ou servidores de aplicativos.
      • Domínio não impede a remoção desse direito de logon contas de logon no console de computadores membro de domínio.
    5. Exemplos de problemas de compatibilidade
      • Servidores de terminal do Windows 2000:O direito de usuário Permitir logon local é necessário para que os usuários fazer logon no Windows 2000 servidores de terminal.
      • Windows NT 4.0, Windows 2000, Windows XP ou Windows Server 2003:Contas de usuário devem receber esse direito de usuário para fazer logon no console de computadores que estejam executando o Windows NT 4.0, Windows 2000, Windows XP ou Windows Server 2003.
      • Windows NT 4.0 e posterior:Em computadores que estejam executando o Windows NT 4.0 e posterior, se você adicionar o direito de usuário Permitir logon local , mas implicitamente ou explicitamente também conceder o direito de logon Negar logon local , as contas não poderão fazer logon no Console de controladores de domínio.
  3. Ignorar a verificação completa
    1. Plano de fundo

      O direito de usuário Ignorar verificação completa permite que o usuário navegue pelas pastas NTFS sistema de arquivos ou no registro sem verificar a permissão de acesso especial Desviar pasta . O direito de usuário Ignorar verificação completa não permite ao usuário listar o conteúdo de uma pasta. Ele permite ao usuário percorrer apenas suas pastas.
    2. Configurações de risco

      A seguir estão as definições de configuração prejudiciais:
      • Removendo contas não administrativas que fizerem logon em computadores baseados no Windows 2000 Terminal Services ou serviços de Terminal com Windows Server 2003 que não tem permissões para acessar arquivos e pastas no sistema de arquivos.
      • Remover o grupo Todos da lista de entidades de segurança que têm esse usuário direito por padrão. Sistemas operacionais Windows e muitos programas são projetados com a expectativa de que qualquer pessoa que pudesse acessar legitimamente o computador terá o direito de usuário Ignorar verificação completa . Portanto, os grupo da lista de entidades de segurança que têm esse direito por padrão removendo todos pode causar instabilidade no sistema operacional ou falha do programa. É melhor que você deixe esta configuração padrão.
    3. Razões para conceder esse direito de usuário

      A configuração padrão para o direito de usuário Ignorar a verificação completa é permitir que qualquer pessoa ignore a verificação. Para experientes administradores de sistema do Windows, esse é o comportamento esperado e eles configurarem listas de controle de acesso do arquivo sistema (SACLs) adequadamente. A única cenário onde a configuração padrão pode levar a um contratempo se o o administrador que configura permissões não entende o comportamento e espera que os usuários não podem acessar uma pasta pai não será capazes de acessar o conteúdo de qualquer pasta filha.
    4. Motivos para remover este direito de usuário

      Para tentar impedir o acesso a arquivos ou pastas no sistema de arquivos, podem ser tentadas organizações estão muito preocupadas com segurança para remover o grupo todos ou até mesmo o grupo usuários da lista de grupos que têm o direito de usuário Ignorar verificação completa .
    5. Exemplos de problemas de compatibilidade
      • Windows 2000, Windows Server 2003:Se o direito de usuário Ignorar a verificação completa for removido ou estiver mal configurado em computadores que são executando o Windows 2000 ou Windows Server 2003, configurações de diretiva de grupo de SYVOL pasta não serão replicadas entre controladores de domínio no domínio.
      • Windows 2000, Windows XP Professional, Windows Server 2003:Computadores que executam o Windows 2000, Windows XP Professional ou Windows Server 2003 registrarão eventos 1000 e 1202 e não poderão aplicar diretivas de usuário e computador, quando as permissões do sistema de arquivo são removidas da árvore SYSVOL se o usuário Ignorar verificação completa direito é removido ou mal configurado.

        Para obter mais informações, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:
        290647Identificação de evento 1000, 1001 é registrada a cada cinco minutos no log de eventos do aplicativo
      • Windows 2000, Windows Server 2003: Em computadores que executam o Windows 2000 ou Windows Server 2003, o Cota Guia do Windows Explorer desaparecerá quando Exibir propriedades de um volume.
      • Windows 2000: Não-administradores que fizerem logon um servidor de terminal do Windows 2000 poderá receber a seguinte mensagem de erro:
        Userinit. exe Erro de aplicativo. O aplicativo não inicializou corretamente 0xc0000142 Clique em OK para encerrar o aplicativo.
        Para obter mais informações, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:
        272142Os usuários são automaticamente desconectados ao tentar fazer logon nos serviços de Terminal
      • Windows NT 4.0, Windows 2000, Windows XP, Windows Server 2003:Usuários cujos computadores estão executando o Windows NT 4.0, Windows 2000, Windows XP ou Windows Server 2003 não poderão acessar pastas compartilhadas ou arquivos em pastas compartilhadas e eles podem receber mensagens de erro "Acesso negado" se eles não recebem o direito de usuário Ignorar verificação completa .

        Para obter mais informações, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:
        277644Mensagem de erro "Acesso negado" quando os usuários tentam acessar pastas compartilhadas
      • Windows NT 4.0:Em computadores com Windows NT 4.0, a remoção do direito de usuário Ignorar verificação completa fará uma cópia descarte fluxos de arquivo. Se você remover este direito de usuário quando um arquivo é copiado de um cliente Windows ou de um Cliente Macintosh para um controlador de domínio Windows NT 4.0 executando serviços para Macintosh, o fluxo de arquivo de destino é perdido e o arquivo aparece como um arquivo somente texto.

        Para obter mais informações, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:
        172930Remoção de "Ignorar a verificação completa" faz com que a cópia descarte fluxos
      • Microsoft Windows 95, Microsoft Windows 98:Em um computador cliente que esteja executando o Windows 95 ou Windows 98, o NET use * /Home comando falhará com um acesso" Negado"mensagem de erro se o grupo Usuários autenticados não é concedido o direito de usuário Ignorar verificação completa .
      • o outlook Web Access:Não-administradores não poderão fazer logon no Microsoft Outlook Web Access e receberão uma mensagem de erro "Acesso negado" se eles não recebem o direito de usuário Ignorar verificação completa .

Configurações de segurança

Clique aqui para obter informações sobre configurações de segurança
A lista a seguir identifica uma configuração de segurança e lista aninhada fornece uma descrição sobre a configuração de segurança, identifica as configurações que podem causar problemas, descreve por que você deve aplicar a configuração de segurança e, em seguida, descreve os motivos por que deseja remover a configuração de segurança. Lista aninhada fornece um nome simbólico para a configuração de segurança e o caminho do registro de configuração de segurança. Finalmente, são fornecidos exemplos de problemas de compatibilidade que podem ocorrer quando a configuração de segurança está configurada.
  1. Auditoria: Desligar o sistema imediatamente se não for possível registrar auditorias de segurança
    1. Plano de fundo
      • O auditoria: desligar o sistema imediatamente se não for possível registrar auditorias de segurança determina se o sistema será desligado se você não pode registrar eventos de segurança. Esta configuração é necessária para a avaliação C2 do programa confiável computador segurança avaliação TCSEC (critérios) e os critérios comuns de avaliação de segurança de tecnologia de informações evitar eventos auditáveis se o sistema de auditoria não pode registrar esses eventos. Se o sistema de auditoria falhar, o sistema é desligado e uma mensagem de erro Stop é exibida.
      • Se o computador não puder registrar eventos para o Talvez o log de segurança, evidências críticas ou importantes informações de solução de problemas não estar disponíveis para revisão após um incidente de segurança.
    2. Configuração de risco

      A seguir é uma configuração prejudicial: O auditoria: desligar o sistema imediatamente se não for possível registrar auditorias de segurança configuração é ativada e o tamanho do log de eventos de segurança é restrito pela opção não substituir eventos (Limpar log manualmente) , a opção Substituir eventos conforme necessário , ou Substituir eventos anteriores número dias opção Visualizador de eventos. Consulte "exemplos de compatibilidade Seção de problemas"para obter informações sobre riscos específicos de computadores executando a versão original do Windows 2000, Windows 2000 Service Pack 1 (SP1), Windows 2000 SP2 ou Windows 2000 SP3.
    3. Razões para habilitar esta configuração

      Se o computador não puder registrar eventos no log de segurança, evidências críticas ou importantes informações de solução de problemas podem não estar disponíveis para revisão após um incidente de segurança.
    4. Motivos para desativar esta configuração
      • Ativando o de auditoria: desligar o sistema imediatamente se não for possível registrar auditorias de segurança configuração pára o sistema se uma auditoria de segurança não pode ser feita para qualquer motivo. Normalmente, um evento não pode ser registrado no log de auditoria de segurança é completo e quando seu método de retenção especificado é a opção não substituir eventos (Limpar log manualmente) ou o Substituir eventos anteriores número dias opção.
      • A sobrecarga administrativa de ativação de auditoria: desligar o sistema imediatamente se não for possível registrar auditorias de segurança configuração pode ser muito alta, especialmente se também ativar a opção não substituir eventos (Limpar log manualmente) para o log de segurança. Esta configuração fornece responsabilidade individual das ações do operador. Por exemplo, um administrador poderia redefinir permissões em todos os usuários, computadores e grupos em uma unidade organizacional (UO) onde a auditoria foi ativada usando a conta interna administrador ou outra conta compartilhada e negar que redefiniu tais permissões. Entretanto, a habilitação da configuração de reduzir a robustez do sistema porque um servidor pode ser forçado a desligar ao encher com eventos de logon e outros eventos de segurança são gravados no log de segurança. Além disso, como o desligamento não é normal, podem resultar danos irreparáveis ao sistema operacional, programas ou dados. Embora o NTFS garante que a integridade do sistema de arquivos é mantida durante um desligamento amigável do sistema, não garante que cada arquivo de dados para cada programa ainda estar em forma utilizável quando o sistema for reiniciado.
    5. Nome simbólico:

      CrashOnAuditFail

    6. Caminho do registro:
      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\CrashOnAuditFail (Reg_DWORD)
    7. Exemplos de problemas de compatibilidade
      • Windows 2000:Por um bug computadores que estejam executando a versão original do Windows 2000, Windows 2000 SP1, Windows 2000 SP2 ou SP3 do Windows Server podem parar o log de eventos antes de alcançar o tamanho especificado na opção tamanho máximo do log para o log de eventos de segurança. Este bug será corrigido no Windows 2000 Service Pack 4 (SP4). Certifique-se de que seu domínio do Windows 2000 controladores de tem o Windows 2000 Service Pack 4 instalado antes de a ativação dessa configuração.

        Para obter mais informações, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:
        312571O log de eventos pára de log de eventos antes de atingir o tamanho máximo do log
      • Windows 2000, Windows Server 2003:Computadores que executam o Windows 2000 ou Windows Server 2003 pode parar de responder e, em seguida, reiniciem espontaneamente se a auditoria: desligar o sistema imediatamente se não for possível registrar auditorias de segurança configuração estiver ativada, o log de segurança está cheio e uma entrada de log de eventos existente não pode ser substituída. Quando o computador for reiniciado, aparece a seguinte mensagem de erro Stop:
        STOP: C0000244 {Falha na auditoria}
        Falha ao tentar gerar uma auditoria de segurança.
        Para recuperar, um administrador deve fazer logon, arquivar o log de segurança (opcional) Limpar o log de segurança e redefinir esta opção (opcional e conforme necessário).
      • Microsoft Network Client para MS-DOS, Windows 95, Windows 98, Windows NT 4.0, Windows 2000, Windows XP, Windows Server 2003:Não-administradores que tentam fazer logon em um domínio receberão a mensagem de erro seguinte:
        Sua conta está configurada para impedi o uso deste computador. Tente outro computador.
        Para obter mais informações, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:
        160783Mensagem de erro: os usuários não é possível logon em uma estação de trabalho
      • Windows 2000:Em computadores com Windows 2000, não-administradores não poderão fazer logon servidores de acesso remoto e receberão uma mensagem de erro semelhante à seguinte:
        Usuário desconhecido ou inválido senha
        Para obter mais informações, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:
        285665Mensagem de erro: sua conta está configurada para impedir o uso do computador
      • Windows 2000:Em controladores de domínio do Windows 2000, o serviço mensagens entre sites (Ismserv) irá parar e não pode ser reiniciado. DCDIAG relatará o erro como "Falha ao testar serviços ISMserv" e identificação de evento 1083 será registrada no log de eventos.
      • Windows 2000:Em controladores de domínio do Windows 2000, replicação do Active Directory falhará e será exibida uma mensagem de "Acesso negado" se o log de eventos de segurança estiver cheio.
      • Microsoft Exchange 2000:Servidores que estejam executando o Exchange 2000 não poderá montar o banco de dados do armazenamento de informações e o evento 2102 será registrado no log de eventos.

        Para obter mais informações, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:
        314294Mensagens de erro do Exchange 2000 são geradas por direito SeSecurityPrivilege e problemas com o Policytest
      • Outlook, Outlook Web Access: Não-administradores não poderão acessar seus emails através de Microsoft Outlook ou Microsoft Outlook Web Access, e eles serão recebe um erro 503.
  2. Controlador de domínio: requisitos de assinatura de servidor LDAP
    1. Plano de fundo

      O o controlador de domínio: requisitos de assinatura de servidor LDAP configuração de segurança determina se o servidor LDAP Lightweight Directory Access Protocol () requer que os clientes LDAP negociem a assinatura de dados. Os valores possíveis para essa configuração de diretiva são os seguintes:
      • Nenhum: Assinatura de dados não é necessário para ligar ao servidor. Se o assinar dados de solicitações do cliente, o servidor suportar.
      • Requer assinatura: A opção de assinatura de dados LDAP deve ser negociada a menos transporte Layer Security/Secure Socket Layer (SSL/TLS) está sendo usado.
      • não definido: Essa configuração não está habilitada ou desabilitada.
    2. Configurações de risco

      A seguir estão as definições de configuração prejudiciais:
      • Habilitando a Exigir assinatura em ambientes onde os clientes não suportam a assinatura LDAP ou onde assinatura LDAP do lado do cliente não está habilitado no cliente
      • Aplicar o Windows 2000 ou Windows Server Modelo de segurança 2003 Hisecdc. inf em ambientes onde os clientes não suporte à assinatura LDAP ou onde assinatura LDAP do lado do cliente não é habilitado
      • Aplicar o Windows 2000 ou Windows Server Modelo de segurança 2003 Hisecws. inf em ambientes onde os clientes não suporte à assinatura LDAP ou onde assinatura LDAP do lado do cliente não é habilitado
    3. Razões para habilitar esta configuração

      Tráfego de rede não assinada é suscetível a ataques de interceptação de onde um intruso captura pacotes entre o cliente e o servidor, modifica os pacotes e encaminha para o servidor. Quando esse comportamento ocorre em um servidor LDAP, um invasor pode causar um servidor tome decisões com base em falsas consultas do cliente LDAP. Você pode reduzir este risco em uma rede corporativa implementando medidas de alta segurança física para ajudar a proteger a infra-estrutura de rede. Modo de cabeçalho de autenticação do Internet Protocol security (IPSec) pode ajudar a evitar ataques de interceptação. Modo de cabeçalho de autenticação executa autenticação mútua e integridade do pacote para o tráfego IP.
    4. Motivos para desativar esta configuração
      • Clientes que não suportam a assinatura LDAP não serão ser capaz de executar consultas LDAP contra controladores de domínio e global catálogos se a autenticação NTLM for negociada e pacotes de serviço correto não instalado em controladores de domínio do Windows 2000.
      • Rastreamentos de rede do tráfego LDAP entre clientes e servidores serão criptografados. Isso torna difícil examinar conversações LDAP.
      • Servidores baseados no Windows 2000 devem ter o Windows 2000 Service Pack 3 (SP3) ou instalado quando forem administrados com programas que suporte a assinatura LDAP e que são executados em computadores cliente que executam o Windows 2000 SP4, Windows XP ou Windows Server 2003. Para obter mais informações, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:
        325465Controladores de domínio do Windows 2000 exigem o Service Pack 3 ou posterior quando usando ferramentas de administração do Windows Server 2003
    5. Nome simbólico:

      LDAPServerIntegrity
    6. Caminho do registro:
      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\LDAPServerIntegrity (Reg_DWORD)
    7. Exemplos de problemas de compatibilidade
      • Vínculos simples falharão e você receberá a mensagem de erro seguinte:
        Ldap_simple_bind_s() falhou: Autenticação forte necessária.
      • Windows 2000 Service Pack 4, Windows XP, Windows Server 2003:Clientes que estão executando o Windows 2000 SP4, Windows XP ou Windows Server 2003, algumas ferramentas de administração do Active Directory não operarão corretamente nos controladores de domínio que estão executando versões do Windows 2000 anteriores ao SP3 quando a autenticação NTLM for negociada.

        Para obter mais informações, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:
        325465Controladores de domínio do Windows 2000 exigem o Service Pack 3 ou posterior quando usando ferramentas de administração do Windows Server 2003
      • Windows 2000 Service Pack 4, Windows XP, Windows Server 2003:Clientes que estão executando o Windows 2000 SP4, Windows XP ou Windows Server 2003, algumas ferramentas de administração do Active Directory destinadas a controladores de domínio que estão executando versões do Windows 2000 são anteriores ao SP3 não operarão corretamente se estiverem usando endereços IP (por exemplo, "DSA. msc /server =x.x.x. x"onde x.x.x. x é um endereço IP).

        Para obter mais informações, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:
        325465Controladores de domínio do Windows 2000 exigem o Service Pack 3 ou posterior quando usando ferramentas de administração do Windows Server 2003
      • Windows 2000 Service Pack 4, Windows XP, Windows Server 2003:Clientes que estão executando o Windows 2000 SP4, Windows XP ou Windows Server 2003, algumas ferramentas de administração do Active Directory destino controladores de domínio que estão executando versões do Windows 2000 são anteriores ao SP3 não operarão corretamente.

        Para obter mais informações, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:
        325465Controladores de domínio do Windows 2000 exigem o Service Pack 3 ou posterior quando usando ferramentas de administração do Windows Server 2003
  3. Membro do domínio: exigir chave forte da sessão (Windows 2000 ou posterior)
    1. Plano de fundo
      • O membro do domínio: exigir chave forte da sessão (Windows 2000 ou posterior) determina se um canal seguro pode ser estabelecido com um controlador de domínio que não é possível criptografar o tráfego de canal seguro com um chave de sessão segura de 128 bits. A ativação dessa configuração impede o estabelecimento de um canal seguro com qualquer controlador de domínio que não é possível criptografar o canal seguro dados com uma chave forte. A desabilitação dessa configuração permite que as chaves de sessão de 64 bits.
      • Antes de habilitar essa configuração de membro estação de trabalho ou em um servidor, todos os controladores de domínio no domínio que o membro pertença devem poder criptografar dados de canal seguro com uma forte chave de 128 bits. Isso significa que todos esses controladores de domínio devem estar executando. Windows 2000 ou posterior.
    2. Configuração de risco

      Ativando o membro do domínio: exigir chave forte da sessão (Windows 2000 ou posterior) configuração é uma configuração prejudicial.
    3. Razões para habilitar esta configuração
      • Proteger as chaves de sessão usadas para estabelecer canais de comunicação entre computadores membro e controladores de domínio são muito mais forte no Windows 2000 do que em versões anteriores do Microsoft sistemas operacionais.
      • É possível, é uma boa idéia para aproveitar essas chaves de sessão mais fortes para ajudar a proteger comunicações de canal seguro de espionagem e ataques de rede de seqüestro de sessão. Eavesdropping é uma forma de ataque malicioso, onde os dados de rede é lido ou é alterado em trânsito. Os dados podem ser modificados para ocultar ou alterar o remetente ou redirecioná-lo.
      Importante Um computador que esteja executando o Windows Server 2008 R2 ou o Windows 7 suporta chaves fortes somente quando forem usados canais seguros. Essa restrição impede que uma relação de confiança entre qualquer domínio 4.0 Windows NT e qualquer domínio baseado no Windows Server 2008 R2. Além disso, essa restrição bloqueia a associação de domínio 4.0 Windows NT de computadores executando o Windows 7 ou Windows Server 2008 R2 e vice-versa.
    4. Motivos para desativar esta configuração

      O domínio contém computadores membro executando sistemas operacionais diferentes do Windows 2000, Windows XP ou Windows Server 2003.
    5. Nome simbólico:

      StrongKey
    6. Caminho do registro:
      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\RequireStrongKey (Reg_DWORD)
    7. Exemplos de problemas de compatibilidade

      Windows NT 4.0:Em computadores com Windows NT 4.0, redefinir canais seguros de relações de confiança entre Windows NT 4.0 e domínios do Windows 2000 com NLTEST falhará. Aparece uma mensagem de erro "Acesso negado":
      A relação de confiança relação entre o domínio primário e o domínio confiável Falha.

      Windows 7 e Server 2008 R2:Para Windows 7 e versões posteriores e Windows Server 2008 R2 e versões posteriores, esta configuração não é respeitada mais e a chave forte é usada sempre. Por isso, relações de confiança com domínios Windows NT 4.0 não funcionam mais.
  4. Membro do domínio: criptografar ou assinar digitalmente dados do canal seguro (sempre) os
    1. Plano de fundo
      • Ativando membro do domínio: criptografar ou assinar digitalmente dados do canal seguro (sempre) os impede o estabelecimento de um canal seguro com qualquer controlador de domínio que não pode assinar ou criptografar todos os dados de canal seguro. Para ajudar a proteger o tráfego de autenticação contra ataques de interceptação, ataques de repetição e outros tipos de ataques de rede, computadores baseados no Windows criam um canal de comunicação é conhecido como canal seguro de serviço Net Logon para autenticar contas de computador. Canais seguros também são usados quando um usuário em um domínio se conecta a um recurso de rede em um domínio remoto. Essa autenticação de vários domínios ou autenticação de passagem, permite que um computador baseado no Windows que tenha ingressado em um domínio que acesso ao banco de usuário conta dados em seu domínio e em quaisquer domínios confiáveis.
      • Para ativar o membro do domínio: criptografar ou assinar digitalmente dados do canal seguro (sempre) os a configuração em um computador membro, todos os controladores de domínio no domínio que pertence o membro devem ser capazes de assinar ou criptografar todos os dados de canal seguro. Isso significa que todos esses controladores de domínio devem estar executando o Windows NT 4.0 com Service Pack 6a (SP6a) ou posterior.
      • Ativando o membro do domínio: criptografar ou assinar digitalmente dados do canal seguro (sempre) os automaticamente permite que o membro do domínio: criptografar ou assinar digitalmente dados do canal seguro (quando possível) os configuração.
    2. Configuração de risco

      Ativando o membro do domínio: criptografar ou assinar digitalmente dados do canal seguro (sempre) os configuração de domínios em que nem todos os controladores de domínio podem assinar ou criptografar dados de canal seguro são uma configuração prejudicial.
    3. Razões para habilitar esta configuração

      Tráfego de rede não assinada é suscetível a ataques de interceptação, onde um invasor captura pacotes entre o servidor e o cliente e os modifica antes de encaminhá-los para o cliente. Quando esse comportamento ocorre em um servidor LDAP Lightweight Directory Access Protocol (), o invasor poderá levar um cliente a tomar decisões baseadas em registros falsos do diretório LDAP. Você pode diminuir o risco de ataque em uma rede corporativa implementando medidas de alta segurança física para ajudar a proteger a infra-estrutura de rede. Além disso, Implementando a segurança do protocolo Internet (IPSec) modo de cabeçalho de autenticação pode evitar ataques de interceptação. Este modo executa autenticação mútua e integridade do pacote para o tráfego IP.
    4. Motivos para desativar esta configuração
      • Computadores em domínios locais ou externos oferecem suporte a canais de segurança criptografada.
      • Nem todos os controladores de domínio no domínio possuem o níveis de revisão de pack de serviço apropriado para suportar criptografado seguro canais.
    5. Nome simbólico:

      StrongKey
    6. Caminho do registro:
      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\RequireSignOrSeal (REG_DWORD)
    7. Exemplos de problemas de compatibilidade
      • Windows NT 4.0: Computadores membro baseados no Windows 2000 não poderão participar Domínios Windows NT 4.0 e receberão a seguinte mensagem de erro:
        A conta não está autorizada a efetuar logon a partir estação.
        Para obter mais informações, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:
        281648Mensagem de erro: A conta não está autorizada a efetuar logon nesta estação
      • Windows NT 4.0:Domínios Windows NT 4.0 não poderão estabelecer uma relação de confiança de nível inferior com um domínio do Windows 2000 e receberão a seguinte mensagem de erro:
        A conta não está autorizada a efetuar logon a partir estação.
        Relações de confiança existentes de baixo nível também não podem autenticar os usuários do domínio confiável. Alguns usuários podem ter problemas de logon no domínio e podem receber uma mensagem de erro informando que o cliente não consegue localizar o domínio.
      • Windows XP:Clientes Windows XP que estão associados a domínios Windows NT 4.0 não poderão autenticar tentativas de logon e podem receber a seguinte mensagem de erro ou os seguintes eventos podem ser registrados no log de eventos:
        Windows não pode conectar ao domínio ou porque o controlador de domínio está inoperante ou não está disponível ou porque o computador conta não foi encontrada

        Evento 5723: A configuração da sessão do computador NomeDoComputador Falha ao autenticar. O nome da conta mencionado na segurança banco de dados NomeDoComputador. O seguinte erro ocorreu: acesso negado.

        Evento 3227: A configuração da sessão para o Windows NT ou o Windows controlador de domínio 2000 Nome do servidor para o domínio Nome de domínio porque Servidor Nome não oferece suporte a autenticação ou ao fechamento da sessão de logon de rede. Atualizar o controlador de domínio ou defina a entrada de Registro RequireSignOrSeal em Este computador para 0.

        Para obter mais informações, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:
        318266Um cliente Windows XP não pode efetuar logon no domínio um 4.0 Windows NT
      • Microsoft Network:Clientes de rede Microsoft receberão uma das seguintes mensagens de erro:
        Falha de logon: nome de usuário desconhecido ou inválido senha.
        Não há nenhuma chave de sessão de usuário para o sessão de logon especificada.
  5. Cliente de rede Microsoft: assinar digitalmente a comunicação (sempre)
    1. Plano de fundo

      Bloco de mensagens de servidor (SMB) é o protocolo de compartilhamento de recursos suportado por muitos sistemas operacionais da Microsoft. É a base de network basic input/output system (NetBIOS) e muitos outros protocolos. A assinatura SMB autentica o usuário e o servidor que hospeda os dados. Se um dos lados falhar o processo de autenticação, a transmissão de dados não ocorrerá.

      Habilitando a assinatura do SMB inicia durante a negociação do protocolo SMB. As diretivas de assinatura do SMB determinam se o computador sempre assina digitalmente comunicações do cliente.

      O protocolo de autenticação SMB do Windows 2000 suporta autenticação mútua. Autenticação mútua fecha um ataque "man-in-the-middle". Autenticação de mensagem do Windows 2000 SMB também suporta o protocolo de autenticação. Autenticação de mensagem ajuda a impedir ataques de mensagem ativa. Para dar essa autenticação, a assinatura SMB coloca uma assinatura digital em cada SMB. O cliente e o servidor verificam a assinatura digital.

      Para usar a assinatura SMB, você deve habilitar a assinatura SMB ou exigir assinatura SMB no cliente SMB e o servidor SMB. Se a assinatura SMB está habilitada no servidor, os clientes também serão habilitados para assinatura SMB usam o assinatura de pacote protocolo durante todas as sessões subseqüentes. Se a assinatura SMB é necessária em um servidor, um cliente não pode estabelecer uma sessão a menos que o cliente é habilitado ou exigido para assinatura SMB.

      Habilitar a assinatura digital em redes de alta segurança ajuda a evitar a representação de clientes e servidores. Esse tipo de representação é conhecido como seqüestro de sessão. Um invasor que tenha acesso à mesma rede que o cliente ou servidor usa ferramentas de seqüestro de sessão para interromper, finalizar ou roubar uma sessão em andamento. Um invasor poderia interceptar e modificar pacotes SMB não assinados, modificar o tráfego e encaminhá-lo para que o servidor pode executar ações indesejadas. Ou, o invasor pode representar o servidor ou cliente após uma autenticação legítima e obter acesso não autorizado a dados.

      O protocolo SMB é usado para o compartilhamento de arquivos e compartilhamento de impressão em computadores que executam o Windows 2000 Server, Windows 2000 Professional, Windows XP Professional ou Windows Server 2003 oferece suporte à autenticação mútua. Autenticação mútua fecha ataques de seqüestro de sessão e dá suporte à autenticação de mensagem. Portanto, ela impede ataques de interceptação. A assinatura SMB fornece essa autenticação colocando uma assinatura digital em cada SMB. O cliente e o servidor, em seguida, verificam a assinatura.

      Anotações
      • Como uma contramedida alternativa, você pode habilitar assinaturas digitais com IPSec para ajudar a proteger todo o tráfego de rede. Existem aceleradores baseados em hardware para criptografia de IPSec e assinatura que você pode usar para minimizar o impacto de desempenho de CPU do servidor. Existem aceleradores disponíveis para assinatura SMB.

        Para obter mais informações, consulte o Assinar digitalmente a comunicação do servidor capítulo no site MSDN da Microsoft.

        Configure a assinatura SMB por meio do Editor de objeto de diretiva de grupo porque uma alteração de um valor de registro local não tem efeito se houver uma diretiva de domínio de substituição.
      • No Windows 95, Windows 98 e Windows 98 Segunda edição, o Directory Services Client usa a assinatura SMB ao autenticar com servidores Windows Server 2003 usando a autenticação NTLM. No entanto, esses clientes não usam a assinatura SMB quando autenticam com estes servidores utilizando a autenticação NTLMv2. Além disso, servidores Windows 2000 não respondem a solicitações desses clientes assinatura SMB. Para obter mais informações, consulte o item 10: "segurança de rede: nível de autenticação Lan Manager."
    2. Configuração de risco

      A seguir é uma configuração prejudicial: deixando ambas as cliente de rede Microsoft: assinar digitalmente a comunicação (sempre) configuração e o cliente de rede Microsoft: assinar digitalmente a comunicação (se o servidor concordar) configuração definida como "Não definido" ou desabilitado. Essas configurações permitem que o redirecionador enviar senhas de texto sem formatação a servidores SMB não Microsoft que não oferecem suporte a criptografia de senha durante a autenticação.
    3. Razões para habilitar esta configuração

      Ativando cliente de rede Microsoft: assinar digitalmente a comunicação (sempre) requer que os clientes assinem o tráfego SMB ao contatar servidores que não exigem a assinatura SMB. Isso torna os clientes menos vulneráveis a ataques de seqüestro de sessão.
    4. Motivos para desativar esta configuração
      • Ativando cliente de rede Microsoft: assinar digitalmente a comunicação (sempre) impede que os clientes se comunicam com servidores de destino que não suportam a assinatura SMB.
      • Configurando computadores para ignorar todas as SMB não assinados comunicações impede que programas e sistemas operacionais da anterior Conectando-se.
    5. Nome simbólico:

      RequireSMBSignRdr
    6. Caminho do registro:
      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters\RequireSecuritySignature
    7. Exemplos de problemas de compatibilidade
      • Windows NT 4.0:Você não poderá redefinir o canal seguro de uma relação de confiança entre um domínio do Windows Server 2003 e um domínio Windows NT 4.0 usando NLTEST ou NETDOM e você receberá uma mensagem de erro "Acesso negado".
      • Windows XP:Copiando arquivos do Windows XP clientes para servidores baseados no Windows 2000 e servidores baseados no Windows Server 2003 podem levar mais tempo.
      • Não ser capaz de mapear uma unidade de rede de um cliente com essa configuração ativada e você receberá o seguinte erro mensagem:
        A conta não está autorizada a efetuar login Esta estação.
    8. Requisitos de reinicialização

      Reinicie o computador ou reinicie o serviço Estação de trabalho. Para fazer isso, digite os seguintes comandos no prompt de comando. Pressione Enter após digitar cada comando.
      NET stop workstation
      NET start workstation
  6. Servidor de rede Microsoft: assinar digitalmente a comunicação (sempre)
    1. Plano de fundo
      • Server Messenger Block (SMB) é o protocolo de compartilhamento de recursos suportado por muitos sistemas operacionais da Microsoft. É a base de network basic input/output system (NetBIOS) e muitos outros protocolos. A assinatura SMB autentica o usuário e o servidor que hospeda os dados. Se um dos lados falhar o processo de autenticação, a transmissão de dados não ocorrerá.

        Habilitando a assinatura do SMB inicia durante a negociação do protocolo SMB. As diretivas de assinatura do SMB determinam se o computador sempre assina digitalmente comunicações do cliente.

        O protocolo de autenticação SMB do Windows 2000 suporta autenticação mútua. Autenticação mútua fecha um ataque "man-in-the-middle". Autenticação de mensagem do Windows 2000 SMB também suporta o protocolo de autenticação. Autenticação de mensagem ajuda a impedir ataques de mensagem ativa. Para dar essa autenticação, a assinatura SMB coloca uma assinatura digital em cada SMB. O cliente e o servidor verificam a assinatura digital.

        Para usar a assinatura SMB, você deve habilitar a assinatura SMB ou exigir assinatura SMB no cliente SMB e o servidor SMB. Se a assinatura SMB está habilitada no servidor, os clientes também serão habilitados para assinatura SMB usam o assinatura de pacote protocolo durante todas as sessões subseqüentes. Se a assinatura SMB é necessária em um servidor, um cliente não pode estabelecer uma sessão a menos que o cliente é habilitado ou exigido para assinatura SMB.

        Habilitar a assinatura digital em redes de alta segurança ajuda a evitar a representação de clientes e servidores. Esse tipo de representação é conhecido como seqüestro de sessão. Um invasor que tenha acesso à mesma rede que o cliente ou servidor usa ferramentas de seqüestro de sessão para interromper, finalizar ou roubar uma sessão em andamento. Um invasor poderia interceptar e modificar pacotes não assinados do Gerenciador de largura de banda de sub-rede (SBM), modificar o tráfego e encaminhá-lo para que o servidor pode executar ações indesejadas. Ou, o invasor pode representar o servidor ou cliente após uma autenticação legítima e obter acesso não autorizado a dados.

        O protocolo SMB é usado para o compartilhamento de arquivos e compartilhamento de impressão em computadores que executam o Windows 2000 Server, Windows 2000 Professional, Windows XP Professional ou Windows Server 2003 oferece suporte à autenticação mútua. Autenticação mútua fecha ataques de seqüestro de sessão e dá suporte à autenticação de mensagem. Portanto, ela impede ataques de interceptação. A assinatura SMB fornece essa autenticação colocando uma assinatura digital em cada SMB. O cliente e o servidor, em seguida, verificam a assinatura.
      • Como uma contramedida alternativa, você pode habilitar assinaturas digitais com IPSec para ajudar a proteger todo o tráfego de rede. Existem aceleradores baseados em hardware para criptografia de IPSec e assinatura que você pode usar para minimizar o impacto de desempenho de CPU do servidor. Existem aceleradores disponíveis para assinatura SMB.
      • No Windows 95, Windows 98 e Windows 98 Segunda edição, o Directory Services Client usa a assinatura SMB ao autenticar com servidores Windows Server 2003 usando a autenticação NTLM. No entanto, esses clientes não usam a assinatura SMB quando autenticam com estes servidores utilizando a autenticação NTLMv2. Além disso, servidores Windows 2000 não respondem a solicitações desses clientes assinatura SMB. Para obter mais informações, consulte o item 10: "segurança de rede: nível de autenticação Lan Manager."
    2. Configuração de risco

      A seguir é uma configuração prejudicial: ativando o servidor de rede Microsoft: assinar digitalmente a comunicação (sempre) em servidores e controladores de domínio que são acessados por computadores incompatíveis com o Windows e computadores cliente baseados no sistema operacional de terceiros em domínios locais ou externos.
    3. Razões para habilitar esta configuração
      • Todos os computadores cliente que ativar esta configuração suporte a SMB diretamente por meio do registro ou a configuração de diretiva de grupo a assinatura. Em outras palavras, todos os computadores cliente que possuem esta configuração habilitada executar o Windows 95 com o cliente DS instalado, Windows 98, Windows NT 4.0, Windows 2000, Windows XP Professional ou Windows Server 2003.
      • Se servidor de rede Microsoft: assinar digitalmente a comunicação (sempre) está desativado, a assinatura SMB está desabilitada completamente. Completamente desativar toda a assinatura SMB deixa os computadores mais vulneráveis a seqüestro de sessão os ataques.
    4. Motivos para desativar esta configuração
      • A ativação dessa configuração pode causar mais lenta de cópia de arquivo e desempenho de rede em computadores cliente.
      • A ativação dessa configuração impedirá que os clientes que não é possível negociar a assinatura SMB se comuniquem com servidores e com o domínio controladores. Isso faz com que operações como associações de domínio, usuário e computador autenticação ou acesso à rede por programas falhar.
    5. Nome simbólico:

      RequireSMBSignServer
    6. Caminho do registro:
      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanManServer\Parameters\RequireSecuritySignature (REG_DWORD)
    7. Exemplos de problemas de compatibilidade
      • Windows 95:Clientes Windows 95 que não têm instalado o cliente de serviços de diretório (DS) autenticação de logon falhará e receberão a seguinte mensagem de erro:
        A senha de domínio que você forneceu não é corrigir ou acesso ao seu logon no servidor foi negado.
        Para obter mais informações, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:
        811497Mensagem de erro quando o cliente Windows 95 ou 4.0 Windows NT fizer logon no domínio do Windows Server 2003
      • Windows NT 4.0: Computadores cliente que estão executando versões do Windows NT 4.0 anteriores ao Service Pack 3 (SP3) será falha de autenticação de logon e será receba a seguinte mensagem de erro:
        O sistema não foi possível fazer logon. Verifique se seu nome de usuário e domínio estão corretos e digite sua senha novamente.
        Alguns servidores SMB não Microsoft suportam apenas trocas de senha não criptografada durante a autenticação. (Estas trocas também conhecidas como trocas de "texto sem formatação".) Windows NT 4.0 SP3 e versões posteriores, o redirecionador SMB não envia uma senha não criptografada durante a autenticação para um servidor SMB a menos que você adicionar uma entrada de registro específica.
        Para ativar senhas não criptografadas para o cliente SMB Windows NT 4.0 SP 3 e sistemas mais recentes, modifique o registro da seguinte maneira: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Rdr\Parameters
        Nome do valor: EnablePlainTextPassword
        Tipo de dados: REG_DWORD
        Dados: 1

        Para obter mais informações sobre tópicos relacionados, clique nos números abaixo para ler os artigos na Base de dados de Conhecimento da Microsoft:
        224287Mensagem de erro: erro de sistema 1240. A conta não está autorizada a efetuar logon nesta estação.
        166730 Senhas não criptografadas podem fazer com que o Service Pack 3 falhar para se conectar a servidores SMB
      • Windows Server 2003: Por padrão, as configurações de segurança nos controladores de domínio que executam o Windows Server 2003 são configuradas para ajudar a impedir as comunicações do controlador de domínio sejam interceptadas ou violadas por usuários mal-intencionados. Para os usuários se comuniquem com êxito com um controlador de domínio que executa o Windows Server 2003, os computadores cliente devem usar tanto a assinatura SMB e criptografia ou assinatura de tráfego de canal seguro. Por padrão, os clientes que executam o Windows NT 4.0 com Service Pack 2 (SP2) ou anterior instalado e clientes que executam o Windows 95 não têm a assinatura do pacote SMB. Portanto, esses clientes não poderá autenticar para um controlador de domínio baseado no Windows Server 2003.
      • As configurações de diretiva do Windows 2000 e Windows Server 2003: Dependendo de suas necessidades específicas de instalação e configuração, recomendamos que você defina as seguintes configurações de diretiva na menor entidade de escopo necessário na hierarquia de snap-in do Editor de diretiva de grupo do Console de gerenciamento Microsoft:
        • Opções de configurações de segurança de configuração de computador
        • Enviar senha não criptografada para conectar a servidores SMB de terceiros (essa configuração é para Windows 2000)
        • Cliente de rede Microsoft: enviar senha não criptografada para servidores SMB de terceiros (essa configuração é para Windows Server 2003)

        Observação Em alguns servidores CIFS de terceiros, como versões Samba mais antigas, é possível usar senhas criptografadas.
      • Os seguintes clientes são incompatíveis com o servidor de rede Microsoft: assinar digitalmente a comunicação (sempre) configuração:
        • Apple Computer, Inc., Mac OS X clientes
        • Microsoft MS-DOS (por exemplo, de clientes de rede Microsoft LAN Manager)
        • Microsoft Windows para Workgroups clientes
        • Clientes Microsoft Windows 95 sem o DS Cliente instalado
        • Computadores com Windows NT 4.0 Microsoft sem o SP3 ou posterior instalado
        • Clientes Novell Netware 6 CIFS
        • Clientes SAMBA SMB que não têm suporte para assinatura SMB
    8. Requisitos de reinicialização

      Reinicie o computador ou reinicie o serviço do servidor. Para fazer isso, digite os seguintes comandos no prompt de comando. Pressione Enter após digitar cada comando.
      NET stop server
      NET start server
  7. Acesso à rede: permitir conversão de SID/nome anônimo
    1. Plano de fundo

      A acesso à rede: permitir conversão de SID/nome anônimo configuração de segurança determina se um usuário anônimo pode solicitar Atributos do número de identificação (SID) de segurança de outro usuário.
    2. Configuração de risco

      Ativando o acesso à rede: permitir conversão de SID/nome anônimo configuração é uma configuração prejudicial.
    3. Razões para habilitar esta configuração

      Se a acesso à rede: permitir conversão de SID/nome anônimo configuração é desabilitados, anteriores sistemas operacionais ou aplicativos Talvez não consiga se comunicar com domínios do Windows Server 2003. Por exemplo, os seguintes sistemas operacionais, serviços ou aplicativos podem não funcionar:
      • Serviço de acesso remoto baseado em 4.0 Windows NT servidores
      • Microsoft SQL Server que estão executando em computadores baseados em 3. x do Windows NT ou com Windows NT 4.0
      • Serviço de acesso remoto que está executando em computadores baseados no Windows 2000 localizados em Windows NT 3. x ou em domínios de Windows NT 4.0
      • SQL Server que está executando em computadores baseados no Windows 2000 localizados em domínios do Windows NT 3. x ou em Windows NT 4.0
      • Usuários no domínio de recurso Windows NT 4.0 que desejam conceder permissões para acessar arquivos, pastas compartilhadas e objetos do registro de usuário contas de domínios de conta que contêm um domínio do Windows Server 2003 controladores
    4. Motivos para desativar esta configuração

      Se essa configuração estiver habilitada, um usuário mal-intencionado poderia usar o SID conhecido de administradores para obter o nome real da conta administrador interna, mesmo se a conta renomeada. Essa pessoa poderia então usar o nome da conta para iniciar um ataque de adivinhação de senha.
    5. Nome simbólico: N
    6. Caminho do registro: Nenhum. O caminho está especificado no código de interface do usuário.
    7. Exemplos de problemas de compatibilidade

      Windows NT 4.0:Computadores em domínios de recurso Windows NT 4.0 exibirá a mensagem de erro "Conta desconhecida" no Editor ACL se recursos, incluindo pastas compartilhadas, arquivos compartilhados e objetos de registro são protegidos com objetos de segurança que residem em domínios de conta que contêm controladores de domínio do Windows Server 2003.
  8. Acesso à rede: não permitir enumeração anônima de contas
    1. Plano de fundo
      • A acesso à rede: não permitir enumeração anônima de contas determina quais permissões adicionais serão concedidas para conexões anônimas ao computador. O Windows permite que usuários anônimos executem determinadas atividades, como enumeração de nomes de contas de gerente de contas de segurança (SAM) workstation e server e compartilhamentos de rede. Por exemplo, um administrador pode usar isso para conceder acesso a usuários em um domínio confiável que não mantenha uma confiança recíproca. Depois que uma sessão é estabelecida, um usuário anônimo pode ter o mesmo acesso que é concedido a todos grupo com base na configuração na acesso à rede: Let Everyone permissões aplicam a usuários anônimos configuração ou a lista de controle de acesso discricional (DACL) do objeto.

        Geralmente, conexões anônimas são solicitadas por versões anteriores de clientes (clientes de nível inferior) durante a instalação da sessão SMB. Nesses casos, um rastreamento de rede mostra que a identificação de processo SMB (PID) é que o redirecionador do cliente como 0xFEFF no Windows 2000 ou 0xCAFE no Windows NT. RPC também pode tentar fazer conexões anônimas.
      • ImportanteEssa configuração não tem impacto no domínio controladores. Em controladores de domínio, esse comportamento é controlado pela presença de "NT AUTHORITY\ANONYMOUS LOGON" no "Acesso compatível anterior ao Windows 2000".
      • No Windows 2000, uma configuração semelhante chamada Restrições adicionais para conexões anônimas gerencia o
        RestrictAnonymous
        valor do registro. O local desse valor é o seguinte
        HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
        Para obter mais informações sobre o valor do Registro RestrictAnonymous, clique nos números abaixo para ler os artigos na Base de dados de Conhecimento da Microsoft:
        246261Como usar o valor do Registro RestrictAnonymous no Windows 2000
        143474 Restringindo informações disponíveis aos usuários de logon anônimo
    2. Configurações de risco

      Ativando o acesso à rede: não permitir enumeração anônima de contas configuração é uma configuração prejudicial de uma perspectiva de compatibilidade. Desativá-la é uma configuração prejudicial de uma perspectiva de segurança.
    3. Razões para habilitar esta configuração

      Um usuário não autorizado poderia listar nomes de conta anonimamente e usar as informações para tentar adivinhar senhas ou executar ataques de engenharia social . Engenharia social é um jargão que significa enganar pessoas revelem suas senhas ou algum tipo de informação de segurança.
    4. Motivos para desativar esta configuração

      Se essa configuração estiver habilitada, é impossível estabelecer relações de confiança com domínios Windows NT 4.0. Essa configuração também causa problemas com clientes de nível inferior (como clientes Windows NT 3.51 e Windows 95) que estão tentando usar recursos no servidor.
    5. Nome simbólico:


      RestrictAnonymousSAM
    6. Caminho do registro:
      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\RestrictAnonymousSAM (Reg_DWORD)
    7. Exemplos de problemas de compatibilidade
    • SMS Network Discovery não poderá obter informações do sistema de operacional e gravará "Desconhecido" Propriedade OperatingSystemNameandVersion.
    • Windows 95, Windows 98:Clientes Windows 95 e Windows 98 não poderão alterar suas senhas.
    • Windows NT 4.0:Windows NT computadores membro 4.0 não poderão ser autenticados.
    • Windows 95, Windows 98:Computadores baseados em Windows 95 e Windows 98 não poderão ser autenticados por controladores de domínio do Microsoft.
    • Windows 95, Windows 98:Usuários em computadores baseados em Windows 95 e Windows 98 não poderão alterar as senhas de suas contas de usuário.
  9. Acesso à rede: não permitir enumeração anônima de contas e compartilhamentos
    1. Plano de fundo
      • A acesso à rede: não permitir enumeração anônima de contas e compartilhamentos (também conhecida como RestrictAnonymous) determina se anônimo enumeração de contas de segurança Compartilhamentos e contas manager (SAM) é permitido. O Windows permite que usuários anônimos realizar determinadas atividades, como enumeração de nomes de contas de domínio (usuários, computadores e grupos) e compartilhamentos de rede. Isso é conveniente para exemplo, quando um administrador deseja conceder acesso a usuários em um confiável domínio que não mantenha uma confiança recíproca. Se você não deseja permitir a enumeração anônima de contas SAM e compartilhamentos, ativar essa configuração.
      • No Windows 2000, uma configuração semelhante chamada Restrições adicionais para conexões anônimas gerencia o
        RestrictAnonymous
        valor do registro. O local desse valor é o seguinte:
        HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
    2. Configuração de risco

      Ativando o acesso à rede: não permitir enumeração anônima de contas e compartilhamentos configuração é uma configuração prejudicial.
    3. Razões para habilitar esta configuração
      • Ativando o acesso à rede: não permitir enumeração anônima de contas e compartilhamentos impede a enumeração de compartilhamentos por usuários e contas SAM e os computadores que estão usando contas anônimas.
    4. Motivos para desativar esta configuração
      • Se essa configuração estiver habilitada, um usuário não autorizado poderia listar nomes de conta anonimamente e usar as informações para tentar adivinhar senhas ou executar ataques de engenharia social . Engenharia social é um jargão que significa enganar pessoas revelem suas senha ou algum formulário de informações de segurança.
      • Se essa configuração estiver habilitada, será impossível estabelecer relações de confiança com domínios Windows NT 4.0. Esta configuração também causará problemas com clientes de nível inferior, como clientes Windows NT 3.51 e Windows 95 que está tentando usar recursos no servidor.
      • Será impossível conceder acesso aos usuários de domínios de recurso, porque os administradores do domínio confiante não poderão enumerar listas de contas no outro domínio. Os usuários que acessam anonimamente servidores de impressão e arquivo não poderá listar os recursos de rede compartilhados nesses servidores. Os usuários devem autenticar antes que possam exibir as listas de pastas e impressoras compartilhadas.
    5. Nome simbólico:

      RestrictAnonymous
    6. Caminho do registro:
      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\RestrictAnonymous
    7. Exemplos de problemas de compatibilidade
      • Windows NT 4.0: Os usuários não poderão alterar suas senhas de Windows NT 4.0 workstations quando RestrictAnonymous está ativada em controladores de domínio dos usuários. Para obter mais informações, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:
        198941Usuários não podem alterar a senha ao fazer logon
      • Windows NT 4.0:Adicionar usuários ou grupos globais de domínios confiáveis do Windows 2000 a grupos locais Windows NT 4.0 no Gerenciador de usuários falhará e a seguinte mensagem de erro será exibida:
        Existem atualmente não há servidores de logon disponível para a solicitação de logon.
        Para obter mais informações, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:
        296405Valor do Registro "RestrictAnonymous" pode quebrar a relação de confiança para um domínio do Windows 2000
      • Windows NT 4.0:Windows NT computadores 4.0 não poderá ingressar em domínios durante a instalação ou usando a interface de usuário de associação de domínio.

        Para obter mais informações, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:
        184538Mensagem de erro: não foi possível localizar um controlador de domínio
      • Windows NT 4.0:Estabelecer uma relação de confiança de nível inferior com domínios de recurso Windows NT 4.0 falhará. A seguinte mensagem de erro será exibida quando RestrictAnonymous está habilitado no domínio confiável:
        Não foi possível Localize o controlador de domínio para este domínio.
        Para obter mais informações, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:
        178640Não foi possível localizar o controlador de domínio ao estabelecer uma relação de confiança
      • Windows NT 4.0:Os usuários que fizerem logon em computadores baseados em Windows NT 4.0 Terminal Server serão mapeado para o diretório base padrão em vez do diretório base é definido no Gerenciador de usuários para domínios.

        Para obter mais informações, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:
        236185Caminhos de pasta base e perfis de usuário do Terminal Server são ignorados após a aplicação do SP4 ou posterior
      • Windows NT 4.0:Windows NT 4.0 controladores de domínio backup (BDCs) não poderá iniciar o serviço Net Logon, obter uma lista de localizadores de backup ou sincronizar o banco de dados SAM do Windows 2000 ou do Windows Server 2003 controladores de domínio no mesmo domínio.

        Para obter mais informações, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:
        293127O serviço Net Logon de um BDC do Windows NT 4.0 não funciona em um domínio do Windows 2000
      • Windows 2000:Computadores membro baseados no Windows 2000 em domínios Windows NT 4.0 não poderão exibir impressoras em domínios externos se a Nenhum acesso sem permissões anônimas explícitas estiver habilitada na diretiva de segurança local do cliente computador.

        Para obter mais informações, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:
        280329Usuário não pode gerenciar ou exibir as propriedades da impressora
      • Windows 2000:Usuários de domínio do Windows 2000 não poderão adicionar impressoras de rede do Active Directory; No entanto, eles poderão adicionar impressoras após selecioná-los no modo de exibição de árvore.

        Para obter mais informações, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:
        318866Clientes Outlook não é possível exibir a lista de endereços global após a instalação do Security Rollup Package 1 (SRP1) no servidor de catálogo global
      • Windows 2000:Em computadores baseados no Windows 2000, no Editor ACL não poderá adicionar usuários ou grupos globais de domínios confiáveis de Windows NT 4.0.

        Para obter mais informações, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:
        296403O valor RestrictAnonymous interrompe a relação de confiança em um ambiente de domínio misto
      • ADMT versão 2:Migração de senha para contas de usuário migradas entre florestas com Active Directory migração ferramenta (ADMT) versão 2 falhará.

        Para obter mais informações, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:
        322981Como solucionar problemas de migração de senha ADMTv2
      • Clientes outlook:Lista de endereços global aparecerá vazia para clientes Microsoft Exchange Outlook.

        Para obter mais informações, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:
        318866Clientes Outlook não é possível exibir a lista de endereços global após a instalação do Security Rollup Package 1 (SR) no servidor de catálogo global
        321169 Desempenho lento de SMB ao copiar arquivos do Windows XP para um controlador de domínio do Windows 2000
      • SMS:Descoberta de rede do Microsoft Systems Management Server (SMS) não poderá obter as informações do sistema operacional. Portanto, ele gravará "Desconhecido" na propriedade OperatingSystemNameandVersion da propriedade SMS DDR do registro de dados de descoberta (DDR).

        Para obter mais informações, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:
        229769Como o Discovery Data Manager determina quando gerar uma solicitação de configuração do cliente
      • SMS: Quando você usar o Assistente de usuário administrador SMS para procurar usuários e grupos, nenhum usuário ou grupo será listado. Além disso, os clientes avançados não podem se comunicar com o ponto de gerenciamento. É necessário o acesso anônimo no ponto de gerenciamento.

        Para obter mais informações, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:
        302413Não há usuários ou grupos listados no Assistente de usuário administrador
      • SMS: Quando você estiver usando o recurso de descoberta de rede no SMS 2.0 e na instalação de cliente remoto com a opção de descoberta de rede topologia, cliente e sistemas operacionais cliente ativada, os computadores podem ser descobertos mas não pode ser instalado.

        Para obter mais informações, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:
        311257Recursos não serão descobertos se conexões anônimas são desativadas
  10. Segurança de rede: nível de autenticação Lan Manager
    1. Plano de fundo

      Autenticação do LAN Manager (LM) é o protocolo usado para autenticar clientes Windows para operações de rede, incluindo associações de domínios, acessar recursos de rede e autenticação de usuário ou computador. O nível de autenticação do LM determina qual protocolo de autenticação de desafio/resposta é negociado entre o cliente e os computadores servidor. Especificamente, o nível de autenticação do LM determina quais protocolos de autenticação que o cliente tentará negociar ou que o servidor aceitará. O valor definido para LmCompatibilityLevel determina qual protocolo de autenticação de desafio/resposta é usado para logons de rede. Esse valor afeta o nível de protocolo de autenticação usado pelos clientes, o nível de segurança de sessão negociado e o nível de autenticação aceito por servidores.

      Configurações possíveis incluem:
      ValorConfiguraçãoDescrição
      0 Enviar respostas LM e NTLM &Os clientes usam autenticação LM e NTLM e nunca usam segurança da sessão NTLMv2. Controladores de domínio aceitam autenticação LM, NTLM e NTLMv2.
      1Enviar LM e NTLM & - usar segurança de sessão NTLMv2 se negociadoOs clientes usam autenticação LM e NTLM e usam segurança da sessão NTLMv2 se o servidor oferece suporte. Controladores de domínio aceitam autenticação LM, NTLM e NTLMv2.
      2Enviar somente resposta NTLMOs clientes usam somente autenticação NTLM e usam segurança da sessão NTLMv2 se o servidor oferece suporte. Controladores de domínio aceitam autenticação LM, NTLM e NTLMv2.
      3Enviar somente resposta NTLMv2Os clientes usam somente autenticação NTLMv2 e usam segurança da sessão NTLMv2 se o servidor oferece suporte. Controladores de domínio aceitam autenticação LM, NTLM e NTLMv2.
      4Enviar somente resposta NTLMv2 / recusar LMOs clientes usam somente autenticação NTLMv2 e usam segurança da sessão NTLMv2 se o servidor oferece suporte. Controladores de domínio recusam LM e aceitam somente autenticação NTLM e NTLMv2.
      5Enviar somente resposta NTLMv2 / recusar LM e NTLM &Os clientes usam somente autenticação NTLMv2 e usam segurança da sessão NTLMv2 se o servidor oferece suporte. Controladores de domínio recusam LM e NTLM e aceitam somente autenticação NTLMv2.
      Observação No Windows 95, Windows 98 e Windows 98 Segunda edição, o Directory Services Client usa a assinatura SMB ao autenticar com servidores Windows Server 2003 usando a autenticação NTLM. No entanto, esses clientes não usam a assinatura SMB quando autenticam com estes servidores utilizando a autenticação NTLMv2. Além disso, servidores Windows 2000 não respondem a solicitações desses clientes assinatura SMB.

      Verificar o nível de autenticação LM: Você deve alterar a diretiva de servidor para permitir NTLM ou configurar o computador cliente para oferecer suporte ao NTLMv2.

      Se a diretiva é definida como Enviar somente respostas NTLMv2\recusar LM e NTLM & (5) no computador de destino que você deseja se conectar, diminuir a configuração do computador ou definir a segurança para a mesma configuração no computador de origem que você está se conectando.

      Encontre o local correto onde você pode alterar o LAN manager nível de autenticação para definir o cliente e o servidor no mesmo nível. Após localizar a diretiva de configuração o LAN manager nível de autenticação, se você deseja se conectar e para computadores que estejam executando versões anteriores do Windows, reduza o valor para pelo menos (1) Enviar LM & NTLM - use NTLM versão 2 segurança de sessão se negociado. Um efeito de configurações incompatíveis é que, se o servidor requer NTLMv2 (valor 5), mas o cliente está configurado para usar o LM e NTLMv1 único (valor 0), o usuário que tenta a autenticação enfrenta uma falha de logon com uma senha incorreta e que incrementa a contagem de senha incorreta. Se saída de bloqueio de conta estiver configurada, o usuário eventualmente pode ser bloqueado.

      Por exemplo, talvez você precise procurar no controlador de domínio ou talvez você precise examinar as diretivas do controlador de domínio.

      Verificar o controlador de domínio

      Observação Talvez você precise repetir o procedimento a seguir em todos os controladores de domínio.
      1. Clique em Iniciar, aponte para Programase clique em Ferramentas administrativas.
      2. Em Configurações de segurança local, expanda Diretivas locais.
      3. Clique em Opções de segurança.
      4. Clique duas vezes Segurança de rede: Nível LAN manager authenticatione clique em um valor na lista.

      Se a configuração efetiva e a configuração Local forem iguais, a diretiva foi alterada neste nível. Se as configurações forem diferentes, você deve verificar a diretiva do controlador de domínio para determinar se o segurança de rede: nível de autenticação LAN manager está definida. Se ele não estiver definido, examine as diretivas do controlador de domínio.

      Examinardiretivas do controlador de domínio
      1. Clique em Iniciar, aponte para Programase clique em Ferramentas administrativas.
      2. No Segurança de controlador de domínio política, expanda Configurações de segurançae em seguida, expanda Diretivas locais.
      3. Clique em Opções de segurança.
      4. Clique duas vezes em segurança de rede: nível de autenticação LAN managere clique em um valor na lista.

      Observação
      • Também convém verificar as diretivas que estão vinculadas no nível do site, o nível de domínio ou unidade organizacional de nível (UO) para determinar onde você deve configurar o nível de autenticação LAN manager.
      • Se você implementar uma configuração de diretiva de grupo como a diretiva de domínio padrão, a diretiva é aplicada a todos os computadores no domínio.
      • Se você implementar uma configuração de diretiva de grupo como a diretiva do controlador de domínio padrão, a diretiva se aplica somente a servidores na UO do controlador de domínio.
      • É uma boa idéia definir o nível de autenticação do LAN manager na menor entidade de escopo necessário na hierarquia de aplicação de diretiva.

      Atualize a diretiva após fazer alterações. (Se a alteração é feita no nível de configurações de segurança local, a alteração é imediata. No entanto, você deve reiniciar os clientes antes de testar.)

      Por padrão, as configurações de diretiva de grupo são atualizadas nos controladores de domínio a cada cinco minutos. Para forçar imediatamente a atualização das configurações de diretiva no Windows 2000 ou posterior, use o comando gpupdate .

      O comando gpupdate /force atualiza configurações de diretiva de grupo baseadas no serviço de diretório do Active Directory, incluindo as configurações de segurança e configurações de diretiva de grupo locais. Este comando substitui a opção /refreshpolicy do agora obsoleto o comando secedit .

      O comando gpupdate usa a seguinte sintaxe:
      gpupdate [/target: {computador|usuário}] [/force] [/wait:valor] [/logoff] [/boot]

      Aplica o objeto de diretiva do novo grupo (GPO) usando o comando gpupdate para reaplicar manualmente todas as configurações de diretiva. Para fazer isso, digite o seguinte no prompt de comando e pressione Enter:
      GPUpdate /Force
      Examine o log de eventos do aplicativo para verificar se a configuração de diretiva foi aplicada com êxito.

      No Windows XP e Windows Server 2003, você pode usar o snap-in RSoP para ver a configuração efetiva. Para isso, clique emIniciar, clique em Executar, tipo msce clique em OK.

      Se o problema persistir depois de fazer a alteração de diretiva, reinicie o servidor baseado no Windows e verifique se o problema foi resolvido.

      Observação Se você tiver vários controladores de domínio baseado no Windows 2000, controladores de domínio baseado no Windows Server 2003 ou ambos, talvez você precise duplicar o Active Directory para certificar-se de que esses controladores de domínio têm alterações atualizadas imediatamente.

      Como alternativa, a configuração pode parecer ser definida como a menor configuração na diretiva de segurança local. Se você pode aplicar a configuração através de um banco de dados de segurança, também pode definir o nível de autenticação LAN manager no registro editando a entrada LmCompatibilityLevel na seguinte subchave do registro:
      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
      Windows Server 2003 tem uma nova configuração padrão para usar somente NTLMv2. Por padrão, os controladores de domínio baseado no Windows 2000 Server SP3 e Windows Server 2003 tem habilitado o "servidor de rede Microsoft: assinar digitalmente a comunicação (sempre)" política. Esta configuração requer que o servidor SMB execute o pacote SMB.Foram feitas alterações para o Windows Server 2003 como controladores de domínio, servidores de arquivos, servidores de infra-estrutura de rede e servidores Web em qualquer organização requerem configurações diferentes maximizar sua segurança.

      Se você deseja implementar a autenticação NTLMv2 em sua rede, verifique se que todos os computadores no domínio estão configurados para usar esse nível de autenticação. Se você aplicar o Active Directory Client Extensions para Windows 95 ou Windows 98 e Windows NT 4.0, as extensões de cliente usam os recursos de autenticação aprimorada disponíveis no NTLMv2. Porque os computadores cliente que estejam executando qualquer um dos seguintes sistemas operacionais não são afetados por objetos de diretiva de grupo do Windows 2000, você terá que configurar manualmente estes clientes:
      • Microsoft Windows NT 4.0
      • Microsoft Windows Millennium Edition
      • Microsoft Windows 98
      • Microsoft Windows 95
      Observação Se você habilitar o Segurança de rede: não armazenar o valor de hash do LAN manager na próxima alteração de senha ou definir o NoLMHash chave de registro, clientes baseados no Windows 98 e Windows 95 que não tenham o Directory Services Client instalado não pode efetuar logon no domínio após uma alteração de senha.

      Muitos servidores CIFS de terceiros, como o Novell Netware 6, não estão cientes do NTLMv2 e usam somente NTLM. Portanto, níveis maiores que 2 não permitem conectividade.

      Para obter mais informações sobre como configurar manualmente o nível de autenticação LAN manager, clique nos números abaixo para ler os artigos na Base de dados de Conhecimento da Microsoft:
      147706Como desabilitar a autenticação LM no Windows NT
      175641 LMCompatibilityLevel e seus efeitos
      299656 Como impedir que o Windows armazene um hash do LAN manager da sua senha no Active Directory e bancos de dados SAM locais
      312630 O Outlook continua a solicitar credenciais de logon
      Para obter mais informações sobre níveis de autenticação LM, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:
      239869Como habilitar a autenticação NTLM 2
    2. Configurações de risco

      A seguir estão as definições de configuração prejudiciais:
      • Configurações não restritivas que enviam senhas em texto não criptografado e que recusam negociação NTLMv2
      • Configurações restritivas que impedem incompatível clientes ou controladores de domínio de negociar um protocolo de autenticação comum
      • Exigir autenticação NTLMv2 em computadores membro e controladores de domínio que estão executando versões do Windows NT 4.0 anterior ao Service Pack 4 (SP4)
      • Exigir autenticação NTLMv2 no Windows 95 clientes ou clientes Windows 98 que não possuem o diretório do Windows Services Client instalado.
      • Se você clicar para selecionar o Exigir segurança de sessão NTLMv2 a caixa de seleção no Editor de diretiva do grupo do Microsoft Management Console snap-in no Windows Server 2003 ou Windows 2000 Service Pack 3 em computador e você diminuir o nível de autenticação LAN manager para 0, as duas configurações de conflito e pode receber a seguinte mensagem de erro no arquivo secpol. msc ou no arquivo gpedit. msc:
        Windows não pode abrir o banco de dados de diretiva local. Ocorreu um erro desconhecido ao tentar abrir o banco de dados.
        Para obter mais informações sobre a ferramenta de análise e configuração de segurança, consulte o Windows 2000 ou os arquivos de Ajuda do Windows Server 2003.

        Para obter mais informações sobre como analisar os níveis de segurança no Windows 2000 e no Windows Server 2003, clique nos números abaixo para ler os artigos na Base de dados de Conhecimento da Microsoft:
        313203Como analisar a segurança do sistema no Windows 2000
        816580 Como analisar a segurança do sistema no Windows Server 2003
    3. Motivos para modificar essa configuração
      • Você deseja aumentar comum menor protocolo de autenticação suportado por clientes e controladores de domínio sua organização.
      • Onde a autenticação segura é uma empresa requisito, você deseja impedir a negociação de LM e o NTLM protocolos.
    4. Motivos para desativar esta configuração

      Cliente ou requisitos de autenticação de servidor ou ambos, aumentaram a ponto onde a autenticação de um protocolo comum não pode ocorrer.
    5. Nome simbólico:

      LmCompatibilityLevel
    6. Caminho do registro:
      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\LmCompatibilityLevel
    7. Exemplos de problemas de compatibilidade
      • Windows Server 2003:Por padrão, as respostas enviar NTLM do Windows Server 2003 NTLMv2 configuração está ativada. Portanto, o Windows Server 2003 recebe a mensagem de erro "Acesso negado" após a instalação inicial quando você tenta se conectar a um cluster de Windows NT 4.0 ou servidores LanManager v 2.1, como o OS/2 Lanserver. Esse problema também ocorre se você tentar conectar-se de um versão anterior do cliente a um servidor baseado no Windows Server 2003.
      • Instalar o Windows 2000 Security Rollup Package 1 (SRP1).SRP1 força NTLM versão 2 (NTLMv2). Esse pacote cumulativo de atualizações foi lançado após o lançamento do Windows 2000 Service Pack 2 (SP2). Para obter mais informações sobre o SRP1, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:

        311401 Windows 2000 Security Rollup Package 1, janeiro de 2002
      • Windows 7 e Windows Server 2008 R2: muitos servidores CIFS de terceiros, como servidores Novell Netware 6 ou Samba baseado em Linux, não conhecem NTLMv2 e usam somente NTLM. Portanto, níveis maiores do que "2" não permitem conectividade. Agora nesta versão do sistema operacional, o LmCompatibilityLevel padrão foi alterado para "3". Assim, quando você atualiza o Windows, esses servidores de terceiros podem parar de funcionar.
      • Clientes Microsoft Outlook podem ser solicitados para credenciais, mesmo que eles já estiver conectados ao domínio. Quando os usuários fornecem suas credenciais, eles recebem a seguinte mensagem de erro: o Windows 7 e Windows Server 2008 R2
        As credenciais de logon fornecidas estavam incorretas. Verifique se seu nome de usuário e domínio estão corretos e digite sua senha novamente.
        Quando você inicia o Outlook, você pode ser solicitado suas credenciais, mesmo se a configuração de segurança de rede de Logon é definida como passagem ou autenticação de senha. Após digitar suas credenciais corretas, você pode receber a seguinte mensagem de erro:
        As credenciais de logon fornecidas estavam incorretas.
        Um rastreamento do Monitor de rede pode mostrar que o catálogo global emitiu uma falha de remote procedure call (RPC) com um status de 0x5. Um status de 0x5 significa "Acesso negado".
      • Windows 2000:Uma captura do Monitor de rede pode mostrar os seguintes erros NetBIOS através de sessão de bloco (SMB) de mensagem do servidor TCP/IP (NetBT):
        Erro SMB R Search Directory Dos, identificador de usuário inválido (91) (5) ACCESS_DENIED (109) STATUS_LOGON_FAILURE
      • Windows 2000: Se um domínio do Windows 2000 com NTLMv2 nível 2 ou posterior é confiável por um domínio Windows NT 4.0, o recurso de computadores membro baseados no Windows 2000 domínio pode enfrentar erros de autenticação.

        Para obter mais informações, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:
        305379Problemas de autenticação no Windows 2000 com níveis NTLM 2 acima de 2 em um domínio Windows NT 4.0
      • Windows 2000 e Windows XP: Por padrão, Windows 2000 e Windows XP definem a opção de diretiva de segurança Local LAN Manager Authentication nível para 0. Uma configuração de 0 significa "Enviar LM e NTLM respostas."

        Observação Windows NT clusters de 4.0 deve usar LM para administração.
      • Windows 2000: Cluster do Windows 2000 não autentica um nó se ambos os nós fazem parte de um Windows NT 4.0 Service Pack 6a (SP6a) domínio.

        Para obter mais informações, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:
        305379Problemas de autenticação no Windows 2000 com níveis NTLM 2 acima de 2 em um domínio Windows NT 4.0
      • A ferramenta de bloqueio do IIS (HiSecWeb) define o valor LMCompatibilityLevel como 5 e o valor RestrictAnonymous em 2.
      • Serviços para Macintosh

        Módulo de autenticação de usuário (UAM): O Microsoft UAM (módulo de autenticação do usuário) fornece um método para criptografar senhas que você usa para fazer logon servidores Windows AFP (AppleTalk Filing Protocol). Fornece de módulo de autenticação de usuário (UAM) Apple apenas mínimo ou sem criptografia. Portanto, sua senha poderia ser facilmente interceptada na LAN ou na Internet. Embora o UAM não seja obrigatório, ele fornece autenticação criptografada para servidores Windows 2000 que executam serviços para Macintosh. Esta versão inclui suporte para autenticação criptografada NTLMv2 de 128 bits e uma versão do MacOS X 10.1 compatível.

        Por padrão, os serviços do Windows Server 2003 para Macintosh permite a autenticação do Microsoft.

        Para obter mais informações, clique nos números abaixo para ler os artigos na Base de dados de Conhecimento da Microsoft:
        834498Cliente Macintosh não pode se conectar a serviços para Mac no Windows Server 2003
        838331 Usuários do Mac OS X não é possível abrir pastas de Macintosh compartilhada em um servidor baseado no Windows Server 2003
      • Windows Server 2008, Windows Server 2003, Windows XP e Windows 2000: Se você configurar o valor LMCompatibilityLevel como 0 ou 1 e depois configurar o valor NoLMHash como 1, aplicativos e componentes podem ser negadas pelo NTLM. Esse problema ocorre porque o computador está configurado para habilitar LM mas não para usar senhas armazenadas LM.

        Se você configurar o valor NoLMHash como 1, você deve configurar o valor LMCompatibilityLevel como 2 ou superior.
  11. Segurança de rede: requisitos de assinatura de cliente LDAP
    1. Plano de fundo

      O segurança de rede: requisitos de assinatura de cliente LDAP determina o nível de assinatura de dados solicitado em nome de clientes que emitem LDAP Lightweight Directory Access Protocol () BIND solicitações da seguinte maneira:
      • Nenhum: A solicitação LDAP BIND é emitida com especificado do chamador opções.
      • Negociar assinatura: se o Secure Sockets Layer/Transport Layer Security (SSL/TLS) não foi iniciado, a solicitação LDAP BIND será iniciada com dados LDAP opção de assinatura definida em adição às opções especificadas pelo chamador. Se tiver de SSL/TLS foi iniciado, a solicitação LDAP BIND será iniciada com especificado do chamador opções.
      • Requer assinatura: é o mesmo que Negociar assinatura. No entanto, se o servidor LDAP intermediário saslBindInProgress resposta não indicar que a assinatura de tráfego LDAP é necessária, o chamador é disse que o pedido do comando LDAP BIND falhou.
    2. Configuração de risco

      Ativando o segurança de rede: requisitos de assinatura de cliente LDAP configuração é uma configuração prejudicial. Se você definir o servidor para requerer assinaturas LDAP, você também deve configurar a assinatura LDAP no cliente. Não configurar o cliente para usar assinaturas LDAP impedirá a comunicação com o servidor. Isso faz a autenticação do usuário, configurações de diretiva de grupo, scripts de logon e outros recursos de falha.
    3. Motivos para modificar essa configuração

      Tráfego de rede não assinada é suscetível a ataques de interceptação de onde um intruso captura pacotes entre o cliente e os servidores, modifica e encaminha para o servidor. Quando isso ocorre em um servidor LDAP, um invasor pode causar um servidor a responder com base em falsas consultas do cliente LDAP. Você pode reduzir este risco em uma rede corporativa implementando medidas de alta segurança física para ajudar a proteger a infra-estrutura de rede. Além disso, você pode ajudar a evitar todos os tipos de ataques de interceptação, exigindo assinaturas digitais em todos os pacotes de rede por meio de cabeçalhos de autenticação IPSec.
    4. Nome simbólico:

      LDAPClientIntegrity
    5. Caminho do registro:
      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LDAP\LDAPClientIntegrity
  12. Log de eventos: Segurança tamanho máximo do log
    1. Plano de fundo

      O Log de eventos: tamanho máximo do log de segurança configuração de segurança especifica o tamanho máximo de eventos de segurança log. Esse log tem um tamanho máximo de 4 GB. Para localizar essa configuração, expanda Configurações do Windowse em seguida, expanda Segurança Configurações.
    2. Configurações de risco

      A seguir estão as definições de configuração prejudiciais:
      • Restringir o tamanho do log de segurança e a segurança método de retenção de log quando o auditoria: desligar o sistema imediatamente se não for possível registrar auditorias de segurança habilitada. Consulte a "auditoria: desligar o sistema imediatamente se não for possível registrar auditorias de segurança" seção deste artigo para obter mais detalhes.
      • Restringir o tamanho do log de segurança assim que a segurança eventos de interesse sejam substituídos.
    3. Razões para aumentar esta configuração

      Requisitos comerciais e de segurança podem exigir que você aumentar o tamanho do log de segurança para tratar os detalhes de log de segurança adicionais ou reter logs de segurança para um período de tempo.
    4. Razões para diminuir esta configuração

      Logs de Visualizar eventos são arquivos de memória mapeada. O máximo tamanho de um log de eventos é restringido pela quantidade de memória física do computador local e pela memória virtual que está disponível para o log de eventos processo. Aumentando o tamanho do log, além da quantidade de memória virtual disponível em Visualizar eventos não aumenta o número de entradas de log são mantida.
    5. Exemplos de problemas de compatibilidade

      Windows 2000:São computadores que estão executando versões do Windows 2000 anteriores ao Service Pack 4 (SP4) pode parar o log de eventos no log de eventos antes de alcançar o tamanho que é especificado na configuração de tamanho máximo do log no Visualizador de eventos se a opção não substituir eventos (Limpar log manualmente) estiver ativada.

      Para obter mais informações, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:
      312571O log de eventos pára de log de eventos antes de atingir o tamanho máximo do log
  13. Log de eventos: Reter o log de segurança
    1. Plano de fundo

      O Log de eventos: Reter log de segurança configuração de segurança determina o método de "empacotamento" do log de segurança. Para localizar essa configuração, expanda Configurações do Windows, e, em seguida, expanda Configurações de segurança.
    2. Configurações de risco

      A seguir estão as definições de configuração prejudiciais:
      • Deixar de manter todos os eventos de segurança registrados antes eles são substituídos
      • Configurar o tamanho máximo do log de segurança configuração muito pequena para que os eventos de segurança sobrescrito
      • Restringir o tamanho do log de segurança e retenção método enquanto o auditoria: desligar o sistema imediatamente se não for possível registrar auditorias de segurança segurança habilitada
    3. Razões para habilitar esta configuração

      Habilitar esta configuração somente se você selecionar o Substituir eventos por dias método de retenção. Se você usar um sistema de correlação de eventos controla eventos, certifique-se de que o número de dias é pelo menos três vezes a freqüência de pesquisa. Faça isso para permitir que os ciclos de pesquisa com falha.
  14. Acesso à rede: permitir que todos as permissões aplicam a usuários anônimos
    1. Plano de fundo

      Por padrão, o acesso à rede: Let Everyone permissões aplicam a usuários anônimos for definida como Não definido no Windows Server 2003. Por padrão, o Windows Server 2003 não inclui o token de acesso anônimo em todos grupo.
    2. Exemplo de problemas de compatibilidade

      O seguinte valor de
      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA\everyoneincludesanonymous
      [REG_DWORD] = 0x0 quebras confiança criação entre o Windows Server 2003 e o Windows NT 4.0, quando o domínio do Windows Server 2003 é a conta e o Windows NT 4.0 é domínio de recurso. Isso significa que o domínio de conta é confiável Windows NT 4.0 e o domínio de recurso é confiante no lado do Windows Server 2003. Esse comportamento ocorre porque seria o processo para iniciar a relação de confiança após a conexão anônima inicial ACL com o token todos que inclui o SID anônimo no Windows NT 4.0.
    3. Motivos para modificar essa configuração

      O valor deve ser definido como 0x1 ou definir usando um GPO no UO do controlador de domínio seja: acesso à rede: Let Everyone permissões aplicadas a usuários anônimos - ativado para possibilitar as criações de confiança.

      Observação Maioria das outras configurações de segurança subir em valor e para 0x0 em seu estado mais seguro. Uma prática mais segura seria alterar o registro no emulador de controlador do domínio primário em vez de em todos os controladores de domínio. Se a função de emulador do controlador de domínio primário for movida por qualquer motivo, o registro deve ser atualizado no novo servidor.

      É necessário reiniciar após esse valor é definido.
    4. Caminho do registro
      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA\everyoneincludesanonymous
  15. Autenticação NTLMv2

    Segurança de sessão

    Segurança de sessão determina os padrões mínimos de segurança para sessões de cliente e servidor. É uma boa idéia verificar estas configurações de diretiva de segurança no snap-in do Editor de diretiva de grupo do Console de gerenciamento Microsoft:
    • Computador Settings\Windows Settings\Security Settings\Local Policies\Security Options
    • Segurança de rede: Segurança de sessão mínima para servidores baseados em NTLM SSP (incluindo RPC seguro)
    • Segurança de rede: Segurança de sessão mínima para clientes baseados em NTLM SSP (incluindo RPC seguro)
    As opções para essas configurações são:
    • Requer integridade de mensagem
    • Requer sigilo de mensagem
    • Exigir NTLM versão 2 segurança de sessão
    • Exigir criptografia de 128 bits
    A configuração padrão é sem requisitos.

    Essas diretivas determinam os padrões mínimos de segurança para uma sessão de comunicação do aplicativo para um servidor para um cliente.

    Historicamente, Windows NT tem suporte para as duas seguintes variantes de autenticação desafio/resposta para logons de rede:
    • Desafio/resposta LM
    • NTLM versão 1 desafio/resposta
    LM permite interoperabilidade com a base instalada de clientes e servidores. NTLM fornece segurança aprimorada para conexões entre clientes e servidores.

    As chaves do Registro correspondentes são:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0\ "NtlmMinServerSec"

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0\ "NtlmMinClientSec"

Sincronização de tempo

Falha na sincronização de tempo. O tempo está desativado por mais de 30 minutos em um computador afetado. Certifique-se de que o relógio do computador cliente está sincronizado com o relógio do controlador de domínio.

Solução alternativa para assinatura SMB

Clique aqui para obter informações sobre como solucionar problemas de assinatura SMB
Recomendamos que você instale o Service Pack 6a (SP6a) em clientes Windows NT 4.0 que interoperam em um domínio do Windows Server 2003. Clientes baseados no Windows 98 Second Edition, clientes baseados no Windows 98 e clientes baseados no Windows 95 devem executar o Directory Services Client para efetuar a NTLMv2. Se não tiverem clientes com Windows NT 4.0 Windows NT 4.0 SP6 instalado ou se clientes baseados em Windows 95, clientes baseados no Windows 98 e Windows 98SE com clientes não tenham o Directory Services Client instalado, desative a diretiva do controlador de domínio padrão no UO do controlador de domínio a configuração de assinatura SMB e vincular essa diretiva para todas as unidades organizacionais que hospedam controladores de domínio.

O Directory Services Client para Windows 98 Second Edition, Windows 98 e Windows 95 realizará a assinatura SMB com servidores Windows 2003 em autenticação NTLM, mas não em autenticação NTLMv2. Além disso, os servidores Windows 2000 não responderá a solicitações de assinatura SMB esses clientes.

Embora não recomendável, você pode impedir que a assinatura SMB seja solicitada em todos os controladores de domínio que executam o Windows Server 2003 em um domínio. Para configurar essa configuração de segurança, execute estas etapas:
  1. Abra a diretiva do controlador de domínio padrão.
  2. Abra a pasta Computador Configuration\Windows Settings\Security Settings\Local Policies\Security Options .
  3. Localize e clique no servidor de rede Microsoft: assinar digitalmente a comunicação (sempre) configuração de diretiva e clique em desativado.
Importante Esta seção, método ou tarefa contém etapas que informam sobre como modificar o registro. No entanto, podem ocorrer problemas graves se modificar o registro incorretamente. Portanto, certifique-se de seguir estas etapas cuidadosamente. Para proteção adicional, faça backup do registro antes de modificá-lo. Em seguida, você pode restaurar o registro se ocorrer um problema. Para obter mais informações sobre como fazer backup e restaurar o registro, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:
322756 Como fazer backup e restaurar o registro no Windows
Como alternativa, desative a assinatura SMB no servidor modificando o registro. Para fazer isso, execute estas etapas:
  1. Clique em Iniciar, clique em Executar, tipo Regedite clique em OK.
  2. Localize e clique na seguinte subchave:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
  3. Clique no EnableSecuritySignature entrada.
  4. Sobre o Editar menu, clique em Modificar.
  5. No Dados do valor caixa, digite 0e clique em OK.
  6. Saia do Editor do registro.
  7. Reinicie o computador ou parar e reiniciar o serviço do servidor. Para fazer isso, digite os seguintes comandos no prompt de comando e pressione Enter após digitar cada comando:
    NET stop server
    NET start server
Observação A chave correspondente no computador cliente está na seguinte subchave do registro:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Lanmanworkstation\Parameters
A seguir lista os números de código de erro traduzido para códigos de status e as mensagens de erro mencionadas anteriormente:
Erro 5
ERROR_ACCESS_DENIED
Acesso negado.
Erro 1326
ERROR_LOGON_FAILURE
Falha de logon: nome de usuário desconhecido ou senha incorreta.
Erro 1788
ERROR_TRUSTED_DOMAIN_FAILURE
Relação de confiança entre o domínio primário e o domínio confiável falhou.
Erro 1789
ERROR_TRUSTED_RELATIONSHIP_FAILURE
Relação de confiança entre esta estação de trabalho e o domínio primário falhou.
Para obter mais informações, clique nos números abaixo para ler os artigos na Base de dados de Conhecimento da Microsoft:
324802Como configurar diretivas de grupo para definir segurança para serviços do sistema no Windows Server 2003
306771 Mensagem de erro "Acesso negado" depois de configurar um cluster do Windows Server 2003
101747 Como instalar a autenticação Microsoft em um Macintosh
161372 Como habilitar a assinatura SMB no Windows NT
236414 Não é possível usar compartilhamentos com o LMCompatibilityLevel definido somente a autenticação NTLM 2
241338 Cliente Windows NT LAN Manager versão 3 com primeiro logon impede atividade de logon
262890 Não é possível obter conexão de unidade do diretório base em um ambiente misto
308580 Mapeamentos de pasta base para servidores de nível inferior podem não funcionar durante o logon
285901 Acesso remoto, VPN e RIS clientes não é possível estabelecer sessões com um servidor configurado para aceitar somente autenticação NTLM versão 2
816585 Como aplicar modelos de segurança predefinidos no Windows Server 2003
820281 Você deve fornecer credenciais de conta do Windows quando você se conectar a Exchange Server 2003 usando o Outlook 2003 RPC sobre recurso HTTP
Registro do usuário segurança certa configuração compatível compatibilidade grupo de segurança Diretiva acl direitos gpedit pdce

Aviso: este artigo foi traduzido automaticamente

Propriedades

ID do Artigo: 823659 - Última Revisão: 07/16/2013 04:30:00 - Revisão: 24.1

  • Microsoft Windows Server 2003, Standard Edition (32-bit x86)
  • Microsoft Windows Server 2003, Datacenter Edition (32-bit x86)
  • Microsoft Windows Server 2003, Enterprise Edition (32-bit x86)
  • Microsoft Windows Server 2003, Enterprise x64 Edition
  • Microsoft Windows XP Professional
  • Microsoft Windows 2000 Server
  • Microsoft Windows 2000 Advanced Server
  • Microsoft Windows 2000 Professional Edition
  • Microsoft Windows NT Server 4.0 Standard Edition
  • Microsoft Windows NT Workstation 4.0 Developer Edition
  • Microsoft Windows 98 Standard Edition
  • Microsoft Windows 95
  • kbinfo kbmt KB823659 KbMtpt
Comentários
;did=1&t=">"); &t=">