Modelo de permissões de transporte do Exchange 2007

Aplica-se a: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007

Tópico modificado em: 2007-08-27

Este tópico fornece informações detalhadas sobre o modelo de permissões de transporte do Microsoft Exchange Server 2007. No Microsoft Exchange Server 2007, transporte refere-se ao processo de transferência de mensagens de um servidor para outro. Quando mensagens são transferidas entre um servidor de Caixa de Correio e o servidor de Transporte de Hub, o protocolo MAPI é usado. Quando mensagens são enviadas e recebidas entre servidores de Transporte de Hub, o protocolo SMTP é usado. Cada sessão de comunicação entre servidores pode ter um estágio opcional de autenticação. Solicitações de conexão podem exigir verificações de autorização.

Autenticação é o processo que tenta identificar o remetente de uma mensagem. Se não houver autenticação ou se a tentativa falhar, a identidade do remetente é anônima. Autorização é o processo que determina se o usuário, programa ou dispositivo que está se conectando deve ter permissão para acessar algum dado, funcionalidade ou serviço. Esse acesso depende da ação solicitada. O processo de autenticação verifica a identidade. O processo de autorização determina o nível de acesso concedido.

No Exchange 2007, os protocolos SMTP e MAPI são fornecidos pelo serviço de Transporte do Microsoft Exchange. Em sessões que usam o protocolo SMTP ou MAPI, o serviço de Transporte do Microsoft Exchange usa o modelo de autorização Microsoft Windows para gerenciar as permissões para uma sessão. No contexto de transporte no Exchange 2007, a autorização se refere à aceitação ou não de vários verbos ou eventos de protocolo. Por exemplo, a autorização verificará se há permissões para que o remetente envie uma mensagem de um endereço de e-mail específico ou uma mensagem de determinado tamanho. Durante as conversas dos protocolos MAPI e SMTP, o Exchange 2007 pode realizar a autenticação de sessão. Depois que a sessão for autenticada, os grupos de permissões disponíveis para ela podem ser alterados por causa da autenticação. Isso permite que mensagens anônimas da Internet e mensagens enviadas por usuários autenticados na organização do Exchange sejam processadas de forma diferente por causa dos diferentes grupos de permissões concedidos por autenticação.

O comportamento padrão para transporte em uma função de servidor de Transporte de Borda difere do comportamento padrão em uma função de servidor de Transporte de Hub. Essa diferença não ocorre por causa de uma variação de código. É causada por uma diferença no conjunto padrão de permissões de cada função. Os servidores Exchange que fazem parte da mesma floresta do Active Directory têm uma relação de confiança. Essa relação de confiança significa que as permissões padrão configuradas durante a instalação permitem o fluxo de emails seguro na floresta.

Cada sessão autenticada apresenta um token de acesso que lista o identificador de segurança para cada grupo do qual a entidade de segurança de autenticação é membro. A Figura 1 mostra a relação entre as associações de grupo listadas no token de acesso e permissões atribuídas a esses grupos pelo objeto que é acessado.

Figura 1   Componentes de autorização de transporte no Exchange 2007

A diferença entre sessões autenticadas e mensagens autenticadas

Um conceito central do modelo de transporte do Exchange 2007 é a diferença entre sessões de transporte autenticadas e mensagens autenticadas. Uma mensagem pode ser carimbada com metadados, o que indica se é autenticada ou anônima. Quando um servidor autentica para outro servidor, ele pode enviar uma mensagem e a carimbar com metadados que indicam se a mensagem é autenticada ou anônima. O servidor de destino determina se o carimbo autenticado é confiável. Se o servidor de destino confiar no remetente, o carimbo autenticado é mantido intacto. Se o servidor de destino não confiar no remetente, substituirá o carimbo autenticado do servidor remetente e carimbará a mensagem com metadados que indicam que a mensagem é anônima. Em uma organização do Exchange, o fluxo interno de mensagens de ponta a ponta ocorre entre servidores que confiam no carimbo da mensagem autenticada. Um servidor de Transporte de Borda que recebe mensagens da Internet não confia no carimbo autenticado de servidores anônimos da Internet. Portanto, o servidor de Transporte de Borda carimba cada mensagem com metadados que indicam que a mensagem é anônima antes de enviar para um servidor de Transporte de Hub por meio de uma conexão autenticada.

Como o processo de autenticação e autorização de transporte de mensagens funciona

No Exchange 2007, os seguintes mecanismos básicos estão disponíveis para autenticar uma sessão SMTP:

• Você pode usar uma conta e senha do Windows em uma sessão MAPI. Como alternativa, pode usar a extensão AUTH de SMTP. Isso inclui autenticação de senha de texto simples, autenticação NTLM e autenticação Kerberos.

• Você pode usar um certificado X.509 através da extensão STARTTLS de SMTP. Nesse cenário, o servidor fornece um certificado como parte da negociação de TLS (Transport Layer Security). Como opção, o cliente também fornece um certificado.

• Você pode usar um mecanismo de autenticação externo. A autenticação externa usa um mecanismo que não é parte do Exchange, como uma rede fisicamente protegida ou IPsec. Esse método é usado quando a comunicação ocorre em roteamentos IP identificados em conectores dedicados de envio e recebimento.

O servidor de transporte de envio pode autenticar o servidor de transporte de recebimento antes de enviar a mensagem Depois que o remetente autenticar, o servidor de transporte de recebimento aplica as permissões ao token de acesso à sessão, que são concedidas ao remetente.

No Exchange 2007, os conectores de envio e de recebimento gerenciam o fluxo de mensagens. Os conectores têm uma DACL (lista de controle de acesso condicional) que define as permissões associadas a envio e recebimento de email. As permissões nos conectores de recebimento são muito importantes. A DACL no conector de recebimento determina as permissões do remetente para mensagens enviadas através do conector de recebimento. Depois que uma sessão SMTP é estabelecida para um conector de recebimento, a sessão é iniciada com um token de acesso anônimo para a sessão. Uma autenticação subseqüente bem-sucedida altera o token de acesso. Se uma sessão não autenticar, os grupos de permissões no token de acesso permanecem os mesmos. Se uma sessão autenticar, são concedidas as permissões atribuídas à conta ou função individual e as permissões atribuídas aos grupos de segurança às quais a conta pertence.

O fluxograma da Figura 2 ilustra como um servidor de transporte do Exchange 2007 usa autenticação e autorização em uma sessão SMTP.

Figura 2   Processo de autenticação e autorização de sessão SMTP

Configurações de autenticação

O conjunto de mecanismos de autenticação configurados para um conector de recebimento determinam os mecanismos disponíveis para uso por sessões que enviam mensagem para o conector de recebimento. O mecanismo de autenticação que é configurado por um conector de envio determina qual mecanismo de autenticação será usado pelo conector de envio para autenticar para um host inteligente.

Autenticação para conectores de recebimento

Você pode configurar mais de um mecanismo de autenticação em um conector de recebimento. Para um conector de recebimento, a configuração de autenticação determina o conjunto de mecanismos de autenticação habilitados pelo servidor para autenticar sessões que enviam mensagens para o servidor. O servidor de envio determina qual mecanismo de autenticação será usado.

A Tabela 1 lista os mecanismos de autenticação que você pode configurar em um conector de recebimento. Para configurar o mecanismo de autenticação do conector de recebimento, use a guia Autenticação das propriedades do conector de recebimento no Console de Gerenciamento do Exchange ou o parâmetro AuthMechanism com o cmdlet Set-ReceiveConnector no Shell de Gerenciamento do Exchange.

Tabela 1   Mecanismos de autenticação para conectores de recebimento

Autenticação para conectores de envio de host inteligente

Para um conector de envio, a configuração SmartHostAuthMechanism determina como o servidor de envio autentica com o host inteligente de destino. O parâmetro SmartHostAuthMechanism pode ter apenas um valor. Se um parâmetro SmartHostAuthMechanism estiver configurado, a autenticação deverá ser bem-sucedida antes do envio da mensagem. Se o mecanismo de autenticação usado pelo servidor de envio Exchange 2007 não for oferecido pelo host inteligente, o servidor não enviará mensagens de email e a sessão será encerrada. Se o mecanismo de autenticação usado pelo servidor de envio Exchange 2007 for oferecido, mas a autenticação falhar, o servidor também não enviará mensagens de email e a sessão será encerrada.

A Tabela 2 lista os mecanismos de autenticação que você pode configurar em um conector de envio. Para configurar o mecanismo de autenticação do conector de envio, use a caixa de diálogo Configurar Autenticação de Host Inteligente na guia Rede das propriedades do conector de envio no Console de Gerenciamento do Exchange ou o parâmetro SmartHostAuthMechanism com o cmdlet Set-SendConnector no Shell de Gerenciamento do Exchange.

Tabela 2   Mecanismos de autenticação para conectores de host inteligente

Protocolo TLS

O protocolo TLS é descrito em RFC 2246. TLS usa certificados X.509. Essas são uma forma de credencial eletrônica. O protocolo TLS pode ser usado da seguinte forma:

• Somente para confidencialidade.

• Para autenticação de servidor com confidencialidade onde o certificado de servidor é validado.

• Para autenticação mútua com confidencialidade onde certificados de cliente e de servidor são validados.

Durante a conversa de protocolo SMTP, o cliente emite o comando SMTP STARTTLS para solicitar que o protocolo TLS seja negociado para essa sessão. O cliente recebe um certificado X.509 do servidor como parte da negociação do protocolo TLS. A diretiva de autenticação de cliente, então, determina se o certificado do servidor de recebimento deve ser validado e se qualquer outro critério deve ser aplicado ao certificado, como correspondência de nome.

Uma parte opcional da negociação do TLS habilita o servidor de recebimento a também solicitar um certificado do servidor de envio. Se o servidor de envio enviar um certificado para o servidor de recebimento, a diretiva local no servidor de recebimento determinará como o certificado será validado e quais permissões serão concedidas para o servidor de envio por causa da autenticação.

Quando TLS é usado para autenticação do servidor, somente o certificado do servidor de recebimento é validado. Se TLS for usado para autenticação mútua, tanto o certificado do servidor de envio como o de recebimento deverão ser validados.

Quando TLS for configurado em um conector de recebimento do Exchange 2007, o servidor deverá ter um certificado X.509. Esse certificado pode ser um certificado auto-assinado ou um certificado que é assinado por uma autoridade de certificação (CA). O servidor Exchange procura um certificado no armazenamento local que corresponda ao FQDN do conector. O servidor de envio seleciona como o protocolo TLS é usado. Quando o Exchange usa TLS somente para confidencialidade, o cliente Exchange não valida o certificado. Por exemplo, quando o Exchange usa o protocolo TLS entre os servidores de Transporte de Hub, usando o Kerberos através do protocolo TLS, ele estabelece um canal confidencial entre os servidores e não executa validação no certificado. A autenticação entre os servidores ocorre usando Kerberos depois que o protocolo TLS for concluído.

Quando a autenticação TLS for necessária, o Exchange deverá validar o certificado. O Exchange pode validar o certificado de duas formas: confiança direta ou validação X.509. Quando o TLS é usado para comunicação de servidor de Transporte de Borda para servidor de Transporte de Hub, o Exchange usa um mecanismo de confiança direta para validar o certificado.

Confiança direta significa que o Exchange usa um armazenamento confiável, como Active Directory ou ADAM (Active Directory Application Mode). Confiança direta também significa que a presença do certificado no armazenamento valida o certificado. Quando a confiança direta é usada, não importa se o certificado é auto-assinado ou assinado por uma autoridade de certificação. Quando você inscreve um servidor de Transporte de Borda na organização do Exchange, a inscrição publica o certificado do servidor de Transporte de Borda no Active Directory para que os servidores de Transporte de Hub o validem. O serviço Microsoft Exchange Edgesync atualiza o ADAM com o conjunto de certificados do servidor de Transporte de Hub para que o servidor de Transporte de Borda os valide.

O outro método que o Exchange usa para validar certificados é a validação X.509. Quando a validação X.509 for usada, o certificado deverá ser assinado por uma CA. O Exchange usa a validação X.509 quando autentica hosts inteligentes ou quando usa Segurança de Domínio. A Segurança de Domínio é explicada na seção seguinte.

Segurança de domínio

A Segurança de Domínio está relacionada ao conjunto de funcionalidades do Exchange 2007 e do Microsoft Office Outlook que oferece uma alternativa relativamente barata para o S/MIME ou outras soluções de segurança no nível de mensagens. O objetivo da Segurança de Domínio é oferecer aos administradores um método de gerenciar caminhos de mensagens protegidos na Internet com parceiros de negócios. Após a configuração desses caminhos de mensagens protegidos, as mensagens que transitam com êxito por esses caminhos a partir de um servidor autenticado são exibidas aos usuários como "Domínio Seguro" na interface do Outlook e do Outlook Web Access.

Um conector de envio verificará se o domínio de destino está na lista de domínios do remetente que estão configurados para Segurança de Domínio se as seguintes condições forem verdadeiras:

• O conector de envio está configurado para rotear mensagens usando registros de recurso de MX (troca de mensagens) do DNS (Sistema de Nome de Domínio).

• O conector de envio está configurado como domínio seguro.

Se o domínio de destino estiver na lista, o servidor de transporte irá impor autenticação TLS mútua quando enviar emails para o domínio.

O servidor de recebimento responderá com um comando SMTP QUIT se as seguintes condições forem verdadeiras:

• O Exchange não pode negociar TLS

• A validação do certificado do servidor ou a verificação da CRL falhar.

As mensagens, então, ficam em fila no servidor de envio. A fila está em um estado de tentativa. Esse comportamento também ocorre quando a verificação de nome falha.

Se um conector de recebimento estiver em um domínio seguro, o servidor de transporte verificará o email recebido. Depois, o servidor de transporte irá impor autenticação TLS mútua se o remetente estiver na lista de domínios destinatários configurados para Segurança de Domínio. Se todas as verificações passarem, a mensagem recebida será marcada como "Domínio Seguro". Se o remetente não puder negociar TLS ou se a validação do certificado do servidor ou a verificação da CRL falhar, o servidor de transporte rejeitará a mensagem usando o protocolo SMTP. Se a verificação de nome falhar, resultará também em um protocolo SMTP REJECT. Depois, o servidor Exchange envia uma mensagem que tem um erro SMTP temporário (4xx) para o servidor de envio. Isso significa que o servidor de envio deve tentar novamente mais tarde. Esse comportamento evita que falhas transitórias causadas por falhas temporárias de verificação da CRL provoquem uma imediata Notificação de Falha na Entrega para o remetente. A falha somente atrasa a entrega da mensagem.

Para obter mais informações, consulte Gerenciando segurança de domínio.

Autenticação protegida externamente

Você pode selecionar a opção de autenticação Protegida Externamente se tiver certeza de que a conexão de rede entre os servidores é confiável. Essa conexão pode ser uma associação IPsec ou uma rede virtual privada. Como alternativa, os servidores podem residir em uma rede confiável fisicamente controlada. Essa configuração é útil no seguinte caso:

• Você estabelece o fluxo de mensagens entre um servidor de transporte do Exchange 2007 e uma versão anterior do Exchange Server ou qualquer outro servidor SMTP.

• Você não deseja usar Autenticação básica.

Conectores do Exchange que estão configurados como Protegidos Externamente devem usar conectores de envio e de recebimento dedicados porque presume-se que todas as conexões para os conectores sejam seguras. Portanto, os conectores de envio configurados como Protegidos Externamente devem usar um host inteligente para roteamento de mensagens. Além disso, os endereços IP dos hosts inteligentes de destino devem estar configurados no conector. Conectores de recebimento configurados como Protegidos Externamente devem ter o parâmetro RemoteIPRanges configurado para o intervalo de endereços IP dos servidores de envio. TLS pode também ser combinado com a opção de autenticação Protegido Externamente para adicionar confidencialidade à sessão. Você pode fazer isso no Shell de Gerenciamento do Exchange se configurar o parâmetro RequireTLS dos conectores como $True.

Autorização

Durante o transporte da mensagem, autorização é o processo que determina se uma ação solicitada, como envio de email, é permitida para uma sessão SMTP.

Permissões de transporte do Exchange 2007

Os servidores de transporte do Exchange 2007 usam o modelo de autorização do Windows para uma sessão SMTP para determinar se o remetente está autorizado a enviar mensagens para um conector específico, para um destinatário específico e como um remetente específico, por exemplo. Uma sessão SMTP recebe um conjunto inicial de permissões (anônimas). Depois que a sessão é autenticada, mais permissões ficam disponíveis para a sessão. Isso altera o conjunto de ações autorizadas para a sessão.

No modelo de autorização do Windows, permissões são concedidas através de uma interação de controle de acesso que compara o token de acesso às ACL (listas de controle de acesso). Um token de acesso lista um conjunto de entidades de segurança. Uma entidade de segurança pode ser uma conta de usuário, conta de computador ou grupo de segurança. Cada entidade de segurança tem um SID (identificador de segurança) associado. A cada sessão é atribuído um token de acesso. As ACLs são definidas no objeto do conector no Active Directory ou no ADAM. A DACL contém um conjunto de ACE (entradas de controle de acesso). Cada ACE permite ou nega uma permissão para uma entidade de segurança. Quando o servidor de transporte verifica se foi concedida permissão para a sessão, como envio de emails, ele chama uma API de verificação de acesso do Windows e fornece o token de acesso da sessão e o DACL do conector como parâmetros, junto com a permissão solicitada.

Esse processo é idêntico ao modo como uma permissão de leitura de arquivo é determinada. O token de acesso, o arquivo DACL e a permissão solicitada são enviados para a mesma API. A API verifica cada entidade de segurança listada no token de acesso contra cada ACE na DACL para determinar se a permissão solicitada será concedida ou negada. Além dos SIDs do Windows fornecidos pelo Active Directory, ADAM ou o banco de dados SAM (Gerenciador de Contas de Segurança) de um computador, o Exchange 2007 define SIDs adicionais. Esses SIDs representam grupos lógicos. A Tabela 3 lista os SIDs definidos pelo Exchange 2007 para uso durante autenticação de transporte.

Table 3   SIDs do Exchange 2007

Permissões do conector de recebimento

Conectores de recebimento processam sessões de entrada para o servidor. A sessão pode ser estabelecida por um remetente autenticado ou anônimo. Se uma sessão for autenticada com sucesso, os SIDs do token de acesso da sessão serão atualizados. A Tabela 4 lista as permissões que podem ser concedidas para uma sessão conectando-se a um conector de recebimento.

Tabela 4   Permissões do conector de recebimento

Permissões de Conector de Envio

Conectores de envio processam sessões de saída para outro servidor. A sessão pode ser estabelecida pelo remetente para um destinatário anônimo ou autenticado. Se a sessão for autenticada com sucesso, o conjunto de SIDs do token de acesso da sessão será atualizado. As permissões do conector de envio determinam os tipos de informações de cabeçalho que podem ser incluídas em uma mensagem enviada usando-se o conector. Mensagens enviadas a outros servidores Exchange na organização ou para uma organização confiável do Exchange em um cenário entre florestas têm normalmente permissão para enviar todos os cabeçalhos. Mensagens enviadas para a Internet ou para servidores SMTP que não sejam Exchange não têm permissão para conter todos os cabeçalhos. Se os cabeçalhos estiverem incluídos na mensagem, a funcionalidade de firewall de cabeçalho do Exchange 2007 os removerá. A Tabela 5 lista as permissões que podem ser concedidas para uma sessão conectando-se a um conector de envio.

Tabela 5   Permissões de conector de envio

Grupos de Permissões

Um grupo de permissões é um conjunto predefinido de permissões que podem ser concedidas em um conector de recebimento. Grupos de permissões estão disponíveis apenas para conectores de recebimento. O uso de grupos de permissões simplifica a configuração de permissões em conectores de recebimento. A propriedade PermissionGroups define os grupos ou funções que podem enviar mensagens para o conector de recebimento e as permissões concedidas a esses grupos. O conjunto de grupos de permissões é predefinido no Exchange 2007. Portanto, você não pode criar grupos de permissões adicionais. Além disso, você não pode modificar os membros do grupo de permissões ou as permissões associadas.

A Tabela 6 lista os grupos de permissões, os membros dos grupos de permissões e as permissões associadas disponíveis no Exchange 2007.

Tabela 6   Grupos de permissões e permissões associadas do conector de recebimento

Tipos de uso do conector

Ao criar um novo conector, você pode especificar o tipo de uso para ele. O tipo de uso determina as configurações padrão do conector. Isso inclui os SIDs autenticados, as permissões atribuídas a esses SIDs e o mecanismo de autenticação.

A Tabela 7 lista os tipos de uso disponíveis para um conector de recebimento. Quando você seleciona um tipo de uso para um conector de recebimento, grupos de permissões são automaticamente atribuídos ao conector. Um mecanismo de autenticação padrão também está configurado.

Tabela 7   Tipos de uso do conector de recebimento

A Tabela 8 lista os tipos de uso disponíveis para um conector de envio. Quando você seleciona um tipo de uso para um conector de envio, permissões são automaticamente atribuídas aos SIDs. Um mecanismo de autenticação padrão também está configurado.

Tabela 8   Tipos de uso do conector de envio

Se você selecionar o tipo de uso Personalizado para um conector de envio ou de recebimento, deverá configurar manualmente o método de autenticação e os SIDs autorizados e atribuir permissões aos SIDs. Se você não especificar um tipo de uso, ele será definido como Personalizado.

Configurando permissões usando o script Enable-CrossForestConnector

Você pode usar o script Enable-CrossForestConnector.ps1 para simplificar o modo como as permissões são configuradas em conectores entre florestas. Esse script atribui permissões de forma semelhante aos grupos de permissões. Um conjunto definido de permissões é atribuído a um conector de envio ou de recebimento. Você pode modificar esse conjunto de permissões conforme necessário para o cenário da conexão, modificando o conteúdo do script Enable-CrossForestConnector.ps1. Para obter mais informações, consulte Configurando conectores entre florestas.

Configurando permissões usando o cmdlet Add-AdPermission

O cmdlet Add-AdPermission do Shell de Gerenciamento do Exchange é um cmdlet global usado para atribuir permissões a objetos armazenados no Active Directory. Você pode usar o cmdlet Add-AdPermission para conceder permissões individuais em um conector de envio ou de recebimento. O cmdlet Add-AdPermission normalmente não é usado para gerenciar permissões de transporte. Entretanto, deve ser usado para configurar permissões nos seguintes cenários:

• Estabelecer fluxo de mensagens em um cenário entre florestas.

• Aceitar email anônimo da Internet de um remetente de um domínio autoritativo.

As permissões de transporte do Exchange 2007 são parte do conjunto de direitos estendidos que podem ser atribuídos com o uso desse cmdlet. O procedimento a seguir mostra como você pode usar o cmdlet Add-AdPermission para definir permissões em um conector de recebimento do servidor de Transporte de Hub para permitir que sessões anônimas enviem mensagens:

Como definir permissões em um conector de recebimento usando o Shell de Gerenciamento do Exchange

• Execute o seguinte comando:

  Add-AdPermission -Identity "Default Hub1" -User "NT AUTHORITY\ANONYMOUS LOGON" -ExtendedRights ms-Exch-SMTP-Submit,ms-Exch-SMTP-Accept-Any-Recipient,ms-Exch-Bypass-Anti-Spam
  

Você pode usar o cmdlet Get-AdPermission para exibir a DACL para um conector de envio ou de recebimento. Execute um dos seguintes comandos para recuperar as permissões atribuídas a um conector de recebimento e para exibir os resultados em uma tabela formatada:

Como exibir as permissões estendidas em um conector de recebimento usando o Shell de Gerenciamento do Exchange

• Execute um dos seguintes comandos:

  Get-AdPermission -Identity "Default ServerName" | format-table -view User
  Get-AdPermission -Identity "Default ServerName" | format-table -view Identity
  

Você pode usar o cmdlet Remove-AdPermission para remover quaisquer permissões atribuídas anteriormente.

Para obter mais informações sobre como configurar, exibir e remover permissões usando o Shell de Gerenciamento do Exchange, consulte os seguintes tópicos:

• Add-ADPermission

• Get-ADPermission

• Remove-ADPermission

Configurando permissões usando o ADSI Edit

O ADSI (Active Directory Service Interfaces) Edit é um Console de Gerenciamento da Microsoft fornecido com as Ferramentas de Suporte do Windows. Ele é usado como um editor de nível baixo para modificação de propriedades do Active Directory ou objetos ADAM não expostos em outras interfaces de gerenciamento. O ADSI Edit deve ser usado somente por administradores experientes.

Você pode usar o ADSI Edit para exibir e modificar as ACLs para conectores de envio e de recebimento. Depois de abrir o ADSI Edit, você localiza o objeto do conector. Os conectores do Exchange 2007 são armazenados na partição de configuração do serviço de diretório. Os conectores de envio são armazenados como um objeto no contêiner de conexões. Os conectores de recebimento são armazenados como um objeto filho do servidor de transporte do Exchange 2007.

Para modificar as permissões do conector de recebimento usando o ADSI Edit:

1. Localize o conector de recebimento, indo para o seguinte local:

   CN=Configuration\CN=Services\CN=Microsoft Exchange\CN=<Organization>\CN=Administrative Groups\CN=Exchange Administrative Group (FYDIBOHF23SPDLT)\CN=Servers\CN=<Server Name>\CN=Protocols\CN=SMTP Receive Connectors

2. Selecione um conector de recebimento no painel de resultados. Clique com o botão direito e clique em Propriedades.

3. Clique na guia Segurança. A tela a seguir é exibida:

   

4. Clique em Adicionar para selecionar o usuário ou grupo ao qual estão sendo concedidas permissões ou selecione uma entrada existente de Nome de usuário ou grupo.

5. Selecione as permissões que devem ser atribuídas à conta e marque a caixa de seleção na coluna Permitir.

Para modificar as permissões do conector de envio usando o ADSI Edit:

1. Localize o conector de envio, indo para o seguinte local:

   CN=Configuration\CN=Services\CN=Microsoft Exchange\CN=<Organization>\CN=Administrative Groups\CN=Exchange Administrative Group(FYDIBOHF23SPDLT)\CN=Routing Groups\CN=Routing Group (DWBGZMFD01QNBJR)\CN=Connections

2. Selecione um conector de envio no painel de resultados. Clique com o botão direito e clique em Propriedades.

3. Clique na guia Segurança. A tela a seguir é exibida:

   

4. Clique em Adicionar para selecionar o usuário ou grupo ao qual estão sendo concedidas permissões ou selecione uma entrada existente de Nome de usuário ou grupo.

5. Selecione as permissões que devem ser atribuídas à conta e marque a caixa de seleção na coluna Permitir.

Solução de problemas de permissões

Durante a conversa de protocolo, o servidor SMTP pode rejeitar certos comandos por falta de permissões. A Tabela 9 lista as mensagens de rejeição de protocolo mais comuns e a configuração de permissões que causam o erro.

Tabela 9   Mensagens comuns de rejeição de protocolo e suas causas

Para obter mais informações

Para obter mais informações, consulte os seguintes tópicos:

• Conectores de Envio

• Conectores de Recebimento

• Set-SendConnector

• Set-ReceiveConnector

• Add-ADPermission

• Get-ADPermission

• Gerenciando domínios aceitos