J'essaie de donner des autorisations "envoi" à un utilisateur dans Exchange 2010. Voici le commandement PowerShell, je suis en cours d'exécution:
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éalisée. Informations supplémentaires: l'accès est refusé. Active Directory Réponse: 00000005: SECERR: DSID-031521D0, Problème 4003 (INSFF_Access_rights), Data 0 + CatégorieInfo: WellsError: (0: Int32) [Ajouter-Adpermission], AdopérationException + entièrementQualiedErroride: EDBB94A3, Microsoft.Exchange.management.RecipientTasks. Addadpert
J'ai essayé plusieurs alternatives à la commande PowerShell - c'est-à-dire. Utilisation -IDentitinity, etc., mais cela et l'assistant EMC renvoient toutes la même erreur.
Je ne suis pas sûr si le "INSFF_Access_Rights" se réfère à moi qui exécute la commande ou l'utilisateur que je donne les droits d'envoi?
Je suis suivi de Microsoft Techet "Gérer l'envoi d'autorisations pour une boîte aux lettres" page Web ici: http://technet.microsoft.com/en-us/library/ bb676368.aspx
J'ai donc ajouté les deux autorisations dont vous avez besoin pour faire cela:
Gestion de l'organisation
Gestion des destinataires
Mais cela ne fait pas aider. Des idées?
Si je fais ce qui suit:
Cela fonctionne, si je ferme l'aduac et que je l'ouvre à nouveau et vérifiez ces nouvelles autorisations qu'ils sont toujours là. Si je reviens environ 10 minutes plus tard, ces autorisations sont maintenant parties - User2 ne s'affiche pas dans les autorisations de sécurité de l'utilisateur1 du tout.
Ne pense pas que j'ai jamais vu ce genre de comportement de publicité avant.
J'ai finalement réparé cela.
Inquiètaez-vous, comme c'est une autorisation d'annonce - pas une autorisation d'échange comme vous auriez pu être attendue.
Quoi qu'il en soit, ce sont les étapes:
Faire la boîte aux lettres cible "Shareable" à l'aide de cette commande dans PowerShell sur votre serveur Exchange:
Set-Mailbox user1 -type:shared
Si vous obtenez cette erreur (identique à mon premier post):
Vous devrez trouver cet utilisateur dans l'annonce et aller aux propriétés >> Sécurité >> Avancé:
Vous devez [~ # ~] activer [~ # ~]] L'option "Inclure des autorisations héritables du parent de cet objet":
Une fois que cela est fait, vous devriez pouvoir remplir le script de partage de dossier.
Ensuite, accorde effectivement les droits en utilisant cette commande:
Add-ADPermission user1 -User Ourdomain\User2 -ExtendedRights "Send As"
J'espère que cela aide les autres qui ont le même problème.
Kieran
L'accès aux messages refusés provient généralement du compte exécutant la session PowerShell n'ayant pas assez d'autorisation. Je reçois cela tout le temps Lorsque je viens de lancer la coquille de gestion Exchange au lieu de fonctionner comme mon compte d'utilisateur administratif.
Suite à votre mise à jour, ce que je soupçonne peut se produire est que User1 fait partie d'un groupe protégé (opérateurs d'impression) afin que Exchange ne vous permet pas d'accorder l'envoi comme sur User2 car il sait qu'il ne sera extrêté que dans l'heure suivante. On dirait que vous avez confirmé que la théorie en ajoutant manuellement Envoyer comme en utilisant ADUC et le voyant de supprimer une courte durée plus tard.
Sur le contrôleur de domaine qui exécute le rôle PDC Emulator FSMO, chaque heure, quelque chose appelé The Adminsdholder thread est exécuté. Ce que cela prend suffit tous les comptes qui sont (ou ont déjà été, même s'ils ont ensuite supprimé) dans des groupes protégés (administrateurs d'entreprise, administrateurs de domaine, opérateurs de comptes, exploitants d'impression pour nommer quelques-uns des plus courants) et supprime tout Les autorisations accordées sur les objets et les remplace avec certaines autorisations explicitement définies. L'idée étant qu'un compte délégué ne soit pas capable de faire des ravages et de dénoncer un administrateur de domaine de leurs privilèges.
Je ne suis pas entièrement convaincu que votre solution d'autorisation explicitement accordée au travail et ne sera pas réinitialisé toutes les heures, mais j'ai eu tort auparavant - donc si cela le fait, génial! Si toutefois, l'utilisateur n'a pas besoin d'être dans le groupe d'opérateurs d'impression, je vous recommanderais de modifier leur compte à l'aide de ADSI Modifier et de définir la propriété Admincount propriété à zéro. Activez ensuite des 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 cmdlet Exchange et avec un peu de chance, cela fonctionnera (donnez-vous évidemment suffisamment de temps pour que la réplication annonce se produise).
Je ne pense pas que vous puissiez modifier votre cmdlet pour pouvoir accueillir cela - comme je l'ai dit, i Imaginez (pas certain cependant) que cela Ne vous laissera pas le faire car Exchange sait que la permission ne sera jamais supprimée sous peu de temps après et essaie de sauver la confusion de votre part. Sous les circonstances "normales" (c'est-à-dire un utilisateur standard), la cmdlet ne doit que travailler sans problème, car l'ensemble du fil d'administrateur d'administrateur n'entre même pas en jeu.
Avez-vous vu ce KB: accès refusé lorsque vous essayez de donner à l'utilisateur "envoi" ou "recevoir comme" autorisation pour un groupe de distribution dans Exchange Server 2010 ou Exchange Server 201
Par défaut, le sous-système de confiance des échanges n'est pas accordé la permission de "modifier les autorisations". Cela provoque l'échec de la cmdlet ADD-Adpermission par une erreur refusée.
Pour contourner ce problème, ajoutez l'autorisation "Modifier les autorisations" du sous-système de confiance des échanges à l'unité organisationnelle (OU) contenant le groupe de distribution en procédant comme suit:
- Ouvrez les utilisateurs et les ordinateurs Active Directory.
- Cliquez sur Afficher, puis sur Fonctions avancées.
- Cliquez avec le bouton droit sur l'unité de commande contenant les listes de distribution, puis cliquez sur Propriétés.
- Dans l'onglet Sécurité, cliquez sur Avancé.
- Dans l'onglet Autorisations, cliquez sur Ajouter.
- Dans le nom d'objet Enter pour sélectionner la case, tapez Sous-système de confiance Exchange, puis cliquez sur OK.
- Dans l'onglet Objet, sélectionnez cet objet et tous les objets de descendants dans la liste Appliquer sur la liste, localisez la modification des autorisations dans la liste des autorisations, puis définissez-la pour permettre.
- Cliquez sur OK.
Rencontré cette "héritage non activée" sur le compte d'un utilisateur, tout en essayant de configurer la migration vers O365. Impossible d'importer des propriétés d'échange. A écrit cette petite routine pour activer la case "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 celle-ci l'a fait: http://support.risalblogs.com/blog/2012/02/07/the-user-has-sufficitive-access-rights-Error- Quand-tenta-t-on-définir-envoi-sweorissions-on-mailbox-in-Exchange-2010 /
Le compte d'utilisateur de la publicité en particulier que j'essayais de définir Envoyer, car Perms on n'a pas eu d'autorisations héritables vérifiées en annonce.