Solução de problemas para os clientes do Office 365 dedicado/ITAR (vNext) a delegação entre florestas

IMPORTANTE: Este artigo foi traduzido pelo software de tradução automática da Microsoft e eventualmente pode ter sido editado pela Microsoft Community através da tecnologia Community Translation Framework (CTF) ou por um tradutor profissional. A Microsoft oferece artigos traduzidos automaticamente por software, por tradutores profissionais e editados pela comunidade para que você tenha acesso a todos os artigos de nossa Base de Conhecimento em diversos idiomas. No entanto, um artigo traduzido pode conter erros de vocabulário, sintaxe e/ou gramática. A Microsoft não é responsável por qualquer inexatidão, erro ou dano causado por qualquer tradução imprecisa do conteúdo ou por seu uso pelos nossos clientes.

Clique aqui para ver a versão em Inglês deste artigo: 3064053
Sintomas
Clientes do Microsoft Exchange Online vNext tem problemas na funcionalidade de suas permissões de "acesso total", "send as" permissões e delegar acesso a objetos em diferentes ambientes.
Causa
Delegação entre florestas (incluindo permissões "Enviar como" e "acesso total") para funcionar como o esperado, vários requisitos devem ser atendidos.
Resolução
Delegação entre florestas requer uma configuração específica na nuvem e no ambiente de serviços de domínio Active Directory (AD DS) no local. A seguir é comuns cenários de solução de problemas:
  • Delegante/representante
  • Acesso total do usuário e permissões "Enviar como" para caixa de correio compartilhada

Delegante/representante

Visão geral

Nesse cenário, o representante pode exibir determinadas pastas de caixa de correio de delegante. O representante também tem permissões "send on behalf" à caixa de correio de delegante. O delegado é adicionado ao atributo publicDelegates (também conhecido como o atributoGrantSendOnBehalfTono Microsoft Exchange Server)em delegante recebe permissões de nível de pasta para as pastas de caixa de correio e da caixa de correio. Esse cenário requer o seguinte:

  1. A capacidade de adicionar um usuário de outra floresta como um representante.

    Objetos de cada usuário devem existir na nuvem e o ambiente local. O usuário será um objeto de caixa de correio em um ambiente e um usuário habilitado para email em outro ambiente. Para adicionar um usuário habilitado para email para um delegado, o valor do atributo msExchRecipientDisplayType deve ser definido para -1073741818. Este valor faz com que o objeto ACLable. Ou seja, ele permite que o objeto seja adicionado a uma lista de controle de acesso (ACL). O Outlook reconhece que este objeto e a esteja adicionada como um delegado, mesmo que não seja uma caixa de correio no ambiente do Exchange de delegante.

    Por padrão, esse valor é configurado na nuvem. No entanto, o cliente deve configurar um processo para atualizar esse valor para todos os usuários habilitados para email no seu ambiente do Exchange local (representando as caixas de correio da nuvem). Iniciando no Microsoft Exchange Server 2013 CU10 (local instalação do Exchange), todos os usuários de correio definirá o atributo apropriadomsExchRecipientDisplayType .

    Clientes dedicados herdados movendo para vNext

    Usuários de e-mail nos ambientes legados dedicados será ACLable. Usuários de correio individuais em vNext podem pedir para ser atualizado manualmente. Para obter mais informações, consulteKB 3187967 não é possível adicionar outra caixa de correio no Outlook após a migração para Office 365 dedicado/ITAR (vNext).

    O Exchange 2010 e Exchange 2013 (antes da liberação do CU10)

    Os usuários podem atualizar os provisionamento scripts ou processos para configurar qualquer caixa de correio remota recém configurada como ACLable. Um cmdlet que se parece com o exemplo a seguir deve ser integrado aos processos de provisionamento. Esse cmdlet é executado em relação as instalações AD DS para o objetoRemoteMailbox. Este esteja representada como um objeto de usuário de email.

    Exemplo:
    Get-ADUser $User| Set-ADObject -Replace @{msExchRecipientDisplayType=-1073741818}
    Exchange 2013 CU10

    Quando o Exchange Server 2013 CU10 é lançado para o público, você encontrará uma nova funcionalidade que permite que um administrador execute uma alteração organizacional para definir objetos sincronizados como ACLable no Outlook. Depois disso, chamadas feitas por meio de serviço de replicação de caixa de correio (SRTA) permitirá MEUs locais como ACLable.
    Set-OrganizationConfig -ACLableSyncedObjectEnabled $true
  2. A capacidade de acessar a caixa de correio pastas entre florestas no Outlook.

    Essa funcionalidade está disponível em clientes que estejam executando o Office Outlook 2007 SP1 ou uma versão posterior.

  3. A capacidade de delegar enviar em nome de delegante.

    A permissão "send on behalf" existe no ambiente que hospeda a caixa de correio do delegante quando o delegado é adicionado no Outlook. Essa permissão é concedida quando o atributo publicDelegatesé definido em um ambiente e sincronizado com outro ambiente que usa Azure AD Sync (sincronização AAD). O nome do atributo no Exchange éGrantSendOnBehalfTo.

    Por padrão, o valor desse atributo é sincronizado do ambiente local para a nuvem. No entanto, o valor não sincronizar da nuvem no ambiente local. O cliente deve criar transformações manuais AAD sincronizados para esse atributo para seu diretório de fluxo. Essas transformações devem ser configuradas pelo cliente em sua instalação de sincronização AAD.

    • Entrada nova sincronização fluxo da nuvem AD para o metaverso local:
      FlowType = direta
      Atributo target = publicDelegates
      Origem = cloudPublicDelegates
    • Fluxo de sincronização do metaverso local para o local de saída AD:
      FlowType = direta
      Atributo target = publicDelegates
      Origem = publicDelegates

    Isso significa que um representante é removido da caixa de correio de delegante na nuvem e, em seguida, a alteração é sincronizada no ambiente local por sincronização AAD.

    Observação: Por padrão, as versões futuras do AADConnect irá fluir esse atributo para baixo do Azure AD.

Responsabilidades do recurso

Para o cliente:

  • Sincronização de AAD transfere manualmente o atributo publicDelegates da nuvem para AD Azure no local.
  • Os usuários habilitados para email no local AD deve definir o valor do atributo msExchRecipientDisplayType para -1073741818 (Este é o valor padrão no Exchange 2013 CU9 e versões posteriores). Portanto, eles são ACLable.
Da Microsoft:

  • Encaminhar sincronização do AD Azure para Exchange Online

    Quando um atributo é sincronizado com sincronização AAD AD Azure, o processo de sincronização direta sincroniza os valores apropriados no Exchange Online.
  • Os usuários habilitados para email na nuvem devem definir o valor do atributo msExchRecipientDisplayType para -1073741818. Portanto, eles são ACLable (somente clientes Office 365 dedicado).
  • BackSync transfere o atributo CloudPublicDelegates do Exchange Online para AD Azure. Isso permite que o cliente transformação de sincronização AAD flua o valor do anúncio Azure a instalações AD (somente clientes Office 365 dedicado).

Solução de Problemas

Se os usuários relatar problemas ao tentar concluir tarefas relacionadas ao delegado, siga estas etapas:

  1. No caso do escopo apropriadamente.

    • Que está relatando o problema: representante ou delegante?
    • Qual é o problema que estão vendo? Por exemplo, os usuários não podem adicionar um delegado, não é possível remover um representante ou o representante não pode usar "send on behalf" ou acesso a uma pasta específica.
  2. Examine o atributo publicDelegates (também conhecido como atributo deGrantSendonBehalfTo no Exchange) o local AD DS e AD Azure para confirmar se as permissões estão configuradas corretamente.

    1. Atributos do Active Directory local podem ser exportados usando o módulo de diretório ativo do Windows PowerShell.

    2. Atributos do Active Directory Azure podem ser exportados usando o módulo de AD Azure (arquivo de download e as instruções estão disponíveis noGerenciar o AD Azure usando o Windows PowerShell).
  3. Com base nas informações fornecidas, revise as responsabilidades de visão geral e recurso para determinar onde a configuração incorreta pode existir.

Acesso de usuário completo e enviar como permissões de caixa de correio compartilhada

Visão geral

Objetos de cada usuário devem existir no ambiente de nuvem e local. O usuário será um objeto de caixa de correio em um ambiente e um usuário habilitado para email em outros ambientes. Enviar como e as permissões de acesso completo são armazenadas na lista de controle de acesso (ACL) no objeto de usuário e não são replicadas por sincronização AAD. Envie como as permissões são verificadas no ambiente da caixa de correio do remetente ou do delegado. Isso pode aumentar a complexidade em cenários que envolvem delegates e caixas de correio compartilhadas em diferentes ambientes. A permissão de acesso total do usuário que permite acesso à caixa de correio não é afetada por caixas de correio em diferentes ambientes. Em um ambiente híbrido, que se espera que enviam como permissões precisam ser gerenciados em dois objetos.

Enviar como permissões na nuvem são gerenciadas usando o cmdlet Exchange Online, Adicionar RecipientPermission. Enviar como permissões locais são gerenciados usando o cmdlet Exchange, Adicionar ADPermission.

Permissões de acesso total são gerenciadas usando o Adicionar MailboxPermission cmdlet.

Existem dois cenários que envolvem as permissões:

  1. Caixa de correio do representante está no local e a caixa de correio compartilhada é na nuvem.

    Quando a caixa de correio compartilhada é movida para a nuvem, o Exchange SRTA copia o acesso completo e "send as" permissões ACLs durante a migração. Todas as permissões que já são definidas na caixa de correio são transferidas e permanecem no usuário habilitado para email no ambiente local. O delegado continuarão a poder enviar como e acessar a caixa de correio porque existem as permissões no objeto no ambiente local. Que o delegado é movido posteriormente para a nuvem, nenhuma alteração adicional é necessária. Os usuários continuarão a poder enviar da caixa de correio porque as permissões também existem na caixa de correio na nuvem. Se as permissões forem alteradas depois que a caixa de correio for movida, etapas adicionais podem ser necessárias.
  2. Caixa de correio do representante está na nuvem, e a caixa de correio compartilhada é local.

    "Enviar como"permissões

    As permissões "send as" devem ser adicionadas ao objeto habilitado para email na nuvem, que representa a caixa de correio compartilhada. O cliente pode preparar para uma migração concluir uma varredura única e das permissões de caixa de correio no ambiente local e adicionando manualmente essas permissões aos objetos na nuvem. Qualquer permissão "Enviar como" é as alterações após a movimentação da caixa de correio deve ser atualizada manualmente nos objetos de caixa de correio compartilhada em ambos os ambientes.

    "Acesso total"permissões

    O permissionsremain "acesso total" na caixa de correio local após a migração. Etapas adicionais podem ser necessárias quando você adicionar novas permissões.

Responsabilidades do recurso

Para o cliente:

  • Gerenciamento de permissões no local e em nuvem ambientes Exchange

Solução de Problemas

  1. Caso o escopo apropriado:

    • Quais usuários e caixas de correio compartilhadas estão envolvidas?
    • Qual o ambiente hospeda cada caixa de correio?
  2. Solicite uma cópia das permissões do AD DS o local AD DS e on-line do Exchange:

    1. Local atributos do AD DS podem ser exportados usando o módulo de diretório ativo do Windows PowerShell:

    2. Permissões do Exchange Online podem ser exportadas usando o PowerShell remoto (RPS):

  3. Com base nas informações fornecidas, revise as responsabilidades de visão geral e recurso para determinar onde a configuração incorreta pode existir.

Propriedades

ID do Artigo: 3064053 - Última Revisão: 11/14/2016 21:55:00 - Revisão: 3.0

Microsoft Business Productivity Online Dedicated, Microsoft Business Productivity Online Suite Federal

  • vkbportal226 kbmt KB3064053 KbMtpt
Comentários