Exchange 2007-Transport-Berechtigungsmodell

 

Gilt für: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007

Letztes Änderungsdatum des Themas: 2007-08-27

In diesem Thema finden Sie ausführliche Informationen zum Transport-Berechtigungsmodell von Microsoft Exchange Server 2007. In Microsoft Exchange Server 2007 beschreibt der Transport das Übertragen von Nachrichten von einem Server auf einen anderen. Wenn Nachrichten zwischen einem Postfachserver und dem Hub-Transport-Server übertragen werden, wird dabei das MAPI-Protokoll verwendet. Wenn Nachrichten zwischen Hub-Transport-Servern gesendet und empfangen werden, wird SMTP (Simple Mail Transfer Protocol) verwendet. Jede Kommunikationssitzung zwischen Servern kann eine optionale Authentifizierungsphase aufweisen. Verbindungsanforderungen erfordern möglicherweise Autorisierungsprüfungen.

Die Authentifizierung bezeichnet den Prozess, bei dem versucht wird, den Absender einer Nachricht zu identifizieren. Wenn keine Authentifizierung erfolgt oder diese einen Fehler aufweist, dann bleibt die Identität des Absenders anonym. Bei der Autorisierung wird bestimmt, ob einem Benutzer, einem Programm oder einem Gerät, die eine Verbindung herstellen, der Zugriff auf Daten, Funktionen oder Dienste gewährt wird. Dieser Zugriff hängt von der angeforderten Aktion ab. Beim Authentifizierungsprozess wird die Identität überprüft. Bei der Autorisierung wird die zu gewährende Zugriffsebene bestimmt.

In Exchange 2007 werden die SMTP- und MAPI-Protokolle vom Microsoft Exchange-Transportdienst bereitgestellt. In Sitzungen, die entweder das SMTP- oder MAPI-Protokoll verwenden, nutzt der Microsoft Exchange-Transportdienst das Autorisierungsmodell von Microsoft Windows, um die Berechtigungen für eine Sitzung zu verwalten. Im Zusammenhang mit dem Transport in Exchange 2007 bezieht sich die Autorisierung darauf, ob verschiedene Protokollverben oder Ereignisse angenommen werden. Bei der Autorisierung wird z. B. auf Berechtigungen geprüft, die es dem Absender ermöglichen, eine Nachricht von einer bestimmten E-Mail-Adresse oder mit einer bestimmten Größe zu senden. Exchange 2007 kann während der MAPI- und SMTP-Protokollverhandlungen die Sitzungsauthentifizierung ausführen. Nachdem eine Sitzung authentifiziert wurde, können sich die für die Sitzung verfügbaren Berechtigungsgruppen aufgrund der Authentifizierung ändern. Dies ermöglicht die unterschiedliche Verarbeitung von anonymen Nachrichten aus dem Internet und von Nachrichten, die von authentifizierten Benutzern in der Exchange-Organisation gesendet werden, da von der Authentifizierung verschiedene Berechtigungsgruppen gewährt werden.

Das Standardverhalten für den Transport der Serverfunktion Edge-Transport unterscheidet sich vom Standardverhalten für die Serverfunktion Hub-Transport. Dieser Unterschied entstammt keiner Codeabweichung. Dieser Unterschied ergibt sich durch die Abweichung beim Standardberechtigungssatz für die jeweilige Funktion. Zwischen Exchange-Servern, die Teil der gleichen Active Directory-Gesamtstruktur sind, herrscht ein Vertrauensverhältnis. Dieses Vertrauensverhältnis bedeutet, dass die während der Installation konfigurierten Standardberechtigungen die sichere Nachrichtenübermittlung innerhalb der Gesamtstruktur ermöglichen.

Jede authentifizierte Sitzung stellt ein Zugriffstoken dar, das die Sicherheits-ID für die einzelnen Gruppen aufführt, in denen der authentifizierende Sicherheitsprinzipal Mitglied ist. In Abbildung 1 wird die Beziehung zwischen den für das Zugriffstoken aufgeführten Gruppenmitgliedschaften und den Berechtigungen veranschaulicht, die diesen Gruppen für das Objekt zugeordnet werden, auf das zugegriffen wird.

Abbildung 1   Komponenten für die Transport-Autorisierung in Exchange 2007

Komponenten für die Exchange-Transport-Autorisierung

Der Unterschied zwischen authentifizierten Sitzungen und authentifizierten Nachrichten

Ein zentrales Konzept des Transportmodells in Exchange 2007 ist der Unterschied zwischen authentifizierten Transportsitzungen und authentifizierten Nachrichten. Eine Nachricht kann mit Metadaten gekennzeichnet werden, die angeben, ob diese authentifiziert oder anonym ist. Wenn ein Server einen anderen Server authentifiziert, dann kann dieser eine Nachricht senden und diese mit Metadaten kennzeichnen, die angeben, ob es sich um eine authentifizierte oder anonyme Nachricht handelt. Der empfangende Server bestimmt, ob der authentifizierte Stempel vertrauenswürdig ist. Wenn der empfangende Server dem Absender vertraut, bleibt der authentifizierte Stempel unverändert. Wenn der empfangende Server dem Absender nicht vertraut, setzt er den authentifizierten Stempel des sendenden Servers außer Kraft und kennzeichnet die Nachricht mit Metadaten, die darauf hinweisen, dass es sich um eine anonyme Nachricht handelt. In einer Exchange-Organisation tritt die interne End-to-End-Nachrichtenübermittlung zwischen Servern auf, die dem authentifizierten Nachrichtenstempel vertrauen. Ein Edge-Transport-Server, der Nachrichten aus dem Internet erhält, vertraut dem authentifizierten Stempel anonymer Server im Internet nicht. Daher stempelt der Edge-Transport-Server jede Nachricht mit Metadaten, die angeben, dass die Nachricht anonym ist, bevor diese über eine authentifizierte Verbindung an einen Hub-Transport-Server gesendet wird.

Funktionsweise der Nachrichtentransport-Authentifizierung und des Autorisierungsprozesses

In Exchange 2007 stehen die folgenden grundlegenden Mechanismen zum Authentifizieren einer SMTP-Sitzung zur Verfügung:

  • In einer MAPI-Sitzung können Sie ein Windows-Konto und -Kennwort verwenden. Alternativ können Sie auch die AUTH-Erweiterung von SMTP verwenden. Dies umfasst die "Nur-Text"-Kennwortauthentifizierung, die NTLM-Authentifizierung sowie die Kerberos-Authentifizierung.

  • Sie können ein X.509-Zertifikat mithilfe der STARTTLS-Erweiterung von SMTP verwenden. In diesem Szenario stellt der Server ein Zertifikat als Teil der TLS-Aushandlung (Transport Layer Security) bereit. Optional stellt der Client auch ein Zertifikat bereit.

  • Sie können einen externen Authentifizierungsmechanismus verwenden. Bei der externen Authentifizierung wird ein Mechanismus verwendet, der nicht zu Exchange gehört, z. B. ein physikalisch geschütztes Netzwerk oder IPsec. Diese Methode wird verwendet, wenn die Kommunikation über identifizierte IP-Routen sowie dedizierte Sendeconnectors und Empfangsconnectors erfolgt.

Der sendende Transportserver kann sich beim empfangenden Transportserver authentifizieren, bevor er die Nachricht sendet. Nachdem die Authentifizierung des Absenders erfolgt ist, wendet der empfangende Transportserver die Berechtigungen auf das Sitzungszugriffstoken an, die dem Absender gewährt werden.

In Exchange 2007 verwalten Sendeconnectors und Empfangsconnectors die Nachrichtenübermittlung. Die Connectors verfügen über eine DACL (freigegebene Zugriffssteuerungsliste), die die Berechtigungen festlegt, die dem sendenden und empfangenden E-Mail zugeordnet werden. Die Berechtigungen für Empfangsconnectors sind am wichtigsten. Die DACL auf dem Empfangsconnector bestimmt die Berechtigungen des Absenders für Nachrichten, die über den Empfangsconnector übermittelt werden. Nachdem eine SMTP-Sitzung mit einem Empfangsconnector eingerichtet wurde, startet die Sitzung ein anonymes Zugriffstoken für diese Sitzung. Eine nachfolgende erfolgreiche Authentifizierung ändert das Zugriffstoken. Wenn eine Sitzung nicht authentifiziert wird, bleiben die Berechtigungsgruppen im Zugriffstoken unverändert. Wenn eine Sitzung authentifiziert wird, erhält sie die Berechtigungen, die dem einzelnen Konto oder der einzelnen Rolle zugeordnet sind und die Berechtigungen, die allen Sicherheitsgruppen zugeordnet sind, zu denen das Konto gehört.

Das Ablaufdiagramm in Abbildung 2 veranschaulicht, wie ein Exchange 2007-Transportserver die Authentifizierung und Autorisierung in einer SMTP-Sitzung verwendet.

Abbildung 2   SMTP-Sitzungsauthentifizierung und Autorisierungsprozess

Ablaufdiagramm mit dem Authentifizierungsprozess für SMTP-Sitzungen

Authentifizierungskonfigurationen

Der für einen Empfangsconnector konfigurierte Satz von Authentifizierungsmechanismen bestimmt die Authentifizierungsmechanismen, die von Sitzungen verwendet werden können, die Nachrichten an den Empfangsconnector übermitteln. Der für einen Sendeconnector konfigurierte Authentifizierungsmechanismus bestimmt, welcher Authentifizierungsmechanismus vom Sendeconnector zum Authentifizieren bei einem Smarthost verwendet wird.

Authentifizierung für Empfangsconnectors

Sie können mehrere Authentifizierungmechanismen auf einem Empfangsconnector konfigurieren. Für einen Empfangsconnector bestimmt die Authentifizierungseinstellung den Satz der Authentifizierungsmechanismen, die vom Server aktiviert werden, um Sitzungen zu authentifizieren, die Nachrichten an den Server übermitteln. Der sendende Server bestimmt, welcher Authentifizierungsmechanismus verwendet wird.

Tabelle 1 führt die Authentifizierungsmechanismen auf, die Sie auf einem Empfangsconnector konfigurieren können. Wenn Sie den Authentifizierungsmechanismus des Empfangsconnectors konfigurieren möchten, verwenden Sie die Registerkarte Authentifizierung der Eigenschaften des Empfangsconnectors in der Exchange-Verwaltungskonsole oder den Parameter AuthMechanism mit dem Cmdlet Set-ReceiveConnector in der Exchange-Verwaltungsshell.

Tabelle 1   Authentifizierungsmechanismen für Empfangsconnectors

Authentifizierungsmechanismus Beschreibung

Keine

Es werden keine Authentifizierungsoptionen angeboten.

Transport Layer Security (TLS)

Der Connector bietet den Clients STARTTLS.

Integrierte Windows-Authentifizierung

Der Connector bietet den Clients AUTH plus NTLM GSSAPI. Mithilfe von GSSAPI können die Clients entweder NTLM oder Kerberos aushandeln.

Standardauthentifizierung

Der Connector bietet den Clients AUTH plus LOGIN. Der Benutzername und das Kennwort werden als unverschlüsselter Text vom Client empfangen. Diese Mechanismus erfordert ein Windows-Konto zum Überprüfen der Anmeldeinformationen.

Standardauthentifizierung über TLS

Dies ist der Richtlinienmodifikator für die Standardauthentifizierung. Der Connector bietet dem Client nur dann AUTH und LOGIN, wenn der Client TLS ausgehandelt hat. Dieser Mechanismus erfordert außerdem, dass TLS als Authentifizierungsmechanismus festgelegt wird.

Exchange Server-Authentifizierung

Der Connector bietet für Exchange-Server EXPS und GSSAPI, die ältere Versionen von Exchange Server ausführen sowie X-ANONYMOUSTLS für Clients von Exchange 2007-Servern.

Extern gesichert (zum Beispiel mit IPsec).

Diese Option berücksichtigt alle Verbindungen von einem anderen autorisierenden Connector.

Authentifizierung für Smarthost sendende Connectors

Für einen Sendeconnector bestimmt die Einstellung SmartHostAuthMechanism, wie der sendende Server sich beim Zielsmarthost authentifiziert. Die Einstellung SmartHostAuthMechanism kann nur einen Wert besitzen. Wenn SmartHostAuthMechanism konfiguriert ist, muss die Authentifizierung erfolgreich durchgeführt werden, bevor Nachrichten übermittelt werden können. Wenn der vom sendenden Exchange 2007-Server verwendete Authentifizierungsmechanismus nicht vom Smarthost bereitgestellt wird, sendet der Server keine E-Mail-Nachrichten und die Sitzung wird beendet. Wenn der vom sendenden Exchange 2007-Server verwendete Authentifizierungsmechanismus nicht erfolgreich ausgeführt wird, sendet der Server ebenfalls keine E-Mail-Nachrichten und die Sitzung wird beendet.

Tabelle 2 führt die Authentifizierungsmechanismen auf, die Sie auf einem Sendeconnector konfigurieren können. Wenn Sie den Authentifizierungsmechanismus des Sendeconnectors konfigurieren möchten, verwenden Sie das Dialogfeld Smarthost-Authentifizierungseinstellungen konfigurieren auf de Registerkarte Netzwerk der Eigenschaften des Sendeconnectors in der Exchange-Verwaltungskonsole oder den Parameter SmartHostAuthMechanism mit dem Cmdlet Set-SendConnector in der Exchange-Verwaltungsshell.

Tabelle 2   Authentifizierungsmechanismen für Sendeconnectors

Authentifizierungsmechanismus Beschreibung

Keine

Anonymer Zugriff ist zulässig.

Standardauthentifizierung

Der Connector muss AUTH und LOGIN verwenden. Dies erfordert, dass Sie einen Benutzernamen und ein Kennwort angeben. Bei der Standardauthentifizierung werden die Anmeldeinformationen als unverschlüsselter Text gesendet. Alle Smarthosts, über die dieser Sendeconnector die Authentifizierung durchführt, müssen denselben Benutzernamen und dasselbe Kennwort akzeptieren. Wenn der Parameter RequireTLS ebenfalls auf $True eingestellt ist, dann muss der Connector vom dem Senden der Anmeldeinformationen TLS verwenden, aber es wird keine Überprüfung des Serverzertifikats durchgeführt.

Standardauthentifizierung erfordert TLS

Dies ist ein Richtlinienmodifikator für die Standardauthentifizierung. Er erfordert, dass der Connector TLS verwendet, bevor AUTH versucht wird. Außerdem erfordert er vom sendenden Server, dass die X.509-Zertifikatsüberprüfung für den empfangenden Server ausgeführt wird. Die Zertifikatsüberprüfung umfasst das Prüfen der Zertifikatssperrliste (Certificate Revocation List, CRL) und das Vergleichen der Serveridentität mit der Liste der auf dem Connector konfigurierten Smarthosts, bevor dieser AUTH versucht. Einer der als Smarthost aufgeführten vollqualifizierten Domänennamen (Fully Qualified Domain Names, FQDN) muss im Serverzertifikat aufgeführt sein, damit der Namensvergleich erfolgreich ausgeführt werden kann. Wenn der FQDN des Smarthosts auf einen MX-Datensatz verweist, muss daher der aufgeführte Smarthost-FQDN im Zertifikat enthalten sein.

Exchange Server-Authentifizierung

Der Connector verwendet entweder EXPS und GSSAPI für Exchange-Server, die ältere Versionen von Exchange Server ausführen oder X-ANONYMOUSTLS für Exchange 2007-Server.

Extern gesichert (zum Beispiel mit IPsec).

Die Netzwerkverbindung ist mithilfe einer Methode gesichert, die sich außerhalb des Exchange-Servers befindet.

Transportschichtsicherheit (Transport Layer Security)

Das TLS-Protokoll ist in RFC 2246 beschrieben. TLS verwendet X.509-Zertifikate. Diese stellen eine Art von elektronischen Anmeldeinformationen dar. TSL kann wie folgt verwendet werden:

  • Nur für die Vertraulichkeit.

  • Für die Serverauthentifizierung mit Vertraulichkeit, bei der das Serverzertifikat überprüft wird.

  • Zur gegenseitigen Authentifizierung mit Vertraulichkeit, bei der sowohl Client- als auch Serverzertifikate überprüft werden.

Während der SMTP-Protokollverhandlung startet der Client den Befehl SMTP STARTTLS, um die Verhandlung von TLS für diese Sitzung anzufordern. Dieser Client empfängt ein X.509-Zertifikat des Servers als Teil der TLS-Protokollverhandlung. Die Clientauthentifizierungsrichtlinie bestimmt dann, ob das Zertifikat des empfangenden Servers überprüft und andere Kriterien auf das Zertifikat angewendet werden sollen, z. B. der Namensvergleich.

Ein optionaler Teil der TLS-Verhandlung ermöglicht es dem empfangenden Server, auch ein Zertifikat vom sendenden Server anzufordern. Wenn der sendende Server ein Zertifikat an den empfangenen Server sendet, bestimmt die lokale Richtlinie auf dem empfangenen Server, wie das Zertifikat überprüft wird und welche Berechtigungen dem sendenden Server aufgrund der Authentifizierung erteilt werden.

Wenn TLS für die Serverauthentifizierung verwendet wird, erfolgt nur die Überprüfung des Zertifikats des empfangenden Servers. Wenn TLS für die gegenseitige Authentifizierung verwendet wird, müssen sowohl das Zertifikat des sendenden Servers als auch das Zertifikat des empfangenen Servers überprüft werden.

Wenn TLS auf einem Exchange 2007-Empfangsconnector konfiguriert ist, muss der Server über ein X.509-Zertifikat verfügen. Bei diesem Zertifikat kann es sich um ein selbstsigniertes Zertifikat oder um ein von einer Zertifizierungsstelle signiertes Zertifikat handeln. Der Exchange-Server sucht im lokalen Speicher nach einem Zertifikat, das mit dem FQDN des Connectors übereinstimmt. Der sendende Server wählt aus, wie das TLS-Protokoll verwendet wird. Wenn Exchange TSL nur für die Vertraulichkeit verwendet, überprüft der Exchange-Client das Zertifikat nicht. Wenn Exchange TLS z. B. zwischen Hub-Transport-Servern mithilfe des "Kerberos über TLS"-Protokolls verwendet, richtet es einen vertraulichen Kanal zwischen den Servern ein und führt für das Zertifikat keine Überprüfung durch. Die Authentifizierung zwischen den Servern erfolgt mithilfe von Kerberos, nachdem das TLS-Protokoll abgeschlossen ist.

Wenn die TLS-Authentifizierung erforderlich ist, muss Exchange das Zertifikat überprüfen. Es gibt zwei Möglichkeiten, mit denen Exchange das Zertifikat überprüfen kann: Direkte Vertrauensstellung oder X.509-Überprüfung. Wenn TLS für die Kommunikation zwischen Edge-Transport- und Hub-Transport-Servern verwendet wird, dann setzt Exchange eine direkte Vertrauensstellung ein, um das Zertifikat zu überprüfen.

Direkte Vertrauensstellung bedeutet, dass Exchange einen vertrauenswürdigen Speicher verwendet, z. B. ADAM (Active Directory oder Active Directory Application Mode). Direkte Vertrauensstellung bedeutet auch, dass ein Zertifikat durch das Vorhandensein des Zertifikats im Speicher bestätigt wird. Wenn die direkte Vertrauensstellung verwendet wird, ist es nicht von Bedeutung, ob das Zertifikat selbstsigniert oder von einer Zertifizierungsstelle signiert ist. Wenn Sie einen Edge-Transport-Server für eine Exchange-Organisation abonnieren, veröffentlicht das Abonnement das Edge-Transport-Serverzertifikat für die Überprüfung durch die Hub-Transport-Server in Active Directory. Der Microsoft Exchange Edgesync-Dienst aktualisiert ADAM mit dem Satz von Hub-Transport-Serverzertifikaten, damit diese vom Edge-Transport-Server überprüft werden können.

Die zweite Methode zum Überprüfen von Zertifikaten, die Exchange verwendet, ist die X.509-Überprüfung. Wenn die X.509-Überprüfung verwendet wird, muss das Zertifikat von einer Zertifizierungsstelle signiert sein. Exchange verwendet die X.509-Überprüfung beim Authentifizieren von Smarthosts oder bei der Verwendung der Domänensicherheit. Die Domänensicherheit wird im folgenden Abschnitte erläutert.

Domänensicherheit

Die Domänensicherheit bezieht sich in Exchange 2007 und Microsoft Office Outlook auf eine Reihe von Funktionen, die eine relativ kostengünstige Alternative zu S/MIME oder andere Sicherheitslösungen auf Nachrichtenebene darstellen. Der Zweck der Domänensicherheit ist es, Administratoren eine Möglichkeit zum Verwalten gesicherter Nachrichtenpfade zu Geschäftspartnern über das Internet bereitzustellen. Nachdem diese gesicherten Nachrichtenpfade konfiguriert sind, werden die erfolgreich über den gesicherten Pfad übertragenen Nachrichten eines authentifizierten Absenders den Benutzern in der Benutzeroberfläche von Outlook und Outlook Web Access als "domänengesichert" angezeigt.

Ein Sendeconnector überprüft, das sich die Zieldomäne auf der Liste der Absenderdomänen befindet, die für die Domänensicherheit konfiguriert sind, wenn die folgenden Bedingungen zutreffen:

  • Der Sendeconnector ist für die Weiterleitung von Nachrichten mithilfe eines öffentlichen DNS (Domain Name System) MX-Ressourcendatensatzes (Mail Exchange) konfiguriert.

  • Der Sendeconnector ist als "domänengesichert" konfiguriert.

Wenn sich die Zieldomäne auf der Liste befindet, erzwingt der Transportserver die gegenseitige TLS-Authentifizierung, wenn sie E-Mails an die Domäne sendet.

Der empfangende Server antwortet mit einem SMTP QUIT-Befehl, wenn die folgenden Bedingungen zutreffen:

  • Exchange kann TLS nicht aushandeln.

  • Bei der Serverzertifikatsüberprüfung oder der CRL-Überprüfung ist ein Fehler aufgetreten.

Die Nachrichten befinden sich auf dem sendenden Server in einer Warteschlange. Die Warteschlange besitzt den Status "Wiederholen". Dieses Verhalten tritt auch auf, wenn bei der Überprüfung des Namens ein Fehler auftritt.

Wenn ein Empfangsconnector domänengesichert ist, überprüft der Transportserver die empfangenen Nachrichten. Dann erzwingt der Transportserver die gegenseitige TLS-Authentifizierung, wenn sich der Absender auf der Liste der Empfängerdomänen befindet, die für die Domänensicherheit konfiguriert sind. Wenn alle Überprüfungen erfolgreich ausgeführt wurden, wird die empfangene Nachricht als "domänengesichert" gekennzeichnet. Wenn der Absender TLS nicht aushandeln kann oder die Serverzertifikatsüberprüfung oder die CRL-Überprüfung fehlgeschlagen ist, lehnt der Transportserver die Nachricht mithilfe des REJECT-Befehls des SMTP-Protokolls ab. Wenn bei der Namensüberprüfung ein Fehler auftritt, führt dies ebenfalls zum REJECT-Befehl des SMTP-Protokolls. Dann sendet der Exchange-Server eine Nachricht über einen temporären SMTP-Fehler (4xx) an den sendenden Server. Das bedeutet, dass es der sendende Server später noch mal probieren soll. Dieses Verhalten verhindert, dass durch temporäre CRL-Überprüfungsfehler hervorgerufene Übergangsfehler zu einem sofortigen Unzustellbarkeitsbericht an den Absender führen. Der Fehler verzögert nur die Nachrichtenübermittlung.

Weitere Informationen finden Sie unter Verwalten der Domänensicherheit.

Extern gesicherte Authentifizierung

Sie können die Authentifizierungsoption für die externe Sicherheit auswählen, wenn Sie sich sicher sind, dass die Netzwerkverbindung zwischen den Servern vertrauenswürdig ist. Diese Verbindung kann eine IPsec-Zuordnung oder ein virtuelles privates Netzwerk (VPN) sein. Alternativ können die Server sich auch in einem vertrauenswürdigen, physikalisch gesteuerten Netzwerk befinden. Diese Konfiguration ist im folgenden Fall hilfreich:

  • Sie richten eine Nachrichtenübermittlung zwischen einem Exchange 2007-Transportserver und einer älteren Version von Exchange Server oder einem beliebigen anderen SMTP-Server ein.

  • Sie möchten die Standardauthentifizierung nicht verwenden.

Als extern gesicherte konfigurierte Exchange-Connectors müssen dedizierte Sendeconnectors und Empfangsconnectors verwenden, da alle Verbindungen zu den Connectors als sicher betrachtet werden. Daher müssen Sendeconnectors, die als extern gesichert konfiguriert sind, einen Smarthost für die Weiterleitung von Nachrichten verwenden. Außerdem müssen die IP-Adressen der Zielsmarthosts auf dem Connector konfiguriert sein. Für Empfangsconnectors, die als extern gesichert konfiguriert sind, muss der Parameter RemoteIPRanges auf den IP-Adressbereich des sendenden Servers eingestellt sein. TLS kann auch mit der extern gesicherten Authentifizierung kombiniert werden, um die Vertraulichkeit der Sitzung zu erhöhen. Dies können Sie in der Exchange-Verwaltungsshell erreichen, wenn Sie für den Parameter RequireTLS der Connectors den Wert $True festlegen.

Autorisierung

Beim Nachrichtentransport stellt die Autorisierung den Prozess dar, der bestimmt, ob eine angeforderte Aktion, z. B. das Senden von Nachrichten, für eine SMTP-Sitzung zugelassen wird.

Exchange 2007-Transportberechtigungen

Die Exchange 2007-Transportserver verwenden das Autorisierungsmodell von Windows für eine SMTP-Sitzung, um zu bestimmen, ob der Absender Nachrichten beispielsweise an einen bestimmten Connector oder bestimmten Empfänger und als spezifischer Absender senden darf. Eine SMTP-Sitzung erhält einen anfänglichen Berechtigungssatz (anonym). Nachdem eine Sitzung authentifiziert wurde, stehen der Sitzung weitere Berechtigungen zur Verfügung. Dadurch ändert sich der Satz der Aktionen, die für die Sitzung autorisiert sind.

Im Autorisierungsmodell von Windows werden Berechtigungen über eine Zugriffssteuerungsinteraktion erteilt, bei der das Zugriffstoken mit den Zugriffssteuerungslisten (Access Control List, ACL) verglichen wird. Ein Zugriffstoken führt einen Satz von Sicherheitsprinzipalen auf. Ein Sicherheitsprinzipal kann ein Benutzerkonto, ein Computerkonto oder eine Sicherheitsgruppe sein. Jeder Sicherheitsprinzipal besitzt eine zugeordnete Sicherheits-ID (SID). Jeder Sitzung ist ein Zugriffstoken zugeordnet. Die Zugriffssteuerungslisten sind im Connectorobjekt in Active Directory oder ADAM definiert. Eine DACL enthält einen Satz von Zugriffssteuerungseinträgen (Access Control Entries, ACE). Jeder ACE lässt eine Berechtigung für einen Sicherheitsprinzipal zu oder lehnt diese ab. Wenn der Transportserver prüft, ob der Sitzung eine Berechtigung erteilt wurde, z. B. zum Senden von E-Mails, dann ruft sie eine Windows-API für die Zugriffsprüfung auf und stellt das Sitzungszugriffstoken sowie die DACL des Connectors als Parameter zusammen mit der angeforderten Berechtigung bereit.

Dieser Prozess ist mit der Ermittlung einer Berechtigung zum Lesen von Dateien vergleichbar. Das Zugriffstoken, die Datei-DACL und die angeforderte Berechtigung werden an die gleiche API gesendet. Die API prüft jeden Sicherheitsprinzipalen, der im Zugriffstoken aufgeführt ist, anhand der einzelnen Zugriffssteuerungseinträge in der DACL, um zu ermitteln, ob die angeforderte Berechtigung gewährt oder abgelehnt wird. Zusätzlich zu den von Active Directory, ADAM oder der lokalen SAM-Datenbank (Security Accounts Manager) auf einem Computer bereitgestellten Windows-SIDs, legt Exchange 2007 weitere SIDs fest. Diese SIDs stellen logische Gruppen dar. In Tabelle 3 sind die von Exchange 2007 für die Verwendung bei der Transportauthentifizierung definierten SIDs aufgeführt.

Tabelle 3   Exchange 2007-SIDs

Anzeigename SID Logische Gruppe

Partnerserver

S-1-9-1419165041-1139599005-3936102811-1022490595-10

Sender- und Empfängerdomänen, die für die Domänensicherheit definiert sind.

Hub-Transport-Server

S-1-9-1419165041-1139599005-3936102811-1022490595-21

Hub-Transport-Server in der gleichen Exchange-Organisation.

Edge-Transport-Server

S-1-9-1419165041-1139599005-3936102811-1022490595-22

Vertrauenswürdige Edge-Transport-Server

Extern gesicherte Server

S-1-9-1419165041-1139599005-3936102811-1022490595-23

Vertrauenswürdige Server von Drittanbietern, die sich in der gleichen autorisierenden Domäne befinden.

Legacy-Exchange-Server

S-1-9-1419165041-1139599005-3936102811-1022490595-24

Exchange Server 2003-Server, die sich in der gleichen Exchange-Organisation befinden.

Empfangsconnectorberechtigungen

Empfangsconnectors verarbeiten auf dem Server eingehende Sitzungen. Die Sitzung kann von einem authentifizierten oder von einem anonymen Absender eingerichtet werden. Wenn eine Sitzung erfolgreich authentifiziert wurde, werden die SIDs im Sitzungszugriffstoken aktualisiert. In Tabelle 4 sind die Berechtigungen aufgeführt, die einer Sitzung erteilt werden können, die eine Verbindung zu einem Empfangsconnector herstellt.

Tabelle 4   Empfangsconnectorberechtigungen

Berechtigung Anzeigename Beschreibung

ms-Exch-SMTP-Submit

Nachrichten an Server übermitteln

Der Sitzung muss diese Berechtigung erteilt werden, ansonsten ist sie nicht in der Lage, Nachrichten an diesen Empfangsconnector zu übermitteln. Wenn eine Sitzung nicht über diese Berechtigung verfügt, schlägt der Befehl MAIL FROM fehl.

ms-Exch-SMTP-Accept-Any-Recipient

Nachrichten an beliebige Empfänger übermitteln

Diese Berechtigung ermöglicht es der Sitzung, Nachrichten über diesen Connector weiterzugeben. Wenn diese Berechtigung nicht erteilt wird, werden von diesem Connector nur Nachrichten akzeptiert, die an Empfänger in akzeptierten Domänen adressiert sind.

ms-Exch-SMTP-Accept-Any-Sender

Jeden Absender akzeptieren

Diese Berechtigung ermöglicht es der Sitzung, die Täuschungsprüfung (Spoofing) für die Absenderadresse zu umgehen.

ms-Exch-SMTP-Accept-Authoritative-Domain-Sender

Absender aus autorisierender Domäne akzeptieren

Diese Berechtigung ermöglicht es der Sitzung, eine Prüfung zu umgehen, die eingehende Nachrichten von E-Mail-Adressen in autorisierenden Domänen verhindert.

ms-Exch-SMTP-Accept-Authentication-Flag

Authentifizierungskennzeichen akzeptieren

Diese Berechtigung ermöglicht es Exchange-Servern, die ältere Versionen von Exchange Server ausführen, Nachrichten von internen Absendern zu übermitteln. Exchange 2007-Server erkennen diese dann als interne Nachricht.

ms-Exch-Accept-Headers-Routing

Routingkopfzeilen akzeptieren

Diese Berechtigung ermöglicht es der Sitzung, eine Nachricht zu übermitteln, bei der alle empfangenen Kopfzeilen intakt sind. Wenn diese Berechtigung nicht erteilt wird, entfernt der Server alle empfangenen Kopfzeilen.

ms-Exch-Accept-Headers-Organization

Organisationskopfzeilen akzeptieren

Diese Berechtigung ermöglicht es der Sitzung, eine Nachricht zu übermitteln, bei der alle Organisationskopfzeilen intakt sind. Organisationskopfzeilen beginnen alle mit "X-MS-Exchange-Organization-". Wenn diese Berechtigung nicht erteilt wird, entfernt der empfangende Server alle Organisationskopfzeilen.

ms-Exch-Accept-Headers-Forest

Gesamtstrukturkopfzeilen akzeptieren

Diese Berechtigung ermöglicht es der Sitzung, eine Nachricht zu übermitteln, bei der alle Gesamtstrukturkopfzeilen intakt sind. Gesamtstrukturkopfzeilen beginnen alle mit "X-MS-Exchange-Forest-". Wenn diese Berechtigung nicht erteilt wird, entfernt der empfangende Server alle Gesamtstrukturkopfzeilen.

ms-Exch-Accept-Exch50

Exch50 akzeptieren

Diese Berechtigung ermöglicht es der Sitzung, eine Nachricht zu übermitteln, die den Befehl XEXCH50 enthält. Dieser Befehl ist für die Interoperabilität zwischen Exchange 2000 Server und Exchange 2003 erforderlich. Der Befehl EXCH50 stellt Daten wie die SCL (Spam Confidence Level) für die Nachricht bereit.

ms-Exch-Bypass-Message-Size-Limit

Beschränkung der Nachrichtengröße umgehen

Diese Berechtigung ermöglicht es der Sitzung, eine Nachricht zu übermitteln, die die für den Connector konfigurierte Beschränkung der Nachrichtengröße überschreitet.

Ms-Exch-Bypass-Anti-Spam

Antispam umgehen

Diese Berechtigung ermöglicht es der Sitzung, die Antispamfilter zu umgehen.

Sendeconnectorberechtigungen

Sendeconnectors verarbeiten an einen anderen Server ausgehende Sitzungen. Die Sitzung kann vom Absender für einen authentifizierten oder anonymen Empfänger eingerichtet werden. Wenn die Sitzung erfolgreich authentifiziert wurde, wird der SID-Satz im Sitzungszugriffstoken aktualisiert. Sendeconnectorberechtigungen bestimmen den Typ der Kopfzeileninformationen, die in eine Nachricht einbezogen werden können, die mithilfe des Connectors gesendet wird. An andere Exchange-Server in der Organisation oder an eine vertrauenswürdige Exchange-Organisation gesendete Nachrichten in einem gesamtstrukturübergreifenden Szenario dürfen normalerweise alle Kopfzeilen senden. Über das Internet oder an nicht zu Exchange gehörende SMTP-Server gesendete Nachrichten, dürfen nicht alle Kopfzeilen enthalten. Wenn in der Nachricht Kopfzeilen einbezogen sind, entfernt die Kopfzeilenfirewallfunktion von Exchange 2007 diese Kopfzeilen. In Tabelle 5 sind die Berechtigungen aufgeführt, die einer Sitzung erteilt werden können, die eine Verbindung zu einem Sendeconnector herstellt.

Tabelle 5   Sendeconnectorberechtigungen

Berechtigung Anzeigename Beschreibung

ms-Exch-Send-Exch50

Exch50 senden

Diese Berechtigung ermöglicht es der Sitzung, eine Nachricht zu übermitteln, die den Befehl EXCH50 enthält. Wenn diese Berechtigung nicht erteilt wird, sendet der Server die Nachricht, ohne den Befehl EXCH50 einzubeziehen.

Ms-Exch-Send-Headers-Routing

Routingkopfzeilen senden

Diese Berechtigung ermöglicht es der Sitzung, eine Nachricht zu senden, bei der alle empfangenen Kopfzeilen intakt sind. Wenn diese Berechtigung nicht erteilt wird, entfernt der Server alle empfangenen Kopfzeilen.

Ms-Exch-Send-Headers-Organization

Organisationskopfzeilen senden

Diese Berechtigung ermöglicht es der Sitzung, eine Nachricht zu senden, bei der alle Organisationskopfzeilen intakt sind. Organisationskopfzeilen beginnen alle mit "X-MS-Exchange-Organization-". Wenn diese Berechtigung nicht erteilt wird, entfernt der sendende Server alle Organisationskopfzeilen.

Ms-Exch-Send-Headers-Forest

Gesamtstrukturkopfzeilen senden

Diese Berechtigung ermöglicht es der Sitzung, eine Nachricht zu senden, bei der alle Gesamtstrukturkopfzeilen intakt sind. Gesamtstrukturkopfzeilen beginnen alle mit "X-MS-Exchange-Forest-". Wenn diese Berechtigung nicht erteilt wird, entfernt der sendende Server alle Gesamtstrukturkopfzeilen.

Berechtigungsgruppen

Eine Berechtigungsgruppe entspricht einem vordefinierten Satz von Berechtigungen, die auf einem Empfangsconnector erteilt werden können. Berechtigungsgruppen sind nur für Empfangsconnectors verfügbar. Die Verwendung von Berechtigungsgruppen vereinfacht die Konfiguration von Berechtigungen auf Empfangsconnectors. Die Eigenschaft PermissionGroups definiert die Gruppen oder Rollen, die Nachrichten an den Empfangsconnector übermitteln können sowie die Berechtigungen, die für diese Gruppen zulässig sind. Der Satz der Berechtigungsgruppen ist in Exchange 2007 vordefiniert. Daher können Sie keine zusätzlichen Berechtigungsgruppen erstellen. Außerdem können Sie die Berechtigungsgruppenmitglieder oder zugeordneten Berechtigungen nicht ändern.

In Tabelle 6 sind die Berechtigungsgruppen, die Berechtigungsgruppenmitglieder und die zugeordneten Berechtigungen aufgeführt, die in Exchange 2007 zur Verfügung stehen.

Tabelle 6   Berechtigungsgruppen und zugeordnete Berechtigungen für den Empfangsconnector

Name der Berechtigungsgruppe Sicherheitsprinzipale Auf Edge-Transport-Servern erteilte Berechtigungen Auf Hub-Transport-Servern erteilte Berechtigungen

Anonym

Anonyme Benutzer

  • Nachrichten an Server übermitteln

  • Jeden Absender akzeptieren

  • Routingkopfzeilen akzeptieren

  • Nachrichten an Server übermitteln

  • Jeden Absender akzeptieren

  • Routingkopfzeilen akzeptieren

ExchangeUsers

Authentifizierte Benutzer (bekannte Konten werden ausgeschlossen)

Nicht verfügbar

  • Nachrichten an Server übermitteln

  • Jeden Empfänger akzeptieren

  • Antispamfilter umgehen

Exchange-Server

Exchange 2007-Server

Alle Empfangsberechtigungen

  • Alle Empfangsberechtigungen

ExchangeLegacyServers

Exchange 2003- und Exchange 2000-Server

Nicht verfügbar

  • Nachrichten an Server übermitteln

  • Nachrichten an beliebige Empfänger übermitteln

  • Jeden Absender akzeptieren

  • Absender aus autorisierender Domäne akzeptieren

  • Authentifizierungskennzeichen akzeptieren

  • Routingkopfzeilen akzeptieren

  • Exch50 akzeptieren

  • Beschränkungen der Nachrichtengröße umgehen

  • Antispamfilter umgehen

Partner

Partnerserverkonto

  • Nachrichten an Server übermitteln

  • Routingkopfzeilen akzeptieren

  • Nachrichten an Server übermitteln

  • Routingkopfzeilen akzeptieren

Connectorverwendungstypen

Wenn Sie einen neuen Connector erstellen, können Sie einen Verwendungstyp für den Connector angeben. Der Verwendungstyp bestimmt die Standardeinstellungen für den Connector. Dies umfasst die zu authentifizierenden SIDs, die diesen SIDs zuzuweisende Berechtigungen und den Authentifizierungsmechanismus.

In Tabelle 7 sind die Verwendungstypen aufgeführt, die für einen Empfangsconnector verfügbar sind. Wenn Sie einen Verwendungstyp für einen Empfangsconnector auswählen, werden die Berechtigungsgruppen dem Connector automatisch zugeordnet. Außerdem wird auch ein Standardauthentifizierungsmechanismus konfiguriert.

Tabelle 7   Verwendungstypen für Empfangsconnectors

Verwendungstyp Standardberechtigungsgruppen Standardauthentifizierungsmechanismus

Client

ExchangeUsers

  • TLS

  • BasicAuthPlusTLS

Benutzerdefiniert

Keine

Keine

Intern

  • ExchangeServers

  • ExchangeLegacyServers

Exchange Server-Authentifizierung

Internet

AnonymousUsers

Partner

Keine oder extern gesichert.

Partner

Partner

Nicht zutreffend. Dieser Verwendungstyp ist ausgewählt, wenn Sie eine gegenseitige TSL-Authentifizierung mit einer Remotedomäne einrichten.

In Tabelle 8 sind die Verwendungstypen aufgeführt, die für einen Sendeconnector verfügbar sind. Wenn Sie einen Verwendungstyp für einen Sendeconnector auswählen, werden die Berechtigungen den SIDs automatisch zugeordnet. Außerdem wird auch ein Standardauthentifizierungsmechanismus konfiguriert.

Tabelle 8   Verwendungstypen für Sendeconnectors

Verwendungstyp Standardberechtigungen Sicherheitsprinzipale Standardauthentifizierungsmechanismus für Smarthosts

Benutzerdefiniert

Keine

Keine

Keine

Intern

  • Organisationskopfzeilen senden

  • Exch50 senden

  • Routingkopfzeilen senden

  • Gesamtstrukturkopfzeilen senden

  • Hub-Transport-Server

  • Edge-Transport-Server

  • Exchange-Serversicherheitsgruppe

  • Extern gesicherte Server

  • Sicherheitsgruppe "Exchange Legacy Interop"

  • Exchange 2003- und Exchange 2000-Bridgeheadserver

Exchange Server-Authentifizierung

Internet

Routingkopfzeilen senden

Anonymes Benutzerkonto

Keine

Partner

Routingkopfzeilen senden

Partnerserver

Nicht zutreffend. Dieser Verwendungstyp ist ausgewählt, wenn Sie eine gegenseitige TSL-Authentifizierung mit einer Remotedomäne einrichten.

Wenn Sie den Verwendungstyp Benutzerdefiniert für einen Sendeconnector oder Empfangsconnector auswählen, müssen Sie die Authentifizierungsmethoden und die autorisierten SIDs manuell konfigurieren und den SIDs Berechtigungen zuweisen. Wenn Sie keinen Verwendungstyp angeben, wird als Verwendungstyp für den Connector Benutzerdefiniert festgelegt.

Festlegen von Berechtigungen mithilfe des Skripts "Enable-CrossForestConnector"

Sie können das Skript Enable-CrossForestConnector.ps1 verwenden, um das Konfigurieren von Berechtigungen für gesamtstrukturübergreifende Connectors zu vereinfachen. Das Skript ordnet Berechtigungen in einer Weise zu, die einer Berechtigungsgruppe gleicht. Einem Sendeconnector oder Empfangsconnector wird ein definierter Satz von Berechtigungen zugeordnet. Sie können diesen Berechtigungssatz nach Bedarf ändern, indem Sie den Inhalt des Skripts Enable-CrossForestConnector.ps1 modifizieren. Weitere Informationen finden Sie unter Konfigurieren gesamtstrukturübergreifender Connectors.

Festlegen von Berechtigungen mithilfe des Cmdlets "Add-AdPermission"

Das Cmdlet Add-AdPermission in der Exchange-Verwaltungsshell ist ein globales Cmdlet, mit dem Berechtigungen zu Objekten zugeordnet werden können, die in Active Directory gespeichert werden. Mithilfe des Cmdlets Add-AdPermission können Sie einem Sendeconnector oder einem Empfangsconnector einzelne Berechtigungen erteilten. Das Cmdlet Add-AdPermission wird normalerweise nicht zum Verwalten von Transportberechtigungen verwendet. Es muss jedoch zum Konfigurieren von Berechtigungen in den folgenden Szenarien verwendet werden:

  • Einrichten der Nachrichtenübermittlung in einem gesamtstrukturübergreifenden Szenario.

  • Akzeptieren anonymer E-Mails aus dem Internet von einem Absender in einer autorisierenden Domäne.

Die Exchange 2007-Transportberechtigungen sind Teil des Satzes der erweiterten Rechte, die mithilfe dieses Cmdlets zugeordnet werden können. Das folgende Verfahren veranschaulicht, wie Sie mit dem Add-AdPermission Berechtigungen für den Empfangsconnector eines Hub-Transport-Servers festlegen können, um anonymen Sitzungen das Übermitteln von Nachrichten zu gewähren:

Festlegen von Berechtigungen für einen Empfangsconnector mithilfe der Exchange-Verwaltungsshell

  • Führen Sie den folgenden Befehl aus:

    Add-AdPermission -Identity "Default Hub1" -User "NT AUTHORITY\ANONYMOUS LOGON" -ExtendedRights ms-Exch-SMTP-Submit,ms-Exch-SMTP-Accept-Any-Recipient,ms-Exch-Bypass-Anti-Spam
    

Mithilfe des Cmdlets Get-AdPermission können Sie die DACL für einen Sendeconnector oder Empfangsconnector anzeigen. Führen Sie einen der folgenden Befehle aus, um die Berechtigungen abzurufen, die einem Empfangsconnector zugeordnet sind und die Ergebnisse in einer formatierten Tabelle anzuzeigen:

Anzeigen von erweiterten Berechtigungen für einen Empfangsconnector mithilfe der Exchange-Verwaltungsshell

  • Führen Sie einen der folgenden Befehle aus:

    Get-AdPermission -Identity "Default ServerName" | format-table -view User
    Get-AdPermission -Identity "Default ServerName" | format-table -view Identity
    

Sie können das Cmdlet Remove-AdPermission verwenden, um beliebige zuvor zugeordnete Berechtigungen zu entfernen.

Weitere Informationen über das Festlegen, Anzeigen und Entfernen von Berechtigungen mithilfe der Exchange-Verwaltungsshell finden Sie unter den folgenden Themen:

Festlegen von Berechtigungen mithilfe der ADSI-Bearbeitung

ADSI-Bearbeitung (Active Directory Service Interfaces) ist eine Microsoft-Verwaltungskonsole, die mit den Windows-Supporttools bereitgestellt wird. Die ADSI-Bearbeitung wird als Low-Level-Editor zum Ändern der Eigenschaften von Active Directory- oder ADAM-Objekten verwendet, die in anderen Verwaltungsoberflächen nicht angezeigt werden. Die ADSI-Bearbeitung sollte nur von erfahrenen Administratoren verwendet werden.

Mithilfe der ADSI-Bearbeitung können Sie die ACLs für Sende- und Empfangsconnectors anzeigen und ändern. Nachdem Sie die ADSI-Bearbeitung geöffnet haben, navigieren Sie zum Connectorobjekt. Exchange 2007-Connectors werden in der Partition Konfiguration des Verzeichnisdiensts gespeichert. Sendeconnectors werden als Objekt im Container Verbindungen gespeichert. Empfangsconnectors werden als untergeordnetes Objekt des Exchange 2007-Transportservers gespeichert.

So ändern Sie Empfangsconnectorberechtigungen mithilfe der ADSI-Bearbeitung

  1. Navigieren Sie zum Empfangsconnector, indem Sie zum folgenden Speicherort wechseln:

    CN=Configuration\CN=Services\CN=Microsoft Exchange\CN=<Organisation>\CN=Administrative Groups\CN=Exchange Administrative Group (FYDIBOHF23SPDLT)\CN=Servers\CN=<Servername>\CN=Protocols\CN=SMTP Receive Connectors

  2. Wählen Sie im Ergebnisbereich einen Empfangsconnector aus. Klicken Sie mit der rechten Maustaste auf den Empfangsconnector, und klicken Sie dann auf Eigenschaften.

  3. Klicken Sie auf die Registerkarte Sicherheit. Der folgende Bildschirm wird angezeigt:

    Empfangsconnector Sicherheit (Registerkarte) in ADSI-Editor

  4. Klicken Sie auf Hinzufügen, um den Benutzer oder die Gruppe auszuwählen, denen Berechtigungen zugeordnet werden, oder wählen Sie einen vorhandenen Eintrag für Gruppe oder Benutzername aus.

  5. Wählen Sie die Berechtigungen aus, die dem Konto zugeordnet werden sollen, und aktivieren Sie dann das Kontrollkästchen in der Spalte Zulassen.

So ändern Sie Sendeconnectorberechtigungen mithilfe der ADSI-Bearbeitung

  1. Navigieren Sie zum Sendeconnector, indem Sie zum folgenden Speicherort wechseln:

    CN=Configuration\CN=Services\CN=Microsoft Exchange\CN=<Organisation>\CN=Administrative Groups\CN=Exchange Administrative Group(FYDIBOHF23SPDLT)\CN=Routing Groups\CN=Routing Group (DWBGZMFD01QNBJR)\CN=Connections

  2. Wählen Sie im Ergebnisbereich einen Sendeconnector aus. Klicken Sie mit der rechten Maustaste auf den Connector, und klicken Sie dann auf Eigenschaften.

  3. Klicken Sie auf die Registerkarte Sicherheit. Der folgende Bildschirm wird angezeigt:

    Sendeconnector Sicherheit (Registerkarte) in ADSI-Editor

  4. Klicken Sie auf Hinzufügen, um den Benutzer oder die Gruppe auszuwählen, denen Berechtigungen zugeordnet werden, oder wählen Sie einen vorhandenen Eintrag für Gruppe oder Benutzername aus.

  5. Wählen Sie die Berechtigungen aus, die dem Konto zugeordnet werden sollen, und aktivieren Sie dann das Kontrollkästchen in der Spalte Zulassen.

Problembehandlung bei Berechtigungen

Während der Protokollverhandlung lehnt der SMTP-Server möglicherweise bestimmte Befehle ab, da die entsprechenden Berechtigungen fehlen. In Tabelle 9 sind die häufigsten Nachrichten für die Ablehnung von Protokollen und die Konfiguration der Berechtigungen aufgeführt, die den Fehler verursacht.

Tabelle 9   Häufige Nachrichten für die Ablehnung von Protokollen und ihre Ursachen

SMTP-Serverantwort Ursache

530 5.7.1 Client wurde nicht authentifiziert

Der im Feld MAIL FROM des SMTP-Protokolls angegebene Absender verfügt nicht über die Berechtigung für diesen Server. Dem Absender muss die Berechtigung ms-Exch-SMTP-Submit erteilt werden.

535 5.7.3 Authentifizierung nicht erfolgreich ausgeführt

Während der AUTH-Phase bei der SMTP-Protokollverhandlung wurden falsche Anmeldeinformationen angegeben oder der authentifizierte Benutzer verfügt nicht über die Berechtigung für die Übermittlung an diesen Server.

550 5.7.1 Client verfügt nicht über die Berechtigung für die Übermittlung an diesen Server

Der im Feld MAIL FROM der SMTP-Protokollverhandlung angegebene Absender wurde authentifiziert, verfügt aber nicht über die Berechtigung für die Übermittlung an diesen Server.

550 5.7.1 Client verfügt nicht über die Berechtigung zum Senden als dieser Absender

Der im Feld MAIL FROM der SMTP-Protokollverhandlung angegebene Absender stellt eine Adresse in einer autorisierenden Domäne dar. Die Sitzung verfügt jedoch nicht über die Berechtigung ms-Exch-SMTP-Accept-Authoritative-Domain-Sender. Dieses Problem kann auftreten, wenn eine Nachricht über das Internet an einen Edge-Transport-Server übermittelt wurde, für den die Exchange-Organisation die Autorisierung übernimmt.

550 5.7.1 Client verfügt nicht über die Berechtigung zum Senden im Namen der Absenderadresse

Der authentifizierte Benutzer verfügt nicht über die Berechtigung zum Übermitteln einer Nachricht im Namen des Absenders, der in der Kopfzeile der Nachricht angegeben ist. Außerdem verfügt die Sitzung nicht über die Berechtigung ms-Exch-SMTP-Accept-Any-Sender.

550 5.7.1. Kein Relay möglich

Die Empfängerdomäne, an die die Nachricht gerichtet ist, befindet sich in keiner der akzeptierten Domänen, die für diese Organisation angegeben sind. Außerdem verfügt die Sitzung nicht über die Berechtigung ms-Exch-SMTP-Accept-Any-Recipient.

Weitere Informationen

Weitere Informationen hierzu finden Sie unter den folgenden Themen: