Impossible d'accorder des autorisations d'envoi en tant que dans Exchange 2010

J'essaie d'accorder des autorisations «d'envoi en tant que» à un utilisateur dans Exchange 2010. Voici la commande Powershell que j'exécute:

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

Powershell renvoie cette erreur:

L'opération Active Directory a échoué sur DC.OurDomain.pri. Cette erreur n'est pas récupérable. Informations supplémentaires: l'accès est refusé. Réponse Active Directory: 00000005: SecErr: DSID-031521D0, problème 4003 (INSUFF_ACCESS_RIGHTS), données 0 + CategoryInfo: WriteError: (0: Int32) [Add-ADPermission], ADOperationException + FullyQualifiedErrorId: EDBB94A3, Microsoft.Exchange.Tas. AddADPermission

J'ai essayé plusieurs alternatives à la commande Powershell - ie. en utilisant -Identity etc., mais cela et l'assistant EMC renvoient tous la même erreur.

Je ne sais pas si "INSUFF_ACCESS_RIGHTS" fait référence à moi qui exécute la commande ou à l'utilisateur auquel je donne le droit d'envoi en tant que?

J'ai suivi la page Web Microsoft Technet «Gérer les autorisations Envoyer en tant que pour une boîte aux lettres» ici: http://technet.microsoft.com/en-us/library/bb676368.aspx

Nous avons donc ajouté les deux autorisations dont vous avez besoin pour ce faire:

Gestion de l'organisation

Gestion des destinataires

Mais cela n'aide pas. Des idées?

Mise à jour

Si je fais ce qui suit:

• ouvrir "Utilisateurs et ordinateurs AD" avec la vue "Fonctions avancées"
• Accédez aux propriétés de User1
• Appuyez sur "Avancé" sur l'onglet Sécurité
• Sélectionnez "Ajouter"
• entrez dans "Utilisateur2" et sélectionnez "Envoyer en tant que" Autoriser

Cela fonctionne, si je ferme ADUaC et l'ouvre à nouveau et revérifie ces nouvelles autorisations, elles sont toujours là. Si je reviens environ 10 minutes plus tard, ces autorisations ont maintenant disparu - user2 n'apparaît pas du tout dans les autorisations de sécurité de user1.

Ne pensez pas que j'ai déjà vu ce genre de comportement AD auparavant.

J'ai finalement corrigé cela.

Il est intéressant de noter que Send-As est une autorisation AD - pas une autorisation d'échange comme vous vous en doutez.

Quoi qu'il en soit, voici les étapes:

Rendez la boîte aux lettres cible «partageable» à l'aide de cette commande dans Powershell sur votre serveur Exchange:

Set-Mailbox user1 -type:shared

Si vous obtenez cette erreur (la même que dans mon premier post):

Vous devrez trouver cet utilisateur dans AD et accéder aux propriétés >> Sécurité >> Avancé:

Vous devez ACTIVER l'option "Inclure les autorisations héritables du parent de cet objet":

Une fois cela fait, vous devriez pouvoir terminer le script de partage de dossier.

Accordez ensuite les droits en utilisant cette commande:

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

J'espère que cela aide ceux qui ont le même problème.

Kieran

Les messages d'accès refusé proviennent généralement du compte exécutant la session PowerShell ne disposant pas des autorisations suffisantes. Je reçois cela tout le temps lorsque je lance simplement Exchange Management Shell au lieu de faire fonctionner mon compte d'utilisateur administratif.

Après votre mise à jour, ce que je soupçonne peut-être, c'est que l'utilisateur1 fait partie d'un groupe protégé (opérateurs d'impression), donc Exchange ne vous permet pas d'accorder Envoyer en tant que sur l'utilisateur2 car il sait qu'il ne sera supprimé que dans l'heure suivante. Il semble que vous ayez confirmé cette théorie en ajoutant manuellement Envoyer en utilisant ADUC et en la voyant supprimée peu de temps après.

Sur le contrôleur de domaine qui exécute le rôle FSMO de l'émulateur PDC, toutes les heures, quelque chose appelé le thread adminSDHolder s'exécute. Cela prend tous les comptes qui sont (ou ont été, même s'ils ont été supprimés par la suite) dans des groupes protégés (administrateurs d'entreprise, administrateurs de domaine, opérateurs de compte, opérateurs d'impression pour n'en nommer que quelques-uns des plus courants) et supprime tous autorisations accordées sur les objets et les remplace par certaines autorisations définies explicitement. L'idée étant qu'un compte délégué n'est pas en mesure de faire des ravages et de priver un administrateur de domaine de ses privilèges.

Je ne suis pas entièrement convaincu que votre solution d'accorder explicitement l'autorisation va fonctionner et ne sera pas réinitialisée toutes les heures, mais je me suis trompé auparavant - alors si c'est le cas, tant mieux! Si toutefois l'utilisateur n'a pas besoin d'être dans le groupe Opérateurs d'impression, je vous recommande de modifier son compte à l'aide de ADSI Edit et de définir la propriété adminCount sur zéro. Activez ensuite les autorisations héritables sur l'objet utilisateur et réinitialisez les autorisations par défaut. Une fois que vous avez fait cela, essayez à nouveau votre applet de commande Exchange et avec un peu de chance, cela fonctionnera (donnez évidemment suffisamment de temps pour que la réplication AD se produise).

Je ne pense pas que vous serez en mesure de modifier votre applet de commande pour s'adapter à cela - comme je l'ai dit, j'imagine (pas certain cependant) que cela ne vous permettra pas de le faire car Exchange sait que l'autorisation ne va être supprimée peu de temps après et essaie d'éviter la confusion de votre part. Dans des circonstances "normales" (c'est-à-dire un utilisateur standard), la cmdlet devrait simplement fonctionner sans problème car le thread adminSDHolder entier n'entre même pas en jeu.

Avez-vous vu cette base de connaissances: accès refusé lorsque vous essayez d'accorder à l'utilisateur l'autorisation «envoyer en tant que» ou «recevoir en tant que» pour un groupe de distribution dans Exchange Server 2010 ou Exchange Server 2013

Cause

Par défaut, le sous-système approuvé Exchange ne bénéficie pas de l'autorisation "Modifier les autorisations". Cela provoque l'échec de la cmdlet Add-ADPermission avec une erreur d'accès refusé.

Résolution

Pour contourner ce problème, ajoutez l'autorisation «Modifier les autorisations» pour le sous-système approuvé Exchange à l'unité d'organisation (OU) qui contient le groupe de distribution en procédant comme suit:

1. Ouvrez Utilisateurs et ordinateurs Active Directory.
2. Cliquez sur Affichage, puis sur Fonctionnalités avancées.
3. Cliquez avec le bouton droit sur l'unité d'organisation qui contient les listes de distribution, puis cliquez sur Propriétés.
4. Dans l'onglet Sécurité, cliquez sur Avancé.
5. Dans l'onglet Autorisations, cliquez sur Ajouter.
6. Dans la zone Entrez le nom de l'objet à sélectionner, tapez Sous-système approuvé Exchange, puis cliquez sur OK.
7. Dans l'onglet Objet, sélectionnez Cet objet et tous les objets descendants dans la liste Appliquer à, recherchez Modifier les autorisations dans la liste Autorisations, puis définissez-le sur Autoriser.
8. Cliquez sur OK.

Rencontré cet «héritage non activé» sur le compte d'un utilisateur, tout en essayant de configurer la migration vers o365. Impossible d'importer les propriétés Exchange. A écrit cette petite routine pour activer la case à cocher «autorisations héritables».

$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”;
}

Les solutions ci-dessus n'ont pas résolu mon problème, mais celui-ci l'a fait: http://support.risualblogs.com/blog/2012/02/07/the-user-has-insufficient-access-rights-error-when-trying- définir-envoyer-comme-autorisations-sur-une-boîte aux lettres-en-échange-2010 /

Le compte d'utilisateur AD particulier sur lequel j'essayais de définir les autorisations Envoyer en tant que sur n'avait pas d'autorisations héritées vérifiées dans AD.