TechNet Magazine > Home > Todas as edições > 2007 > July >  Comunicações: Logon no Outlook Web Ac...
Comunicações
Logon no Outlook Web Access com cartões inteligentes
Victor Akinnagbe and Ted Dressel and Jason Opdycke
 
Visão geral:
  • Autenticação de dois fatores
  • Delegação restrita de Kerberos
  • Configuração do ISA Server e do Exchange

Os funcionários móveis apresentam um desafio de segurança único para as organizações de TI. Os usuários remotos precisam de acesso seguro a dados e serviços como email. Contudo, infelizmente, a realidade é que os
os vínculos mais vulneráveis na cadeia de segurança envolvem senhas fracas, malware (como keyloggers) e vírus nos computadores remotos que acessam os recursos internos da sua organização.
Uma maneira de aumentar a segurança nesse ambiente móvel é remover um desses vínculos vulneráveis: as senhas (embora a idéia de permitir acesso a uma conta sem uma senha para autenticação possa parecer estranha). Uma técnica básica para eliminar os problemas associados às senhas é conhecida como autenticação de dois fatores (ou, às vezes, de multifatores). Em vez de contar com um único método, uma senha, para permitir acesso, a autenticação de dois fatores impõe o uso de métodos adicionais de autenticação, incluindo uma combinação de nome de usuário/senha, um dispositivo físico, como um cartão inteligente, ou um identificador biométrico, como impressão digital.
Se você tiver usuários remotos, provavelmente terá de abrir um pouco o seu firewall para permitir o acesso remoto à rede corporativa. Um firewall padrão proporciona uma redução básica de risco, fornecendo um isolamento no nível de rede entre as redes interna e externa (consulte a Figura 1). Para obter uma segurança adicional, as portas são simplesmente fechadas e, se a comunicação precisar acontecer com um dispositivo na rede interna, elas serão encaminhadas para o local correto. Essas técnicas fornecem uma proteção considerável no nível de rede, porém, agora várias camadas de segurança de rede tornaram-se necessárias devido a ataques cada vez mais sofisticados.
Figura 1 Firewall padrão com portas bloqueadas ou encaminhadas (Clique na imagem para aumentar a exibição)
Como os funcionários móveis com acesso aos serviços corporativos mais comuns, em geral, são aqueles que usam email e sistema de mensagens, a configuração da infra-estrutura do Exchange, sem dúvida, nunca foi tão importante. Fornecer aos usuários o acesso ao email por meio do OWA (Outlook® Web Access) é uma maneira de proporcionar serviços seguros aos funcionários móveis. Outra etapa-chave é fornecer uma autenticação segura de dois fatores para o OWA por meio de cartões inteligentes. Neste artigo, examinaremos com mais detalhes a configuração e os problemas que você deve conhecer ao fazer a implantação do OWA habilitado para cartão inteligente.

Melhor do que um firewall
A implantação do ISA (Microsoft® Internet Security and Acceleration) Server 2006 na sua rede pode simplificar a tarefa de abrir a rede para usuários remotos de maneira mais segura. O ISA Server 2006 inclui recursos de aprimoramento de segurança, como VPN habilitada para cartão inteligente, autenticação LDAP para o Active Directory® e delegação restrita de Kerberos. O ISA Server é um pouco diferente do que normalmente se entende por firewall. Ele apresenta várias camadas de segurança, não apenas funcionando na camada de rede, com ou sem o hardware de firewall padrão, mas também fornecendo recursos de segurança adicionais que normalmente não possuem suporte nos firewalls tradicionais, como filtros de aplicativos. Você não quer que ninguém use o método HTTP POST em um site hospedado em particular? Você quer forçar a conformidade RFC em mensagens SMTP antes que cheguem a seu servidor Exchange? Você quer inspecionar os pacotes HTTP SSL (Secure Sockets Layer) antes que eles entrem na rede? O ISA Server pode gerenciar todas essas tarefas e muito mais a fim de garantir que somente um tráfego limpo e filtrado seja encaminhado para a sua DMZ (zona desmilitarizada) ou rede interna.
As sessões SSL são um grande problema para os firewalls padrão. Quando passam pelo firewall, os pacotes permanecem criptografados (o que significa que o SSL está funcionando corretamente). Assim, se um aplicativo como o OWA for publicado por meio de um firewall de hardware ou software usando SSL, não haverá nenhum tipo de inspeção apreciável que possa ser feita pelo firewall padrão, a não ser a inspeção do estado do pacote. O simples fato de abrir e encaminhar portas pode deixar uma área exposta de superfície de ataque considerável. Como nenhuma inspeção real está acontecendo na borda, os pacotes não inspecionados ou não autenticados podem ser roteados para a rede interna.
O ISA Server 2006 pode atuar como um ponto de extremidade SSL para clientes HTTP, garantindo que somente o tráfego autorizado alcance o servidor Exchange publicado. O ISA Server oferece suporte a um recurso útil chamado ponte SSL. Normalmente, um pacote é criptografado por um cliente que se comunica por meio de uma sessão SSL padrão com o ISA Server. Com a ponte SSL, o ISA Server pode terminar a criptografia SSL localmente, inspecionar o pacote que, neste caso, não é criptografado, autenticar o usuário para o Active Directory (se necessário), criptografar novamente o pacote usando SSL e passar o pacote criptografado para o servidor Exchange apropriado (consulte aFigura 2). Usando essa técnica, a ponte SSL minimiza os ataques ocultos dentro de uma sessão SSL, que não pareceriam nada além de blobs de dados criptografados para um firewall sem suporte para aplicativo.
Figura 2 O ISA Server obtém uma exibição do tráfego na camada do aplicativo (Clique na imagem para aumentar a exibição)
O tráfego pré-autenticado que alcança o servidor é um ponto importante a se notar quanto à delegação restrita de Kerberos. Em um firewall padrão, as portas são simplesmente encaminhadas para o servidor Exchange, e o próprio servidor front-end é responsável por executar as tarefas de autenticação em relação aos possíveis usuários mal-intencionados. Quando a autenticação é necessária, o ISA Server pode contatar diretamente o Active Directory e fazer a solicitação de credenciais em nome do usuário. Se o usuário for autenticado com êxito, o ISA Server encaminhará a mensagem ao servidor front-end do Exchange. O servidor front-end não precisa mais autenticar solicitações aleatórias desconhecidas de usuário e pode ser usado unicamente para atuar como proxy nas solicitações a servidores back-end. O ISA Server 2005 também pode usar a delegação restrita de Kerberos para permitir acesso com base em certificado a tecnologias como Windows SharePoint Services e Exchange ActiveSync.
O Exchange Server 2003 incluiu suporte para autenticação com base em Kerberos entre servidores front-end e back-end para logins do OWA. (Você está usando IPsec para proteger o tráfego de cliente, certo?) O Exchange Server também oferece suporte à autenticação de Kerberos a servidores de caixa de correio em cluster.

Habilitando a autenticação de cartão inteligente
A implementação da autenticação com base em cartão inteligente para o OWA tornou-se um desafio. Entretanto, desenvolveu-se uma solução com base no recurso de delegação restrita de Kerberos que, agora, está disponível no ISA Server 2006. A solução permite ao usuário enviar credenciais por meio de um certificado a fim de obter uma autenticação bem-sucedida para o OWA. A delegação restrita veio como um aperfeiçoamento bem-vindo do suporte à delegação de Kerberos no Windows® 2000, que usava delegação irrestrita. A função restrita de Kerberos é mais segura e limita o possível risco de ataques sofisticados usando a representação.
No cenário habilitado para cartão inteligente, o ISA Server 2006 contata o Active Directory para autenticar o usuário, já que este não possui acesso roteável para o KDC (centro de distribuição de chaves) da rede externa. O ISA Server submete-se ao mapeamento de usuários de certificado do Active Directory para autenticar o usuário e adquire os tíquetes Kerberos com base no UPN (nome de usuário principal). Nesse caso, o ISA Server está fornecendo a funcionalidade de delegação restrita de Kerberos a um servidor front-end por meio dos serviços de proxy reverso e filtragem no nível de aplicativo. Se houvesse uma tentativa de delegação sem um proxy reverso, o maior risco de explorações poderia afetar a integridade da rede ou do domínio do Active Directory.
O Exchange Server 2003 e o 2007 permitem a autenticação básica e integrada. Entretanto, é necessário aplicar uma atualização de software ao Exchange Server 2003 para a autenticação com base em cartão inteligente de forma que o OWA funcione. (Para obter mais informações, consulte o artigo "Descrição do novo recurso do Exchange Server 2003 que oferece suporte à autenticação de cartão inteligente para o Outlook Web Access".) Você deve ter um domínio no modo funcional nativo do Windows Server® 2003, todos os servidores do Exchange Server 2003 devem ter o SP2 ou superior aplicado e você precisa de um servidor ISA Server 2006 atuando como proxy reverso para o site do OWA.
Depois de instalar a atualização de software e configurar os servidores do Exchange e ISA, os usuários poderão autenticar uma sessão do OWA usando cartões inteligentes. A Figura 3 mostra o fluxo de eventos necessário para a autenticação de cartão inteligente. Primeiro, o usuário abre o site do OWA no Internet Explorer® (1). Na verdade, ele se conecta ao ISA Server e é solicitado a fornecer um certificado, em vez de nome de usuário e senha, para iniciar a sessão do OWA. O certificado apropriado é armazenado no cartão inteligente, para o qual o usuário precisa de um PIN.
Figura 3 Autenticando o OWA com um cartão inteligente (Clique na imagem para aumentar a exibição)
A validação de certificado (2) é manipulada por meio de uma CRL (lista de certificados revogados) ou de uma solicitação OCSP (protocolo de status de certificados online), dependendo da configuração do ISA Server e de outro software instalado. O ISA Server faz uma solicitação para um DC (controlador de domínio) a fim de verificar as credenciais do usuário. Se a solicitação falhar, o ISA Server apresentará uma página de erro ao usuário e nenhuma solicitação chegará ao servidor front-end do Exchange.
Depois que as credenciais são verificadas, o tíquete Kerberos é gerado e a solicitação é passada para o servidor front-end do Exchange, usando autenticação integrada (3). Ao receber a solicitação, o servidor front-end do Exchange valida o tíquete Kerberos e localiza o servidor de caixa de correio back-end (4).
O servidor front-end solicita um tíquete Kerberos para o servidor back-end apropriado por meio da delegação restrita de Kerberos e atua como proxy na solicitação de caixa de correio para o servidor back-end, usando autenticação integrada (5). A solicitação é atendida pelo servidor back-end (6) e os dados de caixa de correio são retornados ao servidor front-end do Exchange (7). Os dados HTML para a página OWA são passados para o ISA Server (8), que os repassa de volta para o computador cliente (9).

Configurando o ambiente do Exchange
O artigo da Base de Dados de Conhecimento mencionado anteriormente descreve a atualização de software para o Exchange Server 2003 e inclui informações que ajudarão a guiá-lo no processo de habilitar a delegação restrita de Kerberos usando o ISA Server 2006 e o Exchange Server 2003.
A principal ação que a atualização de software permite é automatizar o processo de delegação restrita de Kerberos do servidor front-end do Exchange para os respectivos servidores back-end. A atualização não automatizará o processo de delegação restrita de Kerberos do ISA Server para o servidor front-end, já que o ISA Server não faz parte da organização do Exchange. A delegação terá de ser habilitada manualmente de cada instância do ISA Server para cada servidor front-end do Exchange.
A atualização de software adiciona uma nova guia no ESM (Gerenciador do Sistema do Exchange) que permite designar um servidor front-end do Exchange como um KCD-FE (consulte a Figura 4); este, por sua vez, permite que o servidor seja preenchido na guia de delegação dos respectivos servidores back-end do Exchange.
Figura 4 Habilitando a delegação restrita de Kerberos 
A nova interface do usuário permite especificar nas propriedades do Grupo Administrativo as credenciais que devem ser usadas para preencher o atributo msDS-AllowedToDelegateTo (A2D2), como mostra a Figura 5. Esse é o atributo responsável pela delegação restrita de Kerberos.
Figura 5 Configurando a conta que controla a delegação 
Respeitando o princípio do privilégio mínimo, você pode usar uma conta de usuário padrão e conceder-lhe a capacidade de delegar usuários e computadores por meio de um GPO (Objeto de Diretiva de Grupo). Depois que essa permissão elevada for concedida, a conta poderá ser usada como uma conta de serviço a fim de automatizar o processo de delegação restrita de Kerberos para o respectivo Grupo Administrativo.
Verifique se você executou as etapas apropriadas para impedir que um usuário mal-intencionado seja capaz de comprometer a conta de serviço de delegação restrita de Kerberos. Mesmo que a conta não seja de administrador de domínio, o acesso a ela poderia levar a ataques sofisticados que tirem vantagem da delegação de Kerberos. Como não possui a capacidade de estabelecer novas associações de Kerberos, a conta deve ser usada com cuidado. Tome as precauções necessárias para garantir a segurança e a integridade da conta: uma senha longa e complexa, aumento de auditoria, técnicas de desabilitação de conta e assim por diante.
A atualização de software do Exchange também faz uma alteração muito importante na interface ESM em relação à autenticação integrada. Anteriormente, no Exchange Server 2003, quando um servidor era atribuído como front-end, a opção para habilitar a Autenticação Integrada do Windows para Diretórios Virtuais HTTP (sob o Servidor Virtual HTTP) ficava cinza (consulte Figura 6).
Figura 6a A atualização habilita a autenticação integrada 
Figura 6b A atualização habilita a autenticação integrada 
Isso ocorria porque não havia suporte para a autenticação integrada nos servidores front-end do Exchange em decorrência de problemas técnicos, como o fato de que os servidores proxy interrompiam as sessões NTLM, os usuários empregando autenticação de Kerberos precisavam de uma conexão para o Active Directory e, normalmente, os usuários da Internet não faziam parte do domínio. A atualização descrita no artigo da Base de Dados de Conhecimento supramencionado exclui essas limitações. Com a atualização instalada, você pode simplesmente ir para o diretório virtual e marcar a caixa Autenticação Integrada do Windows como o mecanismo para verificar as credenciais do usuário. Quando marcada, ela define um atributo chamado msexchAuthenticationFlags no objeto de diretório virtual do Active Directory (para ver isso, use o snap-in Adsiedit.msc para o Console de Gerenciamento Microsoft).
Os usuários que verificam email por meio do OWA podem conhecer o nome dos servidores back-end do Exchange e se conectarem a eles usando autenticação integrada quando usarem a intranet corporativa. A diferença na experiência do usuário com a autenticação integrada é que, como você está conectado à rede, não é solicitado a fornecer nome de usuário e senha porque o Internet Explorer fará a autenticação no site automaticamente. Isso é ótimo para os usuários que usam a rede corporativa, mas os usuários externos — e os usuários do OWA em geral são externos — não se conectarão a um domínio quando estiverem fora da rede e fizerem logon em um servidor front-end do Exchange. (Esse processo é explicado em detalhes no artigo da Base de Dados de Conhecimento "Como o IIS autentica clientes de navegador".)
No Exchange Server, a atualização preenche a guia Delegação para usar o atributo A2D2, em vez do atributo SPN (nome da entidade de serviço) no Active Directory. Se examinar o objeto do computador do Exchange usando Adsiedit.msc, você notará dois atributos distintos: o atributo A2D2, que é a lista de delegação restrita de Kerberos, e o atributo SPN, que atua como um localizador de Kerberos e ponto de especificação de conta. Embora seja verdade que os dois atributos trabalhem juntos para que ocorra a delegação restrita de Kerberos, você deve modificar apenas o atributo A2D2 na interface gráfica.
O Windows pode usar o HOST SPN incorporado como alias para localizar outros serviços. Isso significa que setspn.exe não precisa ser usado para que a delegação restrita de Kerberos funcione na delegação de front-end para back-end do Exchange. (Embora especificar explicitamente HTTP/Servername na lista de atributos SPN funcione com esta solução, isso abre espaço para mais erros do administrador e não é necessário para que a delegação restrita de Kerberos funcione.) A delegação restrita de Kerberos está procurando o atributo A2D2 no Active Directory. Quando esse atributo não é preenchido (ou possui o valor SPN errado), a delegação restrita de Kerberos não funciona entre os respectivos servidores. Em um cluster do Exchange, porém, o atributo A2D2 do servidor front-end precisa apenas ser apontado para a conta do computador do nó do cluster para funcionar de forma apropriada.
Conforme observado anteriormente, um domínio do Windows Server 2003 contendo os servidores do Exchange 2003 deve estar no modo funcional nativo do Windows Server 2003. A delegação restrita de Kerberos não pode ser usada, a menos que esse nível de funcionalidade de domínio seja alcançado. Se o seu domínio ainda estiver no modo misto e você instalar a atualização de software discutida anteriormente, a princípio, parecerá que ela funciona, mas, na verdade, os registros SPN falharão. A delegação restrita de Kerberos também é uma função de domínio, e não uma função no nível de floresta. Isso significa que, para o Exchange Server 2003, os servidores front-end e back-end do ISA Server e do Exchange devem ser membros do mesmo domínio (embora usuários de diferentes domínios ainda possam autenticar a delegação restrita de Kerberos). A instância do ISA Server que não for membro de um domínio ou que for membro de um domínio diferente não funcionará como parte desta solução.

Configurando o site do OWA
O IIS Admin não deve ser usado para qualquer tipo de alteração de autenticação no OWA. Muito embora o OWA seja executado sob o IIS e responda às alterações na metabase como qualquer outro site da Web, o Exchange apresenta certa complexidade com o processo DS2MB (serviços de diretório para metabase). O processo DS2MB replicará as alterações do Active Directory para a metabase do IIS em um processo unidirecional que substituirá quaisquer alterações feitas diretamente no IIS. O impacto desse processo é que, se um administrador fizer uma alteração diretamente na metabase do IIS (como configurar a autenticação integrada), a solução parecerá funcionar, mas falhará assim que o ciclo da próxima replicação DS3MB começar.
A opção de habilitar a Autenticação Integrada do Windows para Diretórios Virtuais HTTP foi disponibilizada no ESM porque ele faz as edições diretamente no Active Directory, que replica a alteração para a metabase do IIS. Tenha em mente que, embora a interrupção do serviço do Atendedor do Sistema também interrompa o processo DS2MB, permitindo que as alterações sejam feitas na metabase do IIS e não sejam substituídas, isso não é aconselhável. Na próxima vez que for iniciado, o Atendedor do Sistema pesquisará as alterações no Active Directory e a solução será desabilitada automaticamente.
A guia Delegação mostra as opções Usar apenas Kerberos e Usar qualquer protocolo de autenticação. Pela lógica, você selecionaria Usar apenas Kerberos, já que a solução que estamos discutindo trata do uso da delegação restrita de Kerberos, mas essa é uma das muitas situações de TI em que a lógica comum não se aplica. Portanto, em vez disso, você deve selecionar Usar qualquer protocolo de autenticação (como mostra a Figura 7), pois a solicitação não chega como Kerberos, mas como HTTP com um certificado correspondente mapeado para uma conta do Active Directory.
Figura 7 Configurações corretas de autenticação para cartões inteligentes 
Nesse caso, o ISA Server está solicitando o certificado PKI do usuário sobre SSL. A solicitação de entrada não é um tíquete Kerberos, por isso, é necessário que aconteça uma transição para que a delegação restrita de Kerberos funcione de forma apropriada. Assim, se a configuração Usar apenas Kerberos for especificada, a cadeia de comunicação no ISA Server será interrompida. Observe, porém, que a opção Usar apenas Kerberos funcionará na delegação de servidor Exchange front-end para back-end, já que o servidor front-end apenas receberá tíquetes Kerberos do ISA Server.
Os diretórios virtuais \Exchange e \Public são os únicos locais que devem conter informações particulares do usuário e da pasta pública. A configuração SSL no Exchange não é nova para a delegação restrita de Kerberos ou para a autenticação de dois fatores, mas uma conseqüência da habilitação SSL padrão do OWA com credenciais de autenticação básica. Você deve seguir os métodos documentados para habilitar SSL no OWA porque, se incorretamente forçar SSL, poderá interromper o OWA e causar problemas com o ESM também.

Detalhes de configuração adicionais
Ao implementar esta solução, será muito mais fácil implantar o ISA Server e o Exchange da forma padrão primeiro. Não coloque a solução inteira de delegação restrita de Kerberos com todas as configurações definidas (especialmente se, antes, o ISA Server não fazia parte da sua implantação). Isso poderá complicar o processo de solução de problemas se um componente ou uma etapa falhar. É muito mais fácil implantar o ISA Server e o Exchange da forma padrão (com nome de usuário e senha, mas sem autenticação baseada em formulários), garantir que a instalação funcione e, depois, fazer a transição para a delegação restrita de Kerberos e a autenticação de certificação.
Normalmente, a autenticação baseada em formulários não pode ser usada com OWA habilitado para cartão inteligente. A autenticação baseada em formulários indica que um usuário possui um nome de usuário e uma senha para enviar por meio do formulário padrão do Outlook. Entretanto, com a autenticação de dois fatores baseada em cartão inteligente, o usuário terá somente um cartão inteligente e não uma senha. Assim, a autenticação baseada em formulários não poderá, de forma alguma, aceitar ou enviar apenas o certificado para autenticação. O uso da autenticação baseada em formulários em qualquer ponto da cadeia (por exemplo, no servidor front-end protegido pelo ISA Server) invalidará a configuração do OWA habilitado para cartão inteligente. Se você habilitar a autenticação baseada em formulários, o diretório virtual do Exchange obrigatoriamente será definido como Autenticação básica e o mesmo acontecerá com a metabase do IIS.
Se você tiver uma mistura de usuários que possuem nome de usuário/senha e cartão inteligente, poderá habilitar a autenticação de retorno no ouvinte da Web ISA, de maneira que, quando um usuário pressionar a tecla ESC ao ser solicitado a inserir as credenciais baseadas em certificado, terá de inserir as credenciais padrão de nome de usuário/senha mesmo que a Autenticação integrada esteja habilitada no ISA Server do servidor Exchange. Além disso, o ISA Server pode esgotar o tempo limite da sessão SSL da mesma forma que as funções de autenticação baseadas em formulários.

Conclusão
O suporte a cartão inteligente para autenticação no OWA é um acréscimo bem-vindo tanto para o Exchange Server 2003 quanto para o Exchange Server 2007. Com a capacidade de fazer logon no OWA usando um certificado, os usuários não precisam mais se esforçar para se lembrar de senhas longas e complexas, e os administradores agora possuem uma ferramenta eficaz contra keyloggers e outras formas de malware que podem detectar as credenciais do usuário em um sistema infectado. Para obter mais informações, consulte a barra lateral "Recursos".
A configuração correta do ISA Server para autenticação de dois fatores com cartões inteligentes aumenta ainda mais a segurança geral, executando a filtragem no nível de aplicativo do OWA publicado. Além disso, o ISA Server 2006 possui suporte interno para publicar tanto o Exchange Server 2003 como o Exchange Server 2007 por meio de simples assistentes de publicação; por isso, o ISA Server ainda representa um ótimo investimento para as organizações na transição para o Exchange Server 2007.

Victor Akinnagbe é engenheiro-chefe de campo da Microsoft e atua na região de Washington, D.C. Suas principais áreas de foco são segurança, infra-estrutura e sistema de mensagens.
Ted Dressel é consultor da Microsoft e atua na região de Washington, D.C. Suas principais áreas de foco são segurança e infra-estrutura.
Jason Opdycke é engenheiro-chefe de campo da Microsoft e atua na região de Charlotte. Suas principais áreas de foco são segurança e infra-estrutura.
© 2008 Microsoft Corporation e CMP Media, LLC. Todos os direitos reservados. A reprodução parcial ou completa sem autorização é proibida..
Page view tracker