In Exchange 2010 können keine Sendeberechtigungen erteilt werden

Ich versuche, einem Benutzer in Exchange 2010 die Berechtigung "Senden als" zu erteilen. Hier ist der Powershell-Befehl, den ich ausführe:

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

Powershell gibt diesen Fehler zurück:

Der Active Directory-Vorgang ist in DC.OurDomain.pri fehlgeschlagen. Dieser Fehler kann nicht behoben werden. Zusätzliche Informationen: Der Zugriff wird verweigert. Active Directory-Antwort: 00000005: SecErr: DSID-031521D0, Problem 4003 (INSUFF_ACCESS_RIGHTS), Daten 0 + CategoryInfo: WriteError: (0: Int32) [Add-ADPermission], ADOperationException + FullyQualifiedErrorId: EDBB94At.Tan. AddADPermission

Ich habe mehrere Alternativen zum Powershell-Befehl ausprobiert - dh. Verwenden von -Identity usw., aber das und der EMV-Assistent geben alle den gleichen Fehler zurück.

Ich bin nicht sicher, ob sich "INSUFF_ACCESS_RIGHTS" auf mich bezieht, der den Befehl ausführt, oder auf den Benutzer, dem ich die Send-as-Rechte erteile.

Ich habe die Microsoft Technet- Webseite "Senden als Berechtigungen für ein Postfach verwalten" hier verfolgt: http://technet.microsoft.com/en-us/library/bb676368.aspx

Haben Sie also die zwei Berechtigungen hinzugefügt, die Sie dazu benötigen:

Organisationsmanagement

Empfängerverwaltung

Das hilft aber nicht. Irgendwelche Ideen?

Aktualisieren

Wenn ich folgendes mache:

• Öffnen Sie "AD Users & Computers" mit der Ansicht "Advanced Features"
• Gehen Sie zu den Eigenschaften von Benutzer1
• Klicken Sie auf der Registerkarte Sicherheit auf "Erweitert"
• Wählen Sie "Hinzufügen"
• Geben Sie "User2" ein und wählen Sie "Send As" Allow

Das funktioniert, wenn ich ADUaC schließe und wieder öffne und die neuen Berechtigungen erneut überprüfe, die noch vorhanden sind. Wenn ich ungefähr 10 Minuten später zurückkehre, sind diese Berechtigungen jetzt weg - Benutzer2 wird in den Sicherheitsberechtigungen von Benutzer1 überhaupt nicht angezeigt.

Ich glaube nicht, dass ich jemals zuvor ein solches AD-Verhalten gesehen habe.

Ich habe das endlich behoben.

Interessanterweise ist Send-As eine AD-Berechtigung - keine Austauschberechtigung, wie Sie es vielleicht erwartet haben.

Wie auch immer, das sind die Schritte:

Machen Sie das Zielpostfach mit diesem Befehl in Powershell auf Ihrem Exchange Server "gemeinsam nutzbar":

Set-Mailbox user1 -type:shared

Wenn Sie diesen Fehler erhalten (wie in meinem ersten Beitrag):

Sie müssen diesen Benutzer in AD finden und zu den Eigenschaften >> Sicherheit >> Erweitert gehen:

Sie müssen die Option "Vererbbare Berechtigungen vom übergeordneten Objekt dieses Objekts einschließen " aktivieren :

Sobald dies erledigt ist, sollten Sie in der Lage sein, das Ordnerfreigabeskript abzuschließen.

Gewähren Sie dann tatsächlich die Rechte mit diesem Befehl:

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

Hoffe das hilft anderen, die das gleiche Problem haben.

Kieran

Nachrichten, denen der Zugriff verweigert wurde, stammen normalerweise von dem Konto, auf dem die PowerShell-Sitzung ausgeführt wird und das nicht über ausreichende Berechtigungen verfügt. Ich bekomme dies die ganze Zeit, wenn ich nur die Exchange-Verwaltungsshell starte, anstatt sie als mein Administrator-Benutzerkonto auszuführen.

Ich vermute, dass Benutzer1 nach Ihrem Update möglicherweise Teil einer geschützten Gruppe (Druckoperatoren) ist, sodass Exchange Ihnen das Senden als für Benutzer2 nicht gestattet, da es weiß, dass es erst in der nächsten Stunde entfernt wird. Es sieht so aus, als hätten Sie diese Theorie bestätigt, indem Sie Send As mithilfe von ADUC manuell hinzugefügt und kurze Zeit später entfernt haben.

Auf dem Domänencontroller, auf dem die PDM-Emulator-FSMO-Rolle ausgeführt wird, wird stündlich ein sogenannter adminSDHolder-Thread ausgeführt. Dabei werden alle Konten, die sich in geschützten Gruppen befinden (oder jemals entfernt wurden, auch wenn sie später entfernt wurden) (Unternehmensadministratoren, Domänenadministratoren, Kontobetreiber, Druckbetreiber, um nur einige der gebräuchlichsten zu nennen), alle Konten entfernt Berechtigungen für die Objekte erteilt und durch bestimmte explizit definierte Berechtigungen ersetzt. Die Idee ist, dass ein delegiertes Konto nicht in der Lage ist, Chaos zu verursachen und einem Domain-Administrator seine Berechtigungen zu entziehen.

Ich bin nicht ganz davon überzeugt, dass Ihr Fix, explizit die Erlaubnis zu erteilen, funktionieren wird und nicht jede Stunde zurückgesetzt wird, aber ich habe mich vorher geirrt - wenn ja, großartig! Wenn der Benutzer jedoch nicht zur Gruppe der Druckoperatoren gehören muss , empfehlen wir Ihnen, sein Konto mithilfe von ADSI Edit zu ändern und die Eigenschaft adminCount auf Null zu setzen. Aktivieren Sie dann die vererbbaren Berechtigungen für das Benutzerobjekt und setzen Sie die Standardberechtigungen zurück. Versuchen Sie anschließend Ihr Exchange-Cmdlet erneut, und mit etwas Glück funktioniert es (geben Sie offensichtlich genügend Zeit für die AD-Replikation).

Ich glaube nicht, dass Sie Ihr Cmdlet ändern können, um dies zu berücksichtigen. Wie ich bereits sagte, stelle ich mir (allerdings nicht sicher) vor, dass Sie dies nicht tun können, da Exchange weiß, dass die Berechtigung nur entfernt wird kurz danach und versucht, Verwirrung von Ihrer Seite zu sparen. Unter "normalen" Umständen (dh bei einem Standardbenutzer) sollte das Cmdlet problemlos funktionieren, da nicht einmal der gesamte adminSDHolder-Thread ins Spiel kommt.

Haben Sie gesehen, dass diese KB: Zugriff verweigert wurde, wenn Sie versuchen, dem Benutzer die Berechtigung "Senden als" oder "Empfangen als" für eine Verteilergruppe in Exchange Server 2010 oder Exchange Server 2013 zu erteilen

Ursache

Standardmäßig wird Exchange Trusted Subsystem nicht die Berechtigung "Berechtigungen ändern" erteilt. Dies führt dazu, dass das Cmdlet Add-ADPermission mit einem Fehler "Zugriff verweigert" fehlschlägt.

Auflösung

Um dieses Problem zu umgehen, fügen Sie der Organisationseinheit (OU), die die Verteilergruppe enthält, die Berechtigung "Berechtigungen ändern" für das vertrauenswürdige Exchange-Subsystem hinzu, indem Sie die folgenden Schritte ausführen:

1. Öffnen Sie Active Directory-Benutzer und -Computer.
2. Klicken Sie auf Ansicht und dann auf Erweiterte Funktionen.
3. Klicken Sie mit der rechten Maustaste auf die Organisationseinheit, die die Verteilerlisten enthält, und klicken Sie dann auf Eigenschaften.
4. Klicken Sie auf der Registerkarte Sicherheit auf Erweitert.
5. Klicken Sie auf der Registerkarte Berechtigungen auf Hinzufügen.
6. Geben Sie im Auswahlfeld Objektnamen eingeben ein vertrauenswürdiges Exchange-Subsystem ein, und klicken Sie dann auf OK.
7. Wählen Sie auf der Registerkarte Objekt die Option Dieses Objekt und alle untergeordneten Objekte in der Liste Anwenden auf aus, suchen Sie in der Liste Berechtigungen nach Berechtigungen ändern und setzen Sie sie dann auf Zulassen.
8. OK klicken.

Beim Versuch, die Migration auf o365 einzurichten, ist diese "Vererbung nicht aktiviert" für ein Benutzerkonto aufgetreten. Exchange-Eigenschaften konnten nicht importiert werden. Schrieb diese kleine Routine, um das Kontrollkästchen "Vererbbare Berechtigungen" zu aktivieren.

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

Die oben genannten Lösungen haben mein Problem nicht gelöst, aber dieses Problem hat es gelöst: http://support.risualblogs.com/blog/2012/02/07/the-user-has-insufficient-access-rights-error-when-trying- to-set-send-as-permissions-on-a-mailbox-in-exchange-2010 /

Für das bestimmte AD-Benutzerkonto, für das ich die Berechtigung "Senden als" festlegen wollte, wurden in AD keine vererbbaren Berechtigungen aktiviert.