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.

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:

  • Mitarbeiter scheiden aus
    aber das Konto soll noch nicht gelöscht werden, weil noch nicht klar ist, wer die Aufgaben übernimmt
  • Mitarbeiter gehen längere Zeit in Urlaub, werden aber zurückkommen
    z.B. Schwangerschaft, Soziales Jahr, Auslandseinsatz, unbezahlter Urlaub, Krankheit.
  • Administrative Limits
    Um z.B. für Datensicherungen, Migrationen etc. keine Änderung an Daten zuzulassen, kann der Benutzer deaktiviert werden.

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:

  • Typ 1: Aktivierte Benutzer im Forrest
    Dies sind "normale" Anwender von Exchange, bei denen das Anmeldekonto auch zugleich der Speicherplatz für die Exchange Information ist. Die Windows Berechtigungen werden anhand der Attribute objectSID bzw. sidHistory ermittelt.
  • Typ 2: Deaktivierte Benutzer
    Dies sind besondere Benutzer für NT4-Domänen, d.h. Platzhalter für nicht im Forrest existierende Benutzer, die trotzdem Exchange 2000 nutzen sollen siehe Exchange 2000 mit NT4. Der ADC legt in der Regel solche Anwender in gemischten Umgebungen an.
    Die Berechtigungen werden anhand des Attributs msExchMasterAccountSID ermittelt

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.

  • Q319047 XADM: You Receive a Non-Delivery Report When You Send a Message to a Disabled Account

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

  • 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

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.

  • Sie können das Kennwort des Users ändern
    Leider muss der Benutzer dieses dann später wieder erfragen oder sie müssen es sicher übermitteln. Das hilft aber nicht, wenn Sie eine Autorisierung per Smartcard nutzen.
  • Sie können die Anmeldezeiten des Benutzer beschränken
    Damit kann er sich nicht anmelden, obwohl er aktiviert ist. Zumindest an Programme, die diese Information auswerten. Ich weiß nicht, ob IAS (Radius) und IIS (Web) diese Information nutzen, oder ob diese nur für interaktive Logins gilt.
  • Sie können das Konto sperren
    Dies passiert z.B. auch wenn ein Anwender mehrfach das falsche Kennwort eingibt. Solche Konten sind nicht mehr nutzbar, aber empfangen weiterhin Nachrichten. Leider sorgen die Richtlinien meist auch dafür, dass die Sperre nach einer bestimmten Zeit (30 Min) wieder deaktiviert wird, so dass dies keine dauerhafte Lösung ist.
  • Konto abgelaufen
    Sie können ein Konto auch "ablaufen" lassen, d.h. den Zeitpunkt der spätesten Anmeldung in die Vergangenheit legen. Dann ist keine Anmeldung mehr möglich, aber Nachrichten werden weiterhin empfangen.
  • Sie können das Konto deaktivieren
    Dann müssen Sie einen anderen Account als "assoziiertes Externes Konto" zuweisen (Siehe "Q278888 XADM: Associate an Exchange 2000 Mailbox with a Windows NT User"). Hier hilft uns die Besonderheit, dass der Account "SELF" ebenso genutzt werden kann. Wenn Sie daher schon deaktiviert Benutzer haben, dann sollten Sie prüfen, ob bei diesen Benutzer das Feld "MSExchMasterAccountSID" gesetzt ist. Wenn nicht, dann sollten Sie den SELF-Account eintragen. Dies kann auch per Skript geschehen.
    Nur wenn Sie per MMC den Benutzer wieder aktivieren, dann wird das Feld leider wieder gelöscht so dass beim nächsten deaktivieren wieder alles beim alten ist.

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.

  • ADMODIFY
    Das Programm ADModify erlaubt es bei den ausgewählten Anwendern den Benutzer "SELF" hinzuzufügen.
  • AddSelf
    Diese kleineVBScript kann diese Tätigkeit automatisiert ausführen.

Zusammenfassung

In aller Kürze zusammengefasst bedeutet dies:

Exchange 2000 stellt keine Nachricht an Konten zu, wenn das Konto deaktiviert ist und es kein kein anderes "zugeordnetes externes Konto gibt".
Prüfen Sie daher genau diese Auswirkung, wenn sie Konten temporär "deaktivieren", um Anwender einen Zugriff zu verhindern.

Ich hoffe, dass die nächste Version des Store diesen Fall besser abdeckt und die ObjectSID des Benutzers nutzt, wenn dieser Benutzer deaktiviert ist, aber keine MSExchMasterAccountSID hat.

Weitere Links