Exchange ACL Problem

Diese Seite beschreibt, an welchen Stellen sich in einer "alten Exchange Umgebung" noch alte Exchange 2000/2003 Berechtigungen oder Skype for Business Reste verbergen können, die Folgefehler verursachen.

Dies ist kein How-To und auch keine Erlaubnis mit ADSIEDIT an Berechtigungen zu drehen. Sie sollten schon wissen, was sie tun.

Fehlermeldung

Als ich die Postfachberechtigungen einer "Shared Mailbox" anpassen wollte, bekam ich folgende Fehlermeldung:

Die beiden ObjektType-Einträge habe ich mir erst einmal gemerkt.

Der Zugriffssteuerungseintrag definiert den folgenden ObjectType 'd819615a-3b9b-4738-b47e-f1bd8ee3aea4', der nicht aufgelöst werden kann.
Der Zugriffssteuerungseintrag definiert den folgenden ObjectType 'e2d6986b-2c7f-4cda-9851-d5b5f3fb6706', der nicht aufgelöst werden kann.

Eine schnelle Suche nach den GUIDs ergab schon einige Treffer:

Die Hinweise zeigen Richtung Lync und Skype for Business.

Postfachrechte

Ich hab den Fehler in den Postfachrechten vermutet und mir diese erst einmal ausgeben lassen. Eine Anzeige der Berechtigungen auf dieser SharedMailbox hat neben gültigen Konten auch einige SIDs mittlerweile gelöschter Konten gezeigt. (gekürzte Ausgabe)

[PS] C:\>get-MailboxPermission -Identity shared1 |ft user,isinherited,deny -AutoSize

User                                         IsInherited Deny
----                                         ----------- ----
NT AUTHORITY\SELF                                  False False
NT AUTHORITY\SELF                                  False False
MSXFAQ\Administrator                                True True
MSXFAQ\Domänen-Admins                               True True
MSXFAQ\Organisations-Admins                         True True
MSXFAQ\Exchange Organization Administrators         True True
S-1-5-21-11949449-30417519-71842111-5870            True True
MSXFAQ\Organization Management                      True True
NT AUTHORITY\SYSTEM                                 True False
NT AUTHORITY\NETWORK SERVICE                        True False
MSXFAQ\Administrator                                True False
MSXFAQ\Domänen-Admins                               True False
MSXFAQ\Organisations-Admins                         True False
MSXFAQ\Exchange Domain Servers                      True False
MSXFAQ\Exchange Services                            True False
S-1-5-21-11949449-30417519-71842111-5491            True False
MSXFAQ\Exchange Servers                             True False
MSXFAQ\Exchange Organization Administrators         True False
MSXFAQ\Exchange View-Only Administrators            True False
MSXFAQ\Exchange Public Folder Administrators        True False
S-1-5-21-11949449-30417519-71842111-5870            True False
MSXFAQ\Exchange Trusted Subsystem                   True False
MSXFAQ\Organization Management                      True False
MSXFAQ\Public Folder Management                     True False
MSXFAQ\Delegated Setup                              True False
S-1-5-21-11949449-30417519-71842111-7953            True False
MSXFAQ\Managed Availability Servers                 True False

Hier zeigen sich schon mal ein paar Objekte, die anscheinend nicht mehr aufgelöst werden können. Wenn Sie nicht gerade eine Umgebung mit vielen Forests haben, in denen einige Trusts nicht funktionieren, sind solche "S-"-Einträge ein hinweis auf gelöschte Objekte. Der vorderer Teil (hier "S-1-5-21-11949449-30417519-71842111") ist die Domain-SID, mit der Sie prüfen können, ob das Konto in ihrer Domain gewesen ist. Die SID der Domain zu ihrem Benutzer erhalten Sie mit:

[PS] C:\>[System.Security.Principal.WindowsIdentity]::GetCurrent().user.AccountDomainSid.Value
S-1-5-21-11949449-30417519-71842111

Wenn der vordere Teil mit den Einträgen passt, dann gibt es das Objekt nicht mehr und kann in den ACLs eigentlich auch entfernt werden.

Bitte vermeiden sie zukünftig einfach, Berechtigungen an Benutzer zu geben, die irgendwann ausscheiden. Besser sind Berechtigungsgruppen, bei denen dann natürlich auch dokumentiert werden sollte, wo sie berechtigt wurden.

Sie können die Postfachrechte übrigens im ADSIEDIT zwar als SDDL-String im Feld "msExchMailboxSecurity" anzeigen aber weder mit AD User&Computers noch ADSIEDIT bearbeiten.

Per PowerShell können Sie mit "Remove-MailboxPermission" die direkt zugewiesenen Berechtigungen entfernen aber keine vererbten Rechte. In meinem Beispiel sind aber alle Rechte vererbt und es stellt sie sich Frage, woher. Es ist ja keine klassische AD-Vererbung. Wer sich nun aber an die alten Exchange 2000/2003-Tricks erinnert, um einem Dienstkonto z.B. Vollzugriff auf alle Postfächer einzuräumen, der kennt noch die Rechte auf der "Exchange Organisation". Leider gibt es seit Exchange 2007 keine MMC mehr dafür aber ADSIEDIT hilft auch dabei. Öffnen Sie die Configuration-Partition

CN=Configuration,DC=example,DC=COM
- CN=Services
   CN= Microsoft Exchange

In den Berechtigungen sollten Sie dann die gleichen "defekten" ACLs finden, d.h. AD-Objekte, die nicht mehr vorhanden sind.

Manchmal sind auch die unbekannten Objekte selbst von weiter oben vererbt. Ich haben schon Berechtigungen von CN=Configuration,DC=<domain>,DC=<de> gefunden, die ich nur als OrganizationAdmin editieren konnte. Aber in der Gegenrichtung habe ich schon Rechte von mittlerweile gelöschten Objekten gefunden, die auf der Mailboxdatenbank, auf der Administrativen Gruppe oder der Organisation zugewiesen waren.

Nachdem all diese Reste entfernt waren, war die Ausgabe der Berechtigungen zwar sauber, aber der Fehler immer noch da.

Suche nach der GUID

Aus verschiedenen Blogs scheint es sich bei dem Problem, doch um Berechtigungen auf der Domäne zu handeln, die nicht in den Exchange Postfachberechtigungen erscheinen aber Exchange dennoch stören. Eine Suche liefert Hinweise:

Import-Module ActiveDirectory

Get-ACL "AD:\dc=msxfaq,dc=de" `
| Select Access -ExpandProperty Access `
| Where-Object {$_.ObjectType -eq "e2d6986b-2c7f-4cda-9851-d5b5f3fb6706"} `
| ft IdentityReference,IsInherited -AutoSize

IdentityReference             IsInherited
-----------------             -----------
MSXFAQ\RTCHSDomainServices       False
MSXFAQ\RTCDomainUserAdmins       False

Get-ACL "AD:\dc=msxfaq,dc=de" `
| Select Access -ExpandProperty Access `
| Where-Object {$_.ObjectType -eq "d819615a-3b9b-4738-b47e-f1bd8ee3aea4"} `
| ft IdentityReference,IsInherited -AutoSize

IdentityReference               IsInherited
-----------------               -----------
MSXFAQ\RTCHSDomainServices         False
MSXFAQ\RTCDomainServerAdmins       False
MSXFAQ\RTCDomainUserAdmins         False

In allen Fällen handelt es sich um Skype for Business/Lync-Gruppen. In meinem Forest gab es aber zu der Zeit gar keinen Skype fo Business-Server mehr. Anscheinend habe ich beim Deprovisoining den letzten Schritt vergessen.

Disable-CsAdDomain
Disable-CsAdForest

Diese sollten eigentlich auch die Berechtigungen und Gruppen zurückbauen. In meinem Fall sind auf der Domäne die drei ACL-Einträge verblieben:

Ich habe diese dann manuell gelöscht. Eine Kontrolle mit den PowerShell-Befehlen ergab dann keine Treffer mehr.

Anonym und AD

Manchmal kommt die Fehlermeldung aber auch, weil andere Berechtigungen verblieben sind. Hier betraf es "authentifizierte Benutzer" auf der Root der Domain, die wir wie folgt auslesen konnten:

Get-ACL "AD:\dc=msxfaq,dc=de" `
| Select-Object Access -ExpandProperty Access `
| Where-Object {$_.ObjectType -eq "e2d6986b-2c7f-4cda-9851-d5b5f3fb6706"}

Bei mir waren drei Einträge zu sehen, die ich auch in DSA.MSC gefunden habe:

Sie können hier auch schnell entfernt werden.

Achtung: allein das leere Feld bei "Access" ist kein ausreichender Indikator. Es gibt durchaus weitere Einträge mit leeren Einträgen. Leider sehen wir in der MMC aber nicht mehr Details.

Zusammenfassung

Obsolete Berechtigungen nach der Deinstallation von Programmen oder Löschung von Benutzerkonten oder Gruppen können auch Jahre später noch anderen Programme bei der Installation oder Funktion stören. Hier waren es Reste einer lokalen Skype for Business Installation, die Monate nach der Deinstallation die Verwaltung von Postfachrechen bei SharedMailboxen blockiert hat. Diesmal haben schon andere Administratoren das Problem gehabt und nachdem ich deren Beschreibung gelesen und kein Risiko gesehen habe, konnte ich mein Problem lösen.

Es bleibt dennoch ein komischer Beigeschmack, dass Exchange 2016 in dem Fall sich an eigentlich ganz normal vergebenen Berechtigungen auf die Domäne gestört hat, die in den Postfach Berechtigungen gar nicht sichtbar waren. Vermutlich liest und ändert Exchange aber auch die AD-Rechte (Stichwort SendAs) und hier könnten die vererbten Berechtigungen gestört haben.

Weitere Links