Não é possível conceder permissões de 'enviar como' no Exchange 2010

Estou tentando conceder permissões de 'enviar como' para um usuário no Exchange 2010. Aqui está o comando do Powershell que estou executando:

Add-ADPermission "User1" -User "Ourdomain\User2" -Extendedrights "Send As"

O PowerShell retorna este erro:

A operação do Active Directory falhou no DC.OurDomain.pri. Este erro não é recuperável. Informações adicionais: Acesso negado. Resposta do Active Directory: 00000005: SecErr: DSID-031521D0, problema 4003 (INSUFF_ACCESS_RIGHTS), dados 0 + CategoryInfo: WriteError: (0: Int32) [Add-ADPermission], ADOperationException + FullyQualifiedErrorId: EDBB94A3, Microsoft.Exchange.Get. AddADPermission

Eu tentei várias alternativas ao comando Powershell - ie. usando -Identity etc., mas isso e o assistente EMC retornam o mesmo erro.

Não tenho certeza se o "INSUFF_ACCESS_RIGHTS" está se referindo a mim que está executando o comando ou ao usuário ao qual estou dando os direitos de envio como?

Tenho acompanhado a página da Web Microsoft Technet "Gerenciar permissões de envio como para uma caixa de correio" aqui: http://technet.microsoft.com/en-us/library/bb676368.aspx

Então, você adicionou as duas permissões necessárias para fazer isso:

Gestão da organização

Gerenciamento de Destinatários

Mas isso não está ajudando. Alguma ideia?

Atualizar

Se eu fizer o seguinte:

• abra "Usuários e computadores do AD" com a visualização "Recursos avançados"
• Vá para as propriedades do Usuário1
• Clique em "Avançado" na guia Segurança
• Selecione "Adicionar"
• entre em "Usuário2" e selecione "Enviar como".

Isso funciona, se eu fechar o ADUaC, abri-lo novamente e verificar novamente as novas permissões que ainda estão lá. Se eu retornar cerca de 10 minutos depois, essas permissões serão removidas - o usuário2 não aparecerá nas permissões de segurança do usuário1.

Não pense que eu já vi esse tipo de comportamento do AD antes.

Eu finalmente consertei isso.

Curiosamente, o Send-As é uma permissão do AD - não uma permissão de troca, como você poderia esperar.

Enfim, estas são as etapas:

Torne a caixa de correio de destino "compartilhável" usando este comando no Powershell no Exchange Server:

Set-Mailbox user1 -type:shared

Se você receber esse erro (o mesmo que no meu primeiro post):

Você precisará encontrar esse usuário no AD e acessar as propriedades >> Segurança >> Avançado:

Você precisa habilitar a opção "Incluir permissões herdáveis ​​do pai deste objeto":

Feito isso, você poderá concluir o script de compartilhamento de pastas.

Em seguida, conceda os direitos usando este comando:

Add-ADPermission user1 -User Ourdomain\User2 -ExtendedRights "Send As"

Espero que ajude outras pessoas que têm o mesmo problema.

Kieran

As mensagens de acesso negado geralmente vêm da conta que está executando a sessão do PowerShell sem permissão suficiente. Recebo isso o tempo todo quando inicio o Shell de Gerenciamento do Exchange em vez de executar como minha conta de usuário administrativo.

Após a atualização, o que eu suspeito pode estar acontecendo é que o Usuário1 faz parte de um grupo protegido (operadores de impressão), portanto, o Exchange não permite que você conceda Enviar como no Usuário2, pois sabe que será retirado apenas na próxima hora. Parece que você confirmou essa teoria adicionando manualmente Enviar como usando o ADUC e vendo-a removida pouco tempo depois.

No controlador de domínio que executa a função FSMO do emulador PDC, a cada hora algo chamado de thread adminSDHolder é executado. O que isso faz é pegar todas as contas que estão (ou já foram, mesmo que tenham sido removidas posteriormente) em grupos protegidos (Administradores Corporativos, Administradores de Domínio, Operadores de Contas, Operadores de Impressão, para citar alguns dos mais comuns) e remove todos os permissões concedidas nos objetos e as substitui por certas permissões definidas explicitamente. A ideia é que uma conta delegada não seja capaz de causar estragos e tirar dos privilégios um administrador de domínio.

Não estou inteiramente convencido de que sua correção de conceder permissão explicitamente funcione e não será redefinida a cada hora, mas já estive errado antes - então, se funcionar, ótimo! Se, no entanto, o usuário não precisar estar no grupo Operadores de impressão, recomendo que você modifique a conta deles usando o ADSI Edit e defina a propriedade adminCount como zero. Ative as permissões herdáveis ​​no objeto de usuário e redefina as permissões padrão. Depois de fazer isso, tente seu cmdlet do Exchange novamente e com um pouco de sorte ele funcionará (obviamente, dê tempo suficiente para que a replicação do AD ocorra).

Eu não acho que você poderá modificar seu cmdlet para acomodar isso - como eu disse, imagino (embora não tenha certeza) que não permitirá que você faça isso porque o Exchange sabe que a permissão será removida logo depois e está tentando economizar confusão de sua parte. Sob circunstâncias "normais" (ou seja, um usuário padrão), o cmdlet deve funcionar sem problemas, porque todo o segmento adminSDHolder nem entra em ação.

Você já viu este KB: Acesso negado ao tentar conceder ao usuário "enviar como" ou "receber como" permissão para um grupo de distribuição no Exchange Server 2010 ou Exchange Server 2013

Causa

Por padrão, o Exchange Trusted Subsystem não recebe a permissão "modificar permissões". Isso faz com que o cmdlet Add-ADPermission falhe com um erro de acesso negado.

Resolução

Para contornar esse problema, adicione a permissão "modificar permissões" para o Exchange Trusted Subsystem à unidade organizacional (UO) que contém o grupo de distribuição seguindo estas etapas:

1. Abra Usuários e Computadores do Active Directory.
2. Clique em Exibir e, em seguida, clique em Recursos avançados.
3. Clique com o botão direito do mouse na UO que contém as listas de distribuição e clique em Propriedades.
4. Na guia Segurança, clique em Avançado.
5. Na guia Permissões, clique em Adicionar.
6. Na caixa Digite o nome do objeto a ser selecionado, digite subsistema confiável do Exchange e clique em OK.
7. Na guia Objeto, selecione Este objeto e todos os objetos descendentes na lista Aplicar em, localize Modificar permissões na lista Permissões e defina-o como Permitir.
8. Clique OK.

Foi encontrada essa 'herança não ativada' na conta de um usuário, enquanto tentava configurar a migração para o o365. Não foi possível importar propriedades do Exchange. Escreveu esta pequena rotina para ativar a caixa de seleção 'permissões herdáveis'.

$user = Get-ADuser -Filter "(displayname -eq "Joe Cool")
$ou = [ADSI](“LDAP://” + $user)
$sec = $ou.psbase.objectSecurity
If ($sec.get_AreAccessRulesProtected()) {
   $isProtected = $false ## allows inheritance
   $preserveInheritance = $true ## preserver inhreited rules
   $sec.SetAccessRuleProtection($isProtected, $preserveInheritance)
   $ou.psbase.commitchanges()
   Write-Host “$user is now inherting permissions”;
}

As soluções acima não resolveram meu problema, mas esta resolveu: http://support.risualblogs.com/blog/2012/02/07/the-user-has-insufficient-access-rights-error-when-trying- definir como enviar como permissões em uma caixa de correio no Exchange 2010 /

A conta de usuário do AD em que eu estava tentando definir permissões de Enviar como não tinha permissões herdáveis ​​verificadas no AD.