POP3/IMAP4 Anmeldung

Auf dieser Seite möchte ich meine Erfahrungen und Ergebnisse beim Einsatz von POP3/IMAP4 dokumentieren. Outlook über MAPI/HTTP oder RPC/HTTP find ich natürlich viel besser und auch ActiveSync oder OWA bieten einen sehr einfachen Zugang zu Exchange Postfächern. Aber POP3 und IMAP4 sind nicht nur Clients für Linux-Systeme sondern werden immer noch von vielen Automatisierungsaufgaben genutzt. Also muss ein Exchange Admin sich damit auch noch beschäftigen.

Hinweis: POP3 und IMAP4 werden in der Regel zum "Lesen" aber nicht zum Senden von Mails genutzt. Sie könnte per IMAP auch senden aber in der Regel wird dazu SMTP mit Authentifizierung über den Port 587 konfiguriert.

Achtung Exchange Online: BasicAuth ist abgekündigt. Siehe auch Exchange Online Authentifizierung

Dienste starten

Die POP3 und IMAP4 Funktion ist mittlerweile bei Exchange zwar noch vorhanden und für jeden Benutzer auch aktiv aber die entsprechenden Dienste werden nicht automatisch gestartet.

Die Regeln in der Windows Firewall sind allerdings schon vorhanden, so dass Sie die Dienste einfach auf "automatisch" stellen und starten können.

Allerdings gibt es ja immer noch die Netzwerk-Firewall zwischen Client, Internet und Exchange. Hier müssen Sie natürlich auch noch ein paar Türchen öffn995 POP3S

Kennwort Security

Die klassischen POP3/IMAP4-Dienste über die Port 110 und 143 sind nicht per TLS verschlüsselt, d.h. jeder "Schnüffler" auf der Leitung könnte die übertragenen Daten und Mails mitlesen. Das ist aber auch zwischen Mailservern per SMTP möglich, wenn die Server hier kein STARTTLS unterstützen. Dennoch sollten Sie zweimal überlegen, ob sie POP3/IMAP4 so erreichbar machen oder nicht generell auf TLS setzen.

Aber wenn Sie POP3/IMAP4 unverschlüsselt zur Verfügung stellen, dann ist Exchange per Default so konfiguriert dass zumindest das Kennwort nicht unverschlüsselt über die Leitung geht. Dafür sorgt u.a. die Einstellung "LoginType", die pro Server konfiguriert werden.

PS C:\> Get-PopSettings  |fl

ProtocolName                      : POP3
UnencryptedOrTLSBindings          : {[::]:110, 0.0.0.0:110}
SSLBindings                       : {[::]:995, 0.0.0.0:995}
InternalConnectionSettings        : {EX01.UCLABOR.DE:995:SSL, EX01.UCLABOR.DE:110:TLS}
ExternalConnectionSettings        : {}
X509CertificateName               : EX01
Banner                            : The Microsoft Exchange POP3 service is ready.
LoginType                         : SecureLogin
AuthenticatedConnectionTimeout    : 00:30:00
PreAuthenticatedConnectionTimeout : 00:01:00
EnableGSSAPIAndNTLMAuth           : True
Server                            : EX01

PS C:\> Get-ImapSettings | fl

ProtocolName                      : IMAP4
UnencryptedOrTLSBindings          : {[::]:143, 0.0.0.0:143}
SSLBindings                       : {[::]:993, 0.0.0.0:993}
InternalConnectionSettings        : {EX01.UCLABOR.DE:993:SSL, EX01.UCLABOR.DE:143:TLS}
ExternalConnectionSettings        : {}
X509CertificateName               : EX01
Banner                            : The Microsoft Exchange IMAP4 service is ready.
LoginType                         : SecureLogin
AuthenticatedConnectionTimeout    : 00:30:00
PreAuthenticatedConnectionTimeout : 00:01:00
EnableGSSAPIAndNTLMAuth           : True
Server                            : EX01

Hier gibt es drei Optionen:

Typ Sicherheit Bedeutung

PlainTextLogin

Unsicher ohne TLS

Eine Anmeldung mit "LOGIN username Kennwort" ist möglich

PlainTextAuthentication

Unsicher

Eine Anmeldung mit LOGIN ist nicht möglich. Stattdessen muss mit "AUTHENTICATION" z.B. ein NTLM-Hash oder Kerberos-Ticket übertragen werden. So ist das Kennwort auch bei ansonsten unverschlüsselter Übertragung besser geschützt

SecureLogin (Default)

Sicher

Nur bei dieser Einstellung ist sichergestellt, dass die Anwender entweder ein sicheres Anmeldeverfahren (Kerberos, NTLM) nutzen oder Klartext-Authentifizierung über SSL abgesichert ist.

"PlainTextLogin" ist definitiv nicht sicher und die Daten können allzu leicht abgefischt werden. Das kann über einen Netzwerk-Sniffer erfolgen. Aber ohne TLS kann ein Angreifer auch per ARP-Spoofing, DNS-Injection etc. ihren einfach aus seinen Service oder POP/IMAP-Proxy umleiten und ganz einfach mitlesen.

Ich weiß aber auch, dass es immer noch sehr viele Programme und Tools gibt, die am liebsten unverschlüsselt und mit Basic Authentication arbeiten. Für eine Ersteinrichtung mit Tracing ist das auch durchaus tolerierbar aber im Regelbetrieb sollten Sie eine Verschlüsselung per TLS fordern. Es ist aber nicht einfach gerade bei Migrationen oder "gewachsenen Systemen" so einen Wechsel einzuführen.

Achtung: Eine Anmeldung per "BaiscAuth" wird auf dem Exchange Server als "Interactive Login" durch LSASS ausgeführt und auch im NETLOGON.LOG bei aktiviertem Debugging (nltest /DBFLAG:2080FFFF) entsprechend angezeigt.

05/28 22:12:53 [LOGON] [18824] SamLogon: Interactive logon of (null)\POPUSER from EX16 Returns 0x0
05/28 22:12:53 [LOGON] [33752] SamLogon: Interactive logon of (null)\IMAPUSER from EX16 Returns 0x0
05/28 22:12:53 [LOGON] [18824] SamLogon: Interactive logon of (null)\IMAPDELEGATE from EX16 Entered
05/28 22:12:53 [LOGON] [18824] SamLogon: Interactive logon of (null)\POPSHARED from EX16 Returns 0x0
05/28 22:12:53 [LOGON] [20128] SamLogon: Interactive logon of (null)\ from EX16 Entered

Das ist natürlich für den Server deutlich aufwändiger, als ein Kerberos-Ticket zu bewerten.

Benutzerkonfiguration

Damit IMAP4 oder POP3 nach all den Vorabreiten funktioniert, müssen Sie beim Benutzer gar nichts mehr machen. Jeder Benutzer kann "per Default" POP3 und IMAP4 nutzen, wenn der Server es anbietet und die Firewall es zulässt. Solange die Dienste nicht laufen, ist das kein Risiko. Wenn Sie aber auf einem Server IMAP4 oder insbesondere POP3 aktivieren und Anwender dies herausfinden, dann besteht das Risiko, dass Anwender einen anderen Client nutzen und per POP/IMAP auf die Mails zugreifen. Beim POP3 besteht die Gefahr, dass der Anwender die Mails im Posteingang sogar "herunterlädt". Auf dem Exchange Server sind diese Elemente dann gelöscht. Der Zugriffe per POP/IMAP wird sogar per Autodiscover veröffentlicht.

Sobald Sie an den Einsatz von POP3/IMAP4 denken, rate ich ihnen dringend, beim Provisioning-Prozess diese Funktion bei den Benutzern abzuschalten.

Set-CasMailbox `
   -Identity <MailboxId> `
   -PopEnabled $false `
   -ImapEnabled $false

Technische Funktion

Die Postfächer liegen wie bisher in einer Exchange Datenbank und die POP3/IMAP4-Dienste sprechen nach draußen mit den Client über POP3 oder IMAP4. Zum Backend haben die Dienste unter Exchange 2010 und früher direkt mit dem Postfachserver per RPC gesprochen. Es gab keine Umleitung oder Proxy-Funktion wie bei Outlook mit "ExternalURL/InternalURL" und Autodiscover. Bei geografisch verteilten Firmen war es daher wünschenswert einen POP/IMAP-Server am gleichen Standort der Mailbox anzusprechen, damit MAPI/RPC nicht über das WAN übertragen werden musste

Bei Exchange 2013 und höher hat Microsoft dieses Thema anders gelöst. Es gibt hier einen "Frontend"-Service und einen "Backend"-Service. Der Client verbindet sich immer und ausschließlich zu einem Frontend-Service und dieser authentifiziert auch den Client. Mit dem Wissen um den Benutzer ermittelt der POP/IMAP Frontend Server nun den Server mit der aktiven Datenbank und sendet die Pakete dann als Proxy zum passenden Backend-Server. Dies funktioniert auch über die Grenzen einer Site hinweg.

Anmeldename

Der Zugang zum Exchange Postfach kann eine Applikation über die Funktion "Autodiscover" sehr einfach in Erfahrung bringen. Aber auch eine manuelle Konfiguration von POP3 oder IMAP4 ist schnell gemacht. Die meisten Programme erlauben aber neben dem Server:Port und SSL-Einstellungen nur die Eingabe eines Benutzernamens samt Kennwort. Diese Daten werden dann zum Exchange Server übermittelt, der sich nun überlegen muss, wie er das richtige Postfach findet. Es kann ja durchaus sein, dass das Postfach in einem Forest liegt während das Anmeldekonto in einem anderen Forest oder zumindest einer anderen Domäne als der Exchange Server liegt. Auch könnte es gewünscht sein, dass ein Benutzer auf ein andere Postfach als Stellvertreter zugreift. Daher muss der POP3/IMAP4-Service mit bestimmten Annahmen arbeiten, wie er aus dem Benutzernamen die Daten. Ich habe einfach mal eine Testserie gemacht.

Für die Tests aber ich eigens einen Benutzer angelegt, bei dem SAMAccountname und Alias unterschiedlich waren und der UPN nicht als Mailadresse vorlag. So konnte ich gut sehen, wann Exchange einen Treffer hatte und welche Postfach zugeordnet wurde.

Format Status Bedeutung

Username

Exchange sucht in der eigenen Domäne nach einem Benutzer mit diesem "SamAccountName". Der Benutzer darf also nicht in einer anderen Domäne sein. Im Security-Eventlog findet sich nur ein Eintrag mit dem Benutzernamen und einer leeren Domain.

Es gibt Blogs die in dem Fall fordern, dass SamAccountName und Alias übereinstimmen. Bei mir funktioniert dies aber auch nur mit dem SamAccountName. Ich vermute, dass Exchange dann einfach das Postfach des angemeldeten Benutzers öffnet.

Diese Form der Anmeldung ist aber nicht eindeutig, denn der SamAccountName kann in einem Forest mit mehreren Domänen durchaus mehrfach verwendet werden.

Domain/Username
Domain\Username

Sobald genau ein "/" oder "\" im Benutzername enthalten ist, wertet Exchange den ersten Teilstring als Domäne und den zweiten als SamAccountName. Nach erfolgter Anmeldung greift der Anwender auf das mit dem Benutzer verknüpften Postfach zu. Der MailnickName (Alias) musste bei meinen Tests mit Exchange 2016 nicht übereinstimmen.

Im Security Eventlog sieht man gut die Auftrennung.

Diese Methode funktioniert sogar mit einem Ressource Forest. Anscheinend nutzt Exchange die SID des Anmeldekonto, um im eigenen Forest nach einer LinkedMailbox zu suchen.

Domain/Username/Alias
Domain\Username\Alias

Wenn zwei "/" zu finden sind, dann wertet Exchange die als explizite Angabe eines Postfachs an dritter Stelle. Damit ist aber auch klar, dass eine Anmeldung nur mit Benutzername und Postfach aber ohne Domain nicht möglich ist. Diese Schreibweise hilft auch, wenn der SamAccountName nicht mit dem MailNickname übereinstimmt.

UPN

Sobald ein @ im Benutzername ist, wird der Name als UPN gewertet. Das ist sehr hilfreich, da über den eindeutigen UPN auch sehr einfach das Anmeldekonto in einem anderen Forest gefunden werden kann. Dies ist insbesondere bei Ressource Forest-Umgebungen hilfreich.

Achtung
Bei der Nutzung des UPN muss sichergestellt sein, dass der UPN-Suffix in allen Forest nur einem Forest zugeordnet ist und nicht zwei Konten den gleichen UPN haben. Das gilt auch für die nächsten Fälle.

UPN/Alias
UPN\Alias

Durch das Anhängen einer Mailbox hinter einem "/" kann der Benutzer gezielt auf ein andere Postfach zugreifen. Diese Schreibweise hilft auch, wenn der UPN nicht mit dem MailNickname übereinstimmt.

Domain\UPN

Dies geht, wenn der per UPN angegebene Benutzer in der angegebenen Domain ist.

Domain\UPN\Alias
Domain\UPN\UPN

Diese Kombinationen haben bei mir nicht funktioniert.

Und dann gibt es noch einige Dinge zu beachten:

  • Eine Anmeldung mit dem "Alias" eines Postfachs und dem passenden Kennwort funktioniert nicht
    Exchange sucht also nicht nach dem MailNickName um ein passendes Objekt zu finden
  • Eine Anmeldung mit einer "SMTP-Adresse" ist nicht möglich
    Auch wenn das in vielen Foren immer wieder kolportiert wird. Mir ist es nie gelungen, es sei denn der UPN und die SMTP-Adresse sind gleich. Aber dann ist es ja keine Anmeldung mit der SMTP-Adresse
  • Postfächer müssen natürlich immer im Exchange Forest sein.
    Ein POP3/IMAP4 Frondend Server kann keine andere Exchange Organisation bedienen.
  • Mit der Nutzung des UPN können Sie Probleme mit mehreren Domains umgehen, in denen es den SAM-Accountname mehrfach geben kann
    Allerdings funktioniert das nur, wenn der UPN wirklich eindeutig ist und die UPN-Domain nur in einem Forest existiert. Anders als bei der Anmeldung mit SamAccountName ignoriert Exchange den Deaktiviert-Status eines Konto
  • Achten Sie in ihrer Exchange Umgebung immer darauf, dass der Alias (MailNickname) eindeutig ist
    Das sollte immer so ein aber nicht alle Provisioning-Tools achten darauf.
  • Kein anonymer Zugriff oder Zugriff als Gast auf Postfächer per POP/IMAP
    Beide Protokolle erfordern eine Anmeldung mit einem gültigen Windows Konto. Die Angabe von "anonymous/anonymous" oder "Guest/guest" funktioniert nicht.
  • Kein Zugriff auf Administrator-Postfächer per POP/IMAP
    Das ist wohl ein Sicherheitsthema, dass Administratoren keine unsicheren Protokolle nutzen.
  • Thunderbird:
    Wenn Sie bei Thunderbird eine Anmeldung per "Password normal" machen und als Anmeldename "Domain\User" verwenden, dann macht Thunderbird daraus ein "Domain\User@Servername". Damit findet z.B. Exchange nicht mehr den UPN.

Ohne Zugriff auf den Sourcecode kann ich natürlich nicht abschließend sicherstellen, dass Exchange genau so in jeder Version funktioniert

Achten Sie bei Trusts zu anderen Forests darauf, dass z.B. die Uhrzeit stimmt. Ein 0xC0000133 bedeutet "RB5KRB_AP_ERR_SKEW.

Ich habe mal versucht die Logik als Tabelle darzustellen:

Anzahl "\" Anzahl "@" Ergebnis

2

0

Trenne nach Domain\User\Alias

2

1 oder 2

nicht gültig

1

1

Trenne nach upn\alias

1

0

Trenne domain\username und suche nach Alias=Username

1

2 oder mehr

nicht gültig

0

0

domain = lokale domain und suche nach der Mailbox für den angemeldeten Benutzer. Der Alias muss nicht übereinstimmen.

0

1

Username = UPN und suche Mailbox über die SMTP=UPN

Sonderfall Ressource Forest

Die Suche nach dem Anmeldebenutzer kann auch über "Trusts" erfolgen, so dass auch Ressource Forest-Szenarien mit Linked Mailbox abgedeckt sind. Dabei besteht eine deaktiviertes Konto mit einem Postfach im Exchange Forest während sich der Anwender selbst an einem anderen Forest authentifiziert. Hier muss Exchange also etwas mehr Logik anwenden, denn bei der Linked Mailbox seht nur der Verweis auf das Anmeldekonto in Form einer SID.

Format Format Bedeutung

Accountdomain\Username

OK

Exchange kann nicht nur den Anwender wie erwartet anmelden, sondern scheint auch im eigenen Forest nach einem Postfach zu suchen, welches dieses Konto als "LinkedAccount" eingetragen hat

Accountdomain\Username\Alias

OK

Auch die explizite Angabe eines anderen Postfachs ist möglich.

Account@accountdomain

OK

Auch eine Anmeldung nur mit dem UPN ist möglich.

Account@accountdomain\Alias

OK

Entsprechend geht auch der Zugriff als Stellvertreter.

Mailadresse
Mailadresse\Alias

Fail

Eine Anmeldung mit der Mailadresse ist hingegen nicht möglich. Die Exchange IMAP-Dienste suchen also nicht über die Proxy-Adressen nach einem möglichen Konto. Ein "Anmelden mit Mailadresse" geht also nur, wenn der UPN zufällt gleich ist.

Username
Username\Linked

OK

Diese Variante funktioniert interessanterweise. selbst über Forest-Trusts hinweg. Anscheinend sucht Exchange auch in "vertrauten Forests" nach Anmeldekonten. Es funktioniert sogar, wenn ich dem deaktivierten Benutzer der der LinkedMailbox den gleichen SamAccountName gebe.
Sobald das Konto der Linked Mailbox aber aktiviert ist, werden dessen Zugangsdaten ausgewertet.

LinkedUPN

Fail

Sollte die LinkedMailbox den gleichen UPN haben, wie das Anmeldekonto, dann schlägt die Anmeldung fehlt. Dabei ist es egal, ob das Konto deaktiviert ist und selbst wenn der UPN-Suffix der Account Domäne nicht im Ressource Forest addiert ist. Es reicht der Eintrag am Ressource Benutzer (mit ADSIEDIT).

Diese kleine Testreihe lässt einige Rückschlüsse auf die Logik zu, wie Exchange anhand des Benutzernamens versucht das passende Konto und die Mailbox zu finden. Ich lerne daraus

  • Exchange sucht sowohl im eigenen Forest als auch in allen per Trust verbundenen Forests nach "passenden" Benutzern"
  • Der eigene Ressource Forest wird zuerst durchsucht.
  • Bei einer Anmeldung des UPN geht Exchange davon aus, dass der Wert über alle Forests eindeutig ist
    Daher schließt er deaktivierte Konten auch nicht aus der Suche aus
  • Bei der Anmeldung per "SamAccountname" ignoriert er deaktivierte Konten.

Die sicherste Funktion einer erfolgreichen Anmeldung haben Sie daher bei der Nutzung eines zumindest in ihrer Umgebung aus mehreren Forests eindeutigen UPN. Die Nutzung des SamAccountName ist ebenso möglich, wenn Sie die Eindeutigkeit sicherstellen. Als Trenner können Sie "\" oder "/" nutzen.

Meine Tests habe ich mit Exchange 2016 CU14 durchgeführt. In Ermangelung eines Exchange 2010 in der Testumgebung habe ich Besonderheiten beim Proxying nicht beleuchtet.

Password

Der Benutzername ist aber nur ein Teil der Anmeldung. Auch das Kennwort kann Probleme machen. Früher konnten Kennworte unter Windows z.B. maximal 14 Stellen lang sein. Mittlerweile ist das ein 256bit Unicode-Feld, so dass 127 Zeichen maximal eingegeben werden können. Microsoft Konten (LiveID/Password) nutzen aber wohl nur die ersten 16 Stellen.

Eine zweiter Aspekt sind die möglich Zeichen. Hier gibt es bei IMAP schon ein paar Sonderzeichen, die bei der Angabe eines Kennworts beim "LOGIN" besonders zu beachten sind. Hier die Definition aus der RFC2060:

password        ::= astring
astring         ::= atom / string
atom            ::= 1*ATOM_CHAR
ATOM_CHAR       ::= <any CHAR except atom_specials>
atom_specials   ::= "(" / ")" / "{" / SPACE / CTL / list_wildcards / quoted_specials

string          ::= quoted / literal
literal         ::= "{" number "}" CRLF *CHAR8
quoted          ::= <"> *QUOTED_CHAR <">
QUOTED_CHAR     ::= <any TEXT_CHAR except quoted_specials> / "\" quoted_specials
quoted_specials ::= <"> / "\"

Quelle: RFC2060 https://tools.ietf.org/html/rfc2060 Abschnitt 9. Formal Syntax

Das Password ist ein "astring", d.h. besteht aus einem ATOM oder String. Ein String ist wiederum ein "Quoted" oder "Literal" usw. Interessant wird es am Ende, dass "quoted_specials" quasi immer verboten sind. In der RFC2060 gibt es noch jede Menge andere Abschnitte über ungültige oder zumindest kritisch Zeichen wie "#","/","\","~" und "+", da diese in Konflikt mit anderen Nutzungen stehen könnten.

Von mir erfolgreich getestetes Kennwort

password1+/&%()=?[]\

Probleme gab es mit ", {, }

Wir sollten aber mal davon ausgehen, dass ein IMAP4-Client um diese Besonderheiten weiß und das Kennwort entsprechend umschreibt. Für schnelle Tests per TELNET sollten Sie sich vielleicht ein Testkonto ohne Sonderzeichen zulegen.

Modern Authentication

Office 365 nutzt schon länger die "Modern Authentication". Dabei wird der Service nicht mehr direkt per "Benutzername/Kennwort" angesprochen, sondern der Client wird vom Service zu einem Ticket-Service umgeleitet. Dort muss sich der Client und ggfls. sogar die Applikation mit einer ClientID ausweisen und erst wenn der Ticketserver dann alle Voraussetzungen als erfüllt ansieht, stellt er ein Ticket aus. Über diesen Weg kann der Server die Verifizierung von Anmeldedaten als auch Conditional Access und Multi Faktor Authentifizierung (MFA) delegieren und der Ticketserver kann sehr schnell DoS-Attacken etc. erkennen.

Ende September 2019 hat Microsoft für die Dienste in Office 365 abgekündigt, dass hier keine "Basic-Authentication" mehr möglich sein wird. Im April 2020 wurde aber in Zeichen von Corona die Deadline noch mal verschoben:

... we have decided to postpone disabling Basic Authentication in Exchange Online for those tenants still actively using it until the second half of 2021 ...
.. We will continue to disable Basic Authentication for newly created tenants by default and begin to disable Basic Authentication in tenants that have no recorded usage starting October 2020 ..
https://techcommunity.microsoft.com/t5/exchange-team-blog/basic-authentication-and-exchange-online-april-2020-update/ba-p/1275508

Last year we announced we are turning off Basic Authentication for Exchange Web Services on October 13, 2020. Today, we are announcing we are also turning off Basic Authentication in Exchange Online for Exchange ActiveSync (EAS), POP, IMAP and Remote PowerShell at the same time – October 13, 2020.
Quelle: https://techcommunity.microsoft.com/t5/Exchange-Team-Blog/Improving-Security-Together/ba-p/805892

Damit ist klar, dass zumindest in Exchange Online die Tage der alten einfachen Anmeldung per TELNET oder Trivial-Skripte gezählt sind. Die Anmeldung für IMAP mittels OAUTH ist aber nichts ungewöhnliches mehr und GMail als auch outlook.com bieten dies schon ein. Ein einfaches "capabiliy" liefer schon die Info "AUTH=OAUTH2".

Internals und Tracing

Ich habe sehr viele Fälle und Varianten durchprobiert aber vermutlich gibt es immer noch Fälle, die ich nicht bedacht habe. Es gibt auch weitere Exchange Versionen, Servicepacks und Updates, die Einfluss auf die Anmeldung haben könnten. Auch bei Windows Trusts zu anderen Domänen und Forest gibt es weitere Steuerungsmöglichkeiten. Da die meisten Kommunikationen allerdings verschlüsselt ablaufen, ist es nicht immer einfach nach dem Fehler zu suchen.

Es gibt aber verschiedene Dinge, sie die sehr einfach einschalten können:

  • Exchange Protokollierung für POP3/IMAP
    Über die PowerShell können Sie eine dateibasierte Protokollierung einschalten. Sie wird aber erst nach dem Neustart der Dienste aktiv und schreibt die Daten ins Logging-Verzeichnis von Exchange. Da hier die Protokoll-Sequenzen enthalten sind, sehen Sie z.B. die Befehle und auch die verwendeten Benutzernamen.
Set-ImapSettings -ProtocolLogEnabled $true 
Set-PopSettings -ProtocolLogEnabled $true
  • Exchange POP3/IMAP4 Eventlogging
    Sie können auf dem Exchange Servereine etwas ausführlichere Protokollierung im Application Eventlog aktivieren. Manchmal hilft es auch die ADAccess-Komponente von Exchange noch zu aktivieren, wenngleich dann natürlich sehr viel protokolliert wird
Get-EventLogLevel "msexchange imap*" | Set-EventLogLevel -Level expert
Get-EventLogLevel "msexchange pop*" | Set-EventLogLevel -Level expert
Get-EventLogLevel *ldap* | Set-EventLogLevel -level expert
  • Windows Security Eventlog
    Wenn Sie auf dem Server das Auditing für An/Abmeldungen aktivieren, dann finden Sie im Security-Eventlog die erfolgreichen aber auch erfolglosen Anmeldungen. Sie helfen auf jeden Fall zu erkennen, wenn es sich um Anmeldeprobleme handelt oder Exchange die übergebenen Benutzernamen nicht richtig decodiert
  • LDAP-Tracing (Siehe LDAP Tracing)
    Etwas tiefer geht es, wenn Sie versuchen die LDAP-Anfragen von Exchange zu ermitteln. Per Wireshark oder ADInsight werden sie leider nichts sehen, da Exchange 64bit andere DLLs nutzt und die LDAP-Anfragen verschlüsselt sind.
Log Name:      Application
Source:        MSExchangePOP3
Date:          22/01/2014 11:41:29
Event ID:      2005
Task Category: (1)
Level:         Warning
Keywords:      Classic
User:          N/A
Computer:      exchangeCAS
Description:
User user1@account.forest wasn't found in Active Directory.

Sollten Sie weitere Quellen finden oder Sonderfälle dokumentiert haben, die ich hier vergessen habe, dann freue ich mich über Feedback und Korrekturhinweise.

Weitere Links