de-DEen-GB
rss

Granikos Technology Blog

Hinweis: Das folgende Beispiel ist keine Fiktion. Die beschriebenen Systeme und die Betriebssituation sind Realität.
Dieser Artikel zeigt nicht die endgültige Lösung für die ungünstige Betriebssituation auf, da eine optimale Lösung mit Investionen und Umbauten verbunden ist.


Edison Bulb Das Thema "ungünstiger Exchange Server Implementierungen" scheint in seiner Vielfalt unerschöpflich. Leider ist Exchange Server, auch in der aktuellen Version 2019, ein sehr tolerantes Produkt, wenn es um die Installation und den Erstbetrieb geht. Die eigentlichen Probleme und Fehler einer schlechten Exchange Server Implementierung treten erst nach einer gewissen Betriebszeit in Erscheinung.  Ähnlich sieht es aus, wenn nach einer IT-Störung notwendige Wiederherstellungsschritte ausgelassen oder unbedacht ausgeführt werden. 

Heute möchte ich mit Ihnen folgendes Beispiel teilen, bei dem einige Informationen auf Annahmen basieren, da von Kundenseite nicht alle Fragen beantwortet wurden bzw.  beantwortet werden konnten. 

 

Ausgangssituation

In der lokal installierten Exchange Server Plattform treten Performance-Probleme mit der Nachrichtenzustellung im Outlook-Client auf. Nach Aussage des Kunden erfolgt die Zustellung eingehener Nachrichten mit einer bis zu 60-minütigen Verzögerung. 

Diese Beschreibung erscheint auf den ersten Blick auf einen einfach zu lösenden Fehler hinzudeuten. Bei genauer Betrachtung zeigt sich aber, dass es sich um ein schwerwiegendes Problem innerhalb der Exchange Server-Plattform handelt.

Im Vorfeld wurde, so die Aussage des Kunden, die IT-Infrastruktur durch eine Krypto-Attacke kompromittiert. Im Rahmen der ausgeführten Wiederherstellungsmassnahmen wurde, so der Anschein, ein Domain Controller auf einen älteren Stand zurückgesetzt. Zu dieser Maßnahme fehlen leider detaillierte Informationen. 

 

Fakten

Laut Active Directory Konfigurationspartition besteht die Exchange Server Organisation aus insgesamt 11 Exchange Server Systemen, die sich wie folgt aufteilen:

  • 6 Exchange Server 2010 SP3
    • 3 Systeme mit Mailbox-Rolle
      30 Postfachdatenbanken
    • 3 Systeme mit kombinierter CAS- und Hub-Transport-Rolle
       
  • 5 Exchange Server 2016 mit CU12
    • 2 Systeme mit produktiv eingebunden Postfachdatenbanken in einer DAG mit ca. 40 Postfachdatenbanken
    • 3 Systeme ohne produktiv eingebundene Postfachdatenbanken
       
  • 2 konfigurierte Datenbankverfügbarkeitsgruppen (DAG)

 

In der Realität der Serverlandschaft in der lokalen IT-Infrastruktur sieht es allerdings anders aus:

  • Exchange Server 2010 Systeme sind nicht mehr vorhanden
  • Keine Aussage, ob Exchange Server 2010 auf diesen sechs Systemen deinstalliert wurde oder ob die Systeme einfach gelöscht wurden
  • Migration von Exchange Server 2010 zu Exchange Server 2016 gilt beim Kunden offiziell als abgeschlossen

 

Der Unterschied zwischen Active Directory Konfigurationspartition und der aktuellen Realität der IT-Infrastruktur resultiert höchstwahrscheinlich aus einer übereilten authoritativen Wiederherstellung des Active Directory nach der bereits erwähnten Krypto-Attacke. Hierdurch wurde, falls durchgeführt, ebenfalls eine stark veraltete Konfiguration der Exchange Organisation wiederhergestellt.

 

Die Ressourcen der aktuell betriebenen beiden Exchange Server 2016 Systeme:

  • 12 vCores
  • 16 GB Arbeitsspeicher
  • Bereitstellung des Datenspeichers per iSCSI von einem QNAP NAS

Weitere Fakten:

  • Selbstsignierte Exchange Server Zertiifkate für Frontend-Dienste
  • Unterschiedliche Konfiguration je Exchange Server
  • ~100 Transportregeln mit CC-Ergänzungen für die Zustellung an weitere Mitarbeiter
  • Endpunkt-Sicherheitslösung ohne Konfiguration von Exchange Server-Ausnahmen

 

Fazit

In der beschriebene Exchange Server Plattform kommen unterschiedliche Probleme zusammen. Das beschriebene Fehlerbild der verzögerten Nachrichtenzustellung hängt weniger mit der eklatante Fehlkonfiguration der Exchange Organisation zusammen, als mit dem schlechten Aufbau der IT-Hardware. Hier kommen mehrere Punkte zusammen:

  • Die Einbindung der Volumes per iSCSI über die allgemeine Netzwerkinfrastruktur führt zu einer schlechten Disk I/O Performance
  • Die Nutzung von 40 Exchange-Postfachdatenbanken per iSCSI über den gleichen iSCSI Endpunkt verschlechtert die Disk I/O Performance nochmals
  • Das Verhältnis von verfügbarer Prozessorleistung und Arbeitsspeicher der Exchange Server 2016 Systeme ist unüberlegt konfiguriert
  • Der Arbeitsspeicher ist für die Einbindung von 40 Postfachdatenbanken viel zu gering
    • Bei einer guten Datenbankverteilung innerhalb der DAG und Einbindung von 20 aktiven Postfachdatenbankkopien je DAG-Mitgliedsserver ist der Arbeitsspeicher bereits zu gering
    • Bei einer Aktivierung aller Datenbankkopien auf einem Exchange Server im Fehlerfall steht nicht ausreichend Arbeitsspeicher zur Verfügung

Die Probleme hinsichtlich der Leistungsdefizite der beiden Exchange Server 2016 Systeme hätten bereits im Vorfeld mit einer einfachen Systemüberwachung des Betriebssystems erkannt werden können. Bei der Konfiguration des Arbeitsspeicher für die Systeme standen die Einschränkungen der Hypervisor-Hostsysteme im Vordergrund. Die realen Anforderungen von Betriebssystem, Exchange Server 2016, Endpunkt-Sicherheitslösung und anderer installierter Komponenten, fanden keinen Anwendung. Insbesondere wurden auch die internen Anforderungen von Exchange Server 2016 beim Betrieb einer DAG, in Kombination mit der Managed Availability, nicht berücksichtigt. 

Mit dieser Hardware-Konfiguration kann der Programmcode von Exchange Server nicht korrekt arbeiten. Die im Verhältnis recht hohe Zahl an vorhandenen Prozessorkernen führt nicht zu einer Beschleunigung von Exchange Server. Da gleichzeitig nicht genug freier Arbeitsspeicher zur Verfügung steht und die Disk I/O-Leistung zu gering ist, kommt es zwangsläufig zu einer verzögerten Ausführung des Codes und damit automatisch zu einer verzögerten Verarbeitung von Nachrichten.

Für diese Hardware-Plattform sind zu viele iSCSI-Volumes in Betrieb und zu viele Postfachdatenbanken je Server eingebunden. Bei 40 Datenbanken mit je einer aktiven und einer passiven Kopie werden insgesamt 80 Datenbankkopien auf den iSCSI-Zielen betrieben. Trotz der starken Reduzierung der Disk I/O-Anforderungen in Exchange Server 2016, im Vergleich zu den Vorversionen, kann ein iSCSI-NAS die permanent erforderliche Leistung nicht liefern. Für ein Caching von Postfachinformationen steht nicht genug Arbeitsspeicher zur Verfügung. Exchange Server muss die Daten direkt auf Disk schreiben, um die Daten sicher zu persistieren. 

Die fehlerhafte Konfiguration der Exchange Organisation im Active Directory trägt ihren ganz eigenen Teil zu den Problemen bei. Diese Konfiguration wird von allen Exchange Servern gelesen und für weitere Aktionen verwendet. Einige dieser Aktionen, die jeder einzelne, in Betrieb befindliche, Exchange Server durchführt, sind:

  • Regelmäßiger Test der Kommunikationsverbindungen (http https, etc.) zu den anderen Exchange Servern, die in der Konfiguration der Exchange Organisation vorhanden sind
    • Funktionstest zu anderen Mitgliedsservern der gleichen DAG
    • Funktionstest der Erreichbarkeit von Exchange Servern außerhalb der DAG
  • Versand von Test-Nachrichten zwischen allen aktiven Postfachdatenbanken einer DAG
    • Funktionstest der E-Mail-Zustellung
    • Funktionstest der Suchindizierung
    • Funktionstest der Client-Protokolle
  • Prüfung auf fehlende Kalendereinträge in jedem Postfach

Exchange Server besteht aus viel mehr als nur der Verarbeitung von individuellen eingehende und ausgehenden Nachrichten. Die Funktion der Managed Availability nimmt einen nicht unerheblichen Teil des Leistungsbedarfs eines Exchange Servers in Anspruch. Exchange Server ist dafür ausgelegt, eine hochverfügbare Messaging-Plattform bereitzustellen. Hierzu dienen all die Funktionen, die unter der Haube ablaufen. Neben den Anforderungen an die Systemleistung von CPU und Arbeitsspeicher, schreiben alle Exchange Server Komponenten Protokolldateien auf Disk. Dies wird gerne ebenfalls vernachlässigt. 

Die in der Active Directory Konfigurationspartition vorhandenen Exchange Server 2010 Systeme sind als Computerobjekte nicht mehr vorhanden. Dies deutet darauf hin, dass die Wiederherstellung der authoritativen AD-Datensicherung Ursache des Fehlers ist. Alternativ ist es auch möglich, dass diese Situation durch eine "Ad-Hoc-Deinstallation" von Exchange Server aus dem Active Directory eingetreten ist. Unter einer "Ad-Hoc-Deinstallation" versteht man das unmittelbare Löschen des AD-Computerobjektes eines Servers, auf dem Exchange Server installiert ist. Diese Art der "Deinstallation" von Exchange Server führt automatisch zu verwaisten Einträgen in der Konfigurationspartition und damit zu Folgeproblemen beim Betrieb der Exchange Organisation. 

Führen Sie unter keinen Umständen eine "Ad-Hoc-Deinstallation" von Exchange Server durch.

 

Die Fehlersituation in der Exchange Server-Plattform bei diesem Kunden ist noch nicht abschließend gelöst. Die optimale Lösung erfordert zum einen die Bereinigung des Active Directory und zum anderen einen Umbau der Exchange Server Infrastruktur. Dies ist jedoch mit Investitionen verbunden.

 

Links

 

Dieses Beispiel ist eine Ergänzung zu den in meinem Buch "Exchange Server 2019 - Das Handbuch für Administratoren" beschriebenen Beispielen ungünstiger Exchange Server Implementierungen

Ich wünsche Ihnen viel Spaß und gute Laune mit Exchange Server.

 


Image by Pexels

Weiterlesen »

Logo Microsoft Teams Meetup Berlin

Am 18. Juni 2019 trifft sich die Microsoft Teams Meetup Gruppe Berlin zu ihrem vierten Treffen.

Bei unseren Meetup-Treffen sprechen wir über Microsoft Teams als universelle Plattform zur Zusammenarbeit als Teil einer Modern Workplace Strategie. Hierzu gehören das Teilen und gemeinsame Arbeiten an Dokumenten, Audio- und Video-Kommunikation, Telefonie und die Erweiterbarkeit durch Applikation, Bots und weitere Schnittstellen.

 

Agenda

  • Microsoft Teams als Entwicklungsplattform für Unternehmensanwendungen
  • Neuigkeiten rund um Microsoft Teams
  • Entwicklung von Erweiterungen für Microsoft Teams

 

Termin

 

Sie haben ein interessantes Thema oder eine Produktlösung für Microsoft Teams, die Sie auf einem unserer Meetups vorstellen möchten? Melden Sie sich bei mir: thomas.stensitzki@granikos.eu. Ich freue mich über Ihre Nachricht.

 

Links

 

Viel Spaß mit Microsoft Teams!

 

Weiterlesen »

Photo by Max DeRoin from PexelsDas Blog Cumulative Update für Mai 2019 (CU0519) fasst interessante Themen rund um Cloud SicherheitExchange ServerOffice 365, Azure und Skype for Business des Monats Mai 2019 zusammen.

Exchange Server

Microsoft 365 | OneDrive | Exchange Online | and more

Microsoft Teams

Skype for Business Server | Communications

Microsoft Azure

Cloud | Cloud Sicherheit

Docs | Knowledge Base | TechNet

Allgemein

Replay

Podcast Empfehlungen

Tools

 


Gerne unterstützen wir Sie bei der Planung und Durchführung Ihrer Exchange Server Implementierung oder Migration.

Sie denken über einen vollständigen Wechsel zu Office 365 oder eine Hybrid-Konfiguration mit Office 365 nach? Wir beraten Sie umfassend und neutral über die Möglichkeiten der Office 365 Plattform und Microsoft 365.

Sie möchten mehr über Exchange Server 2019 erfahren? Wir empfehlen das Standardwerk zu Exchange Server 2019 von Thomas Stensitzki "Exchange Server 2019 - Das Handbuch für Administratoren".

Weitere Informationen zu unseren Dienstleistungen finden Sie auf unserer Website (https://www.granikos.eu) oder Sie kontaktieren direkt unser Vertriebsteam: info@granikos.eu

 

Weiterlesen »

Identitätsmodelle

Office 365 unterstützt grundsätzlich drei unterschiedliche Modelle von Benutzeridentitäten, kurz Identitäten, für die Authentifizierung. Ohne eine erfolgreiche Authentifizierung ist eine Nutzung der zugewiesen Produkte und Dienste nicht möglich. Sie müssen sich für mindestens eine der drei Indentitätsmodelle entscheiden.

Die drei unterstützten Formen der Identität sind

  • Cloud-Identität
    Bei dieser Identität gibt es keine Verbindung zu einem möglicherweise vorhanden Benutzerkonto im lokalen Active Directory. Die Verwaltung erfolgt vollständig in Office 365. Ebenso erfolgt die Authentifizierung durch Azue Active Directory (Azure AD) in der Cloud.
     
  • Synchronisierte Identität
    Bei dieser Identität erfolgt eine Synchronisierung von Active Directory Benutzerobjekten und dem jeweiligen Kennwort-Hash. Auf Basis des synchronisierten Kennwort-Hashes erfolgt eine Authentifizierung durch Azure AD. 
    Synchronisierte Identitäten existieren in Azure AD parallel zu vorhandenen Cloud-Identitäten.
     
  • Föderierte Identität - auch als Verbundidentität bezeichnet
    Diese Form der Identität ist eine Sonderform der synchronisierten Identität. Es erfolgt keine Synchronisierung der Kennwort-Hashes. Die Authentifizierung erfolgt durch Komponenten, die zusätzlich in der lokalen IT-Infrastruktur bereitgestellt werden müssen.
    Föderierte Identitäten existieren in Azure parallel zu vorhanden synchronisierten und Cloud-Identitäten.

 

Das folgende Schaubild verdeutlicht die Unterschiede der drei Identitätsmodelle.

Office 365 - Identitätsmodelle

 

Authentifizierung

Die Authentifizierung von synchronisierten Benutzerkonten aus dem lokalen Active Directory mit Azure AD sind drei unterschiedliche Authentifizierungsmethoden möglich.

Die drei Methoden sind:

  • Kennwortsynchronisierung
    • Hierbei werden Kennwort-Hashes über AAD Connect zu Azure AD synchronisiert
    • Mit Self-Password-Reset können Benutzer ihr Kennwort in Azure AD ändern und mit aktiviertem Password-WriteBack wird die Änderung ins lokale AD zurückgeschrieben
    • Neben einem System, auf dem AAD Connect installiert ist, sind keine weiteren Systeme in der lokalen IT-Infrastruktur -Premises erforderlich

 

  • Federation Services
    • Hierbei werden in der IT-Infrastruktur sog. Federation Server und, für den Zugriff aus dem Internet, Reverse Proxy Systeme im Perimeter-Netzwerk installiert
    • Mögliche Federation Software-Lösungen:
      • ADFS, Ping Federate, Shibboleth, u.a.
    • Neben einem System für AAD Connect werden zusätzliche Serversysteme benötigt
      Beispiel für ADFS
      • Minimum: 1x ADFS im LAN, 1x ADFS-Proxy im Perimeter-Netzwerk
      • Redundanz: 2x ADFS im LAN, 2x ADFS-Proxy im Perimeter-Netzwerk
    • Mit einer Federation-Implementierung können weitere Applikationen, zusätzlich zu Office 365, mit einer föderierten SSO-Anmeldung angebunden werden
      • Intern: z.B. Jira, Intranet, u.a.
      • Extern: z.B. Hosted SAP, u.a. 
    • Zusätzlich wird mindestens eine öffentliche IP-Adresse und eingehende HTTPS-Verbindungen benötigt
    • Hinweis:
      • Normalerweise werden Federation Services eingeführt, um KEINE Kennwort-Hashes mit Azure AD zu synchronisieren
      • MIT synchronisierten Kennwort-Hashes, ist ein längerer Ausfall der Federation Server leicht kompensierbar, da die UPN-Domäne in Office 365 nur von "federated" auf "standard" umgestellt werden muss

 

  • Azure AD Connect Pass-through
    • Hierbei wird auf mindestens einem internem System (Domain Member) der Azure AD Connect Pass-through-Agent installiert
    • Der Agent baut eine ausgehende Verbindung zu Azure AD auf
    • Ein höhere Verfügbarkeit wird durch die Installation mehrerer Azure AD Connect Pass-through-Agenten erreicht
    • Der Agent kann auf bestehenden Systemen installiert werden
    • Eine SSO-Anbindungen ist für interne Applikation nur u.U. möglich. 

 

Hinsichtlich der Vor- und Nachteile dieser drei Optionen müssen Sie Ihre Anwendungsszenarien kennen. Alle drei Methoden haben ganz unterschiedliche Anforderungen. Gerade im Hinblick auf gewünschte SSO-Anbindungen von Lösungen jenseits von Office 365 (Azure AD) fallen eventuell einzelne Optionen weg.

Es dürfen aber nicht nur die Authentifizierungsart und die Applikationen betrachtet werden. Die verwendeten Clients (Desktop OS, Mobile OS, Applikationen) müssen für die ausgewählte Authentifizierungsart geeignet sein. Idealerweise sind natürlich Windows 10 und Office 2016/2019 oder Office 365 ProPlus im Einsatz. Ältere Softwarekomponenten müssen Sie separat evaluieren.

 

Links

 

Viel Spaß mit Microsoft 365 und Azure AD.

 

Weiterlesen »

Microsoft Teams LogoMicrosoft Teams bietet zahlreiche Möglichkeiten zur Konfiguration und Kontrolle der Sicherheits- und Complianceeinstellungen. Matt Soseman, Security Architekt bei Microsoft, hat zum Thema Security & Compliance in Microsoft Teams eine Youtube Playlist erstellt.

Hier ist eine Übersicht der wichtigsten Videos:

How do I secure access to Microsoft Teams and ensure only authorized individuals can use the tool? Join us as we explore how Azure Active Directory Conditional Access and Identity Protection can provide a new level of security for Microsoft Teams.

How do I enforce policy to ensure my users cannot share sensitive data in a Microsoft Teams private chat or channel conversation? Join us as we explore how Office 365 Data Loss Prevention can block users from sharing sensitive data in Microsoft Teams – and be alerted when a violation occurs!

How do I enforce policy to ensure my users cannot copy/paste or download sensitive data out of Microsoft Teams and into a non-approved application/website? Join us as we explore how Windows Information Protection can help enforce compliance and ensure corporate data stays within Microsoft Teams or approved applications.

How do I enforce policy when a user accesses Microsoft Teams from a personal (non-managed) computer? Join us as we explore how Microsoft Cloud App Security and Azure Active Directory Conditional Access can block downloads of files in Microsoft Teams to a non-managed computer.

How can I protect my end users from malicious files that are uploaded to Microsoft Teams? Join us as we explore how the Office 365 Advanced Threat Protection Safe Attachments feature detonates files uploaded to Microsoft Teams and blocks those files from being executed.

How can I protect the Microsoft Teams app when used on a non-managed personal smartphone? Join us as we explore how Microsoft Intune Mobile Application Management capabilities allow you to control the Microsoft Teams app (and other corporate apps) and enforce compliance – all without managing the device.

How can I enforce compliance when a 3rd party storage is used in Microsoft Teams? Join us as we explore how to monitor/audit and enforce policy using Microsoft Cloud App Security on 3rd party storage in Microsoft Teams.

 

Links

 

 

Weiterlesen »