Exchange 2000/2003 Disabled Account und msExchMasterAccountSid

Deaktivierte User in E2K erhalten keine Mails
Es sei denn Sie installieren einen Hotfix:
915358 A hotfix is available to change the behavior of the Full Mailbox Access permission in Exchange 2000 Server
916783 A hotfix is available to change the way that Exchange Server 2003 SP2 handles a disabled Active Directory user account that is associated with an Exchange Server 2003 mailbox
Alt: 903158 A hotfix is available to modify the way that Exchange Server 2003 handles a disabled Active Directory user account that is associated with an Exchange Server 2003 mailbox

Beachten Sie dazu auch die Seiten Ressourceforest und LinkedMailbox.

Achtung
In Exchange 2010 gibt es eine besondere "LinkedMailbox", die diese Funktion nun abdeckt. Auch hier ist per Default das Konto zwar deaktiviert, aber nicht mehr zwingend.

Wenn Sie das Konto eines Anwenders mit einem Exchange 2000/2003 Postfach deaktivieren, dann kann sich zwar dieser Anwender nicht mehr anmelden und seine Nachrichten nicht mehr lesen, aber auch eingehende Mails werden mit folgenden Fehler nicht mehr zugestellt:

Diese Nachricht hat das E-Mail-System des Empfängers erreicht, die 
Übermittlung der Nachricht wurde jedoch verweigert. Versuchen Sie 
nochmals, diese Nachricht zu senden. Wenn die Übermittlung erneut 
fehlschlägt, wenden Sie sich an den Systemadministrator. 
<nawsv001.netatwork.de #5.2.1>

Bei einem englischen Server lautet die Meldung entsprechend:

The Message has reached the recipient mail system. Delivery was 
denied. try again later. Please call System administrator if
error still occurs
<servername.domain.tld #5.2.1>

Zeitgleich gibt es im Eventlog den Eintrag:

Weiterhin erhalten Sie nachts beim Durchlaufen des IS durch die Ordner die gleiche Meldung im Eventlog.

Wann wird ein Benutzer deaktiviert ?

Faktisch bedeutet dies, dass ich mehrere Probleme damit habe, denn Benutzer "deaktivieren" kann für mehrere Zwecke nützlich sein:

Das Ergebnis ist aber in jedem Fall das gleiche, dass Nachrichten an dieses Konto nicht zugestellt werden können.

Warum verhält sich Exchange so ?

Der Exchange 2000/2003 Store kennt zwei Typen von Anwendern:

Der Exchange 2000 Store nutzt die SID des Objekts für die Zugriffskontrolle. Bei einem aktivierten Benutzer liest der Store die Object-SID ein. Bei einem deaktivieren Benutzer geht der Store von einem externen Konto aus und liest das Feld "MSExchMasterAccountSID". Hier steht bei deaktivieren Benutzern die SID des Kontos, welches normalerweise genutzt wird (das NT4-Konto einer vertrauten Domäne). Diese Feld ist aber bei einem aktiven Benutzer nicht gesetzt und wenn dieser deaktiviert wird, wird es auch nicht wieder gefüllt.

Wird umgekehrt ein deaktiviert Benutzer MIT gesetztem Feld MSExchMasterAccountSID durch die MMC aktiviert (statt per ADClean mit einem migrierten Postfach zusammengeführt), dann löscht die MMC das Feld MSExchMasterAccountSID und setzt es beim Deaktivieren aber auch nicht mehr. Insofern ist auch dieser "Administratorfehler" ein Desaster für gemischte Umgebungen. Hinzu kommen bei all diesen Probleme auch noch, dass die Zugriffsrechte (ACLs) in dem Feld MSExchMailboxACL ebenso korrekt gesetzt sein müssen.

Weitere Effekte

Der Store nutzt aber nicht nur die Benutzer sondern Benutzer sind auch Mitglied von Verteilern. Gerade in gemischten Umgebungen mit der Migration von Exchange 5.5 nach Exchange 2000 ist es bekannt, dass der Store die MAPI-Rechte in NTFS-ACLs umrechnet und er dazu sowohl die Gruppen als auch die Mitglieder auflösen können muss. Ansonsten setzt der Store die Rechte nur für die Besitzer um. Ohne Exchange 2000 SP2 wurden diese fehlenden Rechte nach 24h leider nach Exchange 5.5 zurückrepliziert was ein mittleres Chaos auslöst.

Aber ich kann einen deaktivieren Benutzer ohne MSExchMasterAccountSID auch NICHT mehr in öffentlichen Ordnern nutzen, um Rechte zu vergeben. Ich kann ihn aus dem Adressbuch (wo er noch erscheint) natürlich hinzufügen, aber nach dem OK wird der Eintrag wieder gelöscht. Andererseits kann ich den deaktivierten Usern sehr wohl Rechte auf das Dateisystem und Freigaben vergeben, also ist die SID auch bei AD weiterhin vorhanden und gültig. Wenn ich aber den User erst in Exchange 5.5. anlege und repliziere und die Rechte vergebe und dann im AD "deaktiviere", dann bleibt das Recht auf dem PF bestehen allerdings mit dem Eintrag "NTUSER: LDAP-Name im AD".

Ein weiterer Seiteneffekt ist z.B.: der absichtliche Einsatz deaktivierte Konten, z.B. Ressourcenpostfächer, die bei Exchange 2000 zwingend Windows 2000 Konten sind. Zwar kann jemand anderes das Recht auf die Mailbox haben aber solange das Konto "aktiviert" ist, könnte sich jemand bei Kenntnis des Kennworts auch anmelden. Daher bietet es sich auch an, diese zu deaktivieren. Wäre schade, wenn man Sitzungsräume, Beamer und andere Ressourcen nicht deaktivieren könnte.

Status von Microsoft

Dieser Fehler ist bekannt und wird intern diskutiert. Das Verhalten ist in Exchange 2000 Service Pack 3 nicht geändert worden und angeblich würde eine Änderung ein umfangreicher Eingriff in das Design bedeuten.

Aber seit März 2006 gibt es nun auch in Form eines HotFix eine Lösung

Trotzdem kann auch ein anderer Weg für Sie eine Lösung darstellen. Vor allem wenn Sie noch nicht Exchange 2003 einsetzen

Workaround

Fakt ist, dass ein Anwender im Forrest, welcher deaktiviert wurde nicht mehr per Mail erreichbar ist und auch sonst Störung möglich sind. Wie kann ich das nun lösen ?

Wenn Sie einen Benutzer den Zugriff verhindern möchten, aber das Postfach trotzdem erreichbar halten wollen, dann haben sie folgende Möglichkeiten.

Die beste Lösung ?

Am besten wäre es natürlich, denn der STORE, der für die Probleme verantwortlich sein dürfte, seine Logik etwas erweitert. Bisher nutzt der Store anscheinend eine feste Zuordnung in der Art:

IF USER = enabled
 THEN SID = USER.OBJECTSID
IF USER = disabled 
 THEN SID = USER.MSExchMasterAccountSID
IF SID= nothing 
 THEN ERROR

Es würde ja reichen, diesen Teil zu erweitern um

IF USER = disabled and USER.MSExchMasterAccountSID= nothing 
 THEN SID = USER.OBJECTSID

Und genau hierfür gibt es mittlerweile sogar eine Lösung.

Zusammenfassung

In aller Kürze zusammengefasst bedeutet dies:

Weitere Links

Keywords:Disabled msExchMasterAccountSID DisabledAccount