Configurando a Autenticação Kerberos para Servidores de Acesso para Cliente com Balanceamento de Carga
Aplica-se a: Exchange Server 2010 SP2, Exchange Server 2010 SP3
Tópico modificado em: 2016-11-28
Para usar a autenticação Kerberos com um matriz com carga balanceada de servidores de Acesso para Cliente, diversas etapas de configuração devem ser concluídas. Para obter informações sobre como usar Kerberos com uma matriz de servidor de Acesso para Cliente ou uma solução de balanceamento de carga, consulte Usar Kerberos com uma matriz de servidor de Acesso para Cliente ou uma solução de balanceamento de carga.
Criar a credencial de conta de serviço alternativo no Active Directory
Todos os computadores dentro da matriz de servidor de Acesso para Cliente devem compartilhar a mesma conta de serviço. Além disso, quaisquer servidores de Acesso para Cliente que possam ser chamados em um cenário de ativação de datacenter também devem compartilhar da mesma conta de serviço. Em geral, basta ter uma única conta de serviço por floresta. Essa conte é referida como credencial de conta de serviço alternativo (credencial ASA).
Dica
Se sua implantação for complexa e se estender além dos cenários descritos abaixo, tiver problemas de delegação de administrador ou possuir diversos segmentos de floresta em diferentes programações de implantação do Exchange, você poderá ter que criar contas adicionais. O script RollAlternateServiceAccountPasswordl.ps1 deve ser executado separadamente para cada conta criada.
Tipo de credencial
É possível criar uma conta de computador ou uma conta de usuário para a conta de serviço alternativo. Como uma conta de computador não permite logon interativo, ela pode ter políticas de segurança mais simples do que uma conta de usuário e, portanto, ser a solução preferencial para a credencial ASA. Se você criar uma conta de computador, na verdade, a senha não expira, mas ainda recomendamos a atualização da senha periodicamente. A política de grupo local pode especificar a duração máxima de uma conta para contas de computador e podem existir scripts programados para periodicamente excluir contas de computador que atendam às políticas atuais. A atualização periódica da senha para contas de computador garantirá que as suas contas de computador não sejam excluídas por não atender à política local. Sua diretiva de segurança local determinará quando a senha precisa ser alterada.
Nome da credencial
Não existem requisitos em particular para o nome da credencial ASA. É possível usar qualquer nome que esteja de acordo com seu esquema de nomeação.
Grupos e funções
A credencial ASA não precisa de privilégios de segurança especiais. 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 Computadores do 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 do Domínio.
Senha
A senha que você forneceu quando criou a conta, na verdade, nunca será usada. Em vez disso, o script redefinirá a senha. Portanto, ao criar a conta, é possível usar qualquer senha que esteja de acordo com os requisitos de senha de sua organização.
Situações entre florestas
Se você tiver uma implantação entre florestas ou de floresta de recursos, e os usuários estiverem fora da floresta do Active Directory que contém o Exchange, será necessário configurar a confiança entre florestas e os sufixos de nomes de roteamento nas florestas. Para obter mais informações, consulte Acessando recursos entre florestas e Sufixos de nomes de roteamento entre florestas.
Identificando os nomes da entidade de serviço que devem ser associados à credencial de conta de serviço alternativo
Após ter criado a conta de serviço alternativo, determine os SPNs (nomes de entidade de serviço) do Exchange que serão associados às credenciais ASA. A lista de SPNs do Exchange pode variar dependendo de sua configuração, porém deverá incluir, no mínimo, o seguinte:
http Use este SPN para os Serviços Web do Exchange, os downloads do Catálogo de Endereços Offline e o serviço Descoberta Automática.
exchangeMDB Use este SPN para Acesso para Cliente RPC.
exchangeRFR Use este SPN para o serviço de Catálogo de Endereços.
exchangeAB Use este SPN para o serviço de Catálogo de Endereços.
Os valores de SPN devem ser configurados de modo que correspondam ao nome de serviço em uso no balanceador de carga da rede, e não nos servidores individuais.
Para ajudar no planejamento de quais valores de SPN devem ser implantados, considere os seguintes cenários conceituais:
Site único do Active Directory
Vários sites do Active Directory
Vários sites do Active Directory com resiliência de site de DAG
Em cada um desses cenários, presume-se que nomes de domínio totalmente qualificados com balanceamento de carga tenham sido implantados para as URLs internas e externas e para a URI interna da Descoberta Automática, usadas pelos membros do servidor de Acesso para Cliente. Para mais informações, consulte Noções básicas de proxy e redirecionamento.
Site único do Active Directory
Se você tiver um único site do Active Directory, seu ambiente pode lembrar o ambiente da ilustração a seguir.
Com base nos nomes de domínio totalmente qualificados usados pelos clientes internos do Outlook na ilustração anterior, os seguintes SPNs teriam que ser implantados 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
Clientes externos ou baseados na Internet que usem o Outlook Anywhere não usarão a autenticação Kerberos. Portanto, os nomes de domínio totalmente qualificados usados por esses clientes não precisam ser adicionados como SPNs à credencial ASA.
Importante
Se você implantar uma infraestrutura de DNS dividido, os clientes externos e internos usarão os mesmos nomes de domínio totalmente qualificados, e esses nomes precisam ser representados como SPNs na credencial ASA.
Vários sites do Active Directory
Se você tiver vários sites do Active Directory, seu ambiente pode lembrar o ambiente da ilustração a seguir.
Com base nos nomes de domínio totalmente qualificados usados pelos clientes internos do Outlook na ilustração anterior, os seguintes SPNs teriam que ser implantados na credencial ASA usada para a matriz do servidor de Acesso para Cliente com o site ADSite1 do Active Directory:
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
Com base nos nomes de domínio totalmente qualificados usados pelos clientes internos do Outlook na ilustração anterior, os seguintes SPNs teriam que ser implantados na credencial ASA usada para a matriz do servidor de Acesso para Cliente no site ADSite2 do Active Directory:
http/mailsdc.corp.contoso.com
http/autodsdc.corp.contoso.com
exchangeMDB/outlooksdc.corp.contoso.com
exchangeRFR/outlooksdc.corp.contoso.com
exchangeAB/outlooksdc.corp.contoso.com
Dica
Este exemplo mostra como você pode usar várias credenciais ASA para este cenário específico. No entanto, é possível usar uma única credencial ASA para todos os sites do Active Directory que hospedem matrizes de servidor de Acesso para Cliente nas quais você deseje implantar autenticação Kerberos.
Vários sites do Active Directory com resiliência de site de DAG
Se você tiver vários sites do Active Directory com resiliência de site de DAG, seu ambiente pode lembrar o ambiente da ilustração a seguir.
Como essa arquitetura inclui um DAG (grupo de disponibilidade de banco de dados) que se estende por ambos os sites do Active Directory, você deve implantar uma única credencial ASA para uso dos membros das matrizes de servidor de Acesso para Cliente nos sites ADSite1 e ADSite2. Caso não use uma única credencial ASA, os clientes terão problemas com a autenticação Kerberos quando você realizar uma alternância de datacenter porque os membros da matriz de servidor de Acesso para Cliente secundário não poderão descriptografar o tíquete da sessão Kerberos. Para mais informações sobre a ativação do datacenter secundário, consulte Switchovers do Datacenter.
Com base nos nomes de domínio totalmente qualificados usados pelos clientes internos do Outlook na ilustração anterior, os seguintes SPNs teriam que ser implantados na credencial ASA usada para as matrizes do servidor de Acesso para Cliente no nos sites ADSite1 e ADSite2:
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
http/mailsdc.corp.contoso.com
http/autodsdc.corp.contoso.com
exchangeMDB/outlooksdc.corp.contoso.com
exchangeRFR/outlooksdc.corp.contoso.com
exchangeAB/outlooksdc.corp.contoso.com
Converter o diretório virtual do Catálogo de Endereços Offline em um aplicativo
Em sua forma original, o diretório virtual do Catálogo de Endereços Offline não é um aplicativo Web, e portanto não é controlado pelo serviço Host de Serviço do Microsoft Exchange. Logo, as solicitações de autenticação Kerberos ao diretório virtual do Catálogo de Endereços Offline não podem ser descriptografadas pela credencial ASA.
Para converter o diretório virtual do Catálogo de Endereços Offline em um aplicativo Web, execute o script ConvertOABDir.ps1 em cada membro do servidor de Acesso para Cliente. O script também criará um novo pool de aplicativos para o diretório virtual Catálogo de Endereços Offline. O script está localizado no diretório Scripts do Exchange 2010 SP2, ou pode ser baixado aqui.
Implantando a credencial de conta de serviço alternativa
Depois de criar a credencial ASA, verifique se a conta replicou todos os controladores de domínio em todos os sites do Active Directory que contenham os servidores de Acesso para Cliente que usarão a credencial ASA.
Em seguida, você poderá executar o script de credencial AlternateServiceAccount no Shell de Gerenciamento do Exchange. Para mais informações, consulte Usando o Script RollAlternateserviceAccountCredential.ps1 no Shell. Depois que o script tiver sido executado, é recomendável verificar se todos os servidores de destino foram atualizados corretamente.
Dica
O script é fornecido somente em inglês.
Para ajudar a solucionar problemas de scripts, consulte Solução de Problemas do Script RollAlternateServiceAccountCredential.ps1.
Este exemplo de saída do script RollAlternateServiceAccountPassword.ps1 usa uma conta de computador criada como a credencial ASA. A conta se chama contoso/newSharedServiceAccountName. No exemplo a seguir, o script aplica as configurações de credencial a cada membro da matriz de servidor de Acesso para Cliente de nome outlook.corp.contoso.com.
Para executar o script, use o seguinte comando:
RollAlternateServiceAccountPassword.ps1 -ToArrayMembers outlook.corp.contoso.com -GenerateNewPasswordFor contoso\newSharedServiceAccountName$
Você deve receber a saída a seguir após a execução do script. Haverá uma solicitação de aprovação para mudança de senha.
========== Started at 08/02/2010 15:48:09 ==========Destination servers that will be updated:Name----CASACASBCredentials that will be pushed to every server in the specified scope (recent first):UserName Password-------- --------contoso\newSharedServiceAccountName$ System.Security.SecureStringPrior to pushing new credentials, all existing credentials that are invalid or no longer work will be removed from the destination servers.Pushing credentials to server CASAPushing credentials to server CASBSetting a new password on Alternate Service Account in Active DirectoryPassword changeDo you want to change password for contoso\newSharedServiceAccountName$ in Active Directory at this time?[Y] Yes [N] No [S] Suspend [?] Help (default is "Y"): yPreparing to update Active Directory with a new password for contoso\newSharedServiceAccountName$ ...Resetting a password in the Active Directory for contoso\newSharedServiceAccountName$ ...New password was successfully set to Active Directory.Retrieving the current Alternate Service Account configuration from servers in scopeAlternate Service Account properties:StructuralObjectClass QualifiedUserName Last Pwd Update --------------------- ----------------- --------------- computer contoso\newSharedServiceAccountName$ 8/2/2010 3:49:05 PM SPNs-----Per-server Alternate Service Account configuration as of the time of script completion: Array: outlook.corp.contoso.comIdentity AlternateServiceAccountConfiguration-------- ------------------------------------NAE14CAS Latest: 8/2/2010 3:48:38 PM, contoso\newSharedServiceAccountName$ Previous: <Not set>NAE14CAS2 Latest: 8/2/2010 3:48:51 PM, contoso\newSharedServiceAccountName$ Previous: <Not set>
Você também verá dois IDs de Eventos em seus logs de eventos. Um evento é para o início do script, o outro é para a conclusão bem-sucedida. Segue um trecho do evento de conclusão bem-sucedida.
Log Name: ApplicationSource: MSExchange Management ApplicationEvent ID: 14002Task Category: KerberosLevel: InformationDescription:Maintenance of the Alternate Service Accounts succeeded.
Verificando a implantação da credencial ASA
No Shell de Gerenciamento do Exchange, execute os seguintes comandos para verificar as configurações dos servidores de Acesso para Cliente.
Get-ClientAccessServer -IncludeAlternateServiceAccountCredentialStatus | fl name,*alter*
O resultado desse comando deve ser parecido com o que se vê a seguir.
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>
Se você executou o script várias vezes e fez alterações, a entrada Anterior mostrará quando a última alteração foi realizada.
Name : NAE14CASAlternateServiceAccountConfiguration : Latest: 8/2/2010 4:32:38 PM, contoso\newSharedServiceAccountName$ Previous: 8/2/2010 4:32:24 PM, contoso\sharedkerbacct$Name : NAE14CAS2AlternateServiceAccountConfiguration : Latest: 8/2/2010 4:32:38 PM, contoso\newSharedServiceAccountName$ Previous: 8/2/2010 4:32:24 PM, contoso\sharedkerbacct$
Associando nomes de entidade de serviço à credencial de conta de serviço alternativa
Antes de configurar os SPNs, verifique se os SPNs de destino já não estão configurados em uma conta diferente na floresta. A credencial ASA deve ser a única conta na floresta à qual esses SPNs estejam associados. É possível confirmar se nenhuma outra conta na floresta possui SPNs associados a ela executando o comando setspn com os parâmetros –q e –f pela linha de comando. O exemplo a seguir mostra como executar esse comando. O comando não deve retornar nada. Se algum valor for retornado, outra conta já está associada ao SPN que você está pensando em usar.
Dica
Apenas o Windows Server 2008 tem suporte ao parâmetro de verificação de duplicata em toda a floresta (-f) no comando setspn.
Setspn -q -f exchangeMDB/outlook.corp.contoso.com
O comando a seguir oferece um exemplo de como configurar os SPNs na credencial ASA compartilhada. O comando setspn com esta sintaxe deve ser executado uma vez para cada SPN de destino que você identificar.
Setspn -S exchangeMDB/outlook.corp.contoso.com contoso\newSharedServiceAccountName$
Quando tiver definido os SPNs, verifique se eles foram adicionados usando o seguinte comando.
Setspn -L contoso\newSharedServiceAccountName$
Validar a autenticação Kerberos de cliente do Exchange
Após configurar com êxito o Kerberos e implantar o script RollAlternateServiceAccountPasswordl.ps1, verifique se os clientes conseguem fazer a autenticação.
Verificando se o serviço de host do Microsoft Exchange Service está em execução
O serviço de host do Microsoft Exchange Service nos servidores de Acesso para Cliente é responsável pelo gerenciamento da credencial ASA. Se o serviço não estiver em execução, a autenticação Kerberos não será possível. Por padrão, o serviço é configurado para iniciar automaticamente quando o computador for iniciado. Certifique-se de ter instalado o Exchange Server 2010 SP1 Rollup 3 ou uma versão posterior em todos os servidores de Acesso para Cliente de seu ambiente.
Validar a autenticação pelo Outlook
Para garantir que o Outlook consegue se conectar aos servidores de Acesso para Cliente com a autenticação Kerberos, siga estas etapas:
Confirme se o Outlook está configurado para apontar para a matriz correta de servidor de Acesso para Cliente com carga balanceada.
Defina as configurações de segurança do servidor de conta de email para usar a segurança de rede de logon Autenticação Negotiate. Ou então configure o cliente para usar Autenticação de Senha Kerberos. No entanto, se os SPNs forem removidos, os clientes não poderão se autenticar até que você mude o mecanismo de autenticação para Autenticação Negotiate novamente.
Confirme se o Outlook está desabilitado para o cliente. Se o Outlook falhar na autenticação usando o Kerberos, ele tentará retornar ao Outlook Anywhere, por isso o Outlook deve estar desabilitado para este teste.
Reinicie o Outlook.
Se seu computador desktop estiver executando o Windows 7, use klist.exe para ver quais tíquetes Kerberos foram concedidos e estão sendo usados. Caso não esteja executando o Windows 7, obtenha o klist.exe pelo Kit de Recursos do Windows Server 2003.
A validação usando o cmdlet Test-OutlookConnectivity
Para verificar se o Kerberos está funcionando, use o cmdlet Test-OutlookConnectivity. Essa é a melhor forma de ver se a conectividade TCP pode ser estabelecida. Por padrão, o cmdlet usará a autenticação Negotiate para uma conexão TCP. Por isso, se o Kerberos estiver configurado, ela será usada. O arquivo klist.exe pode ser usado para visualizar os tíquetes Kerberos no computador. Ele pode ser executado a partir do próprio servidor de Acesso para Cliente, bem como de uma ferramenta de monitoramento automatizada, como SCOM. Ao usar o cmdlet Test-OutlookConnectivity, certifique-se de que o banco de dados de Caixa de Correio tenha a propriedade RPCClientAccessServer definida para o nome da matriz de servidor de Acesso para Cliente. Caso contrário, o cmdlet não testará a funcionalidade de credencial ASA compartilhada.
Test-OutlookConnectivity -Identity administrator -MailboxCredential $c -Protocol tcp
Para verificar se a conexão é feita usando Kerberos, veja o klist.exe para saber se há tíquetes Kerberos associados aos novos SPNs que foram adicionados.
Validar Kerberos pelo servidor de Acesso para Cliente
Para verificar pelo servidor de Acesso para Cliente se o Kerberos está funcionando corretamente, você pode examinar os logs de protocolo para verificar conexões Kerberos bem-sucedidas. Você pode usar estes logs, além das outras validações, para confirmar que o Kerberos está sendo usado.
No servidor de Acesso para Cliente, examine os logs de protocolo do Catálogo de endereços. Normalmente estes logs estão localizados no seguite caminho: C:\Arquivos de Programas\Microsoft\Exchange server\v14\Logging\AddressBook Service.
Examine o arquivo de log mais recente e procure pela palavra Kerberos depois que o script tenha sido executado. Se houver o tráfego Kerberos, uma conexão foi feita com êxito. A linha no arquivo de log deve ser similar a:
2010-06-11T22:58:49.799Z,9,0,/o=First Organization/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=Administrator,,2001:4898:f0:3031:99f:ce35:750a:8b09,EXCH-A-363,ncacn_ip_tcp,Bind,,6,,,Kerberos,
Se você usar a palavra Kerberos, o servidor criará conexões autenticadas Kerberos com êxito. Para mais informações sobre o log de serviço do Catálogo de endereços, consulte Noções Básicas Sobre o Serviço de Catálogo de Endereços.
Solução de problemas de falha de autenticação
Há diversos problemas comuns que podem ocorrer quando você está configurando a autenticação Kerberos.
Clientes do Outlook configurados para usar somente autenticação Kerberos não conseguem se conectar
Se o seu cliente do Outlook que está configurado para usar somente autenticação Kerberos não conseguir se conectar, siga estas etapas de solução de problemas:
Configure o Outlook para usar autenticação NTLM somente e depois verifique a conectividade. Se não for possível estabelecer conexão, verifique se a matriz de servidor de Acesso para Cliente está disponível ou se há estabilidade na conectividade de rede.
Se a conectividade NTLM for estabelecida com êxito, mas não a Kerberos, verifique se os SPNs não estão registrados em outras contas além da conta de serviço alternativo. Verifique se os SPNs do Exchange estão registrados na conta usada pela conta de serviço alternativo compartilhada usando o comando de consulta setSPN, conforme descrito anteriormente neste tópico.
Verifique se a senha está coordenada entre todos os servidores de Acesso para Cliente e o Active Directory. Para isso, execute o script no modo assistido e gere uma nova senha.
Verifique se o serviço de Catálogo de endereços do Microsoft Exchange está sendo executado nos servidores de Acesso para Cliente.
Se a autenticação ainda não tiver êxito, verifique se os diretórios virtuais dos serviços que você deseja acessar com Kerberos está com a autenticação integrada ao Windows habilitada. É possível usar os cmdlets Get-VirtualDirectory para verificar os métodos de autenticação. Para mais informações sobre diretórios virtuais, consulte Entendendo os Diretórios Virtuais do Outlook Web App e Noções Básicas Sobre Diretórios Virtuais dos Serviços Web do Exchange.
Falhas do serviço de Descoberta automática
Se for observada a seguinte falha de serviço de Descoberta automática, provavelmente, ela ocorreu porque o cabeçalho de solicitação do serviço de Descoberta automática contém um grande tíquete de autenticação Kerberos que fez com que o tamanho do cabeçalho excedesse o limite configurado pelo servidor de Serviços de Informações da Internet (IIS). O erro será semelhante ao mostrado a seguir.
HTTP/1.1 400 Bad Request
Content-Type: text/html; charset=us-ascii
Server: Microsoft-HTTPAPI/2.0
Date: Tue, 09 Mar 2010 18:06:18 GMT
Connection: close
Content-Length: 346
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN""https://www.w3.org/TR/html4/strict.dtd">
<HTML><HEAD><TITLE>Bad Request</TITLE>
<META HTTP-EQUIV="Content-Type" Content="text/html; charset=us-ascii"></HEAD>
<BODY><h2>Bad Request - Request Too Long</h2>
<hr><p>HTTP Error 400. The size of the request headers is too long.</p>
</BODY></HTML>
Para corrigir esse erro, aumente o limite de tamanho do cabeçalho do IIS. Para mais informações, consulte Documentação IIS.
Manutenção da credencial ASA em andamento
Se sua senha local na credencial ASA compartilhada precisa ser atualizada periodicamente, consulte Usando o Script RollAlternateserviceAccountCredential.ps1 no Shell a fim de obter instruções de configuração de uma tarefa agendada para fazer manutenção regular de senha. Sempre monitore a tarefa agendada para garantir a substituição oportuna da senha e evitar possíveis interrupções de autenticação.
Desativando a autenticação de Kerberos
Para reverter a sua matriz de servidor de Acesso para Cliente, de forma que ela não use Kerberos, remova os SPNs da conta de serviço compartilhado. Se os SPNs forem removidos, a autenticação Kerberos não será tentada pelos seus clientes, e os clientes configurados para usar a autenticação Negociar usará NTLM. Os clientes configurados para usar somente Kerberos não poderão se conectar. Quando os SPNs forem removidos, você deverá também excluir a conta de serviço compartilhada. É possível usar o script de manutenção para remover as credenciais de todos os membros de matriz de servidor de Acesso para Cliente usando o parâmetro toEntireForest e usando o parâmetro -copy from server para especificar o servidor que não deve ter nenhuma credencial de Kerberos. Além disso, em algum momento você deve reiniciar todos os computadores cliente para limpar o cache de tíquetes Kerberos.
© 2010 Microsoft Corporation. Todos os direitos reservados.