de-DEen-GB
 
rss

Granikos Technology Blog

On Februar 9, 2018
751 Views
The blog post in English has been published at ENow's Solution Engine (ESE) blog.


Die Nutzung von Office 365 Diensten erfordert eine korrekte Namensauflösung für die verwendeten Dienste. Ohne eine funktionierende Namensauflösung können Anwender aus dem Unternehmensnetzwerk oder direkt aus dem Internet nicht auf Office 365-Dienste zugreifen. Das "Finden" der Office 365-Dienste erfolgt auf Basis des Anmeldenamens des Anwenders. Dieser Anmeldename (UPN) und die Haupt-E-Mail-Adresse sind im Idealfall identisch. Die Hintergründe für diese Anforderung hat Joe Palichario bereits 2015 in seinem Blog veröffentlicht. In meinem Beispiel folgen die Anmeldenamen dem Schema Vorname.Nachname@granikoslabs.de, der ADFS Authentifizierungsserver ist unter dem Namen adfs.granikoslabs.de veröffentlicht.

Unter einer Split-DNS Konfiguration versteht man den Betrieb der DNS-Zone, in einer internen und einer externen Konfiguration. Die interne DNS-Zone wird auf DNS-Servern bereitgestellt, die von Clientsystemen aus dem Unternehmensnetzwerk angefragt werden. Die externe DNS-Zone wird entweder auf eigenen DNS-Servern, die aus dem Internet erreichbar sind, oder auf DNS-Servern eines Internet DNS-Anbieters bereitgestellt. Diese Split-DNS Aufteilung ist wichtig, um Clientsystemen entweder die interne IP-Adresse oder die öffentliche IP-Adresse eines Dienstendpunktes bereitzustellen. In einer Hybrid-Konfiguration mit Office 365 ist solch eine Split-DNS Konfiguration dringend empfohlen. Wenn Sie Office 365 im reinen Cloudbetrieb nutzen, ist diese Konfiguration nicht notwendig.

Das folgende Schaubild verdeutlicht die DNS Konfiguration für die Split-DNS Implementierung inklusive ADFS-Server und ADFS-Proxy.

Übersicht Split-DNS und ADFS mit Office 365

Ein interner Client, der auf Ressourcen von Office 365 zugreifen möchte, muss sich am internen ADFS-System authentifizieren . Hierzu wird der Client zum ADFS-Server umgeleitet.

  1. Das interne Clientsystem fragt den internen DNS-Server nach der IP-Adresse für adfs.granikoslabs.de und erhält die interne IP-Adresse des ADFS-Servers
  2. Das interne Clientsystem verbindet sich zum internen ADFS-Server, wird authentifiziert und kann, falls berechtigt, auf die gewünschte Office 365 Ressource zugreifen

Ein externer Client, der auf Ressourcen von Office 365 zugreifen möchte, muss sich ebenfalls am internen ADFS-System authentifizieren. Jedoch ist dieses System nicht direkt aus dem Internet erreichbar, sondern über einen ADFS-Proxy veröffentlicht.

  1. Das externe Clientsystem fragt den DNS-Server des Internet DNS-Anbieters nach der IP-Adresse für adfs.granikoslabs.de und erhält die öffentliche IP-Adresse des ADFS-Proxy-Servers
  2. Der externe Client verbindet sich über den ADFS-Proxy-Server mit dem internen ADFS-Server, wird authentifiziert und kann, falls berechtigt, auf die gewünschte Office 365 Ressource zugreifen

Es ist wichtig, dass neben den individuellen Adressen für die benutzerdefinierte Domäne des Office 365-Tenant auch alle weiteren, von Microsoft bereitgestellten, öffentlichen Adressen für Office 365 auflösbar sein müssen. Die öffentlichen Office 365 Endpunkte werden über CNAME, SRV und TXT Einträge in der internen und externen DNS-Zone definiert. 

Die nachfolgende Liste gibt einen Überblick der DNS-Namen für den Office 365 Tenant mit der benutzerdefinierten Domäne granikoslabs.de.

Übersicht DNS-Einträge einer benutzerdefinierten Domäne in Office 365

Die vollständige Liste der erforderlichen DNS-Namen finden Sie in der Administrationsoberflache von Office 365. Für jede benutzerdefinierte Domäne sind separate Einträge in der jeweiligen DNS-Zone erforderlich, wenn diese Domäne zur Anmeldung an Office 365 und als E-Mail Domäne verwendet wird.

Grundsätzlich unterstützt Office 365 auch eine Konfiguration, bei der der Anmeldename nicht identisch mit der primäre SMTP-Adresse oder SIP-Adresse ist. Jedoch erhöht eine solche Konfiguration den Supportaufwand im Fehlerfall und führt zu einer verwirrenden Benutzererfahrung. Auf den unterschiedlichen Anmeldeseiten der Office 365 Dienste wird der Anwender mal aufgefordert, die E-Mail-Adresse oder den Anmeldenamen einzugeben. Gleichzeitig bietet eine solch individuelle Konfiguration keinerlei Vorteile hinsichtlich der IT-Sicherheit. Eine bessere Absicherung wird vielmehr durch den Einsatz einer Multi-Faktor-Authentifizierung und Zugriffsfilterung (Conditional Access) erreicht.

Viel Spaß mit Office 365!

 

 

Weiterlesen »
The English version of this post can be read here.

Für die Prüfung von gültigen E-Mail Absendern stehen unterschiedliche Technologien zur Verfügung. Jede für sich genommen stellt aber nur einen Baustein einer Gesamtlösung dar. Nach aktuellem Standard ist die Empfehlung, alle drei Technologien zu implementieren.

Die Technologien sind:

  • SPF - Sender Policy Framework
    Mit Hilfe des SPF Eintrages in einer DNS Zone wird beschrieben, welche Serversysteme befugt sind, E-Mails im Namen der Domäne zu versenden. Werden E-Mails unter verschiedenen Absendedomänen versendet, so muss für jede Absenderdomäne ein SPF Eintrag konfiguriert werden.
     
  • DKIM - Domain Keys Identified Mail
    DKIM verfolgt das gleiche Ziel wie SPF. Jedoch wird bei DKIM ein Teil der E-Mail Informationen mit einem privaten Schlüssel verschlüsselt. Der öffentliche Schlüssel wird über die DNS Zone des E-Mail Absenders bereitgestellt. Die Schlüsselerstellung erfolgt heutzutage in den meisten Fällen direkt im E-Mail Server, da dieser auch die Verschlüsselung der Nachrichten durchführt.
     
  • DMARC - Domain-based Message Authentication, Reporting & Conformance
    DMARC setzt auf SPF und DKIM auf. DMARC führt ein sog. Alignment für SPF und DKIM durch. Dieses Alignment beschreibt eine Richtlinie, die festlegt, wie streng ein empfangender Mail-Server die Absenderinformationen gegen SPF und DKIM prüfen bzw. bewerten soll. Stefan Cink hat hierzu einen ausführlichen Artikel im Net at Work Blog verfasst.

Das nachfolgende Schaubild verdeutlicht die Relation der Protokolle zu einander.

Relationen von DMARC, SPC und DKIM

Die Konfiguration von SPF, DKIM und DMARC ist kein Ersatz für E-Mail Nachrichtenverschlüsselung oder eine Transportverschlüsselung bei der E-Mail Übertragung. Vielmehr mehr dienen die genannten drei Technologien der Erkennung und Bewertung von gültigen Absendern und stellen einen Schutzmechanismus vor Spam dar.

Man darf nicht vergessen, dass die Konfiguration der drei Technoligen nur ein Angebot für andere E-Mail Server darstellt. Als Absender hat man schlicht keine Kontrolle darüber, ob und wie SPF, DKIM oder DMARC von der empfangenden Seite ausgewertet werden. Werden sie aber ausgewertet, so müssen die Konfigurationen korrekt und fehlerfrei sein und keine Testeinträge mehr enthalten.

Die nachfolgenden Abschnitte beschreiben insbesondere die DNS Konfiguration für SPF, DKIM und DMARC. Dieser Blogeintrag stellt keine detaillierte Bewertung der drei Technologien dar, sondern beschreibt deren Implementierung.

SPF

Für jede Domäne, die E-Mails versendet, ist ein SPF Eintrag (Resource Record) in der DNS Zone einzutragen. Ein SPF Eintrag ist immer vom Typ TXT und nutzt keinen Hostnamen (oder Resource Record Namen). Er gilt immer für die gesamte zu betrachtende Zone.

Beispiel

mcsmemail.de.          3600     IN      TXT     "v=spf1 mx a:mail.mcsmemail.de ?all"

Das nachfolgende Beispiel zeigt das Anlegen eines SPF TXT Eintrages in einer DNS Verwaltungsoberfläche eines Internet-Hosters. Das Textfeld für den Hostnamen bleibt leer.

Anlegen eines SPF TXT DNS Eintrages

Die im Beispiel verwendeten Einträge bedeuten:

v=spf1
Die SPF Version des Texteintrage

mx
Die in der DNS Zone konfigurierten MX Servereinträge für eingehende E-Mails sind valide Sender

a:mail.mcsmemail.de
Der in der DNS Zone existierende A Resource Record ist ebenfalls an valider Sender

?all
Neutrale Bewertung von nicht genannten Systemen, die ebenfalls E-Mails mit dieser Domäne senden

Die Erstellung der SPF Konfiguration erfolgt am einfachsten über einen der zahlreiche Online-Konfiguratoren. Diese werten bereits die aktuelle Konfiguration der DNS Zone aus.

DKIM

Bei einem DKIM Eintrag erfolgt die Konfiguration ebenfalls über einen TXT Eintrag in der DNS Zone der Absenderdomäne. Im Gegensatz zum SPF Eintrag ist ein Name für den Resource Record verpflichtend. Im Zusammenhang mit DKIM spricht man hier vom einem Selektor.

Ein DKIM DNS Eintrag erfolgt immer unterhalb der DNS Subdomäne _domainkey.

Beispiel

nsp._domainkey.mcsmemail.eu. 3600 IN     TXT     "v=DKIM1\; k=rsa\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQChZM8yjegaKfd0ssKyezTW/7xbDSNc0uPd50xa5/ecerv1v3mHKM+T7mClzRmIEx+Ji6AisVeo2uvjTYPemHFMBlQpuS/4zc2QxWHqp62FSQ7lASBOzDfUrIwayPVqwSPD6NrnfVSWoUNrFGGSVeU5uLASecBzTfxPukqTHgYKhQIDAQAB"

Das nachfolgende Beispiel zeigt das Anlegen eines DKIM TXT Eintrages in einer DNS Verwaltungsoberfläche eines Internet-Hosters. Das Textfeld für den Hostnamen enthält den Selektor nsp und die Subdomäne _domainkey.

Anlegen eines DKIM TXT DNS Eintrages

Die im Beispiel verwendeten Einträge bedeuten:

v=DKIM1
Die DKIM Version des DNS Eintrages

k=rsa
Verschlüsselungsmethode des öffentlichen Schlüssels

p=MIGfMA....
Der öffentliche Schlüssel des DKIM Schlüsselpaares

DMARC

Die Konfiguration von DMARC erfolgt ebenfalls über einen TXT Eintrag in der DNS Zone der absendenden Domäne. Für die Konfiguration wird der definierte Resource Record Name _dmarc verwendet.

Beispiel

_dmarc.mcsmemail.de.     3600    IN      TXT     "v=DMARC1\; p=none\; rua=mailto:DMARCRUA@mcsmemail.de\; ruf=mailto:DMARCRUF@mcsmemail.de\; fo=1\; adkim=s\; aspf=s\; rf=afrf\"

Das nachfolgende Beispiel zeigt das Anlegen eines DMARC TXT Eintrages in einer DNS Verwaltungsoberfläche eines Internet-Hosters. Das Textfeld für den Hostnamen enthält immer den Namen _dmarc.

Anlegen eines DMARC TXT DNS Eintrages

Die im Beispiel verwendeten Einträge bedeuten:

v=DMARC1
Die DMARC Version des DNS Eintrages

p=none
Keine definierte Policy für DMARC (Dies sollte immer das Startszenario sein, bevor man zu Quarantine oder Reject wechselt)

rua=mailto:DMARCRUA@mcscmemail.de
E-Mail Adresse für aggregierte Statusberichte

ruf=mailto:DMARCRUF@mcscmemail.de
E-Mail Adresse für Fehlerbericht

fo=1
Definition der Art des Fehlerberichtes

adkim=s
Definition DKIM Prüfung, s = strict

aspf=s
Definiton der SPF Prüfung, s = strict

rf=afrf
Nachrichtenformat des Fehlerberichtes, afrf = Abuse Report Format nach RFC 5965

Die Richtlinie (Policy, p) zur Auswertung und Reaktion sollte langsam gesteigert werden. Je Richtlinie sind die Ergebnisse wie folgt:

  • none - Keine Aktion, Betroffene Nachrichten werden nur im täglichen Bericht protokolliert
  • quarantine - Betroffene Nachrichten werden als Spam gekennzeichnet
  • reject - Die Nachricht wird auf SMTP Ebene zurückgewiesen

Sehr empfehlenswert zu diesem Thema ist ein Supportartikel von Google.

Für die Überprüfung der DNS Zoneneinträge kann das PowerShell Tool von Net at Work verwendet werden. Das PowerShell script kann nur mit NoSpamProxy 11 oder höher verwendet werden. Ebenso stehen zahlreiche Online-Tools zur Verfügung. Unten finden Sie direkt Verlinkungen zu den Tools von MXToolbox.

Links

 


Sichern Sie Ihre E-Mail Kommunikation mit PGP oder S/MIME und nutzen Sie sichere E-Mail Verschlüsselung am Gateway mit NoSpamProxy Encryption. E-Mail Security Made in Germany.
Wir beraten Sie gerne: info@granikos.eu
 

Weiterlesen »