Autenticação Kerberos para conexão de cliente MAPI com uma matriz de servidor do Client Access

Resumo

Para Microsoft Exchange Server implantações de 2010 que têm mais de um servidor de Acesso ao Cliente em um site do Active Directory, a topologia exige frequentemente uma matriz de servidor do Client Access e uma solução de balanceamento de carga para distribuir o tráfego entre todos os servidores de Acesso ao Cliente no site. Devido a alterações no Exchange Server 2010, os clientes de email mapi não podem usar a autenticação Kerberos para se conectar a uma caixa de correio quando uma matriz de servidor do Client Access está sendo usada. Para contornar esse comportamento, Microsoft Exchange Server Service Pack 1 (SP1) inclui uma nova funcionalidade que permite configurar a autenticação Kerberos para clientes de email MAPI em uma matriz de servidor do Client Access.

Para obter mais informações sobre como a autenticação Kerberos funcionou em versões anteriores do Exchange Server e sobre as alterações no Exchange Server 2010 que impedem a autenticação Kerberos de trabalhar com clientes de email MAPI, confira a seguinte postagem no blog do Exchange Team:

Recomendação: habilitando a autenticação Kerberos para clientes MAPI

Informações adicionais

O serviço Host do Serviço do Microsoft Exchange que é executado na função CAS (servidor de acesso ao cliente) é estendido no Exchange Server 2010 SP1 para usar uma credencial ASA (conta de serviço alternativa compartilhada) para autenticação Kerberos. Essa extensão de host de serviço monitora o computador local. Quando as credenciais são adicionadas ou removidas, o pacote de autenticação Kerberos no sistema local e o contexto do serviço de rede são atualizados. Assim que uma credencial for adicionada ao pacote de autenticação, todos os serviços de acesso ao cliente poderão usá-la para autenticação Kerberos. O servidor de Acesso ao Cliente também poderá autenticar solicitações de serviço endereçadas diretamente, além de poder usar a credencial ASA. Essa extensão, conhecida como servicelet, é executada por padrão e não requer nenhuma configuração ou ação a ser executada.

Você pode ter que usar a autenticação Kerberos para sua organização Exchange Server 2010 pelos seguintes motivos:

• A autenticação Kerberos é necessária para sua política de segurança local.

• Você está encontrando ou esperando problemas de escalabilidade do NTLM, como conectividade MAPI direta com o serviço RPC Client Access, causando falhas intermitentes de NTLM.

  Em implantações de cliente em larga escala, o NTLM pode causar gargalos nos servidores de Acesso ao Cliente. Isso pode causar falhas de autenticação intermitente. Os serviços que usam a autenticação NTLM são mais sensíveis a problemas de latência do Active Directory. Isso leva a falhas de autenticação quando a taxa de solicitações de servidor do Client Access aumenta.

Para configurar a autenticação kerberos, você deve estar familiarizado com o Active Directory e como configurar matrizes de servidor do Client Access. Você também deve ter um conhecimento de trabalho da autenticação Kerberos.

Para implantar a credencial ASA para autenticação Kerberos, siga estas etapas.

Criar uma conta a ser usada como credencial ASA

Todos os computadores na matriz de servidor do Client Access devem compartilhar a mesma conta de serviço. Isso inclui todos os servidores de Acesso ao Cliente que podem começar como parte de uma alternância de datacenter. Geralmente, uma conta de serviço por floresta é suficiente.

Crie uma conta de computador em vez de uma conta de usuário para a ASA (conta de serviço alternativa), porque uma conta de computador não permite logon interativo. Portanto, uma conta de computador pode ter políticas de segurança mais simples do que uma conta de usuário e é a solução preferida para a credencial ASA.

Para obter mais informações sobre como criar uma conta de computador, consulte Criar uma nova conta de computador.

Não há requisitos específicos para o nome da credencial ASA. Você pode usar qualquer nome que siga seu esquema de nomenclatura. A credencial ASA não precisa de privilégios especiais de segurança. Se você estiver implantando uma conta de computador para a credencial ASA, isso significa que a conta só precisa ser membro do grupo de segurança de Computadores de Domínio. Se você estiver implantando uma conta de usuário para a credencial ASA, isso significa que a conta só precisa ser membro do grupo de segurança Usuários de Domínio.

Determinar os SPNs a serem associados à credencial de conta de serviço alternativa

Depois de criar a conta de serviço alternativa, você deve determinar os SPNs (nomes de entidade de serviço do Exchange) que serão associados às credenciais ASA. Os valores SPN devem ser configurados para corresponder ao nome do serviço usado no balanceador de carga de rede em vez de em servidores individuais. A lista de SPNs do Exchange pode variar de acordo com sua configuração, mas a lista deve incluir pelo menos o seguinte:

• http Usar este SPN para Serviços Web do Exchange, downloads do Catálogo de Endereços Offline e o serviço de Descoberta Automática.
• exchangeMDB Use este SPN para acesso ao cliente do RPC.
• ExchangeRFR Use este SPN para o serviço catálogo de endereços.
• exchangeAB Use este SPN para o serviço catálogo de endereços.

Para uma pequena empresa, você provavelmente não terá nada maior que um único site do Active Directory. Por exemplo, seu único site do Active Directory pode se assemelhar ao diagrama a seguir.

Para determinar os SPNs que você usaria neste exemplo, devemos examinar os FQDNs (nomes de domínio totalmente qualificados) que são usados pelos clientes internos do Outlook na ilustração anterior. Neste exemplo, você implantará os seguintes SPNs na credencial ASA:

• http/mail.corp.contoso.com
• http/autod.corp.contoso.com
• exchangeMDB/outlook.corp.contoso.com
• exchangeRFR/outlook.corp.contoso.com
• exchangeAB/outlook.corp.contoso.com

Se o site for maior que um único site do Active Directory, você poderá ver mais exemplos no tópico Configurando a Autenticação Kerberos para Load-Balanced Servidores de Acesso ao Cliente .

Converter o diretório virtual do OAB em um aplicativo

O diretório virtual OAB (catálogo de endereços offline) não é um aplicativo Web. Portanto, ele não é controlado pelo serviço Host do Serviço do Microsoft Exchange. Como resultado, a credencial ASA não pode descriptografar solicitações de autenticação kerberos para o diretório virtual da OAB.

Para converter o diretório virtual do OAB em um aplicativo Web do IIS, execute o script ConvertOABVDir.ps1 em cada membro CAS. O script também criará um novo pool de aplicativos chamado MSExchangeOabAppPool para o diretório virtual da OAB. Para baixar o script, acesse a página ConvertOABDir.ps1 no Centro de Scripts da Microsoft.

Implantar a credencial ASA nos membros do CAS

Exchange Server 2010 SP1 inclui um script para habilitar a implantação da credencial ASA. O script é nomeado RollAlternateServiceAccountPassword.ps1 e está localizado no diretório Scripts.

Para usar o script para enviar push da credencial a todos os servidores de Acesso ao Cliente na floresta para configuração pela primeira vez, siga estas etapas:

1. No Shell de Gerenciamento do Exchange, execute o seguinte comando:

   .\RollAlternateserviceAccountPassword.ps1 -ToEntireForest -GenerateNewPasswordFor "Your_Domain_Name\Computer_Account_Name$" -Verbose
   

2. Execute o comando a seguir para agendar uma tarefa agendada de rolagem de senha automatizada uma vez por mês chamada "Exchange-RollAsa". Essa tarefa agendada por comando atualizará a credencial ASA para todos os servidores de Acesso ao Cliente na floresta com uma nova senha gerada por script. A tarefa agendada é criada, mas o script não é executado. Quando a tarefa agendada é executada, o script é executado no modo autônomo.

   .\RollAlternateServiceAccountPassword.ps1 -CreateScheduledTask "Exchange-RollAsa" -ToEntireForest -GenerateNewPasswordFor "Your_Domain_Name\Computer_Account_Name$"
   

Para obter mais informações sobre como usar o script RollAlternateserviceAccountPassword.ps1, consulte Usando o script RollAlternateserviceAccountPassword.ps1 no Shell .

Verificar a implantação da credencial ASA

No Shell de Gerenciamento do Exchange, execute o seguinte comando para marcar as configurações nos servidores de Acesso ao Cliente:Get-ClientAccessServer -IncludeAlternateServiceAccountCredentialStatus | fl name,*alter*

O resultado deste comando será semelhante a este:

Name : CASAAlternateServiceAccountConfiguration : Latest: 8/2/2010 3:48:38 PM, contoso\newSharedServiceAccountName$ Previous: <Not set>Name : CASBAlternateServiceAccountConfiguration : Latest: 8/2/2010 3:48:51 PM, contoso\newSharedServiceAccountName$ Previous: <Not set>

Associar SPNs à credencial ASA

Antes de configurar os SPNs, verifique se os SPNs de destino ainda não estão configurados em uma conta diferente na floresta. A credencial ASA deve ser a única conta na floresta com a qual esses SPNs estão associados. Você pode verificar se nenhuma outra conta na floresta tem os SPNs associados a ela abrindo um prompt de comando e executando o comando setspn com os parâmetros –q e –f . O exemplo a seguir mostra como executar esse comando. O comando não deve retornar nada. Se ele retornar um valor, outra conta já estará associada ao SPN que você deseja usar.

Setspn -q -f exchangeMDB/outlook.**domain.domain.domain_root**

Neste comando, exchangeMDB/outlook.domain.domain.domain_root é o SPN do SPN para acesso ao cliente RPC, como exchangeMDB/outlook.corp.contoso.com.

O comando a seguir mostra como definir os SPNs na credencial ASA compartilhada. Você precisa executar o comando setspn com essa sintaxe uma vez para cada SPN de destino que você identificar.

Setspn -S exchangeMDB/outlook.corp.contoso.com contoso\newSharedServiceAccountName$

Depois de definir as SPNs, verifique se elas foram adicionadas executando o comando a seguir.

Setspn -L contoso\newSharedServiceAccountName

Depois de configurar kerberos com êxito e implantar o script RollAlternateServiceAccountPasswordl.ps1, verifique se os computadores cliente podem se autenticar com êxito.

Verifique se o serviço host do Serviço do Microsoft Exchange está em execução

Verifique se você instalou Exchange Server 2010 SP1 Rollup 3 ou uma versão posterior em todos os servidores do Client Access em seu ambiente. O serviço Host do Serviço do Microsoft Exchange nos servidores de Acesso ao Cliente é responsável pelo gerenciamento da credencial ASA. Se esse serviço não estiver em execução, a autenticação kerberos não funcionará. Por padrão, o serviço é configurado para iniciar automaticamente quando o computador é iniciado. Para verificar se o serviço está em execução, siga estas etapas:

1. Abra serviços no CAS. Para abrir serviços, clique em Iniciar, clique em Painel de Controle, clique duas vezes em Ferramentas Administrativas e clique duas vezes em Serviços.
2. Na lista de serviços, localize o serviço Host do Serviço do Microsoft Exchange.
3. Na coluna Status, verifique se o status está iniciado. Se o serviço não for iniciado, clique com o botão direito do mouse no serviço Host do Serviço do Microsoft Exchange e clique em Iniciar. Para configurar o serviço para começar automaticamente, clique com o botão direito do mouse no serviço Host do Serviço do Microsoft Exchange, clique em Propriedades, clique em Automáticona lista De tipos de inicialização e clique em OK.
   Validar a autenticação do Outlook

Para confirmar se o Outlook pode usar a autenticação Kerberos para se conectar aos servidores de Acesso ao Cliente, siga estas etapas:

1. Confirme se o Outlook está configurado para apontar para a matriz correta de servidor de acesso ao cliente balanceada por carga.
2. Configure as configurações de segurança do servidor da conta de email para usar a segurança de rede de logon Negociar Autenticação. ObservaçãoVocê pode configurar o cliente para usar a Autenticação de Senha kerberos, mas se os SPNs forem removidos, os computadores cliente não poderão autenticar até que você altere o mecanismo de autenticação de volta para Negociar Autenticação.
3. Verifique se o Outlook Anywhere não está habilitado para o computador cliente. Se o Outlook não conseguir se autenticar usando a Autenticação de Senha kerberos, ele tentará voltar ao Outlook Anywhere, portanto, o Outlook Anywhere deve ser desabilitado para este teste.
4. Reinicie o Outlook.
5. Se o computador da área de trabalho estiver executando o Windows 7, você poderá executar klist.exe para ver quais tíquetes Kerberos são concedidos e estão sendo usados. Se você não estiver executando o Windows 7, poderá obter klist.exe do Kit de Recursos do Windows Server 2003.

Recursos adicionais

Para obter informações detalhadas sobre esse problema e seu trabalho, confira o seguinte artigo do TechNet:

Usando Kerberos com uma matriz de servidor de acesso ao cliente ou uma solução de Load-Balancing

Para obter mais informações sobre como usar a autenticação Kerberos em servidores de acesso ao cliente com balanceamento de carga, confira o seguinte artigo do TechNet:

Configurando a Autenticação Kerberos para servidores de acesso ao cliente Load-Balanced