shop high quality replique rolex.

discover the luxury rolex imitacion online watch store.

replica watches are the best qulity online.

swiss replica watches owns a high factor within throughout the world watch business sector.

richard mille fakes are the perfect mix between italian design and swiss technology at the service of the passion for the sea.


Granikos Technology Blog

Dies ist die deutschsprachige Version des Originalartikels Enabling Kerberos Authentication Fails vom 3. Juli 2017


Die Aktivierung der Kerberos Authentifizierung für Exchange Server 2013/2016 wird in diversen Artikeln im Internet beschrieben. In diesem Blogartikel geht es heute um ein Phänomen, das mir in einer Exchange Server 2013 Umgebung (8 Server DAG) begegnet ist. 

Alle Outlook 2010 Clients verwenden OutlookAnywhere für den Exchange Server Zugriff aus dem internen Netz. MAPI over Http ist sowohl auf der Organisationsebene als auch auf Postfachebene deaktiviert, da noch ein Problem mit der Kompatibilität einer Drittanbietersoftware existiert.


Nach der Aktivierung der Kerberos Authentifizierung verwenden alle Outlook Clients weiterhin nur die NTLM Authentifizierung, um sich am OutlookAnywhere Endpunkt anzumelden. Und dies, obwohl die Schritt-für-Schritt Anleitung aus dem TechNet befolgt wurde. Kerberos war für die Outlook Clients kein Thema. 

Ein Blick in die Übersicht des Outlook Verbindungsstatus (Strg + Rechter Mausklick auf des Outllok Symbol im System Tray) zeigt die Verwendung von NTLM.

Outlook nutzt weiterhin NTLM als Authentifizierungsanbieter


Die Umstellung der Authentifizerung auf Kerberos für OutlookAnywhere erfolgt auf jedem CAS Server über das folgende PowerShell Cmdlet:

Get-OutlookAnywhere -Server CASSERVER | Set-OutlookAnywhere -InternalClientAuthenticationMethod  Negotiate

Alle acht Exchange 2013 Server boten auch nach gebotener Zeit keine Nego Authentifizierung an. Die Überprüfung der OutlookAnywhere Konfiguration mit Hilfe der PowerShell zeigte die korrekten Konfigurationswerte. Aber was nun?

Ein Kontrolle der Authentifizerungseinstellungen für das \Rpc virtuelle Verzeichnis der Front End Website in der IIS Management Console zeigte, dass das virtuelle Verzeichnis nur für NTLM konfiguriert war.

OutlookAnywhere im Front End verwendet nur NTLM



Mit Hilfe der IIS Management Console wurde der Negotiate Authentifizierungsanbieter hinzugefügt in der Reihenfolge der Anbieter an die erste Stelle gesetzt..

Negotiate zur Anbieterliste hinzufügen

Negotiate als ersten Anbieter konfigurieren

Nach Anpassung der Authentifizierungsanbieter in der Front End Wesbite können sich Outlook Clients mit Kerberos Authentifizerung an den OutlookAnywhere Endpunkt verbinden.

Outlook Verbindungsstatus zeigt Negotiate als Authentifizierungsanbieter


Im Normalfall sollte die IIS Management Console nicht für die Konfiguration der virtuellen Verzeichnisse einer Exchange Server INstallation verwendet werden. Die Anpassung der Konfigurationen mit Hilfe IIS MMC sollte nur im Troubleshooting-Fall verwendet werden, wenn einem unerklärliche Phänomene begegnen.

Die bevorzugte Methode zur Konfiguration von Exchange Server Einstellungen für virtuelle Verzeichnisse ist die Exchange Management Shell.


Weiterhin viel Spaß mit Exchange Server



Weiterlesen »

Exchange Server 2007 Exchange Server 2010 Exchange Server 2013 Exchange Server 2016Microsoft hat die Exchange Updates für das 4. Quartal 2016 veröffentlicht.

Für den Betrieb von Exchange Server 2016 auf Windows Server 2016 wurde ein Knowledge Base Artikel veröffentlicht. Bei einer Installation von Exchenge auf Windows Server 2016 ist die Installation des Fixes zwingend. Das Setup wird ohne die Installation des Fixes nicht fortfahren.

Der Einsatz von .NET Framework 4.6.2 ist für die Q4 2016 Cumulative Updates noch optional, jedoch dringend empfohlen. Für die kommenden Cumulative Updates wird das .NET Framework 4.6.2 allerdings verpflichtend sein.

Die einzelnen Updates für Exchange:

Bei einem Hybrid Betrieb mit Office 365 und Exchange Server 2013/2016 muss entweder das jeweils das aktuelle CU oder nur das vorherige CU installiert sein. Dies entspricht dem N-1 Ansatz.

Für einen reinen On-Premises Betrieb von Exchange Server 2013/2016 gilt N-2. Es wird jeweils das aktuelle CU und die beiden letzten Vorversionen unterstützt.




Weiterlesen »
On September 14, 2016
This is a translated blog post of the original post in German, which can be read here.

Different technologies are used to verify the validity of email senders. Each technology by itself represents only one component of a holistic solution. It is currently recommended to implement all three technologies.

The technologies are:

  • SPF - Sender Policy Framework
    The SPF resource record of a DNS zone defines which servers (hostnames or IP addresses) are allowed to send emails on behalf of the domain. Each sender domain must have it's own SPF resource record.
  • DKIM - Domain Keys Identified Mail
    DKIM pursues the same objective as SPF. With DKIM parts of an email, messages are encrypted using a private key. The public key is published as a DNS resource record. In most cases, the key pair is generated by the mail servers, as these encrypt the message anyway.
  • DMARC - Domain-based Message Authentication, Reporting & Conformance
    DMARC is placed on top of SPF and DKIM. DMARC executes a so-called alignment for SPF and DKIM. An alignment defines a policy that describes how strict a receiving server (MTA) should validate and assess the sender address with SPF and DKIM. Stefan Cink of Net at Work has published a detailed post (DE) on this.


The following figure illustrates the protocol relations.

DMARC, SPC and DKIM relations

The use of SPF, DKIM, and DMARC are no substitute for email message encryption itself or transport encryption. These technologies are used to identify and asses valid senders and to protect against spam messages.

Keep in mind that SPF, DKIM, and DMARC are offerings for other emails servers. As a sending party, you do not control if and how SPF, DKIM, and DMARC are evaluated by the receiving server. But if evaluated, the configuration must be correct to avoid messages being rejected by receiving email servers.

The following sections focus on the DNS configuration for SPF, DKIM, and DMARC. This post is not intended to rate the technologies, but to describe the implementation.



Each domain is used for sending emails requires an SPF resource record (RR) in its DNS zone. An SPF record is always of the type TXT and does not use any hostname (or resource record name, if you will). An SPF RR is always valid for the entire DNS zone.

Example          3600     IN      TXT     "v=spf1 mx ?all"

The following screenshot illustrates adding a new SPF TXT record in a common DNS management interface (DE) of an internet provider. The hostname textbox remains empty.

Anlegen eines SPF TXT DNS Eintrages

Example explained:

SPF Version

MX server records defined within the DNS zone are valid senders
The additional DNS hostname defined as A resource record is a valid sender as well

Neutral validation of non listed servers that send emails for this domain

SPF records can be created by using one of the various online resources.



DKIM resource records are configured as TXT resource records as well. In contrast to an SPF record, a hostname is mandatory. In this case its called selector.

A DKIM TXT record is always created as a record in the subdomain _domainkey.

Example 3600 IN     TXT     "v=DKIM1\; k=rsa\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQChZM8yjegaKfd0ssKyezTW/7xbDSNc0uPd50xa5/ecerv1v3mHKM+T7mClzRmIEx+Ji6AisVeo2uvjTYPemHFMBlQpuS/4zc2QxWHqp62FSQ7lASBOzDfUrIwayPVqwSPD6NrnfVSWoUNrFGGSVeU5uLASecBzTfxPukqTHgYKhQIDAQAB"

The following screenshot illustrates adding a new DKIM TXT record in a common DNS management interface (DE) of an internet provider. The hostname textbox contains the selector nsp followed by the subdomain _domainkey.

Anlegen eines DKIM TXT DNS Eintrages

Example explained:

DKIM version

Public key encryption method

The DKIM public key



DMARC is configured as a TXT resource record as well. The DMARC resource record uses the fixed hostname _dmarc.

Example     3600    IN      TXT     "v=DMARC1\; p=none\;\;\; fo=1\; adkim=s\; aspf=s\; rf=afrf\"

The following screenshot illustrates adding a new DMARC TXT record in a common DNS management interface (DE) of an internet provider. The hostname textbox contains always the value _dmarc.

Anlegen eines DMARC TXT DNS Eintrages

Example explained:

DMARC version

No DMARC policy defined (You should always start with None, before switching to Quarantine or Reject)
Email address for status reports
Email address for error reports

Error report type

DKIM alignment, s = strict

SPF alignment, s = strict

Error report message format, afrf = Abuse Report Format following RFC 5965

The DMARC policy (p) should be raised step-by-step. The results for each policy type are:

  • none - No action, affected messages are part of the daily message report
  • quarantine - Affected messages are marked as spam
  • reject - An affected message is rejected on the SMTP layer

Recommended reading on this topic: Google Support Post.

DMARC DNS zone entries can easily be checked by using the Net at Works PowerShell tool. The PowerShell script can only be used with NoSpamProxy11+. But there are some online tools available as well.



Do you need assistance with your Exchange Server setup? You have questions about your Exchange Server infrastructure and going hybrid with Office 365?

Contact us at or visit our website


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.


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          3600     IN      TXT     "v=spf1 mx ?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:

Die SPF Version des Texteintrage

Die in der DNS Zone konfigurierten MX Servereinträge für eingehende E-Mails sind valide Sender
Der in der DNS Zone existierende A Resource Record ist ebenfalls an valider Sender

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.


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 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:

Die DKIM Version des DNS Eintrages

Verschlüsselungsmethode des öffentlichen Schlüssels

Der öffentliche Schlüssel des DKIM Schlüsselpaares


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     3600    IN      TXT     "v=DMARC1\; p=none\;\;\; 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:

Die DMARC Version des DNS Eintrages

Keine definierte Policy für DMARC (Dies sollte immer das Startszenario sein, bevor man zu Quarantine oder Reject wechselt)
E-Mail Adresse für aggregierte Statusberichte
E-Mail Adresse für Fehlerbericht

Definition der Art des Fehlerberichtes

Definition DKIM Prüfung, s = strict

Definiton der SPF Prüfung, s = strict

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.



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:

Weiterlesen »


De-Mail ist Bestandteil der E-Government-2.0 Strategie Deutschlands und ist eine vom Bundesamt für Sicherheit in der Informationstechnik (BSI) zertifizierte Technik zur sicheren, vertraulichen und nachweisbaren E-Mail Kommunikation.

Eine komfortable Anbindung an die De-Mail Infrastruktur ist mit Hilfe der E-Mail Gateway Lösung NoSpamProxy Encryption möglich. Für eine Anbindung an die E-Mail Systeme eines Unternehmens muss eine De-Mail Gateway Kommunikation eingerichtet werden. Die Nutzung von De-Mail in dieserm Szenario erfordert den Einsatz einer Signaturkarte, was für die Anbindung an eine serverbasierte Softwarelösung ganz eigene Herausforderungen mit sich bringt.

Im nachfolgenden Artikel wird die Anbindung exemplarisch für die T-Systems De-Mail Schnittstelle unter Verwendung von NoSpamProxy Encryption beschrieben. Die von T-Systems zur Verfügung gestellte Gateway-Lösung wird hierzu nicht benötigt. Die NoSpamProxy Encryption Gateway Rolle ist in diesem Beispiel bereits auf dem Windows Server 2012R2 System installiert.


Lesegeräte für Signaturkarten sind mit einer USB Schnittstelle ausgestattet. Bei direkter Nutzung einer hardwarebasierten Serverlösung stellt dies kein Problem dar, da der Kartenleser direkt am Server angeschlossen werden kann.

In einer virtualisierten Serverinfrastruktur muss der USB Kartenleser mit Hilfe eines USB Servers dem Betriebssystem zur Verfügung gestellt werden. Hier gibt es unterschiedliche Produkte am Markt. T-System empfiehlt hier das SoHo Produkt myUTN-50a der Fa. SEH. Am Markt existieren auch industrietaugliche Alternativen.

Als Kartenlesen empfiehlt und verkauft T-Systems den SCR3310 (lt. Herstellt End of Life), der auch in diesem Beispiel verwendet wird.


  • Da die PIN Nutzung durch die Software erfolgt, darf kein Kartenleser mit eigener Tastatur verwendet werden.
  • Jeder Gateway Server erfordert einen eigenen Kartenleser und eine dedizierte Smartcard.


Die Installation aller Smartcard Komponenten muss über die Konsole erfolgen. Eine Installation über eine RDP Verbindung (auch RDP Konsole) führt zu einer fehlerhaften Installation der Smartcard Komponenten.

1. Einrichtung und Installation USB Server

Für den USB Server ist die Verwendung einer dedizierten und fest konfigurierten IP-Adresse einer Zuweisung per DHCP vorzuziehen. Nach der Einrichtung muss der USB Server mit Hilfe der zugehörigen Verwaltungssoftware erreichbar sein und die USB Ports müssen im Gastbetriebssystem eingebunden werden. Die korrekte Einbindung kann im Gerätemanager kontrolliert werden.

Wichtig ist, dass die Einbindung des USB-Servers als „Autostart“ konfiguriert ist, damit der USB-Server beim Start des Betriebssystems automatisch verbunden wird.

Konfiguration AutoStart (exemplarisch)

2. Installation Smartcard-Kartenleser (SCR3311)

Die Installation der Treibersoftware für den Kartenleser SCR3311 ist einfach, da es sich um eine simple Windows-Installer Lösung handelt. Nach der Installation muss der Kartenleser im Gerätemanager sichtbar sein und als korrekt installiert angezeigt werden.

3. Installation Smartcard

Für den Zugriff auf die Smartcard muss der Treiber für das TCOS (TeleSec Chipcard Operating System) installiert werden. Hier ist TCOS Cardmodul Treiber für die manuelle Installation zu verwenden. Nach dem Entpacken des gezippten Archivs erfolgt die Installation (Treiber Update) mit Hilfe des Gerätemanagers. Nach der Installation muss die Smartcard im Gerätemanager sichtbar sein und als korrekt installiert angezeigt werden.

Smartcard Leser und Smartcard im Gerätemanager

4. Installation CardManager

Für die Registrierung der auf der Smartcard gespeicherten Zertifikate muss die TCOS CardManager Software installiert werden. Auch hier ist die Installation einfach, da es sich um eine simple Windows-Installer Lösung handelt.


Nachdem alle Komponenten korrekt installiert sind, können die Zertifikate auf dem Server registriert und mit Hilfe eines Tools im Zertifikatsspeicher des Servers zur Nutzung bereitgestellt werden.

1. Registrierung Zertifikate

Starten Sie den TeleSec CardManager und wählen Sie die den Knoten Personalisierung -> Zertifikate und registrieren Sie alle Zertifikate.

Registrierung der Zertifikate im CardManager

2. Promoten der Zertifikate

Nach der Registrierung müssen die registrierten Zertifikate in den lokalen Zertifikatspeicher promotet werden, damit die Software mit den Zertifikaten arbeiten kann.

Starten Sie die CertificatePromoter.exe und wählen Sie alle registrierten Zertifikate. Klicken Sie anschließend auf Ok und starten Sie anschließend den Server durch.

Registrierte Zertifikate promoten

Wichtig ist, dass nach der Bereitstellung der Zertifikate mindestens das Zertifikat für Client Authentication, Smart Card Logon im Zertifikatsspeicher aufgeführt wird.

Übersicht der Zertifikate im Zertifikatesspeicher

In der Anzeige der Zertifikatsdetails können die erweiterten Nutzungsarten angezeigt werden:


3. De-Mail Konnektor

Nachdem nun die Zertifikate korrekt im lokalen Zertifikatsspeicher verfügbar sind, kann der NoSpamProxy De-Mail Konnektor in der NoSpamProxy Verwaltungskonsole konfiguriert werden.

Vergeben Sie einen Namen für den Konnektor und wählen Sie T-System als Ziel aus. Anschließend wählen Sie das zu verwendete Zertifikat aus.

Konfiguration De-Mail Connector

Im Auswahldialog für das Zertifikat werden alle Zertifikate angezeigt, die auf den verbundenen NoSpamProxy Gateway Systemen im lokalen Zertifikatsspeicher zur Verfügung stehen. Werden in diesem Dialog die De-Mail Zertifikate nicht angezeigt, müssen die Konfigurationsschritte zur Einbindung der Zertifikate überprüft werden.

Überprüfen Sie anhand der Zertifikate-Detailanzeige das zu verwendende Zertifikat (s.o.) und wählen es anschließend aus.

De-Mail Zertifikatauswahl

Für jedes Gateway-System muss ein separater Konnektor erstellt werden.

Nach der Einrichtung des Konnektors und der erfolgreichen Verbindung zum T-System De-Mail Server werden in der NoSpamProxy Verwaltungskonsole die zur Verfügung stehenden De-Mail Domänen angezeigt. Damit wurde die De-Mail Anbindung mit NoSpamProxy Protection eingerichtet.

Nach der rein technischen Anbindung des Unternehmens an De-Mail, muss De-Mail in Ihre Fachverfahren nach Ihren Wünschen und Anforderungen integriert werden. Dies erfordert eine ganz individuelle Beratung und Umsetzung.



Viel Spaß mit De-Mail.



Weiterlesen »