Kategorie: Exchange

Exchange Online: Postfach von on Premise nicht migrierbar – Mailbox existiert

Als ein Postfach migriert wurde, hatte wohl Exchange Online nicht die ExchangeGUID erkannt und das Postfach neu erstellt.

Somit war die Mailbox doppelt vorhanden, einmal On Premise (mit Daten) und einmal auf Exchange Online (ohne Daten).

Früher bedeutete das, das die Mailbox komplett neu aufgesetzt werden musste und somit alles wieder angepasst werden musste (inkl. Sharepoint usw.).

Mittlerweile gibt es da jedoch ein Powershell Befehlt für (vorher müsst ihr jedoch dem Benutzer die Exchange Lizenz entziehen):

Erst dazu mit einem Rechner verbinden, der auch die Exchange Online Powershell hat und wie folgt verbinden:

$UserCredential = Get-Credential

$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.o ffice365.com/powershell-liveid/ -Credential $UserCredential -Authentication Basic -AllowRedirection

Import-PSSession $Session -DisableNameChecking

Set-User name@domain.tld -PermanentlyClearPreviousMailboxInfo

Jetzt kann man den User wieder nach Exchange Online migrieren.

Anschließend natürlich kontrollieren, ob die Lizenz wieder zugewiesen wurde.

Weitere Infos:

https://techcommunity.microsoft.com/t5/Exchange-Team-Blog/Permanently-Clear-Previous-Mailbox-Info/ba-p/607619


OWA und ECP mit Sophos per 2FA bzw. OTP zusätzlich schützen

Heute bin ich über einen interessanten Artikel gestolpert bei networkguy.de. Dort wird OWA (Outlook Web Access bzw. Outlook Web App) und ECP (Exchange Control Panel) mit einer 2FA (2 Factor Authentification) bzw. OTP (One Time Password) geschützt.

Dies wird mit der Sophos UTM Firewall realisiert, da ich diese in der Homeversion einsetze stehen auch mir diese Optionen dafür offen.

Dafür wird in der Lizensiert die WAF (Web Application Firewall) benötigt.

Die Konfiguration stellt sich in 3 Schritten dar:

  • Umstellen der Sicherheit vom IIS (Internet Information Services) auf Basic und neustarten des Dienstes
  • Erstellen der WAF Regeln in der Sophos
  • Aktivieren der OTP Option in der Sophos

Umstellen der Sicherheit:

  • Melden Sie sich auf dem Exchange Server an
  • Öffnen Sie den Internetinformationsdienste Manager
  • Gehen Sie links im Verzeichnisbaum auf SERVERNAME > Sites > Default Web Site > rechts auf Authentifizierung
  • Wählen Sie bei Standardauthentifizierung auf Aktiviert
  • Gehen Sie auf Start > Ausführen > und geben Sie iisreset gefolgt von einem Enter ein

Nun kommt der 2. Teil, Erstellen der WAF Regeln:

  • Da die Grundkonfiguration der WAF/Exchange-anbindung umfangreicher ist, verweise ich hier auf die Anleitung von networkguy.de – dort ist es geschildert: https://networkguy.de/?p=998
  • Weiter geht es nun nach Webserver Protection > Reverse Authentification > Profiles > Neues Profil erstellen wie folgt:
  • Jetzt diesem Profil noch 2 Regeln erstellen unter Webserver Protection > Web Application Firewall > Site Path Routing > wie folgt:

Anschließend nun der 3. Teil:

  • Dazu unter Definitions & Users > Authentification Services > Ine-Time Password > One-Password Service Status aktivieren und wie folgt einrichten:

Anschließend können sich die User im Userportal dann die App einrichten und OWA bzw. ECP gesichert nutzen. Dazu im Userportel anmelden mit den Anmeldedaten, dann mit der Sophos oder Google Authentificator App den QR Code kopieren.

Dann auf Fortsetzen, beim erneuten Anmelden dann jedoch hinten an dem Passwort noch den Code aus der Authentificator App einfach anhängen (sonst landet man wieder beim QR Code).

Alternativ kann man sich ein Template einrichten, wo man das eigene Design und auch andere Felder – bei mir habe ich Passwort und PIN in eigene Felder gepackt:

Weiterhin muss im ECP noch unter Server > Virtuelle Verzeichnisse > einmal unter OWA und einmal unter ECP Doppelklick > Authentifizierung > Mindestens ein Standardauthentifizierungsverfahren verwenden > Standardauthentifizierung auswählen.

Anschließend mit iisreset den Webserver neustarten.

Nun ist alles eingerichtet und erfolgreich getestet – jetzt können Sie sich am OWA oder ECP anmelden.

Weitere Links:

Hinweis: Sichern Sie vorher unbedingt ihre Server, mindestens jedoch ein Backup der Sophos runterladen und beim IIS die Metabase sichern – besser sind jedoch Vollbackups. Achten Sie auch darauf, das wenn sie 2FA oder OTP denn Zugriff zum Webadmin beschränken, in gewissen Situationen keinen Zugriff mehr haben wenn die App oder das Gerät verloren geht!!


Veeam Community Edition (Freeware)

Veeam hat seine Backup and Replication Sicherungssoftware als Community Edition freigegeben – diese ist nun kostenlos zu haben und das dazu noch mit ein paar richtig Interessanten Features, die gerade in kleinen bis Home Netzwerken äußerst interessant sind:

  • Sicherung kommt zwar ohne vCenter aus und kann Single Host alleine sichern – jedoch benötigt dieser weiterhin eine Lizenz um die Backup API zu nutzen.
  • Sichern als Veeam Datei und nicht mehr als VeeamZIP – somit auch Vollsicherung UND inkrementielle Sicherungen möglich.
  • Sichert nun auch Zeitgesteuert über die Oberfläche und nicht über Umwegen wie Windows Tasks.
  • Sichert virtuelle sowie Physische Server.
  • Sichert auf auf einfache SMB Drives wie z.B. von NAS oder lokal angeschlossene Platten wie USB Platten.
  • Sicherung sowie Replikation möglich.
  • Beschränkt auf 10 VMs.
  • Kann jederzeit auf Lizenz umgestellt werden, ohne Neuinstallation usw.

Download:
https://www.veeam.com/de/virtual-machine-backup-solution-free.html


Office 365 mit Active Directory verbinden

Um Office 365 mit dem AD zu verbinden (um z.B. Exchange- oder Sharepoint Online zu verwenden oder einfach nur Anmeldeprobleme bei Outlook zu beheben) geht ihr bitte wie folgt vor:

  • Die Domain der Emailadresse im AD als UPN einzurichten (DC > Active Directory Domänen und Vertrauensstellungen > Links den obersten Punkt rechte Maustaste > Eigenschaften > Benutzerprinzipalnamen Suffixe die Domain hinzufügen – z.B. domain.de).
  • Den Benutzern im AD den Anmeldenamen an die Emailadresse anpassen (DC > Active Directory Benutzer und Computer > Benutzer Eigenschaften öffnen > Register Konto > Benutzeranmeldename so Einstellen das er zusammen mit der Domain aus der Drop Down Box die Emailadresse ergibt).
  • Unter admin.microsoft.com eine eigene Domain erstellen (bitte dazu eine nicht verwendete Adresse verwenden wie administration oder so – die echten Adressen werden nachher syncronsiert werden mit dem AD) – z.B. sollte euer AD beispiel.local heißen, dann die Domain beispiel.onmicrosoft.com erstellen (wählt den Namen sorgfälltig, er kann im nachhinein nicht geändert werden).
  • Fügt nun die echte Domain hinzu unter admin.microsoft.com > Setup > Domänen (hierzu könnt ihr einen DNS TXT Eintrag erstellen, damit wird verifiziert das die Domain euch gehört), wenn ihr Exchange usw. lokal (ON Premise) nutzt, erstellt bitte nicht die MX Einträge usw.
  • Nun auf dem DC im AD eine OU erstellen für die Office 365 Benutzer und diese dorthin verschieben (DC >Active Directory Benutzer und Computer).
  • Auf einem Memberserver (DCs werden nicht unterstützt) noch die Software Azure AD Connect installieren und einrichten mit den Daten des Kontos das ihr erstellt habt, gebt auch direkt die OU an mit euren Office 365 Benutzern, damit diese nun übertragen werden.
  • Anschließend könnt ihr die User anpassen unter admin.microsoft.com > Benutzer > Aktive Benutzer und diesen bei Bedarf die entsprechende Lizenz oder Dienste zuordnen.




Exchange: Ordnerzugriffe per Shell

Sollte ein Anwender krank sein und jemand muss auf seine Ordner zugreifen, so kann dies der Administrator auch per Shell erledigen.

Hier dazu der Microsoftartikel:

https://docs.microsoft.com/en-us/powershell/module/exchange/mailboxes/add-mailboxfolderpermission?view=exchange-ps

Der Powershell Befehl lautet z.B. wie folgt:

Add-MailboxFolderPermission -Identity <inhaber>:\Mailbox -User <vertretung> -AccessRights Editor -SharingPermissionFlags Delegate

Rechte:
Editor (erstellen)
Reviewer (nur lesen)

Rechtevorgabe Beispiel:
Calender: Editor
Tasks: Reviewer
Inbox: Reviewer

Vorlage:

Add-MailboxFolderPermission -Identity <inhaber>:\Calendar -User <vertretung> -AccessRights Editor
Add-MailboxFolderPermission -Identity <inhaber>:\Tasks -User <vertretung> -AccessRights Reviewer
Add-MailboxFolderPermission -Identity <inhaber>:\Inbox -User <vertretung> -AccessRights Reviewer


Windows/IIS: TLS absichern

Bei der Prüfung eines alten Windows 2008 R2 Servers mit Greenbone Security Assistent wurden mir mehrere Probleme ausgegeben, da der Windows Server 2008 R2 einige Optionen nutzt, die als nicht mehr sicher gelten.

Diese kann man per Registry de- bzw. aktivieren, was jedoch sehr unkomfortabel ist. Einfacher geht es mit dem IIS Crypto Tool 2.0 – dies bietet alle Optionen an und dies sogar noch mit komfortablen Templates.

Die Sicherheit kann man anschließend mit dem SSL Lab Test verifizieren.

Benötigt man ein Offline Tool, da der Server nicht von extern erreichbar ist, kann man ein Tool von Github nutzen, welches auch für Windows existiert.

Anschließend noch SMTP mit TLS testen.

In größeren Umgebungen (hier in dem Beispiel zwei Exchange Server die über Windows Clusterdienste NLB für CAS und Hubtransport zur Verfügung stellen) sollte man behutsam umgehen, ich bin wie folgt vorgegangen:

  • Entfernen EXCHANGE1 aus dem NLB (ca. 5 Sekunden unterbrechung, evtl. kommt kurz bei Clients das Anmeldefenster – wenn zuvor auf dem EXCHANGE1 verbunden gewesen)
  • Warten bis die Warteschlange geleert wurde und kontrollieren, das diese nicht mehr füllt
  • Erstellen Snapshot, falls was schief laufen sollte
  • Erstellen Security-Übersicht
  • Anpassen der Security
  • Kontrolle der Security-Einstellungen
  • Einbinden wieder in den NLB
  • Anpassen der Security-Einstellungen wie auf EXCHANGE1 auf dem EXCHANGE2
  • Testen von Extern mit ausgiebigem Sicherheits-Bericht
  • Besprechen ob Einstellungen anwendbar
  • Testen mit Penetrationstool
  • Wenn alles sauber funktioniert, bereinigen der Snapshots

Quellen:

 


Exchange: Einheitliche Signatur/Disclaimer erstellen über Transportregel

Oft werden Signaturen von Hand erstellt und verteilt. Dabei ist das Design/CI nicht einheitlich oder Informationen sind nicht aktuell, da sie nicht zentral verwaltet werden.

Damit Änderungen nur noch an einer Stelle gemacht werden und auch die Signaturen einheitlich sind, bietet es sich an im Exchange dies direkt Zentral über Transportregeln zu verwalten.

Melden Sie sich dazu im Exchange Control Panel (ECP) an mit einem Administrativen Account unter https://servername/ecp .

Gehen Sie nun nach Nachrichtenfluss > Regeln. Anschließend auf das Pluszeichen und wählt dort den Punkt Haftungsausschlüsse anwenden …

Vergebt den Namen Signatur/Disclaimer und wählt unter Diese Regel anwenden, wenn … die Option Der Absender ist … und wählt dort die Benutzer oder Gruppen aus, auf die die Regeln angewendet werden soll (z.B. falls vorhanden All Users).

Wählen Sie in dem Punkt darunter Folgendermaßen vorgehen … die Option Haftungsausschluss anfügen … aus und bearbeitet den Text mit dem gewünschtem Text (ein Beispiel folgt unten).

Bei Eigenschaften dieser Regel stellen Sie Priorität 0 ein und bei Diese Regel mit folgenden Schweregrad überwachen stellen sie Nicht angegeben ein.

Unter dem Punkt Modus für diese Regel auswählen, wählen Sie bitte Erzwingen.

Beispiel für eine Signatur:

<br><br>
<font face=verdana, tahoma, arial size=2 color=black>%%CustomAttribute1%%<br><br>
<b>%%displayname%%</b></font><br><br>
<font face=verdana, tahoma, arial size=2 color=silver>
%%street%%, %%zipcode%% %%city%%, %%country%%<br>
Telefon: %%phonenumber%%, Fax: %%faxnumber%%, Mobil:
%%mobilenumber%%<br>
Internet: www.leibling.de, Email: %%email%%
</font>

Wenn Sie unter Empfänger > Postfächer die Informationen unter Allgemein und Kontaktinformationen eingegeben haben, können Sie auf diese zurückgreifen (z.B. Anzeigename = %%displayname%%).

Sollten Sie Informationen benötigen, die sie dort nicht hinterlegt haben (z.B. i.A. oder ppa), dann können Sie diese unter Empfänger > Postfächer > Allgemein > Weitere Optionen > Benutzerdefinierte Attribute > Stiftsymbol drücken > In entsprechender Spalte eintragen. Auf diese Werte kann dann mit %%CustomAttribute1%% (Nummer bitte Analog zur Spalte angeben) zurückgegriffen werden – ich habe dort z.B. personalisierte Grußformeln hinterlegt.

Weitere Informationen: https://docs.microsoft.com/en-us/exchange/policy-and-compliance/mail-flow-rules/conditions-and-exceptions?view=exchserver-2019

Informationen für iOS Benutzer:

iOS versendet – wenn in einer Mail keine Formatierung vorhanden ist als Text, somit wird die automatisch erstellt Signatur auch als nur Text angehangen und hat keine Formatierungen. Soll die Formatierung erhalten bleiben, so könnte man in der Signatur auf dem Gerät einfach ein Leerzeichen setzen und dies als Fett markieren. Dann würde die Mails als HTML gesendet und somit blieben die Formatierungen erhalten. Leider entstellte sich bei den Tests jedoch damit das Schriftbild der eigentlichen Mail (es wurde eine Standardschriftart verwendet – leider kann man die Schriftart bei einem iOS Gerät nicht einstellen). Ich habe mich dann dazu entschieden die Mail als nur Text zu lassen (sprich: nicht den Signaturtrick auf dem Gerät anzuwenden), da ich diese dann vom Gesamtbild schicker fand als mit verschiedenen Schriftarten.

Einschränkungen:

  • Wird eine Mail intern weitergeleitet, so wird keine Signatur angehangen – dies ist normal, da die Mail ja nicht über den Transportweg nach außen geht und somit nicht verarbeitet wird. Bei einem internen Weiterleiten, wird die Mail direkt im Postfach abgelegt.
  • Die Signatur kann immer nur an den Anfang gestellt oder ans Ende der Mail angehangen werden – nicht ans Ende einer Nachricht. Wird auf einer Mail geantwortet, so ist die Signatur nicht am Ende des neu geschrieben Textes, sondern am Ende der Mail!
  • Werden Mails verschlüsselt oder signiert, darf die Mail nicht mehr verändert werden – dies würde jedoch geschehen, wenn auf dem Transportweg eine Signatur angehangen würde.

Exchange: TLS Testen

Ein Exchangeserver verwendet wenn möglich TLS (muss auf dem Sende- und Empfangsconnector eingerichtet sein).

Möchte man gerne die Verbindungen kontrollieren, dann kann man OpenSSL installieren und mit dem folgenden Befehl die Verbindung kontrollieren:

openssl s_client -connect remote.leibling.de:25 -starttls smtp

Email: SPF erstellen

Kategorie: Exchange , Server , Sophos , Support

Bei einem Kunden wurden gefälschte Emails an die Buchhaltung gesendet, welche vorgaben von der Geschäftsleitung zu sein, welches das Ziel hatten die Buchhaltung zur Geldüberweisung zu bewegen.

Damit solche gefälschten Mails nicht mehr ankommen (zumindest nicht mit dem gefälschten Absender aus der eigenen Domain) habe ich dann im DNS SPF (Sender Policy Framework) eingerichtet – SPF war schon auf dem Mailgateway eingerichtet.

SPF wird im DNS in Form eine TXT Records eingerichtet – dieser sollte so aussehen:

v=spf1 include:remote.leibling.de include:mx.worldserver.net -all

Im Include sollte jeder Server stehen, der Mails im Namen der Domain versendet. Es kann auch mit ip4:1.2.3.4/24 erweitert werden.

Weitere Infos: https://de.wikipedia.org/wiki/Sender_Policy_Framework

Ein Tool um SPF Einträge zu erstellen gibt es hier: http://www.spf-record.de/generator

Ein Tool um den SPF zu prüfen gibt es hier: https://dmarcian.com/spf-survey/

 


Outlook 2016 kann sich nicht anmelden an Exchange

Ich habe einen Kunden der zwei Standorte hat. Der eine Standort hat Exchange 2010 und alle Rechner vor Ort sind noch mit Outlook 2010 eingerichtet. Diese hatten kein Problem auf den lokalen Exchange Server zuzugreifen, da diese durch das AD konfiguriert werden konnten und nicht über Autodiscover konfiguriert waren.

In dem anderen Standort war „nur“ ein Essentials Server, Exchange wurde über VPN im anderem Standort mitbenutzt. Die Clients hatten ebenfalls noch Outlook 2010 und wurden manuell einrichtet.

Nun kam jedoch ein neuer Client mit Office 2016 dazu im entferntem Stadndort und konnte wegen dem fehlenden Autodiscover nicht eingerichtet werden.

Da der Server jedoch noch Windows Server 2008 R2 war kam einrichten einer weitern Bindung im IIS für Autodiscover (mit SNI) nicht in betracht.

Ich habe dazu dann auf dem DNS im Netz mit dem Exchange eine neue Zone für die Emaildomain eingerichtet und dort einen Servicerecord für Autodiscover erstellt:

  • Start > ausführen > dnsmgmt.msc
  • Forward-lookup-Zone > Neue Zone erstellen (emaildomain)
  • Rechte Maustaste > weitere Einträge erstellen > Dienstidentifizierung (SRV) > Eintrag erstellen
  • Dienst: _autodiscover
  • Protokoll: _tcp
  • Port: 443
  • Host: URL des Exchangeserver

Dazu noch in dem anderen Netz im DNS eine bedingte Weiterleitung eingerichtet für die Emaildomain welche auf den DNS im Exchange Standort zeigt.

Hinweis:

Eine andere Alternative (welche ich jedoch nicht ausprobiert habe) wäre es, wenn man statt einem Servicerecord einen Alias erstellt mit namen autodiscover auf dem Exchange Server.

Sollte eine Anmeldung erfolgen, so bitte unbedingt als Anmeldenamen domain\user verwenden und nicht die Emailadresse.

Vergesst bitte nicht im DNS auch die anderen Adressen anzulegen welche im echten DNS sind (z.B. Exchange URL, www usw.).

Wenn eine Rückfrage kommt, ob die Weiterleitung erlaubt ist diese zulassen und denn Hacken machen bei nicht mehr Rückfragen. Dann erscheint die Rückfrage in Zukunft nicht mehr.