DetailPage-MSS-KB

Base de Dados de Conhecimento

Artigo: 821839 - Última revisão: quinta-feira, 25 de Outubro de 2007 - Revisão: 1.4

 
importante : Este artigo contém informações sobre como modificar o registo. Antes de modificar o registo, certifique-se de que efectua uma cópia de segurança e de que compreende como o restaurar o registo se ocorrer um problema. Para obter informações sobre como efectuar uma cópia de segurança, restaurar e editar o registo, clique no número de artigo que se segue para visualizar o artigo na Microsoft Knowledge Base:
256986  (http://support.microsoft.com/kb/256986/EN-US/ ) Descrição do registo do Microsoft Windows

Nesta página

Sumário

Este artigo descreve a utilização de segurança do protocolo Internet (IPSec) em servidores back-end do Exchange 2003 em execução no cluster de servidor baseado no Windows Server 2003.

Microsoft Exchange 2003 em execução em computadores baseados no Windows Server 2003 suporta e utilizar o IPSec clusters do payload ESP (Encapsulating Security) para encriptar comunicações com servidores em cluster do Exchange 2003 que utilizam o balanceamento de carga em rede de modo de transporte ou clusters de servidor. Quando utiliza o IPSec entre servidores front-end e servidores back-end, horas de activação pós-falha dependem tempo de recuperação do Exchange 2003 e o tempo que demora para IPSec para renegociar associações de segurança durante o processo de activação pós-falha.

Mais Informação

Servidores front-end do Exchange 2003, tais como servidores Outlook Web Access (OWA) não é possível utilizar segura de sockets (SSL, Secure Sockets Layer) ou segurança da camada de transporte (TLS, Transport Layer Security) para encriptar o tráfego para servidores back-end do Exchange 2003. A comunicação entre servidores front-end e servidores back-end sempre utiliza formulários não encriptados do tráfego Hypertext Transfer protocolo (HTTP) Post Office Protocol versão 3 (POP3) ou Internet Messaging Access Protocol 4 (IMAP4) são utilizados.

No Exchange 2003, o protocolo HTTP utiliza a autenticação segura sempre que possível. Servidor front-end do Exchange 2003 utiliza a autenticação Kerberos ou NTLM para comunicar com o servidor back-end se o servidor back-end está configurado para aceitar a autenticação integrada do Windows. Isto ajuda a proteger informações de palavra-passe de utilizador de um utilizador mal intencionado que poderia tentar capturar o tráfego de rede entre o servidor front-end e servidor back-end.

O protocolo POP3 e o protocolo IMAP4 só podem utilizar a autenticação básica para comunicar com um servidor back-end. Devido a esta limitação, informações de palavra-passe de utilizador não estão protegidas contra um utilizador mal intencionado que poderia tentar capturar tráfego de rede entre o servidor front-end e servidor back-end.

A lista seguinte descreve algumas das razões por que razão poderá pretender utilizar o IPSec para estabelecer a fidedignidade e encriptar tráfego de rede entre um servidor front-end do Exchange 2003 e um servidor back-end:
  • O ambiente de rede pode requerer que as palavras-passe de utilizador ser encriptado. Isto é importante para os clientes POP3 e IMAP4 clientes que estiverem a utilizar um servidor front-end.
  • Poderá necessitar de encriptação de todos os dados o tráfego de rede entre o servidor front-end e servidor back-end. As mensagens de correio electrónico poderão ser consideradas sensíveis e devem ser encriptadas entre o servidor front-end e servidor back-end.
  • Poderá ter um firewall configurado entre o servidor front-end e servidor back-end que apenas permite ligações IPSec ou que pretende enviar tráfego de rede tudo através deste firewall através de uma única porta.
Para efectuar estas tarefas, pode configurar o IPSec para estabelecer a fidedignidade e para encriptar o tráfego de rede entre o servidor front-end e servidor back-end. Neste cenário é suportado no Windows Server 2003 se tecnologias de clustering são utilizadas ou não, mas o cenário só é suportado em configurações de Microsoft Windows 2000 Server que utilizam um ambiente sem clusters. Para mais informações sobre a utilização do IPSec num cluster do Windows 2000 Server ou um cluster com balanceamento de carga em rede, clique números de artigo que se seguem para visualizar os artigos na base de dados de conhecimento da Microsoft:
306677  (http://support.microsoft.com/kb/306677/EN-US/ ) IPSec não está concebido para a activação pós-falha
248346  (http://support.microsoft.com/kb/248346/ ) Sessões de L2TP perdidos quando adicionar um servidor a um cluster com balanceamento de carga em rede
Quando configura o IPSec num servidor back-end em cluster de servidor Windows Server 2003, o seguinte comportamento ocorre quando utiliza o utilitário administrador de clusters para mover um recurso de cluster que utiliza um endereço IP virtual:
  1. O endereço IP virtual através de programação é removido do primeiro nó de cluster.
  2. A remoção do endereço IP virtual a partir do primeiro nó de cluster faz com que o IPSec para "correctamente" Remover o estado de associação de segurança IPSec com o servidor front-end.
  3. Se o servidor front-end ainda tenta estabelecer ligação ao servidor de back-end, o protocolo de negociação IKE (IPSec Internet Key Exchange) tenta imediatamente para renegociar uma associação de segurança com o novo nó de cluster back-end.
  4. Quando o novo nó de cluster back-end configura-se com o endereço IP virtual, o componente IPSec nesse nó responde para o servidor front-end e estabelece novas associações de segurança IPSec.
Este procedimento pode demorar cerca de 3 a 6 segundos, mas o tempo real depende a carga da CPU em nós do cluster e as condições de rede existentes durante este processo.

Num cenário em que o nó de cluster back-end do serviço Microsoft Cluster deixa de responder (bloqueia), o serviço de cluster é iniciado o procedimento de activação pós-falha para o programa com clusters e o endereço IP virtual. No entanto, neste caso, o computador de IPSec front-end ainda acredita tem uma ligação segura para o endereço IP virtual. O componente IPSec utiliza o temporizador de inactividade para determinar que o nó de back-end já não existe. Num computador baseado no Windows 2000, o tempo de inactividade mínimo é de 5 minutos. Num computador baseado no Windows Server 2003, o tempo de inactividade automaticamente é reduzido para um minuto se a chave de registo NLBSFlags estiver definida. Assim que o IPSec remove as associações de segurança IPSec inactivas, o IKE tenta renegociação novas associações de segurança IPSec. Após 1 minuto, o IKE tenta estabelecer uma nova negociação de modo principal para o endereço IP virtual e, em seguida, for bem sucedido na criação de novas associações de segurança com o novo nó de cluster. Devido este procedimento, o tempo total necessário para IPSec para activação pós-falha é 6 minutos: tempo de inactividade IPSec de 5 minutos mais 1 minuto para IKE renegociar uma nova negociação de modo principal com o endereço IP virtual.

Para alterar a hora de renegociação

Para permitir que IPSec para renegociar a sessão para um nó de cluster back-end um curto período de tempo após uma activação pós-falha inesperado, defina o valor do registo NLBSFlags na seguinte subchave de registo no front-end Exchange 2003:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent\Oakley
Para o fazer:

aviso : a utilização incorrecta do Editor de registo poderá provocar problemas graves que poderão forçar a reinstalação do sistema operativo. Microsoft não garante que os problemas resultantes da utilização incorrecta do Editor de registo possam ser resolvidos. As suas próprias risco da utilização do Editor de registo.
  1. No servidor front-end do Exchange 2003, clique em Iniciar e, em seguida, clique em Executar .
  2. Na caixa Abrir , escreva regedit e, em seguida, clique em OK .
  3. Localize a seguinte subchave do registo:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent\Oakley
  4. No painel da direita, clique com o botão direito do rato SinalizadoresNLBS e, em seguida, clique em Modificar .
  5. Na caixa dados do valor , escreva 1 (um) e, em seguida, clique em OK .

    Nota Depois de definir o valor de registo NLBSFlags para 1 , o tempo total necessário para IPSec para activação pós-falha é de 2 minutos: 1 minuto para tempo de inactividade expirar mais 1 minuto o IKE para renegociar associações de segurança.
  6. Saia do Editor de registo.

Sugeridos estrutura da política IPSec

Enquanto este artigo não fornece instruções passo a passo sobre como configurar políticas IPSec, as implementações de política IPSec sugeridas seguintes podem ser utilizadas com o Exchange 2003:
  • Para encriptar palavras-passe de utilizador de POP3 e IMAP4 as palavras-passe de utilizador, utilize o IPSec para encriptar tráfego para os servidores de Exchange 2003 back-end na porta 110 (POP3) e a porta 143 (IMAP4).
  • Para encriptar a sequência de mensagem real aos servidores back-end Exchange 2003, utilize o IPSec para encriptar todo o tráfego para os servidores back-end na porta 80, porta 110 e porta 143.
  • Para encriptar todas as comunicações entre os servidores front-end do Exchange 2003 e servidores back-end Exchange 2003 e para controladores de domínio, encriptar tráfego de rede completo incluindo o tráfego seguinte:
    • Protocolo simples de acesso de directório (LDAP)
    • Chamada de procedimento remoto (RPC, Remote Procedure Call)
    • Kerberos
    • Comunicação de LDAP com servidores de catálogo global
Para obter informações adicionais sobre como configurar o IPSec, procure IPSec no Centro de suporte e ajuda do Windows Server 2003.

A informação contida neste artigo aplica-se a:
  • Microsoft Exchange Server 2003 Enterprise Edition
  • Microsoft Exchange Server 2003 Standard Edition
  • Microsoft Windows Server 2003 Datacenter Edition
  • Microsoft Windows Server 2003 Enterprise Edition
Palavras-chave: 
kbmt kbinfo KB821839 KbMtpt
Tradução automáticaTradução automática
IMPORTANTE: Este artigo foi traduzido por um sistema de tradução automática (também designado por Machine translation ou MT), não tendo sido portanto revisto ou traduzido por humanos. A Microsoft tem artigos traduzidos por aplicações (MT) e artigos traduzidos por tradutores profissionais. O objectivo é simples: oferecer em Português a totalidade dos artigos existentes na base de dados do suporte. Sabemos no entanto que a tradução automática não é sempre perfeita. Esta pode conter erros de vocabulário, sintaxe ou gramática… erros semelhantes aos que um estrangeiro realiza ao falar em Português. A Microsoft não é responsável por incoerências, erros ou estragos realizados na sequência da utilização dos artigos MT por parte dos nossos clientes. A Microsoft realiza actualizações frequentes ao software de tradução automática (MT). Obrigado.
Clique aqui para ver a versão em Inglês deste artigo: 821839  (http://support.microsoft.com/kb/821839/en-us/ )
Partilhar
Opções de suporte adicionais
Fóruns de Suporte da Comunidade Microsoft
Contacte-nos directamente
Encontre um parceiro certificado Microsoft
Loja Microsoft