Entrar com a conta da Microsoft
Entrar ou criar uma conta.
Olá,
Selecionar uma conta diferente.
Você tem várias contas
Escolha a conta com a qual você deseja entrar.

Resumo

As configurações de segurança e as atribuições de direitos de usuário podem ser alteradas em políticas locais e políticas de grupo para ajudar a reforçar a segurança em controladores de domínio e computadores membros. No entanto, a desvantagem do aumento da segurança é a introdução de incompatibilidades com clientes, serviços e programas.

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

Para obter informações sobre Política de Grupo para Windows 7, Windows Server 2008 R2 e Windows Server 2008, consulte os seguintes artigos:

Observação: o conteúdo restante neste artigo é específico do Windows XP, do Windows Server 2003 e de versões anteriores do Windows.

Windows XP

Para aumentar o reconhecimento das configurações de segurança configuradas incorretamente, use a ferramenta Política de Grupo Editor de Objetos para alterar as configurações de segurança. Quando você usa Política de Grupo Editor de Objetos, 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 aprimorado é uma caixa de diálogo que contém um link para este artigo. A caixa de diálogo é exibida quando você altera uma configuração de segurança ou uma atribuição de direitos de usuário para uma configuração que oferece menos compatibilidade e é mais restritiva. Se você alterar diretamente a mesma configuração de segurança ou atribuição de direitos de usuário usando o Registro ou usando modelos de segurança, o efeito será o mesmo que alterar a configuração no Editor de Objetos do Política de Grupo. No entanto, a caixa de diálogo que contém o link para este artigo não é exibida.

Este artigo contém exemplos de clientes, programas e operações que são afetados por configurações de segurança específicas ou atribuições de direitos de usuário. No entanto, os exemplos não são autoritativos para todos os sistemas operacionais da Microsoft, para todos os sistemas operacionais de terceiros ou para todas as versões do programa afetadas. Nem todas as configurações de segurança e atribuições de direitos de usuário estã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 apresentá-las em um ambiente de produção. A floresta de teste deve espelhar a floresta de produção das seguintes maneiras:

  • Versões do sistema operacional cliente e servidor, programas de cliente e servidor, versões do service pack, hotfixes, alterações de esquema, grupos de segurança, associações de grupo, permissões em objetos no sistema de arquivos, pastas compartilhadas, registro, serviço de diretório do Active Directory, configurações locais e Política de Grupo, e tipo e local de contagem de objetos

  • Tarefas administrativas executadas, ferramentas administrativas usadas e sistemas operacionais usados para executar tarefas administrativas

  • Operações executadas, como as seguintes:

    • Autenticação de logon de computador e usuário

    • Redefinições de senha por usuários, computadores e por administradores

    • Navegação

    • Definindo permissões para o sistema de arquivos, para pastas compartilhadas, para o Registro e para recursos do Active Directory usando o Editor de ACL em todos os sistemas operacionais cliente em todos os domínios de conta ou recurso de todos os sistemas operacionais cliente de todos os domínios de conta ou recurso

    • Impressão de contas administrativas e não administrativas

Windows Server 2003 SP1

Avisos em Gpedit.msc

Para ajudar os clientes a saber que estão editando um direito de usuário ou uma opção de segurança que poderia afetar negativamente sua rede, dois mecanismos de aviso foram adicionados ao gpedit.msc. Quando os administradores editarem um direito de usuário que pode afetar negativamente toda a empresa, eles verão um novo ícone semelhante a um sinal de rendimento. Eles também receberão uma mensagem de aviso que tem um link para o artigo da Base de Dados de Conhecimento Microsoft 823659. 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 <opção de segurança ou direito do usuário que está sendo modificada> (Q823659) Se você foi direcionado para este artigo da Base de Dados de Conhecimento a partir de um link no Gpedit.msc, certifique-se de ler e entender a explicação fornecida e o possível efeito de alterar essa configuração. A lista a seguir lista os Direitos do Usuário que contêm o texto de aviso:

  • Acessar este computador da rede

  • Fazer logon localmente

  • Ignorar verificação de passagem

  • Habilitar computadores e usuários para delegação confiável

O seguinte lista opções de segurança que têm o aviso e uma mensagem pop-up:

  • Membro do Domínio: criptografar digitalmente ou assinar dados de canal seguro (sempre)

  • Membro do domínio: exigir chave de sessão forte (Windows 2000 ou versão posterior)

  • Controlador de domínio: requisitos de assinatura de servidor LDAP

  • Servidor de rede da Microsoft: assinar comunicações digitalmente (sempre)

  • Acesso à rede: permite a conversão de sid/nome anônimo

  • Acesso à rede: não permitir enumeração anônima de compartilhamentos e contas SAM

  • Segurança de rede: nível de autenticação do 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 incompatibilidades que podem ocorrer quando você altera configurações específicas em domínios do Windows NT 4.0, domínios do Windows 2000 e domínios do Windows Server 2003.

Direitos do usuário

A lista a seguir descreve um direito de usuário, identifica as definições de configuração que podem causar problemas, descreve por que você deve aplicar o direito do usuário e por que você pode querer remover o direito do usuário e fornece exemplos de problemas de compatibilidade que podem ocorrer quando o direito do usuário está configurado.

  1. Acessar este computador da rede

    1. Fundo

      A capacidade de interagir com computadores remotos baseados no Windows requer o acesso a este computador do direito do usuário de rede. Exemplos dessas operações de rede incluem o seguinte:

      • 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 de computadores

      • Acesso a pastas compartilhadas, impressoras e outros serviços do sistema localizados em computadores remotos na rede



      Usuários, computadores e contas de serviço obtêm ou perdem o direito de acessar este computador do usuário de rede, sendo adicionados ou removidos explicitamente ou implicitamente de um grupo de segurança que recebeu esse direito de usuário. Por exemplo, uma conta de usuário ou uma conta de computador pode ser adicionada explicitamente a um grupo de segurança personalizado ou a 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 de Domínio, Usuários Autenticados ou Controladores de Domínio Empresarial.

      Por padrão, as contas de usuário e as contas de computador recebem o access this computer do usuário de rede diretamente quando grupos computados como Todos ou, preferencialmente, Usuários Autenticados e, para controladores de domínio, o grupo Controladores de Domínio Empresarial, são definidos nos controladores de domínio padrão Política de Grupo Object (GPO).

    2. Configurações arriscadas

      A seguir estão as definições de configuração prejudiciais:

      • Removendo o grupo de segurança controladores de domínio empresarial deste direito de usuário

      • Removendo o grupo Usuários Autenticados ou um grupo explícito que permite aos usuários, computadores e contas de serviço o direito do usuário de se conectar a computadores pela rede

      • Remover todos os usuários e computadores deste direito de usuário

    3. Motivos para conceder esse direito de usuário

      • Conceder ao access este computador do direito de usuário de rede para o grupo Controladores de Domínio Empresarial atende aos requisitos de autenticação que a replicação do Active Directory deve ter para que a replicação ocorra entre controladores de domínio na mesma floresta.

      • Esse direito de usuário permite que usuários e computadores acessem arquivos compartilhados, impressoras e serviços do sistema, incluindo o Active Directory.

      • Esse direito de usuário é necessário para que os usuários acessem emails usando versões anteriores do Microsoft Outlook Web Access (OWA).

    4. Motivos para remover esse direito de usuário

      • Os usuários que podem conectar seus computadores à rede podem acessar recursos em computadores remotos para os quais têm permissões. Por exemplo, esse direito de usuário é necessário para que um usuário se conecte a impressoras compartilhadas e a pastas. Se esse direito de usuário for concedido ao grupo Todos e se algumas pastas compartilhadas tiverem permissões de sistema de arquivos NTFS e compartilhamento configuradas para que o mesmo grupo tenha acesso de leitura, qualquer pessoa poderá exibir arquivos nessas pastas compartilhadas. No entanto, essa é uma situação improvável para novas instalações do Windows Server 2003 porque o compartilhamento padrão e as permissões NTFS no Windows Server 2003 não incluem o grupo Todos. Para sistemas atualizados do Microsoft Windows NT 4.0 ou Windows 2000, essa vulnerabilidade pode ter um nível mais alto de risco porque o compartilhamento padrão e as permissões do sistema de arquivos para esses sistemas operacionais não são tão restritivos quanto as permissões padrão no Windows Server 2003.

      • Não há nenhum motivo válido para remover o grupo de Controladores de Domínio Empresarial desse direito de usuário.

      • O grupo Todos geralmente é removido em favor do grupo Usuários Autenticados. Se o grupo Todos for removido, o grupo Usuários Autenticados deverá receber esse direito de usuário.

      • Windows NT domínios 4.0 atualizados para o Windows 2000 não concedem explicitamente ao Access este computador o direito de usuário de rede 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 política de domínio Windows NT 4.0, a 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 essa configuração incorreta concedendo ao grupo controladores de domínio empresarial esse usuário direito quando você atualiza pdCs (controladores de domínio primários) do Windows NT 4.0. Conceda ao grupo Controladores de Domínio Empresarial esse direito de usuário se ele não estiver presente no editor de Política de Grupo objeto.

    5. Exemplos de problemas de compatibilidade

      • Windows 2000 e Windows Server 2003: a replicação das seguintes partições falhará com erros de "Acesso Negado", conforme relatado por ferramentas de monitoramento, como REPLMON e REPADMIN ou eventos de replicação no log de eventos.

        • Partição de esquema do Active Directory

        • Partição de configuração

        • Partição de domínio

        • Partição de catálogo global

        • Partição de aplicativo

      • Todos os sistemas operacionais de rede da Microsoft: a autenticação de conta de usuário de computadores cliente de rede remota falhará, a menos que o usuário ou um grupo de segurança do qual o usuário seja membro tenha sido concedido esse direito de usuário.

      • Todos os sistemas operacionais de rede da Microsoft: a autenticação de conta de clientes de rede remota falhará, a menos que a conta ou um grupo de segurança do qual a conta seja membro tenha sido concedido esse direito de usuário. Esse cenário se aplica a contas de usuário, contas de computador e contas de serviço.

      • Todos os sistemas operacionais de rede da Microsoft: remover todas as contas desse direito de usuário impedirá que qualquer conta entre no domínio ou acesse recursos de rede. Se grupos computados como Controladores de Domínio Empresarial, Todos ou Usuários Autenticados forem removidos, você deverá conceder explicitamente a esse usuário o direito a contas ou a grupos de segurança dos quais a conta é membro para acessar computadores remotos pela rede. Esse cenário se aplica a todas as contas de usuário, a todas as contas de computador e a todas as contas de serviço.

      • Todos os sistemas operacionais de rede da Microsoft: a conta de administrador local usa uma senha "em branco". A 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 localmente

    1. Fundo

      Os usuários que estão tentando fazer logon no console de um computador baseado no Windows (usando o atalho de teclado CTRL+ALT+DELETE) e as 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 estão fazendo logon nos consoles de computadores membros ou controladores de domínio em toda a empresa e usuários de domínio que estão fazendo logon em computadores membros para acessar suas áreas de trabalho usando contas sem privilégios. Os usuários que usam uma conexão de Área de Trabalho Remota ou Serviços de Terminal devem ter o logon Permitir logon localmente em computadores de destino que executam o Windows 2000 ou o Windows XP porque esses modos de logon são considerados locais para o computador de hospedagem. Os usuários que estão fazendo logon em um servidor que tem o Servidor de Terminal habilitado e que não têm esse direito de usuário ainda poderão iniciar uma sessão interativa remota em domínios do Windows Server 2003 se tiverem o direito de usuário Permitir logon por meio dos Serviços de Terminal.

    2. Configurações arriscadas

      A seguir estão as definições de configuração prejudiciais:

      • Removendo grupos de segurança administrativos, incluindo operadores de conta, operadores de backup, operadores de impressão ou operadores de servidor, e o grupo de administradores internos da política do controlador de domínio padrão.

      • Remover contas de serviço que são usadas por componentes e programas em computadores membros e em controladores de domínio no domínio da política do controlador de domínio padrão.

      • Removendo usuários ou grupos de segurança que fizerem logon no console de computadores membros no domínio.

      • Removendo contas de serviço definidas no banco de dados SAM (Gerenciador de Contas de Segurança) local de computadores membros ou de computadores de grupo de trabalho.

      • Removendo contas administrativas não internas que estão sendo autenticadas nos Serviços de Terminal em execução em um controlador de domínio.

      • Adicionar todas as contas de usuário no domínio explicitamente ou implicitamente por meio do grupo Todos ao direito de logon de Negar localmente. Essa configuração impedirá que os usuários fazendo logon em qualquer computador membro ou em qualquer controlador de domínio no domínio.

    3. Motivos para conceder esse direito de usuário

      • Os usuários devem ter o direito permitir logon localmente para acessar o console ou a área de trabalho de um computador do grupo de trabalho, um computador membro ou um controlador de domínio.

      • Os usuários devem ter esse direito de usuário para fazer logon em uma sessão dos Serviços de Terminal em execução em um computador membro ou controlador de domínio baseado no Windows 2000.

    4. Motivos para remover esse direito de usuário

      • A falha ao restringir o acesso do console a contas de usuário legítimas pode fazer com que usuários não autorizados baixem e executam código mal-intencionado para alterar seus direitos de usuário.

      • A remoção do direito permitir logon local do usuário impede logons não autorizados nos consoles de computadores, como controladores de domínio ou servidores de aplicativos.

      • A remoção desse direito de logon impede que contas que não são de domínio faça logon no console de computadores membros no domínio.

    5. Exemplos de problemas de compatibilidade

      • Servidores de terminal do Windows 2000: o direito permitir logon localmente do usuário é necessário para que os usuários possam fazer logon em servidores de terminal do Windows 2000.

      • Windows NT 4.0, Windows 2000, Windows XP ou Windows Server 2003: as contas de usuário devem receber esse direito de usuário para fazer logon no console de computadores que executam o Windows NT 4.0, Windows 2000, Windows XP ou Windows Server 2003.

      • Windows NT 4.0 e posterior: em computadores que executam o Windows NT 4.0 e posterior, se você adicionar o direito permitir logon localmente, mas você conceder implicitamente ou explicitamente o direito de logon negar localmente, as contas não poderão fazer logon no console dos controladores de domínio.

  3. Ignorar verificação de passagem

    1. Fundo

      A passagem bypass verificando o direito do usuário permite que o usuário navegue por pastas no sistema de arquivos NTFS ou no Registro sem verificar a permissão de acesso especial de Pasta de Passagem. A passagem bypass verificando o direito do usuário não permite que o usuário liste o conteúdo de uma pasta. Ele permite que o usuário percorra apenas suas pastas.

    2. Configurações arriscadas

      A seguir estão as definições de configuração prejudiciais:

      • Removendo contas não administrativas que fazem logon em computadores dos Serviços de Terminal baseados no Windows 2000 ou computadores dos Serviços de Terminal baseados no Windows Server 2003 que não têm permissões para acessar arquivos e pastas no sistema de arquivos.

      • Removendo o grupo Todos da lista de entidades de segurança que têm esse usuário certo por padrão. Os sistemas operacionais Windows e também muitos programas são projetados com a expectativa de que qualquer pessoa que possa acessar o computador de forma legítima terá a passagem bypass verificando o direito do usuário. Portanto, remover o grupo Todos da lista de entidades de segurança que têm esse usuário certo por padrão pode levar à instabilidade do sistema operacional ou à falha do programa. É melhor que você deixe essa configuração em seu padrão.

    3. Motivos para conceder esse direito de usuário

      A configuração padrão para a verificação de passagem de bypass à direita do usuário é permitir que qualquer pessoa ignore a verificação de passagem. Para administradores experientes do sistema Windows, esse é o comportamento esperado e eles configuram SACLs (listas de controle de acesso do sistema de arquivos) adequadamente. O único cenário em que a configuração padrão pode levar a um problema é se o administrador que configura permissões não entende o comportamento e espera que os usuários que não podem acessar uma pasta pai não poderão acessar o conteúdo de nenhuma pasta filho.

    4. Motivos para remover esse direito de usuário

      Para tentar impedir o acesso aos arquivos ou às pastas no sistema de arquivos, as organizações que estão muito preocupadas com a segurança podem ficar tentados a remover o grupo Todos, ou até mesmo o grupo Usuários, da lista de grupos que têm a passagem Bypass verificando o direito do usuário.

    5. Exemplos de problemas de compatibilidade

      • Windows 2000, Windows Server 2003: se a passagem bypass verificar o direito do usuário for removida ou estiver configurada incorretamente em computadores que executam o Windows 2000 ou o Windows Server 2003, as configurações do Política de Grupo na pasta SYVOL não serão replicadas entre os controladores de domínio no domínio.

      • Windows 2000, Windows XP Professional, Windows Server 2003: computadores que executam o Windows 2000, o Windows XP Professional ou o Windows Server 2003 registrarão eventos 1000 e 1202 e não poderão aplicar a política de computador e a política de usuário quando as permissões necessárias do sistema de arquivos forem removidas da árvore SYSVOL se o direito do usuário de verificação de passagem de bypass for removido ou estiver configurado incorretamente.

         

      • Windows 2000, Windows Server 2003: em computadores que executam o Windows 2000 ou o Windows Server 2003, a guia Cota no Windows Explorer desaparecerá quando você exibir propriedades em um volume.

      • Windows 2000: não administradores que fizerem logon em um servidor de terminal do Windows 2000 podem receber a seguinte mensagem de erro:

        Userinit.exe de aplicativo. O aplicativo não pôde ser inicializado corretamente 0xc0000142 clique em OK para encerrar o aplicativo.

      • Windows NT 4.0, Windows 2000, Windows XP, Windows Server 2003: os usuários cujos computadores estão executando o Windows NT 4.0, Windows 2000, Windows XP ou Windows Server 2003 podem não conseguir acessar pastas ou arquivos compartilhados em pastas compartilhadas e podem receber mensagens de erro "Acesso Negado" se não receberem o direito do usuário de verificação de passagem de bypass.


         

      • Windows NT 4.0: em computadores baseados no Windows NT 4.0, a remoção da passagem bypass do direito do usuário de verificação fará com que uma cópia de arquivo remova fluxos de arquivos. Se você remover esse direito do usuário, quando um arquivo for copiado de um cliente Windows ou de um cliente Macintosh para um controlador de domínio do Windows NT 4.0 que esteja executando o Services for Macintosh, o fluxo de arquivos de destino será perdido e o arquivo aparecerá como um arquivo somente texto.

      • Microsoft Windows 95, Microsoft Windows 98: em um computador cliente que esteja executando o Windows 95 ou o Windows 98, o comando net use * /home falhará com uma mensagem de erro "Acesso Negado" se o grupo Usuários Autenticados não receber o direito de verificação de passagem bypass.

      • 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 não receberem a verificação de passagem de bypass do direito do usuário.

Configurações de segurança

A lista a seguir identifica uma configuração de segurança e a lista aninhada fornece uma descrição sobre a configuração de segurança, identifica as definições de configuração que podem causar problemas, descreve por que você deve aplicar a configuração de segurança e descreve os motivos pelos quais você pode querer remover a configuração de segurança. Em seguida, a lista aninhada fornece um nome simbólico para a configuração de segurança e o caminho do Registro da configuração de segurança. Por fim, são fornecidos exemplos de problemas de compatibilidade que podem ocorrer quando a configuração de segurança é definida.

  1. Auditoria: desligar o sistema imediatamente se não for possível registrar auditorias de segurança

    1. Tela de fundo

      • A auditoria: desligue o sistema imediatamente se não for possível registrar a configuração de auditorias de segurança determina se o sistema será desligado se você não puder registrar eventos de segurança. Essa configuração é necessária para a avaliação C2 do programa TCSEC (Trusted Computer Security Evaluation Criteria) e para os Critérios Comuns de Avaliação de Segurança da Tecnologia da Informação para evitar eventos auditáveis se o sistema de auditoria não puder registrar esses eventos. Se o sistema de auditoria falhar, o sistema será desligado e uma mensagem de erro Parar será exibida.

      • Se o computador não puder registrar eventos no log de segurança, evidências críticas ou informações importantes de solução de problemas poderão não estar disponíveis para revisão após um incidente de segurança.

    2. Configuração arriscada

      A seguir está uma configuração prejudicial: a auditoria: desligar o sistema imediatamente se não for possível registrar a configuração de auditorias de segurança estiver ativada e o tamanho do log de eventos de segurança for restrito pela opção Não substituir eventos (limpar log manualmente), pela opção Substituir Eventos conforme necessário ou pela opção Substituir Eventos com mais de dias numéricos no Visualizador de Eventos. Consulte a seção "Exemplos de problemas de compatibilidade" para obter informações sobre riscos específicos para computadores que executam a versão original lançada do Windows 2000, Windows 2000 Service Pack 1 (SP1), Windows 2000 SP2 ou Windows 2000 SP3.

    3. Motivos para habilitar essa configuração

      Se o computador não puder registrar eventos no log de segurança, evidências críticas ou informações importantes de solução de problemas poderão não estar disponíveis para revisão após um incidente de segurança.

    4. Motivos para desabilitar essa configuração

      • Habilitando a auditoria: desligue o sistema imediatamente se não for possível registrar a configuração de auditorias de segurança para o sistema se uma auditoria de segurança não puder ser registrada por qualquer motivo. Normalmente, um evento não pode ser registrado quando o log de auditoria de segurança está cheio e quando seu método de retenção especificado é a opção Não substituir eventos (limpar log manualmente) ou a opção Substituir Eventos com mais de dias numéricos.

      • A carga administrativa de habilitar a Auditoria: desligar o sistema imediatamente se não for possível registrar a configuração de auditorias de segurança pode ser muito alta, especialmente se você também ativar a opção Não substituir eventos (limpar log manualmente) para o log de segurança. Essa configuração fornece responsabilidade individual das ações do operador. Por exemplo, um administrador pode redefinir permissões em todos os usuários, computadores e grupos em uma UO (unidade organizacional) em que a auditoria foi habilitada usando a conta de administrador interna ou outra conta compartilhada e, em seguida, negar que redefiniu essas permissões. No entanto, habilitar a configuração reduz a robustez do sistema porque um servidor pode ser forçado a desligar, sobrecarregue-o com eventos de logon e com outros eventos de segurança gravados no log de segurança. Além disso, como o desligamento não é normal, podem ocorrer danos irreparáveis ao sistema operacional, programas ou dados. Embora o NTFS garanta que a integridade do sistema de arquivos seja mantida durante um desligamento inadequado do sistema, ele não pode garantir que todos os arquivos de dados de cada programa ainda estarão em uma 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: Devido a um bug, os computadores que executam a versão original lançada do Windows 2000, Windows 2000 SP1, Windows 2000 SP2 ou Windows Server SP3 podem parar de registrar eventos antes que o tamanho especificado na opção De tamanho máximo do log de eventos de segurança seja atingido. Esse bug foi corrigido no Windows 2000 Service Pack 4 (SP4). Verifique se os controladores de domínio do Windows 2000 têm o Windows 2000 Service Pack 4 instalado antes de considerar habilitar essa configuração.

         

      • Windows 2000, Windows Server 2003: Computadores que executam o Windows 2000 ou o Windows Server 2003 podem parar de responder e, em seguida, podem reiniciar espontaneamente se a auditoria: desligar o sistema imediatamente se não for possível registrar a configuração de auditorias de segurança estiver ativada, o log de segurança estiver cheio e uma entrada de log de eventos existente não poderá ser substituída. Quando o computador for reiniciado, a seguinte mensagem de erro Parar será exibida:

        STOP: C0000244 {Audit Failed}
        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 essa 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 seguinte mensagem de erro:

        Sua conta está configurada para impedir que você use este computador. Tente outro computador.

      • Windows 2000: Em computadores baseados no Windows 2000, os não administradores não poderão fazer logon em servidores de acesso remoto e receberão uma mensagem de erro semelhante à seguinte:

        Usuário desconhecido ou senha incorreta

      • Windows 2000: Em controladores de domínio do Windows 2000, o serviço de mensagens entre sites (Ismserv.exe) será interrompido e não poderá ser reiniciado. O DCDIAG relatará o erro como "ISMserv dos serviços de teste com falha" e a ID do evento 1083 será registrada no log de eventos.

      • Windows 2000: em controladores de domínio do Windows 2000, a replicação do Active Directory falhará e uma mensagem "Acesso Negado" será exibida se o log de eventos de segurança estiver cheio.

      • Microsoft Exchange 2000: Os servidores que executam o Exchange 2000 não poderão montar o banco de dados do repositório de informações e o evento 2102 será registrado no log de eventos.

      • Outlook, Outlook Web Access: não administradores não poderão acessar seus emails por meio do Microsoft Outlook ou do Microsoft Outlook Web Access e receberão um erro 503.

  2. Controlador de domínio: requisitos de assinatura de servidor LDAP

    1. Fundo

      O controlador de domínio: a configuração de segurança dos requisitos de assinatura do servidor LDAP determina se o servidor LDAP (Lightweight Directory Access Protocol) exige que os clientes LDAP negociem a assinatura de dados. Os valores possíveis para essa configuração de política são os seguintes:

      • Nenhum: a assinatura de dados não é necessária para associar ao servidor. Se o cliente solicitar a assinatura de dados, o servidor oferecerá suporte a ele.

      • Exigir assinatura: a opção de assinatura de dados LDAP deve ser negociada, a menos que o protocolo TLS/SSL esteja sendo usado.

      • não definido: essa configuração não está habilitada ou desabilitada.

    2. Configurações arriscadas

      A seguir estão as definições de configuração prejudiciais:

      • Habilitando Exigir entrada em ambientes em que os clientes não dão suporte à assinatura LDAP ou em que a assinatura LDAP do lado do cliente não está habilitada no cliente

      • Aplicando o modelo de segurança Hisecdc.inf do Windows 2000 ou Windows Server 2003 em ambientes em que os clientes não dão suporte à assinatura LDAP ou em que a assinatura LDAP do lado do cliente não está habilitada

      • Aplicando o modelo de segurança Hisecws.inf do Windows 2000 ou Windows Server 2003 em ambientes em que os clientes não dão suporte à assinatura LDAP ou em que a assinatura LDAP do lado do cliente não está habilitada

    3. Motivos para habilitar essa configuração

      O tráfego de rede não assinado é suscetível a ataques man-in-the-middle em que um invasor captura pacotes entre o cliente e o servidor, modifica os pacotes e os encaminha para o servidor. Quando esse comportamento ocorre em um servidor LDAP, um invasor pode fazer com que um servidor tome decisões baseadas em consultas falsas do cliente LDAP. Você pode reduzir esse risco em uma rede corporativa implementando medidas de segurança física fortes para ajudar a proteger a infraestrutura de rede. O modo de cabeçalho de autenticação ipSec (segurança do protocolo IPSec) pode ajudar a evitar ataques man-in-the-middle. O modo de cabeçalho de autenticação executa a autenticação mútua e a integridade do pacote para o tráfego ip.

    4. Motivos para desabilitar essa configuração

      • Os clientes que não dão suporte à assinatura LDAP não poderão realizar consultas LDAP em controladores de domínio e em catálogos globais se a autenticação NTLM for negociada e se os service packs corretos não forem instalados em controladores de domínio do Windows 2000.

      • Os rastreamentos de rede do tráfego LDAP entre clientes e servidores serão criptografados. Isso torna difícil examinar conversas LDAP.

      • Os servidores baseados no Windows 2000 devem ter o Windows 2000 Service Pack 3 (SP3) ou instalados quando forem administrados com programas que dão suporte à assinatura LDAP que são executados em computadores cliente que executam o Windows 2000 SP4, o Windows XP ou o 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

      • As associações simples falharão e você receberá a seguinte mensagem de erro:

        Ldap_simple_bind_s() falhou: Autenticação Forte Necessária.

      • Windows 2000 Service Pack 4, Windows XP, Windows Server 2003: em clientes que executam o Windows 2000 SP4, Windows XP ou Windows Server 2003, algumas ferramentas de administração do Active Directory não funcionarão corretamente em controladores de domínio que executam versões do Windows 2000 anteriores ao SP3 quando a autenticação NTLM for negociada.

         

      • Windows 2000 Service Pack 4, Windows XP, Windows Server 2003: em clientes que executam o Windows 2000 SP4, Windows XP ou Windows Server 2003, algumas ferramentas de administração do Active Directory direcionadas a controladores de domínio que executam versões do Windows 2000 anteriores ao SP3 não funcionarão corretamente se estiverem usando endereços IP (por exemplo, "dsa.msc /server=x.x.x.x" em que
        x.x.x.x é um endereço IP).


         

      • Windows 2000 Service Pack 4, Windows XP, Windows Server 2003: em clientes que executam o Windows 2000 SP4, Windows XP ou Windows Server 2003, algumas ferramentas de administração do Active Directory direcionadas a controladores de domínio que executam versões do Windows 2000 anteriores ao SP3 não funcionarão corretamente.

         

  3. Membro do domínio: exigir chave de sessão forte (Windows 2000 ou posterior)

    1. Tela de fundo

      • O membro do domínio: Exigir configuração de chave de sessão forte (Windows 2000 ou posterior) determina se um canal seguro pode ser estabelecido com um controlador de domínio que não pode criptografar o tráfego de canal seguro com uma chave de sessão forte de 128 bits. Habilitar essa configuração impede o estabelecimento de um canal seguro com qualquer controlador de domínio que não possa criptografar dados de canal seguro com uma chave forte. Desabilitar essa configuração permite chaves de sessão de 64 bits.

      • Antes de habilitar essa configuração em uma estação de trabalho membro ou em um servidor, todos os controladores de domínio no domínio ao qual o membro pertence devem ser capazes de criptografar dados de canal seguro com uma chave forte de 128 bits. Isso significa que todos esses controladores de domínio devem estar executando o Windows 2000 ou posterior.

    2. Configuração arriscada

      Habilitar o membro domain: exigir uma configuração de chave de sessão forte (Windows 2000 ou posterior) é uma configuração prejudicial.

    3. Motivos para habilitar essa configuração

      • As chaves de sessão usadas para estabelecer comunicações de canal seguro entre computadores membros e controladores de domínio são muito mais fortes no Windows 2000 do que em versões anteriores dos sistemas operacionais microsoft.

      • Quando for possível, é uma boa ideia aproveitar essas chaves de sessão mais fortes para ajudar a proteger as comunicações de canal seguro contra interceptações e ataques de rede de sequestro de sessão. A interceptação é uma forma de ataque mal-intencionado em que os dados de rede são lidos ou alterados em trânsito. Os dados podem ser modificados para ocultar ou alterar o remetente ou redirecioná-los.

      Importante Um computador que executa o Windows Server 2008 R2 ou Windows 7 dá suporte apenas a chaves fortes quando canais seguros são usados. Essa restrição impede uma relação de confiança entre qualquer domínio baseado em Windows NT 4.0 e qualquer domínio baseado no Windows Server 2008 R2. Além disso, essa restrição bloqueia Windows NT associação de domínio baseada em Windows NT 4.0 de computadores que executam o Windows 7 ou o Windows Server 2008 R2 e vice-versa.

    4. Motivos para desabilitar essa configuração

      O domínio contém computadores membros que executam 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 baseados

      no Windows NT 4.0, a redefinição de canais seguros de relações de confiança entre domínios do Windows NT 4.0 e do Windows 2000 com NLTEST falha. Uma mensagem de erro "Acesso Negado" é exibida:

      Falha na relação de confiança entre o domínio primário e o domínio confiável.

      Windows 7 e Server 2008 R2: para Windows 7 e versões posteriores e Windows Server 2008 R2 e versões posteriores, essa configuração não é mais respeitada e a chave forte é sempre usada. Por isso, as relações de confiança Windows NT domínios 4.0 não funcionam mais.

  4. Membro do domínio: criptografar digitalmente ou assinar dados de canal seguro (sempre)

    1. Tela de fundo

      • Habilitar membro de domínio: criptografar ou assinar digitalmente dados de canal seguro (sempre) impede o estabelecimento de um canal seguro com qualquer controlador de domínio que não possa assinar ou criptografar todos os dados de canal seguro. Para ajudar a proteger o tráfego de autenticação contra ataques man-in-the-middle, ataques de reprodução e outros tipos de ataques de rede, os computadores baseados no Windows criam um canal de comunicação conhecido como um canal seguro por meio do serviço de Logon da Rede 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 multiomain, ou autenticação de passagem, permite que um computador baseado no Windows que ingressou em um domínio tenha acesso ao banco de dados da conta de usuário em seu domínio e em qualquer domínio confiável.

      • Para habilitar a configuração membro domínio: criptografar digitalmente ou assinar dados de canal seguro (sempre) em um computador membro, todos os controladores de domínio no domínio ao qual o membro pertence 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 Windows NT 4.0 com o Service Pack 6a (SP6a) ou posterior.

      • Habilitar o membro domínio: criptografar digitalmente ou assinar dados de canal seguro (sempre) habilita automaticamente a configuração Membro de domínio: criptografar digitalmente ou assinar dados de canal seguro (quando possível).

    2. Configuração arriscada

      Habilitar o membro domínio: criptografar digitalmente ou assinar a configuração de dados de canal seguro (sempre) em domínios em que nem todos os controladores de domínio podem assinar ou criptografar dados de canal seguro é uma configuração prejudicial.

    3. Motivos para habilitar essa configuração

      O tráfego de rede não assinado é suscetível a ataques man-in-the-middle, em que 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 pode fazer com que um cliente tome decisões baseadas em registros falsos do diretório LDAP. Você pode reduzir o risco desse ataque em uma rede corporativa implementando medidas de segurança física fortes para ajudar a proteger a infraestrutura de rede. Além disso, implementar o modo de cabeçalho de autenticação ipSec (segurança do protocolo IPSec) pode ajudar a evitar ataques man-in-the-middle. Esse modo executa a autenticação mútua e a integridade do pacote para o tráfego IP.

    4. Motivos para desabilitar essa configuração

      • Os computadores em domínios locais ou externos dão suporte a canais seguros criptografados.

      • Nem todos os controladores de domínio no domínio têm os níveis de revisão do service pack apropriados para dar suporte a canais seguros criptografados.

    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: os computadores membros baseados no Windows 2000 não poderão ingressar em domínios do Windows NT 4.0 e receberão a seguinte mensagem de erro:

        A conta não está autorizada a fazer logon nesta estação.

        Para obter mais informações, clique no seguinte número de artigo para exibir o artigo na Base de Dados de Conhecimento Microsoft:

        281648 Mensagem de erro: a conta não está autorizada a fazer logon desta estação
         

      • Windows NT 4.0: os domínios do 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 fazer logon nesta estação.

        As relações de confiança de nível inferior existentes também podem não autenticar usuários do domínio confiável. Alguns usuários podem ter problemas para fazer logon no domínio e podem receber uma mensagem de erro informando que o cliente não pode localizar o domínio.

      • Windows XP: os clientes do Windows XP que ingressaram em domínios do Windows NT 4.0 não poderão autenticar tentativas de logon e poderão receber a seguinte mensagem de erro ou os seguintes eventos poderão ser registrados no log de eventos:

        O Windows não pode se conectar ao domínio porque o controlador de domínio está inativo ou não está disponível ou porque sua conta de computador não foi encontrada

      • Microsoft Network: os clientes de Rede da Microsoft receberão uma das seguintes mensagens de erro:

        Falha de logon: nome de usuário desconhecido ou senha incorreta.

        Não há chave de sessão do usuário para a sessão de logon especificada.

  5. Cliente de rede da Microsoft: assinar comunicações digitalmente (sempre)

    1. Fundo

      O SMB (Server Message Block) é o protocolo de compartilhamento de recursos compatível com muitos sistemas operacionais da Microsoft. É a base do NetBIOS (sistema de entrada/saída básico de rede) e de muitos outros protocolos. A assinatura SMB autentica o usuário e o servidor que hospeda os dados. Se um dos lados falhar no processo de autenticação, a transmissão de dados não ocorrerá.

      A habilitação da assinatura SMB é iniciada durante a negociação do protocolo SMB. As políticas de assinatura SMB determinam se o computador sempre assina digitalmente as comunicações do cliente.

      O protocolo de autenticação SMB do Windows 2000 dá suporte à autenticação mútua. A autenticação mútua fecha um ataque "man-in-the-middle". O protocolo de autenticação SMB do Windows 2000 também dá suporte à autenticação de mensagens. A autenticação de mensagens ajuda a evitar ataques ativos de mensagens. Para fornecer essa autenticação, a assinatura SMB coloca uma assinatura digital em cada SMB. Cada cliente e servidor verificam a assinatura digital.

      Para usar a assinatura SMB, você deve habilitar a assinatura SMB ou exigir a assinatura SMB no cliente SMB e no servidor SMB. Se a assinatura SMB estiver habilitada em um servidor, os clientes que também estão habilitados para assinatura SMB usarão o protocolo de assinatura de pacote durante todas as sessões subsequentes. Se a assinatura SMB for necessária em um servidor, um cliente não poderá estabelecer uma sessão, a menos que o cliente esteja habilitado ou seja necessário para a assinatura SMB.


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

      O protocolo SMB usado para compartilhamento de arquivos e para compartilhamento de impressão em computadores que executam o Windows 2000 Server, Windows 2000 Professional, Windows XP Professional ou Windows Server 2003 dá suporte à autenticação mútua. A autenticação mútua fecha os ataques de sequestro de sessão e dá suporte à autenticação de mensagens. Portanto, impede ataques man-in-the-middle. A assinatura SMB fornece essa autenticação colocando uma assinatura digital em cada SMB. Em seguida, o cliente e o servidor verificam a assinatura.

      Notas

      • Como uma contramedidas alternativa, você pode habilitar assinaturas digitais com IPSec para ajudar a proteger todo o tráfego de rede. Há aceleradores baseados em hardware para criptografia e assinatura IPSec que você pode usar para minimizar o impacto no desempenho da CPU do servidor. Esses aceleradores não estão disponíveis para assinatura SMB.

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

        Configure a assinatura SMB Política de Grupo Editor de Objetos porque uma alteração em um valor de registro local não terá efeito se houver uma política de domínio de substituição.

      • No Windows 95, no Windows 98 e no Windows 98 Second Edition, o Cliente de Serviços de Diretório usa a assinatura SMB quando ele é autenticado com servidores Windows Server 2003 usando a autenticação NTLM. No entanto, esses clientes não usam a assinatura SMB quando se autenticam com esses servidores usando a autenticação NTLMv2. Além disso, os servidores Windows 2000 não respondem a solicitações de assinatura SMB desses clientes. Para obter mais informações, consulte o item 10: "Segurança de rede: nível de autenticação do Lan Manager".

    2. Configuração arriscada

      A seguir está uma configuração prejudicial: Deixar o cliente de rede da Microsoft: assinar digitalmente a configuração de comunicações (sempre) e o cliente de rede da Microsoft: assinar comunicações digitalmente (se o servidor concordar) definido como "Não Definido" ou desabilitado. Essas configurações permitem que o redirecionador envie senhas de texto sem formatação para servidores não Microsoft SMB que não dão suporte à criptografia de senha durante a autenticação.

    3. Motivos para habilitar essa configuração

      Habilitar o cliente de rede da Microsoft: assinar comunicações digitalmente (sempre) exige que os clientes assinem o tráfego SMB ao contatar servidores que não exigem assinatura SMB. Isso torna os clientes menos vulneráveis a ataques de sequestro de sessão.

    4. Motivos para desabilitar essa configuração

      • Habilitar o cliente de rede da Microsoft: assinar comunicações digitalmente (sempre) impede que os clientes se comuniquem com servidores de destino que não dão suporte à assinatura SMB.

      • Configurar computadores para ignorar todas as comunicações SMB não assinadas impede que programas e sistemas operacionais anteriores se conectem.

    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 do Windows NT 4.0 usando NLTEST ou NETDOM e receberá uma mensagem de erro "Acesso Negado".

      • Windows XP: copiar arquivos de clientes do Windows XP para servidores baseados no Windows 2000 e para servidores baseados no Windows Server 2003 pode levar mais tempo.

      • Você não poderá mapear uma unidade de rede de um cliente com essa configuração habilitada e receberá a seguinte mensagem de erro:

        A conta não está autorizada a fazer logon nesta estação.

    8. Requisitos de reinicialização

      Reinicie o computador ou reinicie o serviço estação de trabalho. Para fazer isso, digite os comandos a seguir em um prompt de comando. Pressione Enter depois de digitar cada comando.

      estação de trabalho net
      stop net start workstation

  6. Servidor de rede da Microsoft: assinar comunicações digitalmente (sempre)

    1. Tela de fundo

      • O SMB (Server Messenger Block) é o protocolo de compartilhamento de recursos compatível com muitos sistemas operacionais da Microsoft. É a base do NetBIOS (sistema de entrada/saída básico de rede) e de muitos outros protocolos. A assinatura SMB autentica o usuário e o servidor que hospeda os dados. Se um dos lados falhar no processo de autenticação, a transmissão de dados não ocorrerá.

        A habilitação da assinatura SMB é iniciada durante a negociação do protocolo SMB. As políticas de assinatura SMB determinam se o computador sempre assina digitalmente as comunicações do cliente.

        O protocolo de autenticação SMB do Windows 2000 dá suporte à autenticação mútua. A autenticação mútua fecha um ataque "man-in-the-middle". O protocolo de autenticação SMB do Windows 2000 também dá suporte à autenticação de mensagens. A autenticação de mensagens ajuda a evitar ataques ativos de mensagens. Para fornecer essa autenticação, a assinatura SMB coloca uma assinatura digital em cada SMB. Cada cliente e servidor verificam a assinatura digital.

        Para usar a assinatura SMB, você deve habilitar a assinatura SMB ou exigir a assinatura SMB no cliente SMB e no servidor SMB. Se a assinatura SMB estiver habilitada em um servidor, os clientes que também estão habilitados para assinatura SMB usarão o protocolo de assinatura de pacote durante todas as sessões subsequentes. Se a assinatura SMB for necessária em um servidor, um cliente não poderá estabelecer uma sessão, a menos que o cliente esteja habilitado ou seja necessário para a assinatura SMB.


        Habilitar a assinatura digital em redes de alta segurança ajuda a impedir a representação de clientes e de servidores. Esse tipo de representação é conhecido como sequestro de sessão. Um invasor que tem acesso à mesma rede que o cliente ou o servidor usa ferramentas de sequestro de sessão para interromper, encerrar ou roubar uma sessão em andamento. Um invasor pode interceptar e modificar pacotes SBM (Gerenciador de Largura de Banda de Sub-rede) não assinados, modificar o tráfego e encaminhá-lo para que o servidor possa executar ações indesejadas. Ou, o invasor pode representar como o servidor ou como o cliente após uma autenticação legítima e, em seguida, obter acesso não autorizado aos dados.

        O protocolo SMB usado para compartilhamento de arquivos e para compartilhamento de impressão em computadores que executam o Windows 2000 Server, Windows 2000 Professional, Windows XP Professional ou Windows Server 2003 dá suporte à autenticação mútua. A autenticação mútua fecha os ataques de sequestro de sessão e dá suporte à autenticação de mensagens. Portanto, impede ataques man-in-the-middle. A assinatura SMB fornece essa autenticação colocando uma assinatura digital em cada SMB. Em seguida, o cliente e o servidor verificam a assinatura.

      • Como uma contramedidas alternativa, você pode habilitar assinaturas digitais com IPSec para ajudar a proteger todo o tráfego de rede. Há aceleradores baseados em hardware para criptografia e assinatura IPSec que você pode usar para minimizar o impacto no desempenho da CPU do servidor. Esses aceleradores não estão disponíveis para assinatura SMB.

      • No Windows 95, no Windows 98 e no Windows 98 Second Edition, o Cliente de Serviços de Diretório usa a assinatura SMB quando ele é autenticado com servidores Windows Server 2003 usando a autenticação NTLM. No entanto, esses clientes não usam a assinatura SMB quando se autenticam com esses servidores usando a autenticação NTLMv2. Além disso, os servidores Windows 2000 não respondem a solicitações de assinatura SMB desses clientes. Para obter mais informações, consulte o item 10: "Segurança de rede: nível de autenticação do Lan Manager".

    2. Configuração arriscada

      A seguir está uma configuração prejudicial: Habilitar o servidor de rede da Microsoft: assinar digitalmente a configuração de comunicações (sempre) em servidores e em controladores de domínio acessados por computadores incompatíveis baseados no Windows e computadores cliente baseados em sistema operacional de terceiros em domínios locais ou externos.

    3. Motivos para habilitar essa configuração

      • Todos os computadores cliente que habilitam essa configuração diretamente por meio do Registro ou por meio da configuração Política de Grupo suporte à assinatura SMB. Em outras palavras, todos os computadores cliente que têm essa configuração habilitada executam o Windows 95 com o cliente DS instalado, Windows 98, Windows NT 4.0, Windows 2000, Windows XP Professional ou Windows Server 2003.

      • Se o servidor de rede da Microsoft: as comunicações assinadas digitalmente (sempre) estiverem desabilitadas, a assinatura SMB estará completamente desabilitada. Desabilitar completamente todas as assinaturas SMB deixa os computadores mais vulneráveis a ataques de sequestro de sessão.

    4. Motivos para desabilitar essa configuração

      • Habilitar essa configuração pode causar uma cópia de arquivo mais lenta e desempenho de rede em computadores cliente.

      • Habilitar essa configuração impedirá que os clientes que não podem negociar a assinatura SMB se comuniquem com servidores e com controladores de domínio. Isso faz com que operações como junções de domínio, autenticação de usuário e computador ou acesso à rede por programas falhem.

    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: os clientes do Windows 95 que não têm o cliente DS (Serviços de Diretório) instalado falharão na autenticação de logon e receberão a seguinte mensagem de erro:

        A senha de domínio fornecida não está correta ou o acesso ao servidor de logon foi negado.

      • Windows NT 4.0: os computadores cliente que executam versões do Windows NT 4.0 anteriores ao Service Pack 3 (SP3) falharão na autenticação de logon e receberão a seguinte mensagem de erro:

        O sistema não pôde fazer logon. Verifique se seu nome de usuário e seu domínio estão corretos e digite sua senha novamente.

        Alguns servidores SMB não Microsoft dão suporte apenas a trocas de senha não criptografadas durante a autenticação. (Essas trocas também conhecidas como trocas de "texto sem formatação".) Para 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ê adicione uma entrada específica do Registro.
        Para habilitar senhas não criptografadas para o cliente SMB no 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

         

      • Windows Server 2003: por padrão, as configurações de segurança em controladores de domínio que executam o Windows Server 2003 são configuradas para ajudar a impedir que as comunicações do controlador de domínio sejam interceptadas ou adulteradas por usuários mal-intencionados. Para que os usuários se comuniquem com êxito com um controlador de domínio que executa o Windows Server 2003, os computadores cliente devem usar 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 o Service Pack 2 (SP2) ou instalados anteriormente e os clientes que executam o Windows 95 não têm a assinatura de pacote SMB habilitada. Portanto, esses clientes podem não ser capazes de se autenticar em um controlador de domínio baseado no Windows Server 2003.

      • Configurações de política do Windows 2000 e do Windows Server 2003: dependendo de suas necessidades de instalação e configuração específicas, recomendamos que você defina as seguintes configurações de política na entidade mais baixa do escopo necessário na hierarquia de snap-in do Editor do Microsoft Management Console Política de Grupo:

        • Configuração do Computador\Segurança do Windows Configurações\Opções de Segurança

        • Enviar senha não criptografada para se conectar a servidores SMB de terceiros (essa configuração é para o Windows 2000)

        • Cliente de rede da Microsoft: enviar senha não criptografada para servidores SMB de terceiros (essa configuração é para o Windows Server 2003)


        Observação Em alguns servidores CIFS de terceiros, como versões mais antigas do Samba, você não pode usar senhas criptografadas.

      • Os seguintes clientes são incompatíveis com o servidor de rede da Microsoft: assinar digitalmente a configuração de comunicações (sempre):

        • Apple Computer, Inc., clientes Mac OS X

        • Clientes de rede do Microsoft MS-DOS (por exemplo, Microsoft LAN Manager)

        • Clientes do Microsoft Windows for Workgroups

        • Clientes do Microsoft Windows 95 sem o cliente DS instalado

        • Microsoft Windows NT computadores baseados em 4.0 sem SP3 ou posterior instalado

        • Clientes CIFS do Novell Netware 6

        • 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 servidor. Para fazer isso, digite os comandos a seguir em um prompt de comando. Pressione Enter depois de digitar cada comando.

      net stop server
      net start server

  7. Acesso à rede: permitir a conversão anônima de SID/nome

    1. Fundo

      O acesso à rede: permitir a configuração de segurança anônima de conversão de SID/nome determina se um usuário anônimo pode solicitar atributos de SID (Número de Identificação de Segurança) para outro usuário.

    2. Configuração arriscada

      Habilitar o acesso à rede: permitir a definição de conversão anônima de SID/Nome é uma configuração prejudicial.

    3. Motivos para habilitar essa configuração

      Se a configuração de acesso à rede: Permitir a conversão anônima de SID/Nome estiver desabilitada, sistemas operacionais ou aplicativos anteriores poderão não conseguir se comunicar com domínios do Windows Server 2003. Por exemplo, os seguintes sistemas operacionais, serviços ou aplicativos podem não funcionar:

      • Windows NT do Serviço de Acesso Remoto baseado em 4.0

      • Microsoft SQL Server que estão em execução Windows NT computadores baseados em 3.x ou Windows NT baseados em 4.0

      • Serviço de Acesso Remoto em execução em computadores baseados no Windows 2000 localizados em domínios do Windows NT 3.x ou domínios Windows NT 4.0

      • SQL Server em execução em computadores baseados no Windows 2000 localizados em domínios do Windows NT 3.x ou em domínios Windows NT 4.0

      • Usuários no domínio de recursos do Windows NT 4.0 que desejam conceder permissões para acessar arquivos, pastas compartilhadas e objetos do Registro para contas de usuário de domínios de conta que contêm controladores de domínio do Windows Server 2003

    4. Motivos para desabilitar essa configuração

      Se essa configuração estiver habilitada, um usuário mal-intencionado poderá usar o CONHECIDO SID de Administradores para obter o nome real da conta de Administrador interna, mesmo que a conta tenha sido renomeada. Essa pessoa pode usar o nome da conta para iniciar um ataque de adivinhação de senha.

    5. Nome simbólico: N/A

    6. Caminho do Registro: Nenhum. O caminho é especificado no código da interface do usuário.

    7. Exemplos de problemas de compatibilidade Windows NT 4.0: computadores

      em domínios de recursos do Windows NT 4.0 exibirão a mensagem de erro "Conta Desconhecida" no Editor de ACL se os recursos, incluindo pastas compartilhadas, arquivos compartilhados e objetos do Registro, forem protegidos com entidades 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 SAM

    1. Tela de fundo

      • O acesso à rede: Não permitir enumeração anônima da configuração de contas SAM determina quais permissões adicionais serão concedidas para conexões anônimas com o computador. O Windows permite que usuários anônimos executem determinadas atividades, como enumerar os nomes de contas sam (security accounts manager) da estação de trabalho e do servidor e de 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 mantém uma relação de confiança recíproca. Depois que uma sessão é feita, um usuário anônimo pode ter o mesmo acesso concedido ao grupo Todos com base na configuração no acesso à rede: Permitir que as permissões de Todos se apliquem à configuração de usuários anônimos ou à DACL (lista de controle de acesso discricionário) do objeto.

        Normalmente, as conexões anônimas são solicitadas por versões anteriores de clientes (clientes de nível inferior) durante a configuração da sessão SMB. Nesses casos, um rastreamento de rede mostra que a ID do Processo SMB (PID) é o redirecionador de cliente, como 0xFEFF no Windows 2000 ou 0xCAFE no Windows NT. O RPC também pode tentar fazer conexões anônimas.

      • Importante Esta configuração não tem impacto sobre controladores de domínio. Em controladores de domínio, esse comportamento é controlado pela presença de "NT AUTHORITY\ANONYMOUS LOGON" em "Acesso compatível com o Windows 2000".

      • No Windows 2000, uma configuração semelhante chamada Restrições Adicionais para Conexões Anônimas gerencia o valor do Registro RestrictAnonymous . O local desse valor é o seguinte

        HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA  

    2. Configurações arriscadas

      Habilitar o acesso à rede: não permitir a enumeração anônima da configuração de contas SAM é uma configuração prejudicial de uma perspectiva de compatibilidade. Desabilitá-la é uma configuração prejudicial de uma perspectiva de segurança.

    3. Motivos para habilitar essa configuração

      Um usuário não autorizado pode listar anonimamente nomes de conta e, em seguida, usar as informações para tentar adivinhar senhas ou executar ataques de engenharia social. A engenharia social é um jargão que significa enganar as pessoas para revelar suas senhas ou alguma forma de informações de segurança.

    4. Motivos para desabilitar essa configuração

      Se essa configuração estiver habilitada, será impossível estabelecer relações de confiança com Windows NT domínios 4.0. Essa configuração também causa problemas com clientes de nível inferior (como clientes do Windows NT 3.51 e clientes do 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

    • A Descoberta de Rede sms não poderá obter informações do sistema operacional e gravará "Desconhecido" na propriedade OperatingSystemNameandVersion.

    • Windows 95, Windows 98: clientes do Windows 95 e clientes do Windows 98 não poderão alterar suas senhas.

    • Windows NT 4.0: Windows NT computadores membros baseados em Windows NT 4.0 não poderão ser autenticados.

    • Windows 95, Windows 98: computadores baseados no Windows 95 e windows 98 não poderão ser autenticados por controladores de domínio da Microsoft.

    • Windows 95, Windows 98: Os usuários em computadores baseados no Windows 95 e no 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 compartilhamentos e contas SAM

    1. Tela de fundo

      • O acesso à rede: Não permitir enumeração anônima de contas SAM e configuração de compartilhamentos (também conhecido como RestrictAnonymous) determina se a enumeração anônima de contas e compartilhamentos sam (Gerenciador de Contas de Segurança) é permitida. O Windows permite que usuários anônimos executem determinadas atividades, como enumerar os nomes de contas de domínio (usuários, computadores e grupos) e de compartilhamentos de rede. Isso é conveniente, por exemplo, quando um administrador deseja conceder acesso a usuários em um domínio confiável que não mantém uma relação de confiança recíproca. Se você não quiser permitir a enumeração anônima de contas SAM e de compartilhamentos, habilite essa configuração.

      • No Windows 2000, uma configuração semelhante chamada Restrições Adicionais para Conexões Anônimas gerencia o valor do Registro RestrictAnonymous . O local desse valor é o seguinte:

        HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA

    2. Configuração arriscada

      Habilitar o acesso à rede: não permitir a enumeração anônima de contas SAM e configuração de compartilhamentos é uma configuração prejudicial.

    3. Motivos para habilitar essa configuração

      • Habilitando o acesso à rede: não permitir a enumeração anônima de contas SAM e configuração de compartilhamentos impede a enumeração de contas SAM e compartilhamentos por usuários e computadores que estão usando contas anônimas.

    4. Motivos para desabilitar essa configuração

      • Se essa configuração estiver habilitada, um usuário não autorizado poderá listar anonimamente nomes de conta e, em seguida, usar as informações para tentar adivinhar senhas ou executar ataques de engenharia social. A engenharia social é um jargão que significa enganar as pessoas para revelar sua senha ou alguma forma de informação de segurança.

      • Se essa configuração estiver habilitada, será impossível estabelecer relações de confiança com Windows NT domínios 4.0. Essa configuração também causará problemas com clientes de nível inferior, como clientes Windows NT 3.51 e Windows 95 que estão tentando usar recursos no servidor.

      • Será impossível conceder acesso a usuários de domínios de recursos porque os administradores no domínio confiante não poderão enumerar listas de contas no outro domínio. Os usuários que acessam arquivos e servidores de impressão anonimamente não poderão listar os recursos de rede compartilhados nesses servidores. Os usuários devem se 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 estações de trabalho do Windows NT 4.0 quando RestrictAnonymous estiver habilitado em controladores de domínio no domínio dos usuários.

      • Windows NT 4.0: a adição de usuários ou grupos globais de domínios confiáveis do Windows 2000 a grupos locais do Windows NT 4.0 no Gerenciador de Usuários falhará e a seguinte mensagem de erro será exibida:

        No momento, não há servidores de logon disponíveis para a solicitação de logon de serviço.

      • Windows NT 4.0: computadores baseados no Windows NT 4.0 não poderão ingressar em domínios durante a instalação ou usando a interface do usuário de ingresso no domínio.

      • Windows NT 4.0: o estabelecimento de uma relação de confiança de nível inferior com Windows NT domínios de recursos do Windows NT 4.0 falhará. A seguinte mensagem de erro será exibida quando RestrictAnonymous estiver habilitado no domínio confiável:

        Não foi possível localizar o controlador de domínio para este domínio.

      • Windows NT 4.0: os usuários que fizerem logon em computadores do Servidor de Terminal baseados no Windows NT 4.0 serão mapeados para o diretório base padrão em vez do diretório base definido no Gerenciador de Usuários para domínios.

      • Windows NT 4.0: os BDCs (controladores de domínio de backup) do Windows NT 4.0 não poderão iniciar o serviço de Logon net, obter uma lista de navegadores de backup ou sincronizar o banco de dados SAM do Windows 2000 ou dos controladores de domínio do Windows Server 2003 no mesmo domínio.

      • Windows 2000: Computadores membros baseados no Windows 2000 em domínios do Windows NT 4.0 não poderão exibir impressoras em domínios externos se a configuração Sem acesso sem permissões explicitamente anônimas estiver habilitada na política de segurança local do computador cliente.

      • Windows 2000: os 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 depois de selecioná-las no modo de exibição de árvore.

      • Windows 2000: Em computadores baseados no Windows 2000, o Editor de ACL não poderá adicionar usuários ou grupos globais de domínios confiáveis do Windows NT 4.0.

      • ADMT versão 2: A migração de senha para contas de usuário migradas entre florestas com a ADMT (Ferramenta de Migração do Active Directory) versão 2 falhará.

        Para obter mais informações, clique no seguinte número de artigo para exibir o artigo na Base de Dados de Conhecimento Microsoft:

        322981 Como solucionar problemas de migração de senha entre florestas com ADMTv2

      • Clientes do Outlook: a lista de endereços global aparecerá vazia para clientes do Microsoft Exchange Outlook.

      • SMS: A Descoberta de Rede do Sms (Microsoft Systems Management Server) não poderá obter as informações do sistema operacional. Portanto, ele gravará "Unknown" na propriedade OperatingSystemNameandVersion da propriedade DDR sms do DDR (registro de dados de descoberta).

      • SMS: Quando você usa o Assistente de Usuário do Administrador de 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. O acesso anônimo é necessário no Ponto de Gerenciamento.

      • SMS: Quando você estiver usando o recurso descoberta de rede no SMS 2.0 e na Instalação de Cliente Remoto com a opção de descoberta de rede de sistemas operacionais cliente, cliente e topologia ativada, os computadores podem ser descobertos, mas podem não estar instalados.

  10. Segurança de rede: nível de autenticação do Lan Manager

    1. Fundo

      A autenticação LM (LAN Manager) é o protocolo usado para autenticar clientes do Windows para operações de rede, incluindo junções de domínio, acesso a recursos de rede e autenticação de usuário ou computador. O nível de autenticação lm determina qual protocolo de autenticação de desafio/resposta é negociado entre o cliente e os computadores do servidor. Especificamente, o nível de autenticação lm determina quais protocolos de autenticação 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 que os clientes usam, o nível de segurança de sessão negociado e o nível de autenticação aceito pelos servidores.

      As configurações possíveis incluem o seguinte.

      Valor

      Configuração

      Descrição

      0

      Enviar respostas & NTLM do LM

      Os clientes usam autenticação LM e NTLM e nunca usam segurança de sessão NTLMv2. Os controladores de domínio aceitam autenticação LM, NTLM e NTLMv2.

      1

      Send LM & NTLM – use a segurança de sessão NTLMv2, se negociada

      Os clientes usam autenticação LM e NTLM e usam a segurança de sessão NTLMv2 se o servidor der suporte a ela. Os controladores de domínio aceitam autenticação LM, NTLM e NTLMv2.

      2

      Enviar somente resposta NTLM

      Os clientes usam somente autenticação NTLM e usam a segurança de sessão NTLMv2 se o servidor der suporte a ela. Os controladores de domínio aceitam autenticação LM, NTLM e NTLMv2.

      3

      Enviar somente resposta NTLMv2

      Os clientes usam somente autenticação NTLMv2 e usam a segurança de sessão NTLMv2 se o servidor der suporte a ela. Os controladores de domínio aceitam autenticação LM, NTLM e NTLMv2.

      4

      Enviar somente resposta NTLMv2/recusar LM

      Os clientes usam somente autenticação NTLMv2 e usam a segurança de sessão NTLMv2 se o servidor der suporte a ela. Os controladores de domínio recusam LM e aceitam apenas autenticação NTLM e NTLMv2.

      5

      Enviar resposta NTLMv2 somente/recusar LM & NTLM

      Os clientes usam somente autenticação NTLMv2 e usam a segurança de sessão NTLMv2 se o servidor der suporte a ela. Os controladores de domínio recusam LM e NTLM e aceitam apenas a autenticação NTLMv2.

      Observação No Windows 95, Windows 98 e Windows 98 Second Edition, o Cliente de Serviços de Diretório usa a assinatura SMB quando autentica com servidores Windows Server 2003 usando a autenticação NTLM. No entanto, esses clientes não usam a assinatura SMB quando se autenticam com esses servidores usando a autenticação NTLMv2. Além disso, os servidores Windows 2000 não respondem a solicitações de assinatura SMB desses clientes.

      Verifique o nível de autenticação lm: você deve alterar a política no servidor para permitir o NTLM ou configurar o computador cliente para dar suporte a NTLMv2.

      Se a política estiver definida como (5) Enviar resposta NTLMv2 somente\recusar LM & NTLM no computador de destino ao qual você deseja se conectar, você deverá diminuir a configuração nesse computador ou definir a segurança para a mesma configuração que está no computador de origem do qual você está se conectando.

      Localize o local correto em que você pode alterar o nível de autenticação do gerenciador de LAN para definir o cliente e o servidor para o mesmo nível. Depois de encontrar a política que está definindo o nível de autenticação do gerenciador de LAN, se você quiser se conectar a computadores que executam versões anteriores do Windows, reduza o valor para pelo menos (1) Send LM & NTLM – use a segurança de sessão NTLM versão 2, se negociada. Um efeito de configurações incompatíveis é que, se o servidor exigir NTLMv2 (valor 5), mas o cliente estiver configurado para usar somente LM e NTLMv1 (valor 0), o usuário que tentar autenticação apresentará uma falha de logon que tem uma senha incorreta e que incrementa a contagem de senhas incorretas. Se o bloqueio de conta estiver configurado, o usuário poderá ser bloqueado eventualmente.

      Por exemplo, talvez seja necessário examinar o controlador de domínio ou examinar as políticas do controlador de domínio.

      Examinar o controlador de domínio

      Observe que talvez seja necessário repetir o procedimento a seguir em todos os controladores de domínio.

      1. Clique em Iniciar, aponte para Programas e clique em Ferramentas Administrativas.

      2. Em Configurações de Segurança Local, expanda Políticas Locais.

      3. Clique em Opções de Segurança.

      4. Clique duas vezes em Segurança de Rede: nível de autenticação do gerenciador de LAN e clique em um valor na lista.


      Se a Configuração Efetiva e a Configuração Local forem iguais, a política será alterada nesse nível. Se as configurações forem diferentes, você deverá verificar a política do controlador de domínio para determinar se a configuração de nível de autenticação segurança de rede: lan manager está definida lá. Se ele não estiver definido lá, examine as políticas do controlador de domínio.

      Examinar as políticas do controlador de domínio

      1. Clique em Iniciar, aponte para Programas e clique em Ferramentas Administrativas.

      2. Na política de Segurança do Controlador de Domínio, expanda As Configurações de Segurança e, em seguida, expanda Políticas Locais.

      3. Clique em Opções de Segurança.

      4. Clique duas vezes em Segurança de Rede: nível de autenticação do gerenciador de LAN e clique em um valor na lista.


      Nota

      • Talvez você também precise verificar as políticas vinculadas no nível do site, no nível do domínio ou no nível da UO (unidade organizacional) para determinar onde você deve configurar o nível de autenticação do gerenciador de LAN.

      • Se você implementar uma configuração Política de Grupo como a política de domínio padrão, a política será aplicada a todos os computadores no domínio.

      • Se você implementar uma configuração Política de Grupo como a política do controlador de domínio padrão, a política se aplicará somente aos servidores na UO do controlador de domínio.

      • É uma boa ideia definir o nível de autenticação do gerenciador de LAN na entidade mais baixa do escopo necessário na hierarquia do aplicativo de política.

      O Windows Server 2003 tem uma nova configuração padrão para usar somente NTLMv2. Por padrão, os controladores de domínio baseados em Windows Server 2003 e Windows 2000 Server SP3 habilitam a política "Servidor de rede da Microsoft: assinar comunicações digitalmente (sempre)". Essa configuração exige que o servidor SMB execute a assinatura de pacotes SMB. Alterações no Windows Server 2003 foram feitas porque controladores de domínio, servidores de arquivos, servidores de infraestrutura de rede e servidores Web em qualquer organização exigem configurações diferentes para maximizar sua segurança.

      Se você quiser implementar a autenticação NTLMv2 em sua rede, verifique se todos os computadores no domínio estão definidos para usar esse nível de autenticação. Se você aplicar extensões de cliente do Active Directory para Windows 95 ou Windows 98 e Windows NT 4.0, as extensões de cliente usarão os recursos de autenticação aprimorados que estão disponíveis no NTLMv2. Como os computadores cliente que executam qualquer um dos seguintes sistemas operacionais não são afetados pelo Windows 2000 Política de Grupo Objects, talvez seja necessário configurar manualmente esses clientes:

      • Microsoft Windows NT 4.0

      • Microsoft Windows Millennium Edition

      • Microsoft Windows 98

      • Microsoft Windows 95

      Observação Se você habilitar a segurança de rede: não armazene o valor de hash do gerenciador de LAN na próxima política de alteração de senha ou defina a chave do Registro NoLMHash , os clientes baseados no Windows 95 e windows 98 que não têm o Cliente de Serviços de Diretório instalado não poderão fazer 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 apenas NTLM. Portanto, níveis maiores que 2 não permitem conectividade. Também há clientes SMB de terceiros que não usam segurança de sessão estendida. Nesses casos, o LmCompatiblityLevel do servidor de recursos não é levado em consideração. Em seguida, o servidor empacota essa solicitação herdada e a envia para o Controlador de Domínio do Usuário. As configurações no Controlador de Domínio decidem quais hashes são usados para verificar a solicitação e se eles estão a atender aos requisitos de segurança do Controlador de Domínio.

       

      299656 Como impedir que o Windows armazene um hash do gerenciador de LAN de sua senha no Active Directory e bancos de dados SAM locais
       

      2701704O evento de auditoria mostra o pacote de autenticação como NTLMv1 em vez de NTLMv2 Para obter mais informações sobre níveis de autenticação lm, clique no seguinte número de artigo para exibir o artigo na Base de Dados de Conhecimento Microsoft:

      239869 Como habilitar a autenticação NTLM 2
       

    2. Configurações arriscadas

      A seguir estão as definições de configuração prejudiciais:

      • Configurações não complexas que enviam senhas em texto não criptografado e que negam a negociação NTLMv2

      • Configurações restritivas que impedem que clientes ou controladores de domínio incompatíveis negociam um protocolo de autenticação comum

      • Exigir autenticação NTLMv2 em computadores membros e controladores de domínio que estejam executando versões do Windows NT 4.0 anteriores ao Service Pack 4 (SP4)

      • Exigir autenticação NTLMv2 em clientes do Windows 95 ou em clientes do Windows 98 que não têm o Cliente de Serviços de Diretório do Windows instalado.

      • Se você clicar para marcar a caixa de seleção Exigir segurança de sessão NTLMv2 no snap-in editor do Console de Gerenciamento microsoft Política de Grupo em um computador baseado no Windows Server 2003 ou Windows 2000 Service Pack 3 e diminuir o nível de autenticação do gerenciador de LAN para 0, as duas configurações entrarão em conflito e você poderá receber a seguinte mensagem de erro no arquivo Secpol.msc ou no arquivo GPEdit.msc:

        O Windows não pode abrir o banco de dados de política local. Erro desconhecido ao tentar abrir o banco de dados.

        Para obter mais informações sobre a Ferramenta de Configuração e Análise de Segurança, consulte os arquivos da Ajuda do Windows 2000 ou do Windows Server 2003.

    3. Motivos para modificar essa configuração

      • Você deseja aumentar o protocolo de autenticação mais baixo que tem suporte de clientes e controladores de domínio em sua organização.

      • Quando a autenticação segura é um requisito de negócios, você deseja não permitir a negociação dos protocolos LM e NTLM.

    4. Motivos para desabilitar essa configuração

      Os requisitos de autenticação de cliente ou servidor, ou ambos, foram aumentados para o ponto em que a autenticação em 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, a configuração de respostas NTLM do Envio de NTLM do Windows Server 2003 está habilitada. 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 baseado no Windows NT 4.0 ou a servidores baseados em LanManager V2.1, como Lanserver os/2. Esse problema também ocorrerá se você tentar se conectar de um cliente de versão anterior a um servidor baseado no Windows Server 2003.

      • Instale o Pacote cumulativo de atualizações de segurança 1 (SRP1) do Windows 2000. O SRP1 força o NTLM versão 2 (NTLMv2). Este pacote cumulativo de atualizações foi lançado após o lançamento do Windows 2000 Service Pack 2 (SP2).
         

      • Windows 7 e Windows Server 2008 R2: muitos servidores CIFS de terceiros, como novell Netware 6 ou servidores Samba baseados em Linux, não estão cientes de NTLMv2 e usam apenas NTLM. Portanto, níveis maiores que "2" não permitem conectividade. Agora, nesta versão do sistema operacional, o padrão para LmCompatibilityLevel foi alterado para "3". Portanto, quando você atualiza o Windows, esses filers de terceiros podem parar de funcionar.

      • Os clientes do Microsoft Outlook podem ser solicitados a fornecer credenciais, mesmo que já estejam conectados ao domínio. Quando os usuários fornecem suas credenciais, eles recebem a seguinte mensagem de erro: 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.

        Ao iniciar o Outlook, você poderá ser solicitado a fornecer suas credenciais mesmo que a configuração de Segurança de Rede de Logon esteja definida como Passagem ou Autenticação de Senha. Depois de digitar suas credenciais corretas, você poderá 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 RPC (chamada de procedimento remoto) 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 na sessão do bloco de mensagens do servidor (SMB) NetBIOS sobre TCP/IP (NetBT):

        Erro dos dos diretórios de pesquisa do SMB R, (5) ACCESS_DENIED (109) STATUS_LOGON_FAILURE (91) Identificador de usuário inválido

      • Windows 2000: se um domínio do Windows 2000 com NTLMv2 Nível 2 ou posterior for confiável por um domínio do Windows NT 4.0, os computadores membros baseados no Windows 2000 no domínio de recursos poderão ter erros de autenticação.

      • Windows 2000 e Windows XP: por padrão, o Windows 2000 e o Windows XP definem a opção política de segurança local no nível de autenticação do LAN Manager como 0. Uma configuração de 0 significa "Enviar respostas LM e NTLM".

        Observe Windows NT clusters baseados em 4.0 devem usar LM para administração.

      • Windows 2000: o clustering do Windows 2000 não autenticará um nó de junção se ambos os nós fizerem parte de um domínio do Windows NT 4.0 Service Pack 6a (SP6a).

      • A Ferramenta de Bloqueio do IIS (HiSecWeb) define o valor LMCompatibilityLevel como 5 e o valor RestrictAnonymous como 2.

      • Serviços para Macintosh

        UAM (Módulo de Autenticação de Usuário): o Microsoft UAM (Módulo de Autenticação de Usuário) fornece um método para criptografar as senhas que você usa para fazer logon nos servidores do Windows AFP (Protocolo de Arquivamento do AppleTalk). O UAM (Módulo de Autenticação de Usuário) da Apple fornece apenas criptografia mínima ou nenhuma. Portanto, sua senha pode ser facilmente interceptada na LAN ou na Internet. Embora o UAM não seja necessário, ele fornece autenticação criptografada para servidores Windows 2000 que executam o Services For Macintosh. Esta versão inclui suporte para autenticação criptografada NTLMv2 de 128 bits e uma versão compatível com MacOS X 10.1.

        Por padrão, o servidor Windows Server 2003 Services para Macintosh permite apenas a Autenticação da Microsoft.
         

      • Windows Server 2008, Windows Server 2003, Windows XP e Windows 2000: se você configurar o valor LMCompatibilityLevel como 0 ou 1 e, em seguida, configurar o valor NoLMHash como 1, os aplicativos e componentes poderão ter acesso negado por meio do NTLM. Esse problema ocorre porque o computador está configurado para habilitar o LM, mas não para usar senhas armazenadas em LM.

        Se você configurar o valor noLMHash como 1, deverá configurar o valor LMCompatibilityLevel como 2 ou superior.

  11. Segurança de rede: requisitos de assinatura de cliente LDAP

    1. Fundo

      A segurança de rede: a configuração dos requisitos de assinatura de cliente LDAP determina o nível de assinatura de dados solicitado em nome de clientes que emitem solicitações BIND do Protocolo LDAP da seguinte maneira:

      • Nenhum: a solicitação LDAP BIND é emitida com as opções especificadas pelo chamador.

      • Negociar assinatura: se a SSL/TLS (Secure Sockets Layer/Transport Layer Security) não tiver sido iniciada, a solicitação LDAP BIND será iniciada com a opção de assinatura de dados LDAP definida, além das opções especificadas pelo chamador. Se o SSL/TLS tiver sido iniciado, a solicitação LDAP BIND será iniciada com as opções especificadas pelo chamador.

      • Exigir assinatura: isso é o mesmo que assinar Negotiate. No entanto, se a resposta SaslBindInProgress intermediária do servidor LDAP não indicar que a assinatura de tráfego LDAP é necessária, o chamador será informado de que a solicitação de comando LDAP BIND falhou.

    2. Configuração arriscada

      Habilitar a segurança de rede: a configuração de requisitos de assinatura de cliente LDAP é uma configuração prejudicial. Se você definir o servidor para exigir assinaturas LDAP, também deverá configurar a assinatura LDAP no cliente. Não configurar o cliente para usar assinaturas LDAP impedirá a comunicação com o servidor. Isso faz com que a autenticação do usuário, Política de Grupo configurações, scripts de logon e outros recursos falhem.

    3. Motivos para modificar essa configuração

      O tráfego de rede não assinado é suscetível a ataques man-in-the-middle em que um invasor captura pacotes entre o cliente e os servidores, modifica-os e os encaminha para o servidor. Quando isso ocorre em um servidor LDAP, um invasor pode fazer com que um servidor responda com base em consultas falsas do cliente LDAP. Você pode reduzir esse risco em uma rede corporativa implementando medidas de segurança física fortes para ajudar a proteger a infraestrutura de rede. Além disso, você pode ajudar a evitar todos os tipos de ataques man-in-the-middle 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: tamanho máximo do log de segurança

    1. Fundo

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

    2. Configurações arriscadas

      A seguir estão as definições de configuração prejudiciais:

      • Restringir o tamanho do log de segurança e o método de retenção do log de segurança quando a auditoria: desligar o sistema imediatamente se não for possível registrar em log a configuração de auditorias de segurança estiver habilitada. Consulte a seção "Auditoria: desligar o sistema imediatamente se não for possível registrar auditorias de segurança" deste artigo para obter mais detalhes.

      • Restringir o tamanho do log de segurança para que os eventos de segurança de interesse sejam substituídos.

    3. Motivos para aumentar essa configuração

      Os requisitos de segurança e negócios podem determinar que você aumente o tamanho do log de segurança para lidar com detalhes adicionais do log de segurança ou para manter os logs de segurança por um período mais longo.

    4. Motivos para diminuir essa configuração Visualizador de Eventos

      logs são arquivos mapeados em memória. O tamanho máximo de um log de eventos é restrito pela quantidade de memória física no computador local e pela memória virtual disponível para o processo de log de eventos. Aumentar o tamanho do log além da quantidade de memória virtual que está disponível para Visualizador de Eventos não aumenta o número de entradas de log mantidas.

    5. Exemplos de problemas de compatibilidade

      Windows 2000: Computadores que executam versões do Windows 2000 anteriores ao Service Pack 4 (SP4) podem interromper o registro em log de eventos no log de eventos antes de atingir o tamanho 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.


       

  13. Log de Eventos: Reter o log de segurança

    1. Fundo

      O Log de Eventos: manter a configuração de segurança do log de segurança determina o método de "encapsulamento" para o log de segurança. Para localizar essa configuração, expanda as Configurações do Windows e, em seguida, expanda as Configurações de Segurança.

    2. Configurações arriscadas

      A seguir estão as definições de configuração prejudiciais:

      • Falha ao reter todos os eventos de segurança registrados antes de serem substituídos

      • Definindo a configuração de tamanho máximo do log de segurança muito pequena para que os eventos de segurança sejam substituídos

      • Restringir o tamanho do log de segurança e o método de retenção enquanto a auditoria: desligar o sistema imediatamente se não for possível registrar em log a configuração de segurança de auditorias de segurança está habilitada

    3. Motivos para habilitar essa configuração

      Habilite essa configuração somente se você selecionar o método de retenção Substituir eventos por dias. Se você usar um sistema de correlação de eventos que sonda eventos, verifique se o número de dias é pelo menos três vezes a frequência da votação. Faça isso para permitir ciclos de sondagem com falha.

  14. Acesso à rede: permitir que as permissões de Todos se apliquem a usuários anônimos

    1. Fundo

      Por padrão, o acesso à rede: Permitir que as permissões de Todos se apliquem à configuração de usuários anônimos está definido como Não Definido no Windows Server 2003. Por padrão, o Windows Server 2003 não inclui o token de Acesso Anônimo no grupo Todos.

    2. Exemplo de problemas de compatibilidade

      O valor a seguir de

      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA\everyoneincludesanonymous [REG_DWORD]=0x0 interrompe a criação de confiança entre o Windows Server 2003 e o Windows NT 4.0, quando o domínio do Windows Server 2003 é o domínio da conta e o domínio Windows NT 4.0 é o domínio do recurso. Isso significa que o domínio da conta é confiável no Windows NT 4.0 e o domínio do recurso confia no lado do Windows Server 2003. Esse comportamento ocorre porque o processo para iniciar a relação de confiança após a conexão anônima inicial é ACL'd 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 definido usando um GPO na UO do controlador de domínio para: Acesso à rede: Permitir que as permissões de Todos se apliquem a usuários anônimos – Habilitadas para tornar as criações de confiança possíveis.

      Observe que a maioria das outras configurações de segurança subirá em valor em vez de 0x0 em seu estado mais seguro. Uma prática mais segura seria alterar o registro no emulador do controlador de 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 deverá ser atualizado no novo servidor.

      Uma reinicialização é necessária depois que esse valor é definido.

    4. Caminho do Registro

      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA\everyoneincludesanonymous

  15. Autenticação NTLMv2

    1. Segurança de sessão

      A segurança da sessão determina os padrões mínimos de segurança para sessões de cliente e servidor. É uma boa ideia verificar as seguintes configurações de política de segurança no snap-in do Editor do Microsoft Management Console Política de Grupo:

      • Configurações do Computador\Configurações do Windows\Configurações de Segurança\Políticas Locais\Opções de Segurança

      • Segurança de rede: segurança mínima de sessão para servidores NTLM SSP baseados (incluindo RPC seguro)

      • Segurança de rede: segurança mínima de sessão para clientes NTLM SSP baseados (incluindo RPC seguro)

      As opções para essas configurações são as seguintes:

      • Exigir integridade da mensagem

      • Exigir confidencialidade da mensagem

      • Exigir segurança de sessão NTLM versão 2

      • Exigir criptografia de 128 bits

      A configuração padrão antes do Windows 7 é Sem requisitos. A partir do Windows 7, o padrão foi alterado para Exigir criptografia de 128 bits para melhorar a segurança. Com esse padrão, os dispositivos herdados que não dão suporte à criptografia de 128 bits não poderão se conectar.

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

      Observe que, embora descritos como configurações válidas, os sinalizadores para exigir integridade e confidencialidade da mensagem não são usados quando a segurança da sessão NTLM é determinada.

      Historicamente, Windows NT dá suporte às duas variantes a seguir de autenticação de desafio/resposta para logons de rede:

      • Desafio/resposta lm

      • Desafio/resposta do NTLM versão 1

      O LM permite a interoperabilidade com a base instalada de clientes e servidores. O NTLM fornece segurança aprimorada para conexões entre clientes e servidores.

      As chaves do Registro correspondentes são as seguintes:

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

    2. Configurações arriscadas

      Essa configuração controla como as sessões de rede protegidas usando NTLM serão tratadas. Isso afeta sessões baseadas em RPC autenticadas com NTLM, por exemplo. Há os seguintes riscos:

      • Usar métodos de autenticação mais antigos do que NTLMv2 facilita o ataque da comunicação devido aos métodos de hash mais simples usados.

      • O uso de chaves de criptografia inferiores a 128 bits permite que os invasores interrompam a comunicação usando ataques de força bruta.

Sincronização de tempo

Falha na sincronização de tempo. O tempo de folga é de mais de 30 minutos em um computador afetado. Verifique se o relógio do computador cliente está sincronizado com o relógio do controlador de domínio.

Solução alternativa para assinatura SMB

Recomendamos que você instale o Service Pack 6a (SP6a) em clientes Windows NT 4.0 que interoperam em um domínio baseado no Windows Server 2003. Clientes baseados no Windows 98 Second Edition, clientes baseados no Windows 98 e clientes baseados no Windows 95 devem executar o Cliente de Serviços de Diretório para executar NTLMv2. Se os clientes baseados no Windows NT 4.0 não tiverem o Windows NT 4.0 SP6 instalado ou se clientes baseados no Windows 95, clientes baseados no Windows 98 e clientes baseados em Windows 98SE não tiverem o Cliente de Serviços de Diretório instalado, desabilite a assinatura SMB na configuração de política do controlador de domínio padrão na UO do controlador de domínio e vincule essa política a todas as UOs que hospedam controladores de domínio.

O Cliente de Serviços de Diretório para Windows 98 Second Edition, Windows 98 e Windows 95 executará a Assinatura SMB com servidores Windows 2003 sob autenticação NTLM, mas não sob autenticação NTLMv2. Além disso, os servidores Windows 2000 não responderão às solicitações de Assinatura SMB desses clientes.

Embora não o recomendemos, você pode impedir que a assinatura SMB seja necessária em todos os controladores de domínio que executam o Windows Server 2003 em um domínio. Para definir essa configuração de segurança, siga estas etapas:

  1. Abra a política do controlador de domínio padrão.

  2. Abra a pasta Configuração do Computador\Configurações do Windows\Configurações de Segurança\Políticas Locais\Opções de Segurança.

  3. Localize e clique no servidor de rede da Microsoft: assine digitalmente a configuração de política de comunicações (sempre) e clique em Desabilitado.

Importante Esta seção, método ou tarefa contém etapas que informam como modificar o registro. No entanto, poderão ocorrer problemas graves se você modificar o registro incorretamente. Portanto, certifique-se de seguir estas etapas com cuidado. Para proteção adicional, faça backup do registro antes de modificá-lo. Em seguida, você poderá restaurar o registro se ocorrer um problema. Para obter mais informações sobre como fazer backup e restaurar o registro, clique no seguinte número de artigo para exibir o artigo na Base de Dados de Conhecimento 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, siga estas etapas:

  1. Clique em Iniciar, clique em Executar, digite regedit e clique em OK.

  2. Localize e clique na seguinte subchave:
    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Lanmanserver\Parameters

  3. Clique na entrada enablesecuritysignature .

  4. No menu Editar , clique em Modificar.

  5. Na caixa de dados Valor , digite 0 e clique em OK.

  6. Saia do Editor do Registro.

  7. Reinicie o computador ou pare e reinicie o serviço servidor. Para fazer isso, digite os seguintes comandos em um prompt de comando e pressione Enter depois de 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 O seguinte lista os números de código de erro traduzidos para códigos de status e para as mensagens de erro textuais mencionadas anteriormente:

erro 5
ERROR_ACCESS_DENIED

O acesso é negado.

erro 1326



ERROR_LOGON_FAILURE Falha de logon: nome de usuário desconhecido ou senha incorreta.

erro 1788



ERROR_TRUSTED_DOMAIN_FAILURE Falha na relação de confiança entre o domínio primário e o domínio confiável.

erro 1789



ERROR_TRUSTED_RELATIONSHIP_FAILURE Falha na relação de confiança entre esta estação de trabalho e o domínio primário.

Para obter mais informações, clique nos seguintes números de artigo para exibir os artigos na Base de Dados de Conhecimento Microsoft:

324802 Como configurar políticas de grupo para definir a segurança para serviços do sistema no Windows Server 2003

816585 Como aplicar modelos de segurança predefinidos no Windows Server 2003

Precisa de mais ajuda?

Quer mais opções

Explore os benefícios da assinatura, procure cursos de treinamento, saiba como proteger seu dispositivo e muito mais.

As comunidades ajudam você a fazer e responder perguntas, fazer comentários e ouvir especialistas com conhecimento avançado.

Essas informações foram úteis?

Qual é o seu grau de satisfação com a qualidade do idioma?
O que afetou sua experiência?
Ao pressionar enviar, seus comentários serão usados para aprimorar os produtos e serviços da Microsoft. Seu administrador de TI poderá coletar esses dados. Política de Privacidade.

Agradecemos seus comentários!

×